From daemon@optimus.ietf.org Sat Jun 1 02:09:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20271 for ; Sat, 1 Jun 2002 02:09:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA05525 for sip-archive@odin.ietf.org; Sat, 1 Jun 2002 02:09:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04611; Sat, 1 Jun 2002 01:45:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04585 for ; Sat, 1 Jun 2002 01:45:02 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13027 for ; Sat, 1 Jun 2002 01:44:36 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17E1hC-0007j0-00; Sat, 01 Jun 2002 08:44:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15608.24410.666126.161715@harjus.eng.song.fi> Date: Sat, 1 Jun 2002 08:44:58 +0300 To: Jonathan Rosenberg Cc: "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <3CF7ED61.AE86452E@dynamicsoft.com> References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i support jonathan's proposal to have some other header that the nai to tell its identity to the proxy. in the absence of this other header, the from header should serve the purpose (unless it is anonymous). a long time ago i remember someone proposing a "Really-From" for this purpose. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 1 02:12:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21779 for ; Sat, 1 Jun 2002 02:12:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA05674 for sip-archive@odin.ietf.org; Sat, 1 Jun 2002 02:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04507; Sat, 1 Jun 2002 01:39:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04449 for ; Sat, 1 Jun 2002 01:39:52 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12997 for ; Sat, 1 Jun 2002 01:39:25 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17E1cD-0007iv-00; Sat, 01 Jun 2002 08:39:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15608.24101.557895.701535@harjus.eng.song.fi> Date: Sat, 1 Jun 2002 08:39:49 +0300 To: Jonathan Rosenberg Cc: "Elwell, John" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity In-Reply-To: <3CF7DD32.43D6BE52@dynamicsoft.com> References: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C6@Beex50.siemenscomms.co.uk> <3CF7DD32.43D6BE52@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > If > there is a P-Asserted-Identity header present, and it contains a SIP or > SIP URI from an untrusted source, the proxy MAY replace that SIP or SIPS > URI with a single SIP or SIP URI. i don't agree with the replacement in case the message comes from an ua, since if an ua adds an identity there is a some reason for it and if the identity is not what the proxy expects it to be, it should either refuse the request or remove the identity, but not to change it to something else without the user knowing it. but it looks like i'm the only one left on this list that still believes that the user should also have some rights left ... -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 1 02:38:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21992 for ; Sat, 1 Jun 2002 02:38:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06551 for sip-archive@odin.ietf.org; Sat, 1 Jun 2002 02:38:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05575; Sat, 1 Jun 2002 02:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05547 for ; Sat, 1 Jun 2002 02:09:53 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20555 for ; Sat, 1 Jun 2002 02:09:27 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g516ArYH029258; Sat, 1 Jun 2002 02:10:53 -0400 (EDT) Message-ID: <3CF8650C.7B787698@dynamicsoft.com> Date: Sat, 01 Jun 2002 02:09:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Elwell, John" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity References: <15608.24101.557895.701535@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > Jonathan Rosenberg writes: > > > If > > there is a P-Asserted-Identity header present, and it contains a SIP > or > > SIP URI from an untrusted source, the proxy MAY replace that SIP or > SIPS > > URI with a single SIP or SIP URI. > > i don't agree with the replacement in case the message comes from an ua, > since if an ua adds an identity there is a some reason for it and if the > identity is not what the proxy expects it to be, it should either refuse > the request or remove the identity, but not to change it to something > else without the user knowing it. Yes, I agree. The above is only in the case where you are still using the P-Asserted-Identity to support the hint. I have proposed in another mail NOT to do that, and to use a different header. In that case, you would never change a P-Asserted-ID; it'd be stripped at ingress if present, and a new one added with the authentivated identity. In the case where the user suggests a hint that does not correspond to a valid authenticated identity, I think its reasonable for the proxy to reject the request. Of course the hint itself needs to be stripped too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 1 16:47:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27377 for ; Sat, 1 Jun 2002 16:47:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19574 for sip-archive@odin.ietf.org; Sat, 1 Jun 2002 16:48:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18431; Sat, 1 Jun 2002 16:20:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18400 for ; Sat, 1 Jun 2002 16:20:04 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-199-133.dsl.rcsntx.swbell.net [64.217.199.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27075 for ; Sat, 1 Jun 2002 16:19:32 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g51Jqnn07383; Sat, 1 Jun 2002 14:53:02 -0500 Message-ID: <3CF932BB.199D7641@infravast.com> Date: Sat, 01 Jun 2002 15:46:51 -0500 From: Chris Martin Reply-To: christopher.a.martin@wcom.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: "Peterson, Jon" , Cullen Jennings , Mark Watson , sip Subject: Re: [Sip] Comments on draft-ietf-sip-asserted-identity-00 References: <3CF6A500.8080901@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Some comments/questions: > > > If a UA is part of the Trust Domain from which it received a message > > containing a P-Asserted-Identity header field, then it can use the > > value freely but it MUST ensure that it does not forward the > > information to any element that is not part of the Trust Domain. > > > > Does this in any way depend on a request for privacy? Or do we place a > stronger burden on a UAS than on a proxy for non-sharing of asserted > identity? A proxy is a UAS right? > > (OK, just one question) If the UA is part of a trust domain doesnt that imply that it has an intermediary UAS. If so wouldnt that UAS be the element responsible for forwarding/not forwarding/enforce the information relayed to elements outside the Trust Domain? Chris > > Thanks! > > Ben. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 1 20:28:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28905 for ; Sat, 1 Jun 2002 20:28:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA26638 for sip-archive@odin.ietf.org; Sat, 1 Jun 2002 20:28:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25758; Sat, 1 Jun 2002 20:00:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25705 for ; Sat, 1 Jun 2002 20:00:19 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28657 for ; Sat, 1 Jun 2002 19:59:51 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g51NxWK37898; Sat, 1 Jun 2002 18:59:32 -0500 (CDT) Message-ID: <3CF95FDA.5010305@dynamicsoft.com> Date: Sat, 01 Jun 2002 18:59:22 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: christopher.a.martin@wcom.com CC: "Peterson, Jon" , Cullen Jennings , Mark Watson , sip Subject: Re: [Sip] Comments on draft-ietf-sip-asserted-identity-00 References: <3CF6A500.8080901@dynamicsoft.com> <3CF932BB.199D7641@infravast.com> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chris Martin wrote: > Ben Campbell wrote: > >>Some comments/questions: >> >> >>>If a UA is part of the Trust Domain from which it received a message >>> containing a P-Asserted-Identity header field, then it can use the >>> value freely but it MUST ensure that it does not forward the >>> information to any element that is not part of the Trust Domain. >>> >> >>Does this in any way depend on a request for privacy? Or do we place a >>stronger burden on a UAS than on a proxy for non-sharing of asserted >>identity? > > > A proxy is a UAS right? Actually, no, a UAS is the endpoint receiving and responding to the request, i.e. the final server side of the transaction. (For end-to-end responses, at least.) > > >>(OK, just one question) > > > If the UA is part of a trust domain doesnt that imply that it has an > intermediary UAS. If so wouldnt that UAS be the element responsible for > forwarding/not forwarding/enforce the information relayed to elements > outside the Trust Domain? Assuming you mean proxy when you write UAS, there is no such impication. You could have a trivial trust domain that just includes a UAC and UAS, with no proxies. But your second sentence is true (again, assuming you meant to say proxy.) if privacy is requested. My comment was directed to the fact that a proxy _can_ forward the AI to non-trusted nodes if privacy is _not_ requested. But unless I read wrong, a UA cannot do so even if privacy is not requested. This has implications for certain UA types (like PSTN gateways) > > Chris > > >>Thanks! >> >>Ben. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jun 2 04:39:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12105 for ; Sun, 2 Jun 2002 04:39:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22005 for sip-archive@odin.ietf.org; Sun, 2 Jun 2002 04:39:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20649; Sun, 2 Jun 2002 04:05:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20620 for ; Sun, 2 Jun 2002 04:05:08 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11864 for ; Sun, 2 Jun 2002 04:04:41 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17EQMJ-00085m-00; Sun, 02 Jun 2002 11:05:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15609.64525.116567.516784@harjus.eng.song.fi> Date: Sun, 2 Jun 2002 14:05:49 +0300 To: Ben Campbell Cc: Jonathan Rosenberg , "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <3CF96096.1070506@nostrum.com> References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> <15608.24410.666126.161715@harjus.eng.song.fi> <3CF96096.1070506@nostrum.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell writes: > The fact that the From field _can_ be anonymous makes the From header a > not-very-good choice. It is entirely possible you would want to use such > a hint _and_ request anonymity. in which case as i proposed to use Really-From header in the very same message to which you replied. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jun 2 13:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17532 for ; Sun, 2 Jun 2002 13:50:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11469 for sip-archive@odin.ietf.org; Sun, 2 Jun 2002 13:50:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10536; Sun, 2 Jun 2002 13:17:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10506 for ; Sun, 2 Jun 2002 13:17:32 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17276 for ; Sun, 2 Jun 2002 13:17:03 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17EYyt-0008Co-00; Sun, 02 Jun 2002 20:17:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15610.32134.161769.848896@harjus.eng.song.fi> Date: Sun, 2 Jun 2002 23:18:14 +0300 To: Ben Campbell Cc: Jonathan Rosenberg , "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <3CFA48B0.7010904@nostrum.com> References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> <15608.24410.666126.161715@harjus.eng.song.fi> <3CF96096.1070506@nostrum.com> <15609.64525.116567.516784@harjus.eng.song.fi> <3CFA48B0.7010904@nostrum.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell writes: > This means any device that cares has to check From, and then under some > conditions check somewhere else. It would be much better to have only > one header to check for this purpose. in theory yes, but for backwards compatibility we MUST support current UAs that do not insert Really-From. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jun 2 23:52:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24231 for ; Sun, 2 Jun 2002 23:52:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA04734 for sip-archive@odin.ietf.org; Sun, 2 Jun 2002 23:53:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04236; Sun, 2 Jun 2002 23:34:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04205 for ; Sun, 2 Jun 2002 23:34:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23981 for ; Sun, 2 Jun 2002 23:33:32 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g533YuYH001326; Sun, 2 Jun 2002 23:34:56 -0400 (EDT) Message-ID: <3CFAE37E.A10D33A3@dynamicsoft.com> Date: Sun, 02 Jun 2002 23:33:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: fluffy@cisco.com CC: sip@ietf.org, Jon Peterson , mwatson@nortelnetworks.com References: <200205291133.HAA11227@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Comments on this draft: > Extensions to the Session Initiation Protocol (SIP) for Asserted > Identity within Trusted Networks > draft-ietf-sip-asserted-identity-00 Based on iesg feedback on the call-auth draft, I suggest you pre-emptively add "Private" to the beginning. > This document describes private extensions to SIP that enable a > network of trusted SIP servers to assert the identity of end users or > end systems I seem to recall that the requirements explicitly talk about the identity of users (calling and called parties), and NOT their devices/end-systems (the phone can authenticate itself as the phone using sip...). Its a nit, but one of my big concerns is that we are clear on WHAT identity is being asserted. > This > document does NOT offer a general privacy or identity model suitable > for inter-domain use, But it does; can't the trust domain span "domains" in the traditional DNS sense? > The means by which the > network determines the identity to assert is outside the scope of > this document (though it commonly entails some form of > authentication). I thought it was a requirement that the specification clearly define the means by which identity is authenticated. > A key requirement of [5] is that the behavior of all nodes within a > given Trust Domain 'T' is known to comply to a certain set of > specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for > the following: > > 1. The manner in which users are authenticated OK, I think I am confused. I had thought that spec(T) was THIS document, but perhaps its more of some abstract thing that a domain is aware of (my apologies if this was extensively discussed - i missed many of the threads on this subject). I fear the requirements doc might be conflating the two, since I finished my read of that assuming that this was the case. In any case, the list of things spec(T) has to specify belongs in the requiremetns document, not here, I would think, and certainly not in the applicability statement. > For example, a caller that wants to > maintain privacy and consequently provides limited information in the > SIP From header field will not be identifiable by recipients of the > call unless they rely on some other means to discovery the identity > of the caller. s/discovery/discover However, I think this example doesn't support the claim above. The outcome described here - that the recipients of the call can't know who the caller is - is the desired outcome, and not an error. The claim is that certain combinations that need to be supported, can't be supported. This is NOT such a combination. > This document attempts to address this requirement using a very "this requirement" is a dangling reference here, since the requirement you are talking about is mentioned two paragraphs above. I suggest "This document attempts to provide a network asserted identity service...." > [5] Watson, M., "Short term requirements for Network Asserted > Identity", draft-ietf-sipping-nai-reqs-01 (work in progress), > May 2002. This is listed as a normative requirement, but its going to be an informational RFC. I don't believe you can have informational RFCs as normative dependencies. You should make it an informational reference. > When a proxy receives a > message from a node it does not trust, the proxy MUST authenticate > the originator of the message, and use the identity which results > from this authentication to insert an appropriate P-Asserted-Identity > header field into the message. This won't work, of course, for a proxy that receives an incoming call made by a user in a separate domain. You can't mandate that a proxy authenticate ALL incoming requests, and certainly not all incoming messages (which then includes responses). I think you mean that a proxy MAY authenticate the originator... Furthermore, the word "appropriate" is too vague here. You need to be more specific. Also, shouldn't this bit here mention something about spec(T) - using the authentication mechanism described there, or something? > 6. Hints for Multiple Identities isn't this part of proxy behavior? It should be a subsection of 5. Indeed, it should probably be towards the beginning of 5, which needs to lay out a rigorous set of processing steps for a proxy, preferably in the order they need to be done. Since the hints are used in the beginning of proxy processing, they belong early on. Also, I just commented in a separate email that I do not believe we should reuse P-Asserted-ID for this. > Parties who wish to request the removal of P-Asserted-Identity header > fields before they are transmitted to an element that is not trusted > may add the "id" privacy token to the Privacy header field. reference to privacy spec is appropriate here. > If there is no Privacy header field, the proxy MAY include the P- > Asserted-Identity header field or it MAY remove it. You need to qualify this sentence with "when forwarding the request to an untrusted element." > Users will typically want to > request "id" privacy when they are challenged for authentication. This seems to imply that the only time you need to include the Privacy: id is when you send the request as a result of a 401/407. But, thats not true. Consider a proxy connected to a user with TLS (which will be the case frequently in order to establish trust between the user and thr proxy). The proxy need only challenge the user once; subsequent requests over the same tls connection are known to be from the same user. Thus, these rqeuests are not a result of a 401/407, but need to have the Privacy: id header on them since the proxy can assert an identity. > If multiple P-Asserted-Identity headers field values are present in a > message, and privacy of the P-Asserted-Identity header field is > requested, then all instances of the header field values MUST be > removed. add "before forwarding the request to an untrusted entity". Section 7, as with 6, needs to be split up and the appropriate behavior relegated to sections on UAC, UAS and proxy behavior. > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity of the user > sending a SIP message as it was verified by authentication. > > PAssertedID = "P-Asserted-Identity" HCOLON ( name-addr / addr-spec ) This grammar is not correct. Multiple headers with a single value MUST be identical to a single header with multiple values. That is, the following two need to be the same: P-Asserted-Identity: sip:user1@domain.com, tel:5551212 and P-Asserted-Identity: sip:user1@domain.com P-Asserted-Identity: tel:5551212 indeed, no matter which form is used, this is formally referred to as a "P-Asserted-Identity header field with multiple values". Thus, your BNF must be: PAssertedID = "P-Asserted-Identity" HCOLON pid-value *(COMMA pid-value) pid-value = nameaddr / addr-spec > There may be zero or one P-Asserted-Identity > headers with either a SIP or SIPS URI and in addition there may be > zero or one P-Asserted-Identity headers with a tel URL. These words are not correct. The proper wording is: "There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI, and the other MUST be a tel URL." > Header field where proxy ACK BYE CAN INV OPT REG > ------------ ----- ----- --- --- --- --- --- --- > P-Asserted-Identity adr - o - o o - > > > SUB NOT REF INF UPD PRA > --- --- --- --- --- --- > o o o - - - Is there a particular reason that this header is excluded from usage in INFO, UPDATE, PRACK, REGISTER and ACK? The only one where it doesn't make sense is CANCEL. > The presence of this privacy type in > a Privacy header field indicates that the user would like the Network > Asserted Identity to be kept private with respect to SIP entities > outside the Trust Domain or trust federation with which the user > authenticated. This is the first time the term "trust federation" is introduced. Please stick to terminology from the requirements document. > Via header branch parameters are > omitted for clarity. Well, you've included call-ids, cseqs, and even tags. Please do include the branch IDs so that these are valid requests, else make them have ONLY the headers relevant to the flow, so its clear that they are not valid requests. The latter is preferred. Section 10.1 should have a ladder diagram. In 10.1, message F2 is missing a to tag (all responses have them) In 10.2, there is an extra CRLF in message F3, after max-forwards. > 13.2 Registration of "id" privacy type for SIP Privacy header > > Name of privacy type: id You need to reference the section of the privacy spec which has defined this IANA registry. Furthermore, the information provided here must match, word for word, the request information defined by the privacy spec. Unfortuantely, it doesn't do that properly yet, but these two docs need to get aligned on that. Thanks, Jonathan R. 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 : Extensions to the Session Initiation Protocol > (SIP) > for Asserted Identity within Trusted Networks > Author(s) : C. Jennings, J. Peterson, M. Watson > Filename : draft-ietf-sip-asserted-identity-00.txt > Pages : 17 > Date : 28-May-02 > > This document describes private extensions to SIP that enable a > network of trusted SIP servers to assert the identity of end users or > end systems, and the application of existing privacy mechanisms to > the identity problem. The use of these extensions is only applicable > inside an administrative domain with previously agreed-upon policies > for generation, transport and usage of such information. This > document does NOT offer a general privacy or identity model suitable > for inter-domain use, or use in the Internet at large. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-00. > txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-asserted-identity-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-asserted-identity-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > Subject: > Date: Wed, 29 May 2002 12:44:54 -0400 > > ------------------------------------------------------------------------ > > ATT40156.txtName: ATT40156.txt > Type: Plain Text (text/plain) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 00:17:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24503 for ; Mon, 3 Jun 2002 00:17:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06052 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 00:18:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04925; Sun, 2 Jun 2002 23:56:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04898 for ; Sun, 2 Jun 2002 23:56:10 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24263 for ; Sun, 2 Jun 2002 23:55:41 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g533tA428045; Sun, 2 Jun 2002 22:55:10 -0500 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Peterson, Jon'" Cc: "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Sun, 2 Jun 2002 22:55:09 -0500 Message-ID: <004b01c20ab2$75411090$b27ba8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3CF7ED61.AE86452E@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > My reasoning is simple. A header has a particular meaning. > That meaning should be invariant to where that header > appears, request or response, or any other conditions. We > have been burned HARD by this one with the Contact header, > which really has two different meanings depending on context. > It was only much later on we realized that we needed both in > the same request, but of course, its too late... > > P-Asserted-Identity should mean "this is the identity > asserted by the trust domain for the originator of this > message". Period. That is not at all the same thing as "this > is the identity the end user would like you to use, assuming > its one of the allowed identities for this user". In fact, > there are vastly different trust implications for the two > semantics. I can see right now a case where some > misconfigured proxy forgets to strip the "hint" and all of a > sudden it becomes a fraudulent call, since the hint was the > identity of a different user. I think I disagree. I think existence of a P-A-I header in a message means "a previous hop (sender or proxy) has asserted this identity. Deal with it." Options for dealing with it are: 1) Believe it 2) Delete it (in conjunction with "privacy" modifier) 3) Delete it and assert a different identity 4) Reject the message There are some interesting transitivity properties if one considers that ANY delivered P-A-I is potentially a "hint". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 07:59:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09166 for ; Mon, 3 Jun 2002 07:59:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05496 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 08:00:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04696; Mon, 3 Jun 2002 07:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04667 for ; Mon, 3 Jun 2002 07:39:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08472; Mon, 3 Jun 2002 07:38:35 -0400 (EDT) Message-Id: <200206031138.HAA08472@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, 03 Jun 2002 07:38:35 -0400 Subject: [Sip] I-D ACTION:draft-henrikson-sip-charging-information-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private SIP Extension for Mobile Charging Information Author(s) : E. Henrikson Filename : draft-henrikson-sip-charging-information-03.txt Pages : 10 Date : 31-May-02 This memo describes a private extension to SIP in the form of P-Charging-Function-Addresses and P-Charging-Vector headers. The former header is used to pass the addresses of entities that provide a charging function. The latter header is used to pass charging correlation information. The affected UAs and proxies associated with a dialog or standalone transaction need to know the identities or addresses of the appropriate charging entities. They also need to pass correlation information so that the records generated and sent to the charging entities may be properly associated for a coordinated billing effort. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-information-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-henrikson-sip-charging-information-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-henrikson-sip-charging-information-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: <20020531131709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-henrikson-sip-charging-information-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-henrikson-sip-charging-information-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531131709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 09:24:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11769 for ; Mon, 3 Jun 2002 09:24:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10001 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 09:25:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08208; Mon, 3 Jun 2002 08:56:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08171 for ; Mon, 3 Jun 2002 08:56:40 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-219-169-59.dsl.rcsntx.swbell.net [64.219.169.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10611 for ; Mon, 3 Jun 2002 08:56:09 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g53CCrn14341; Mon, 3 Jun 2002 07:12:54 -0500 Message-ID: <3CFB69F7.462D62C1@infravast.com> Date: Mon, 03 Jun 2002 08:07:03 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: christopher.a.martin@wcom.com, "Peterson, Jon" , Cullen Jennings , Mark Watson , sip Subject: Re: [Sip] Comments on draft-ietf-sip-asserted-identity-00 References: <3CF6A500.8080901@dynamicsoft.com> <3CF932BB.199D7641@infravast.com> <3CF95FDA.5010305@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Chris Martin wrote: > > Ben Campbell wrote: > > > >>Some comments/questions: > >> > >> > >>>If a UA is part of the Trust Domain from which it received a message > >>> containing a P-Asserted-Identity header field, then it can use the > >>> value freely but it MUST ensure that it does not forward the > >>> information to any element that is not part of the Trust Domain. > >>> > >> > >>Does this in any way depend on a request for privacy? Or do we place a > >>stronger burden on a UAS than on a proxy for non-sharing of asserted > >>identity? > > > > > > A proxy is a UAS right? > > Actually, no, a UAS is the endpoint receiving and responding to the > request, i.e. the final server side of the transaction. (For end-to-end > responses, at least.) > > > > > > >>(OK, just one question) > > > > > > If the UA is part of a trust domain doesnt that imply that it has an > > intermediary UAS. If so wouldnt that UAS be the element responsible for > > forwarding/not forwarding/enforce the information relayed to elements > > outside the Trust Domain? > > Assuming you mean proxy when you write UAS, there is no such impication. > You could have a trivial trust domain that just includes a UAC and UAS, > with no proxies. But your second sentence is true (again, assuming you > meant to say proxy.) if privacy is requested. Thanks. and yes, that was what I meant. :^) > > My comment was directed to the fact that a proxy _can_ forward the AI to > non-trusted nodes if privacy is _not_ requested. But unless I read > wrong, a UA cannot do so even if privacy is not requested. This has > implications for certain UA types (like PSTN gateways) > > > > > Chris > > > > > >>Thanks! > >> > >>Ben. > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 09:33:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12257 for ; Mon, 3 Jun 2002 09:33:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10899 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 09:33:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09856; Mon, 3 Jun 2002 09:22:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09244 for ; Sun, 2 Jun 2002 12:33:24 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16919 for ; Sun, 2 Jun 2002 12:32:56 -0400 (EDT) Received: from nostrum.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g52GX1K01127; Sun, 2 Jun 2002 11:33:01 -0500 (CDT) Message-ID: <3CFA48B0.7010904@nostrum.com> Date: Sun, 02 Jun 2002 11:32:48 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Jonathan Rosenberg , "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> <15608.24410.666126.161715@harjus.eng.song.fi> <3CF96096.1070506@nostrum.com> <15609.64525.116567.516784@harjus.eng.song.fi> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This means any device that cares has to check From, and then under some conditions check somewhere else. It would be much better to have only one header to check for this purpose. jh@lohi.eng.song.fi wrote: > Ben Campbell writes: > > > The fact that the From field _can_ be anonymous makes the From header a > > not-very-good choice. It is entirely possible you would want to use such > > a hint _and_ request anonymity. > > in which case as i proposed to use Really-From header in the very same > message to which you replied. > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 09:36:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12358 for ; Mon, 3 Jun 2002 09:36:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11106 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 09:36:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09865; Mon, 3 Jun 2002 09:22:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26089 for ; Sat, 1 Jun 2002 20:03:08 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28684 for ; Sat, 1 Jun 2002 20:02:40 -0400 (EDT) Received: from nostrum.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g5202eK38096; Sat, 1 Jun 2002 19:02:40 -0500 (CDT) Message-ID: <3CF96096.1070506@nostrum.com> Date: Sat, 01 Jun 2002 19:02:30 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Jonathan Rosenberg , "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'David R. Oran'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> <15608.24410.666126.161715@harjus.eng.song.fi> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The fact that the From field _can_ be anonymous makes the From header a not-very-good choice. It is entirely possible you would want to use such a hint _and_ request anonymity. jh@lohi.eng.song.fi wrote: > i support jonathan's proposal to have some other header that the nai to > tell its identity to the proxy. in the absence of this other header, > the from header should serve the purpose (unless it is anonymous). a > long time ago i remember someone proposing a "Really-From" for this > purpose. > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 10:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14537 for ; Mon, 3 Jun 2002 10:11:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13746 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 10:12:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12236; Mon, 3 Jun 2002 09:54:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12206 for ; Mon, 3 Jun 2002 09:54:02 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13508 for ; Mon, 3 Jun 2002 09:53:31 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g53Dre6n007921 for ; Mon, 3 Jun 2002 15:53:41 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g53Drda9029347 for ; Mon, 3 Jun 2002 16:53:39 +0300 (EET DST) Message-ID: <3CFB74E2.30EFE0C0@ericsson.com> Date: Mon, 03 Jun 2002 16:53:38 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 3 P- headers draft submission Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I have just submitted a new version of 3 P- headers drafts I am editing, namely P-Visited-Network-ID, P-Associated-URI and P-Called-Party-ID. I only updated the references and the IANA considerations section. They will be available soon. In the meantime, you can download a copy from: http://standards.ericsson.net/sip/drafts/draft-garcia-sip-visited-network-id-03.txt http://standards.ericsson.net/sip/drafts/draft-garcia-sip-associated-uri-03.txt http://standards.ericsson.net/sip/drafts/draft-garcia-sip-called-party-id-03.txt /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 12:40:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22525 for ; Mon, 3 Jun 2002 12:40:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15408 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 12:41:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13017; Mon, 3 Jun 2002 12:18:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12934 for ; Mon, 3 Jun 2002 12:18:14 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21821 for ; Mon, 3 Jun 2002 12:17:45 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g53GHbI29223; Mon, 3 Jun 2002 11:17:37 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 11:17:32 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870396@va02.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general Date: Mon, 3 Jun 2002 11:17:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think Proxy-Require is overkill if it is only being used to manage your connection to a server one hop away from you - though I get the point about removing the Proxy-Require, potentially, once the privacy service has been reached. Ultimately, there probably isn't any other way to provide an assurance that a given intermediary instantiates the privacy service role. Somewhat reluctantly (since I don't think this is an ideal use of Proxy-Require), I agree we should include it in the privacy draft as an optional failsafe for user agents. As for whether or not a privacy service MUST be one hop away from the user agent requesting privacy, we encourage it, but also offer ways to accomodate a more distant privacy service (i.e. SIPS). I see no reason to levy any absolute constraints on the proximity of the privacy service. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, May 31, 2002 1:17 PM > To: Bob Penfield > Cc: Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general > > > > > Bob Penfield wrote: > > > > > > > How does the user know whether privacy services are > supported? Do > > they > > > > need to try it with Proxy-Require to see if the request fails? > > > > > > > > > > The text above is meant to suggest that users should know > out-of-band > > that > > > their local administrative domain supports a privacy > service function. > > > > I too am quite concerned about this. It seems adaquate to say the UA > > "just > > knows" when we're talking about a P-Header with limited > applicability, > > but > > not necessarily for a general purpose protocol mechanism. > > Right. > > > > > However, this mechanism would use a Require header, not a > Proxy-Require. > > There are very few headers mentioned in this draft that RFC > 3261 allows > > a > > proxy to modify or delete. I assert that performing any > user, header or > > session privacy functions in an intermediary turns the > privacy service > > into > > a B2BUA. If the UA is aware that is sending to a privacy > service then it > > can > > certainly be aware that it is sending to a B2BUA and > include the tag in > > its > > Require header. > > Hmm. The problem is that you want get the desired effect if > there are no > privacy services on the path, and you thought there were. Inserting a > Require: privacy in teh request would get the request all the > way to the > UAS, who then knows your identity, in addition to knowing that you > wanted to be anonymous. Seems like the worst of all cases. > So, while in > theory, you might be right, practically speaking this has to be > proxy-require to work. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 12:46:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22628 for ; Mon, 3 Jun 2002 12:46:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09299 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 12:47:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26732; Mon, 3 Jun 2002 12:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26625 for ; Mon, 3 Jun 2002 12:02:44 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21092 for ; Mon, 3 Jun 2002 12:02:13 -0400 (EDT) Received: from OranLT.cisco.com ([161.44.238.34]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g53G23PI027385; Mon, 3 Jun 2002 09:02:03 -0700 (PDT) Date: Mon, 03 Jun 2002 12:01:48 -0400 From: "David R. Oran" To: Jonathan Rosenberg , "Peterson, Jon" cc: "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? Message-ID: <310935862.1023105708@OranLT.cisco.com> In-Reply-To: <3CF7ED61.AE86452E@dynamicsoft.com> References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I find Jonathan's point quite persuasive. It might help with clarity on Juha's application of the header as well. In fact, if we have a separate header for the UA to insert, it might also encode user's desire about whether he wants the service provider to reject the call if it is unwilling to use the UA-asserted identity. If we go the renaming route, could conveivably have: p-ua-asserted-identity, and p-proxy-asserted-identity. Dave. --On Friday, May 31, 2002 5:38 PM -0400 Jonathan Rosenberg wrote: > I hate to throw a wrench in here, but since we do have an oppty for > another rev of the doc during ietf LC, I would like to voice an opinion. > > I don't believe that the hint should use the same header. > > My reasoning is simple. A header has a particular meaning. That meaning > should be invariant to where that header appears, request or response, > or any other conditions. We have been burned HARD by this one with the > Contact header, which really has two different meanings depending on > context. It was only much later on we realized that we needed both in > the same request, but of course, its too late... > > P-Asserted-Identity should mean "this is the identity asserted by the > trust domain for the originator of this message". Period. That is not at > all the same thing as "this is the identity the end user would like you > to use, assuming its one of the allowed identities for this user". In > fact, there are vastly different trust implications for the two > semantics. I can see right now a case where some misconfigured proxy > forgets to strip the "hint" and all of a sudden it becomes a fraudulent > call, since the hint was the identity of a different user. > > It wouldn't shock me either if one day down the road we find we do need > both of these things in the same request. > > I don't care what you call it. But, its not P-Asserted-Identity. > > -Jonathan R. > > > "Peterson, Jon" wrote: >> >> Since I've never been one to fly in the face of public opinion (cough), >> I'll agree (at least in this case) that we should go with majority rule >> and use the Asserted-Identity header for the 'hint'. >> >> Jon Peterson >> NeuStar, Inc. >> >> -----Original Message----- >> From: Mark Watson [mailto:mwatson@nortelnetworks.com] >> Sent: Thursday, May 23, 2002 9:18 AM >> To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy'; >> sip@ietf.org >> Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> >> In the absence of further comment, can I make a *proposal* that we stick >> with Asserted-Identity for the hint and for the NAI itself, and that >> both are described in Cullen's draft ? >> >> Can we take this as AGREED if there are no comments by cob tomorrow ? >> (Guidance sought from chairs on this second question). >> >> Updated requirements draft to be submitted first thing tomorrow. >> >> Regards...Mark >> >> > -----Original Message----- >> > From: Andrew Allen [ mailto:AAllen@dynamicsoft.com >> ] >> > Sent: 22 May 2002 15:51 >> > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; >> > 'Rohan Mahy'; sip@ietf.org >> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> > >> > >> > >> > I agree with Dave. Lets put the hint in the >> > asserted-identity. Lets not have >> > two redundant headers that need to be transferred over the >> > Radio interface >> > unnecessarily. >> > >> > Andrew >> > >> > > -----Original Message----- >> > > From: David R. Oran [ mailto:oran@cisco.com >> ] >> > > Sent: Wednesday, May 22, 2002 9:45 AM >> > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org >> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> > > >> > > >> > > I suggest we allow the hint to be placed in the >> > > asserted-identity rather >> > > than in another header. A boundary proxy has to deal with a >> > UA putting >> > > in the header no matter what, if only to reject the request with an >> > > error. >> > > >> > > Once we have a full solution the issue of hints should go >> > > away as a side >> > > effect of having the "authorization server" functionality that Jon >> > > proposes. Better IMHO to have one obsolescent header to deal >> > > with rather >> > > than two, as well as avoiding the concomitant verbiage >> > describing the >> > > combinatoric cases involving two headers. >> > > >> > > Dave. >> > > >> > > > -----Original Message----- >> > > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org >> ] On >> > > > Behalf Of Mark Watson >> > > > Sent: Wednesday, May 22, 2002 9:59 AM >> > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> > > > Importance: High >> > > > >> > > > >> > > > All, >> > > > >> > > > Can we have a *decision* asap as to whether the 'hint' uses >> > > > Asserted-Identity, or another header in another draft. >> > > > >> > > > I do not mind which. If the latter I will publish an I-D >> > > > describing it as soon as we have a decision, assuming it is >> > > > this week, since I'm away next week. >> > > > >> > > > If we do nothing, then I guess 3GPP will make up its own mind >> > > > how to do this, without supervision or advice from IETF, >> > > > which I think would be a bad thing. >> > > > >> > > > Regards...Mark >> > > > >> > > > >> > > > -----Original Message----- >> > > > From: Watson, Mark [MDN05:EP10:EXCH] >> > > > Sent: 20 May 2002 12:08 >> > > > To: 'Peterson, Jon'; 'Rohan Mahy' >> > > > Cc: sip@ietf.org >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> > > > >> > > > >> > > > The 'hint' was one of the three requirements that 3GPP >> > > > communicated to us in April. >> > > > It is a separate requirement from the Network Asserted >> > > > Identity itself, and so is not addressed in the requirements >> > > > draft, although I have been careful to point this out, and to >> > > > point out that it is a requirement nontheless, on several >> > > > occasions. I believe we need the 'hint' in the same timeframe >> > > > as the rest of the short term work. >> > > > Whether it is the same header/draft or a different >> > > > header/draft is another question on which I will only say >> > > > that we'd better make up our minds pretty quick. ...Mark >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz >> ] >> > > > > Sent: 19 May 2002 18:11 >> > > > > To: 'Rohan Mahy' >> > > > > Cc: sip@ietf.org >> > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? >> > > > > >> > > > > >> > > > > >> > > > > My argument was not that the proposed hint won't work - just >> > > > > that it isn't >> > > > > necessary to solve the problem at hand. It might not be the >> > > > > case that the >> > > > > problems with the hint stop at the philosophical point you >> > > > > mention below. >> > > > > What I asked in my last mail was not whether or not we needed >> > > > > a hint, but >> > > > > rather whether or not we should table that question until we >> > > > > resolve the >> > > > > other questions at hand. I just don't want to spend the >> > > > > cycles arguing about >> > > > > the hint given our very aggressive timetable - frankly, I >> > > > think that >> > > > > reaching consensus on this hint matter might push back our >> > > > > dates a bit. >> > > > > Let's investigate this hint stuff in June, but for now just >> > > > > figure out how a >> > > > > Trust Domain can manage an asserted identity in a message. >> > > > > >> > > > > Jon Peterson >> > > > > NeuStar, Inc. >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Rohan Mahy [ mailto:rohan@cisco.com >> ] >> > > > > > Sent: Sunday, May 19, 2002 8:29 AM >> > > > > > To: Peterson, Jon >> > > > > > Cc: sip@ietf.org >> > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? >> > > > > > >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > The requirement for a hint is well understood, limited in >> > > > > > scope, and well motivated in the draft. Nobody has >> > identified >> > > > > > any technical reason why the hint won't work. Your argument >> > > > > > that allowing a hint weakens the strength of the language on >> > > > > > ignoring Asserted-Identity from untrusted parties is purely >> > > > > > philosophical in nature. I don't buy your argument. >> > > > > > >> > > > > > thanks, >> > > > > > -rohan >> > > > > > >> > > > > > >> > > > > > ---- Original message ---- >> > > > > > > Date: Fri, 17 May 2002 16:02:11 -0500 >> > > > > > > From: "Peterson, Jon" >> > > > > > > Subject: [Sip] Asserted-Identity: How to 'hint'? >> > > > > > > To: "'sip@ietf.org'" >> > > > > > > >> > > > > > > >> > > > > > > In the course of the discussion between Mark Watson, Cullen >> > > > > > Jennings and >> > > > > > > myself about the short-term identity work, we have returned a >> >> > > > > > few times to >> > > > > > > the question of the infamous hint. This hint is, of course, a >> >> > > > > > way that a >> > > > > > > user agent (one that is not a member of the Trust Domain in >> > > > > > the short-term >> > > > > > > network asserted identity space) can provide a 'hint' to the >> > > > > > intermediary >> > > > > > > that will generate an Asserted-Identity indicating which >> > > > > > identity among >> > > > > > > several possibilities should be asserted. >> > > > > > > >> > > > > > > The need for this arises particularly from the 3G space, in >> > > > > > which the >> > > > > > > authentication process takes place independently of SIP and >> > > > > > does not carry >> > > > > > > this sort of personal identity information. It also assumes >> > > > > > that the >> > > > > > > operators of the intermediary in question are aware of >> > > > > > several legitimate >> > > > > > > identities which the user can elect to assert. >> > > > > > > >> > > > > > > It has been proposed on the mailing list and >> > elsewhere that the >> > > > > > > Asserted-Identity header should be re-used by user agents >> > > > > > outside the Trust >> > > > > > > Domain to provide such a hint. I see a number of reasons for >> > > > > > and against >> > > > > > > using the Asserted-Identity for this purpose. For example, >> > > > > > today, there is a >> > > > > > > requirement that asserted-identities which are transmitted >> > > > > > from untrusted >> > > > > > > sources should not be used in any way - this would seem to >> > > > > > weaken that >> > > > > > > requirement. There is also possibly some behavior that still >> > > > > > needs to be >> > > > > > > specified (like how an intermediary would reject or otherwise >> >> > > > > > handle a >> > > > > > > request with an inappropriate hint) that might be impactful >> > > > > > to our choice. >> > > > > > > >> > > > > > > For the time being, however, I would like to suggest that >> > > > > > providing the hint >> > > > > > > is outside the scope of the current deliverables (the >> > > > > > asserted-identity >> > > > > > > requirements and mechanism drafts), which need to be >> > > > > > complete, as we >> > > > > > > discussed in the interim meeting, by the end of this month. I >> >> > > > > > believe that a >> > > > > > > separate draft should propose the use of Asserted-Identity or >> >> > > > > > any other >> > > > > > > header for this hint (in whatever timeframe is appropriate >> > > > > > for 3G's >> > > > > > > requirements), but that we should not speak to this matter in >> >> > > > > > the current >> > > > > > > asserted-identity deliverables. There is, as I see it, no >> > > > > > dependency on >> > > > > > > defining this hint before we dictate how intermediaries will >> > > > > > assert >> > > > > > > identities. >> > > > > > > >> > > > > > > Any comments on this plan? >> > > > > > > >> > > > > > > Jon Peterson >> > > > > > > NeuStar, Inc. >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> >> > > > > > > This list is for NEW development of the core SIP 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 >> > > >> > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com ----------------------------------------------------------- David R. Oran Phone/Fax: +1 978 264 2048 Cisco Systems VoIP: +1 408 571 4576 7 Ladyslipper Lane Email: oran@cisco.com Acton, MA 01720 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 12:47:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22622 for ; Mon, 3 Jun 2002 12:46:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09182 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 12:47:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05344; Mon, 3 Jun 2002 12:26:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05272 for ; Mon, 3 Jun 2002 12:26:05 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21992 for ; Mon, 3 Jun 2002 12:25:36 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g53GP8I29485; Mon, 3 Jun 2002 11:25:08 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 11:25:03 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870397@va02.va.neustar.com> From: "Peterson, Jon" To: "'David R. Oran'" , Jonathan Rosenberg Cc: "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Mon, 3 Jun 2002 11:25:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Well, I for one would be more than happy to deliver the hint with some other header. The problem is that we're a little short on time. We know from Keith that 3G and others require this hint on the same time frame as the short-term identity assertion mechanism. Given that: - Should the hint mechanism be specified in the same draft as the short-term identity assertion mechanism? (I for one would like to believe that you don't need the hint in order to have a trust-based network that manages identity, so I don't think identity needs to block on defining the hint. Still, building a new draft might take more time than we have.) - What do we call the new header? (I think it should be a P- header; I don't think we should change the name of the existing P-Asserted-Identity header if we can help it - maybe P-Suggested-Identity for the hint?) - Does the syntax of P-Asserted-Identity differ from that of P-Suggested-Identity in any interesting way? I think we need answers to these questions (and any others that may come up) by tomorrow - to satisfy the IESG, we need to have the short-term identity/privacy bundle resubmitted as complete drafts by this Thursday (6/6/02). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, June 03, 2002 9:02 AM > To: Jonathan Rosenberg; Peterson, Jon > Cc: 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > I find Jonathan's point quite persuasive. It might help with > clarity on > Juha's application of the header as well. In fact, if we have > a separate > header for the UA to insert, it might also encode user's desire about > whether he wants the service provider to reject the call if > it is unwilling > to use the UA-asserted identity. > > If we go the renaming route, could conveivably have: > p-ua-asserted-identity, and > p-proxy-asserted-identity. > > Dave. > > --On Friday, May 31, 2002 5:38 PM -0400 Jonathan Rosenberg > wrote: > > > I hate to throw a wrench in here, but since we do have an oppty for > > another rev of the doc during ietf LC, I would like to > voice an opinion. > > > > I don't believe that the hint should use the same header. > > > > My reasoning is simple. A header has a particular meaning. > That meaning > > should be invariant to where that header appears, request > or response, > > or any other conditions. We have been burned HARD by this > one with the > > Contact header, which really has two different meanings depending on > > context. It was only much later on we realized that we > needed both in > > the same request, but of course, its too late... > > > > P-Asserted-Identity should mean "this is the identity > asserted by the > > trust domain for the originator of this message". Period. > That is not at > > all the same thing as "this is the identity the end user > would like you > > to use, assuming its one of the allowed identities for this > user". In > > fact, there are vastly different trust implications for the two > > semantics. I can see right now a case where some misconfigured proxy > > forgets to strip the "hint" and all of a sudden it becomes > a fraudulent > > call, since the hint was the identity of a different user. > > > > It wouldn't shock me either if one day down the road we > find we do need > > both of these things in the same request. > > > > I don't care what you call it. But, its not P-Asserted-Identity. > > > > -Jonathan R. > > > > > > "Peterson, Jon" wrote: > >> > >> Since I've never been one to fly in the face of public > opinion (cough), > >> I'll agree (at least in this case) that we should go with > majority rule > >> and use the Asserted-Identity header for the 'hint'. > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> -----Original Message----- > >> From: Mark Watson [mailto:mwatson@nortelnetworks.com] > >> Sent: Thursday, May 23, 2002 9:18 AM > >> To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy'; > >> sip@ietf.org > >> Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > >> In the absence of further comment, can I make a *proposal* > that we stick > >> with Asserted-Identity for the hint and for the NAI > itself, and that > >> both are described in Cullen's draft ? > >> > >> Can we take this as AGREED if there are no comments by cob > tomorrow ? > >> (Guidance sought from chairs on this second question). > >> > >> Updated requirements draft to be submitted first thing tomorrow. > >> > >> Regards...Mark > >> > >> > -----Original Message----- > >> > From: Andrew Allen [ mailto:AAllen@dynamicsoft.com > >> ] > >> > Sent: 22 May 2002 15:51 > >> > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; > 'Peterson, Jon'; > >> > 'Rohan Mahy'; sip@ietf.org > >> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > > >> > > >> > > >> > I agree with Dave. Lets put the hint in the > >> > asserted-identity. Lets not have > >> > two redundant headers that need to be transferred over the > >> > Radio interface > >> > unnecessarily. > >> > > >> > Andrew > >> > > >> > > -----Original Message----- > >> > > From: David R. Oran [ mailto:oran@cisco.com > > >> ] > >> > > Sent: Wednesday, May 22, 2002 9:45 AM > >> > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > >> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > > > >> > > > >> > > I suggest we allow the hint to be placed in the > >> > > asserted-identity rather > >> > > than in another header. A boundary proxy has to deal with a > >> > UA putting > >> > > in the header no matter what, if only to reject the > request with an > >> > > error. > >> > > > >> > > Once we have a full solution the issue of hints should go > >> > > away as a side > >> > > effect of having the "authorization server" > functionality that Jon > >> > > proposes. Better IMHO to have one obsolescent header to deal > >> > > with rather > >> > > than two, as well as avoiding the concomitant verbiage > >> > describing the > >> > > combinatoric cases involving two headers. > >> > > > >> > > Dave. > >> > > > >> > > > -----Original Message----- > >> > > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org > >> ] On > >> > > > Behalf Of Mark Watson > >> > > > Sent: Wednesday, May 22, 2002 9:59 AM > >> > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org > >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > > > Importance: High > >> > > > > >> > > > > >> > > > All, > >> > > > > >> > > > Can we have a *decision* asap as to whether the 'hint' uses > >> > > > Asserted-Identity, or another header in another draft. > >> > > > > >> > > > I do not mind which. If the latter I will publish an I-D > >> > > > describing it as soon as we have a decision, assuming it is > >> > > > this week, since I'm away next week. > >> > > > > >> > > > If we do nothing, then I guess 3GPP will make up its own mind > >> > > > how to do this, without supervision or advice from IETF, > >> > > > which I think would be a bad thing. > >> > > > > >> > > > Regards...Mark > >> > > > > >> > > > > >> > > > -----Original Message----- > >> > > > From: Watson, Mark [MDN05:EP10:EXCH] > >> > > > Sent: 20 May 2002 12:08 > >> > > > To: 'Peterson, Jon'; 'Rohan Mahy' > >> > > > Cc: sip@ietf.org > >> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > > > > >> > > > > >> > > > The 'hint' was one of the three requirements that 3GPP > >> > > > communicated to us in April. > >> > > > It is a separate requirement from the Network Asserted > >> > > > Identity itself, and so is not addressed in the requirements > >> > > > draft, although I have been careful to point this out, and to > >> > > > point out that it is a requirement nontheless, on several > >> > > > occasions. I believe we need the 'hint' in the same timeframe > >> > > > as the rest of the short term work. > >> > > > Whether it is the same header/draft or a different > >> > > > header/draft is another question on which I will only say > >> > > > that we'd better make up our minds pretty quick. ...Mark > >> > > > > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz > >> ] > >> > > > > Sent: 19 May 2002 18:11 > >> > > > > To: 'Rohan Mahy' > >> > > > > Cc: sip@ietf.org > >> > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > >> > > > > > >> > > > > > >> > > > > > >> > > > > My argument was not that the proposed hint won't > work - just > >> > > > > that it isn't > >> > > > > necessary to solve the problem at hand. It might not be the > >> > > > > case that the > >> > > > > problems with the hint stop at the philosophical point you > >> > > > > mention below. > >> > > > > What I asked in my last mail was not whether or > not we needed > >> > > > > a hint, but > >> > > > > rather whether or not we should table that > question until we > >> > > > > resolve the > >> > > > > other questions at hand. I just don't want to spend the > >> > > > > cycles arguing about > >> > > > > the hint given our very aggressive timetable - frankly, I > >> > > > think that > >> > > > > reaching consensus on this hint matter might push back our > >> > > > > dates a bit. > >> > > > > Let's investigate this hint stuff in June, but for now just > >> > > > > figure out how a > >> > > > > Trust Domain can manage an asserted identity in a message. > >> > > > > > >> > > > > Jon Peterson > >> > > > > NeuStar, Inc. > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: Rohan Mahy [ mailto:rohan@cisco.com > >> ] > >> > > > > > Sent: Sunday, May 19, 2002 8:29 AM > >> > > > > > To: Peterson, Jon > >> > > > > > Cc: sip@ietf.org > >> > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > >> > > > > > > >> > > > > > > >> > > > > > Hi, > >> > > > > > > >> > > > > > The requirement for a hint is well understood, limited in > >> > > > > > scope, and well motivated in the draft. Nobody has > >> > identified > >> > > > > > any technical reason why the hint won't work. > Your argument > >> > > > > > that allowing a hint weakens the strength of the > language on > >> > > > > > ignoring Asserted-Identity from untrusted > parties is purely > >> > > > > > philosophical in nature. I don't buy your argument. > >> > > > > > > >> > > > > > thanks, > >> > > > > > -rohan > >> > > > > > > >> > > > > > > >> > > > > > ---- Original message ---- > >> > > > > > > Date: Fri, 17 May 2002 16:02:11 -0500 > >> > > > > > > From: "Peterson, Jon" > >> > > > > > > Subject: [Sip] Asserted-Identity: How to 'hint'? > >> > > > > > > To: "'sip@ietf.org'" > >> > > > > > > > >> > > > > > > > >> > > > > > > In the course of the discussion between Mark > Watson, Cullen > >> > > > > > Jennings and > >> > > > > > > myself about the short-term identity work, we > have returned a > >> > >> > > > > > few times to > >> > > > > > > the question of the infamous hint. This hint > is, of course, a > >> > >> > > > > > way that a > >> > > > > > > user agent (one that is not a member of the > Trust Domain in > >> > > > > > the short-term > >> > > > > > > network asserted identity space) can provide a > 'hint' to the > >> > > > > > intermediary > >> > > > > > > that will generate an Asserted-Identity > indicating which > >> > > > > > identity among > >> > > > > > > several possibilities should be asserted. > >> > > > > > > > >> > > > > > > The need for this arises particularly from the > 3G space, in > >> > > > > > which the > >> > > > > > > authentication process takes place > independently of SIP and > >> > > > > > does not carry > >> > > > > > > this sort of personal identity information. It > also assumes > >> > > > > > that the > >> > > > > > > operators of the intermediary in question are aware of > >> > > > > > several legitimate > >> > > > > > > identities which the user can elect to assert. > >> > > > > > > > >> > > > > > > It has been proposed on the mailing list and > >> > elsewhere that the > >> > > > > > > Asserted-Identity header should be re-used by > user agents > >> > > > > > outside the Trust > >> > > > > > > Domain to provide such a hint. I see a number > of reasons for > >> > > > > > and against > >> > > > > > > using the Asserted-Identity for this purpose. > For example, > >> > > > > > today, there is a > >> > > > > > > requirement that asserted-identities which are > transmitted > >> > > > > > from untrusted > >> > > > > > > sources should not be used in any way - this > would seem to > >> > > > > > weaken that > >> > > > > > > requirement. There is also possibly some > behavior that still > >> > > > > > needs to be > >> > > > > > > specified (like how an intermediary would > reject or otherwise > >> > >> > > > > > handle a > >> > > > > > > request with an inappropriate hint) that might > be impactful > >> > > > > > to our choice. > >> > > > > > > > >> > > > > > > For the time being, however, I would like to > suggest that > >> > > > > > providing the hint > >> > > > > > > is outside the scope of the current deliverables (the > >> > > > > > asserted-identity > >> > > > > > > requirements and mechanism drafts), which need to be > >> > > > > > complete, as we > >> > > > > > > discussed in the interim meeting, by the end > of this month. I > >> > >> > > > > > believe that a > >> > > > > > > separate draft should propose the use of > Asserted-Identity or > >> > >> > > > > > any other > >> > > > > > > header for this hint (in whatever timeframe is > appropriate > >> > > > > > for 3G's > >> > > > > > > requirements), but that we should not speak to > this matter in > >> > >> > > > > > the current > >> > > > > > > asserted-identity deliverables. There is, as I > see it, no > >> > > > > > dependency on > >> > > > > > > defining this hint before we dictate how > intermediaries will > >> > > > > > assert > >> > > > > > > identities. > >> > > > > > > > >> > > > > > > Any comments on this plan? > >> > > > > > > > >> > > > > > > Jon Peterson > >> > > > > > > NeuStar, Inc. > >> > > > > > > > >> > > > > > > _______________________________________________ > >> > > > > > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > >> > >> > > > > > > This list is for NEW development of the core > SIP 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 > >> > > > >> > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > ----------------------------------------------------------- > David R. Oran Phone/Fax: +1 978 264 2048 > Cisco Systems VoIP: +1 408 571 4576 > 7 Ladyslipper Lane Email: oran@cisco.com > Acton, MA 01720 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 14:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27382 for ; Mon, 3 Jun 2002 14:50:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23369 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 14:50:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22534; Mon, 3 Jun 2002 14:30:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22504 for ; Mon, 3 Jun 2002 14:30:44 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26546 for ; Mon, 3 Jun 2002 14:30:14 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.165]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g53IVjYH002622; Mon, 3 Jun 2002 14:31:45 -0400 (EDT) Message-ID: <3CFBB5AE.85CCE3BD@dynamicsoft.com> Date: Mon, 03 Jun 2002 14:30:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <70565611B164D511957A001083FCDD5601870397@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > Well, I for one would be more than happy to deliver the hint with some > other > header. The problem is that we're a little short on time. We know from > Keith > that 3G and others require this hint on the same time frame as the > short-term identity assertion mechanism. Given that: > > - Should the hint mechanism be specified in the same draft as the > short-term > identity assertion mechanism? (I for one would like to believe that you > don't need the hint in order to have a trust-based network that manages > identity, so I don't think identity needs to block on defining the hint. > Still, building a new draft might take more time than we have.) I see no reason for a separate draft. Its just an optional feature of the asserted identity mechanism. > > - What do we call the new header? (I think it should be a P- header; I > don't > think we should change the name of the existing P-Asserted-Identity > header > if we can help it - maybe P-Suggested-Identity for the hint?) Fine. > > - Does the syntax of P-Asserted-Identity differ from that of > P-Suggested-Identity in any interesting way? I like Dave's idea of adding a param which indicates whether to reject or ignore if the suggested identity cannot be asserted. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 14:59:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27600 for ; Mon, 3 Jun 2002 14:59:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23646 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 15:00:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23181; Mon, 3 Jun 2002 14:43:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23154 for ; Mon, 3 Jun 2002 14:43:52 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27085 for ; Mon, 3 Jun 2002 14:43:22 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17Ewny-00006X-00; Mon, 03 Jun 2002 21:43:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15611.58179.297690.483415@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 00:44:35 +0300 To: "Peterson, Jon" Cc: "'David R. Oran'" , Jonathan Rosenberg , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <70565611B164D511957A001083FCDD5601870397@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD5601870397@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > - What do we call the new header? (I think it should be a P- header; I don't > think we should change the name of the existing P-Asserted-Identity header > if we can help it - maybe P-Suggested-Identity for the hint?) since the hint is needed for the general case where from is anonymous and since there is no other standardized sip mechanism for that purpose, i'm strongly against defining a p-header for it. it must be a normal, standards track header with possibly a new error code to tell the UA that the proxy didn't like the identity the ua was claiming. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 3 17:38:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02064 for ; Mon, 3 Jun 2002 17:38:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02735 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 17:38:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00431; Mon, 3 Jun 2002 17:03:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19947 for ; Mon, 3 Jun 2002 13:45:47 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25240 for ; Mon, 3 Jun 2002 13:45:13 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g53Hjel01638 for ; Mon, 3 Jun 2002 13:45:41 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 12:45:40 -0500 Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02C7AC4B@il0015exch004u.ih.lucent.com> From: "Henrikson, Eric H (Eric)" To: Dean Willis , sip@ietf.org Cc: rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Date: Mon, 3 Jun 2002 12:45:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: Poll: expert review of draft-henrikson-sip-charging-informati on Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All, Revision 4 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 4 contains the following changes: - addition of 'm' to table 2 under section 4.3 to indicate proxy may modify P-Charging-Vector, which makes the table consistent with the description in the text - updated reference 13 to the latest version - additional details added to section 7, IANA Considerations The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 4 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Henrikson, Eric H (Eric) Sent: Thursday, May 30, 2002 2:55 PM To: 'Dean Willis'; sip@ietf.org Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com Subject: RE: Poll: expert review of draft-henrikson-sip-charging-information All, Revision 3 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 3 contains the following changes: - additions to Applicability Statement for when the new charging headers don't apply - clarifications to the Security Considerations - fixing the examples to show IP addresses for the charging function addresses - additional sections for acknowledgements and the full copyright statement The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 3 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, May 24, 2002 12:28 PM To: sip@ietf.org Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; ehenrikson@lucent.com Subject: Poll: expert review of draft-henrikson-sip-charging-information You may recall that we're doing an Expert Review of draft-henrikson-sip-charging-information. If you have a strong opinion for, against, or supporting a need for further work, or any further suggestions for enhancement, please post them now. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 3 18:59:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03658 for ; Mon, 3 Jun 2002 18:59:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06803 for sip-archive@odin.ietf.org; Mon, 3 Jun 2002 19:00:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06029; Mon, 3 Jun 2002 18:44:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05973 for ; Mon, 3 Jun 2002 18:44:19 -0400 (EDT) Received: from lmg04.affinity.com (lmg.affinity.com [207.150.192.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03300; Mon, 3 Jun 2002 18:43:48 -0400 (EDT) Received: from homepc2 ([66.82.99.227]) by lmg.ahnet.net with SMTP id <288653-17489>; Mon, 3 Jun 2002 15:43:25 -0700 From: "Fred Robinson" To: , Date: Mon, 3 Jun 2002 16:44:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_002B_01C20B1D.F8A7F870" 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.2600.0000 Subject: [Sip] AIN Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C20B1D.F8A7F870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002C_01C20B1D.F8A7F870" ------=_NextPart_001_002C_01C20B1D.F8A7F870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm currently working on a VoIP integration project that requires interfacing with the ILEC's Advanced Intelligent Network (AIN). Reading through the client's requirements I came across a requirement that states; the SIP proxy must support all RFC 2543 extensions for AIN. I'm not aware of this section in 2543 or bis-09, is it possible they are referring to a draft? Is there a SIP or SIPPING draft specific to AIN extensions to SIP? Fred Robinson Operator, SIPFusion 558 Copperdale Ln. Golden, CO 80403 fred.robinson@sipfusion.com office: 303.642.8061 mobile: 720.272.5201 ------=_NextPart_001_002C_01C20B1D.F8A7F870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm = currently=20 working on a VoIP integration project that requires interfacing with the = ILEC's=20 Advanced Intelligent Network (AIN).  Reading through the client's=20 requirements I came across a requirement that states; the SIP proxy must = support=20 all RFC 2543 extensions for AIN.  I'm not aware of this section in = 2543 or=20 bis-09, is it possible they are referring to a draft?  Is there a = SIP or=20 SIPPING draft specific to AIN extensions to SIP?

Fred Robinson
Operator,=20 SIPFusion
 
558 Copperdale Ln.
Golden, CO=20 80403
fred.robinson@sipfusion.com
office: 303.642.8061
mobile:=20 720.272.5201

 
------=_NextPart_001_002C_01C20B1D.F8A7F870-- ------=_NextPart_000_002B_01C20B1D.F8A7F870 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <378113122@03062002-11ae> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAeAJMDASIAAhEBAxEB/8QAGwAAAwEAAwEAAAAAAAAAAAAA BAUGAAIDBwH/xABGEAABAwMCAgUHBwYPAAAAAAABAgMEAAURBhIHIRMUMUFRIjJVcZSxwWF0dYGR odM1NjdzstIIFRcYIzRCUlZiY5Oz4fD/xAAaAQEAAgMBAAAAAAAAAAAAAAAAAgYBBAUD/8QAKhEA AgIBAgQDCQAAAAAAAAAAAQIAAxEEIRIxQWETUcEFIjM0cYGx0fD/3QAEACj/2gAMAwEAAhEDEQA/ AB7lcmLXEMiRuIyEpSkZUpR7AKDjXee9IbQ5ZX2WnDjpCsHaPEiuV/tz9wisqiqSJEZ5LzYV2KI7 q64OoEOyUwp8dyDLVyCXPNWf8p76szORZgnA6d5Qq61NPEq8R3zvy+3rvDrhLdhshxmG7KUVY2N4 yPl50BatQrurwS3bX22txSp1RBSkjupzSHR35Ie+cufCpOW8VQDsfSRrFZodiu4xvv1zDbvdxahH HVnJC5C9iEoIBzQ7OpG+ttxp0KRCW8cNqdA2qPhmhtVvJjybS8sKKW5W4hIyT6hXRcpS9SKjQ4UO QlKXkuOPutlKUAevvrxstYOwB3GMDzm1Tp62qRmXY5yc8vSew6COIMs/6g91LLdxNm3eL1u3aNuk qOVFIcbWggkHBploLlb5n6we6ozhtrJVl0iiENN32ftfdV00KGXGzlXYFZ7a4+s+O0svsz5RP7rP T7Hc5N2twlSrZItrm8p6CQQVYHfy8aY1Iar1FMTw0m3yC1LtkkNBSESGtjrR3gc0nOOXvptKmSEa McmpdIkCAXQ537tmc/bWrOhHNapfTV4nv8Not4f3TJvUlPHI5uKGfD1VNaXRcdY2xu5O6+ktTncl USGW0JjnPmlHafrpEvb6q4IsM9VqAVPEdZjg/wB/Bx99QWhpevFqmdJHckMAJwbwtTKgvnu2YQSR 2fJ4Va3O0XKbaI8SLfpEKS0U9JKbbQVO4GDkEYGTz5Ui4ez7rIl6hg3S5O3A26eWGnXEpSdoHgBW MSJG4MbdY1j6Ms3tzv4VbrGsfRlm9ud/Cqchv33Xt2uTsS9v2ezQJCorQipHSPrT5yio93MUZpq7 Xi16ukaRvsz+MD1frUKapASpxGcFKgO8fCsyUb9Y1j6Ms3tzv4VbrGsfRlm9ud/CqXtj+qtSam1H bWr6qDb4c0oDiG0qeAxyQjIwB3k9tH6Qm3eBrG76XudzcubUZluRHkPAdIEq7Ukjt7fupEaW7VL8 mJvkw223kOuNOJbcKkgoWpBwSBkeT4Vql2LgzHXLaWrCkzZP/Ms1qRJ+dcItuaS7LdDTalBAUQTz /wDCkF9nQ7yI0K3LEmT0yVBbYyGwO0k91BL1+w4na5bN6T3KWCPdXFrXUVjPQ2hLee3YoD3Cu/Zq a393i2+hzKfRob6iH8M8Q7jErpk+LbmUuzHw0gnaFEHmfqqf0dc4XVVQunT1hx9akowckdufuoNe v2XBhds3DwKwfhXxOu4yFbk2kJI7woD4UbU1mwMG2HYwmhvWlkNZye46cvzG+pPyhZfnY+FPqjFa /ZUQVWwkg5GXBy+6vv8AKE36OV/uf9VJdTQGZuLn2M830GqZFXg5Z6jzz5z2nQf9QmfrB7qB4N/o /Z+cvftVA6f4ys2Rh5pVmW90igrIfAxy9VNG+PkRlGxrTam09u1L4A/Zrjapw9zMvKWfQVtVpkRx uP3L7iRFemcPrwzHbLjnQbglIySEqBP3A0ik6+sMjQXVoUkzJr0AtiIwkqcSdmDuH9kDvJ8KQn+E BHIwdPOe0D92hmeN9pjKWpjSLbSnPPKFoSVevCeda83Z6Dw+ebj8NbS+6ra23E3rV4AZJNS+pV8M LlAeuLE+IzcCkqZdgLKHyvHLyU8yc+Ipanj7EQ2G0acUlAGAkPgDHq20KjjTZG3+nRo1hDvb0iVI Cvt20ieoaHcujujLYu9b+vqZ/pek848ztz8u3GaScPvzg1l9Lq9xqW/nAsf4fc9oH7tcUcfIjZUU abUkrOVFL4G4+J8mkR1pK8wdD3C76d1A+mBumuSoj73koeaXjsV2ZGKIscpOruJzmoICVKtNthGM 1JKSA+4o89ue4An7PlqYlccrZOSES9KIkJHYHXErA+1NdjXHuGw2G2dNltCexKHwAPqCaRKzQP50 az+k/hWtn6aL19GM+8VKI4+RG1KUjTaklZyoh8Dcfl8msOPkQOl0abUHCMFXTjJHr20iItQXAxtR 3NoKI2zHuWfFZNao2+agN3vky4oaLKZLynA2VZ25PZmtSJ//2Q== ------=_NextPart_000_002B_01C20B1D.F8A7F870-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 01:14:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10324 for ; Tue, 4 Jun 2002 01:14:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA03517 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 01:15:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24597; Tue, 4 Jun 2002 00:56:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24567 for ; Tue, 4 Jun 2002 00:56:22 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10192 for ; Tue, 4 Jun 2002 00:55:52 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g544uJ6n000255 for ; Tue, 4 Jun 2002 06:56:19 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g544uJa9010102 for ; Tue, 4 Jun 2002 07:56:19 +0300 (EET DST) Message-ID: <3CFC4874.60C0305F@lmf.ericsson.se> Date: Tue, 04 Jun 2002 07:56:20 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIPit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I read on the pulver.com site that they will host the 11th SIPit in OCTOBER. I would just like to clarify that this means there will be no SIPit in august. Or, is someone else going to host a SIPit in august? And, if the event is held in october, when will the following event after that be held? December is only two months later, so... I appologise if this is not the correct list for this mail, but I never got any reply from SIPForum, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 04:15:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21129 for ; Tue, 4 Jun 2002 04:15:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12400 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 04:16:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11410; Tue, 4 Jun 2002 04:02:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11379 for ; Tue, 4 Jun 2002 04:02:08 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20888 for ; Tue, 4 Jun 2002 04:01:38 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5481Jc07998; Tue, 4 Jun 2002 04:01:19 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 03:01:08 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703A0@va02.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Tue, 4 Jun 2002 03:01:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So, I take it from the silence on this list today about this matter that there is consensus to create a P-Suggested-Identity header in the existing short-term identity draft that admits of a criticality parameter as Jonathan descibes it below? This would be a good time to speak up if you feel otherwise. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, June 03, 2002 11:30 AM > To: Peterson, Jon > Cc: 'David R. Oran'; 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; > sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > > > "Peterson, Jon" wrote: > > > > Well, I for one would be more than happy to deliver the > hint with some > > other > > header. The problem is that we're a little short on time. > We know from > > Keith > > that 3G and others require this hint on the same time frame as the > > short-term identity assertion mechanism. Given that: > > > > - Should the hint mechanism be specified in the same draft as the > > short-term > > identity assertion mechanism? (I for one would like to > believe that you > > don't need the hint in order to have a trust-based network > that manages > > identity, so I don't think identity needs to block on > defining the hint. > > Still, building a new draft might take more time than we have.) > > I see no reason for a separate draft. Its just an optional feature of > the asserted identity mechanism. > > > > > - What do we call the new header? (I think it should be a > P- header; I > > don't > > think we should change the name of the existing P-Asserted-Identity > > header > > if we can help it - maybe P-Suggested-Identity for the hint?) > > Fine. > > > > > - Does the syntax of P-Asserted-Identity differ from that of > > P-Suggested-Identity in any interesting way? > > I like Dave's idea of adding a param which indicates whether to reject > or ignore if the suggested identity cannot be asserted. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 04:19:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21183 for ; Tue, 4 Jun 2002 04:19:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12587 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 04:20:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11144; Tue, 4 Jun 2002 04:00:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11098 for ; Tue, 4 Jun 2002 04:00:44 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20844 for ; Tue, 4 Jun 2002 04:00:14 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g547xNI25878; Tue, 4 Jun 2002 02:59:24 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 02:59:19 -0500 Message-ID: <70565611B164D511957A001083FCDD560187039F@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: "'David R. Oran'" , Jonathan Rosenberg , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Tue, 4 Jun 2002 02:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have not been persuaded by the argument that the 'hint' has applicability outside of the short-term asserted identity mechanism. Agreed that the hint only seems to be necessary because a user could potentially select an anonymous From field, but with whom would a user share such a suggested identity when they are anonymous, and why would they share it? Even when the From field is anonymous, the hint is only necessary when the normal authentication process in SIP (which provides a secure way for a user to share their identity with a specific intermediary) does not allow the user to express a usable identity to the network. I think the normal SIP authentication method constitutes a standard way of expressing an identity to the network when the From field is anonymous - if a user has multiple identities, they can express any one of several identities in the username portion of an Authorization header. Thus, I don't see this as any particular reason why the 'hint', with it's more modest applicability, cannot be represented by a P- header. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, June 03, 2002 2:45 PM > To: Peterson, Jon > Cc: 'David R. Oran'; Jonathan Rosenberg; 'Mark Watson'; > 'Andrew Allen'; > 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > Peterson, Jon writes: > > > - What do we call the new header? (I think it should be a > P- header; I don't > > think we should change the name of the existing > P-Asserted-Identity header > > if we can help it - maybe P-Suggested-Identity for the hint?) > > since the hint is needed for the general case where from is anonymous > and since there is no other standardized sip mechanism for > that purpose, > i'm strongly against defining a p-header for it. it must be a normal, > standards track header with possibly a new error code to tell the UA > that the proxy didn't like the identity the ua was claiming. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 04:27:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21266 for ; Tue, 4 Jun 2002 04:27:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12878 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 04:28:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12272; Tue, 4 Jun 2002 04:10:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12239 for ; Tue, 4 Jun 2002 04:10:30 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21061 for ; Tue, 4 Jun 2002 04:09:59 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17F9Oc-0000Iv-00; Tue, 04 Jun 2002 11:10:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15612.30194.423683.556495@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 11:10:26 +0300 To: "Peterson, Jon" Cc: "'David R. Oran'" , Jonathan Rosenberg , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <70565611B164D511957A001083FCDD560187039F@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD560187039F@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > I have not been persuaded by the argument that the 'hint' has applicability > outside of the short-term asserted identity mechanism. Agreed that the hint > only seems to be necessary because a user could potentially select an > anonymous From field, but with whom would a user share such a suggested > identity when they are anonymous, and why would they share it? this has been discussed many times before: when the call is routed to pstn, the calling party number is still carried in the isup message even if the caller wants to remain anonymous to the called party. > Even when the From field is anonymous, the hint is only necessary when the > normal authentication process in SIP (which provides a secure way for a user > to share their identity with a specific intermediary) does not allow the > user to express a usable identity to the network. I think the normal SIP > authentication method constitutes a standard way of expressing an identity > to the network when the From field is anonymous - if a user has multiple > identities, they can express any one of several identities in the username > portion of an Authorization header. are you suggesting that if my customer has a phone number in each of the 15 area codes in finland, he/she should have 15 different sip usernames/passwords? if i would propose such a thing to my customer, he/she would think i must be joking. > Thus, I don't see this as any particular reason why the 'hint', with it's > more modest applicability, cannot be represented by a P- header. there is real demonstrated need to include "Really From" style header in basic sip. ietf must do its job properly and, in order to do so, must not be constrained by 3gpp or any other external deadlines. if that is not acceptable to 3gpp, then i suggest that you go invent your own 3GPP-headers and be done with it. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 04:53:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21528 for ; Tue, 4 Jun 2002 04:53:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14181 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 04:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12941; Tue, 4 Jun 2002 04:29:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12910 for ; Tue, 4 Jun 2002 04:29:38 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21342 for ; Tue, 4 Jun 2002 04:29:07 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17F9h9-0000JP-00; Tue, 04 Jun 2002 11:29:35 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15612.31343.163449.656540@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 11:29:35 +0300 To: "Peterson, Jon" Cc: "'Jonathan Rosenberg'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <70565611B164D511957A001083FCDD56018703A0@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703A0@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > So, I take it from the silence on this list today about this matter that > there is consensus to create a P-Suggested-Identity header in the existing > short-term identity draft that admits of a criticality parameter as Jonathan > descibes it below? haven't you been listening? i'm STRONGLY opposed a P-header for this purpose. there are many reasons for it: 1) there is a general need to include such capability in sip. 2) we may need a new error code to indicate that the request was rejected due to "wrong" requested identity and p-headers are informational only. 3) i would have hard time to convince non-3gpp UA, proxy, and SIP/ISUP gw vendors to implement anything starting with P. this rush seems again be caused solely by 3gpp reasons, which in totally unacceptable for the "rest of us" (if any besides me are still left). i would like to hear a comment from the ADs on this. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 06:12:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22250 for ; Tue, 4 Jun 2002 06:12:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17643 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 06:12:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16700; Tue, 4 Jun 2002 05:53:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16590 for ; Tue, 4 Jun 2002 05:52:59 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22072 for ; Tue, 4 Jun 2002 05:52:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g549qn6n008614; Tue, 4 Jun 2002 11:52:49 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g549qla9028990; Tue, 4 Jun 2002 12:52:48 +0300 (EET DST) Message-ID: <3CFC8DEF.9C1F7DC1@ericsson.com> Date: Tue, 04 Jun 2002 12:52:47 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'jh@lohi.eng.song.fi'" , "'David R. Oran'" , Jonathan Rosenberg , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <70565611B164D511957A001083FCDD560187039F@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > [snip] > Even when the From field is anonymous, the hint is only necessary when the > normal authentication process in SIP (which provides a secure way for a user > to share their identity with a specific intermediary) does not allow the > user to express a usable identity to the network. I think the normal SIP > authentication method constitutes a standard way of expressing an identity > to the network when the From field is anonymous - if a user has multiple > identities, they can express any one of several identities in the username > portion of an Authorization header. I don't agree with this usage of the username part of the Authorization header. The username part indicates the username who is authenticating, as opposed to the hint of the identity. You may also consider that the authorization data is typically locally stored data, as opposed to the asserted identity, that can cross domains is transitive trust exists between networks. Therefore, the username part of the Authorization header does not offer, in the general case, a hint for the asserted identity. Jonathan already commented about the problems of overloading the semantics of one header with other semantics, and I consider the same hack to the username part of the Authorization header. Let's move forward and go for a new header for the hint. /Miguel > > Thus, I don't see this as any particular reason why the 'hint', with it's > more modest applicability, cannot be represented by a P- header. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: Monday, June 03, 2002 2:45 PM > > To: Peterson, Jon > > Cc: 'David R. Oran'; Jonathan Rosenberg; 'Mark Watson'; > > 'Andrew Allen'; > > 'Rohan Mahy'; sip@ietf.org > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > > > > Peterson, Jon writes: > > > > > - What do we call the new header? (I think it should be a > > P- header; I don't > > > think we should change the name of the existing > > P-Asserted-Identity header > > > if we can help it - maybe P-Suggested-Identity for the hint?) > > > > since the hint is needed for the general case where from is anonymous > > and since there is no other standardized sip mechanism for > > that purpose, > > i'm strongly against defining a p-header for it. it must be a normal, > > standards track header with possibly a new error code to tell the UA > > that the proxy didn't like the identity the ua was claiming. > > > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 07:57:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24212 for ; Tue, 4 Jun 2002 07:57:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22462 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 07:57:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21449; Tue, 4 Jun 2002 07:44:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21394 for ; Tue, 4 Jun 2002 07:44:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23470; Tue, 4 Jun 2002 07:43:53 -0400 (EDT) Message-Id: <200206041143.HAA23470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Jun 2002 07:43:53 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol (SIP) extension for Visited Network Identifier Author(s) : M. Garcia Filename : draft-garcia-sip-visited-network-id-03.txt Pages : 7 Date : 03-Jun-02 This memo describes a private extension to SIP in the form of a P-Visited-Network-ID header. The contents of the header identify each of the visited networks the message traversed en-route to the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-visited-network-id-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-garcia-sip-visited-network-id-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-garcia-sip-visited-network-id-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: <20020603130006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-visited-network-id-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-visited-network-id-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603130006.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 07:58:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24293 for ; Tue, 4 Jun 2002 07:58:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22538 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 07:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21388; Tue, 4 Jun 2002 07:44:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21360 for ; Tue, 4 Jun 2002 07:44:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23450; Tue, 4 Jun 2002 07:43:47 -0400 (EDT) Message-Id: <200206041143.HAA23450@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Jun 2002 07:43:47 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol ((SIP) extension for Called Party Identity Author(s) : M. Garcia Filename : draft-garcia-sip-called-party-id-03.txt Pages : 8 Date : 03-Jun-02 This memo describes a private extension to SIP in the form of a P-Called-Party-ID header. A proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-called-party-id-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-garcia-sip-called-party-id-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-garcia-sip-called-party-id-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: <20020603125954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-called-party-id-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-called-party-id-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603125954.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 07:59:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24325 for ; Tue, 4 Jun 2002 07:59:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22572 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 07:59:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21488; Tue, 4 Jun 2002 07:44:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21439 for ; Tue, 4 Jun 2002 07:44:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23490; Tue, 4 Jun 2002 07:43:58 -0400 (EDT) Message-Id: <200206041143.HAA23490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Jun 2002 07:43:57 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol (SIP)extension for Associated Uniform Resource Identifiers (URI) Author(s) : M. Garcia Filename : draft-garcia-sip-associated-uri-03.txt Pages : 7 Date : 03-Jun-02 This memo describes a private extension to SIP [1] that allows a registrar to return a set of associated URIs to a registered address- of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request. The P-Associated-URI header field transports the set of Associated URIs to the registered address- of-record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-associated-uri-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-garcia-sip-associated-uri-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-garcia-sip-associated-uri-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: <20020603130017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-associated-uri-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-associated-uri-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603130017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 09:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28935 for ; Tue, 4 Jun 2002 09:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29563 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 09:59:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28450; Tue, 4 Jun 2002 09:33:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28419 for ; Tue, 4 Jun 2002 09:33:29 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28019 for ; Tue, 4 Jun 2002 09:32:58 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g54Db3V13832; Tue, 4 Jun 2002 08:37:08 -0500 Subject: Re: [Sip] SIPit From: Robert Sparks To: Christer Holmberg Cc: sip@ietf.org In-Reply-To: <3CFC4874.60C0305F@lmf.ericsson.se> References: <3CFC4874.60C0305F@lmf.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jun 2002 08:32:40 -0500 Message-Id: <1023197566.1332.30.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Pulver beat me to the punch on getting announcements out and web pages updated. Yes, that is a move of SIPIT 11 to October in Atlanta at the same time as VON. We'll be leveraging the facilities Pulver has available for that event. (The events will be separate and secured - the SIPIT will not turn into an exhibit). The subsequent events will rescheduled accordingly - we are also going to spread them further apart for a couple of events. SIPIT 12 will most likely be at the end of February and SIPIT 13 in August 2003. The sponsors haven't changed. Watch the sipit page on www.sipforum.org for updates. RjS On Mon, 2002-06-03 at 23:56, Christer Holmberg wrote: > > Hi, > > I read on the pulver.com site that they will host the 11th SIPit in > OCTOBER. I would just like to clarify that this means there will be no > SIPit in august. Or, is someone else going to host a SIPit in august? > > And, if the event is held in october, when will the following event > after that be held? December is only two months later, so... > > I appologise if this is not the correct list for this mail, but I never > got any reply from SIPForum, so... > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 10:09:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29411 for ; Tue, 4 Jun 2002 10:09:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00487 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 10:09:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28813; Tue, 4 Jun 2002 09:44:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28782 for ; Tue, 4 Jun 2002 09:44:19 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28401 for ; Tue, 4 Jun 2002 09:43:36 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 4 Jun 2002 08:43:27 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A6F@NREXCH.netrake.net> Thread-Topic: Comments on draft-ietf-sip-sec-agree-02.txt Thread-Index: AcILzc4IssI3tvHsTvqDMqKeS+Mbaw== From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA28783 Subject: [Sip] Comments on draft-ietf-sip-sec-agree-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit In section 3.3 "Syntax": 1. The SIP specification already has a rule named "algorithm": see section 25.1 "Basic Rules" in bis-09. To avoid conflict, I would propose changing the name for this rule. 2. While there is no rule called "extension" in the SIP spec, I would suggest changing the name of this rule as well to be consistent with other rules that use "extension" in the name. Here's what I would like to see: mech-parameters = ( mech-preference / mech-algorithm / mech-extension ) mech-preference = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) mech-algorithm = "alg" EQUAL token mech-extension = generic-param - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 10:31:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00510 for ; Tue, 4 Jun 2002 10:31:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02113 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 10:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01184; Tue, 4 Jun 2002 10:21:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01154 for ; Tue, 4 Jun 2002 10:21:17 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29948 for ; Tue, 4 Jun 2002 10:20:44 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 12F326A906; Tue, 4 Jun 2002 17:21:09 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B9C476A904; Tue, 4 Jun 2002 17:21:06 +0300 (EEST) Message-ID: <3CFCCD1B.5080803@piuha.net> Date: Tue, 04 Jun 2002 17:22:19 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Rob Phillips Cc: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-sec-agree-02.txt References: <7E06D3212981524CA10D2A114937C414093A6F@NREXCH.netrake.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rob Phillips wrote: > In section 3.3 "Syntax": > > 1. The SIP specification already has a rule named "algorithm": see section 25.1 "Basic Rules" in bis-09. To avoid conflict, I would propose changing the name for this rule. > > 2. While there is no rule called "extension" in the SIP spec, I would suggest changing the name of this rule as well to be consistent with other rules that use "extension" in the name. I agree. Thanks for observing this. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 12:33:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05069 for ; Tue, 4 Jun 2002 12:33:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09359 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 12:34:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06422; Tue, 4 Jun 2002 11:58:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06391 for ; Tue, 4 Jun 2002 11:58:13 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03643 for ; Tue, 4 Jun 2002 11:57:45 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g54FxEYH003589; Tue, 4 Jun 2002 11:59:14 -0400 (EDT) Message-ID: <3CFCE36F.9E50F411@dynamicsoft.com> Date: Tue, 04 Jun 2002 11:57:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Peterson, Jon" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <15612.31343.163449.656540@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. jh@lohi.eng.song.fi wrote: > > Peterson, Jon writes: > > > So, I take it from the silence on this list today about this matter > that > > there is consensus to create a P-Suggested-Identity header in the > existing > > short-term identity draft that admits of a criticality parameter as > Jonathan > > descibes it below? > > haven't you been listening? i'm STRONGLY opposed a P-header for this > purpose. there are many reasons for it: > > 1) there is a general need to include such capability in sip. > > 2) we may need a new error code to indicate that the request was > rejected due to "wrong" requested identity and p-headers are > informational only. > > 3) i would have hard time to convince non-3gpp UA, proxy, and SIP/ISUP > gw vendors to implement anything starting with P. I haven't really made up my mind yet on whether this suggested identity is a P-header or not; so please don't construe the following as an argument in favor - I am just trying to tease the problem apart a bit. I think the decision point about the hint is based on whether the hint is ever useful without the P-Asserted-Identity. If it is useful without that extension, then it probably does qualify as a regular header. If it is not useful without that extension, then it is probably a P-header. Personally, I don't see how one would use the hint without a network asserted identity. In the application you are interested in, you are delivering one of several phone numbers to a PSTN gateway, even when the user is anonymous. The gateway needs to only pass an authenticated identity, in which case it can't pass the user's hint, it has to pass the P-Asserted-Identity. Thus, your application would seem to require the P-Asserted-Identity header. However, I can imagine that the hint might be useful for the long term identity work too. When a request is sent to an authentication service, the authentication service needs to know what identity to assert, in the same way the proxy needs to know what identity to assert in the short term case. So, here is a case where the suggested identity is useful for an application outside of the P-header. I must admit, though, in the general SIP usage that I am unconvinced that one really needs to have such a large number of identities that it is not reasonable to have a different set of credentials for each of them. In many cases the credentials are configured in some reasonable way, so that the user won't necessarily need to manually enter them (for example, burn in at a store for a wireless phone) I am curious whether you are really handing out 15 phone numbers to a single user... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 14:37:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10073 for ; Tue, 4 Jun 2002 14:37:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15700 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 14:37:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13480; Tue, 4 Jun 2002 14:01:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13447 for ; Tue, 4 Jun 2002 14:01:31 -0400 (EDT) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07958 for ; Tue, 4 Jun 2002 14:01:01 -0400 (EDT) Received: from victorpc ([206.184.140.168]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g54I1I100907; Tue, 4 Jun 2002 14:01:18 -0400 From: "Victor Paulsamy" To: "Jonathan Rosenberg" , Cc: Subject: RE: [Sip] RE: Was the Translate header used? Date: Tue, 4 Jun 2002 10:59:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm re-posting to get some response: > Victor Paulsamy wrote: > > > > In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last > > but > > one reads, "... From this 200 OK, the STUN agent knows whether or not > > the > > Translate header was used or not." > > > > In the example shown, the STUN agent learnt the public IP by querying > > STUN > > sever and changed the outgoing REGISTER appropriately to reflect this. > > When > > this request reaches the proxy, it checks the sent-by value against the > > received address; they are same in this case (hence no received= param). > > > Jonathan Rosenberg wrote: > No, they wouldn't be the same. The registration is sent over TCP, and > uses a different port than was used to communicate with the STUN server. > Victor Paulsamy wrote: The example message corresponding to the text is: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5678 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 88sdasdlasd0 Contact: sip:user@1.2.3.4:5678 Translate: sip:user@1.2.3.4:5678 CSeq: 88790 REGISTER Here, the request is indeed, sent using UDP. > > Say, the proxy supports SIP extensions for NAT. The proxy then rewrites > > the > > Translate header with sent-by value (in this case) which is same as the > > original value it carried in it. When returned in the 200 OK response, > > the > > STUN agent sees that, the Translate header has the same value that it > > put > > in, yet, the proxy supports the extension for NAT. > > Jonathan Rosenberg wrote: > > Since the source port is different than the Contact port, the contact > > would be rewritten and the client would know. > > Victor Paulsamy wrote: The source port (10) has been natted to 5678 (hence the port in Contact holds 5678). The original request sent by the client: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 99asdasd98hnn Contact: sip:user@10.0.1.1:5060 CSeq: 88790 REGISTER The STUN agent finds out the address and port (as seen by the proxy) by querying the STUN server; rewrites the message to: REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5678 From: sip:user@provider.com To: sip:user@provider.com Call-ID: 88sdasdlasd0 Contact: sip:user@1.2.3.4:5678 Translate: sip:user@1.2.3.4:5678 CSeq: 88790 REGISTER When sent out, the NAT rewrites the source address and port (to 1.2.3.4:5678), finally reached the proxy. At the proxy, it sees a Translate header hence, finds out a matching Contact header. The host value is replaced with the sent-by field from the Via (which in this case, is same as the value that's already present). The port number is replaced with the sent-by field (again, the same value that's carried in it). Though, the entire Contact header is rewritten, it results in the very same value it has already been carrying! Regards, --victor Victor Paulsamy E-mail: victor@zapex.com Senior Software Engineer Phone : 650.930.1339 (Direct) Zapex Technologies, Inc. Phone : 650.930.1300 (Main) Mountain View, CA 94043 Fax : 650.930.1399 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 4 14:48:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10351 for ; Tue, 4 Jun 2002 14:48:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16105 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 14:49:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12193; Tue, 4 Jun 2002 13:41:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12162 for ; Tue, 4 Jun 2002 13:41:32 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07265 for ; Tue, 4 Jun 2002 13:41:02 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17FIJF-0000R9-00; Tue, 04 Jun 2002 20:41:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15612.64456.994160.433215@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 20:41:28 +0300 To: Jonathan Rosenberg Cc: "Peterson, Jon" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <3CFCE36F.9E50F411@dynamicsoft.com> References: <15612.31343.163449.656540@harjus.eng.song.fi> <3CFCE36F.9E50F411@dynamicsoft.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I think the decision point about the hint is based on whether the hint > is ever useful without the P-Asserted-Identity. If it is useful without > that extension, then it probably does qualify as a regular header. If it > is not useful without that extension, then it is probably a P-header. my reply to that is that also the asserted-identity should be a regular, rather than a p header. i haven't yet figured out why asserted-identity is a p header except because of the rush by 3gpp, which has taken over ietf sip working group. it would be nice if each person sending email to the list about this topic could tell up front if she/he or his/her company has vested interest in 3gpp in order to be able to determine how "objective" his/her opinion is. > The gateway needs to only pass an authenticated > identity, in which case it can't pass the user's hint, it has to pass > the P-Asserted-Identity. Thus, your application would seem to require > the P-Asserted-Identity header. i have always disliked the word "hint" and asked to replace it in the drafts. as i have said too many times already, to me requested-identity is what the user asks for and it i don't like it, i refuse the request. therefore within my own domain, the sip/pstn gw may very well look at the requested-identity and thus requested-identity is useful without asserted-identity. > In many cases the credentials are configured in some reasonable > way, so that the user won't necessarily need to manually enter them (for > example, burn in at a store for a wireless phone) I am curious whether > you are really handing out 15 phone numbers to a single user... yes, since it would allow the user to have local identity in each of the 15 calling areas and people can return to the call to the user via a cheaper local call. having a separate username/password for each number is a nightmare not only to the user, but also for the service provider. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:20:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11380 for ; Tue, 4 Jun 2002 15:20:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17623 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:21:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16194; Tue, 4 Jun 2002 14:50:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16166 for ; Tue, 4 Jun 2002 14:50:21 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10423 for ; Tue, 4 Jun 2002 14:49:51 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17FJNp-0000Ry-00; Tue, 04 Jun 2002 21:50:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.3049.291200.39180@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 21:50:17 +0300 To: Henry Sinnreich Cc: "'Jonathan Rosenberg'" , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <000e01c20bf7$ac246850$80e023a6@hsinnreich2> References: <15612.64456.994160.433215@harjus.eng.song.fi> <000e01c20bf7$ac246850$80e023a6@hsinnreich2> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit henry, i also do want requested and asserted identity features, but i want them as real sip headers, not private p headers in order to meet some 3gpp deadline. so you don't care if all new useful extensions are all p headers? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11512 for ; Tue, 4 Jun 2002 15:25:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17796 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:25:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15989; Tue, 4 Jun 2002 14:43:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15952 for ; Tue, 4 Jun 2002 14:43:49 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10253 for ; Tue, 4 Jun 2002 14:43:19 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GX700D012NZGP@firewall.wcom.com> for sip@ietf.org; Tue, 4 Jun 2002 18:43:11 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GX700BCF2NNQQ@firewall.wcom.com>; Tue, 04 Jun 2002 18:43:11 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GX700E012NTTX@dgismtp06.wcomnet.com>; Tue, 04 Jun 2002 18:43:06 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.128]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GX700E172NTR3@dgismtp06.wcomnet.com>; Tue, 04 Jun 2002 18:43:05 +0000 (GMT) Date: Tue, 04 Jun 2002 13:43:08 -0500 From: Henry Sinnreich Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-reply-to: <15612.64456.994160.433215@harjus.eng.song.fi> To: jh@lohi.eng.song.fi, "'Jonathan Rosenberg'" Cc: "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Message-id: <000e01c20bf7$ac246850$80e023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > it would be nice if each person sending email to the list > about this topic could tell up front if she/he or his/her > company has vested interest in 3gpp in order to be able to > determine how "objective" his/her opinion is. I do not work for 3GPP but am very happy to see SIP embraced by such an important constituency. SIP has only to gain by the additional requirements from such commercial user communities. Plus mobility... Whatever we may think of some "walled garden" or not e2e transparent approaches, there is an analogy to IP that is used not only over the Internet, but also in private IP networks that are "very closed". I propose a cheer for the 3GPP folks for adopting SIP so seriously. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of jh@lohi.eng.song.fi > Sent: Tuesday, June 04, 2002 12:41 PM > To: Jonathan Rosenberg > Cc: Peterson, Jon; 'David R. Oran'; 'Mark Watson'; 'Andrew > Allen'; 'Rohan Mahy'; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? > > > Jonathan Rosenberg writes: > > > I think the decision point about the hint is based on > whether the hint > is ever useful without the > P-Asserted-Identity. If it is useful without > that > extension, then it probably does qualify as a regular header. > If it > is not useful without that extension, then it is > probably a P-header. > > my reply to that is that also the asserted-identity should be > a regular, rather than a p header. i haven't yet figured out > why asserted-identity is a p header except because of the > rush by 3gpp, which has taken over ietf sip working group. > > it would be nice if each person sending email to the list > about this topic could tell up front if she/he or his/her > company has vested interest in 3gpp in order to be able to > determine how "objective" his/her opinion is. > > > The gateway needs to only pass an authenticated > > identity, in which case it can't pass the user's hint, it > has to pass > the P-Asserted-Identity. Thus, your > application would seem to require > the P-Asserted-Identity header. > > i have always disliked the word "hint" and asked to replace > it in the drafts. as i have said too many times already, to > me requested-identity is what the user asks for and it i > don't like it, i refuse the request. therefore within my own > domain, the sip/pstn gw may very well look at the > requested-identity and thus requested-identity is useful > without asserted-identity. > > > In many cases the credentials are configured in some > reasonable > way, so that the user won't necessarily need to > manually enter them (for > example, burn in at a store for a > wireless phone) I am curious whether > you are really > handing out 15 phone numbers to a single user... > > yes, since it would allow the user to have local identity in > each of the 15 calling areas and people can return to the > call to the user via a cheaper local call. having a separate > username/password for each number is a nightmare not only to > the user, but also for the service provider. > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:39:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11973 for ; Tue, 4 Jun 2002 15:39:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18651 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:39:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17443; Tue, 4 Jun 2002 15:17:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17412 for ; Tue, 4 Jun 2002 15:17:07 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11280 for ; Tue, 4 Jun 2002 15:16:32 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GX70040147FL0@firewall.wcom.com> for sip@ietf.org; Tue, 4 Jun 2002 19:16:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GX70045S47FBQ@firewall.wcom.com>; Tue, 04 Jun 2002 19:16:27 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GX700201478DG@pmismtp01.wcomnet.com>; Tue, 04 Jun 2002 19:16:26 +0000 (GMT) Received: from hsinnreich2 ([166.35.248.93]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GX70015F46WRF@pmismtp01.wcomnet.com>; Tue, 04 Jun 2002 19:16:09 +0000 (GMT) Date: Tue, 04 Jun 2002 14:16:08 -0500 From: Henry Sinnreich Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-reply-to: <15613.3049.291200.39180@harjus.eng.song.fi> To: jh@lohi.eng.song.fi Cc: "'Jonathan Rosenberg'" , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Message-id: <000201c20bfc$485ace90$5df823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha, >so you don't care if all > new useful extensions are all p headers? You are right we should care and a doable approach may be to let the 3GPP folks meet their deadline first, and after that adopt from their work whatever makes sense in the open Internet as non p- headers. What do you think? Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of jh@lohi.eng.song.fi > Sent: Tuesday, June 04, 2002 1:50 PM > To: Henry Sinnreich > Cc: 'Jonathan Rosenberg'; 'Peterson, Jon'; 'David R. Oran'; > 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > henry, > > i also do want requested and asserted identity features, but > i want them as real sip headers, not private p headers in > order to meet some 3gpp deadline. so you don't care if all > new useful extensions are all p headers? > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:41:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12040 for ; Tue, 4 Jun 2002 15:41:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18701 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:41:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17497; Tue, 4 Jun 2002 15:18:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17466 for ; Tue, 4 Jun 2002 15:18:12 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11284 for ; Tue, 4 Jun 2002 15:17:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g54JJIYH004056 for ; Tue, 4 Jun 2002 15:19:19 -0400 (EDT) Message-ID: <3CFD1254.DF6989CB@dynamicsoft.com> Date: Tue, 04 Jun 2002 15:17:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] updating session timer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I am in the process of doing an update to session timer. This draft got "shelved" while we were finishing up bis and the rest of the pile of drafts for 3gpp. As such, its being updated to now reference bis rather than rfc2543. One of the things I am doing in this process is assessing whether anything new impacts design decisions we made in the original draft. One of the things we assumed in session timer was that all session refreshes were with re-invite. The principal reason for that was that we wanted the refreshes to have a soft-state property, so that a refresh could itself cause the recovery of call and session state at a failed-and-rebooted UA (or a backup). The notion of such soft-state recovery of sessions was something that we discussed at length for bis (bug #207), and ultimately decided not to go with. In the case of bis, the particular issue was that if you have a media stream failure, should you send a re-INVITE in order to re-establish the call with a backup? This would allow relatively fast recovery. However, we didn't do this because it had numerous problems, which I won't repeat. There was also limited interest in such recovery. Now, the point of this is that we discarded support for rapid recovery of call state and sessions from bis. Session timer would provide much slower recovery, arguably, so slow as to not be useful. Since we already discarded the much-more-useful approach, there seems little value in supporting the much-less-useful approach. Another thing that has changed with bis is the existence of another method which is a pretty reasonable mechanism for refreshing the session timer - UPDATE. An UPDATE without an offer at all seems a perfect mechanism for updating a session timer. So, I would propose we re-visit this design decision, and at the very least, allow for session timer refreshes to occur in UPDATE as well as INVITE. The other alternative is to allow session timer refreshes in any method. This would allow normally ocurring SIP messages within the dialog (if any) to cause refreshes, and if you had nothing to send, you would use UPDATE. The overall benefit here is reduced overhead (2-way exchange with UPDATE instead of three-way with INVITE). I see no reason why we shouldn't allow for session timer updates in any method. Another issue possibly worth revisiting is the decision to allow session timer to work as long as only one of the two UA in a dialog support it. In order to enable that, there is some complex proxy behavior, and generally more complex UA behavior. With more experience behind us (although I must say I am not aware of any UA implementations of this draft), do people still believe this is a reasonable assumption? I'm inclined not to change it, since I really prefer not to revisit every design decision unless there is good reason (i.e., bis has changed an assumption). Comments welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:44:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12213 for ; Tue, 4 Jun 2002 15:44:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18797 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:45:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17609; Tue, 4 Jun 2002 15:20:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17578 for ; Tue, 4 Jun 2002 15:20:30 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11371 for ; Tue, 4 Jun 2002 15:20:00 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g54JLQYH004059; Tue, 4 Jun 2002 15:21:26 -0400 (EDT) Message-ID: <3CFD12D3.BAADABFD@dynamicsoft.com> Date: Tue, 04 Jun 2002 15:19:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Henry Sinnreich , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? References: <15613.3049.291200.39180@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > henry, > > i also do want requested and asserted identity features, but i want them > as real sip headers, not private p headers in order to meet some 3gpp > deadline. so you don't care if all new useful extensions are all p > headers? The asserted identity draft is a P-header because it has some big assumptions that make it inapplicable to the Internet at large, and dangerous if not part of a well architected network. The assumptions are true for 3gpp, but it is not the case that the draft is a P-header just because of 3gpp. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 15:49:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12398 for ; Tue, 4 Jun 2002 15:49:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18884 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 15:50:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17942; Tue, 4 Jun 2002 15:29:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17909 for ; Tue, 4 Jun 2002 15:29:30 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11643 for ; Tue, 4 Jun 2002 15:28:59 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17FJzh-0000Ss-00; Tue, 04 Jun 2002 22:29:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.5397.236019.673512@harjus.eng.song.fi> Date: Tue, 4 Jun 2002 22:29:25 +0300 To: Henry Sinnreich Cc: "'Jonathan Rosenberg'" , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <000201c20bfc$485ace90$5df823a6@hsinnreich2> References: <15613.3049.291200.39180@harjus.eng.song.fi> <000201c20bfc$485ace90$5df823a6@hsinnreich2> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henry Sinnreich writes: > You are right we should care and a doable approach may be to let the > 3GPP folks meet their deadline first, and after that adopt from their > work whatever makes sense in the open Internet as non p- headers. once ietf defines a p header for some purpose, there is far less motivation to produce the corresponding standards track sip header. the result is weaker sip and non-interoperable products. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 16:17:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13513 for ; Tue, 4 Jun 2002 16:17:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20415 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 16:18:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19271; Tue, 4 Jun 2002 15:59:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19240 for ; Tue, 4 Jun 2002 15:59:32 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12757 for ; Tue, 4 Jun 2002 15:59:01 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g54JwR409822; Tue, 4 Jun 2002 14:58:27 -0500 From: "Dean Willis" To: Cc: Subject: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Tue, 4 Jun 2002 14:58:20 -0500 Message-ID: <006301c20c02$2da52220$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <15613.5397.236019.673512@harjus.eng.song.fi> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > once ietf defines a p header for some purpose, there is far > less motivation to produce the corresponding standards track > sip header. the result is weaker sip and non-interoperable products. That is a legitimate position to take regarding the proposed SIP Change Process, something that we ARE working to refine. I've found my own P-header draft has been as rigorously developed and discussed as my standards-track work, and the more we talk about it, the more I've begun to wonder: 1) What REALLY differentiates P-headers from standards track, if they're held to the same level of accountability? The difference here, I suspect, is contained in the applicability statement -- P-headers seem to need a "Danger! Don't use this UNLESS you have the following really odd network AND have taken special steps, listed here, to compensate for the problems induced by that oddness". It actually appears to be harder to write a P-header draft and get it accepted than a "standard" draft, because it's so hard to craft this applicability statement. 2) For things that turn out to be broadly useful, how will we evolve from a P-header to a standard? Can we? Should we discard the "preliminary" definition of P and only use P-headers for things that seem really obviously proprietary, like unique billing tokens and stuff? What happens when they turn out to be widely used? 3) Should I have just made P-Service-Route standards track instead of a P-header? It does have applicability outside of 3GPP, and doesn't need the "Danger, Will Robinson!" applicability statetement that seems to characterize the "really 3GPP drafts". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 16:59:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14828 for ; Tue, 4 Jun 2002 16:59:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22787 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 17:00:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21670; Tue, 4 Jun 2002 16:37:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21639 for ; Tue, 4 Jun 2002 16:37:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14120 for ; Tue, 4 Jun 2002 16:36:49 -0400 (EDT) Received: from OranLT.cisco.com ([161.44.238.34]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g54KafPI021438; Tue, 4 Jun 2002 13:36:42 -0700 (PDT) Date: Tue, 04 Jun 2002 16:36:25 -0400 From: "David R. Oran" To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] updating session timer Message-ID: <413813422.1023208585@OranLT.cisco.com> In-Reply-To: <3CFD1254.DF6989CB@dynamicsoft.com> References: <3CFD1254.DF6989CB@dynamicsoft.com> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It certainly makes sense to have UPDATE refresh the session timer. Other than that I don't see much benefit in tweaking the design, unless we just want to say that any method refreshes the timer. That makes the spec future-proof for new methods, which might be a good thing, or a bad thing depending on some clairvoyance I don't have. I vote for the minimal disruption: add UPDATE as a method which refreshes the timer and leave the rest alone. Dave. --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg wrote: > Folks, > > I am in the process of doing an update to session timer. This draft got > "shelved" while we were finishing up bis and the rest of the pile of > drafts for 3gpp. As such, its being updated to now reference bis rather > than rfc2543. One of the things I am doing in this process is assessing > whether anything new impacts design decisions we made in the original > draft. > > One of the things we assumed in session timer was that all session > refreshes were with re-invite. The principal reason for that was that we > wanted the refreshes to have a soft-state property, so that a refresh > could itself cause the recovery of call and session state at a > failed-and-rebooted UA (or a backup). > > The notion of such soft-state recovery of sessions was something that we > discussed at length for bis (bug #207), and ultimately decided not to go > with. In the case of bis, the particular issue was that if you have a > media stream failure, should you send a re-INVITE in order to > re-establish the call with a backup? This would allow relatively fast > recovery. However, we didn't do this because it had numerous problems, > which I won't repeat. There was also limited interest in such recovery. > Now, the point of this is that we discarded support for rapid recovery > of call state and sessions from bis. Session timer would provide much > slower recovery, arguably, so slow as to not be useful. Since we already > discarded the much-more-useful approach, there seems little value in > supporting the much-less-useful approach. > > Another thing that has changed with bis is the existence of another > method which is a pretty reasonable mechanism for refreshing the session > timer - UPDATE. An UPDATE without an offer at all seems a perfect > mechanism for updating a session timer. > > So, I would propose we re-visit this design decision, and at the very > least, allow for session timer refreshes to occur in UPDATE as well as > INVITE. The other alternative is to allow session timer refreshes in any > method. This would allow normally ocurring SIP messages within the > dialog (if any) to cause refreshes, and if you had nothing to send, you > would use UPDATE. The overall benefit here is reduced overhead (2-way > exchange with UPDATE instead of three-way with INVITE). I see no reason > why we shouldn't allow for session timer updates in any method. > > Another issue possibly worth revisiting is the decision to allow session > timer to work as long as only one of the two UA in a dialog support it. > In order to enable that, there is some complex proxy behavior, and > generally more complex UA behavior. With more experience behind us > (although I must say I am not aware of any UA implementations of this > draft), do people still believe this is a reasonable assumption? I'm > inclined not to change it, since I really prefer not to revisit every > design decision unless there is good reason (i.e., bis has changed an > assumption). > > Comments welcome. > > Thanks, > Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ----------------------------------------------------------- David R. Oran Phone/Fax: +1 978 264 2048 Cisco Systems VoIP: +1 408 571 4576 7 Ladyslipper Lane Email: oran@cisco.com Acton, MA 01720 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 17:07:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15124 for ; Tue, 4 Jun 2002 17:07:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23709 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 17:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22210; Tue, 4 Jun 2002 16:47:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22169 for ; Tue, 4 Jun 2002 16:47:53 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14390 for ; Tue, 4 Jun 2002 16:47:22 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g54KpYV14863; Tue, 4 Jun 2002 15:51:34 -0500 From: Robert Sparks To: sip@ietf.org Cc: Allison Mankin Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jun 2002 15:44:56 -0500 Message-Id: <1023223496.9663.129.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Responses to Last Call Comments : draft-ietf-sip-refer-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've just submitted http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-05.txt which incorporates the last call comments on refer-04. The changes are: Content: * The syntax of Refer-To was modified to allow extension parameters. * The behavior of registrars and redirect servers was incorrect in 04. Redirect servers are method agnostic and redirect REFER like any other request. Registrars are now required to return a 405 instead of a 603. * A discussion on the use of the mandatory Subscription-State header field in NOTIFY has been added. * Registration instructions for the REFER method was added to the IANA considerations section Spelling, grammar, format: * The draft title was changed to include the word "SIP" * The references were retitled "Normative References" * Use of colons after header field names in the text was dropped for consistency * Some non-normative words that looked like they might be normative (lower case shoulds and mays) were replaced with less potentially confusing text. * minor editorial nits were addressed. 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 daemon@ns.ietf.org Tue Jun 4 17:10:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15260 for ; Tue, 4 Jun 2002 17:10:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23893 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 17:11:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22142; Tue, 4 Jun 2002 16:46:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22114 for ; Tue, 4 Jun 2002 16:46:31 -0400 (EDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14368 for ; Tue, 4 Jun 2002 16:45:59 -0400 (EDT) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g54Kh7US002145 for ; Tue, 4 Jun 2002 16:45:58 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3CBB497300256025; Tue, 4 Jun 2002 16:45:47 -0400 content-class: urn:content-classes:message Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Tue, 4 Jun 2002 16:45:48 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F902AB757C@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcIMA4ZJjPKzd9c2SZObUIR4XMkJCgABCvyA From: "Roy, Radhika R, ALASO" To: "Dean Willis" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA22115 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit inline [RRR] -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] What happens when they turn out to be widely used? [RRR] The architecture for the 3GPP application server environment can also be applicable in any wire-line network. So, the P-headers defined for 3GPP may have the wider applicability. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 17:27:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16125 for ; Tue, 4 Jun 2002 17:27:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24321 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 17:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23652; Tue, 4 Jun 2002 17:06:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23623 for ; Tue, 4 Jun 2002 17:06:33 -0400 (EDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15058 for ; Tue, 4 Jun 2002 17:06:01 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g54L6rv26558 for ; Tue, 4 Jun 2002 21:06:54 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g54L4Mo18952 for ; Tue, 4 Jun 2002 21:04:22 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060414063307384 ; Tue, 04 Jun 2002 14:06:33 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 14:06:27 -0700 Message-ID: From: "Padhye, Chinmay" To: sip@ietf.org Cc: "'David R. Oran'" , Jonathan Rosenberg Subject: RE: [Sip] updating session timer Date: Tue, 4 Jun 2002 14:06:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I feel any method sent/received on an existing dialog should reset the session timer for that dialog. Its OK for UPDATE to change the session timer related roles, timer values, etc. Regards, Chinmay -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Tuesday, June 04, 2002 1:36 PM To: Jonathan Rosenberg; sip@ietf.org Subject: Re: [Sip] updating session timer It certainly makes sense to have UPDATE refresh the session timer. Other than that I don't see much benefit in tweaking the design, unless we just want to say that any method refreshes the timer. That makes the spec future-proof for new methods, which might be a good thing, or a bad thing depending on some clairvoyance I don't have. I vote for the minimal disruption: add UPDATE as a method which refreshes the timer and leave the rest alone. Dave. --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg wrote: > Folks, > > I am in the process of doing an update to session timer. This draft got > "shelved" while we were finishing up bis and the rest of the pile of > drafts for 3gpp. As such, its being updated to now reference bis rather > than rfc2543. One of the things I am doing in this process is assessing > whether anything new impacts design decisions we made in the original > draft. > > One of the things we assumed in session timer was that all session > refreshes were with re-invite. The principal reason for that was that we > wanted the refreshes to have a soft-state property, so that a refresh > could itself cause the recovery of call and session state at a > failed-and-rebooted UA (or a backup). > > The notion of such soft-state recovery of sessions was something that we > discussed at length for bis (bug #207), and ultimately decided not to go > with. In the case of bis, the particular issue was that if you have a > media stream failure, should you send a re-INVITE in order to > re-establish the call with a backup? This would allow relatively fast > recovery. However, we didn't do this because it had numerous problems, > which I won't repeat. There was also limited interest in such recovery. > Now, the point of this is that we discarded support for rapid recovery > of call state and sessions from bis. Session timer would provide much > slower recovery, arguably, so slow as to not be useful. Since we already > discarded the much-more-useful approach, there seems little value in > supporting the much-less-useful approach. > > Another thing that has changed with bis is the existence of another > method which is a pretty reasonable mechanism for refreshing the session > timer - UPDATE. An UPDATE without an offer at all seems a perfect > mechanism for updating a session timer. > > So, I would propose we re-visit this design decision, and at the very > least, allow for session timer refreshes to occur in UPDATE as well as > INVITE. The other alternative is to allow session timer refreshes in any > method. This would allow normally ocurring SIP messages within the > dialog (if any) to cause refreshes, and if you had nothing to send, you > would use UPDATE. The overall benefit here is reduced overhead (2-way > exchange with UPDATE instead of three-way with INVITE). I see no reason > why we shouldn't allow for session timer updates in any method. > > Another issue possibly worth revisiting is the decision to allow session > timer to work as long as only one of the two UA in a dialog support it. > In order to enable that, there is some complex proxy behavior, and > generally more complex UA behavior. With more experience behind us > (although I must say I am not aware of any UA implementations of this > draft), do people still believe this is a reasonable assumption? I'm > inclined not to change it, since I really prefer not to revisit every > design decision unless there is good reason (i.e., bis has changed an > assumption). > > Comments welcome. > > Thanks, > Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ----------------------------------------------------------- David R. Oran Phone/Fax: +1 978 264 2048 Cisco Systems VoIP: +1 408 571 4576 7 Ladyslipper Lane Email: oran@cisco.com Acton, MA 01720 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 18:07:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17567 for ; Tue, 4 Jun 2002 18:07:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26370 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 18:08:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25216; Tue, 4 Jun 2002 17:45:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25192 for ; Tue, 4 Jun 2002 17:45:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16917 for ; Tue, 4 Jun 2002 17:45:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA01873; Tue, 4 Jun 2002 17:44:57 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06159; Tue, 4 Jun 2002 17:44:58 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jun 2002 17:44:57 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B5446@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'David R. Oran'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] updating session timer Date: Tue, 4 Jun 2002 17:44:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I also vote for allow in UPDATE, and no more. But, please, we seem to be able to find something to tweak no matter how long we bake things. This one is overdone, let's get it out now. Brian > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 04, 2002 4:36 PM > To: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] updating session timer > > > It certainly makes sense to have UPDATE refresh the session > timer. Other > than that I don't see much benefit in tweaking the design, > unless we just > want to say that any method refreshes the timer. That makes the spec > future-proof for new methods, which might be a good thing, or > a bad thing > depending on some clairvoyance I don't have. > > I vote for the minimal disruption: add UPDATE as a method > which refreshes > the timer and leave the rest alone. > > Dave. > > --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg > wrote: > > > Folks, > > > > I am in the process of doing an update to session timer. > This draft got > > "shelved" while we were finishing up bis and the rest of the pile of > > drafts for 3gpp. As such, its being updated to now > reference bis rather > > than rfc2543. One of the things I am doing in this process > is assessing > > whether anything new impacts design decisions we made in > the original > > draft. > > > > One of the things we assumed in session timer was that all session > > refreshes were with re-invite. The principal reason for > that was that we > > wanted the refreshes to have a soft-state property, so that > a refresh > > could itself cause the recovery of call and session state at a > > failed-and-rebooted UA (or a backup). > > > > The notion of such soft-state recovery of sessions was > something that we > > discussed at length for bis (bug #207), and ultimately > decided not to go > > with. In the case of bis, the particular issue was that if > you have a > > media stream failure, should you send a re-INVITE in order to > > re-establish the call with a backup? This would allow > relatively fast > > recovery. However, we didn't do this because it had > numerous problems, > > which I won't repeat. There was also limited interest in > such recovery. > > Now, the point of this is that we discarded support for > rapid recovery > > of call state and sessions from bis. Session timer would > provide much > > slower recovery, arguably, so slow as to not be useful. > Since we already > > discarded the much-more-useful approach, there seems little value in > > supporting the much-less-useful approach. > > > > Another thing that has changed with bis is the existence of another > > method which is a pretty reasonable mechanism for > refreshing the session > > timer - UPDATE. An UPDATE without an offer at all seems a perfect > > mechanism for updating a session timer. > > > > So, I would propose we re-visit this design decision, and > at the very > > least, allow for session timer refreshes to occur in UPDATE > as well as > > INVITE. The other alternative is to allow session timer > refreshes in any > > method. This would allow normally ocurring SIP messages within the > > dialog (if any) to cause refreshes, and if you had nothing > to send, you > > would use UPDATE. The overall benefit here is reduced > overhead (2-way > > exchange with UPDATE instead of three-way with INVITE). I > see no reason > > why we shouldn't allow for session timer updates in any method. > > > > Another issue possibly worth revisiting is the decision to > allow session > > timer to work as long as only one of the two UA in a dialog > support it. > > In order to enable that, there is some complex proxy behavior, and > > generally more complex UA behavior. With more experience behind us > > (although I must say I am not aware of any UA > implementations of this > > draft), do people still believe this is a reasonable assumption? I'm > > inclined not to change it, since I really prefer not to > revisit every > > design decision unless there is good reason (i.e., bis has > changed an > > assumption). > > > > Comments welcome. > > > > Thanks, > > Jonathan R. > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > ----------------------------------------------------------- > David R. Oran Phone/Fax: +1 978 264 2048 > Cisco Systems VoIP: +1 408 571 4576 > 7 Ladyslipper Lane Email: oran@cisco.com > Acton, MA 01720 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 19:37:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19897 for ; Tue, 4 Jun 2002 19:37:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00476 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 19:38:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29472; Tue, 4 Jun 2002 19:10:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29441 for ; Tue, 4 Jun 2002 19:10:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19660 for ; Tue, 4 Jun 2002 19:09:53 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g54N9gPI025995; Tue, 4 Jun 2002 16:09:42 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU41960; Tue, 4 Jun 2002 16:06:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA08727; Tue, 4 Jun 2002 16:09:42 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.18613.866709.978537@thomasm-u1.cisco.com> Date: Tue, 4 Jun 2002 16:09:41 -0700 (PDT) To: Jonathan Rosenberg Cc: jh@lohi.eng.song.fi, "Peterson, Jon" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <3CFCE36F.9E50F411@dynamicsoft.com> References: <15612.31343.163449.656540@harjus.eng.song.fi> <3CFCE36F.9E50F411@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I think the decision point about the hint is based on whether the hint > is ever useful without the P-Asserted-Identity. If it is useful without > that extension, then it probably does qualify as a regular header. If it > is not useful without that extension, then it is probably a P-header. > > Personally, I don't see how one would use the hint without a network > asserted identity. In the application you are interested in, you are > delivering one of several phone numbers to a PSTN gateway, even when the > user is anonymous. The gateway needs to only pass an authenticated > identity, in which case it can't pass the user's hint, it has to pass > the P-Asserted-Identity. Thus, your application would seem to require > the P-Asserted-Identity header. Jonathan, I'm probably foolish wandering back into this debate, but I find this entire subject rather perplexing. I guess I see all of this as various elements wanting to assert an identity -- perhaps bound to some cryptographic proof -- along with who is signing it. Yes, there may well be the need for different identities, just like I need different keys to unlock locks; same goes for the doors along the proxy routed path. Nor do I think we should expect that there is any global name space which would allow a single unified identity; to my first hop proxy, I'm mike@mtcc.com, but I'm pretty sure that I'll need an mat@cisco.com identity to get past Cisco's edge proxy. Telling either one that they must adopt the other's indentifiers is... hopeless IMO (and undesirable). So, I guess from the UA standpoint I see that we have a general requirement that the UA be able to assert multiple identities. Essentially, what it seems to me that we need is one or more AKA's to be used anywhere along the proxy routed path by anyone who is willing to believe that identity, or more specifically the identity which was asserted (and signed) by some (possibly third party) entity. For network asserted, it seems to me that all we're doing is expanding the set of things that can insert an AKA, along eventually with some cryptographic proof as well. Again, its consumer would be anybody along the proxy routed path who is willing to believe it. The UAS is an obvious consumer, but this may well be a useful way for organizations to "vouch" their users to the next hop proxy without having to expose the underlying, internal authentication mechanisms to the outside for verification. So, I guess I don't understand all of the thrashing around on this issue. If we had a header sort of like: Also-known-as: identity [; asserted-by=identity [; signature=signature]] Which could be inserted along the proxy routed path, does that give each device farther downstream the necessary information to unlock the sucessive door? (yes, I realize there is more to this given privacy, etc, but that doesn't seem to be what's at issue in this current go-round) So to answer your question, yes I think that the Asserted-Identity, or AKA, or "hint" (bletch) is useful all on its own. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 20:45:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20648 for ; Tue, 4 Jun 2002 20:45:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03489 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 20:45:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02055; Tue, 4 Jun 2002 20:18:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02027 for ; Tue, 4 Jun 2002 20:18:35 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20235 for ; Tue, 4 Jun 2002 20:18:04 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g550HtIZ026379; Tue, 4 Jun 2002 17:17:55 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU43658; Tue, 4 Jun 2002 17:14:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA08736; Tue, 4 Jun 2002 17:17:54 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.22706.805754.838714@thomasm-u1.cisco.com> Date: Tue, 4 Jun 2002 17:17:54 -0700 (PDT) To: "David R. Oran" Cc: Jonathan Rosenberg , "Peterson, Jon" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <310935862.1023105708@OranLT.cisco.com> References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com> <3CF7ED61.AE86452E@dynamicsoft.com> <310935862.1023105708@OranLT.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit David R. Oran writes: > I find Jonathan's point quite persuasive. It might help with clarity on > Juha's application of the header as well. In fact, if we have a separate > header for the UA to insert, it might also encode user's desire about > whether he wants the service provider to reject the call if it is unwilling > to use the UA-asserted identity. > > If we go the renaming route, could conveivably have: > p-ua-asserted-identity, and > p-proxy-asserted-identity. What this essentially says is that the _role_ (eg, ua, proxy) is somehow important rather than or along with the identity itself. That is, I might take a different action just because a proxy asserts an identity rather than a UA. This seems rather squirrelly to me. It also means that roles need to be bound to (currently non-existant) credentials as well. Normally I'd think you just want to have identities which bound to some authorization information determine what your course of action. Adding roles adds another dimension. Or is this in *lieu* of who's asserting the identity? Hmm. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 21:06:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20980 for ; Tue, 4 Jun 2002 21:06:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04734 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 21:06:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03412; Tue, 4 Jun 2002 20:44:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03381 for ; Tue, 4 Jun 2002 20:44:53 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20619 for ; Tue, 4 Jun 2002 20:44:23 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g550i6411956; Tue, 4 Jun 2002 19:44:06 -0500 From: "Dean Willis" To: "'Padhye, Chinmay'" , Cc: "'David R. Oran'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] updating session timer Date: Tue, 4 Jun 2002 19:43:59 -0500 Message-ID: <00ab01c20c2a$15590330$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think I agree with Chinmay here. One of the big beefs with session-timer is the number of additional messages required (INVITE-OK-ACK) just to refresh it. If every request-response on the dialog resets the count-down timer, then we have very little overhead. -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Padhye, Chinmay > Sent: Tuesday, June 04, 2002 4:06 PM > To: sip@ietf.org > Cc: 'David R. Oran'; Jonathan Rosenberg > Subject: RE: [Sip] updating session timer > > > Hello, > > I feel any method sent/received on an existing dialog > should reset the session timer for that dialog. > > Its OK for UPDATE to change the session timer related > roles, timer values, etc. > > Regards, > > Chinmay > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 04, 2002 1:36 PM > To: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] updating session timer > > > It certainly makes sense to have UPDATE refresh the session > timer. Other > than that I don't see much benefit in tweaking the design, > unless we just > want to say that any method refreshes the timer. That makes the spec > future-proof for new methods, which might be a good thing, or > a bad thing > depending on some clairvoyance I don't have. > > I vote for the minimal disruption: add UPDATE as a method > which refreshes > the timer and leave the rest alone. > > Dave. > > --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg > wrote: > > > Folks, > > > > I am in the process of doing an update to session timer. This draft > > got "shelved" while we were finishing up bis and the rest > of the pile > > of drafts for 3gpp. As such, its being updated to now reference bis > > rather than rfc2543. One of the things I am doing in this > process is > > assessing whether anything new impacts design decisions we > made in the > > original draft. > > > > One of the things we assumed in session timer was that all session > > refreshes were with re-invite. The principal reason for > that was that > > we wanted the refreshes to have a soft-state property, so that a > > refresh could itself cause the recovery of call and session > state at a > > failed-and-rebooted UA (or a backup). > > > > The notion of such soft-state recovery of sessions was > something that > > we discussed at length for bis (bug #207), and ultimately > decided not > > to go with. In the case of bis, the particular issue was > that if you > > have a media stream failure, should you send a re-INVITE in > order to > > re-establish the call with a backup? This would allow > relatively fast > > recovery. However, we didn't do this because it had > numerous problems, > > which I won't repeat. There was also limited interest in such > > recovery. Now, the point of this is that we discarded support for > > rapid recovery of call state and sessions from bis. Session timer > > would provide much slower recovery, arguably, so slow as to not be > > useful. Since we already discarded the much-more-useful approach, > > there seems little value in supporting the much-less-useful > approach. > > > > Another thing that has changed with bis is the existence of another > > method which is a pretty reasonable mechanism for refreshing the > > session timer - UPDATE. An UPDATE without an offer at all seems a > > perfect mechanism for updating a session timer. > > > > So, I would propose we re-visit this design decision, and > at the very > > least, allow for session timer refreshes to occur in UPDATE > as well as > > INVITE. The other alternative is to allow session timer > refreshes in > > any method. This would allow normally ocurring SIP messages > within the > > dialog (if any) to cause refreshes, and if you had nothing to send, > > you would use UPDATE. The overall benefit here is reduced overhead > > (2-way exchange with UPDATE instead of three-way with > INVITE). I see > > no reason why we shouldn't allow for session timer updates in any > > method. > > > > Another issue possibly worth revisiting is the decision to allow > > session timer to work as long as only one of the two UA in a dialog > > support it. In order to enable that, there is some complex proxy > > behavior, and generally more complex UA behavior. With more > experience > > behind us (although I must say I am not aware of any UA > > implementations of this draft), do people still believe this is a > > reasonable assumption? I'm inclined not to change it, since > I really > > prefer not to revisit every design decision unless there is good > > reason (i.e., bis has changed an assumption). > > > > Comments welcome. > > > > Thanks, > > Jonathan R. > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > ----------------------------------------------------------- > David R. Oran Phone/Fax: +1 978 264 2048 > Cisco Systems VoIP: +1 408 571 4576 > 7 Ladyslipper Lane Email: oran@cisco.com > Acton, MA 01720 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 21:13:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21142 for ; Tue, 4 Jun 2002 21:13:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05091 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 21:13:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03473; Tue, 4 Jun 2002 20:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03442 for ; Tue, 4 Jun 2002 20:45:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20623 for ; Tue, 4 Jun 2002 20:44:59 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g550ioPI011254; Tue, 4 Jun 2002 17:44:50 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU44236; Tue, 4 Jun 2002 17:41:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA08740; Tue, 4 Jun 2002 17:44:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.24320.929009.650934@thomasm-u1.cisco.com> Date: Tue, 4 Jun 2002 17:44:48 -0700 (PDT) To: jh@lohi.eng.song.fi Cc: Henry Sinnreich , "'Jonathan Rosenberg'" , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-Reply-To: <15613.5397.236019.673512@harjus.eng.song.fi> References: <15613.3049.291200.39180@harjus.eng.song.fi> <000201c20bfc$485ace90$5df823a6@hsinnreich2> <15613.5397.236019.673512@harjus.eng.song.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi writes: > Henry Sinnreich writes: > > > You are right we should care and a doable approach may be to let the > > 3GPP folks meet their deadline first, and after that adopt from their > > work whatever makes sense in the open Internet as non p- headers. > > once ietf defines a p header for some purpose, there is far less > motivation to produce the corresponding standards track sip header. > the result is weaker sip and non-interoperable products. Indeed, this entire process seems like it leads to national-variants-of-ISUP hell. Add me to the list of people worried about whether 3GPP short term hacks are harming the long term health of SIP. If you ask me, the main problem here is an inability to just declare consensus for these and just *live* with it. Frankly I'm astonished that this is all still on the table after the endless series of meetings, correspondence etc on this subject. I can't say as that I've seen anything new here. This P-hack route seems to be nothing more than an explicit admission of the WG's dysfunction. Sorry for adding to the noise level. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 4 21:17:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21197 for ; Tue, 4 Jun 2002 21:17:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05240 for sip-archive@odin.ietf.org; Tue, 4 Jun 2002 21:17:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04667; Tue, 4 Jun 2002 21:03:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04636 for ; Tue, 4 Jun 2002 21:03:54 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20951 for ; Tue, 4 Jun 2002 21:03:24 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GX700J01K9GT9@firewall.wcom.com> for sip@ietf.org; Wed, 5 Jun 2002 01:03:17 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GX700H9ZK9GMM@firewall.wcom.com>; Wed, 05 Jun 2002 01:03:16 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GX700201K9FG0@pmismtp02.wcomnet.com>; Wed, 05 Jun 2002 01:03:16 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.178]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GX700M8UK904W@pmismtp02.wcomnet.com>; Wed, 05 Jun 2002 01:03:02 +0000 (GMT) Date: Tue, 04 Jun 2002 20:03:01 -0500 From: Henry Sinnreich Subject: RE: [Sip] Asserted-Identity: How to 'hint'? In-reply-to: <15613.24320.929009.650934@thomasm-u1.cisco.com> To: "'Michael Thomas'" , jh@lohi.eng.song.fi Cc: "'Jonathan Rosenberg'" , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , "'Andrew Allen'" , "'Rohan Mahy'" , sip@ietf.org Message-id: <001c01c20c2c$be041c70$b2202aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > This P-hack route seems to > be nothing more than an explicit admission > of the WG's dysfunction. This stems actually from a business decision not to have the 3GPP networks be part of the open Internet and I am afraid the WG engineeers can do very little about it. Henry > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, June 04, 2002 7:45 PM > To: jh@lohi.eng.song.fi > Cc: Henry Sinnreich; 'Jonathan Rosenberg'; 'Peterson, Jon'; > 'David R. Oran'; 'Mark Watson'; 'Andrew Allen'; 'Rohan Mahy'; > sip@ietf.org > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? > > > jh@lohi.eng.song.fi writes: > > Henry Sinnreich writes: > > > > > You are right we should care and a doable approach may > be to let the > > 3GPP folks meet their deadline first, and > after that adopt from their > > work whatever makes sense > in the open Internet as non p- headers. > > > > once ietf defines a p header for some purpose, there is > far less > motivation to produce the corresponding standards > track sip header. > the result is weaker sip and > non-interoperable products. > > Indeed, this entire process seems like it leads > to national-variants-of-ISUP hell. Add me to > the list of people worried about whether 3GPP > short term hacks are harming the long term > health of SIP. > > If you ask me, the main problem here is an > inability to just declare consensus for these > and just *live* with it. Frankly I'm astonished > that this is all still on the table after the > endless series of meetings, correspondence etc > on this subject. I can't say as that I've seen > anything new here. This P-hack route seems to > be nothing more than an explicit admission > of the WG's dysfunction. > > Sorry for adding to the noise level. > > Mike > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 01:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27851 for ; Wed, 5 Jun 2002 01:45:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27880 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 01:46:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26352; Wed, 5 Jun 2002 01:19:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26321 for ; Wed, 5 Jun 2002 01:19:46 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27172 for ; Wed, 5 Jun 2002 01:19:16 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17FTCx-0000dH-00; Wed, 05 Jun 2002 08:19:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.40815.46524.976723@harjus.eng.song.fi> Date: Wed, 5 Jun 2002 08:19:43 +0300 To: "Roy, Radhika R, ALASO" Cc: "Dean Willis" , Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) In-Reply-To: <62DA45D4963FA747BA1B253E266760F902AB757C@OCCLUST04EVS1.ugd.att.com> References: <62DA45D4963FA747BA1B253E266760F902AB757C@OCCLUST04EVS1.ugd.att.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Roy, Radhika R, ALASO writes: > [RRR] The architecture for the 3GPP application server environment can > also be applicable in any wire-line network. So, the P-headers defined > for 3GPP may have the wider applicability. i prefer an open internet style architecture instead of the recreation of the closed pstn architecture using ip protocols. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 02:15:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06904 for ; Wed, 5 Jun 2002 02:15:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01945 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 02:15:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27638; Wed, 5 Jun 2002 01:36:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27526 for ; Wed, 5 Jun 2002 01:35:55 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27791 for ; Wed, 5 Jun 2002 01:35:24 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g555ZNHs005633 for ; Tue, 4 Jun 2002 22:35:23 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADB73006; Tue, 4 Jun 2002 22:35:33 -0700 (PDT) From: "Cullen Jennings" To: Date: Tue, 4 Jun 2002 22:36:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Asserted-Identity - new hint proposal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am getting the feeling that people want to put the hint in a separate header. How would everyone feel about something along the lines of: P-Suggested-Identity: "Cullen Jennings" ;mandatory The UAC would insert this header to indicate the Asserted-Identity that it wished the Trust Domain to choose. The "mandatory" indicates that the Trust Domain MUST return some 4xx response if it is not going to assert this identity. If the "mandatory" was not present, it would not return an 4xx if it choose a different identity to assert for the user. Should we go with two headers (PSI and PAI)? Does PSI need some flag (like mandatory) to say how it is handled in the case the suggested identity is not going to be provided? Alternatively, should we go with one header and the argument that Dean so nicely summed up as > I think existence of a P-A-I header in a message means "a previous hop > (sender or proxy) has asserted this identity. Deal with it." > > Options for dealing with it are: > > 1) Believe it > 2) Delete it (in conjunction with "privacy" modifier) > 3) Delete it and assert a different identity > 4) Reject the message 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 daemon@optimus.ietf.org Wed Jun 5 03:25:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21893 for ; Wed, 5 Jun 2002 03:25:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15836 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 03:25:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14137; Wed, 5 Jun 2002 02:50:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14113 for ; Wed, 5 Jun 2002 02:50:47 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21539 for ; Wed, 5 Jun 2002 02:50:16 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g556o8f03223; Wed, 5 Jun 2002 01:50:08 -0500 Message-ID: <002501c20c5d$458f0d50$133fed0c@C1893415A> From: "Dean Willis" To: "Cullen Jennings" , References: Subject: Re: [Sip] Asserted-Identity - new hint proposal Date: Wed, 5 Jun 2002 01:48:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I am getting the feeling that people want to put the hint in a separate > header. How would everyone feel about something along the lines of: I liked one header -- I thought the semantic was pretty good "SOMEBODY asserted this identity -- vouch for it or reject it". But at this point I just don't care anymore. . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 04:31:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23678 for ; Wed, 5 Jun 2002 04:31:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20661 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 04:31:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19096; Wed, 5 Jun 2002 04:09:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19066 for ; Wed, 5 Jun 2002 04:09:08 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22679 for ; Wed, 5 Jun 2002 04:08:38 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 17FVqa-0000en-00; Wed, 05 Jun 2002 11:08:48 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.50960.2686.232380@lohi.eng.song.fi> Date: Wed, 5 Jun 2002 11:08:47 +0300 To: "Dean Willis" Cc: "Cullen Jennings" , Subject: Re: [Sip] Asserted-Identity - new hint proposal In-Reply-To: <002501c20c5d$458f0d50$133fed0c@C1893415A> References: <002501c20c5d$458f0d50$133fed0c@C1893415A> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > But at this point I just don't care anymore. . . sama here as long as the header that the ua uses is a real sip header, not a p header. see the discussion from yesterday. i'm very suprised that you simply decided to ignore it and thus caused this vaste of bandwidth. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 04:31:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23697 for ; Wed, 5 Jun 2002 04:31:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20681 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 04:32:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18800; Wed, 5 Jun 2002 04:04:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18769 for ; Wed, 5 Jun 2002 04:04:19 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22610 for ; Wed, 5 Jun 2002 04:03:48 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5584h621834 for ; Wed, 5 Jun 2002 11:04:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Jun 2002 10:59:05 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 5 Jun 2002 10:59:05 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 5 Jun 2002 10:59:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] updating session timer Date: Wed, 5 Jun 2002 10:58:53 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777923A@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] updating session timer Thread-Index: AcIMK6HQl/hbXrPiTGC4ey7Uk1NkDgAOlI+g To: , , Cc: , X-OriginalArrivalTime: 05 Jun 2002 07:59:04.0973 (UTC) FILETIME=[DCC28BD0:01C20C66] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18770 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit We have to separate dialogs from sessions. To my mind, we are talking about Session Timer, not dialog timer. Requests like SUBSCRIBE/NOTIFY can appear within a dialog but should not affect the "session" timer. UPDATE updates a session, not a dialog. /Hisham > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, June 05, 2002 3:44 AM > To: 'Padhye, Chinmay'; sip@ietf.org > Cc: 'David R. Oran'; 'Jonathan Rosenberg' > Subject: RE: [Sip] updating session timer > > > > I think I agree with Chinmay here. One of the big beefs with > session-timer is the number of additional messages required > (INVITE-OK-ACK) just to refresh it. If every request-response on the > dialog resets the count-down timer, then we have very little > overhead. > > -- > Dean > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Padhye, Chinmay > > Sent: Tuesday, June 04, 2002 4:06 PM > > To: sip@ietf.org > > Cc: 'David R. Oran'; Jonathan Rosenberg > > Subject: RE: [Sip] updating session timer > > > > > > Hello, > > > > I feel any method sent/received on an existing dialog > > should reset the session timer for that dialog. > > > > Its OK for UPDATE to change the session timer related > > roles, timer values, etc. > > > > Regards, > > > > Chinmay > > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Tuesday, June 04, 2002 1:36 PM > > To: Jonathan Rosenberg; sip@ietf.org > > Subject: Re: [Sip] updating session timer > > > > > > It certainly makes sense to have UPDATE refresh the session > > timer. Other > > than that I don't see much benefit in tweaking the design, > > unless we just > > want to say that any method refreshes the timer. That makes > the spec > > future-proof for new methods, which might be a good thing, or > > a bad thing > > depending on some clairvoyance I don't have. > > > > I vote for the minimal disruption: add UPDATE as a method > > which refreshes > > the timer and leave the rest alone. > > > > Dave. > > > > --On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg > > wrote: > > > > > Folks, > > > > > > I am in the process of doing an update to session timer. > This draft > > > got "shelved" while we were finishing up bis and the rest > > of the pile > > > of drafts for 3gpp. As such, its being updated to now > reference bis > > > rather than rfc2543. One of the things I am doing in this > > process is > > > assessing whether anything new impacts design decisions we > > made in the > > > original draft. > > > > > > One of the things we assumed in session timer was that > all session > > > refreshes were with re-invite. The principal reason for > > that was that > > > we wanted the refreshes to have a soft-state property, so that a > > > refresh could itself cause the recovery of call and session > > state at a > > > failed-and-rebooted UA (or a backup). > > > > > > The notion of such soft-state recovery of sessions was > > something that > > > we discussed at length for bis (bug #207), and ultimately > > decided not > > > to go with. In the case of bis, the particular issue was > > that if you > > > have a media stream failure, should you send a re-INVITE in > > order to > > > re-establish the call with a backup? This would allow > > relatively fast > > > recovery. However, we didn't do this because it had > > numerous problems, > > > which I won't repeat. There was also limited interest in such > > > recovery. Now, the point of this is that we discarded support for > > > rapid recovery of call state and sessions from bis. Session timer > > > would provide much slower recovery, arguably, so slow as > to not be > > > useful. Since we already discarded the much-more-useful approach, > > > there seems little value in supporting the much-less-useful > > approach. > > > > > > Another thing that has changed with bis is the existence > of another > > > method which is a pretty reasonable mechanism for refreshing the > > > session timer - UPDATE. An UPDATE without an offer at all seems a > > > perfect mechanism for updating a session timer. > > > > > > So, I would propose we re-visit this design decision, and > > at the very > > > least, allow for session timer refreshes to occur in UPDATE > > as well as > > > INVITE. The other alternative is to allow session timer > > refreshes in > > > any method. This would allow normally ocurring SIP messages > > within the > > > dialog (if any) to cause refreshes, and if you had > nothing to send, > > > you would use UPDATE. The overall benefit here is reduced > overhead > > > (2-way exchange with UPDATE instead of three-way with > > INVITE). I see > > > no reason why we shouldn't allow for session timer updates in any > > > method. > > > > > > Another issue possibly worth revisiting is the decision to allow > > > session timer to work as long as only one of the two UA > in a dialog > > > support it. In order to enable that, there is some complex proxy > > > behavior, and generally more complex UA behavior. With more > > experience > > > behind us (although I must say I am not aware of any UA > > > implementations of this draft), do people still believe this is a > > > reasonable assumption? I'm inclined not to change it, since > > I really > > > prefer not to revisit every design decision unless there is good > > > reason (i.e., bis has changed an assumption). > > > > > > Comments welcome. > > > > > > Thanks, > > > Jonathan R. > > > > > > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PH: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > ----------------------------------------------------------- > > David R. Oran Phone/Fax: +1 978 264 2048 > > Cisco Systems VoIP: +1 408 571 4576 > > 7 Ladyslipper Lane Email: oran@cisco.com > > Acton, MA 01720 > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 05:35:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24475 for ; Wed, 5 Jun 2002 05:35:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23743 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 05:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22485; Wed, 5 Jun 2002 05:14:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22453 for ; Wed, 5 Jun 2002 05:14:13 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24206 for ; Wed, 5 Jun 2002 05:13:42 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA23175; Wed, 5 Jun 2002 11:14:09 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA24325; Wed, 5 Jun 2002 11:14:11 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 11:14:12 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DF3@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: sip@ietf.org Subject: [SIP] draft-garcia-sip-visited-network-id-03 Date: Wed, 5 Jun 2002 11:14:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Some comments on the latest version of the draft: - Throughout the draft, it is stated that the network identification takes the form of a quoted text string. But the ABNF in Section 4 shows that it can also be a token. - This is a repeated comment: Section 4, the paragraph after the example "a SIP proxy may insert a new P-Visited-Network-ID header if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier". However, Table 2 of SIP shows that proxy cannot "r"ead the header. You explained in your email that the header may be encrypted and so cannot be read, but that is not clear to the readers of the draft. - Section 4, 2nd paragraph after the example: "a proxy in a visited network that does not maintain registration state MAY insert a P-Visited-Network_ID header into any standalone request outside a dialog or a request that create a dialog". This is the only place where the requirement that the proxy 'does not maintain registration state' is mentioned. If this is a requirement, it should be mentioned and explained in Section 5.2 - The last sentence of the same paragraph: "At the time of writing this document, the only requests that create dialogs are INVITE and SUBSCRIBE". In fact, [9] states that "REFERs occurring outside an existing dialog effectively create a new dialog". - The term 'a standalone request outside a dialog' should be avoided. Instead of repeating 'in a REGISTER request, a standalone request outside a dialog (e.g., MESSAGE), or a request that initiates a dialog', can't we just refer to them as 'the requests indicated in Table 2' ? - Why is the OPTIONS requested excluded ? Is it not a standalone request outside a dialog? - As OPTIONS requests do not carry this header, it is possible that an OPTIONS request used to determine whether the UAS will accept an INVITE request gets positive response but an identical INVITE gets rejected due to failure in authorization of the INVITE based on the contents of the P-Visited-Network-ID. Is this not in violation of RFC 3261? 11.2 of RFC 3261 Processing of OPTIONS request states that "The response code chosen MUST be the same that would have been chosen had the request been an INVITE". - Section 5.2 The closing bracket ")" after MESSAGE[8] is missing. - The last paragraph of 5.2 "A home proxy MUST delete this header when forwarding the message outside the home network domain...". Does this include forwarding the request to a user who is within the home network? - In the References section, it is better to name just the authors and title of the drafts, not the file names including the version numbers. Otherwise, [9] would have to be updated to version 5. Thanks, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 06:35:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25218 for ; Wed, 5 Jun 2002 06:35:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26796 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 06:35:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24926; Wed, 5 Jun 2002 06:04:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24894 for ; Wed, 5 Jun 2002 06:04:42 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24772 for ; Wed, 5 Jun 2002 06:04:12 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA27341; Wed, 5 Jun 2002 12:04:40 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA08795; Wed, 5 Jun 2002 12:04:36 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 12:04:27 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DF4@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Miguel A. Garcia'" Cc: "'sip@ietf.org'" Subject: [SIP] draft-garcia-sip-called-party-id-03 Date: Wed, 5 Jun 2002 12:04:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Just a couple comments : - 2nd paragraph of Section 4 : "Typically, a SIP proxy, inserts the P-Called-Party-ID header field when it retargets the user by replacing the Request-URI with the address-of-record." The proxy retargets the request by replacing the Request-URI with the contact address, not the address-of-record. "The P-Called-Party-ID header value is populated with the contents of the Request-URI in the INVITE, any other method that initiates a dialog or any other standalone request outside a dialog (such as MESSAGE [8])." may be re-phrased as : The P-Called-Party-ID header value is populated with the original contents of the Request-URI of the request. - The draft only talks about proxy inserting the P-Called-Party-ID. In Table 2 of SIP, it indicates "amr" under proxy. When does a proxy modify this header ? Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 06:36:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25241 for ; Wed, 5 Jun 2002 06:36:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26816 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 06:36:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25755; Wed, 5 Jun 2002 06:23:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25724 for ; Wed, 5 Jun 2002 06:23:46 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24975 for ; Wed, 5 Jun 2002 06:23:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g55ANh6n014862; Wed, 5 Jun 2002 12:23:43 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g55ANha9022220; Wed, 5 Jun 2002 13:23:43 +0300 (EET DST) Message-ID: <3CFDE6AF.878D9B1F@ericsson.com> Date: Wed, 05 Jun 2002 13:23:43 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: sip@ietf.org Subject: Re: [SIP] draft-garcia-sip-visited-network-id-03 References: <5B4D0C5BA65ECA46969C1419122317E6E74DF3@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ya-Ching: Thanks for your comments. See my answer below. Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Hi, > > Some comments on the latest version of the draft: > > - Throughout the draft, it is stated that the network > identification takes the form of a quoted text string. > But the ABNF in Section 4 shows that it can also be > a token. Fixed throught the document. > - This is a repeated comment: > Section 4, the paragraph after the example > "a SIP proxy may insert a new P-Visited-Network-ID header > if the request does not contain a P-Visited-Network-ID > header with the same network identifier as its own network > identifier". > However, Table 2 of SIP shows that proxy cannot "r"ead > the header. You explained in your email that the header may > be encrypted and so cannot be read, but that is not clear to > the readers of the draft. I am adding this new paragraph to explain thesituation: Note also that, there is not requirement for the header to be readable in the proxies. Therefore, a first proxy may insert an encrypted header that only the registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) located in the same administrative domain as the first proxy, the second proxy will not be able to read the contents of the P-Visited-Network-ID header. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header value (hopefully with the same visited network identifier). When the request arrives at the registrar, it will notice that the header value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registra! r. > > - Section 4, 2nd paragraph after the example: > "a proxy in a visited network that does not maintain > registration state MAY insert a P-Visited-Network_ID > header into any standalone request outside a dialog or > a request that create a dialog". > This is the only place where the requirement that the > proxy 'does not maintain registration state' is mentioned. > If this is a requirement, it should be mentioned and > explained in Section 5.2 Well, this is not a requirement. You forgot to include the first to words of the sentence: "For instance, ". This means that it is only an example, where a proxy that does not keep any registration state is inserting the header in an INVITE. What I have done is to replace the MAY with a "may", as it is just an example. > > - The last sentence of the same paragraph: > "At the time of writing this document, the only requests > that create dialogs are INVITE and SUBSCRIBE". In fact, > [9] states that "REFERs occurring outside an existing > dialog effectively create a new dialog". Good point. I'll fix it. > > - The term 'a standalone request outside a dialog' should > be avoided. Instead of repeating 'in a REGISTER request, > a standalone request outside a dialog (e.g., MESSAGE), > or a request that initiates a dialog', can't we just refer to > them as 'the requests indicated in Table 2' ? But you will agree with me that I can't do this change until the table is introduce. That leaves only one place to change, in section 5.2. > > - Why is the OPTIONS requested excluded ? Is it not a > standalone request outside a dialog? I fixed it. > > - As OPTIONS requests do not carry this header, it is > possible that an OPTIONS request used to determine > whether the UAS will accept an INVITE request gets > positive response but an identical INVITE gets rejected > due to failure in authorization of the INVITE based on > the contents of the P-Visited-Network-ID. Is this not in > violation of RFC 3261? 11.2 of RFC 3261 Processing > of OPTIONS request states that "The response code > chosen MUST be the same that would have been > chosen had the request been an INVITE". So, allowing the header in an OPTINS will solve the problem. As I said, it was a typo and now it is fixed. > > - Section 5.2 > The closing bracket ")" after MESSAGE[8] is missing. Now it is gone with a reference to the table. > - The last paragraph of 5.2 > "A home proxy MUST delete this header when > forwarding the message outside the home network > domain...". Does this include forwarding the request > to a user who is within the home network? I added this text: A home proxy SHOULD delete this header, even when the request is not forwarded outside the home network administrative domain, when the home proxy has used the contents of the header or the request is routed based on the called party. > > - In the References section, it is better to name just > the authors and title of the drafts, not the file names > including the version numbers. Otherwise, [9] would > have to be updated to version 5. It is updated to version 5. I prefer, though, to name the file names, in order to facilitate the search. Thanks a lot for your comments. Keep tuned to -04 that will include your comments. /Miguel > > Thanks, > Ya-Ching -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 06:42:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25384 for ; Wed, 5 Jun 2002 06:42:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27022 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 06:43:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25691; Wed, 5 Jun 2002 06:22:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25660 for ; Wed, 5 Jun 2002 06:22:03 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24965 for ; Wed, 5 Jun 2002 06:21:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g55AIiss017878 for ; Wed, 5 Jun 2002 06:18:44 -0400 (EDT) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MGV3N5KG; Wed, 5 Jun 2002 06:21:27 -0400 Message-ID: <3CFDE627.6080300@dynamicsoft.com> Date: Wed, 05 Jun 2002 06:21:27 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] updating session timer References: <3CFD1254.DF6989CB@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I always thought that in addition to INVITE/UPDATE we should have had a "side-effect free" mechanism for refreshing timers; some request method whose response cannot change media characteristics. Allowing any request to refresh timers should do the trick, so I'm for that one. Anders Jonathan Rosenberg wrote: > Folks, > > I am in the process of doing an update to session timer. This draft got > "shelved" while we were finishing up bis and the rest of the pile of > drafts for 3gpp. As such, its being updated to now reference bis rather > than rfc2543. One of the things I am doing in this process is assessing > whether anything new impacts design decisions we made in the original > draft. > > One of the things we assumed in session timer was that all session > refreshes were with re-invite. The principal reason for that was that we > wanted the refreshes to have a soft-state property, so that a refresh > could itself cause the recovery of call and session state at a > failed-and-rebooted UA (or a backup). > > The notion of such soft-state recovery of sessions was something that we > discussed at length for bis (bug #207), and ultimately decided not to go > with. In the case of bis, the particular issue was that if you have a > media stream failure, should you send a re-INVITE in order to > re-establish the call with a backup? This would allow relatively fast > recovery. However, we didn't do this because it had numerous problems, > which I won't repeat. There was also limited interest in such recovery. > Now, the point of this is that we discarded support for rapid recovery > of call state and sessions from bis. Session timer would provide much > slower recovery, arguably, so slow as to not be useful. Since we already > discarded the much-more-useful approach, there seems little value in > supporting the much-less-useful approach. > > Another thing that has changed with bis is the existence of another > method which is a pretty reasonable mechanism for refreshing the session > timer - UPDATE. An UPDATE without an offer at all seems a perfect > mechanism for updating a session timer. > > So, I would propose we re-visit this design decision, and at the very > least, allow for session timer refreshes to occur in UPDATE as well as > INVITE. The other alternative is to allow session timer refreshes in any > method. This would allow normally ocurring SIP messages within the > dialog (if any) to cause refreshes, and if you had nothing to send, you > would use UPDATE. The overall benefit here is reduced overhead (2-way > exchange with UPDATE instead of three-way with INVITE). I see no reason > why we shouldn't allow for session timer updates in any method. > > Another issue possibly worth revisiting is the decision to allow session > timer to work as long as only one of the two UA in a dialog support it. > In order to enable that, there is some complex proxy behavior, and > generally more complex UA behavior. With more experience behind us > (although I must say I am not aware of any UA implementations of this > draft), do people still believe this is a reasonable assumption? I'm > inclined not to change it, since I really prefer not to revisit every > design decision unless there is good reason (i.e., bis has changed an > assumption). > > Comments welcome. > > 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 daemon@optimus.ietf.org Wed Jun 5 06:50:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25541 for ; Wed, 5 Jun 2002 06:50:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27253 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 06:50:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26548; Wed, 5 Jun 2002 06:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26517 for ; Wed, 5 Jun 2002 06:32:25 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25137 for ; Wed, 5 Jun 2002 06:31:55 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g55AWNmG012835; Wed, 5 Jun 2002 12:32:23 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g55AWMa9022835; Wed, 5 Jun 2002 13:32:22 +0300 (EET DST) Message-ID: <3CFDE8B6.CFB0E496@ericsson.com> Date: Wed, 05 Jun 2002 13:32:22 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'sip@ietf.org'" Subject: Re: [SIP] draft-garcia-sip-called-party-id-03 References: <5B4D0C5BA65ECA46969C1419122317E6E74DF4@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ya-Ching. See my answers below. Tan Ya-Ching ICM N PG U ID A 1 wrote: > > Just a couple comments : > > - 2nd paragraph of Section 4 : > "Typically, a SIP proxy, inserts the P-Called-Party-ID header > field when it retargets the user by replacing the Request-URI > with the address-of-record." > The proxy retargets the request by replacing the Request-URI > with the contact address, not the address-of-record. Certainly. Fixed. > > "The P-Called-Party-ID header value is populated with the > contents of the Request-URI in the INVITE, any other method > that initiates a dialog or any other standalone request outside a > dialog (such as MESSAGE [8])." > may be re-phrased as : > The P-Called-Party-ID header value is populated with the > original contents of the Request-URI of the request. Ok. > > - The draft only talks about proxy inserting the P-Called-Party-ID. > In Table 2 of SIP, it indicates "amr" under proxy. When does a > proxy modify this header ? > To be honest with you, I can't see any situation where a proxy will need to modify the contents of the header. So I will delete the "m". All this comments will be included in -04. Thanks a lot for your help. /Miguel > Regards, > Ya-Ching -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 08:27:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27528 for ; Wed, 5 Jun 2002 08:27:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01530 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 08:27:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01094; Wed, 5 Jun 2002 08:10:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01030 for ; Wed, 5 Jun 2002 08:09:54 -0400 (EDT) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27021; Wed, 5 Jun 2002 08:09:23 -0400 (EDT) From: aroychow@hss.hns.com Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g55C8hL06378; Wed, 5 Jun 2002 08:08:43 -0400 (EDT) To: jh@lohi.eng.song.fi Cc: "Dean Willis" , "Roy, Radhika R, ALASO" , sip@ietf.org, sip-admin@ietf.org Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 5 Jun 2002 08:08:49 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.8 |June 18, 2001) at 06/05/2002 08:06:51 AM, Serialize complete at 06/05/2002 08:06:51 AM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Roy, Radhika R, ALASO writes: > [RRR] The architecture for the 3GPP application server environment can > also be applicable in any wire-line network. So, the P-headers defined > for 3GPP may have the wider applicability. juha> i prefer an open internet style architecture instead of the recreation juha> of the closed pstn architecture using ip protocols. Im sure a lot of us would have personal preferences on the right way. Right now the industry is struggling to figure out how to make money out of SIP - which is a more realistic step towards making SIP successful than asserting that sip is a great internet-style-peer-peer-protocol. Therefore no matter how 'pstn like' 3g in architecture (and I see nothing wrong with that - again a personal perspective - the centralized model allows a definitive path to revenue), I would agree that its a good thing. However, I would agree with radhika here: The concept of P-headers is OK to me - but as mentioned, we _dont_ have to tie it to 3G. P-headers may be viable in 3G as well as other networks as well - thefore , the scope of P- headers would be for 'networks with certain mandatory properties'. If 3G falls into it, fine. If some other networks fall into it - fine as well - it was not meant only for 3G anyway. regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-475-2139 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 5 09:25:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29779 for ; Wed, 5 Jun 2002 09:25:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05073 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 09:25:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04267; Wed, 5 Jun 2002 09:09:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04237 for ; Wed, 5 Jun 2002 09:09:51 -0400 (EDT) Received: from stingray.shentel.net (stingray.shentel.net [204.111.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29033 for ; Wed, 5 Jun 2002 09:09:20 -0400 (EDT) Received: from steves (ha96s220.d.shentel.net [204.111.96.220]) by stingray.shentel.net (8.11.3/8.11.3) with SMTP id g55D9JD28028 for ; Wed, 5 Jun 2002 09:09:19 -0400 From: "Steve Silverman" To: Date: Wed, 5 Jun 2002 09:10:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] P-headers and 3GPP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I thought the purpose of P-headers (as opposed to regular headers) was to mark them as private, not general use (sort of experimental). Why would one use a P-header for something as general as called-party ID (or Asserted ID)? If this is to be used in 3G, I would think it would be fairly commonplace (hopefully) rather than experimental. Steve Silverman Houston Associates _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 10:57:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02816 for ; Wed, 5 Jun 2002 10:57:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10560 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 10:57:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09725; Wed, 5 Jun 2002 10:36:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09694 for ; Wed, 5 Jun 2002 10:36:32 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02437 for ; Wed, 5 Jun 2002 10:36:00 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g55Ea0PI015352; Wed, 5 Jun 2002 07:36:00 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABU51624; Wed, 5 Jun 2002 07:33:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09065; Wed, 5 Jun 2002 07:35:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15614.8655.283071.193100@thomasm-u1.cisco.com> Date: Wed, 5 Jun 2002 07:35:59 -0700 (PDT) To: "Cullen Jennings" Cc: Subject: [Sip] Asserted-Identity - new hint proposal In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So, I still haven't heard why the role based assertions is better than the alternative of identity based assertions. The way it's structured now, you seemingly either lose information along the way, or have an ambiguous situtation with multiple P-Asserted-Identity's. Suppose for example that my real name is thomasm, but I want to use my alias mat. What I'd do is: Asserted-Identity: ; asserted-by: ;etc At my first hop proxy, it would check to see if mat@cisco.com was an acceptible alias, and if it is, it would add a new AI to vouch for me: Asserted-Identity: ; asserted-by: When it's forwarded to the UAS proxy, it would know that it trusts proxy-15's assertions (but not thomasm's) and therefore add a new header for the UAS: Asserted-Identity: ; asserted-by: So clear back at luser.mtcc.com we finally get the INVITE and see these asserted-identities: Asserted-Identity: ; asserted-by: ;etc Asserted-Identity: ; asserted-by: Asserted-Identity: ; asserted-by: The UAS cdr's through the list and discovers -- aha! -- an asserted identity by proxy-22@mtcc.com which it trusts since it's the inbound proxy. Therefore, luser.mtcc.com knows that the identity it will use for the callerid is the one supplied by proxy-22. If proxy-22 didn't insert an asserted-identity, it probably means that it didn't trust the previous hop, and that the UAS should mark the callerid as suspect, if it displays anything at all. Notice that we don't need "roles" here of UA and proxy, but instead uses their actual identities. Note also that this could be generally applicable for more cases where you need to assert identity such as the firewall-proxy traversal case especially if it were combined with cryptographic proof by the party asserting the identity. It would also allow flexibility of _who_ enables traversal as well, ie that one of my proxies could insert the necessary credentials to get me through a foreign proxy instead of the UAC directly which would enable aggregation, and separation. Mike Cullen Jennings writes: > > I am getting the feeling that people want to put the hint in a separate > header. How would everyone feel about something along the lines of: > > P-Suggested-Identity: "Cullen Jennings" ;mandatory > > The UAC would insert this header to indicate the Asserted-Identity that it > wished the Trust Domain to choose. The "mandatory" indicates that the Trust > Domain MUST return some 4xx response if it is not going to assert this > identity. If the "mandatory" was not present, it would not return an 4xx if > it choose a different identity to assert for the user. > > Should we go with two headers (PSI and PAI)? > > Does PSI need some flag (like mandatory) to say how it is handled in the > case the suggested identity is not going to be provided? > > Alternatively, should we go with one header and the argument that Dean so > nicely summed up as > > I think existence of a P-A-I header in a message means "a previous hop > > (sender or proxy) has asserted this identity. Deal with it." > > > > Options for dealing with it are: > > > > 1) Believe it > > 2) Delete it (in conjunction with "privacy" modifier) > > 3) Delete it and assert a different identity > > 4) Reject the message > > 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 daemon@ns.ietf.org Wed Jun 5 12:08:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04831 for ; Wed, 5 Jun 2002 12:08:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16547 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 12:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13879; Wed, 5 Jun 2002 11:41:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13848 for ; Wed, 5 Jun 2002 11:41:35 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03973 for ; Wed, 5 Jun 2002 11:41:04 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GX800601OV152@firewall.wcom.com> for sip@ietf.org; Wed, 5 Jun 2002 15:40:14 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GX80054UOV0NO@firewall.wcom.com>; Wed, 05 Jun 2002 15:40:13 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GX800001OUVK8@dgismtp01.wcomnet.com>; Wed, 05 Jun 2002 15:40:12 +0000 (GMT) Received: from hsinnreich2 ([166.42.41.148]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GX800KGLOUIVN@dgismtp01.wcomnet.com>; Wed, 05 Jun 2002 15:39:55 +0000 (GMT) Date: Wed, 05 Jun 2002 10:39:54 -0500 From: Henry Sinnreich Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) In-reply-to: <15613.40815.46524.976723@harjus.eng.song.fi> To: jh@lohi.eng.song.fi, "'Roy, Radhika R, ALASO'" Cc: "'Dean Willis'" , sip@ietf.org Message-id: <000001c20ca7$3ddef990$94292aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha writes: > i prefer an open internet style architecture instead of the > recreation of the closed pstn architecture using ip protocols. 100% agreement. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of jh@lohi.eng.song.fi > Sent: Wednesday, June 05, 2002 12:20 AM > To: Roy, Radhika R, ALASO > Cc: Dean Willis; sip@ietf.org > Subject: RE: SIP Change Process (was RE: [Sip] > Asserted-Identity: How to 'hint'?) > > > Roy, Radhika R, ALASO writes: > > > [RRR] The architecture for the 3GPP application server > environment can > also be applicable in any wire-line > network. So, the P-headers defined > for 3GPP may have the > wider applicability. > > i prefer an open internet style architecture instead of the > recreation of the closed pstn architecture using ip protocols. > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 12:32:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05681 for ; Wed, 5 Jun 2002 12:32:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18192 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 12:32:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16593; Wed, 5 Jun 2002 12:08:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16561 for ; Wed, 5 Jun 2002 12:08:52 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04846 for ; Wed, 5 Jun 2002 12:08:19 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id RAA08560; Wed, 5 Jun 2002 17:08:16 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Wed, 05 Jun 2002 17:08:08 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 05 Jun 2002 17:08:24 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jun 2002 17:08:24 +0100 Message-Id: To: jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt Date: Wed, 5 Jun 2002 17:08:16 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mailguard1 id CJ333AA0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA16562 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Jonathan, Thanks for your expert comments. I return a few comments below... Duncan -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 29 May 2002 22:04 To: sip@ietf.org Subject: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt Comments on this draft: The title needs to have the acronym SIP expanded. [Duncan] Yep- it will from now on read, "Private Session Initiation Protocol Extension for Access Network Information" [/Duncan] The abstract reads oddly; it seems like a sentence has been misplaced: > 1. Abstract > This mechanism is useful in SIP networks that provide layer 2/layer > 3 connectivity through different access technologies. SIP User > Agents > This document defines the private SIP extension header P-Access- > Network-Info. may use this header to relay information about the > access technology to serving proxies in their home network. I think "SIP User Agents" needs to be moved before "may use this header" [Duncan] How did that happen? ;-) I've corrected this. [/Duncan] The applicability statement is not quite right. It needs to capture the specific assumptions and scenarios which limit the scope of this draft. I would propose something like the following: "This draft is appropriate in environments where SIP services are dependent on a SIP elements knowing details about the IP and lower layer technologies used by a UA to connect to the SIP network. Specifically, the extension requires that the UA know the access technology it is using, and that a proxy desires such information to provide services. Generally, SIP is built on the "Everything over IP and IP over Everything" principle, where the access technology is not relevant for the operation of SIP. Since SIP systems generally should not care or even know about the access technology, this draft is not for general SIP usage. The information revealed in the P-Access-Network-Info header is potentially very sensitive. Proper protection of this information depends on the existence of specific business and security relationships amongst the proxies that will see messages containing this header. It also depends on explicit knowledge of the UA on the existence of those relationships. Thefefore, this mechanism is only appropriate in environments where the appropriate relationships are in place, and the UA has explicit knowledge that they exist." [Duncan] I'm perfectly happy to use this wording [/Duncan] > Other examples include a laptop connected to a > wireless LAN at an airport, or a laptop connected to a local ISP > from a hotel room. I have to agree with Bob's assessment that the appropriate business relationships will not be in place between the proxy at the airport and the proxy in my home network. Therefore, this example is really not appropriate. [Duncan] It's deleted. [/Duncan] > For instance, > the type of access being used may influence home network decisions > on what level of security to apply to sessions. I don't see what the access network has to do with session level security (or what proxies have to do with session level security). [Duncan] Just that where the access network is a GPRS network provided by OpCo1 and the 3GPP IMS (SIP) network is also provided by OpCo1, then an operator may decide that the level of security applied to the application layer needs to be either lower (GPRS provides security) or higher (If there's a wireless link involved, let's be more careful. [/Duncan] > It may be desired that the home network have the knowledge of some > information relating to the network that provided access to the > service. This sentence is awkward, I suggest rewording to "The home network may desire knowledge about the access network." [Duncan] Done. [/Duncan] The introduction and overview aren't really different. I would suggest moving the overview into the introduction, and have a separate "Overview of Operations" section which overviews the basic operation of the extension. That section is fairly short, since the extension is simple. Something like: --- Overview of Operation This section provides an overview of the operation of this extension, and is not normative in nature. When a user agent generates a SIP request which it knows is going to be securely sent to its home network, it inserts a P-Access-Network-Info header into the request. This header contains information on the access network that the UA is using to get IP connectivity. The header is ignored by intermediate proxies between the UA and the home proxy. The home proxy can inspect the header and make use of the information contained there to provide services. Before proxying the request onwards, the home proxy strips the header from the request. --- [Duncan] Done. [/Duncan] > The P-Access-Network-Info header MAY be inserted by a UA. Proxies, > MUST NOT add to or modify the contents of the P-Access-Network-Info. This text appears in the section that describes teh syntax and values of the P-header. Generally (as we learned with bis), its better to place normative behavior in one place. Therefore, I suggest you move any normative behavior like this into section 8. Section 7 should remain nothing more than a description of the syntax of the header and the meaning of the various parameters. [Duncan] Done. [/Duncan] > The proxy in the home network may act upon any information in the P- > Access-Network-Info header if it is present, to provide a different > service depending on the network through which the UA is accessing > the server. For example, for cellular radio access networks the home > network may use the cell ID to provide basic localised services. > > A proxy in the home network MUST delete the header before forwarding > the message outside of its own administrative network domain or > outside a trusted administrative network domain. this text belongs in 8.2. [Duncan] Done. [/Duncan] > Some systems may require that the P-Access-Network-Info header is > only sent by the UAC when a secure connection to the proxy in the > home network is present. For example, in 3GPP systems, the UAC MUST > NOT send this header in the initial unauthenticated REGISTER > request. this text belongs in 8.1. [Duncan] Done. [/Duncan] > A UAC supporting this extension may be capable of accessing the > services provided by its home network via one or more access > technologies. This sentence sort of states the obvious. Obviously the UAC is capable of accessing the SIP network through some access technology. [Duncan] Deleted. [/Duncan] > Such a UAC must know the values to use for each type > of supported access technology. The means of this determination are > outside the scope of this document. this belongs in section 8.1. [Duncan] Done. [/Duncan] > The home network must know the possible values that a particular UA > may use to populate the access-type and access-info fields. > > In other words, a home network with business agreements allowing > users to access via a particular technology must be able to parse > the P-Access-Network-Info header containing an access-type for that > technology in order to use this information. > > For example, the access-type could read "IEEE-802.11b". If a home > network knows it has a business agreement with a W-LAN access > network, it must be ready to understand the value "IEEE-802.11b". > Similarly, a UAC supporting this extension that can access via W-LAN > must be able to insert the relevant value. This text confuses me, since it tries to belabor an obvious point - that the proxy must know how to parse these values. Maybe I am missing something. Perhaps this is related to the fact that no definition is provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't just provide a definition for those and then delete the statements above. [Duncan] The definition for the cell-id is just that it is a string of hex. It is defined already in 3GPP specifications. I agree the current text in my draft is probably not adding much. I can't reference 3GPP specifications though, right? I wanted to describe it in this draft, as "You can put anything you want in here as a 'string'." "3GPP mobiles will be limited by 3GPP specifications as to what they can put in there." [/Duncan] > A UAC that supports this extension and is willing to disclose the > related parameters MAY insert the P-Access-Network-Info header in > any SIP message request. You probably need to provide some guidance on when it ought to be doing that. I have a suspicion that you do have specific requirements (like, every request in order to keep cell-id up to date). [Duncan] Agreed. [/Duncan] > This document does not define either the nature of the information > or the messages where the P-Access-Network-Info needs to be > inserted. This is confusing; it does define the nature of the information. What am I missing? [Duncan] OK, bad wording again. What I mean is that this document only provides *some* values to put in the 'access-type' and 'access-info' fields. There's the chance for other people to define their own tokens etc. The nature of the information is not meant to be restricted to providing the cell ID (that's how 3GPP may use this extension, yes, but another system may want to say 'Airport Lounge' in the access-info field). That's waht I meant to say, but I agree, I need to re-word it. [/Duncan] > A proxy, typically located in the home network, and therefore > trusted, MUST delete the header when the SIP signaling is forwarded > to a SIP server located in a non-trusted administrative network > domain. The access network information is used by a home network and > is of no interest to the destination > network. What about a trusted administrative network domain? I think that the home proxy MUST strip this in all cases. [Duncan] Well, a home proxy may wish to leave the header in and forward the message to an Application Server. As long as this is all in the home trusted domain, then it's okay? [/Duncan] > This extension assumes that the access network is trusted by the UA > (because the UAÆs home network has a trust relationship with the > access network), as described in section 7. The trust relationship is not between the access network and the home network. The assumption is that there is a trust relationship between the UA and the proxy it sends the request to, and then between all proxies between the outbound proxy and the home proxy. [Duncan] OK. [/Duncan] > The home network uses the information contained in this header to > provide additional services and This sentence ends mid-stream. [Duncan] Ooops. [/Duncan] > UAs are expected to provide correct information. However, there are > no security problems resulting from a UAC inserting incorrect > information. Well, I doubt that is true in the case of cell-id. Providing false location information can be used for all sorts of bad things. [Duncan] A rogue user or rogue implementation putting false cell-ID information in this header means that the user doesn't get the correct address for the nearest Pizza Restaurant, or doesn't get to their voicemail from abroad. It would be a nasty fault, but is it really that much of a security problem? [/Duncan] Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The SIP Access Network Info header > Author(s) : D. Mills > Filename : draft-mills-sip-access-network-info-02.txt > Pages : 8 > Date : 28-May-02 > > This mechanism is useful in SIP networks that provide layer 2/layer > 3 connectivity through different access technologies. SIP User > Agents > This document defines the private SIP extension header P-Access- > Network-Info. may use this header to relay information about the > access technology to serving proxies in their home network. The > serving proxy may then use this information to optimize services for > the UA. For example, a 3GPP terminal uses this header to pass > information about the access network such as radio access technology > and cell ID to its home service. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info- > 02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mills-sip-access-network-info-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-mills-sip-access-network-info-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > Subject: > Date: Wed, 29 May 2002 10:32:52 -0400 > > ------------------------------------------------------------------------ > > ATT38948.txtName: ATT38948.txt > Type: Plain Text (text/plain) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 12:47:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06194 for ; Wed, 5 Jun 2002 12:47:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18727 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 12:47:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17087; Wed, 5 Jun 2002 12:23:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17056 for ; Wed, 5 Jun 2002 12:23:10 -0400 (EDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05358 for ; Wed, 5 Jun 2002 12:22:38 -0400 (EDT) Received: from sdn-ap-004neomahp0639.dialsprint.net ([63.186.34.131] helo=LTMAM1781) by maynard.mail.mindspring.net with smtp (Exim 3.33 #1) id 17FdYq-00012A-00; Wed, 05 Jun 2002 12:23:01 -0400 Message-ID: <000401c20cad$43101c40$293212ac@mcdata.com> Reply-To: "Michel A. Maddux" From: "Michel A. Maddux" To: "Jonathan Rosenberg" , "Ashhar Farhan" Cc: References: <20011226133303.16872.qmail@mailweb9.rediffmail.com> <3C2A486A.4010708@dynamicsoft.com> Date: Wed, 5 Jun 2002 10:22:50 -0600 Organization: Flatpickers Anonymous MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Experienced engineer seeking employment developing software applications for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Greetings: Please forgive this note; I am seeking employment developing Internet Telephony applications. If anyone is interested in seeing a resume please reply. thanks /m. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 12:59:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06820 for ; Wed, 5 Jun 2002 12:59:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19298 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 13:00:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18365; Wed, 5 Jun 2002 12:35:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18332 for ; Wed, 5 Jun 2002 12:35:49 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05754 for ; Wed, 5 Jun 2002 12:35:19 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA28196; Wed, 5 Jun 2002 18:35:44 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA13586; Wed, 5 Jun 2002 18:35:46 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 18:35:48 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DF7@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Dean Willis'" Cc: sip@ietf.org Subject: RE: [Sip] Draft-willis-sip-path revised to -08 Date: Wed, 5 Jun 2002 18:35:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Dean, Some REALLY final comments: - Section 3 third paragraph "... whereas the vector established by Path applies to future dialogs" is not very correct. It only applies to future requests outside of a dialog - requests that are addressed to the AOR of the user, to be precise. Requests within future dialogs are still bound to the vector established by Record-Route mechanism. - Section 4.1 second paragraph "The UA ... should include a Supported header field in all requests." I think you mean "all REGISTER requests". I don't see the Supported header in the INVITE in your example. A few nits: - Section 4.2 last paragraph "alterany" => "alter any" - Section 4.3 "addres-of-record" => "address-of-record" - Section 5.1 last paragraph "...such as request..." => "such a request" Regards, Ya-Ching | -----Original Message----- | From: Dean Willis [mailto:dwillis@dynamicsoft.com] | Sent: 30 May 2002 02:54 | | Bernie and I just released what we hope is the REALLY final version of | the Path draft. This includes all feedback (mostly nits) so far from | IETF Last Call. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 15:29:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14274 for ; Wed, 5 Jun 2002 15:29:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26313 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 15:30:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25081; Wed, 5 Jun 2002 15:00:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25015 for ; Wed, 5 Jun 2002 15:00:12 -0400 (EDT) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12684 for ; Wed, 5 Jun 2002 14:59:41 -0400 (EDT) Message-ID: <20020605190010.11991.qmail@web11606.mail.yahoo.com> Received: from [207.46.137.9] by web11606.mail.yahoo.com via HTTP; Wed, 05 Jun 2002 12:00:10 PDT Date: Wed, 5 Jun 2002 12:00:10 -0700 (PDT) From: Sean Olson To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] UTF-8 in SIP URIs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Just a question for clarification. For escaped characters in a SIP URI, is it assumed that those octects represent a UTF-8 encoded character? Or are other encodings possible? /sean __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 16:53:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19143 for ; Wed, 5 Jun 2002 16:53:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00727 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 16:53:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29211; Wed, 5 Jun 2002 16:25:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29181 for ; Wed, 5 Jun 2002 16:25:12 -0400 (EDT) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17629 for ; Wed, 5 Jun 2002 16:24:40 -0400 (EDT) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g55Jwnrc013373 for ; Wed, 5 Jun 2002 15:24:39 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3CBB497300264C2D; Wed, 5 Jun 2002 16:24:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Wed, 5 Jun 2002 16:24:28 -0400 Message-ID: <62DA45D4963FA747BA1B253E266760F902AB7D75@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Thread-Index: AcIMqNECMuPWmi84Q4SZCTcLmf3CcAAJYYpw From: "Roy, Radhika R, ALASO" To: "Henry Sinnreich" , Cc: "Dean Willis" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA29182 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit inline [RRR] -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Wednesday, June 05, 2002 11:40 AM nt'?) Juha writes: > i prefer an open internet style architecture instead of the > recreation of the closed pstn architecture using ip protocols. 100% agreement. Henry [RRR] Agreed, it should be the long term goal as it is the only way to make the system scalable in the context of the open Internet. > > Roy, Radhika R, ALASO writes: > > > [RRR] The architecture for the 3GPP application server > environment can > also be applicable in any wire-line > network. So, the P-headers defined > for 3GPP may have the > wider applicability. > > i prefer an open internet style architecture instead of the > recreation of the closed pstn architecture using ip protocols. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 17:57:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22219 for ; Wed, 5 Jun 2002 17:57:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04684 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 17:57:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03084; Wed, 5 Jun 2002 17:26:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03056 for ; Wed, 5 Jun 2002 17:26:20 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20672 for ; Wed, 5 Jun 2002 17:25:48 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g55LPmf08677; Wed, 5 Jun 2002 16:25:48 -0500 From: "Dean Willis" To: "'Tan Ya-Ching ICM N PG U ID A 1'" Cc: Subject: RE: [Sip] Draft-willis-sip-path revised to -08 Date: Wed, 5 Jun 2002 16:25:34 -0500 Message-ID: <008c01c20cd7$877bba90$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E6E74DF7@mchh161e> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Tan Ya-Ching ICM N PG U ID A 1 > Sent: Wednesday, June 05, 2002 11:36 AM > To: 'Dean Willis' > Cc: sip@ietf.org > Subject: RE: [Sip] Draft-willis-sip-path revised to -08 > > > Hi Dean, > > Some REALLY final comments: > > - Section 3 third paragraph > "... whereas the vector established by Path applies to future > dialogs" is not very correct. It only applies to future requests > outside of a dialog - requests that are addressed to the AOR > of the user, to be precise. Requests within future dialogs > are still bound to the vector established by Record-Route > mechanism. I had tried to resist the temtation to insert an entire tutorial on SIP request/response riuting methodologies into one sentence, but if you wish to suggest specific text, I'll happily consider it. > - Section 4.1 second paragraph > "The UA ... should include a Supported header field in > all requests." I think you mean "all REGISTER requests". > I don't see the Supported header in the INVITE in your > example. A bug in the example? The way Supported supposedly works, it's "All Requests", or a least "All Requests for which the UA is willing to use this extension". One might argue that this second usage is more reasonable, but it conflicts with the way many people think Supported works. We probably need a consensus call on this point. I think some Bad Things happened with my examples. I started by attempting to use a schematic representation of SIP messages, such that only the Important Things mentioned in the draft would stand out. Then people started insisting on adding more and more detail, until the examples are almost but not quite photorealistic. I believe this approach is a Bad Idea: the actual topic gets obscured behind peculiar intricacies of "just how is it we're formatting messages this week?". > A few nits: > > - Section 4.2 last paragraph > "alterany" => "alter any" > > - Section 4.3 > "addres-of-record" => "address-of-record" > > - Section 5.1 last paragraph > "...such as request..." => "such a request" Excellent observation. Thanks. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 5 21:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04774 for ; Wed, 5 Jun 2002 21:41:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA16785 for sip-archive@odin.ietf.org; Wed, 5 Jun 2002 21:42:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14974; Wed, 5 Jun 2002 21:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14943 for ; Wed, 5 Jun 2002 21:16:01 -0400 (EDT) Received: from omta04.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03214 for ; Wed, 5 Jun 2002 21:15:31 -0400 (EDT) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta04.mta.everyone.net (Postfix) with ESMTP id C9CB9502BF for ; Wed, 5 Jun 2002 18:16:00 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id A4EE236F9; Wed, 5 Jun 2002 18:16:00 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Wed, 5 Jun 2002 18:16:00 -0700 (PDT) From: Kosta Koeman To: sip@ietf.org Reply-To: kkoeman@techemail.com X-Originating-Ip: [207.46.137.9] Message-Id: <20020606011600.A4EE236F9@sitemail.everyone.net> Content-Transfer-Encoding: 7bit Subject: [Sip] Compact forms questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've noted the following list from http://www.iana.org/assignments/sip-parameters that summarizes the compact forms defined for SIP (note: I have removed all header names without a compact form). Allow-Events u [RFCevents] Call-ID i [RFC2543], draft-ietf-sip-rfc2543bis Contact m [RFC2543], draft-ietf-sip-rfc2543bis Content-Encoding e [RFC2543], draft-ietf-sip-rfc2543bis Content-Length l [RFC2543], draft-ietf-sip-rfc2543bis Content-Type c [RFC2543], draft-ietf-sip-rfc2543bis Event o [RFCevent] From f [RFC2543], draft-ietf-sip-rfc2543bis Subject s [RFC2543], draft-ietf-sip-rfc2543bis Supported k draft-ietf-sip-rfc2543bis To t [RFC2543], draft-ietf-sip-rfc2543bis Via v [RFC2543], draft-ietf-sip-rfc2543bis So the compact forms u & o are defined in the SIP-Specific Event Notification draft; i, m, e, l, c, o, f, s, t, & v are defined in the SIP spec/draft. I could not find the exact document where the compact form k was defined (besides the list, of course). What about the compact forms, r (Refer-To) and b (Referred-By), respectively defined in "The Refer Method" draft (draft-ietf-sip-refer-04) and "The Referred-By Mechanism" draft (draft-ietf-sip-referredby-00)? Are these compact forms not included in the list above due to the fact that their respective documents have not been submitted to be published as proposed standards? Since these compact forms have been defined in drafts, are these letters/compact forms reserved for the proposed usage? If not, is it likely that these letters/compact forms will be reserved in the future and included in the list above? I did note that both of these drafts state that the compact forms should be added to the list above. Thanks, Kosta _____________________________________________________________ Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 02:43:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29974 for ; Thu, 6 Jun 2002 02:43:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07621 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 02:43:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06207; Thu, 6 Jun 2002 02:18:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06183 for ; Thu, 6 Jun 2002 02:18:01 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29554 for ; Thu, 6 Jun 2002 02:17:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g566Hx6n002345 for ; Thu, 6 Jun 2002 08:17:59 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g566Hxa9016925 for ; Thu, 6 Jun 2002 09:17:59 +0300 (EET DST) Message-ID: <3CFEFE99.AC7FC26E@lmf.ericsson.se> Date: Thu, 06 Jun 2002 09:18:01 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SDP in 200 with PRACK Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The following has been discussed before, but I haven't found any clarification for it in the bis- or PRACK draft: Chapter 13.2.1 is bis says: "If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." Now, if PRACK is used, the first reliable non-failure message from the UAS may be a 18x provisional response, so the UAS may include an answer in such a message. My question is: does this still require that the answer which was sent in the 18x must also be included in the 200? My understanding is that bis-09 does not say that, only that the answer must be in the first reliable non-failure message (which, for a pure bis-09 implementation happen to be the 200 response). I know there has been talks about backward compability issues etc, but I couldn't find it written anyware. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 03:10:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00374 for ; Thu, 6 Jun 2002 03:10:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09517 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 03:11:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08063; Thu, 6 Jun 2002 02:51:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08032 for ; Thu, 6 Jun 2002 02:51:11 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00100 for ; Thu, 6 Jun 2002 02:50:39 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA11553; Thu, 6 Jun 2002 08:51:06 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA29211; Thu, 6 Jun 2002 08:51:07 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 08:51:08 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DF8@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Dean Willis'" Cc: sip@ietf.org Subject: RE: [Sip] Draft-willis-sip-path revised to -08 Date: Thu, 6 Jun 2002 08:51:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean, | > | > - Section 3 third paragraph | > "... whereas the vector established by Path applies to future | > dialogs" is not very correct. | | I had tried to resist the temtation to insert an entire | tutorial on SIP request/response riuting methodologies | into one sentence, but if you wish to suggest specific text, | I'll happily consider it. My suggestion in one sentence : ...whereas the vector established by Path applies to all future requests addressed to the user outside of a dialog. | > - Section 4.1 second paragraph | > "The UA ... should include a Supported header field in | > all requests." I think you mean "all REGISTER requests". | > I don't see the Supported header in the INVITE in your | > example. | | A bug in the example? The way Supported supposedly works, it's "All | Requests", or a least "All Requests for which the UA is willing to use | this extension". One might argue that this second usage is more | reasonable, but it conflicts with the way many people think Supported | works. We probably need a consensus call on this point. | No bug in the example, it's my fault. The INVITE in your example is sent from UA2, which has nothing to do with UA1 who supports Path. But the original question remains, do we need the Supported:path if UA1 sends requests other than REGISTER? I support your "All requests for which the UA is willing to use this extension". An INVITE from UA1 with Supported:path serves absolutely no purpose when it reaches UA2. - Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 07:48:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08178 for ; Thu, 6 Jun 2002 07:48:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26655 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 07:48:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24234; Thu, 6 Jun 2002 07:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24202 for ; Thu, 6 Jun 2002 07:09:36 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06682 for ; Thu, 6 Jun 2002 07:09:05 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g56B95i00181 for ; Thu, 6 Jun 2002 06:09:05 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g56B94p18852 for ; Thu, 6 Jun 2002 06:09:04 -0500 (CDT) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g56B94E27515 for ; Thu, 6 Jun 2002 07:09:04 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Jun 2002 07:10:14 -0400 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037779@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: sip@ietf.org Date: Thu, 6 Jun 2002 07:09:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] CANCEL in Bis-09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Section 9.1 lines 1448 states that a CANCEL request SHOULD NOT be sent to cancel a request other than INVITE (due to race conditions). Following that lines 1464-1465 state that if no provisional response has been received, the CANCEL request MUST NOT be sent. Since provisional responses are only used with INVITES, it looks like the strength on line 1448 needs to be changed to MUST NOT fo consistency. Rgds/ George Foti Ericsson Research Canada _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 07:56:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08548 for ; Thu, 6 Jun 2002 07:56:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27284 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 07:57:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25831; Thu, 6 Jun 2002 07:34:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25796 for ; Thu, 6 Jun 2002 07:34:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07537; Thu, 6 Jun 2002 07:33:36 -0400 (EDT) Message-Id: <200206061133.HAA07537@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Jun 2002 07:33:36 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol (SIP)extension for Associated Uniform Resource Identifiers (URI) Author(s) : M. Garcia Filename : draft-garcia-sip-associated-uri-04.txt Pages : 7 Date : 05-Jun-02 This memo describes a private extension to SIP [1] that allows a registrar to return a set of associated URIs to a registered address- of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request. The P-Associated-URI header field transports the set of Associated URIs to the registered address- of-record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-associated-uri-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-garcia-sip-associated-uri-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-associated-uri-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020605094809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-associated-uri-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-associated-uri-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020605094809.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:01:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08786 for ; Thu, 6 Jun 2002 08:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28126 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:02:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25784; Thu, 6 Jun 2002 07:34:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25750 for ; Thu, 6 Jun 2002 07:34:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07520; Thu, 6 Jun 2002 07:33:25 -0400 (EDT) Message-Id: <200206061133.HAA07520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Jun 2002 07:33:25 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol (SIP) extension for Visited Network Identifier Author(s) : M. Garcia Filename : draft-garcia-sip-visited-network-id-04.txt Pages : 7 Date : 05-Jun-02 This memo describes a private extension to SIP in the form of a P-Visited-Network-ID header. The contents of the header identify each of the visited networks the message traversed en-route to the home network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-visited-network-id-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-garcia-sip-visited-network-id-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-visited-network-id-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020605094759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-visited-network-id-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-visited-network-id-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020605094759.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:01:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08805 for ; Thu, 6 Jun 2002 08:01:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28140 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:02:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25610; Thu, 6 Jun 2002 07:33:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25582 for ; Thu, 6 Jun 2002 07:33:36 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07437 for ; Thu, 6 Jun 2002 07:33:06 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g56BX4X17466 for ; Thu, 6 Jun 2002 07:33:04 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 12:33:03 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0051B55EC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Elwell, John" , "'Dean Willis'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity Date: Thu, 6 Jun 2002 12:33:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Or using the most appropriate. After all, if you are asserting that this is the user, all the identities represent the same user. Thus at a PSTN gateway one would prefer to use a tel-url if available. In other cases one may prefer to use the sip-url. Keith > -----Original Message----- > From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] > Sent: 31 May 2002 08:41 > To: 'Dean Willis' > Cc: 'sip@ietf.org' > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > Dean, > > My motivation for saying it should not be allowed was that it > seemed to be > implied elsewhere in the document - I wanted clarification. However, > multiple identities of the same type might give a problem for > gateways, as > you pointed out. I guess a gateway would just have to pick > one, e.g., the > first. > > Regards, > > John > > -------------------------------------------------------------- > John Elwell (john.elwell@siemens.com) > Siemens Communications Limited, > Technology Drive, Beeston, > Nottingham NG9 1LA, UK > Tel: +44 115 943 4989 Fax: +44 115 943 4969 > -------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 30 May 2002 21:58 > > To: 'Elwell, John'; 'sip' > > Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity > > > > > > > > John Elwell pondered: > > > Section 5, 3rd paragraph: > > > "The proxy MAY add a P-Asserted-Identity header field > > with either a > > > single SIP URI or a single SIPS URI. Likewise, the > > proxy MAY add a > > > P-Asserted-Identity header field with a single tel URL." > > > > > > This seems to imply that a proxy can add a header even if > > > there is already a header of the type concerned. Presumably > > > this should not be allowed. > > > > Why? > > > > There might be some issue with multiple tel URLs and gateway > > interworking, but asserting multiple identities seems like a very > > reasonable thing from a SIP perspective. > > > > If you're a PGP user, you may well have multiple identities > associated > > with one PGO key. There are practical reasons for doing this, and it > > doesn't seem to cause any problems. > > > > Different proxies or authentication servers might "know you" by > > different identities and be able to assert those identities on your > > behalf. It might also be reasonable to have multiple > > assertions for the > > same identity, like multiple signers in PGP. > > > > Signed, > > > > dwillis@dynamicsoft.com > > dean.willis@softarmor.com > > dwillis@greycouncil.com > > edean_willis@yahoo.com > > > > Ad nasueatum . . . > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08781 for ; Thu, 6 Jun 2002 08:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28112 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26076; Thu, 6 Jun 2002 07:34:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25987 for ; Thu, 6 Jun 2002 07:34:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07607; Thu, 6 Jun 2002 07:33:58 -0400 (EDT) Message-Id: <200206061133.HAA07607@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Jun 2002 07:33:58 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-05.txt Pages : 17 Date : 05-Jun-02 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. This can be used to enable many applications, including Call Transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020605094851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020605094851.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:04:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08982 for ; Thu, 6 Jun 2002 08:04:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28323 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25734; Thu, 6 Jun 2002 07:33:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25699 for ; Thu, 6 Jun 2002 07:33:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07504; Thu, 6 Jun 2002 07:33:21 -0400 (EDT) Message-Id: <200206061133.HAA07504@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Jun 2002 07:33:20 -0400 Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol ((SIP) extension for Called Party Identity Author(s) : M. Garcia Filename : draft-garcia-sip-called-party-id-04.txt Pages : 8 Date : 05-Jun-02 This memo describes a private extension to SIP in the form of a P-Called-Party-ID header. A proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-sip-called-party-id-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-garcia-sip-called-party-id-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-sip-called-party-id-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020605094749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-sip-called-party-id-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-sip-called-party-id-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020605094749.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:28:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09807 for ; Thu, 6 Jun 2002 08:28:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29206 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:29:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26754; Thu, 6 Jun 2002 07:49:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26730 for ; Thu, 6 Jun 2002 07:49:41 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08220 for ; Thu, 6 Jun 2002 07:49:09 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA01990; Thu, 6 Jun 2002 13:49:23 +0200 (MET DST) Received: from mchh169e.mch4.siemens.de ([139.21.130.176]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA23715; Thu, 6 Jun 2002 13:49:37 +0200 (MET DST) Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:49:39 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DFB@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Ben Campbell'" Cc: "'sip@ietf.org'" Subject: [SIP] Expires header in MESSAGE Date: Thu, 6 Jun 2002 13:49:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In SIP RFC 3261, only INVITE and REGISTER may include the Expires header. Section 20.19 states that "The precise meaing of this (Expires header) is method dependent". The meanings of Expires in INVITE and REGISTER are explained in detail in RFC 3261 (and in draft-ietf-sip-event for SUBSCRIBE). For example, in the section specifying UAS processing of the INVITE, there is a paragraph explaining how the UAS should handle the Expires header if one is present in the INVITE. draft-ietf-sip-message-04 allows MESSAGE to contain the Expires header, but does not explain the precise meaning of it. I propose to add the following statements to the draft: Section 4. UAC Processing The UAC MAY add an Expires header field to limit the validity of the message content. An Expires header field with a value of "0" is an indication to the gateway or store-and-forward server that the message MUST be delivered immediately. Section 7. UAS Processing If the MESSAGE request contains an Expires header field, the UAS sets a timer for the number of seconds indicated in the header field value. When the timer fires, the message is considered to be expired. If the message expires before the UAS displays the message to the user, the UAS should discard the message. A UAS which is a store-and-forward relay MUST NOT forward the message after the timer fired. When a message relay forwards a message, any Expires header field present in the MESSAGE request MUST be copied into the forwarded message. If there is a delay in forwarding the message, the UAS MUST substract the difference between time of forwarding and receipt of the request from the Expires value. A UAS receiving a MESSAGE request containing an Expires header field with a value of "0" MUST display the message to the user immediately. If the UAS is a store-and-forward relay, it MUST forward the message immediately. - Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 08:47:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10886 for ; Thu, 6 Jun 2002 08:47:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00326 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 08:47:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28751; Thu, 6 Jun 2002 08:15:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28720 for ; Thu, 6 Jun 2002 08:15:16 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09335 for ; Thu, 6 Jun 2002 08:14:43 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g56CEaB22891; Thu, 6 Jun 2002 14:14:36 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g56CEYk22093; Thu, 6 Jun 2002 13:14:34 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 13:14:44 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , Cullen Jennings , sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Thu, 6 Jun 2002 13:14:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20D53.B96821F2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D53.B96821F2 Content-Type: text/plain; charset="iso-8859-1" Just got back from holiday. Where are we on this one ? I can see both sides of this argument. The meaning of the 'hint' and of the 'asserted identity within a Trust Domain' are somewhat different, and if one is confused for the other then this is bad. This would suggest different headers. On the other hand, both of these are only as good as your trust relationship with the entity you received it from - you don't get any information about the 'trustworthyness' from the name of the header, you get it from your security relationships/configuration data, as described in the Trust Domain definition. The name 'Asserted-Identity' begs the question 'Asserted by whom' to which the answer is just 'the entity you received it from'. You need more data (configuration/secure connections) etc. to augment its status to 'asserted by the Trust Domain'. So, the semantics of the two headers *in themselves* are the same. Does giving them different names lull you into a false sense of security about the P-Asserted-Identity one ? Finally, P-Suggested-Identity begs the discussion: "Why did you suggest this identity ? Well, because that's the identity I'd prefer to use. Well, why didn't you say than then ?" So, if we must have a separate header, P-Prefered-Identity ?? ...Mark > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 05 June 2002 07:49 > To: Cullen Jennings; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity - new hint proposal > > > > > I am getting the feeling that people want to put the hint in a > separate > > header. How would everyone feel about something along the lines of: > > I liked one header -- I thought the semantic was pretty good "SOMEBODY > asserted this identity -- vouch for it or reject it". But at > this point > I just don't care anymore. . . > > -- > 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 > ------_=_NextPart_001_01C20D53.B96821F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Asserted-Identity - new hint proposal

Just got back from holiday. Where are we on this one = ?

I can see both sides of this argument. The meaning of = the 'hint' and of the 'asserted identity within a Trust Domain' are = somewhat different, and if one is confused for the other then this is = bad. This would suggest different headers.

On the other hand, both of these are only as good as = your trust relationship with the entity you received it from - you = don't get any information about the 'trustworthyness' from the name of = the header, you get it from your security relationships/configuration = data, as described in the Trust Domain definition.

The name 'Asserted-Identity' begs the question = 'Asserted by whom' to which the answer is just 'the entity you received = it from'. You need more data (configuration/secure connections) etc. to = augment its status to 'asserted by the Trust Domain'.

So, the semantics of the two headers *in themselves* = are the same.

Does giving them different names lull you into a = false sense of security about the P-Asserted-Identity one ?

Finally, P-Suggested-Identity begs the discussion: = "Why did you suggest this identity ? Well, because that's the = identity I'd prefer to use. Well, why didn't you say than then = ?"

So, if we must have a separate header, = P-Prefered-Identity ??

...Mark



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.c= om]
> Sent: 05 June 2002 07:49
> To: Cullen Jennings; sip@ietf.org
> Subject: Re: [Sip] Asserted-Identity - new hint = proposal
>
>
>
> > I am getting the feeling that people want = to put the hint in a
> separate
> > header. How would everyone feel about = something along the lines of:
>
> I liked one header -- I thought the semantic = was pretty good "SOMEBODY
> asserted this identity -- vouch for it or = reject it". But at
> this point
> I just don't care anymore. . .
>
> --
> 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
>

------_=_NextPart_001_01C20D53.B96821F2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 11:21:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17876 for ; Thu, 6 Jun 2002 11:21:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10483 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 11:22:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07877; Thu, 6 Jun 2002 10:38:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07846 for ; Thu, 6 Jun 2002 10:38:56 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16106 for ; Thu, 6 Jun 2002 10:38:23 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g56EgcV21648; Thu, 6 Jun 2002 09:42:38 -0500 Subject: Re: [Sip] CANCEL in Bis-09 From: Robert Sparks To: "George Foti (LMC)" Cc: sip@ietf.org In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037779@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C037779@lmc37.lmc.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 09:37:58 -0500 Message-Id: <1023374279.1350.26.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is not an inconsistency. The strength of the requirement to not send provisional responses to non-INVITE requests is SHOULD NOT. See line 1348 of the pdf. RjS On Thu, 2002-06-06 at 06:09, George Foti (LMC) wrote: > Hi, > Section 9.1 lines 1448 states that a CANCEL request SHOULD NOT be sent to > cancel a request other than INVITE (due to race conditions). > > Following that lines 1464-1465 state that if no provisional response has > been received, the CANCEL request MUST NOT be sent. > > Since provisional responses are only used with INVITES, it looks like the > strength on line 1448 needs to be changed to MUST NOT fo consistency. > > Rgds/ > George Foti > Ericsson Research Canada > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 11:33:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18191 for ; Thu, 6 Jun 2002 11:33:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11602 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 11:33:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08735; Thu, 6 Jun 2002 10:53:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08706 for ; Thu, 6 Jun 2002 10:53:31 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16939 for ; Thu, 6 Jun 2002 10:52:58 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g56Ev2V21683; Thu, 6 Jun 2002 09:57:04 -0500 Subject: Re: [Sip] Compact forms questions From: Robert Sparks To: kkoeman@techemail.com Cc: sip@ietf.org In-Reply-To: <20020606011600.A4EE236F9@sitemail.everyone.net> References: <20020606011600.A4EE236F9@sitemail.everyone.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 09:52:18 -0500 Message-Id: <1023375141.2255.35.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes - "r" and "b" were in that registry for awhile, but were removed during recent updates based on a decision to only reflect drafts that have made it to proposed standard. The "r" and "b" will reappear when their respective drafts pass that bar. RjS On Wed, 2002-06-05 at 20:16, Kosta Koeman wrote: > I've noted the following list from http://www.iana.org/assignments/sip-parameters that summarizes the compact forms defined for SIP (note: I have removed all header names without a compact form). > > Allow-Events u [RFCevents] > Call-ID i [RFC2543], draft-ietf-sip-rfc2543bis > Contact m [RFC2543], draft-ietf-sip-rfc2543bis > Content-Encoding e [RFC2543], draft-ietf-sip-rfc2543bis > Content-Length l [RFC2543], draft-ietf-sip-rfc2543bis > Content-Type c [RFC2543], draft-ietf-sip-rfc2543bis > Event o [RFCevent] > From f [RFC2543], draft-ietf-sip-rfc2543bis > Subject s [RFC2543], draft-ietf-sip-rfc2543bis > Supported k draft-ietf-sip-rfc2543bis > To t [RFC2543], draft-ietf-sip-rfc2543bis > Via v [RFC2543], draft-ietf-sip-rfc2543bis > > So the compact forms u & o are defined in the SIP-Specific Event Notification draft; i, m, e, l, c, o, f, s, t, & v are defined in the SIP spec/draft. I could not find the exact document where the compact form k was defined (besides the list, of course). > > What about the compact forms, r (Refer-To) and b (Referred-By), respectively defined in "The Refer Method" draft (draft-ietf-sip-refer-04) and "The Referred-By Mechanism" draft (draft-ietf-sip-referredby-00)? Are these compact forms not included in the list above due to the fact that their respective documents have not been submitted to be published as proposed standards? Since these compact forms have been defined in drafts, are these letters/compact forms reserved for the proposed usage? If not, is it likely that these letters/compact > forms will be reserved in the future and included in the list above? I > did note that both of these drafts state that the compact forms should be added to the list above. > > Thanks, > Kosta > > > > > > > _____________________________________________________________ > Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 12:00:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18689 for ; Thu, 6 Jun 2002 12:00:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13212 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 12:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11648; Thu, 6 Jun 2002 11:34:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11622 for ; Thu, 6 Jun 2002 11:34:00 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18208 for ; Thu, 6 Jun 2002 11:33:27 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA29036; Thu, 6 Jun 2002 17:33:55 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA11412; Thu, 6 Jun 2002 17:33:56 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 17:33:57 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E01@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: kkoeman@techemail.com Cc: sip@ietf.org Subject: RE: [Sip] Compact forms questions Date: Thu, 6 Jun 2002 17:33:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The unanswered part : | | On Wed, 2002-06-05 at 20:16, Kosta Koeman wrote: | | > So the compact forms u & o are defined in the SIP-Specific | Event Notification draft; i, m, e, l, c, o, f, s, t, & v are | defined in the SIP spec/draft. I could not find the exact | document where the compact form k was defined (besides the | list, of course). | "k" is defined in the SIP spec/draft Section 25.1 Supported = ("Supported" / "k") HCOLON [option-tag*(COMMA option-tag)] Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 6 12:29:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19403 for ; Thu, 6 Jun 2002 12:29:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15251 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 12:30:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14211; Thu, 6 Jun 2002 12:04:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14177 for ; Thu, 6 Jun 2002 12:04:12 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18802 for ; Thu, 6 Jun 2002 12:03:42 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Thu, 6 Jun 2002 11:03:31 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE2E@jupiter> From: David Oliver To: "'Dean Willis'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Thu, 6 Jun 2002 11:03:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It seems that the problem with P-Headers is that they are overloaded to mean both Private/Proprietary and Preliminary/Pre-Standards-Track. These are both distinct from strictly experimental (X?) headers in that they are published. In the Private case, publication is informational to the Internet community at large and serves to reserve the name, provides assistance in understanding third party traffic, and may avoid reinventing the wheel for similar applications. Applicability is "restricted", but that could mean "only applicable to POTS, ISDN and Mobile PSTN applications"! In the Preliminary case, the header is believed to have unrestricted applicability, and is urgently required, but the proposal is insufficiently solid to qualify for Standards Track. This could mean that only one community's requirements have been reviewed, or that there are known (but unresolved) technical limitations or risks. Publication reserves the name (and possibly reserves the non-P name?), and provides a suggested mechanism for early adopters, with the caveat that changes are likely. Preliminary headers should either be reviewed, adapted as necessary, and adopted as full Standards Track headers, or rejected and moved to Private status. A time limit should be imposed on this process to avoid them staying in limbo indefinitely. Separating out these overloaded uses of P Headers into two distinct namespaces could help - or at least move the controversy into a better defined arena. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: doliver@securelogix.com Tel: 210.402.9669 Fax: 210.402.6996 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, June 04, 2002 2:58 PM To: jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) > once ietf defines a p header for some purpose, there is far > less motivation to produce the corresponding standards track > sip header. the result is weaker sip and non-interoperable products. That is a legitimate position to take regarding the proposed SIP Change Process, something that we ARE working to refine. ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 18:51:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04142 for ; Thu, 6 Jun 2002 18:51:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18448 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 13:11:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16407; Thu, 6 Jun 2002 12:37:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16373 for ; Thu, 6 Jun 2002 12:37:45 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19719 for ; Thu, 6 Jun 2002 12:37:13 -0400 (EDT) From: ssundaragopalan@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g56GWIH27023; Thu, 6 Jun 2002 22:02:18 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BD0.005B47B1 ; Thu, 6 Jun 2002 22:07:01 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org cc: "'Sipimp \(E-mail\)'" Message-ID: <65256BD0.005B4782.00@sampark.hss.hns.com> Date: Thu, 6 Jun 2002 22:05:54 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Query on Contact Header present in redirection responses Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hi , In a 301/302 redirection responses ,will the sipurl in the Contact header have headers such as "to" and "From",which identifies a callleg??... I Guess, this should'nt be the case,coz,this will change the callleg identifier in the new request and one has to take care of all these intricacies in the implementation. If it is allowed, what is the scenario in which such a thing could occur??... any comments on this?? thanx and regds, srikanth _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:12:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10310 for ; Thu, 6 Jun 2002 19:12:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04530 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:13:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00216; Thu, 6 Jun 2002 18:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00162 for ; Thu, 6 Jun 2002 18:44:18 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00935 for ; Thu, 6 Jun 2002 18:43:44 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g56KmIK01614; Thu, 6 Jun 2002 15:48:18 -0500 From: "Dean Willis" To: "'Tan Ya-Ching ICM N PG U ID A 1'" Cc: Subject: RE: [Sip] Draft-willis-sip-path revised to -08 Date: Thu, 6 Jun 2002 15:48:01 -0500 Message-ID: <00cf01c20d9b$73851a30$1d036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-reply-to: <5B4D0C5BA65ECA46969C1419122317E6E74DF8@mchh161e> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > ...whereas the vector established by Path applies to all > future requests addressed to the user outside of a dialog. Thanks! > No bug in the example, it's my fault. The INVITE in your example > is sent from UA2, which has nothing to do with UA1 who supports > Path. But the original question remains, do we need the > Supported:path if UA1 sends requests other than REGISTER? I > support your "All requests for which the UA is willing to use this > extension". An INVITE from UA1 with Supported:path serves > absolutely no purpose when it reaches UA2. I think there's probably a need for a sort of meta-discssion about what Allowed, Supported, and Required REALLY mean and when they should be used . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:21:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12243 for ; Thu, 6 Jun 2002 19:21:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04915 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:21:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02264; Thu, 6 Jun 2002 18:58:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02223 for ; Thu, 6 Jun 2002 18:58:54 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06081 for ; Thu, 6 Jun 2002 18:58:17 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56LW3YH007538; Thu, 6 Jun 2002 17:32:04 -0400 (EDT) Message-ID: <3CFFD46C.3080403@dynamicsoft.com> Date: Thu, 06 Jun 2002 17:30:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: duncan.mills@vf.vodafone.co.uk CC: sip@ietf.org Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit duncan.mills@vf.vodafone.co.uk wrote: > Jonathan, >>For instance, >> the type of access being used may influence home network decisions >> on what level of security to apply to sessions. > > > I don't see what the access network has to do with session level > security (or what proxies have to do with session level security). > > [Duncan] Just that where the access network is a GPRS network provided > by > OpCo1 and the 3GPP IMS (SIP) network is also provided by OpCo1, then an > operator may decide that the level of security applied to the > application > layer needs to be either lower (GPRS provides security) or higher (If > there's a wireless link involved, let's be more careful. [/Duncan] Just because GPRS provides security doesn't say anything about sip security. Lets be careful here. >>The home network must know the possible values that a particular UA >> may use to populate the access-type and access-info fields. >> >> In other words, a home network with business agreements allowing >> users to access via a particular technology must be able to parse >> the P-Access-Network-Info header containing an access-type for that > > >> technology in order to use this information. >> >> For example, the access-type could read "IEEE-802.11b". If a home >> network knows it has a business agreement with a W-LAN access >> network, it must be ready to understand the value "IEEE-802.11b". >> Similarly, a UAC supporting this extension that can access via > > W-LAN > >> must be able to insert the relevant value. > > > This text confuses me, since it tries to belabor an obvious point - that > the proxy must know how to parse these values. Maybe I am missing > something. Perhaps this is related to the fact that no definition is > provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't > just provide a definition for those and then delete the statements > above. > > > [Duncan] The definition for the cell-id is just that it is a string of > hex. > It is defined already in 3GPP specifications. I agree the current text > in > my draft is probably not adding much. I can't reference 3GPP > specifications > though, right? I wanted to describe it in this draft, as "You can put > anything you want in here as a 'string'." "3GPP mobiles will be limited > by > 3GPP specifications as to what they can put in there." [/Duncan] I don't see why you don't define the values in this spec... shouldn't these specs at least stand alone and work outside of 3gpp so long as the applicability statement holds true? >>This document does not define either the nature of the information >> or the messages where the P-Access-Network-Info needs to be >> inserted. > > > This is confusing; it does define the nature of the information. What am > I missing? > > > [Duncan] OK, bad wording again. What I mean is that this document only > provides *some* values to put in the 'access-type' and 'access-info' > fields. > There's the chance for other people to define their own tokens etc. The > nature of the information is not meant to be restricted to providing the > cell ID (that's how 3GPP may use this extension, yes, but another system > may > want to say 'Airport Lounge' in the access-info field). That's waht I > meant > to say, but I agree, I need to re-word it. [/Duncan] If you want to define some baseline values, but allow others to register or use additional values, then you should say that. > > > >>A proxy, typically located in the home network, and therefore >> trusted, MUST delete the header when the SIP signaling is forwarded > > >> to a SIP server located in a non-trusted administrative network >> domain. The access network information is used by a home network > > and > >> is of no interest to the destination >> network. > > > What about a trusted administrative network domain? I think that the > home proxy MUST strip this in all cases. > > > [Duncan] Well, a home proxy may wish to leave the header in and forward > the > message to an Application Server. As long as this is all in the home > trusted domain, then it's okay? [/Duncan] It gets back to the privacy issue. THe caller may not wish for other domains to know my location. You don't have a way to express privacy preferences, so you have to strip it when sending to any other administrative domain. App servers within the same home domain are ok i guess. >> UAs are expected to provide correct information. However, there are >> no security problems resulting from a UAC inserting incorrect >> information. > > > Well, I doubt that is true in the case of cell-id. Providing false > location information can be used for all sorts of bad things. > > [Duncan] A rogue user or rogue implementation putting false cell-ID > information in this header means that the user doesn't get the correct > address for the nearest Pizza Restaurant, or doesn't get to their > voicemail > from abroad. It would be a nasty fault, but is it really that much of a > security problem? [/Duncan] The 911 operators might not like it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:25:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12962 for ; Thu, 6 Jun 2002 19:25:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05250 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:25:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03190; Thu, 6 Jun 2002 19:01:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03143 for ; Thu, 6 Jun 2002 19:01:02 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06682 for ; Thu, 6 Jun 2002 19:00:30 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g56M4x9F009853 for ; Thu, 6 Jun 2002 18:04:59 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL57302; Thu, 6 Jun 2002 18:09:07 -0400 (EDT) Message-ID: <3CFFDC6D.F3162692@cisco.com> Date: Thu, 06 Jun 2002 18:04:29 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org References: <200206061133.HAA07607@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-refer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have a couple of questions - not unique to this version of the draft, equally applicable to them all I think. The following is from section 2: A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog. REFERs occurring outside an existing dialog effectively create a new dialog following the behavior of SUBSCRIBE specified in [2]. 1) WRT the last sentence above - subscribe dialogs have an expiration time. Suppose the refer still hasn't completed by the time the dialog is about to expire. (Perhaps an INVITE was sent and a Ringing was returned, but the call hasn't yet succeeded or failed.) How would the UA go about refreshing the subscription? (A new REFER in the same dialog doesn't seem right, but neither does a SUBSCRIBE.) Even if the dialog isn't about to expire, I might want to refresh as a way to verify that the other end is still alive, in case no notifies have been received recently. (I should expect notifies as often as the corresponding INVITE can expect responses.) 2) The first sentence implies that a REFER *MAY* be placed *inside* the scope of a dialog created by an invite. In fact this is an important use case. If so, are the subsequent NOTIFY messages returned in the context of that same dialog? (If so, presumably that dialog can be refreshed with reINVITEs.) 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 daemon@optimus.ietf.org Thu Jun 6 19:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13978 for ; Thu, 6 Jun 2002 19:30:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06366 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:31:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03894; Thu, 6 Jun 2002 19:05:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03867 for ; Thu, 6 Jun 2002 19:05:50 -0400 (EDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08690 for ; Thu, 6 Jun 2002 19:05:18 -0400 (EDT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g56LxkT26186 for ; Thu, 6 Jun 2002 21:59:47 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060615081903459 for ; Thu, 06 Jun 2002 15:08:19 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 14:41:13 -0700 Message-ID: From: "Padhye, Chinmay" To: "'sip@ietf.org'" Date: Thu, 6 Jun 2002 14:41:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Refer-05 - Error in Example Replaces header. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, In the latest refer draft - http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-05.txt. There are a couple of problems in one of the examples - Refer-To: sip:dave@denver.com?Replaces%3D12345%40192.168.118.3%3Bto-tag%3D12345%3Bfrom -tag%3D5FFE-3994 It should be - Refer-To: sip:dave@denver.com?Replaces:3D12345%40192.168.118.3%3Bto-tag=3D12345%3Bfrom -tag=3D5FFE-3994 Is this correct. Thanks, Chinmay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:33:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14680 for ; Thu, 6 Jun 2002 19:33:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06627 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:34:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04451; Thu, 6 Jun 2002 19:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04407 for ; Thu, 6 Jun 2002 19:11:57 -0400 (EDT) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10071 for ; Thu, 6 Jun 2002 19:11:25 -0400 (EDT) Message-ID: <20020606221154.21433.qmail@web11603.mail.yahoo.com> Received: from [207.46.225.252] by web11603.mail.yahoo.com via HTTP; Thu, 06 Jun 2002 15:11:54 PDT Date: Thu, 6 Jun 2002 15:11:54 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] UTF-8 in SIP URIs To: Jonathan Rosenberg Cc: sip@ietf.org In-Reply-To: <3CFFB839.2050605@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org That section of RFC 2396 also states that a URI scheme can make a scheme-specific decision about how to handle non-US-ASCII. My question boils down to whether such a decision has been made for the sip(s): URI scheme(s). For example, FTP and HTTP URI schemes both appear to have text surrounding this. Eventually I would expect something like this for SIP. An informational or perhaps BCP on how I18N works with SIP. Thanks! /sean --- Jonathan Rosenberg wrote: > Section 2.1 of rfc 2396 explains why it should in > theory be possible to > use non-ascii, but that there is no way right now, > and it will be > addressed in a revision. Others more clued into > internationalization > issues may have a more up-to-date answer... > > -Jonathan R. > > Sean Olson wrote: > > Just a question for clarification. For escaped > > characters in a SIP URI, is it assumed that those > > octects represent a UTF-8 encoded character? Or > > are other encodings possible? > > > > /sean > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle > Rock Avenue > Chief Scientist First Floor > dynamicsoft East > Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > http://www.jdrosen.net PH: (973) > 952-5000 > http://www.dynamicsoft.com > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:35:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15037 for ; Thu, 6 Jun 2002 19:35:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06655 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:36:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04108; Thu, 6 Jun 2002 19:07:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04077 for ; Thu, 6 Jun 2002 19:07:53 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09087 for ; Thu, 6 Jun 2002 19:07:19 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g56JVYK25012; Thu, 6 Jun 2002 14:31:34 -0500 (CDT) Message-ID: <3CFFB87A.9090406@dynamicsoft.com> Date: Thu, 06 Jun 2002 14:31:06 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tan Ya-Ching ICM N PG U ID A 1 , "'sip@ietf.org'" Subject: Re: [SIP] Expires header in MESSAGE References: <5B4D0C5BA65ECA46969C1419122317E6E74DFB@mchh161e> <3CFFB576.5000206@dynamicsoft.com> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with weekening the language to SHOULD NOT. I can invision applications where it would make perfectly good sense to display an old message with a warning that it has expired. So the expires header would really be a fairly strong hint on behavior, but the sender cannot assume that the recipient will never see expired messages. Jonathan Rosenberg wrote: > I think the general usage of Expires that is discussed here is good, and > consistent with the usage envisioned for the header. However, I would > weaken many of the strengths below from MUST NOT or MUST to SHOULD NOT > or SHOULD. > > -Jonathan R. > > Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> In SIP RFC 3261, only INVITE and REGISTER may include the Expires >> header. >> Section 20.19 states that "The precise meaing of this (Expires header) >> is >> method dependent". The meanings of Expires in INVITE and REGISTER are >> explained in detail in RFC 3261 (and in draft-ietf-sip-event for >> SUBSCRIBE). >> For example, in the section specifying UAS processing of the INVITE, >> there >> is a paragraph explaining how the UAS should handle the Expires header >> if >> one is present in the INVITE. >> >> draft-ietf-sip-message-04 allows MESSAGE to contain the Expires header, >> but >> does not explain the precise meaning of it. >> I propose to add the following statements to the draft: >> >> Section 4. UAC Processing >> >> The UAC MAY add an Expires header field to limit the >> validity of the message content. An Expires header >> field with a value of "0" is an indication to the gateway >> or store-and-forward server that the message MUST >> be delivered immediately. >> >> Section 7. UAS Processing >> >> If the MESSAGE request contains an Expires header >> field, the UAS sets a timer for the number of seconds >> indicated in the header field value. When the timer fires, the >> message is considered to be expired. If the >> message expires before the UAS displays the message to the user, >> the UAS should discard the message. A UAS which is a >> store-and-forward relay MUST NOT forward the message after the >> timer fired. When a >> message relay forwards a message, any Expires header field >> present in the MESSAGE request MUST be copied into the forwarded >> message. If there is a delay in forwarding the message, the UAS >> MUST substract the difference between time of forwarding and >> receipt of the request from the Expires value. >> >> A UAS receiving a MESSAGE request containing an >> Expires header field with a value of "0" MUST display the >> message to the user immediately. If the UAS is a >> store-and-forward relay, it MUST forward the message >> immediately. >> >> >> - Ya-Ching >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 19:49:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17058 for ; Thu, 6 Jun 2002 19:49:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07494 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 19:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05137; Thu, 6 Jun 2002 19:23:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05109 for ; Thu, 6 Jun 2002 19:23:51 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12503 for ; Thu, 6 Jun 2002 19:23:19 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g56ICSV22139; Thu, 6 Jun 2002 13:12:28 -0500 Subject: RE: [Sip] CANCEL in Bis-09 From: Robert Sparks To: "George Foti (LMC)" Cc: "George Foti (LMC)" , sip@ietf.org In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C03777C@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C03777C@lmc37.lmc.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 13:08:04 -0500 Message-Id: <1023386884.1233.31.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Thu, 2002-06-06 at 12:29, George Foti (LMC) wrote: > Given that, can you please explain how this legitimate case be handled > > UAa----------P1-------------P2---------------UAb > > P1, P2 are stateful. > A session is already established between UAa & UAb > > UAa sends a BYE followed by a CANCEL. > P1 proxies the BYE to P2 then answers UAa with 200 OK for the CANCEL, then > proxies the CANCEL to P2. UAa & P1 now beleive that the BYE has been > succesfully cancelled. No, at this point UAa believes the CANCEL was received and processed. UAa will have no knowledge of whether the BYE was successfully canceled until it receives the final response to the BYE. CANCELs are not (statefully) proxied. They are hop-by-hop. P1 accepted the cancel from UAa and is now trying to cancel its request to P2. P1 does _NOT_ believe the BYE has been successfully cancelled. > P2 receives the CANCEL before BYE, returns a 481, then receives the BYE. > P2 forwards the BYE to UAb. This is exactly the race condition that motivated the SHOULD NOT send CANCEL for non-INVITE in bis-09. This is bad because the BYE now _cannot_ be successfully canceled (there is no way to retry the cancel), but it does _not_ result in an inconsistent view of dialog state. > UAb returns 200 OK for the BYE which gets proxied all the way to UAa. And thus UAa knows the BYE was not successfully canceled. There is no inconsistent view of state in this scenario. > > We have now an inconsistent view of the session due to a race condition. > UAa, P1 beleive that the session is still ongoing. P2 & UAb believe that the > session is still gone > > Rgds > /gf > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Thursday, June 06, 2002 10:38 AM > > To: George Foti (LMC) > > Cc: sip@ietf.org > > Subject: Re: [Sip] CANCEL in Bis-09 > > > > > > This is not an inconsistency. > > > > The strength of the requirement to not send provisional > > responses to non-INVITE requests is SHOULD NOT. > > > > See line 1348 of the pdf. > > > > RjS > > > > On Thu, 2002-06-06 at 06:09, George Foti (LMC) wrote: > > > Hi, > > > Section 9.1 lines 1448 states that a CANCEL request SHOULD > > NOT be sent to > > > cancel a request other than INVITE (due to race conditions). > > > > > > Following that lines 1464-1465 state that if no provisional > > response has > > > been received, the CANCEL request MUST NOT be sent. > > > > > > Since provisional responses are only used with INVITES, it > > looks like the > > > strength on line 1448 needs to be changed to MUST NOT fo > > consistency. > > > > > > Rgds/ > > > George Foti > > > Ericsson Research Canada > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:07:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18442 for ; Thu, 6 Jun 2002 20:07:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA08716 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:07:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07417; Thu, 6 Jun 2002 19:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07385 for ; Thu, 6 Jun 2002 19:49:14 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16905 for ; Thu, 6 Jun 2002 19:48:42 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g56HTXi17016; Thu, 6 Jun 2002 12:29:33 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g56HTXt04273; Thu, 6 Jun 2002 12:29:33 -0500 (CDT) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g56HTWE16246; Thu, 6 Jun 2002 13:29:32 -0400 (EDT) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Jun 2002 13:29:32 -0400 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03777C@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Robert Sparks'" , "George Foti (LMC)" Cc: sip@ietf.org Subject: RE: [Sip] CANCEL in Bis-09 Date: Thu, 6 Jun 2002 13:29:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Given that, can you please explain how this legitimate case be handled UAa----------P1-------------P2---------------UAb P1, P2 are stateful. A session is already established between UAa & UAb UAa sends a BYE followed by a CANCEL. P1 proxies the BYE to P2 then answers UAa with 200 OK for the CANCEL, then proxies the CANCEL to P2. UAa & P1 now beleive that the BYE has been succesfully cancelled. P2 receives the CANCEL before BYE, returns a 481, then receives the BYE. P2 forwards the BYE to UAb. UAb returns 200 OK for the BYE which gets proxied all the way to UAa. We have now an inconsistent view of the session due to a race condition. UAa, P1 beleive that the session is still ongoing. P2 & UAb believe that the session is still gone Rgds /gf > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, June 06, 2002 10:38 AM > To: George Foti (LMC) > Cc: sip@ietf.org > Subject: Re: [Sip] CANCEL in Bis-09 > > > This is not an inconsistency. > > The strength of the requirement to not send provisional > responses to non-INVITE requests is SHOULD NOT. > > See line 1348 of the pdf. > > RjS > > On Thu, 2002-06-06 at 06:09, George Foti (LMC) wrote: > > Hi, > > Section 9.1 lines 1448 states that a CANCEL request SHOULD > NOT be sent to > > cancel a request other than INVITE (due to race conditions). > > > > Following that lines 1464-1465 state that if no provisional > response has > > been received, the CANCEL request MUST NOT be sent. > > > > Since provisional responses are only used with INVITES, it > looks like the > > strength on line 1448 needs to be changed to MUST NOT fo > consistency. > > > > Rgds/ > > George Foti > > Ericsson Research Canada > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:18:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19202 for ; Thu, 6 Jun 2002 20:18:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09382 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:18:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02447; Thu, 6 Jun 2002 18:59:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02276 for ; Thu, 6 Jun 2002 18:58:59 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06140 for ; Thu, 6 Jun 2002 18:58:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JVfYH007365; Thu, 6 Jun 2002 15:31:41 -0400 (EDT) Message-ID: <3CFFB839.2050605@dynamicsoft.com> Date: Thu, 06 Jun 2002 15:30:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: sip@ietf.org Subject: Re: [Sip] UTF-8 in SIP URIs References: <20020605190010.11991.qmail@web11606.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 2.1 of rfc 2396 explains why it should in theory be possible to use non-ascii, but that there is no way right now, and it will be addressed in a revision. Others more clued into internationalization issues may have a more up-to-date answer... -Jonathan R. Sean Olson wrote: > Just a question for clarification. For escaped > characters in a SIP URI, is it assumed that those > octects represent a UTF-8 encoded character? Or > are other encodings possible? > > /sean > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:20:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19320 for ; Thu, 6 Jun 2002 20:20:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09448 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:20:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02529; Thu, 6 Jun 2002 18:59:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02289 for ; Thu, 6 Jun 2002 18:59:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06143 for ; Thu, 6 Jun 2002 18:58:28 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JdUYH007377; Thu, 6 Jun 2002 15:39:30 -0400 (EDT) Message-ID: <3CFFBA0D.1050405@dynamicsoft.com> Date: Thu, 06 Jun 2002 15:37:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] SDP in 200 with PRACK References: <3CFEFE99.AC7FC26E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > The following has been discussed before, but I haven't found any > clarification for it in the bis- or PRACK draft: > > Chapter 13.2.1 is bis says: > > "If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE." > > Now, if PRACK is used, the first reliable non-failure message from the > UAS may be a 18x provisional response, so the UAS may include an answer > in such a message. Right. > > My question is: does this still require that the answer which was sent > in the 18x must also be included in the 200? No. The above text is mostly referring to the non-100rel case only. There, the first reliable response is the 2xx. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:30:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19942 for ; Thu, 6 Jun 2002 20:30:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA10157 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:30:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02541; Thu, 6 Jun 2002 18:59:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02320 for ; Thu, 6 Jun 2002 18:59:04 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06187 for ; Thu, 6 Jun 2002 18:58:31 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56HO7YH007179 for ; Thu, 6 Jun 2002 13:24:08 -0400 (EDT) Message-ID: <3CFF9A54.4040209@dynamicsoft.com> Date: Thu, 06 Jun 2002 13:22:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] update to draft-ietf-sip-guidelines Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've just submitted an update to draft-ietf-sip-guidelines. Until it appears in the archives, you can pick up a copy from: http://www.jdrosen.net/papers/draft-ietf-sip-guidelines-05.txt The changes since -04 are: * Added guidelines on constructing titles for extensions * Mandated the use of a table 2/3 in each extension * reworked discussion on large content in sip to be based on its relevance to a sip feature, and based on congestion control * removed exception of REGISTER to large content discussion. * consistent usage of terminology with bis * remove requirement that extensions make sure they can work with stateless proxies (many cannot) * case sensitivity requirements aligned with bis * recommend use of relative times and not absolute dates whenever possible * provided template 2234 syntax for extension headers * added sigcomp as a reasonable compression mechanism * advice specifications to describe handling of recoverable failure cases, not unrecoverable ones * changed recommendation to use normative terminology in overview section; non-normative is now recommended. * removed requirement that extensions describe how tags interact with their extension (this is far less confusing in bis than it was in 2543) * removed changes-since sections in preparation for wglc -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:46:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21018 for ; Thu, 6 Jun 2002 20:46:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11262 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:47:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02587; Thu, 6 Jun 2002 18:59:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02298 for ; Thu, 6 Jun 2002 18:59:01 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06147 for ; Thu, 6 Jun 2002 18:58:29 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JJsYH007358; Thu, 6 Jun 2002 15:19:55 -0400 (EDT) Message-ID: <3CFFB576.5000206@dynamicsoft.com> Date: Thu, 06 Jun 2002 15:18:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'Ben Campbell'" , "'sip@ietf.org'" Subject: Re: [SIP] Expires header in MESSAGE References: <5B4D0C5BA65ECA46969C1419122317E6E74DFB@mchh161e> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think the general usage of Expires that is discussed here is good, and consistent with the usage envisioned for the header. However, I would weaken many of the strengths below from MUST NOT or MUST to SHOULD NOT or SHOULD. -Jonathan R. Tan Ya-Ching ICM N PG U ID A 1 wrote: > In SIP RFC 3261, only INVITE and REGISTER may include the Expires > header. > Section 20.19 states that "The precise meaing of this (Expires header) > is > method dependent". The meanings of Expires in INVITE and REGISTER are > explained in detail in RFC 3261 (and in draft-ietf-sip-event for > SUBSCRIBE). > For example, in the section specifying UAS processing of the INVITE, > there > is a paragraph explaining how the UAS should handle the Expires header > if > one is present in the INVITE. > > draft-ietf-sip-message-04 allows MESSAGE to contain the Expires header, > but > does not explain the precise meaning of it. > > I propose to add the following statements to the draft: > > Section 4. UAC Processing > > The UAC MAY add an Expires header field to limit the > validity of the message content. An Expires header > field with a value of "0" is an indication to the gateway > or store-and-forward server that the message MUST > be delivered immediately. > > Section 7. UAS Processing > > If the MESSAGE request contains an Expires header > field, the UAS sets a timer for the number of seconds > indicated in the header field value. When the timer > fires, the message is considered to be expired. If the > message expires before the UAS displays the message > to the user, the UAS should discard the message. A > UAS which is a store-and-forward relay MUST NOT > forward the message after the timer fired. When a > message relay forwards a message, any Expires > header field present in the MESSAGE request MUST > be copied into the forwarded message. If there is a > delay in forwarding the message, the UAS MUST > substract the difference between time of forwarding > and receipt of the request from the Expires value. > > A UAS receiving a MESSAGE request containing an > Expires header field with a value of "0" MUST display the > message to the user immediately. If the UAS is a > store-and-forward relay, it MUST forward the message > immediately. > > > - Ya-Ching > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:50:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21264 for ; Thu, 6 Jun 2002 20:50:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11591 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:50:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02503; Thu, 6 Jun 2002 18:59:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02310 for ; Thu, 6 Jun 2002 18:59:03 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06174 for ; Thu, 6 Jun 2002 18:58:30 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JHUYH007355; Thu, 6 Jun 2002 15:17:31 -0400 (EDT) Message-ID: <3CFFB4E6.9060408@dynamicsoft.com> Date: Thu, 06 Jun 2002 15:15:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: dean.willis@softarmor.com, c_padhye@trillium.com, sip@ietf.org, oran@cisco.com Subject: Re: [Sip] updating session timer References: <2038BCC78B1AD641891A0D1AE133DBB777923A@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is a good point. I think there was consensus on at least allowing UPDATE to update the session timer. On other methods, things were mixed. However, I am inclined to leave it at just UPDATE, partly for the (arguably philosophical) reason below. I will make the change and be submitting an update shortly. -Jonathan R. hisham.khartabil@nokia.com wrote: > We have to separate dialogs from sessions. > > To my mind, we are talking about Session Timer, not dialog timer. > Requests like SUBSCRIBE/NOTIFY can appear within a dialog but should not > affect the "session" timer. > > UPDATE updates a session, not a dialog. > > /Hisham > > > > >>-----Original Message----- >>From: ext Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Wednesday, June 05, 2002 3:44 AM >>To: 'Padhye, Chinmay'; sip@ietf.org >>Cc: 'David R. Oran'; 'Jonathan Rosenberg' >>Subject: RE: [Sip] updating session timer >> >> >> >>I think I agree with Chinmay here. One of the big beefs with >>session-timer is the number of additional messages required >>(INVITE-OK-ACK) just to refresh it. If every request-response on the >>dialog resets the count-down timer, then we have very little >>overhead. >> >>-- >>Dean >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On >>>Behalf Of Padhye, Chinmay >>>Sent: Tuesday, June 04, 2002 4:06 PM >>>To: sip@ietf.org >>>Cc: 'David R. Oran'; Jonathan Rosenberg >>>Subject: RE: [Sip] updating session timer >>> >>> >>>Hello, >>> >>> I feel any method sent/received on an existing dialog >>>should reset the session timer for that dialog. >>> >>> Its OK for UPDATE to change the session timer related >>>roles, timer values, etc. >>> >>>Regards, >>> >>>Chinmay >>> >>>-----Original Message----- >>>From: David R. Oran [mailto:oran@cisco.com] >>>Sent: Tuesday, June 04, 2002 1:36 PM >>>To: Jonathan Rosenberg; sip@ietf.org >>>Subject: Re: [Sip] updating session timer >>> >>> >>>It certainly makes sense to have UPDATE refresh the session >>>timer. Other >>>than that I don't see much benefit in tweaking the design, >>>unless we just >>>want to say that any method refreshes the timer. That makes >> >>the spec >> >>>future-proof for new methods, which might be a good thing, or >>>a bad thing >>>depending on some clairvoyance I don't have. >>> >>>I vote for the minimal disruption: add UPDATE as a method >>>which refreshes >>>the timer and leave the rest alone. >>> >>>Dave. >>> >>>--On Tuesday, June 04, 2002 3:17 PM -0400 Jonathan Rosenberg >>> wrote: >>> >>> >>>>Folks, >>>> >>>>I am in the process of doing an update to session timer. >>> >>This draft >> >>>>got "shelved" while we were finishing up bis and the rest >>> >>>of the pile >>> >>>>of drafts for 3gpp. As such, its being updated to now >>> >>reference bis >> >>>>rather than rfc2543. One of the things I am doing in this >>> >>>process is >>> >>>>assessing whether anything new impacts design decisions we >>> >>>made in the >>> >>>>original draft. >>>> >>>>One of the things we assumed in session timer was that >>> >>all session >> >>>>refreshes were with re-invite. The principal reason for >>> >>>that was that >>> >>>>we wanted the refreshes to have a soft-state property, so that a >>>>refresh could itself cause the recovery of call and session >>> >>>state at a >>> >>>>failed-and-rebooted UA (or a backup). >>>> >>>>The notion of such soft-state recovery of sessions was >>> >>>something that >>> >>>>we discussed at length for bis (bug #207), and ultimately >>> >>>decided not >>> >>>>to go with. In the case of bis, the particular issue was >>> >>>that if you >>> >>>>have a media stream failure, should you send a re-INVITE in >>> >>>order to >>> >>>>re-establish the call with a backup? This would allow >>> >>>relatively fast >>> >>>>recovery. However, we didn't do this because it had >>> >>>numerous problems, >>> >>>>which I won't repeat. There was also limited interest in such >>>>recovery. Now, the point of this is that we discarded support for >>>>rapid recovery of call state and sessions from bis. Session timer >>>>would provide much slower recovery, arguably, so slow as >>> >>to not be >> >>>>useful. Since we already discarded the much-more-useful approach, >>>>there seems little value in supporting the much-less-useful >>> >>>approach. >>> >>>>Another thing that has changed with bis is the existence >>> >>of another >> >>>>method which is a pretty reasonable mechanism for refreshing the >>>>session timer - UPDATE. An UPDATE without an offer at all seems a >>>>perfect mechanism for updating a session timer. >>>> >>>>So, I would propose we re-visit this design decision, and >>> >>>at the very >>> >>>>least, allow for session timer refreshes to occur in UPDATE >>> >>>as well as >>> >>>>INVITE. The other alternative is to allow session timer >>> >>>refreshes in >>> >>>>any method. This would allow normally ocurring SIP messages >>> >>>within the >>> >>>>dialog (if any) to cause refreshes, and if you had >>> >>nothing to send, >> >>>>you would use UPDATE. The overall benefit here is reduced >>> >>overhead >> >>>>(2-way exchange with UPDATE instead of three-way with >>> >>>INVITE). I see >>> >>>>no reason why we shouldn't allow for session timer updates in any >>>>method. >>>> >>>>Another issue possibly worth revisiting is the decision to allow >>>>session timer to work as long as only one of the two UA >>> >>in a dialog >> >>>>support it. In order to enable that, there is some complex proxy >>>>behavior, and generally more complex UA behavior. With more >>> >>>experience >>> >>>>behind us (although I must say I am not aware of any UA >>>>implementations of this draft), do people still believe this is a >>>>reasonable assumption? I'm inclined not to change it, since >>> >>>I really >>> >>>>prefer not to revisit every design decision unless there is good >>>>reason (i.e., bis has changed an assumption). >>>> >>>>Comments welcome. >>>> >>>>Thanks, >>>>Jonathan R. >>>> >>>> >>>> >>>> >>>>-- >>>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>>>Chief Scientist First Floor >>>>dynamicsoft East Hanover, NJ 07936 >>>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>>http://www.jdrosen.net PH: (973) 952-5000 >>>>http://www.dynamicsoft.com >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on >>> >>>current sip Use >>> >>>>sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>>----------------------------------------------------------- >>>David R. Oran Phone/Fax: +1 978 264 2048 >>>Cisco Systems VoIP: +1 408 571 4576 >>>7 Ladyslipper Lane Email: oran@cisco.com >>>Acton, MA 01720 >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current >>>sip Use sipping@ietf.org for new developments on the >>>application of sip >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current >>>sip Use sipping@ietf.org for new developments on the >>>application of sip >>> >>> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 20:52:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21377 for ; Thu, 6 Jun 2002 20:52:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11709 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 20:52:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02408; Thu, 6 Jun 2002 18:59:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02251 for ; Thu, 6 Jun 2002 18:58:57 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06097 for ; Thu, 6 Jun 2002 18:58:22 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56L9rYH007506; Thu, 6 Jun 2002 17:09:54 -0400 (EDT) Message-ID: <3CFFCF3A.50103@dynamicsoft.com> Date: Thu, 06 Jun 2002 17:08:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henrikson, Eric H (Eric)" CC: Dean Willis , sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com, "Drage, Keith (Keith)" Subject: Re: [Sip] Poll: expert review of draft-henrikson-sip-charging-in formation References: <47AF9FA8BB0DD611A75C00A0C9AA883C02B3F23E@il0015exch004u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Apologies for the delay in responding. Responses inline. Henrikson, Eric H (Eric) wrote: > Jonathan, > > Thank you for the comments. I am open to any alternative that solves > the problem of correlating the dialogs at the S-CSCF. > > Please confirm that I am understanding your proposal correctly. > > The problem we are trying to solve only pertains to the case of a B2BUA > type of application server for 3GPP. If an INVITE is sent from a S-CSCF > to a B2BUA, which then sends a new INVITE back to the S-CSCF, I don't > see how using just the Route information can be used to correlate the > new INVITE with the old INVITE. Each INVITE may have different To tag, >>From tag and Call-ID. The (plain) Route header in the new INVITE may be > common with dozens of other INVITEs that have followed this same path. Well, it shouldn't be. Thats the proposal. > > I find the following definition for Route: > > Route = "Route" HCOLON route-param *(COMMA route-param) > route-param = name-addr *( SEMI rr-param ) > rr-param = generic-param > > Are you suggesting that there is some parameter placed in the 2nd Route > header element inserted by the S-CSCF that it uses for the correlation? > If so, then is it ok to use a 3GPP specific parameter defined within > 3GPP specifications (rr-param)? Either a parameter, or more simply, the user part. Think of it this way. A URI identifies a resource. In the case of a conference server, the URI identifies a particular instance of a conference. It therefore really points to a collection of state that collectively represent the conference. The user part is a pointer to that state. So, for example: sip:conference.988dskad900-asskmsd9@servers.com Now, your S-CSCF is a resource too. In its case, the resource is the particular instance of the application invocation context that this request is associated with. The URI therefore points to a collection of state that collectively represent the context. The user part is a pointer to that state. So, for example: sip:context.asd9asd8asd8890@scscf.3gpp.com Thus, you require no new parameter or standardization. > > If that is what is meant, then I can see where the S-CSCF could define a > unique value to send with the 2nd Route header, e.g. > ";correlate=2349873453", and we could require that 3GPP compliant B2BUA > Application Servers return 2nd Route header as the topmost Route header > to the S-CSCF . They don't need to just be egpp compliant. Any reasonably implemented b2bua should honor route headers like a proxy does. Therefore, it ought to work with any b2bua. > > Eric Henrikson > > p.s. I presume you are referring to the P-Original-Dialog-ID draft and > not the charging information draft. Yes, sorry. To many p-header drafts, too little time.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 6 22:34:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27611 for ; Thu, 6 Jun 2002 22:34:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17181 for sip-archive@odin.ietf.org; Thu, 6 Jun 2002 22:35:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15934; Thu, 6 Jun 2002 22:14:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15904 for ; Thu, 6 Jun 2002 22:14:19 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26092 for ; Thu, 6 Jun 2002 22:13:47 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g572HtV23335; Thu, 6 Jun 2002 21:17:55 -0500 Subject: Re: [Sip] Re: draft-ietf-sip-refer-05.txt From: Robert Sparks To: Paul Kyzivat Cc: sip@ietf.org In-Reply-To: <3CFFDC6D.F3162692@cisco.com> References: <200206061133.HAA07607@ietf.org> <3CFFDC6D.F3162692@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 21:11:03 -0500 Message-Id: <1023415864.1836.125.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Inline On Thu, 2002-06-06 at 17:04, Paul Kyzivat wrote: > I have a couple of questions - not unique to this version of the draft, equally applicable to them all I think. The following is from section 2: > > A REFER request MAY be placed outside the scope of a dialog created > with an INVITE. REFER MAY be Record-Routed, hence MUST contain a > single Contact header field value. REFERs occurring inside an > existing dialog MUST follow the Route/Record-Route logic of that > dialog. REFERs occurring outside an existing dialog effectively > create a new dialog following the behavior of SUBSCRIBE specified in > [2]. > > 1) WRT the last sentence above - subscribe dialogs have an expiration time. Suppose the refer still hasn't completed by the time the dialog is about to expire. (Perhaps an > INVITE was sent and a Ringing was returned, but the call hasn't yet succeeded or failed.) How would the UA go about refreshing the subscription? (A new REFER in the same > dialog doesn't seem right, but neither does a SUBSCRIBE.) I know what you're trying to say, but I cant follow the description of the scenario you lay out. REFER creates a subscription just like SUBSCRIBE does. That means the subscription can be refreshed with a resubscribe as in 3265 or terminated with an unsubscribe. It has become clear from private comments (seems it was about ripe for people to rediscover this particular side effect of an implicit subscription) that more clarification needs to go into the draft. Look for a revision early next week. > > Even if the dialog isn't about to expire, I might want to refresh as a way to verify that the other end is still alive, in case no notifies have been received recently. (I > should expect notifies as often as the corresponding INVITE can expect responses. > > 2) The first sentence implies that a REFER *MAY* be placed *inside* the scope of a dialog created by an invite. In fact this is an important use case. If so, are the > subsequent NOTIFY messages returned in the context of that same dialog? (If so, presumably that dialog can be refreshed with reINVITEs.) This is _the_ most important use case - the first standardized use of REFER uses exactly this case. The draft as currently written addresses this. Any notifies come with dialog identifiers matching the REFER. If the REFER was already in a dialog, the NOTIFYs will also be. Now, DO NOT mistake lifetime of subscription with lifetime of the INVITE dialog. They are separate. You would renew the subscription with resubscribe, not reinvite. There are issues with knowing how long the subscription created with a REFER is good for (until you receive the first Notify, which will let you know for sure). We've hashed through these on the list many times. The clarifications in next weeks revision will make will document these explicitly in the draft so we don't thrash on them yet another time. > > 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 daemon@optimus.ietf.org Fri Jun 7 01:10:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07221 for ; Fri, 7 Jun 2002 01:10:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29917 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 01:11:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23482; Fri, 7 Jun 2002 00:56:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23451 for ; Fri, 7 Jun 2002 00:56:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06320 for ; Fri, 7 Jun 2002 00:55:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g574tMmG019798; Fri, 7 Jun 2002 06:55:22 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g574tMa9021314; Fri, 7 Jun 2002 07:55:22 +0300 (EET DST) Message-ID: <3D003CBB.87436885@lmf.ericsson.se> Date: Fri, 07 Jun 2002 07:55:23 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] SDP in 200 with PRACK References: <3CFEFE99.AC7FC26E@lmf.ericsson.se> <3CFFBA0D.1050405@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Thanks for the comment! So, I guess I also can assume the following: There is no offer in the INVITE, so the offer from the UAS comes in the first reliable provisional response, and the answer to that comes in the PRACK. Now, in this case the offer is NOT needed in the 200, and the answer is NOT needed in the ACK (which is the case for a non-PRACK implementation). Right? A couple of other questions related to this: Q1: Bis-09 says that after the UAC has received an answer to an offer, it may generate subsequent offers in requests. The PRACK draft doesn't say anything about this, so from a protocol point of view I assume there could be a new offer in every PRACK? However, I think there was once a discussion if that really should be allowed, so... Q2: Bis-09 says that once the UAS has sent or received an answer to the initial offer, it must not generate subsequent offers in any responses to the initial INVITE. However, bis-09, nor the PRACK draft, says anything about if the UAS is allowed to send a new offer in a reliable 18x, within the INVITE transaction, if it has received (in a PRACK) an answer to a previous offer. Regards, Christer Holmberg Ericsson Finland Q3: A "cosmetic" question "The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." Should it be mentioned that this is per early dialog? An INVITE may be forked, so the UAC may receive multiple different session descriptions, so there is nothing saying that the first session description is going to be the one which finally be used (ie will be included in the 200). Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > Christer Holmberg wrote: > > Hi, > > > > The following has been discussed before, but I haven't found any > > clarification for it in the bis- or PRACK draft: > > > > Chapter 13.2.1 is bis says: > > > > "If the initial offer is in an INVITE, the answer MUST be in a > > reliable non-failure message from UAS back to UAC which is > > correlated to that INVITE. For this specification, that is > > only the final 2xx response to that INVITE. That same exact > > answer MAY also be placed in any provisional responses sent > > prior to the answer. The UAC MUST treat the first session > > description it receives as the answer, and MUST ignore any > > session descriptions in subsequent responses to the initial > > INVITE." > > > > Now, if PRACK is used, the first reliable non-failure message from the > > UAS may be a 18x provisional response, so the UAS may include an answer > > in such a message. > > Right. > > > > > My question is: does this still require that the answer which was sent > > in the 18x must also be included in the 200? > > No. The above text is mostly referring to the non-100rel case only. > There, the first reliable response is the 2xx. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 03:06:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19437 for ; Fri, 7 Jun 2002 03:06:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05698 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 03:07:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04514; Fri, 7 Jun 2002 02:35:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04478 for ; Fri, 7 Jun 2002 02:35:44 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18973 for ; Fri, 7 Jun 2002 02:35:11 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g576ZCIb016640; Thu, 6 Jun 2002 23:35:12 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADC30619; Thu, 6 Jun 2002 23:35:21 -0700 (PDT) From: "Cullen Jennings" To: Cc: "Fluffy" , "Jon Peterson" , "Mark Watson" Date: Thu, 6 Jun 2002 23:36:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Minor update of draft-ietf-sip-asserted-identity-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Until it becomes available in the archive, there is a updated version at: http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-01.html http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-01.txt Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 07:32:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23341 for ; Fri, 7 Jun 2002 07:32:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19517 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 07:33:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18286; Fri, 7 Jun 2002 07:02:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18175 for ; Fri, 7 Jun 2002 07:02:46 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22890 for ; Fri, 7 Jun 2002 07:02:14 -0400 (EDT) Received: from millcity.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57B2YDB000867; Fri, 7 Jun 2002 07:02:35 -0400 (EDT) Received: from KENJW2K1 (che-vpn1-10.cisco.com [10.86.240.10]) by millcity.cisco.com (Mirapoint) with SMTP id AAK38562; Fri, 7 Jun 2002 06:56:28 -0400 (EDT) Reply-To: From: "Ken Jordan" To: "'Jonathan Rosenberg'" , "'Tan Ya-Ching ICM N PG U ID A 1'" Cc: "'Ben Campbell'" , Subject: RE: [SIP] Expires header in MESSAGE Date: Fri, 7 Jun 2002 07:03:33 -0400 Message-ID: <002801c20e12$f79a4d00$3d02a8c0@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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CFFB576.5000206@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The concern I raised in SIP-Implementors regarding the detrimental effect of transmission delays on the intended value for the expires header (delays which includes UAS delays in forwarding) would be handled by Tan Ya-Ching's proposed text below: In Section 7. UAS Processing If there is a delay in forwarding the message, the UAS MUST subtract the difference between time of forwarding and receipt of the request from the Expires value. I would like to see this text added with Jonathans recommended changes. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Thursday, June 06, 2002 3:18 PM > To: Tan Ya-Ching ICM N PG U ID A 1 > Cc: 'Ben Campbell'; 'sip@ietf.org' > Subject: Re: [SIP] Expires header in MESSAGE > > > I think the general usage of Expires that is discussed here > is good, and > consistent with the usage envisioned for the header. However, I would > weaken many of the strengths below from MUST NOT or MUST to > SHOULD NOT > or SHOULD. > > -Jonathan R. > > Tan Ya-Ching ICM N PG U ID A 1 wrote: > > In SIP RFC 3261, only INVITE and REGISTER may include the Expires > > header. > > Section 20.19 states that "The precise meaing of this > (Expires header) > > is > > method dependent". The meanings of Expires in INVITE and > REGISTER are > > explained in detail in RFC 3261 (and in draft-ietf-sip-event for > > SUBSCRIBE). > > For example, in the section specifying UAS processing of the INVITE, > > there > > is a paragraph explaining how the UAS should handle the > Expires header > > if > > one is present in the INVITE. > > > > draft-ietf-sip-message-04 allows MESSAGE to contain the > Expires header, > > but > > does not explain the precise meaning of it. > > > > I propose to add the following statements to the draft: > > > > Section 4. UAC Processing > > > > The UAC MAY add an Expires header field to limit the > > validity of the message content. An Expires header > > field with a value of "0" is an indication to the gateway > > or store-and-forward server that the message MUST > > be delivered immediately. > > > > Section 7. UAS Processing > > > > If the MESSAGE request contains an Expires header > > field, the UAS sets a timer for the number of seconds > > indicated in the header field value. When the timer > > fires, the message is considered to be expired. If the > > message expires before the UAS displays the message > > to the user, the UAS should discard the message. A > > UAS which is a store-and-forward relay MUST NOT > > forward the message after the timer fired. When a > > message relay forwards a message, any Expires > > header field present in the MESSAGE request MUST > > be copied into the forwarded message. If there is a > > delay in forwarding the message, the UAS MUST > > substract the difference between time of forwarding > > and receipt of the request from the Expires value. > > > > A UAS receiving a MESSAGE request containing an > > Expires header field with a value of "0" MUST display the > > message to the user immediately. If the UAS is a > > store-and-forward relay, it MUST forward the message > > immediately. > > > > > > - Ya-Ching > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 09:15:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25503 for ; Fri, 7 Jun 2002 09:15:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25993 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 09:15:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24104; Fri, 7 Jun 2002 08:39:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24074 for ; Fri, 7 Jun 2002 08:39:05 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24800 for ; Fri, 7 Jun 2002 08:38:33 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g57CcWH24108 for ; Fri, 7 Jun 2002 08:38:33 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:38:32 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0051B579B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: David Oliver , "'Dean Willis'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Fri, 7 Jun 2002 13:38:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At the end of the day it does not matter what these headers are called, or whether they appear in information or standards track RFCs, people will implement and use the ones they find useful, and ignore the ones that they do not. It is not standards organisations that make standards, it is the number of interoperable implementations. Therefore at best the name of the header (i.e. P-...) can only be an extremely rough guide as to whether it is useful or not. Based on this: - I do not believe we should do any more to fragment the naming options that exist, by subdividing categories. - If a P-header appears to be more generally useful, I do not believe we should rename it. I guess I have no problem with turning the document it was specified in from informational to standards track, but it seems unnecessary and after the event to do so. Keith > -----Original Message----- > From: David Oliver [mailto:Oliverdc@securelogix.com] > Sent: 06 June 2002 17:03 > To: 'Dean Willis'; jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: RE: SIP Change Process (was RE: [Sip] > Asserted-Identity: How to > 'hint'?) > > > It seems that the problem with P-Headers is that they are > overloaded to mean > both Private/Proprietary and Preliminary/Pre-Standards-Track. > These are both > distinct from strictly experimental (X?) headers in that they > are published. > > In the Private case, publication is informational to the > Internet community > at large and serves to reserve the name, provides assistance in > understanding third party traffic, and may avoid reinventing > the wheel for > similar applications. Applicability is "restricted", but that > could mean > "only applicable to POTS, ISDN and Mobile PSTN applications"! > > In the Preliminary case, the header is believed to have unrestricted > applicability, and is urgently required, but the proposal is > insufficiently > solid to qualify for Standards Track. This could mean that only one > community's requirements have been reviewed, or that there > are known (but > unresolved) technical limitations or risks. Publication > reserves the name > (and possibly reserves the non-P name?), and provides a > suggested mechanism > for early adopters, with the caveat that changes are likely. > > Preliminary headers should either be reviewed, adapted as > necessary, and > adopted as full Standards Track headers, or rejected and > moved to Private > status. A time limit should be imposed on this process to > avoid them staying > in limbo indefinitely. > > Separating out these overloaded uses of P Headers into two distinct > namespaces could help - or at least move the controversy into a better > defined arena. > > Regards, > > David C. Oliver > Principal Engineer > SecureLogix Corp > Email: doliver@securelogix.com > Tel: 210.402.9669 > Fax: 210.402.6996 > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, June 04, 2002 2:58 PM > To: jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: SIP Change Process (was RE: [Sip] Asserted-Identity: How to > 'hint'?) > > > once ietf defines a p header for some purpose, there is far > > less motivation to produce the corresponding standards track > > sip header. the result is weaker sip and non-interoperable products. > > > That is a legitimate position to take regarding the proposed > SIP Change > Process, something that we ARE working to refine. > > ... > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 09:15:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25521 for ; Fri, 7 Jun 2002 09:15:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26050 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 09:16:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24719; Fri, 7 Jun 2002 08:55:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24689 for ; Fri, 7 Jun 2002 08:55:39 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25126 for ; Fri, 7 Jun 2002 08:55:00 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g57Csve15891 for ; Fri, 7 Jun 2002 18:24:57 +0530 (IST) Received: from Rudra ([10.115.6.189]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GXC6JF01.T1S for ; Fri, 7 Jun 2002 18:24:51 +0530 From: "Shivaprasad Shivarudrappa" To: Date: Fri, 7 Jun 2002 18:33:34 +0530 Organization: Wipro Technologies Message-ID: <000301c20e23$bb81b7c0$bd06730a@Rudra> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e517362e-76f8-11d6-ba7c-006067005148" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] Proxy Fault tolerance Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-e517362e-76f8-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C20E51.D539F3C0" ------=_NextPart_000_0004_01C20E51.D539F3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have a query on the SNMP MIB for SIP. In the sipUACSipServerTable in the SIP UA MIB it is possible to have two entries for the proxy against the same application index. This would mean that there are 2 proxies configured for a SIP end point. Are proxies configured in this manner to achieve fault tolerance ? Couldnt the same be achieved by configuring the DNS SRV records appropriately? Am i right ?? Regards, Shivaprasad S. ------=_NextPart_000_0004_01C20E51.D539F3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have a query on the SNMP MIB for SIP. In = the sipUACSipServerTable  in=20 the SIP UA MIB it is possible to = have two=20 entries for the proxy against the same application index. This would = mean that=20 there are 2 proxies configured for a SIP end point. Are proxies = configured in=20 this manner to achieve fault tolerance ? Couldnt the same be achieved by = configuring the DNS SRV records appropriately?
 
Am i=20 right ??
 
 
Regards,
Shivaprasad S.
 
 
------=_NextPart_000_0004_01C20E51.D539F3C0-- ------=_NextPartTM-000-e517362e-76f8-11d6-ba7c-006067005148-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 10:02:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26621 for ; Fri, 7 Jun 2002 10:02:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28809 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 10:03:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27897; Fri, 7 Jun 2002 09:46:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27866 for ; Fri, 7 Jun 2002 09:46:55 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26194 for ; Fri, 7 Jun 2002 09:46:22 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 7 Jun 2002 08:46:17 -0500 Message-ID: <7E06D3212981524CA10D2A114937C41484AE36@NREXCH.netrake.net> Thread-Topic: [Sip] Minor update of draft-ietf-sip-asserted-identity-01 Thread-Index: AcIN75RQDAxlGzBeQHumAeLGwtJpRgAOMdLA From: "Rob Phillips" To: "Cullen Jennings" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA27867 Subject: [Sip] Problem with draft-ietf-sip-asserted-identity-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Per 9.1 The P-Asserted-Identity Header, I think you want the BNF to look as follows: PAssertedID = "P-Asserted-Identity" HCOLON (name-addr / addr-spec) *2(COMMA PAssertedID-value] PAssertedID-value = name-addr / addr-spec The text in the current version has nothing between the HCOLON and the COMMA field. Additionally, changing the *(COMMA ...) to *2(COMMA ...) correctly modifies the BNF to reflect the subsequent text: A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. - rob -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, June 07, 2002 1:36 AM To: sip@ietf.org Cc: Fluffy; Jon Peterson; Mark Watson Subject: [Sip] Minor update of draft-ietf-sip-asserted-identity-01 Until it becomes available in the archive, there is a updated version at: http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-01.html http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-01.txt 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 daemon@optimus.ietf.org Fri Jun 7 10:39:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28583 for ; Fri, 7 Jun 2002 10:39:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01972 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 10:39:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29294; Fri, 7 Jun 2002 10:12:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29261 for ; Fri, 7 Jun 2002 10:12:12 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27001 for ; Fri, 7 Jun 2002 10:11:39 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57EC2BQ012047; Fri, 7 Jun 2002 10:12:03 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL59586; Fri, 7 Jun 2002 10:16:10 -0400 (EDT) Message-ID: <3D00BF15.A8915B6A@cisco.com> Date: Fri, 07 Jun 2002 10:11:33 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Re: draft-ietf-sip-refer-05.txt References: <200206061133.HAA07607@ietf.org> <3CFFDC6D.F3162692@cisco.com> <1023415864.1836.125.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > I know what you're trying to say, but I cant follow the description > of the scenario you lay out. Never mind. You got the point. > REFER creates a subscription just like SUBSCRIBE does. That means the > subscription can be refreshed with a resubscribe as in 3265 or > terminated with an unsubscribe. It was clear that the subscription is created, but not that it can be refreshed with resubscribe. > It has become clear from private comments (seems it was about ripe > for people to rediscover this particular side effect of an implicit > subscription) that more clarification needs to go into the draft. > Look for a revision early next week. I'm happy to wait, and cut off further discussion now, for the sake of everybody. > > 2) The first sentence implies that a REFER *MAY* be placed *inside* the scope of a dialog created by an invite. In fact this is an important use case. If so, are the > > subsequent NOTIFY messages returned in the context of that same dialog? (If so, presumably that dialog can be refreshed with reINVITEs.) > > This is _the_ most important use case - the first standardized use > of REFER uses exactly this case. The draft as currently written > addresses this. Any notifies come with dialog identifiers matching > the REFER. If the REFER was already in a dialog, the NOTIFYs will > also be. > > Now, DO NOT mistake lifetime of subscription with lifetime of the > INVITE dialog. They are separate. You would renew the subscription > with resubscribe, not reinvite. I just went back and re-read draft-ietf-sip-events-05, and realized I was remembering the details wrong. I now see that dialogs don't expire - individual subscriptions within a dialog expire. That is my mistake, and is clear enough. But I think more about subscription identity, duration, and renewal would be helpful here - it is a little unusual because of the implicit initial subscription. I presume the response to the REFER should contain an Expires header that defines the duration of the subscription. That will permit the UAC to generate a specific SUBSCRIBE to renew before the subscription expires. That does however lead to another question. In 6.3.3 you say that for the second and subsequent REFER requests a UA receives in a given dialog, it MUST include an id parameter[2] in the Event header field of each NOTIFY containing the sequence number (the number from the CSeq header field value) of the REFER this NOTIFY is associated with. This id is of course also used for refreshes, and is predictable even prior to receipt of the first NOTIFY. (Though it might not always be convenient to remember if this is the first implicit subscription in a dialog. It would be easier to predict if the Event header could be returned in the response to the REFER. But that is currently illegal.) But what happens after the first refresh? The refresh will have a unique CSeq value. Does that result in assigning a new id for the subscription? Presumably not, but worth stating explicitly. 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 daemon@optimus.ietf.org Fri Jun 7 10:43:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28795 for ; Fri, 7 Jun 2002 10:43:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02365 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 10:44:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29424; Fri, 7 Jun 2002 10:18:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29397 for ; Fri, 7 Jun 2002 10:18:50 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27308 for ; Fri, 7 Jun 2002 10:18:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g57EKOa26699 for ; Fri, 7 Jun 2002 17:20:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 17:18:46 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 17:18:45 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 17:18:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: draft-ietf-sip-refer-05.txt Date: Fri, 7 Jun 2002 17:18:45 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20305@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Re: draft-ietf-sip-refer-05.txt Thread-Index: AcIOLaqE6nlxP7q+TVSqbzBAyHpw8gAAEPtg To: , Cc: X-OriginalArrivalTime: 07 Jun 2002 14:18:45.0904 (UTC) FILETIME=[3C144100:01C20E2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA29398 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, June 07, 2002 5:12 PM > To: Robert Sparks > Cc: sip@ietf.org > Subject: Re: [Sip] Re: draft-ietf-sip-refer-05.txt > > > > > Robert Sparks wrote: > > > > I know what you're trying to say, but I cant follow the description > > of the scenario you lay out. > > Never mind. You got the point. > > > REFER creates a subscription just like SUBSCRIBE does. That > means the > > subscription can be refreshed with a resubscribe as in 3265 or > > terminated with an unsubscribe. > > It was clear that the subscription is created, but not that > it can be refreshed with resubscribe. > What about implicit unsubscribe? If I get a NOTIFY with a body of 2xx,4xx-6xx. Does that warrant an implicit unsubscribe? or do I still have to unsubscribe? /Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 11:58:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01902 for ; Fri, 7 Jun 2002 11:58:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06536 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 11:59:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05631; Fri, 7 Jun 2002 11:42:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05607 for ; Fri, 7 Jun 2002 11:42:02 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01449 for ; Fri, 7 Jun 2002 11:41:30 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g57Fh3YH008156; Fri, 7 Jun 2002 11:43:04 -0400 (EDT) Message-ID: <3D00D423.4030307@dynamicsoft.com> Date: Fri, 07 Jun 2002 11:41:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kenj@cisco.com CC: "'Tan Ya-Ching ICM N PG U ID A 1'" , "'Ben Campbell'" , sip@ietf.org Subject: Re: [SIP] Expires header in MESSAGE References: <002801c20e12$f79a4d00$3d02a8c0@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I do not support the inclusion of this text. We have not done this for INVITE, and I think the notion of setting expirations that are near in value to the transmission or processing delays is fundamentally a bad idea. They will generally result in race conditions, whereby whether the recipient even gets the data depends on the specific latency for that message, or the number of proxy hops, and so on. Such race conditions are to be avoided. Sending messages into the network just so they can be discarded is a waste of bandwidth and overall resources. I do not think we should do anything to encourage such usages, as the text below would. Thanks, Jonathan R. Ken Jordan wrote: > The concern I raised in SIP-Implementors regarding the detrimental > effect of > transmission delays on the intended value for the expires header (delays > which includes UAS delays in forwarding) would be handled by Tan > Ya-Ching's > proposed text below: > > In Section 7. UAS Processing > > If there is a delay in forwarding the message, the UAS MUST > subtract the > difference between time of forwarding and receipt of the request from > the > Expires value. > > I would like to see this text added with Jonathans recommended changes. > > >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >>Jonathan Rosenberg >>Sent: Thursday, June 06, 2002 3:18 PM >>To: Tan Ya-Ching ICM N PG U ID A 1 >>Cc: 'Ben Campbell'; 'sip@ietf.org' >>Subject: Re: [SIP] Expires header in MESSAGE >> >> >>I think the general usage of Expires that is discussed here >>is good, and >>consistent with the usage envisioned for the header. However, I would >>weaken many of the strengths below from MUST NOT or MUST to >>SHOULD NOT >>or SHOULD. >> >>-Jonathan R. >> >>Tan Ya-Ching ICM N PG U ID A 1 wrote: >> >>>In SIP RFC 3261, only INVITE and REGISTER may include the Expires >>>header. >>>Section 20.19 states that "The precise meaing of this >> >>(Expires header) >> >>>is >>>method dependent". The meanings of Expires in INVITE and >> >>REGISTER are >> >>>explained in detail in RFC 3261 (and in draft-ietf-sip-event for >>>SUBSCRIBE). >>>For example, in the section specifying UAS processing of the INVITE, >>>there >>>is a paragraph explaining how the UAS should handle the >> >>Expires header >> >>>if >>>one is present in the INVITE. >>> >>>draft-ietf-sip-message-04 allows MESSAGE to contain the >> >>Expires header, >> >>>but >>>does not explain the precise meaning of it. >>> >>>I propose to add the following statements to the draft: >>> >>>Section 4. UAC Processing >>> >>> The UAC MAY add an Expires header field to limit the >>> validity of the message content. An Expires header >>> field with a value of "0" is an indication to the gateway >>> or store-and-forward server that the message MUST >>> be delivered immediately. >>> >>>Section 7. UAS Processing >>> >>> If the MESSAGE request contains an Expires header >>> field, the UAS sets a timer for the number of seconds >>> indicated in the header field value. When the timer >>> fires, the message is considered to be expired. If the >>> message expires before the UAS displays the message >>> to the user, the UAS should discard the message. A >>> UAS which is a store-and-forward relay MUST NOT >>> forward the message after the timer fired. When a >>> message relay forwards a message, any Expires >>> header field present in the MESSAGE request MUST >>> be copied into the forwarded message. If there is a >>> delay in forwarding the message, the UAS MUST >>> substract the difference between time of forwarding >>> and receipt of the request from the Expires value. >>> >>> A UAS receiving a MESSAGE request containing an >>> Expires header field with a value of "0" MUST display the >>> message to the user immediately. If the UAS is a >>> store-and-forward relay, it MUST forward the message >>> immediately. >>> >>> >>>- Ya-Ching >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PH: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 12:11:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02485 for ; Fri, 7 Jun 2002 12:11:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09092 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 12:12:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06064; Fri, 7 Jun 2002 11:52:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06041 for ; Fri, 7 Jun 2002 11:52:06 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01675 for ; Fri, 7 Jun 2002 11:51:34 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA23112; Fri, 7 Jun 2002 17:51:52 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA24818; Fri, 7 Jun 2002 17:52:05 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 17:52:06 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E05@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Jonathan Rosenberg'" , kenj@cisco.com Cc: "'Ben Campbell'" , sip@ietf.org Subject: RE: [SIP] Expires header in MESSAGE Date: Fri, 7 Jun 2002 17:52:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The text was added for the case of a store-and-forward relay. What I was trying to say is that the duration the relay stored the message should be taken into account in the Expires header. Here was my original text : | >>> A UAS which is a store-and-forward relay MUST NOT | >>> forward the message after the timer fired. When a | >>> message relay forwards a message, any Expires | >>> header field present in the MESSAGE request MUST | >>> be copied into the forwarded message. If there is a | >>> delay in forwarding the message, the UAS MUST | >>> substract the difference between time of forwarding | >>> and receipt of the request from the Expires value. Regards, Ya-Ching | -----Original Message----- | From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] | Sent: 07 June 2002 17:41 | To: kenj@cisco.com | Cc: Tan Ya-Ching ICM N PG U ID A 1; 'Ben Campbell'; sip@ietf.org | Subject: Re: [SIP] Expires header in MESSAGE | | | I do not support the inclusion of this text. We have not done | this for | INVITE, and I think the notion of setting expirations that | are near in | value to the transmission or processing delays is fundamentally a bad | idea. They will generally result in race conditions, whereby | whether the | recipient even gets the data depends on the specific latency for that | message, or the number of proxy hops, and so on. Such race conditions | are to be avoided. Sending messages into the network just so | they can be | discarded is a waste of bandwidth and overall resources. I do | not think | we should do anything to encourage such usages, as the text | below would. | | Thanks, | Jonathan R. | | Ken Jordan wrote: | > The concern I raised in SIP-Implementors regarding the detrimental | > effect of | > transmission delays on the intended value for the expires | header (delays | > which includes UAS delays in forwarding) would be handled by Tan | > Ya-Ching's | > proposed text below: | > | > In Section 7. UAS Processing | > | > If there is a delay in forwarding the message, the UAS MUST | > subtract the | > difference between time of forwarding and receipt of the | request from | > the | > Expires value. | > | > I would like to see this text added with Jonathans | recommended changes. | > | > | >>-----Original Message----- | >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of | >>Jonathan Rosenberg | >>Sent: Thursday, June 06, 2002 3:18 PM | >>To: Tan Ya-Ching ICM N PG U ID A 1 | >>Cc: 'Ben Campbell'; 'sip@ietf.org' | >>Subject: Re: [SIP] Expires header in MESSAGE | >> | >> | >>I think the general usage of Expires that is discussed here | >>is good, and | >>consistent with the usage envisioned for the header. | However, I would | >>weaken many of the strengths below from MUST NOT or MUST to | >>SHOULD NOT | >>or SHOULD. | >> | >>-Jonathan R. | >> | >>Tan Ya-Ching ICM N PG U ID A 1 wrote: | >> | >>>In SIP RFC 3261, only INVITE and REGISTER may include the Expires | >>>header. | >>>Section 20.19 states that "The precise meaing of this | >> | >>(Expires header) | >> | >>>is | >>>method dependent". The meanings of Expires in INVITE and | >> | >>REGISTER are | >> | >>>explained in detail in RFC 3261 (and in draft-ietf-sip-event for | >>>SUBSCRIBE). | >>>For example, in the section specifying UAS processing of | the INVITE, | >>>there | >>>is a paragraph explaining how the UAS should handle the | >> | >>Expires header | >> | >>>if | >>>one is present in the INVITE. | >>> | >>>draft-ietf-sip-message-04 allows MESSAGE to contain the | >> | >>Expires header, | >> | >>>but | >>>does not explain the precise meaning of it. | >>> | >>>I propose to add the following statements to the draft: | >>> | >>>Section 4. UAC Processing | >>> | >>> The UAC MAY add an Expires header field to limit the | >>> validity of the message content. An Expires header | >>> field with a value of "0" is an indication to the gateway | >>> or store-and-forward server that the message MUST | >>> be delivered immediately. | >>> | >>>Section 7. UAS Processing | >>> | >>> If the MESSAGE request contains an Expires header | >>> field, the UAS sets a timer for the number of seconds | >>> indicated in the header field value. When the timer | >>> fires, the message is considered to be expired. If the | >>> message expires before the UAS displays the message | >>> to the user, the UAS should discard the message. A | >>> UAS which is a store-and-forward relay MUST NOT | >>> forward the message after the timer fired. When a | >>> message relay forwards a message, any Expires | >>> header field present in the MESSAGE request MUST | >>> be copied into the forwarded message. If there is a | >>> delay in forwarding the message, the UAS MUST | >>> substract the difference between time of forwarding | >>> and receipt of the request from the Expires value. | >>> | >>> A UAS receiving a MESSAGE request containing an | >>> Expires header field with a value of "0" MUST display the | >>> message to the user immediately. If the UAS is a | >>> store-and-forward relay, it MUST forward the message | >>> immediately. | >>> | >>> | >>>- Ya-Ching | >>> | >>> | >>>_______________________________________________ | >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip | >>>This list is for NEW development of the core SIP Protocol | >>>Use sip-implementors@cs.columbia.edu for questions on current sip | >>>Use sipping@ietf.org for new developments on the application of sip | >>> | >> | >> | >>-- | >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue | >>Chief Scientist First Floor | >>dynamicsoft East Hanover, NJ 07936 | >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 | >>http://www.jdrosen.net PH: (973) 952-5000 | >>http://www.dynamicsoft.com | >> | >> | >>_______________________________________________ | >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip | >>This list is for NEW development of the core SIP Protocol | >>Use sip-implementors@cs.columbia.edu for questions on current sip | >>Use sipping@ietf.org for new developments on the application of sip | > | > | | | -- | Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue | Chief Scientist First Floor | dynamicsoft East Hanover, NJ 07936 | jdrosen@dynamicsoft.com FAX: (973) 952-5050 | http://www.jdrosen.net PH: (973) 952-5000 | http://www.dynamicsoft.com | _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 12:18:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02677 for ; Fri, 7 Jun 2002 12:18:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09460 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 12:19:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05796; Fri, 7 Jun 2002 11:46:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05765 for ; Fri, 7 Jun 2002 11:46:06 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01554 for ; Fri, 7 Jun 2002 11:45:34 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g57FlGYH008163; Fri, 7 Jun 2002 11:47:16 -0400 (EDT) Message-ID: <3D00D51F.1060702@dynamicsoft.com> Date: Fri, 07 Jun 2002 11:45:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: sip@ietf.org Subject: Re: [Sip] UTF-8 in SIP URIs References: <20020606221154.21433.qmail@web11603.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think the assumption is stated anywhere, but I always assumed it was US-ASCII. What is the need to escape any of the non-US-ASCII characters? I didn't see where in the HTTP spec it talks about this, though.... -Jonathan R. Sean Olson wrote: > That section of RFC 2396 also states that a URI > scheme can make a scheme-specific decision about > how to handle non-US-ASCII. My question boils down > to whether such a decision has been made for the > sip(s): URI scheme(s). For example, FTP and HTTP > URI schemes both appear to have text surrounding > this. Eventually I would expect something like > this for SIP. An informational or perhaps BCP > on how I18N works with SIP. > > Thanks! > /sean > > --- Jonathan Rosenberg > wrote: > >>Section 2.1 of rfc 2396 explains why it should in >>theory be possible to >>use non-ascii, but that there is no way right now, >>and it will be >>addressed in a revision. Others more clued into >>internationalization >>issues may have a more up-to-date answer... >> >>-Jonathan R. >> >>Sean Olson wrote: >> >>>Just a question for clarification. For escaped >>>characters in a SIP URI, is it assumed that those >>>octects represent a UTF-8 encoded character? Or >>>are other encodings possible? >>> >>>/sean >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Yahoo! - Official partner of 2002 FIFA World Cup >>>http://fifaworldcup.yahoo.com >>> >>>_______________________________________________ >>>Sip mailing list >> >>https://www1.ietf.org/mailman/listinfo/sip >> >>>This list is for NEW development of the core SIP >> >>Protocol >> >>>Use sip-implementors@cs.columbia.edu for questions >> >>on current sip >> >>>Use sipping@ietf.org for new developments on the >> >>application of sip >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle >>Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East >>Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) >>952-5050 >>http://www.jdrosen.net PH: (973) >>952-5000 >>http://www.dynamicsoft.com >> > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 12:35:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03524 for ; Fri, 7 Jun 2002 12:35:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10554 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 12:36:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09274; Fri, 7 Jun 2002 12:15:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09243 for ; Fri, 7 Jun 2002 12:15:35 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02595 for ; Fri, 7 Jun 2002 12:15:03 -0400 (EDT) Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g57GFLK09738; Fri, 7 Jun 2002 11:15:22 -0500 (CDT) Message-ID: <3D00DBFE.5090605@dynamicsoft.com> Date: Fri, 07 Jun 2002 11:14:54 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: kenj@cisco.com, "'Tan Ya-Ching ICM N PG U ID A 1'" , sip@ietf.org Subject: Re: [SIP] Expires header in MESSAGE References: <002801c20e12$f79a4d00$3d02a8c0@cisco.com> <3D00D423.4030307@dynamicsoft.com> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I do not support the inclusion of this text. We have not done this for > INVITE, and I think the notion of setting expirations that are near in > value to the transmission or processing delays is fundamentally a bad > idea. They will generally result in race conditions, whereby whether the > recipient even gets the data depends on the specific latency for that > message, or the number of proxy hops, and so on. Such race conditions > are to be avoided. Sending messages into the network just so they can be > discarded is a waste of bandwidth and overall resources. I do not think > we should do anything to encourage such usages, as the text below would. > That makes sense for small transmission and processing delays. But what about store and forward situations, where the delay time could be very long? This situation pretty much breaks the whole idea of delta time Exires headers. > > Ken Jordan wrote: > >> The concern I raised in SIP-Implementors regarding the detrimental >> effect of >> transmission delays on the intended value for the expires header (delays >> which includes UAS delays in forwarding) would be handled by Tan >> Ya-Ching's >> proposed text below: >> >> In Section 7. UAS Processing >> >> If there is a delay in forwarding the message, the UAS MUST >> subtract the >> difference between time of forwarding and receipt of the request from >> the >> Expires value. >> >> I would like to see this text added with Jonathans recommended changes. >> >> >>> -----Original Message----- >>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >>> Jonathan Rosenberg >>> Sent: Thursday, June 06, 2002 3:18 PM >>> To: Tan Ya-Ching ICM N PG U ID A 1 >>> Cc: 'Ben Campbell'; 'sip@ietf.org' >>> Subject: Re: [SIP] Expires header in MESSAGE >>> >>> >>> I think the general usage of Expires that is discussed here >>> is good, and >>> consistent with the usage envisioned for the header. However, I would >>> weaken many of the strengths below from MUST NOT or MUST to >>> SHOULD NOT >>> or SHOULD. >>> >>> -Jonathan R. >>> >>> Tan Ya-Ching ICM N PG U ID A 1 wrote: >>> >>>> In SIP RFC 3261, only INVITE and REGISTER may include the Expires >>>> header. >>>> Section 20.19 states that "The precise meaing of this >>> >>> >>> (Expires header) >>> >>>> is >>>> method dependent". The meanings of Expires in INVITE and >>> >>> >>> REGISTER are >>> >>>> explained in detail in RFC 3261 (and in draft-ietf-sip-event for >>>> SUBSCRIBE). >>>> For example, in the section specifying UAS processing of the INVITE, >>>> there >>>> is a paragraph explaining how the UAS should handle the >>> >>> >>> Expires header >>> >>>> if >>>> one is present in the INVITE. >>>> >>>> draft-ietf-sip-message-04 allows MESSAGE to contain the >>> >>> >>> Expires header, >>> >>>> but >>>> does not explain the precise meaning of it. >>>> >>>> I propose to add the following statements to the draft: >>>> >>>> Section 4. UAC Processing >>>> >>>> The UAC MAY add an Expires header field to limit the >>>> validity of the message content. An Expires header >>>> field with a value of "0" is an indication to the gateway >>>> or store-and-forward server that the message MUST >>>> be delivered immediately. >>>> >>>> Section 7. UAS Processing >>>> >>>> If the MESSAGE request contains an Expires header >>>> field, the UAS sets a timer for the number of seconds >>>> indicated in the header field value. When the timer >>>> fires, the message is considered to be expired. If the >>>> message expires before the UAS displays the message >>>> to the user, the UAS should discard the message. A >>>> UAS which is a store-and-forward relay MUST NOT >>>> forward the message after the timer fired. When a >>>> message relay forwards a message, any Expires >>>> header field present in the MESSAGE request MUST >>>> be copied into the forwarded message. If there is a >>>> delay in forwarding the message, the UAS MUST >>>> substract the difference between time of forwarding >>>> and receipt of the request from the Expires value. >>>> >>>> A UAS receiving a MESSAGE request containing an >>>> Expires header field with a value of "0" MUST display the >>>> message to the user immediately. If the UAS is a >>>> store-and-forward relay, it MUST forward the message >>>> immediately. >>>> >>>> >>>> - Ya-Ching >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>> Chief Scientist First Floor >>> dynamicsoft East Hanover, NJ 07936 >>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PH: (973) 952-5000 >>> http://www.dynamicsoft.com >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 13:33:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05068 for ; Fri, 7 Jun 2002 13:33:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18077 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 13:33:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01565; Fri, 7 Jun 2002 13:05:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01536 for ; Fri, 7 Jun 2002 13:05:14 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04167 for ; Fri, 7 Jun 2002 13:04:44 -0400 (EDT) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57H577p027118; Fri, 7 Jun 2002 13:05:07 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAL61019; Fri, 7 Jun 2002 13:09:15 -0400 (EDT) Message-ID: <3D00E7A5.161C6025@cisco.com> Date: Fri, 07 Jun 2002 13:04:37 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: rsparks@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Re: draft-ietf-sip-refer-05.txt References: <2038BCC78B1AD641891A0D1AE133DBB7C20305@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > What about implicit unsubscribe? If I get a NOTIFY with a body of 2xx,4xx-6xx. Does that warrant an implicit unsubscribe? or do I still have to unsubscribe? > I believe normally the NOTIFY that carries the final response would also terminate the subscription. However that isn't required, so if it doesn't, then I suppose you would need to explicitly unsubscribe, or just wait. 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 daemon@optimus.ietf.org Fri Jun 7 13:45:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05446 for ; Fri, 7 Jun 2002 13:45:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18595 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 13:46:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27358; Fri, 7 Jun 2002 13:14:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27268 for ; Fri, 7 Jun 2002 13:14:19 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04490 for ; Fri, 7 Jun 2002 13:13:48 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A9E7C941014E; Fri, 07 Jun 2002 13:14:15 -0400 Message-ID: <014501c20e46$d0ff7f60$2300000a@acmepacket.com> From: "Bob Penfield" To: "Miguel A. Garcia" , "Tan Ya-Ching ICM N PG U ID A 1" Cc: References: <5B4D0C5BA65ECA46969C1419122317E6E74DF3@mchh161e> <3CFDE6AF.878D9B1F@ericsson.com> Subject: Re: [SIP] draft-garcia-sip-visited-network-id-03 Date: Fri, 7 Jun 2002 13:14:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Miguel A. Garcia" > > Tan Ya-Ching ICM N PG U ID A 1 wrote: > > > > - This is a repeated comment: > > Section 4, the paragraph after the example > > "a SIP proxy may insert a new P-Visited-Network-ID header > > if the request does not contain a P-Visited-Network-ID > > header with the same network identifier as its own network > > identifier". > > However, Table 2 of SIP shows that proxy cannot "r"ead > > the header. You explained in your email that the header may > > be encrypted and so cannot be read, but that is not clear to > > the readers of the draft. > > I am adding this new paragraph to explain thesituation: > > Note also that, there is not requirement for the header to be readable in the > proxies. Therefore, a first proxy may insert an encrypted header that only the > registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) > located in the same administrative domain as the first proxy, the second proxy will > not be able to read the contents of the P-Visited-Network-ID header. In this > situation, the second proxy will consider that its visited network identifier is not > already present in the value of the header, and therefore, it will insert a new P- > Visited-Network-ID header value (hopefully with the same visited network identifier). > When the request arrives at the registrar, it will notice that the header value is > repeated (both the first and the second proxy inserted it). The decrypted values > should be the same, because both proxies where part of the same administrative > domain. While this situation is not desirable, it does not create any harm at the > registrar. > You probably need to use the term "intermediary", as pure proxies would not be allowed to modify the message body and thus could not add a body with the excrypted header. Are you suggesting that there will be intermediaries in the network that will add an encrypted S/MIME "sip/message" body? If that is not the case, only the UA would encrypt the header, but the UA is not allowed to insert the header. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 14:36:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08035 for ; Fri, 7 Jun 2002 14:36:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21737 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 14:37:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20071; Fri, 7 Jun 2002 14:08:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20045 for ; Fri, 7 Jun 2002 14:08:07 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06593 for ; Fri, 7 Jun 2002 14:07:36 -0400 (EDT) Received: from millcity.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57I7wLQ002396; Fri, 7 Jun 2002 14:07:58 -0400 (EDT) Received: from KENJW2K1 (dhcp-161-44-231-99.cisco.com [161.44.231.99]) by millcity.cisco.com (Mirapoint) with SMTP id AAK40313; Fri, 7 Jun 2002 14:01:52 -0400 (EDT) Reply-To: From: "Ken Jordan" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [SIP] Expires header in MESSAGE Date: Fri, 7 Jun 2002 14:08:58 -0400 Message-ID: <003d01c20e4e$65c1e8c0$3d02a8c0@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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D00D423.4030307@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, Thank you for your patience and response. It is difficult for clients to know what value to set for the expires value since, as you point out, there's no way to know what path will be taken (i.e. what UAS or proxy with their associated delay will be used, number of hops, etc). I agree with the implicit fact that handling the expires field in a meaningful way in all uses across SIP and accounting for end-end delays (which will include UAS delays in processing the messages) is a complicated and slippery slope. Given that timeouts are in place to handle long end-end delays, is it possible for a UA or proxy to receive an INVITE or REGISTER that is near expiration or has already expired? If so, how would the UA or proxy know? What recommendation would you give on how a UA determines the minimum expires value that should be used? (You indicated in an earlier response that the expires value should be several orders of magnitude larger than the transmission delays.) Should it be substantially larger than the timeout value (timeout=32 seconds)? Does bis-09 already have a recommended value or method for determining it? Thanks again for your help, Ken > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Friday, June 07, 2002 11:41 AM > To: kenj@cisco.com > Cc: 'Tan Ya-Ching ICM N PG U ID A 1'; 'Ben Campbell'; sip@ietf.org > Subject: Re: [SIP] Expires header in MESSAGE > > > I do not support the inclusion of this text. We have not done > this for > INVITE, and I think the notion of setting expirations that > are near in > value to the transmission or processing delays is fundamentally a bad > idea. They will generally result in race conditions, whereby > whether the > recipient even gets the data depends on the specific latency for that > message, or the number of proxy hops, and so on. Such race conditions > are to be avoided. Sending messages into the network just so > they can be > discarded is a waste of bandwidth and overall resources. I do > not think > we should do anything to encourage such usages, as the text > below would. > > Thanks, > Jonathan R. > > Ken Jordan wrote: > > The concern I raised in SIP-Implementors regarding the detrimental > > effect of > > transmission delays on the intended value for the expires > header (delays > > which includes UAS delays in forwarding) would be handled by Tan > > Ya-Ching's > > proposed text below: > > > > In Section 7. UAS Processing > > > > If there is a delay in forwarding the message, the UAS MUST > > subtract the > > difference between time of forwarding and receipt of the > request from > > the > > Expires value. > > > > I would like to see this text added with Jonathans > recommended changes. > > > > > >>-----Original Message----- > >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > >>Jonathan Rosenberg > >>Sent: Thursday, June 06, 2002 3:18 PM > >>To: Tan Ya-Ching ICM N PG U ID A 1 > >>Cc: 'Ben Campbell'; 'sip@ietf.org' > >>Subject: Re: [SIP] Expires header in MESSAGE > >> > >> > >>I think the general usage of Expires that is discussed here > >>is good, and > >>consistent with the usage envisioned for the header. > However, I would > >>weaken many of the strengths below from MUST NOT or MUST to > >>SHOULD NOT > >>or SHOULD. > >> > >>-Jonathan R. > >> > >>Tan Ya-Ching ICM N PG U ID A 1 wrote: > >> > >>>In SIP RFC 3261, only INVITE and REGISTER may include the Expires > >>>header. > >>>Section 20.19 states that "The precise meaing of this > >> > >>(Expires header) > >> > >>>is > >>>method dependent". The meanings of Expires in INVITE and > >> > >>REGISTER are > >> > >>>explained in detail in RFC 3261 (and in draft-ietf-sip-event for > >>>SUBSCRIBE). > >>>For example, in the section specifying UAS processing of > the INVITE, > >>>there > >>>is a paragraph explaining how the UAS should handle the > >> > >>Expires header > >> > >>>if > >>>one is present in the INVITE. > >>> > >>>draft-ietf-sip-message-04 allows MESSAGE to contain the > >> > >>Expires header, > >> > >>>but > >>>does not explain the precise meaning of it. > >>> > >>>I propose to add the following statements to the draft: > >>> > >>>Section 4. UAC Processing > >>> > >>> The UAC MAY add an Expires header field to limit the > >>> validity of the message content. An Expires header > >>> field with a value of "0" is an indication to the gateway > >>> or store-and-forward server that the message MUST > >>> be delivered immediately. > >>> > >>>Section 7. UAS Processing > >>> > >>> If the MESSAGE request contains an Expires header > >>> field, the UAS sets a timer for the number of seconds > >>> indicated in the header field value. When the timer > >>> fires, the message is considered to be expired. If the > >>> message expires before the UAS displays the message > >>> to the user, the UAS should discard the message. A > >>> UAS which is a store-and-forward relay MUST NOT > >>> forward the message after the timer fired. When a > >>> message relay forwards a message, any Expires > >>> header field present in the MESSAGE request MUST > >>> be copied into the forwarded message. If there is a > >>> delay in forwarding the message, the UAS MUST > >>> substract the difference between time of forwarding > >>> and receipt of the request from the Expires value. > >>> > >>> A UAS receiving a MESSAGE request containing an > >>> Expires header field with a value of "0" MUST display the > >>> message to the user immediately. If the UAS is a > >>> store-and-forward relay, it MUST forward the message > >>> immediately. > >>> > >>> > >>>- Ya-Ching > >>> > >>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sipping@ietf.org for new developments on the application of sip > >>> > >> > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > >>Chief Scientist First Floor > >>dynamicsoft East Hanover, NJ 07936 > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PH: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 7 14:54:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08471 for ; Fri, 7 Jun 2002 14:54:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22656 for sip-archive@odin.ietf.org; Fri, 7 Jun 2002 14:55:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21226; Fri, 7 Jun 2002 14:30:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21164 for ; Fri, 7 Jun 2002 14:30:17 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07728 for ; Fri, 7 Jun 2002 14:29:46 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jun 2002 13:29:29 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE30@jupiter> From: David Oliver To: "'Drage, Keith (Keith)'" , "'Dean Willis'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) Date: Fri, 7 Jun 2002 13:29:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Keith, Personally, I tend to agree with you, but people seem to be concerned that P-headers are both too weak (not standardized) and too strong (a back door way to get something standardized). This may be partly related to the differences between the Internet and ITU/PSTN standards processes (I recall overhearing at one TIA/EIA meeting that only documents from government approved bodies can be standards). The right answer is probably education, combined with better language in documents explaining why they are using P-Headers, rather than going straight for full headers. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: doliver@securelogix.com Tel: 210.402.9669 Fax: 210.402.6996 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Friday, June 07, 2002 7:39 AM To: David Oliver; 'Dean Willis'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?) At the end of the day it does not matter what these headers are called, or whether they appear in information or standards track RFCs, people will implement and use the ones they find useful, and ignore the ones that they do not. It is not standards organisations that make standards, it is the number of interoperable implementations. Therefore at best the name of the header (i.e. P-...) can only be an extremely rough guide as to whether it is useful or not. Based on this: - I do not believe we should do any more to fragment the naming options that exist, by subdividing categories. - If a P-header appears to be more generally useful, I do not believe we should rename it. I guess I have no problem with turning the document it was specified in from informational to standards track, but it seems unnecessary and after the event to do so. Keith <...> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 8 22:04:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15072 for ; Sat, 8 Jun 2002 22:04:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22777 for sip-archive@odin.ietf.org; Sat, 8 Jun 2002 22:05:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21490; Sat, 8 Jun 2002 21:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21462 for ; Sat, 8 Jun 2002 21:29:51 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14398 for ; Sat, 8 Jun 2002 21:28:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g591Pqss011496; Sat, 8 Jun 2002 21:25:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Jun 2002 21:28:37 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1B8@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Tan Ya-Ching ICM N PG U ID A 1 Cc: Adam Roach , "'sip@ietf.org'" Subject: RE: [SIP] NOTIFY request MUST contain an Expires header? Date: Sat, 8 Jun 2002 21:28:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Tan Ya-Ching ICM N PG U ID A 1 wrote: > > > > Thanks for the answer. > > > > In that case, shouldn't the "expires" parameter in the > > Subscription-State > > header in NOTIFY carry the same MUST strength as for > Expires header in > > 200 > > OK response to SUBSCRIBE, instead of just a SHOULD (second last > > paragraph of > > 4.2.2 of draft-sip-events)? Section 4.2.4 'Subscriber > NOTIFY Behavior' > > also > > talks about the "expires" parameter with "If the Subscription-State > > header > > also contains an "expires" parameter...", but what if it > does not ? Can > > a > > NOTIFY request which matches (according to 4.3.4) the > SUBSCRIBE request > > create a subscription and a new dialog if its > Subscription-State does > > not > > contain an "expires" parameter ? > > Yes, this is a good point. I believe this is probably an error in > sip-events, and that the expires parameter needs to be > present with MUST > strength. > > Adam? The thought around the current way it is worded is that it's not strictly necessary (or even all that useful) to include that information after the first NOTIFY has been sent. I agree that this should be spelled out more clearly, and possibly have a MUST strength for any dialog-establishing NOTIFY messages. To avoid having the draft kicked out of the publication process, we'll have to fix this in the next go-around. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jun 9 10:12:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01270 for ; Sun, 9 Jun 2002 10:11:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24488 for sip-archive@odin.ietf.org; Sun, 9 Jun 2002 10:12:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23700; Sun, 9 Jun 2002 09:49:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23669 for ; Sun, 9 Jun 2002 09:49:33 -0400 (EDT) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00909 for ; Sun, 9 Jun 2002 09:48:19 -0400 (EDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g59DVmG28292 for ; Sun, 9 Jun 2002 16:31:53 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Sun, 9 Jun 2002 16:50:09 +0300 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] No answer in 200 (INVITE) for draft-ietf-sip-update-02 Date: Sun, 9 Jun 2002 16:50:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20FBC.8DD138C4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20FBC.8DD138C4 Content-Type: text/plain; charset="windows-1255" Hi all, draft-ietf-sip-update-02 section 8 Example Call Flow presents 200(INVITE) with no SDP. However, draft-ietf-sip-rfc2543bis-09.txt section 13.2.1 reads the following: "Concretely, the above rules specify two exchanges - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges." Do we have contradiction ? Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C20FBC.8DD138C4 Content-Type: text/html; charset="windows-1255" [Sip] No answer in 200 (INVITE) for draft-ietf-sip-update-02

Hi all,

draft-ietf-sip-update-02 section 8 Example Call Flow presents 200(INVITE) with no SDP.
However, draft-ietf-sip-rfc2543bis-09.txt section 13.2.1 reads the following:

   "Concretely, the above rules specify two exchanges - the offer is in
   the INVITE, and the answer in the 2xx (and possibly in a 1xx as well,
   with the same value), or the offer is in the 2xx, and the answer is
   in the ACK. All user agents that support INVITE MUST support these
   two exchanges."

Do we have contradiction ?

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C20FBC.8DD138C4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jun 9 11:53:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04237 for ; Sun, 9 Jun 2002 11:53:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27391 for sip-archive@odin.ietf.org; Sun, 9 Jun 2002 11:54:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27078; Sun, 9 Jun 2002 11:34:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27049 for ; Sun, 9 Jun 2002 11:34:29 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03689 for ; Sun, 9 Jun 2002 11:33:26 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g59FZ0YH009227; Sun, 9 Jun 2002 11:35:01 -0400 (EDT) Message-ID: <3D03753F.8020706@dynamicsoft.com> Date: Sun, 09 Jun 2002 11:33:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: sip@ietf.org Subject: Re: [Sip] No answer in 200 (INVITE) for draft-ietf-sip-update-02 References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Fuxbruner, Amihay wrote: > Hi all, > > draft-ietf-sip-update-02 section 8 Example Call Flow presents > 200(INVITE) with no SDP. > However, draft-ietf-sip-rfc2543bis-09.txt section 13.2.1 reads the > following: > > "Concretely, the above rules specify two exchanges - the offer is in > the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, > > with the same value), or the offer is in the 2xx, and the answer is > in the ACK. All user agents that support INVITE MUST support these > two exchanges." That applies to devices compliant to bis alone. The normative rules specified in the bullet items are more generic, and would allow for different flows through things like 100rel and UPDATE. The example flow in UPDATE is correct. I can see why this is confusing. I'll make a note of it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 03:46:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24798 for ; Mon, 10 Jun 2002 03:46:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12139 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 03:47:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10181; Mon, 10 Jun 2002 03:05:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10135 for ; Mon, 10 Jun 2002 03:05:37 -0400 (EDT) Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24006 for ; Mon, 10 Jun 2002 03:05:00 -0400 (EDT) From: frank.derks@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl6.philips.com (Postfix) with ESMTP id 0A87DA10ED for ; Mon, 10 Jun 2002 09:05:34 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA27943 for ; Mon, 10 Jun 2002 09:05:33 +0200 (MET DST) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA10193 for ; Mon, 10 Jun 2002 09:05:32 +0200 (MET DST) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 10 Jun 2002 09:03:42 +0200 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 10/06/2002 09:06:37, Serialize complete at 10/06/2002 09:06:37 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0026F431C1256BD4_=" Subject: [Sip] draft-ietf-sip-rfc2543bis-09 and the offer/answer model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 0026F431C1256BD4_= Content-Type: text/plain; charset="us-ascii" The latest version of the SIP draft contains the following text: "The offer/answer model defines restrictions on when offers and answers can be made. This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted." The first sentence states that the offer/answer model defines when offers and answers can be made. From draft-ietf-mmusic-sdp-offer-answer-02, it does not really become clear that this is the case. Which restrictions are being referred to? Regards, Frank --=_alternative 0026F431C1256BD4_= Content-Type: text/html; charset="us-ascii"
The latest version of the SIP draft contains the following text:

"The offer/answer model defines restrictions on when offers and answers
can be made. This results in restrictions on where the offers and
answers can appear in SIP messages. In this specification, offers and
answers can only appear in INVITE requests and responses, and ACK. The
usage of offers and answers is further restricted."

The first sentence states that the offer/answer model defines when offers
and answers can be made. From draft-ietf-mmusic-sdp-offer-answer-02, it
does not really become clear that this is the case. Which restrictions
are being referred to?


Regards,

Frank --=_alternative 0026F431C1256BD4_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 05:02:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25881 for ; Mon, 10 Jun 2002 05:02:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA17184 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 05:02:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15455; Mon, 10 Jun 2002 04:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15429 for ; Mon, 10 Jun 2002 04:41:56 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25504 for ; Mon, 10 Jun 2002 04:41:22 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5A8gK619220 for ; Mon, 10 Jun 2002 11:42:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Jun 2002 11:41:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 11:41:52 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 11:41:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Jun 2002 11:41:51 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20306@esebe019.NOE.Nokia.com> Thread-Topic: Empty Allow header Thread-Index: AcIQWqre1DxofFYVQA+MsmeKO71Igw== To: X-OriginalArrivalTime: 10 Jun 2002 08:41:52.0774 (UTC) FILETIME=[AB5AA260:01C2105A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15431 Subject: [Sip] Empty Allow header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is an Allow-header allowed to be empty? The syntax in bis-09 suggests that this is not allowed. Allow = "Allow" HCOLON Method *(COMMA Method) If it is allowed, does it mean that the UAS does not support any methods? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 05:13:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26068 for ; Mon, 10 Jun 2002 05:13:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA18159 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 05:14:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15946; Mon, 10 Jun 2002 04:51:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15916 for ; Mon, 10 Jun 2002 04:51:30 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25672 for ; Mon, 10 Jun 2002 04:50:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5A8ps626819 for ; Mon, 10 Jun 2002 11:51:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Jun 2002 11:51:27 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 11:51:27 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 11:51:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Jun 2002 11:51:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20307@esebe019.NOE.Nokia.com> Thread-Topic: NOTIFY after a SUBSCRIBE has expired Thread-Index: AcIQXACp1Nv7YqirTlKIgs4VvWN7ug== To: X-OriginalArrivalTime: 10 Jun 2002 08:51:27.0240 (UTC) FILETIME=[01C33080:01C2105C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA15917 Subject: [Sip] NOTIFY after a SUBSCRIBE has expired Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sorry if I missed this in the draft. UA1 sends a SUBSCRIBE with expires 3600 UA2 responds with 200 ok followed by NOTIFY. Now, 3600 seconds later, the subscription has not been refreshed, so UA1 deletes all information cached about the subscription. UA2 realises that the subscription has expired and sends a NOTIFY with subscription-state of terminated. UA1 receives this NOTIFY, doesn't find a dialog and rejects the NOTIFY with 481. This does not seem to be the correct behaviour. UA1 should not remove any dialog information until it receives a NOTIFY with subscription-state terminated. Is this the correct behaviour? Is this mentioned anywhere in events-05? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 06:51:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27617 for ; Mon, 10 Jun 2002 06:51:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23249 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 06:51:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22004; Mon, 10 Jun 2002 06:28:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21976 for ; Mon, 10 Jun 2002 06:28:47 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27175 for ; Mon, 10 Jun 2002 06:28:11 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA02791; Mon, 10 Jun 2002 11:28:12 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard2 (4.6.1.91) with ESMTP id for ; Mon, 10 Jun 2002 11:26:55 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 10 Jun 2002 11:26:56 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jun 2002 11:26:59 +0100 Message-Id: To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt Date: Mon, 10 Jun 2002 11:26:57 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, With regards to the following issue: [Duncan] The definition for the cell-id is just that it is a string of > hex. > It is defined already in 3GPP specifications. I agree the current text > in > my draft is probably not adding much. I can't reference 3GPP > specifications > though, right? I wanted to describe it in this draft, as "You can put > anything you want in here as a 'string'." "3GPP mobiles will be limited > by > 3GPP specifications as to what they can put in there." [/Duncan] I don't see why you don't define the values in this spec... shouldn't these specs at least stand alone and work outside of 3gpp so long as the applicability statement holds true? I don't understand your point. I think this draft does stand alone, in that it gives you the SIP header definition and the fields that go in that header, and then it tells you that the content of some of the fields is a string of text. If some standards body X want to use the 'cgi-3gpp' filed and put some random parameter (like screen size) in there, then I guess they can, as long as it is clearly specified in their own specs? The coding, for example, of a GERAN Cell ID, is specified within 3GPP, and has been for some time. The P-Access-Network-Info header is designed to carry ANYTHING related to the access network. Currently, my draft defines two specific chunks of information (merely to break the information down into sensible bits of information, rather than just saying 'Cell-ID' (yes, the draft is intended to satisfy a 3gpp requirement, but if possible I wanted it to be (potentially) useable by others): 1. Access-type; and 2. Access-info. Access-type was designed to contain ANYTHING. That was the idea. However, some obvious values for the access-type filed have been specified in this draft. There is the possibility to add further values. Access-info was intended to be able to contain ANYTHING. 3GPP has the specific requirement to carry, for instance, a CGI ("cgi-3gpp=01 FF 00 FF FF FF FF" ). I don't want to define how you code the stuff after the '=' because this is defined in 3GPP. All I want to do is say that any system using a 3GPP radio access network might want to send the cell ID, in which case they shall use this parameter, and everything to the right of the '=' is just text that the receiver will understand based on 3GPP specs. I thought I'd done this? I thought 'Quoted-string' was enough. It's difficult, when I can't reference the 3GPP specification. Best Regards, Duncan -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 06 June 2002 22:30 To: duncan.mills@vf.vodafone.co.uk Cc: sip@ietf.org Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt duncan.mills@vf.vodafone.co.uk wrote: > Jonathan, >>For instance, >> the type of access being used may influence home network decisions >> on what level of security to apply to sessions. > > > I don't see what the access network has to do with session level > security (or what proxies have to do with session level security). > > [Duncan] Just that where the access network is a GPRS network provided > by > OpCo1 and the 3GPP IMS (SIP) network is also provided by OpCo1, then an > operator may decide that the level of security applied to the > application > layer needs to be either lower (GPRS provides security) or higher (If > there's a wireless link involved, let's be more careful. [/Duncan] Just because GPRS provides security doesn't say anything about sip security. Lets be careful here. >>The home network must know the possible values that a particular UA >> may use to populate the access-type and access-info fields. >> >> In other words, a home network with business agreements allowing >> users to access via a particular technology must be able to parse >> the P-Access-Network-Info header containing an access-type for that > > >> technology in order to use this information. >> >> For example, the access-type could read "IEEE-802.11b". If a home >> network knows it has a business agreement with a W-LAN access >> network, it must be ready to understand the value "IEEE-802.11b". >> Similarly, a UAC supporting this extension that can access via > > W-LAN > >> must be able to insert the relevant value. > > > This text confuses me, since it tries to belabor an obvious point - that > the proxy must know how to parse these values. Maybe I am missing > something. Perhaps this is related to the fact that no definition is > provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't > just provide a definition for those and then delete the statements > above. > > > [Duncan] The definition for the cell-id is just that it is a string of > hex. > It is defined already in 3GPP specifications. I agree the current text > in > my draft is probably not adding much. I can't reference 3GPP > specifications > though, right? I wanted to describe it in this draft, as "You can put > anything you want in here as a 'string'." "3GPP mobiles will be limited > by > 3GPP specifications as to what they can put in there." [/Duncan] I don't see why you don't define the values in this spec... shouldn't these specs at least stand alone and work outside of 3gpp so long as the applicability statement holds true? >>This document does not define either the nature of the information >> or the messages where the P-Access-Network-Info needs to be >> inserted. > > > This is confusing; it does define the nature of the information. What am > I missing? > > > [Duncan] OK, bad wording again. What I mean is that this document only > provides *some* values to put in the 'access-type' and 'access-info' > fields. > There's the chance for other people to define their own tokens etc. The > nature of the information is not meant to be restricted to providing the > cell ID (that's how 3GPP may use this extension, yes, but another system > may > want to say 'Airport Lounge' in the access-info field). That's waht I > meant > to say, but I agree, I need to re-word it. [/Duncan] If you want to define some baseline values, but allow others to register or use additional values, then you should say that. > > > >>A proxy, typically located in the home network, and therefore >> trusted, MUST delete the header when the SIP signaling is forwarded > > >> to a SIP server located in a non-trusted administrative network >> domain. The access network information is used by a home network > > and > >> is of no interest to the destination >> network. > > > What about a trusted administrative network domain? I think that the > home proxy MUST strip this in all cases. > > > [Duncan] Well, a home proxy may wish to leave the header in and forward > the > message to an Application Server. As long as this is all in the home > trusted domain, then it's okay? [/Duncan] It gets back to the privacy issue. THe caller may not wish for other domains to know my location. You don't have a way to express privacy preferences, so you have to strip it when sending to any other administrative domain. App servers within the same home domain are ok i guess. >> UAs are expected to provide correct information. However, there are >> no security problems resulting from a UAC inserting incorrect >> information. > > > Well, I doubt that is true in the case of cell-id. Providing false > location information can be used for all sorts of bad things. > > [Duncan] A rogue user or rogue implementation putting false cell-ID > information in this header means that the user doesn't get the correct > address for the nearest Pizza Restaurant, or doesn't get to their > voicemail > from abroad. It would be a nasty fault, but is it really that much of a > security problem? [/Duncan] The 911 operators might not like it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 07:35:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29024 for ; Mon, 10 Jun 2002 07:35:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26008 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 07:35:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24681; Mon, 10 Jun 2002 07:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24650 for ; Mon, 10 Jun 2002 07:20:17 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28687; Mon, 10 Jun 2002 07:19:34 -0400 (EDT) Message-Id: <200206101119.HAA28687@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, 10 Jun 2002 07:19:34 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-05.txt Pages : 18 Date : 07-Jun-02 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-guidelines-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-guidelines-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607140149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140149.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 07:38:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29200 for ; Mon, 10 Jun 2002 07:38:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26133 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 07:39:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24773; Mon, 10 Jun 2002 07:20:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24714 for ; Mon, 10 Jun 2002 07:20:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28671; Mon, 10 Jun 2002 07:19:27 -0400 (EDT) Message-Id: <200206101119.HAA28671@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, 10 Jun 2002 07:19:27 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-privacy-general-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Privacy Mechanism for the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-ietf-sip-privacy-general-01.txt Pages : 29 Date : 07-Jun-02 This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new 'privacy service' logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-privacy-general-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-privacy-general-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607140138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-privacy-general-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-privacy-general-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140138.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 07:42:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29370 for ; Mon, 10 Jun 2002 07:42:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26387 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 07:43:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24727; Mon, 10 Jun 2002 07:20:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24691 for ; Mon, 10 Jun 2002 07:20:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28703; Mon, 10 Jun 2002 07:19:42 -0400 (EDT) Message-Id: <200206101119.HAA28703@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, 10 Jun 2002 07:19:41 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks Author(s) : C. Jennings, J. Peterson, M. Watson Filename : draft-ietf-sip-asserted-identity-01.txt Pages : 17 Date : 07-Jun-02 This document describes private extensions to SIP that enable a network of trusted SIP servers to assert the identity of authenticated users , and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-asserted-identity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-asserted-identity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607140159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-asserted-identity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-asserted-identity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140159.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 08:19:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00608 for ; Mon, 10 Jun 2002 08:19:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28434 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 08:20:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26891; Mon, 10 Jun 2002 07:55:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26860 for ; Mon, 10 Jun 2002 07:55:13 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29724 for ; Mon, 10 Jun 2002 07:54:38 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17HNlP-0000Fz-00 for ; Mon, 10 Jun 2002 14:55:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15620.37791.128760.714975@harjus.eng.song.fi> Date: Mon, 10 Jun 2002 14:55:11 +0300 To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-01.txt In-Reply-To: <200206101119.HAA28703@ietf.org> References: <200206101119.HAA28703@ietf.org> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i'm still against asserted identity as a p header. there was considerable support to have asserted identity as a normal standards track header. i don't understand how the authors decided to simply ignore that opinion. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 10:41:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06386 for ; Mon, 10 Jun 2002 10:41:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07251 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 10:41:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05622; Mon, 10 Jun 2002 10:10:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05597 for ; Mon, 10 Jun 2002 10:10:52 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04991 for ; Mon, 10 Jun 2002 10:10:18 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g5AEA2V27683; Mon, 10 Jun 2002 09:10:02 -0500 Message-ID: <006d01c21088$add10ab0$56fa403f@C1893415A> From: "Dean Willis" To: "Jonathan Rosenberg" , Cc: References: <3CFFD46C.3080403@dynamicsoft.com> Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt Date: Mon, 10 Jun 2002 09:11:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > [Duncan] The definition for the cell-id is just that it is a string of > > hex. > > It is defined already in 3GPP specifications. I agree the current text > > in > > my draft is probably not adding much. I can't reference 3GPP > > specifications > > though, right? I wanted to describe it in this draft, as "You can put > > anything you want in here as a 'string'." "3GPP mobiles will be limited > > by > > 3GPP specifications as to what they can put in there." [/Duncan] > > I don't see why you don't define the values in this spec... shouldn't > these specs at least stand alone and work outside of 3gpp so long as the > applicability statement holds true? Here's the rub -- the actual format is both defined in 3GPP and subject to change in 3GPP. This gives us a change control problem if we attempt to define it here. It IS possible to use external references to published specifications in an IETF document. From RFC 2026 (this stuff is in Section 7) An Internet Standard TS or AS may incorporate an open external standard by reference. For example, many Internet Standards incorporate by reference the ANSI standard character set "ASCII" [2]. Whenever possible, the referenced specification shall be available online. On the other hand, I'm not yet certain whether the 3GPP rel 5 work is considered "referenceable". I'm sure it will be eventually, but is it now? Duncan, what is the state of the document defining cell-id? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 10 10:53:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06949 for ; Mon, 10 Jun 2002 10:53:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07587 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 10:53:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06390; Mon, 10 Jun 2002 10:30:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06342 for ; Mon, 10 Jun 2002 10:30:20 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05658 for ; Mon, 10 Jun 2002 10:29:44 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA16960; Mon, 10 Jun 2002 15:29:46 +0100 (BST) Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard2 (4.6.1.91) with ESMTP id for ; Mon, 10 Jun 2002 15:28:39 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 10 Jun 2002 15:29:43 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jun 2002 15:29:39 +0100 Message-Id: To: dean.willis@softarmor.com, jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt Date: Mon, 10 Jun 2002 15:29:39 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean, As far as I'm aware, a CR against 3GPP TS24.229 to add text on the P-Access-Network-Info header was approved at the CN plenary meeting last week. That text refers to 'draft-mills-sip-access-network-info' for the syntax of the header and then explicitly defines some additional coding rules (e.g. that if the access-type = "3GPP-GERAN" then the access-info shall contain the cell ID, coded as follows.....) This is the bit that can only be specified ONCE in 3GPP specs. Admittedly, 3GPP TS24.229 may need revising slightly in the future, to reflect a minor change in the syntax of the header in the latest version of the draft (e.g. '3gpp-cgi' becomes 'cgi-3gpp'), but then it'll need revising slightly to update the reference from an I-D to an RFC as well (hopefully!) So this now seems to suggest that I can put a reference towards the 'additional coding rules' in 24.229 in my p-header draft? Best Regards, Duncan -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 10 June 2002 15:11 To: Jonathan Rosenberg; duncan.mills@vf.vodafone.co.uk Cc: sip@ietf.org Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt > > [Duncan] The definition for the cell-id is just that it is a string of > > hex. > > It is defined already in 3GPP specifications. I agree the current text > > in > > my draft is probably not adding much. I can't reference 3GPP > > specifications > > though, right? I wanted to describe it in this draft, as "You can put > > anything you want in here as a 'string'." "3GPP mobiles will be limited > > by > > 3GPP specifications as to what they can put in there." [/Duncan] > > I don't see why you don't define the values in this spec... shouldn't > these specs at least stand alone and work outside of 3gpp so long as the > applicability statement holds true? Here's the rub -- the actual format is both defined in 3GPP and subject to change in 3GPP. This gives us a change control problem if we attempt to define it here. It IS possible to use external references to published specifications in an IETF document. From RFC 2026 (this stuff is in Section 7) An Internet Standard TS or AS may incorporate an open external standard by reference. For example, many Internet Standards incorporate by reference the ANSI standard character set "ASCII" [2]. Whenever possible, the referenced specification shall be available online. On the other hand, I'm not yet certain whether the 3GPP rel 5 work is considered "referenceable". I'm sure it will be eventually, but is it now? Duncan, what is the state of the document defining cell-id? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 10 15:37:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21442 for ; Mon, 10 Jun 2002 15:37:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25266 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 15:37:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23964; Mon, 10 Jun 2002 15:14:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23932 for ; Mon, 10 Jun 2002 15:14:02 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20182 for ; Mon, 10 Jun 2002 15:13:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5AJAgYs004759; Mon, 10 Jun 2002 15:10:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 15:13:28 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1C3@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , sip@ietf.org Subject: RE: [Sip] NOTIFY after a SUBSCRIBE has expired Date: Mon, 10 Jun 2002 15:13:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > UA1 sends a SUBSCRIBE with expires 3600 > UA2 responds with 200 ok followed by NOTIFY. > > Now, 3600 seconds later, the subscription has not been > refreshed, so UA1 deletes all information cached about the > subscription. > > UA2 realises that the subscription has expired and sends a > NOTIFY with subscription-state of terminated. > > UA1 receives this NOTIFY, doesn't find a dialog and rejects > the NOTIFY with 481. > > This does not seem to be the correct behaviour. UA1 should > not remove any dialog information until it receives a NOTIFY > with subscription-state terminated. Is this the correct > behaviour? Is this mentioned anywhere in events-05? What you've described is certainly what's detailed in the current document. For the most part, it's necessary -- otherwise, how would UA1 ever clear state if UA2 disappeared from the network? I guess if we were really bothered by the potential for a 481 in this case, we could ask the subscriber to hold on to dialog state for several more seconds to sucessfully catch and process the incoming NOTIFY. Personally, I don't see any gain from doing so. I could be overlooking some reason that sending a 481 instead of a 200 is a Bad Thing; let me know if you can think of one. Note that this does not mean that sending NOTIFY messages upon expiration is wasted; it helps prevent synchronization issues in which the subscriber (for whatever reason) thinks the subscription lasts longer than the notifier does. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 10 15:55:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22495 for ; Mon, 10 Jun 2002 15:55:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26000 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 15:56:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25356; Mon, 10 Jun 2002 15:40:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25324 for ; Mon, 10 Jun 2002 15:40:11 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21602 for ; Mon, 10 Jun 2002 15:39:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5AJamYs004943; Mon, 10 Jun 2002 15:36:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 15:39:32 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1C5@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'jh@lohi.eng.song.fi'" , Henry Sinnreich Cc: Jonathan Rosenberg , "'Peterson, Jon'" , "'David R. Oran'" , "'Mark Watson'" , Andrew Allen , "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Asserted-Identity: How to 'hint'? Date: Mon, 10 Jun 2002 15:39:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > once ietf defines a p header for some purpose, there is far less > motivation to produce the corresponding standards track sip header. > the result is weaker sip and non-interoperable products. In general, I agree. This points to what I beleive is a problem in the current SIP change draft, the exact same problem that was aired in Minnesota by several people. But that's a different topic. In this particular case, there is a stated desire to use this approach to quickly plug a hole in a very particular circumstance (single domain of trust) until we can come up with a complete solution that works across multiple trust domains. So, I beleive the danger in this one particular case of the working group abandoning work on the final solution in favor of the stopgap is minimal. That's my understanding of what we agreed to in Las Vegas, at least. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 10 16:20:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23447 for ; Mon, 10 Jun 2002 16:20:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27474 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 16:21:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26706; Mon, 10 Jun 2002 16:03:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26675 for ; Mon, 10 Jun 2002 16:03:07 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22710 for ; Mon, 10 Jun 2002 16:02:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5AJxnYs005295; Mon, 10 Jun 2002 15:59:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 16:02:34 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1C6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'jh@lohi.eng.song.fi'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-01.txt Date: Mon, 10 Jun 2002 16:02:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > i'm still against asserted identity as a p header. there was > considerable support to have asserted identity as a normal standards > track header. i don't understand how the authors decided to simply > ignore that opinion. As much as I hate to say it (because I think the whole P- header thing is misguided), I think *if* we must have P- headers at all, this is one of the most obvious places that they should be used. Why? It's simple: this draft, an acknowledged short-term stopgap solution to a problem, has extremely limited applicablity. It is only useful on tightly controlled networks that have a single domain of trust. In general, deploying the currently proposed mechanism on a SIP network is useless at best, and dangerous at worst. My initial reaction is that it shouldn't be published by the IETF at all. It is only the careful scoping put in the draft and the fact that the header name itself makes its limited applicablity self-evident that makes it palatable in the slightest. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 10 18:14:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27793 for ; Mon, 10 Jun 2002 18:14:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04111 for sip-archive@odin.ietf.org; Mon, 10 Jun 2002 18:15:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02708; Mon, 10 Jun 2002 17:52:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02683 for ; Mon, 10 Jun 2002 17:52:16 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27193 for ; Mon, 10 Jun 2002 17:51:41 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5ALqD721471 for ; Mon, 10 Jun 2002 17:52:14 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 16:52:13 -0500 Message-ID: From: "Henrikson, Eric H (Eric)" To: Dean Willis , sip@ietf.org Cc: rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com Date: Mon, 10 Jun 2002 16:52:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: Poll: expert review of draft-henrikson-sip-charging-informati on Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All, Revision 5 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 5 contains the following changes: - fixed typo in section 4.2 for "charge-addr-params" - updated sections 5.2 and 5.3 to make it clear that P-Charging-Vector may be modified The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 5 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Henrikson, Eric H (Eric) Sent: Monday, June 03, 2002 10:46 AM To: 'Dean Willis'; 'sip@ietf.org' Cc: 'rohan@cisco.com'; 'brian.rosen@marconi.com'; 'jo@ipdialog.com' Subject: RE: Poll: expert review of draft-henrikson-sip-charging-information All, Revision 4 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 4 contains the following changes: - addition of 'm' to table 2 under section 4.3 to indicate proxy may modify P-Charging-Vector, which makes the table consistent with the description in the text - updated reference 13 to the latest version - additional details added to section 7, IANA Considerations The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 4 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Henrikson, Eric H (Eric) Sent: Thursday, May 30, 2002 2:55 PM To: 'Dean Willis'; sip@ietf.org Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com Subject: RE: Poll: expert review of draft-henrikson-sip-charging-information All, Revision 3 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today. Revision 3 contains the following changes: - additions to Applicability Statement for when the new charging headers don't apply - clarifications to the Security Considerations - fixing the examples to show IP addresses for the charging function addresses - additional sections for acknowledgements and the full copyright statement The new revision should appear on the IETF web site soon. Please let me know if you have further comments or would like a copy of rev 3 prior to its appearence on the web site. Thank you. Eric Henrikson -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, May 24, 2002 12:28 PM To: sip@ietf.org Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; ehenrikson@lucent.com Subject: Poll: expert review of draft-henrikson-sip-charging-information You may recall that we're doing an Expert Review of draft-henrikson-sip-charging-information. If you have a strong opinion for, against, or supporting a need for further work, or any further suggestions for enhancement, please post them now. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 11 04:55:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16364 for ; Tue, 11 Jun 2002 04:55:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09735 for sip-archive@odin.ietf.org; Tue, 11 Jun 2002 04:55:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08401; Tue, 11 Jun 2002 04:27:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08369 for ; Tue, 11 Jun 2002 04:27:08 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15974 for ; Tue, 11 Jun 2002 04:26:34 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5B8R5mG017574 for ; Tue, 11 Jun 2002 10:27:05 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5B8R5a9018985 for ; Tue, 11 Jun 2002 11:27:05 +0300 (EET DST) Message-ID: <3D05B459.9C69BBB3@lmf.ericsson.se> Date: Tue, 11 Jun 2002 11:27:05 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Local vs Remote ringback on 180 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Bis-09 only talks about local ringback tone generation when 180 is received. The ISUP-SIP draft defines that a remote ringback tone is generated if the 180 contains an SDP message body. However, with the new answer/offer rules, direction indicators (sendrecv, inactive etc) manyfolks model etc, I wonder if such assumption really works. There may be situations where a node must/must not/want/doesn't want to include SDP in 180 - no matter the ringback tone. Bis-09 defines two headers, Alert-Info and Content-Disposition, but the way they are currently defined I don't think they can be used for this purpose either. There probably are some ways to get around this, eg by using re-INVITEs and/or UPDATEs, but I really don't think that's what we want to do.... Comments? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 11 11:23:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28978 for ; Tue, 11 Jun 2002 11:23:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00902 for sip-archive@odin.ietf.org; Tue, 11 Jun 2002 11:24:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27940; Tue, 11 Jun 2002 10:30:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27892 for ; Tue, 11 Jun 2002 10:30:23 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26137 for ; Tue, 11 Jun 2002 10:29:34 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BETZA08438; Tue, 11 Jun 2002 16:29:35 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BETXQ17920; Tue, 11 Jun 2002 15:29:33 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:29:37 +0100 Message-ID: From: "Mark Watson" To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Tue, 11 Jun 2002 15:29:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21154.68EDEE46" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21154.68EDEE46 Content-Type: text/plain; charset="iso-8859-1" Christer, As I understand it, the current situation is as follows: From the point of view of the UAC (assuming an SDP offer in the INVITE for simplicity), then if (i) an SDP answer is received before the 200 OK of the INVITE (e.g. in 183, 180 , UPDATE, 200 OK to UPDATE etc.), and (ii) a=sendrecv or a=sendonly in this answer, and (iii) any manyfolks pre-conditions have been met (i.e. this could be an answer at the end of several offer/answer exchanges negotiating and updating preconditions) then there is Early Media, and the UAC SHOULD (?) play this to the caller. If there is no Early Media, or if the Early Media is on hold (SDP answer contains a=recvonly or a=inactive) AND a 180 has been received, then the UAC SHOULD (?) play local ringing. So, if the UAS does not want to generate Early Media then it has the following choices: (a) do not supply SDP answer until actual call Answer, or (b) supply early SDP answer with a=recvonly or a=inactive Now, (b) is not much use to a UAS trying to negotiate media with pre-conditions, since the direction attribute in this exchange will affect the resources that are reserved, and therefore needs to reflect the requirements of the eventual session. Therefore it would need to place the media on hold *after* the pre-conditions have been met, using an UPDATE. A workaround at the UAC for dealing with a UAS which did not do this is that, even if the offer/answer has been completed with a=sendrecv the UAC pays attention to whether any RTP packets are actually being received - if there are none, then it generates local ringing. Unfortunately, such a workaround is not really applicable to one class of UACs for whom local ringing is quite important, namely distributed PSTN to SIP gateways (consisting of Media Gateways and a Media Gateway Controller as per Megaco model). This is because the information about presence/absence of actual RTP packets is only available at the media layer (MG) which does not make decisions for itself about issues such as tones/announcements/inband ringing. So, I can only hope that all UAS developers implementing Manyfolks are aware of the need to put the media on hold as soon as the pre-conditions have been met (unless thay are going to generate real Eraly Media). A solution to this would be a way of explicitly indicating at the SIP/SDP layer that a media stream, although not on hold, was 'provisional', or did not contain actual media yet. I did not think the Content-Disposition in Manyfolks has formally been given this meaning. If it has, I'm not sure what 'undoes' this 'provisional' status - it shouldn't be the 200 OK to the INVITE because the whole point of UPDATE was to separate media changes from session changes - so it would have to be another offer/answer without the special Content-Disposition. But then are people aware they need to do this at Answer time ? Regards, Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 11 June 2002 09:27 > To: sip@ietf.org > Subject: [Sip] Local vs Remote ringback on 180 > > > > Hi, > > Bis-09 only talks about local ringback tone generation when 180 is > received. The ISUP-SIP draft defines that a remote ringback tone is > generated if the 180 contains an SDP message body. > > However, with the new answer/offer rules, direction indicators > (sendrecv, inactive etc) manyfolks model etc, I wonder if such > assumption really works. There may be situations where a node > must/must > not/want/doesn't want to include SDP in 180 - no matter the ringback > tone. > > Bis-09 defines two headers, Alert-Info and > Content-Disposition, but the > way they are currently defined I don't think they can be used for this > purpose either. > > There probably are some ways to get around this, eg by using > re-INVITEs > and/or UPDATEs, but I really don't think that's what we want to do.... > > Comments? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C21154.68EDEE46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Local vs Remote ringback on 180

Christer,

As I understand it, the current situation is as = follows:

From the point of view of the UAC (assuming an SDP = offer in the INVITE for simplicity), then if
(i) an SDP answer is received before the 200 OK of = the INVITE (e.g. in 183, 180 , UPDATE, 200 OK to UPDATE etc.), = and
(ii) a=3Dsendrecv or a=3Dsendonly in this answer, = and
(iii) any manyfolks pre-conditions have been met = (i.e. this could be an answer at the end of several offer/answer = exchanges negotiating and updating preconditions)

then there is Early Media, and the UAC SHOULD (?) = play this to the caller.

If there is no Early Media, or if the Early Media is = on hold (SDP answer contains a=3Drecvonly or a=3Dinactive) AND a 180 = has been received, then the UAC SHOULD (?) play local = ringing.

So, if the UAS does not want to generate Early Media = then it has the following choices:
(a) do not supply SDP answer until actual call = Answer, or
(b) supply early SDP answer with a=3Drecvonly or = a=3Dinactive

Now, (b) is not much use to a UAS trying to negotiate = media with pre-conditions, since the direction attribute in this = exchange will affect the resources that are reserved, and therefore = needs to reflect the requirements of the eventual session.

Therefore it would need to place the media on hold = *after* the pre-conditions have been met, using an UPDATE.

A workaround at the UAC for dealing with a UAS which = did not do this is that, even if the offer/answer has been completed = with a=3Dsendrecv the UAC pays attention to whether any RTP packets are = actually being received - if there are none, then it generates local = ringing.

Unfortunately, such a workaround is not really = applicable to one class of UACs for whom local ringing is quite = important, namely distributed PSTN to SIP gateways (consisting of Media = Gateways and a Media Gateway Controller as per Megaco model). This is = because the information about presence/absence of actual RTP packets is = only available at the media layer (MG) which does not make decisions = for itself about issues such as tones/announcements/inband = ringing.

So, I can only hope that all UAS developers = implementing Manyfolks are aware of the need to put the media on hold = as soon as the pre-conditions have been met (unless thay are going to = generate real Eraly Media).

A solution to this would be a way of explicitly = indicating at the SIP/SDP layer that a media stream, although not on = hold, was 'provisional', or did not contain actual media yet. I did not = think the Content-Disposition in Manyfolks has formally been given this = meaning. If it has, I'm not sure what 'undoes' this 'provisional' = status - it shouldn't be the 200 OK to the INVITE because the whole = point of UPDATE was to separate media changes from session changes - so = it would have to be another offer/answer without the special = Content-Disposition. But then are people aware they need to do this at = Answer time ?

Regards,

Mark


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 11 June 2002 09:27
> To: sip@ietf.org
> Subject: [Sip] Local vs Remote ringback on = 180
>
>
>
> Hi,
>
> Bis-09 only talks about local ringback tone = generation when 180 is
> received. The ISUP-SIP draft defines that a = remote ringback tone is
> generated if the 180 contains an SDP message = body.
>
> However, with the new answer/offer rules, = direction indicators
> (sendrecv, inactive etc) manyfolks model etc, I = wonder if such
> assumption really works. There may be = situations where a node
> must/must
> not/want/doesn't want to include SDP in 180 - = no matter the ringback
> tone.
>
> Bis-09 defines two headers, Alert-Info and =
> Content-Disposition, but the
> way they are currently defined I don't think = they can be used for this
> purpose either.
>
> There probably are some ways to get around = this, eg by using
> re-INVITEs
> and/or UPDATEs, but I really don't think that's = what we want to do....
>
> Comments?
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C21154.68EDEE46-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 11 17:12:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13287 for ; Tue, 11 Jun 2002 17:12:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19747 for sip-archive@odin.ietf.org; Tue, 11 Jun 2002 17:12:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17949; Tue, 11 Jun 2002 16:52:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17917 for ; Tue, 11 Jun 2002 16:52:08 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12755 for ; Tue, 11 Jun 2002 16:51:32 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 11 Jun 2002 15:51:28 -0500 Message-ID: <7E06D3212981524CA10D2A114937C41484AE3B@NREXCH.netrake.net> Thread-Topic: Question on draft-ietf-sip-digest-aka-03.txt Thread-Index: AcIRicWvI3fd7KCrS62WCkvDeKeflA== From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA17918 Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is it the intention of draft-ietf-sip-digest-aka-03 to replace the definitions of "algorithm" and "nonce" that are already defined in bis-09? Or merely to extend the definitions? - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 11 20:52:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18255 for ; Tue, 11 Jun 2002 20:52:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29701 for sip-archive@odin.ietf.org; Tue, 11 Jun 2002 20:53:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28921; Tue, 11 Jun 2002 20:36:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28895 for ; Tue, 11 Jun 2002 20:36:33 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17848 for ; Tue, 11 Jun 2002 20:35:58 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5C0ZWT30408; Tue, 11 Jun 2002 19:35:32 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 19:35:27 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703D8@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Tue, 11 Jun 2002 19:35:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry for my delay in responding to this one. Agreed that identity-based assertions are ultimately better than role-based assertions - no question. We made a simple scope decision that identity-based assertion would be a matter for the long-term work, not the short-term work. One of the reasons why we went in this direction was because we didn't feel that we needed to have multiple P-Asserted-Identity headers in a message (or more precisely, that we didn't feel we needed to have more than two, one for a SIP[S] URI and one for a tel URL in support of certain PSTN gatewaying applications) in order to satisfy the existing requirements. Agreed that were a need for this to arise, multiple P-Asserted-Identity headers (especially with different asserted identities) would be somewhat ambiguous. Another reason why an identity-based approach didn't seem like a good match for the short-term work is that without cryptographic authentication of the P-Asserted-Identity header, it is a bit too easy for someone to forge something like an 'asserted-by' parameter or add falsified P-Asserted-Identity headers that could mislead downstream entities. You still need to keep track of trust-based identity (i.e. who sent me this, and whether I am configured to trust them) in order to learn how much you should trust the P-Asserted-Identity header(s) in a message. Adding any cryptographic properties to the header is also outside the scope of the short-term identity work. Finally, the short-term work is completely dependent on the concept of trust domains discussed in Mark Watson's NAI requirements document. It therefore has some slightly different assumptions about why proxies transitively trust one another. An assertion from one intermediary in a trust domain is known to be as good as an assertion from any other, as a trust domain is defined, so knowing the identity of the particular intermediary that added the header isn't immediately material. While the applicability of this might seem limited, there are a number of parties that are apparently interested in this sort of network. But that much said, it sounds like your remarks have some applicability to the long-term identity work, which today has no explicit concept of transitivity - your suggestions could prove valuable there. I put together a separate proposal on long-term identity (draft-peterson-sip-identity-00), and I'd appreciate any comments. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, June 05, 2002 7:36 AM > To: Cullen Jennings > Cc: sip@ietf.org > Subject: [Sip] Asserted-Identity - new hint proposal > > > > So, I still haven't heard why the role based > assertions is better than the alternative of > identity based assertions. The way it's structured > now, you seemingly either lose information along > the way, or have an ambiguous situtation with > multiple P-Asserted-Identity's. Suppose for > example that my real name is thomasm, but I > want to use my alias mat. What I'd do is: > > Asserted-Identity: ; asserted-by: > ;etc > > At my first hop proxy, it would check to see if > mat@cisco.com was an acceptible alias, and if it > is, it would add a new AI to vouch for me: > > Asserted-Identity: ; asserted-by: > > > When it's forwarded to the UAS proxy, it would > know that it trusts proxy-15's assertions (but not > thomasm's) and therefore add a new header for the > UAS: > > Asserted-Identity: ; asserted-by: > > > So clear back at luser.mtcc.com we finally get the > INVITE and see these asserted-identities: > > Asserted-Identity: ; asserted-by: > ;etc > Asserted-Identity: ; asserted-by: > > Asserted-Identity: ; asserted-by: > > > The UAS cdr's through the list and discovers -- > aha! -- an asserted identity by proxy-22@mtcc.com > which it trusts since it's the inbound proxy. > Therefore, luser.mtcc.com knows that the identity > it will use for the callerid is the one supplied by > proxy-22. If proxy-22 didn't insert an > asserted-identity, it probably means that it > didn't trust the previous hop, and that the UAS > should mark the callerid as suspect, if it > displays anything at all. > > Notice that we don't need "roles" here of UA and > proxy, but instead uses their actual identities. > Note also that this could be generally applicable > for more cases where you need to assert identity > such as the firewall-proxy traversal case > especially if it were combined with cryptographic > proof by the party asserting the identity. It > would also allow flexibility of _who_ enables > traversal as well, ie that one of my proxies could > insert the necessary credentials to get me through > a foreign proxy instead of the UAC directly which > would enable aggregation, and separation. > > Mike > > > Cullen Jennings writes: > > > > I am getting the feeling that people want to put the hint > in a separate > > header. How would everyone feel about something along the lines of: > > > > P-Suggested-Identity: "Cullen Jennings" > ;mandatory > > > > The UAC would insert this header to indicate the > Asserted-Identity that it > > wished the Trust Domain to choose. The "mandatory" > indicates that the Trust > > Domain MUST return some 4xx response if it is not going to > assert this > > identity. If the "mandatory" was not present, it would not > return an 4xx if > > it choose a different identity to assert for the user. > > > > Should we go with two headers (PSI and PAI)? > > > > Does PSI need some flag (like mandatory) to say how it is > handled in the > > case the suggested identity is not going to be provided? > > > > Alternatively, should we go with one header and the > argument that Dean so > > nicely summed up as > > > I think existence of a P-A-I header in a message means > "a previous hop > > > (sender or proxy) has asserted this identity. Deal with it." > > > > > > Options for dealing with it are: > > > > > > 1) Believe it > > > 2) Delete it (in conjunction with "privacy" modifier) > > > 3) Delete it and assert a different identity > > > 4) Reject the message > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 00:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22693 for ; Wed, 12 Jun 2002 00:08:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10078 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 00:08:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07800; Tue, 11 Jun 2002 23:30:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07760 for ; Tue, 11 Jun 2002 23:30:10 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22065 for ; Tue, 11 Jun 2002 23:29:29 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g5C3TVe27644 for ; Wed, 12 Jun 2002 08:59:31 +0530 (IST) Received: from Rudra ([10.115.6.189]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GXKPOV01.LR6; Wed, 12 Jun 2002 08:59:19 +0530 From: "Shivaprasad Shivarudrappa" To: , , , , , Date: Wed, 12 Jun 2002 09:08:05 +0530 Organization: Wipro Technologies Message-ID: <005501c211c2$9086b4b0$bd06730a@Rudra> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e5173e9f-76f8-11d6-ba7c-006067005148" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: High Subject: [Sip] To find the Port Value for the Particular proxy for which UA configured Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-e5173e9f-76f8-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C211F0.AA3EF0B0" ------=_NextPart_000_0056_01C211F0.AA3EF0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have a query on the SNMP MIB for SIP. In the sipUACSipServerTable in the SIP UA MIB it is possible to have two entries for the proxy against the same application index. This would mean that there are 2 proxies configured for a SIP end point. Are proxies configured in this manner to achieve fault tolerance ? Couldnt the same be achieved by configuring the DNS SRV records appropriately? I went through the draft-ietf-sip-mib-04.txt. I gone through the the example that you had given in the document. What i understood from the example is that through the appindex i can query the the other table for the other values. Problem statement:- How to get the Port vlaue for the particular proxy , for which the SIPUA has been configured? I had correlated the example that you had provided in the draft to access the Port value for the particular proxy for which the SIPUA has been configured. My understanding - To get the portvalue, Port status and other detailes for the Proxy for which the Particular UA has been configured. 1. Query the AppIndex table. Get the applIndex value. 2. Through the applIndex value get the sipUACfgSipServerAddrIndex from the table sipUACfgSipServerTable. 3. Through the sipUACfgSipServerAddrIndex query the table sipPortTable to get the SipPort for the particular proxy for which SIPUA has been configured. IS my understanding is correct . Please correct me if i am wrong. Regards, Shivaprasad S. ------=_NextPart_000_0056_01C211F0.AA3EF0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have = a query on=20 the SNMP MIB for SIP. In the sipUACSipServerTable  in=20 the SIP UA MIB it is possible to = have two=20 entries for the proxy against the same application index. This would = mean that=20 there are 2 proxies configured for a SIP end point. Are proxies = configured in=20 this manner to achieve fault tolerance ? Couldnt the same be achieved by = configuring the DNS SRV records appropriately?
 
 
I went = through the=20 draft-ietf-sip-mib-04.txt. I gone = through=20 the the example that you had given in the document. What i understood = from the=20 example is that through the appindex i can query the the other table for = the=20 other values.
 
 
Problem=20 statement:-
 
  How to=20 get the Port vlaue for the particular proxy , for which the SIPUA has = been=20 configured?
  
  I had = correlated=20 the example that you had provided in the draft to access the Port = value for=20 the particular proxy for which the SIPUA has been=20 configured.
 
My=20 understanding
 
- To get the = portvalue, Port status and other detailes for the Proxy for which = the=20 Particular UA has been configured.
 
   = 1. Query=20 the AppIndex = table. Get the=20 applIndex=20 value.
   = 2. Through=20 the applIndex = value get=20 the  sipUACfgSipServerAddrIndex=20 from the table sipUACfgSipServerTable.
   = 3. Through=20 the sipUACfgSipServerAddrIndex =20 query the table sipPortTable=20 to get the SipPort=20 for the particular
      &n= bsp;proxy=20 for which SIPUA has been configured.
 
 
IS my = understanding is=20 correct . Please correct me if i am wrong.
 
 
Regards,
Shivaprasad=20 S.
 
 
 
------=_NextPart_000_0056_01C211F0.AA3EF0B0-- ------=_NextPartTM-000-e5173e9f-76f8-11d6-ba7c-006067005148-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 04:08:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20184 for ; Wed, 12 Jun 2002 04:08:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09630 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 04:09:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08393; Wed, 12 Jun 2002 03:43:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08364 for ; Wed, 12 Jun 2002 03:43:08 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19848 for ; Wed, 12 Jun 2002 03:42:31 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5C7ilW16108 for ; Wed, 12 Jun 2002 10:44:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 10:43:05 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 10:43:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Date: Wed, 12 Jun 2002 10:43:05 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED4C@esebe013.NOE.Nokia.com> Thread-Topic: Question on draft-ietf-sip-digest-aka-03.txt Thread-Index: AcIRicWvI3fd7KCrS62WCkvDeKeflAAVTVbQ To: , X-OriginalArrivalTime: 12 Jun 2002 07:43:14.0882 (UTC) FILETIME=[CF5A6A20:01C211E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA08365 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Rob, Digest-aka doesn't replace the algorithm and nonce definitions of bis-09, but extends them. More specifically, the draft talks about overloading of the algorithm definition by adding an AKA prefix to the token values; and extending of the nonce which in bis-09 is simply a quoted string. Cheers, Aki > -----Original Message----- > From: ext Rob Phillips [mailto:rob@netrake.com] > Sent: Tuesday, June 11, 2002 11:51 PM > To: sip@ietf.org > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > replace the definitions of "algorithm" and "nonce" that are > already defined in bis-09? Or merely to extend the definitions? > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake > Corporation > mailto: rob@netrake.com 3000 > Technology Drive > voice: (214) 291-1096 > Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, > Texas 75074 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 08:04:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24191 for ; Wed, 12 Jun 2002 08:04:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21775 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 08:04:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20263; Wed, 12 Jun 2002 07:41:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20236 for ; Wed, 12 Jun 2002 07:41:52 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23673 for ; Wed, 12 Jun 2002 07:41:17 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 12 Jun 2002 06:41:15 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A76@NREXCH.netrake.net> Thread-Topic: Conflict(?) between sip-reason-01 and sip-events-05 Thread-Index: AcISBhKf5U5rbwx2RR2FcceDCglvJg== From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA20237 Subject: [Sip] Conflict(?) between sip-reason-01 and sip-events-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I noticed that there's a rule name conflict between sip-reason-01 and sip-events-05. Both define BNF rules for "reason-value" and "reason-extension", but the definitions are certainly not compatable. While the guideline for writing SIP extensions does not explicitly deal with this issue, it seems to me that, to avoid confusion, BNF rules should have unique names. Thoughts? - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 08:19:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24636 for ; Wed, 12 Jun 2002 08:19:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22526 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 08:20:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21749; Wed, 12 Jun 2002 08:04:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24058 for ; Tue, 11 Jun 2002 18:39:26 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15378 for ; Tue, 11 Jun 2002 18:38:49 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BE2Hn01604; Tue, 11 Jun 2002 16:02:18 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BE2FQ13521; Tue, 11 Jun 2002 15:02:15 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:02:19 +0100 Message-ID: From: "Mark Watson" To: Jonathan Rosenberg , fluffy@cisco.com Cc: sip@ietf.org, Jon Peterson Date: Tue, 11 Jun 2002 15:02:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21150.97EA8942" Subject: [Sip] RE: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C21150.97EA8942 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Sorry, I missed this one from last week. Just on the relationship between Spec(T), the requirements and this draft. 1) The requirements tell us that our solution can assume a known common behaviour (aka Spec(T)) for a set of nodes (the Trust Domain), and that we can assume that some of those nodes know about others and have secure connections etc. This assumption is designed to allow us to define a solution which does not use cryptography, but it does not pre-suppose what the 'common known behaviour' actually is - working out what that behaviour is is the job of Cullen's draft. 2) The solution (Cullen's draft) describes what has to be included in Spec(T) in order to make the mechanism work. Some of this is detailed procedures, and indeed all of Cullen's draft would need to be included in any working Spec(T). Some of it is open for the Trust Domain to decide, we just point out that certain things do need to be specified in order for the header to be meaningful. 3) Spec(T) for a given Trust Domain T fills in the details required by Cullen's draft, for example the exact manner in which users are Authenticated. Another Trust Domain, U, might have a different specification, Spec(U) which specified a different, perhaps more or less reliable, manner of authentication. This means that knowing about Cullen's draft is not enough to tell you what a P-Asserted-Identity header that you receive actually means - in particular you don't know the authentication procedure used to generate it - but this is a GOOD THING because you should only attach meaning to a P-Asserted-Identity header if you really do know all about the Trust Domain asserting it - i.e. if you really know about what's in Spec(T). At the end of the day we cannot specify abolutely that P-Asserted-Identity headers all have some known reliability 'X', so it is better not to even try and say this (e.g. by specifying a particular authentication scheme in Cullen's draft). The relability of the data in this header depends on the particular Trust Domain. ...Mark > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 03 June 2002 04:33 > To: fluffy@cisco.com > Cc: sip@ietf.org; Jon Peterson; Watson, Mark [MDN05:EP10:EXCH] > Subject: Re: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt > > > Comments on this draft: > > > Extensions to the Session Initiation Protocol (SIP) for Asserted > > Identity within Trusted Networks > > draft-ietf-sip-asserted-identity-00 > > Based on iesg feedback on the call-auth draft, I suggest you > pre-emptively add "Private" to the beginning. > > > This document describes private extensions to SIP that enable a > > network of trusted SIP servers to assert the identity of > end users or > > end systems > > I seem to recall that the requirements explicitly talk about the > identity of users (calling and called parties), and NOT their > devices/end-systems (the phone can authenticate itself as the phone > using sip...). Its a nit, but one of my big concerns is that we are > clear on WHAT identity is being asserted. > > > This > > document does NOT offer a general privacy or identity > model suitable > > for inter-domain use, > > But it does; can't the trust domain span "domains" in the traditional > DNS sense? > > > The means by which the > > network determines the identity to assert is outside the scope of > > this document (though it commonly entails some form of > > authentication). > > I thought it was a requirement that the specification clearly > define the > means by which identity is authenticated. > > > A key requirement of [5] is that the behavior of all nodes within a > > given Trust Domain 'T' is known to comply to a certain set of > > specifications known as 'Spec(T)'. Spec(T) MUST specify > behavior for > > the following: > > > > 1. The manner in which users are authenticated > > OK, I think I am confused. I had thought that spec(T) was > THIS document, > but perhaps its more of some abstract thing that a domain is aware of > (my apologies if this was extensively discussed - i missed many of the > threads on this subject). I fear the requirements doc might be > conflating the two, since I finished my read of that assuming > that this > was the case. > > In any case, the list of things spec(T) has to specify belongs in the > requiremetns document, not here, I would think, and certainly > not in the > applicability statement. > > > For example, a caller that wants to > > maintain privacy and consequently provides limited > information in the > > SIP From header field will not be identifiable by > recipients of the > > call unless they rely on some other means to discovery > the identity > > of the caller. > > > s/discovery/discover > > However, I think this example doesn't support the claim above. The > outcome described here - that the recipients of the call > can't know who > the caller is - is the desired outcome, and not an error. The claim is > that certain combinations that need to be supported, can't be > supported. > This is NOT such a combination. > > > This document attempts to address this requirement using a very > > "this requirement" is a dangling reference here, since the requirement > you are talking about is mentioned two paragraphs above. I > suggest "This > document attempts to provide a network asserted identity service...." > > > [5] Watson, M., "Short term requirements for Network Asserted > > Identity", draft-ietf-sipping-nai-reqs-01 (work in > progress), > > May 2002. > > This is listed as a normative requirement, but its going to be an > informational RFC. I don't believe you can have informational RFCs as > normative dependencies. You should make it an informational reference. > > > When a proxy receives a > > message from a node it does not trust, the proxy MUST > authenticate > > the originator of the message, and use the identity which results > > from this authentication to insert an appropriate > P-Asserted-Identity > > header field into the message. > > This won't work, of course, for a proxy that receives an incoming call > made by a user in a separate domain. You can't mandate that a proxy > authenticate ALL incoming requests, and certainly not all incoming > messages (which then includes responses). I think you mean > that a proxy > MAY authenticate the originator... > > Furthermore, the word "appropriate" is too vague here. You need to be > more specific. > > Also, shouldn't this bit here mention something about spec(T) - using > the authentication mechanism described there, or something? > > > 6. Hints for Multiple Identities > > isn't this part of proxy behavior? It should be a subsection of 5. > Indeed, it should probably be towards the beginning of 5, > which needs to > lay out a rigorous set of processing steps for a proxy, preferably in > the order they need to be done. Since the hints are used in the > beginning of proxy processing, they belong early on. > > Also, I just commented in a separate email that I do not believe we > should reuse P-Asserted-ID for this. > > > Parties who wish to request the removal of > P-Asserted-Identity header > > fields before they are transmitted to an element that is > not trusted > > may add the "id" privacy token to the Privacy header field. > > reference to privacy spec is appropriate here. > > > If there is no Privacy header field, the proxy MAY include the P- > > Asserted-Identity header field or it MAY remove it. > > You need to qualify this sentence with "when forwarding the request to > an untrusted element." > > > Users will typically want to > > request "id" privacy when they are challenged for authentication. > > This seems to imply that the only time you need to include > the Privacy: > id is when you send the request as a result of a 401/407. > But, thats not > true. Consider a proxy connected to a user with TLS (which will be the > case frequently in order to establish trust between the user and thr > proxy). The proxy need only challenge the user once; > subsequent requests > over the same tls connection are known to be from the same user. Thus, > these rqeuests are not a result of a 401/407, but need to have the > Privacy: id header on them since the proxy can assert an identity. > > > If multiple P-Asserted-Identity headers field values are > present in a > > message, and privacy of the P-Asserted-Identity header field is > > requested, then all instances of the header field values MUST be > > removed. > > add "before forwarding the request to an untrusted entity". > > > Section 7, as with 6, needs to be split up and the > appropriate behavior > relegated to sections on UAC, UAS and proxy behavior. > > > The P-Asserted-Identity header field is used among trusted SIP > > entities (typically intermediaries) to carry the > identity of the user > > sending a SIP message as it was verified by authentication. > > > > PAssertedID = "P-Asserted-Identity" HCOLON ( > name-addr / addr-spec ) > > This grammar is not correct. Multiple headers with a single value MUST > be identical to a single header with multiple values. That is, the > following two need to be the same: > > P-Asserted-Identity: sip:user1@domain.com, tel:5551212 > > and > > P-Asserted-Identity: sip:user1@domain.com > P-Asserted-Identity: tel:5551212 > > indeed, no matter which form is used, this is formally > referred to as a > "P-Asserted-Identity header field with multiple values". > Thus, your BNF > must be: > > PAssertedID = "P-Asserted-Identity" HCOLON pid-value *(COMMA > pid-value) > pid-value = nameaddr / addr-spec > > > There may be zero or one P-Asserted-Identity > > headers with either a SIP or SIPS URI and in addition > there may be > > zero or one P-Asserted-Identity headers with a tel URL. > > These words are not correct. The proper wording is: > > "There may be one or two P-Asserted-Identity values. If there is one > value, it MUST be a sip, sips, or tel URI. If there are two > values, one > value MUST be a sip or sips URI, and the other MUST be a tel URL." > > > Header field where proxy ACK BYE CAN INV > OPT REG > > ------------ ----- ----- --- --- --- > --- --- --- > > P-Asserted-Identity adr - o - > o o - > > > > > > SUB NOT REF > INF UPD PRA > > --- --- --- > --- --- --- > > o o o > - - - > > Is there a particular reason that this header is excluded > from usage in > INFO, UPDATE, PRACK, REGISTER and ACK? The only one where it doesn't > make sense is CANCEL. > > > The presence of this privacy type in > > a Privacy header field indicates that the user would > like the Network > > Asserted Identity to be kept private with respect to SIP entities > > outside the Trust Domain or trust federation with which the user > > authenticated. > > This is the first time the term "trust federation" is > introduced. Please > stick to terminology from the requirements document. > > > Via header branch parameters are > > omitted for clarity. > > Well, you've included call-ids, cseqs, and even tags. Please > do include > the branch IDs so that these are valid requests, else make them have > ONLY the headers relevant to the flow, so its clear that they are not > valid requests. The latter is preferred. > Section 10.1 should have a ladder diagram. > > In 10.1, message F2 is missing a to tag (all responses have them) > > In 10.2, there is an extra CRLF in message F3, after max-forwards. > > > 13.2 Registration of "id" privacy type for SIP Privacy header > > > > Name of privacy type: id > > You need to reference the section of the privacy spec which > has defined > this IANA registry. Furthermore, the information provided here must > match, word for word, the request information defined by the privacy > spec. Unfortuantely, it doesn't do that properly yet, but > these two docs > need to get aligned on that. > > Thanks, > Jonathan R. > > > > > > > > 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 : Extensions to the Session > Initiation Protocol > > (SIP) > > for Asserted Identity within > Trusted Networks > > Author(s) : C. Jennings, J. Peterson, M. Watson > > Filename : draft-ietf-sip-asserted-identity-00.txt > > Pages : 17 > > Date : 28-May-02 > > > > This document describes private extensions to SIP that enable a > > network of trusted SIP servers to assert the identity of > end users or > > end systems, and the application of existing privacy mechanisms to > > the identity problem. The use of these extensions is only > applicable > > inside an administrative domain with previously agreed-upon policies > > for generation, transport and usage of such information. This > > document does NOT offer a general privacy or identity model suitable > > for inter-domain use, or use in the Internet at large. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-id > entity-00. > > txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sip-asserted-identity-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-ietf-sip-asserted-identity-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before > the "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which > have been split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > -------------------------------------------------------------- > ---------- > > > > Subject: > > Date: Wed, 29 May 2002 12:44:54 -0400 > > > > > -------------------------------------------------------------- > ---------- > > > > ATT40156.txtName: ATT40156.txt > > Type: Plain Text (text/plain) > > > > Access-Type: anon-ftp > > Document Info: Site: internet-drafts > > Mode: ftp.ietf.org > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > ------_=_NextPart_001_01C21150.97EA8942 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt

Jonathan,

Sorry, I missed this one from last week.

Just on the relationship between Spec(T), the = requirements and this draft.

1) The requirements tell us that our solution can = assume a known common behaviour (aka Spec(T)) for a set of nodes (the = Trust Domain), and that we can assume that some of those nodes know = about others and have secure connections etc. This assumption is = designed to allow us to define a solution which does not use = cryptography, but it does not pre-suppose what the 'common known = behaviour' actually is - working out what that behaviour is is the job = of Cullen's draft.

2) The solution (Cullen's draft) describes what has = to be included in Spec(T) in order to make the mechanism work. Some of = this is detailed procedures, and indeed all of Cullen's draft would = need to be included in any working Spec(T). Some of it is open for the = Trust Domain to decide, we just point out that certain things do need = to be specified in order for the header to be meaningful.

3) Spec(T) for a given Trust Domain T fills in the = details required by Cullen's draft, for example the exact manner in = which users are Authenticated. Another Trust Domain, U, might have a = different specification, Spec(U) which specified a different, perhaps = more or less reliable, manner of authentication.

This means that knowing about Cullen's draft is not = enough to tell you what a P-Asserted-Identity header that you receive = actually means - in particular you don't know the authentication = procedure used to generate it - but this is a GOOD THING because you = should only attach meaning to a P-Asserted-Identity header if you = really do know all about the Trust Domain asserting it - i.e. if you = really know about what's in Spec(T).

At the end of the day we cannot specify abolutely = that P-Asserted-Identity headers all have some known reliability 'X', = so it is better not to even try and say this (e.g. by specifying a = particular authentication scheme in Cullen's draft). The relability of = the data in this header depends on the particular Trust = Domain.

...Mark


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 03 June 2002 04:33
> To: fluffy@cisco.com
> Cc: sip@ietf.org; Jon Peterson; Watson, Mark = [MDN05:EP10:EXCH]
> Subject: Re: I-D = ACTION:draft-ietf-sip-asserted-identity-00.txt
>
>
> Comments on this draft:
>
> >   Extensions to the Session = Initiation Protocol (SIP) for Asserted
> = >           &n= bsp;         Identity within = Trusted Networks
> = >           &n= bsp;       = draft-ietf-sip-asserted-identity-00
>
> Based on iesg feedback on the call-auth draft, = I suggest you
> pre-emptively add "Private" to the = beginning.
>
> >  This document describes private = extensions to SIP that enable a
> >    network of trusted SIP = servers to assert the identity of
> end users or
> >    end systems
>
> I seem to recall that the requirements = explicitly talk about the
> identity of users (calling and called parties), = and NOT their
> devices/end-systems (the phone can authenticate = itself as the phone
> using sip...). Its a nit, but one of my big = concerns is that we are
> clear on WHAT identity is being = asserted.
>
> > This
> >    document does NOT offer = a general privacy or identity
> model suitable
> >    for inter-domain use, =
>
> But it does; can't the trust domain span = "domains" in the traditional
> DNS sense?
>
> > The means by which the
> >    network determines the = identity to assert is outside the scope of
> >    this document (though it = commonly entails some form of
> >    authentication).
>
> I thought it was a requirement that the = specification clearly
> define the
> means by which identity is = authenticated.
>
> >  A key requirement of [5] is that the = behavior of all nodes within a
> >    given Trust Domain 'T' = is known to comply to a certain set of
> >    specifications known as = 'Spec(T)'.  Spec(T) MUST specify
> behavior for
> >    the following:
> >
> >    1.  The manner in = which users are authenticated
>
> OK, I think I am confused. I had thought that = spec(T) was
> THIS document,
> but perhaps its more of some abstract thing = that a domain is aware of
> (my apologies if this was extensively discussed = - i missed many of the
> threads on this subject). I fear the = requirements doc might be
> conflating the two, since I finished my read of = that assuming
> that this
> was the case.
>
> In any case, the list of things spec(T) has to = specify belongs in the
> requiremetns document, not here, I would think, = and certainly
> not in the
> applicability statement.
>
> > For example, a caller that wants to
> >    maintain privacy and = consequently provides limited
> information in the
> >    SIP From header field = will not be identifiable by
> recipients of the
> >    call unless they rely on = some other means to discovery
> the identity
> >    of the caller.
>
>
> s/discovery/discover
>
> However, I think this example doesn't support = the claim above. The
> outcome described here - that the recipients of = the call
> can't know who
> the caller is - is the desired outcome, and not = an error. The claim is
> that certain combinations that need to be = supported, can't be
> supported.
> This is NOT such a combination.
>
> > This document attempts to address this = requirement using a very
>
> "this requirement" is a dangling = reference here, since the requirement
> you are talking about is mentioned two = paragraphs above. I
> suggest "This
> document attempts to provide a network asserted = identity service...."
>
> >  [5]  Watson, M., "Short = term requirements for Network Asserted
> = >         Identity", = draft-ietf-sipping-nai-reqs-01 (work in
> progress),
> = >         May 2002.
>
> This is listed as a normative requirement, but = its going to be an
> informational RFC. I don't believe you can have = informational RFCs as
> normative dependencies. You should make it an = informational reference.
>
> > When a proxy receives a
> >    message from a node it = does not trust, the proxy MUST
> authenticate
> >    the originator of the = message, and use the identity which results
> >    from this authentication = to insert an appropriate
> P-Asserted-Identity
> >    header field into the = message.
>
> This won't work, of course, for a proxy that = receives an incoming call
> made by a user in a separate domain. You can't = mandate that a proxy
> authenticate ALL incoming requests, and = certainly not all incoming
> messages (which then includes responses). I = think you mean
> that a proxy
> MAY authenticate the originator...
>
> Furthermore, the word "appropriate" = is too vague here. You need to be
> more specific.
>
> Also, shouldn't this bit here mention something = about spec(T) - using
> the authentication mechanism described there, = or something?
>
> > 6. Hints for Multiple Identities
>
> isn't this part of proxy behavior? It should be = a subsection of 5.
> Indeed, it should probably be towards the = beginning of 5,
> which needs to
> lay out a rigorous set of processing steps for = a proxy, preferably in
> the order they need to be done. Since the hints = are used in the
> beginning of proxy processing, they belong = early on.
>
> Also, I just commented in a separate email that = I do not believe we
> should reuse P-Asserted-ID for this.
>
> >  Parties who wish to request the = removal of
> P-Asserted-Identity header
> >    fields before they are = transmitted to an element that is
> not trusted
> >    may add the = "id" privacy token to the Privacy header field.
>
> reference to privacy spec is appropriate = here.
>
> > If there is no Privacy header field, the = proxy MAY include the P-
> >    Asserted-Identity header = field or it MAY remove it.
>
> You need to qualify this sentence with = "when forwarding the request to
> an untrusted element."
>
> > Users will typically want to
> >    request "id" = privacy when they are challenged for authentication.
>
> This seems to imply that the only time you need = to include
> the Privacy:
> id is when you send the request as a result of = a 401/407.
> But, thats not
> true. Consider a proxy connected to a user with = TLS (which will be the
> case frequently in order to establish trust = between the user and thr
> proxy). The proxy need only challenge the user = once;
> subsequent requests
> over the same tls connection are known to be = from the same user. Thus,
> these rqeuests are not a result of a 401/407, = but need to have the
> Privacy: id header on them since the proxy can = assert an identity.
>
> > If multiple P-Asserted-Identity headers = field values are
> present in a
> >    message, and privacy of = the P-Asserted-Identity header field is
> >    requested, then all = instances of the header field values MUST be
> >    removed.
>
> add "before forwarding the request to an = untrusted entity".
>
>
> Section 7, as with 6, needs to be split up and = the
> appropriate behavior
> relegated to sections on UAC, UAS and proxy = behavior.
>
> > The P-Asserted-Identity header field is = used among trusted SIP
> >    entities (typically = intermediaries) to carry the
> identity of the user
> >    sending a SIP message as = it was verified by authentication.
> >
> >        = PAssertedID =3D "P-Asserted-Identity" HCOLON (
> name-addr / addr-spec )
>
> This grammar is not correct. Multiple headers = with a single value MUST
> be identical to a single header with multiple = values. That is, the
> following two need to be the same:
>
> P-Asserted-Identity: sip:user1@domain.com, = tel:5551212
>
> and
>
> P-Asserted-Identity: = sip:user1@domain.com
> P-Asserted-Identity: tel:5551212
>
> indeed, no matter which form is used, this is = formally
> referred to as a
> "P-Asserted-Identity header field with = multiple values".
> Thus, your BNF
> must be:
>
> PAssertedID =3D "P-Asserted-Identity" = HCOLON pid-value *(COMMA
> pid-value)
> pid-value =3D nameaddr / addr-spec
>
> > There may be zero or one = P-Asserted-Identity
> >    headers with either a = SIP or SIPS URI and in addition
> there may be
> >    zero or one = P-Asserted-Identity headers with a tel URL.
>
> These words are not correct. The proper wording = is:
>
> "There may be one or two = P-Asserted-Identity values. If there is one
> value, it MUST be a sip, sips, or tel URI. If = there are two
> values, one
> value MUST be a sip or sips URI, and the other = MUST be a tel URL."
>
> >     Header = field         where   = proxy   ACK  BYE  CAN  INV
>  OPT  REG
> = >         = ------------         = -----   -----   ---  ---  ---  =
> ---  ---  ---
> = >         = P-Asserted-Identity         = ;  adr     -    = o    -  
>  o    o    = -
> >
> >
> = >           &n= bsp;           &n= bsp;           &n= bsp;          SUB  = NOT  REF 
> INF  UPD  PRA
> = >           &n= bsp;           &n= bsp;           &n= bsp;          ---  = ---  --- 
> ---  ---  ---
> = >           &n= bsp;           &n= bsp;           &n= bsp;           = o    o    o  
>  -    -    = -
>
> Is there a particular reason that this header = is excluded
> from usage in
> INFO, UPDATE, PRACK, REGISTER and ACK? The only = one where it doesn't
> make sense is CANCEL.
>
> > The presence of this privacy type = in
> >    a Privacy header field = indicates that the user would
> like the Network
> >    Asserted Identity to be = kept private with respect to SIP entities
> >    outside the Trust Domain = or trust federation with which the user
> >    authenticated.
>
> This is the first time the term "trust = federation" is
> introduced. Please
> stick to terminology from the requirements = document.
>
> > Via header branch parameters are
> >    omitted for = clarity.
>
> Well, you've included call-ids, cseqs, and even = tags. Please
> do include
> the branch IDs so that these are valid = requests, else make them have
> ONLY the headers relevant to the flow, so its = clear that they are not
> valid requests. The latter is preferred. =
> Section 10.1 should have a ladder = diagram.
>
> In 10.1, message F2 is missing a to tag (all = responses have them)
>
> In 10.2, there is an extra CRLF in message F3, = after max-forwards.
>
> > 13.2 Registration of "id" = privacy type for SIP Privacy header
> >
> >    Name of privacy = type:    id
>
> You need to reference the section of the = privacy spec which
> has defined
> this IANA registry. Furthermore, the = information provided here must
> match, word for word, the request information = defined by the privacy
> spec. Unfortuantely, it doesn't do that = properly yet, but
> these two docs
> need to get aligned on that.
>
> Thanks,
> Jonathan R.
>
>
>
>
>
>
>
> 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           : = Extensions to the Session
> Initiation Protocol
> > (SIP)
> = >           &n= bsp;           &n= bsp;   for Asserted Identity within
> Trusted Networks
> = >         = Author(s)       : C. Jennings, J. = Peterson, M. Watson
> = >         = Filename        : = draft-ietf-sip-asserted-identity-00.txt
> = >         = Pages           : = 17
> = >         = Date            = : 28-May-02
> >
> > This document describes private extensions = to SIP that enable a
> > network of trusted SIP servers to assert = the identity of
> end users or
> > end systems, and the application of = existing privacy mechanisms to
> > the identity problem.  The use of = these extensions is only
> applicable
> > inside an administrative domain with = previously agreed-upon policies
> > for generation, transport and usage of = such information.  This
> > document does NOT offer a general privacy = or identity model suitable
> > for inter-domain use, or use in the = Internet at large.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ass= erted-id
> entity-00.
> > txt
> >
> > To remove yourself from the IETF = Announcement list, send a
> message to
> > ietf-announce-request with the word = unsubscribe in the body of the
> > message.
> >
> > Internet-Drafts are also available by = anonymous FTP. Login with the
> > username
> > "anonymous" and a password of = your e-mail address. After logging in,
> > type "cd internet-drafts" and = then
> = >         "get = draft-ietf-sip-asserted-identity-00.txt".
> >
> > A list of Internet-Drafts directories can = be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by = e-mail.
> >
> > Send a message to:
> = >         = mailserv@ietf.org.
> > In the body type:
> = >         "FILE
> = /internet-drafts/draft-ietf-sip-asserted-identity-00.txt".
> >
> > NOTE:   The mail server at = ietf.org can return the document in
> = >         MIME-encoded form = by using the "mpack" utility.  To use this
> = >         feature, insert = the command "ENCODING mime" before
> the "FILE"
> = >         command.  To = decode the response(s), you will need
> "munpack" or
> = >         a MIME-compliant = mail reader.  Different MIME-compliant mail
> > readers
> = >         exhibit different = behavior, especially when dealing with
> = >         = "multipart" MIME messages (i.e. documents which
> have been split
> = >         up into multiple = messages), so check your local
> documentation on
> = >         how to manipulate = these messages.
> >
> >
> > Below is the data which will enable a MIME = compliant mail reader
> > implementation to automatically retrieve = the ASCII version of the
> > Internet-Draft.
> >
> >  
> = --------------------------------------------------------------
> ----------
> >
> > Subject:
> > Date: Wed, 29 May 2002 12:44:54 = -0400
> >
> >  
> = --------------------------------------------------------------
> ----------
> >
> >    ATT40156.txtName: = ATT40156.txt
> = >           &n= bsp;    Type: Plain Text (text/plain)
> >
> = >           &n= bsp;     Access-Type: anon-ftp
> >  Document = Info:        Site: = internet-drafts
> = >           &n= bsp;            = Mode: ftp.ietf.org
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>

------_=_NextPart_001_01C21150.97EA8942-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 08:22:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24717 for ; Wed, 12 Jun 2002 08:22:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22591 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 08:22:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21993; Wed, 12 Jun 2002 08:08:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21965 for ; Wed, 12 Jun 2002 08:08:19 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24281 for ; Wed, 12 Jun 2002 08:07:43 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 12 Jun 2002 07:07:39 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A77@NREXCH.netrake.net> Thread-Topic: Question on draft-ietf-sip-digest-aka-03.txt Thread-Index: AcIRicWvI3fd7KCrS62WCkvDeKeflAAVTVbQAAqO72A= From: "Rob Phillips" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA21966 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit So shouldn't the definitions be: algorithm = "algorithm" EQUAL (aka-namespace / algorithm-value) nonce = "nonce" EQUAL (aka-nonce / nonce-value) in order to be compatable with both bis-09 and sip-digest-aka-03? - rob -----Original Message----- From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] Sent: Wednesday, June 12, 2002 2:43 AM To: Rob Phillips; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Hi Rob, Digest-aka doesn't replace the algorithm and nonce definitions of bis-09, but extends them. More specifically, the draft talks about overloading of the algorithm definition by adding an AKA prefix to the token values; and extending of the nonce which in bis-09 is simply a quoted string. Cheers, Aki > -----Original Message----- > From: ext Rob Phillips [mailto:rob@netrake.com] > Sent: Tuesday, June 11, 2002 11:51 PM > To: sip@ietf.org > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > replace the definitions of "algorithm" and "nonce" that are > already defined in bis-09? Or merely to extend the definitions? > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake > Corporation > mailto: rob@netrake.com 3000 > Technology Drive > voice: (214) 291-1096 > Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, > Texas 75074 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 08:28:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24992 for ; Wed, 12 Jun 2002 08:28:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22755 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 08:29:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22315; Wed, 12 Jun 2002 08:13:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22283 for ; Wed, 12 Jun 2002 08:12:58 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24420 for ; Wed, 12 Jun 2002 08:12:21 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17I6zf-0000wU-00 for ; Wed, 12 Jun 2002 15:12:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.15047.806877.854553@harjus.eng.song.fi> Date: Wed, 12 Jun 2002 15:12:55 +0300 To: sip@ietf.org X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-asserted-identity-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit it is very frustrating that the authors of draft-ietf-sip-asserted-identity-01 don't take any of the comments in account that they themselves don't like when they issue new revisions of their draft. this would be ok if they would publish a private draft, but we are talking about a wg draft here. several people agreed with me that the word "hint" is not good and it was suggested to use the term "requested identity". also, there was a proposal to include a parameter to tell what the network must do in case it doesn't like the requested identity. finally, even if you, against the opinion of several people, decide to publish the asserted identity as an informational p header document, because you expect someone at some later day to publish the real thing, i don't see how how that argument would apply to requested identity over the ua-proxy interface. requested identity is as complete as it gets. so at minimum the requested identity header MUST be a non p header. that is by the way also a very good reason to use another name for the ua-proxy header. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 10:23:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29532 for ; Wed, 12 Jun 2002 10:23:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01991 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 10:24:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00111; Wed, 12 Jun 2002 10:00:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00064 for ; Wed, 12 Jun 2002 10:00:02 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28502 for ; Wed, 12 Jun 2002 09:59:24 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5CDxTq24065 for ; Wed, 12 Jun 2002 09:59:29 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 14:59:27 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB005330B35@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Dean Willis , Jonathan Rosenberg , duncan.mills@vf.vodafone.co.uk Cc: sip@ietf.org Subject: RE: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt Date: Wed, 12 Jun 2002 14:59:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Judging by the RFC text quoted below, 3GPP TS 24.229 is referencable, and has been since March. The version containing the relevant text will be available in a couple of weeks time - the content is approved. Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 10 June 2002 15:11 > To: Jonathan Rosenberg; duncan.mills@vf.vodafone.co.uk > Cc: sip@ietf.org > Subject: Re: [Sip] Re: I-D > ACTION:draft-mills-sip-access-network-info-02.t xt > > > > > [Duncan] The definition for the cell-id is just that it > is a string > of > > > hex. > > > It is defined already in 3GPP specifications. I agree the current > text > > > in > > > my draft is probably not adding much. I can't reference 3GPP > > > specifications > > > though, right? I wanted to describe it in this draft, as "You can > put > > > anything you want in here as a 'string'." "3GPP mobiles will be > limited > > > by > > > 3GPP specifications as to what they can put in there." [/Duncan] > > > > I don't see why you don't define the values in this spec... > shouldn't > > these specs at least stand alone and work outside of 3gpp so long as > the > > applicability statement holds true? > > Here's the rub -- the actual format is both defined in 3GPP > and subject > to change in 3GPP. This gives us a change control problem if > we attempt > to define it here. > > It IS possible to use external references to published > specifications in > an IETF document. > > From RFC 2026 (this stuff is in Section 7) > > An Internet Standard TS or AS may incorporate an open external > standard by reference. For example, many Internet Standards > incorporate by reference the ANSI standard character set > "ASCII" [2]. > Whenever possible, the referenced specification shall be available > online. > > On the other hand, I'm not yet certain whether the 3GPP rel 5 work is > considered "referenceable". I'm sure it will be eventually, but is it > now? Duncan, what is the state of the document defining cell-id? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 12:40:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04224 for ; Wed, 12 Jun 2002 12:40:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10912 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 12:40:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09223; Wed, 12 Jun 2002 12:13:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09156 for ; Wed, 12 Jun 2002 12:13:42 -0400 (EDT) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03296 for ; Wed, 12 Jun 2002 12:13:07 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v32.5.) id t.11c.127fd896 (3940); Wed, 12 Jun 2002 12:12:32 -0400 (EDT) Message-ID: <11c.127fd896.2a38ccf0@aol.com> Date: Wed, 12 Jun 2002 12:12:32 EDT Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 To: jh@lohi.eng.song.fi, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_11c.127fd896.2a38ccf0_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_11c.127fd896.2a38ccf0_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 8:24:10 AM Eastern Daylight Time, jh@lohi.eng.song.fi writes: > several people agreed with me that the word "hint" is not good and it > was suggested to use the term "requested identity". also, there was a > proposal to include a parameter to tell what the network must do in case > it doesn't like the requested identity. > I agree. This term "hint" is wrong. Independent of any techincal issues involved, no call control signaling should include elements that "hint" or "suggest" or "imply" or "allude" or "insinuate" or any such verb. All signaling should be based on containing explicit information that has specific meanings. Mike Pierce Artel --part1_11c.127fd896.2a38ccf0_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 8:24:10 AM Eastern Daylight Time, jh@lohi.eng.song.fi writes:


several people agreed with me that the word "hint" is not good and it
was suggested to use the term "requested identity".  also, there was a
proposal to include a parameter to tell what the network must do in case
it doesn't like the requested identity.


I agree. This term "hint" is wrong. Independent of any techincal issues involved, no call control signaling should include elements that "hint" or "suggest" or "imply" or "allude" or "insinuate" or any such verb. All signaling should be based on containing explicit information that has specific meanings.

Mike Pierce
Artel
--part1_11c.127fd896.2a38ccf0_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 13:33:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06128 for ; Wed, 12 Jun 2002 13:33:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13852 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 13:34:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12124; Wed, 12 Jun 2002 13:04:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12096 for ; Wed, 12 Jun 2002 13:04:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04994 for ; Wed, 12 Jun 2002 13:03:57 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5CH42Hs021856; Wed, 12 Jun 2002 10:04:02 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABV82133; Wed, 12 Jun 2002 10:01:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11906; Wed, 12 Jun 2002 10:04:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.32513.22563.484222@thomasm-u1.cisco.com> Date: Wed, 12 Jun 2002 10:04:01 -0700 (PDT) To: "Peterson, Jon" Cc: "'Michael Thomas'" , Cullen Jennings , sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal In-Reply-To: <70565611B164D511957A001083FCDD56018703D8@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703D8@va02.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The problem I see is that for all intents and purposes longterm > /dev/null. I'm not alone in this concern, nor is my concern about this without precedent. The entire structure of this wg seems to have become how we can best rationalize range of the moment hacks. What happened to the mindset of doing the necessary engineering to generalize what the PSTN did badly instead of slavishly reproducing its misfeatures, bug for bug? Mike PS: you are incorrect about the added vulnerablity; without cryptographic proof, both have equivalent transitive trust problems. Peterson, Jon writes: > Sorry for my delay in responding to this one. > > Agreed that identity-based assertions are ultimately better than role-based > assertions - no question. We made a simple scope decision that > identity-based assertion would be a matter for the long-term work, not the > short-term work. > > One of the reasons why we went in this direction was because we didn't feel > that we needed to have multiple P-Asserted-Identity headers in a message (or > more precisely, that we didn't feel we needed to have more than two, one for > a SIP[S] URI and one for a tel URL in support of certain PSTN gatewaying > applications) in order to satisfy the existing requirements. Agreed that > were a need for this to arise, multiple P-Asserted-Identity headers > (especially with different asserted identities) would be somewhat ambiguous. > > Another reason why an identity-based approach didn't seem like a good match > for the short-term work is that without cryptographic authentication of the > P-Asserted-Identity header, it is a bit too easy for someone to forge > something like an 'asserted-by' parameter or add falsified > P-Asserted-Identity headers that could mislead downstream entities. You > still need to keep track of trust-based identity (i.e. who sent me this, and > whether I am configured to trust them) in order to learn how much you should > trust the P-Asserted-Identity header(s) in a message. Adding any > cryptographic properties to the header is also outside the scope of the > short-term identity work. > > Finally, the short-term work is completely dependent on the concept of trust > domains discussed in Mark Watson's NAI requirements document. It therefore > has some slightly different assumptions about why proxies transitively trust > one another. An assertion from one intermediary in a trust domain is known > to be as good as an assertion from any other, as a trust domain is defined, > so knowing the identity of the particular intermediary that added the header > isn't immediately material. While the applicability of this might seem > limited, there are a number of parties that are apparently interested in > this sort of network. > > But that much said, it sounds like your remarks have some applicability to > the long-term identity work, which today has no explicit concept of > transitivity - your suggestions could prove valuable there. I put together a > separate proposal on long-term identity (draft-peterson-sip-identity-00), > and I'd appreciate any comments. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, June 05, 2002 7:36 AM > > To: Cullen Jennings > > Cc: sip@ietf.org > > Subject: [Sip] Asserted-Identity - new hint proposal > > > > > > > > So, I still haven't heard why the role based > > assertions is better than the alternative of > > identity based assertions. The way it's structured > > now, you seemingly either lose information along > > the way, or have an ambiguous situtation with > > multiple P-Asserted-Identity's. Suppose for > > example that my real name is thomasm, but I > > want to use my alias mat. What I'd do is: > > > > Asserted-Identity: ; asserted-by: > > ;etc > > > > At my first hop proxy, it would check to see if > > mat@cisco.com was an acceptible alias, and if it > > is, it would add a new AI to vouch for me: > > > > Asserted-Identity: ; asserted-by: > > > > > > When it's forwarded to the UAS proxy, it would > > know that it trusts proxy-15's assertions (but not > > thomasm's) and therefore add a new header for the > > UAS: > > > > Asserted-Identity: ; asserted-by: > > > > > > So clear back at luser.mtcc.com we finally get the > > INVITE and see these asserted-identities: > > > > Asserted-Identity: ; asserted-by: > > ;etc > > Asserted-Identity: ; asserted-by: > > > > Asserted-Identity: ; asserted-by: > > > > > > The UAS cdr's through the list and discovers -- > > aha! -- an asserted identity by proxy-22@mtcc.com > > which it trusts since it's the inbound proxy. > > Therefore, luser.mtcc.com knows that the identity > > it will use for the callerid is the one supplied by > > proxy-22. If proxy-22 didn't insert an > > asserted-identity, it probably means that it > > didn't trust the previous hop, and that the UAS > > should mark the callerid as suspect, if it > > displays anything at all. > > > > Notice that we don't need "roles" here of UA and > > proxy, but instead uses their actual identities. > > Note also that this could be generally applicable > > for more cases where you need to assert identity > > such as the firewall-proxy traversal case > > especially if it were combined with cryptographic > > proof by the party asserting the identity. It > > would also allow flexibility of _who_ enables > > traversal as well, ie that one of my proxies could > > insert the necessary credentials to get me through > > a foreign proxy instead of the UAC directly which > > would enable aggregation, and separation. > > > > Mike > > > > > > Cullen Jennings writes: > > > > > > I am getting the feeling that people want to put the hint > > in a separate > > > header. How would everyone feel about something along the lines of: > > > > > > P-Suggested-Identity: "Cullen Jennings" > > ;mandatory > > > > > > The UAC would insert this header to indicate the > > Asserted-Identity that it > > > wished the Trust Domain to choose. The "mandatory" > > indicates that the Trust > > > Domain MUST return some 4xx response if it is not going to > > assert this > > > identity. If the "mandatory" was not present, it would not > > return an 4xx if > > > it choose a different identity to assert for the user. > > > > > > Should we go with two headers (PSI and PAI)? > > > > > > Does PSI need some flag (like mandatory) to say how it is > > handled in the > > > case the suggested identity is not going to be provided? > > > > > > Alternatively, should we go with one header and the > > argument that Dean so > > > nicely summed up as > > > > I think existence of a P-A-I header in a message means > > "a previous hop > > > > (sender or proxy) has asserted this identity. Deal with it." > > > > > > > > Options for dealing with it are: > > > > > > > > 1) Believe it > > > > 2) Delete it (in conjunction with "privacy" modifier) > > > > 3) Delete it and assert a different identity > > > > 4) Reject the message > > > > > > 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 14:13:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07609 for ; Wed, 12 Jun 2002 14:13:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16278 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 14:14:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14557; Wed, 12 Jun 2002 13:51:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14526 for ; Wed, 12 Jun 2002 13:51:24 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06775 for ; Wed, 12 Jun 2002 13:50:49 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5CHokB23916; Wed, 12 Jun 2002 13:50:46 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 12:50:40 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703E3@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: Cullen Jennings , sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Wed, 12 Jun 2002 12:50:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree that there is a danger that the short-term work will become the de facto standard, and that the long-term work will never mature. On the former point, we have taken some steps to minimize that possibility (it's a P- header, it has very limited applicability, it is tied to the Trust Domain model, etc). On the latter point, I've already spent some time trying to work on the long-term story, and I've received quite a few comments, suggesting that there is some reasonable interest in this work. Rather than merely arguing that it will never amount to anything, I'd like to ask you to help those of us that are interested make this happen. We also hope to define a way of transitioning from the short-term to long-term model when both are relatively complete. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, June 12, 2002 10:04 AM > To: Peterson, Jon > Cc: 'Michael Thomas'; Cullen Jennings; sip@ietf.org > Subject: RE: [Sip] Asserted-Identity - new hint proposal > > > > The problem I see is that for all intents and > purposes longterm > /dev/null. I'm not alone in > this concern, nor is my concern about this without > precedent. The entire structure of this wg seems > to have become how we can best rationalize range > of the moment hacks. > > What happened to the mindset of doing the > necessary engineering to generalize what the PSTN > did badly instead of slavishly reproducing its > misfeatures, bug for bug? > > Mike > > PS: you are incorrect about the added vulnerablity; > without cryptographic proof, both have > equivalent transitive trust problems. > > Peterson, Jon writes: > > Sorry for my delay in responding to this one. > > > > Agreed that identity-based assertions are ultimately > better than role-based > > assertions - no question. We made a simple scope decision that > > identity-based assertion would be a matter for the > long-term work, not the > > short-term work. > > > > One of the reasons why we went in this direction was > because we didn't feel > > that we needed to have multiple P-Asserted-Identity > headers in a message (or > > more precisely, that we didn't feel we needed to have more > than two, one for > > a SIP[S] URI and one for a tel URL in support of certain > PSTN gatewaying > > applications) in order to satisfy the existing > requirements. Agreed that > > were a need for this to arise, multiple P-Asserted-Identity headers > > (especially with different asserted identities) would be > somewhat ambiguous. > > > > Another reason why an identity-based approach didn't seem > like a good match > > for the short-term work is that without cryptographic > authentication of the > > P-Asserted-Identity header, it is a bit too easy for > someone to forge > > something like an 'asserted-by' parameter or add falsified > > P-Asserted-Identity headers that could mislead downstream > entities. You > > still need to keep track of trust-based identity (i.e. who > sent me this, and > > whether I am configured to trust them) in order to learn > how much you should > > trust the P-Asserted-Identity header(s) in a message. Adding any > > cryptographic properties to the header is also outside the > scope of the > > short-term identity work. > > > > Finally, the short-term work is completely dependent on > the concept of trust > > domains discussed in Mark Watson's NAI requirements > document. It therefore > > has some slightly different assumptions about why proxies > transitively trust > > one another. An assertion from one intermediary in a trust > domain is known > > to be as good as an assertion from any other, as a trust > domain is defined, > > so knowing the identity of the particular intermediary > that added the header > > isn't immediately material. While the applicability of > this might seem > > limited, there are a number of parties that are apparently > interested in > > this sort of network. > > > > But that much said, it sounds like your remarks have some > applicability to > > the long-term identity work, which today has no explicit concept of > > transitivity - your suggestions could prove valuable > there. I put together a > > separate proposal on long-term identity > (draft-peterson-sip-identity-00), > > and I'd appreciate any comments. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Wednesday, June 05, 2002 7:36 AM > > > To: Cullen Jennings > > > Cc: sip@ietf.org > > > Subject: [Sip] Asserted-Identity - new hint proposal > > > > > > > > > > > > So, I still haven't heard why the role based > > > assertions is better than the alternative of > > > identity based assertions. The way it's structured > > > now, you seemingly either lose information along > > > the way, or have an ambiguous situtation with > > > multiple P-Asserted-Identity's. Suppose for > > > example that my real name is thomasm, but I > > > want to use my alias mat. What I'd do is: > > > > > > Asserted-Identity: ; asserted-by: > > > ;etc > > > > > > At my first hop proxy, it would check to see if > > > mat@cisco.com was an acceptible alias, and if it > > > is, it would add a new AI to vouch for me: > > > > > > Asserted-Identity: ; asserted-by: > > > > > > > > > When it's forwarded to the UAS proxy, it would > > > know that it trusts proxy-15's assertions (but not > > > thomasm's) and therefore add a new header for the > > > UAS: > > > > > > Asserted-Identity: ; asserted-by: > > > > > > > > > So clear back at luser.mtcc.com we finally get the > > > INVITE and see these asserted-identities: > > > > > > Asserted-Identity: ; asserted-by: > > > ;etc > > > Asserted-Identity: ; asserted-by: > > > > > > Asserted-Identity: ; asserted-by: > > > > > > > > > The UAS cdr's through the list and discovers -- > > > aha! -- an asserted identity by proxy-22@mtcc.com > > > which it trusts since it's the inbound proxy. > > > Therefore, luser.mtcc.com knows that the identity > > > it will use for the callerid is the one supplied by > > > proxy-22. If proxy-22 didn't insert an > > > asserted-identity, it probably means that it > > > didn't trust the previous hop, and that the UAS > > > should mark the callerid as suspect, if it > > > displays anything at all. > > > > > > Notice that we don't need "roles" here of UA and > > > proxy, but instead uses their actual identities. > > > Note also that this could be generally applicable > > > for more cases where you need to assert identity > > > such as the firewall-proxy traversal case > > > especially if it were combined with cryptographic > > > proof by the party asserting the identity. It > > > would also allow flexibility of _who_ enables > > > traversal as well, ie that one of my proxies could > > > insert the necessary credentials to get me through > > > a foreign proxy instead of the UAC directly which > > > would enable aggregation, and separation. > > > > > > Mike > > > > > > > > > Cullen Jennings writes: > > > > > > > > I am getting the feeling that people want to put the hint > > > in a separate > > > > header. How would everyone feel about something along > the lines of: > > > > > > > > P-Suggested-Identity: "Cullen Jennings" > > > ;mandatory > > > > > > > > The UAC would insert this header to indicate the > > > Asserted-Identity that it > > > > wished the Trust Domain to choose. The "mandatory" > > > indicates that the Trust > > > > Domain MUST return some 4xx response if it is not going to > > > assert this > > > > identity. If the "mandatory" was not present, it would not > > > return an 4xx if > > > > it choose a different identity to assert for the user. > > > > > > > > Should we go with two headers (PSI and PAI)? > > > > > > > > Does PSI need some flag (like mandatory) to say how it is > > > handled in the > > > > case the suggested identity is not going to be provided? > > > > > > > > Alternatively, should we go with one header and the > > > argument that Dean so > > > > nicely summed up as > > > > > I think existence of a P-A-I header in a message means > > > "a previous hop > > > > > (sender or proxy) has asserted this identity. Deal with it." > > > > > > > > > > Options for dealing with it are: > > > > > > > > > > 1) Believe it > > > > > 2) Delete it (in conjunction with "privacy" modifier) > > > > > 3) Delete it and assert a different identity > > > > > 4) Reject the message > > > > > > > > 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 > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 14:37:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08655 for ; Wed, 12 Jun 2002 14:37:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17828 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 14:38:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15829; Wed, 12 Jun 2002 14:04:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15800 for ; Wed, 12 Jun 2002 14:04:20 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07267 for ; Wed, 12 Jun 2002 14:03:44 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17ICTh-00011j-00; Wed, 12 Jun 2002 21:04:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.36129.670612.191469@harjus.eng.song.fi> Date: Wed, 12 Jun 2002 21:04:17 +0300 To: Michael Thomas Cc: "Peterson, Jon" , Cullen Jennings , sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal In-Reply-To: <15623.32513.22563.484222@thomasm-u1.cisco.com> References: <70565611B164D511957A001083FCDD56018703D8@va02.va.neustar.com> <15623.32513.22563.484222@thomasm-u1.cisco.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > What happened to the mindset of doing the > necessary engineering to generalize what the PSTN > did badly instead of slavishly reproducing its > misfeatures, bug for bug? this is exactly what 3gpp is doing. they are trying to re-implement their existing walled garden with new set of protocols (ip, sip, radius, etc). ietf should have no part in such a madness. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 14:41:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08787 for ; Wed, 12 Jun 2002 14:41:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17974 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 14:41:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16018; Wed, 12 Jun 2002 14:08:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15992 for ; Wed, 12 Jun 2002 14:08:22 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07432 for ; Wed, 12 Jun 2002 14:07:46 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5CI7JB24352; Wed, 12 Jun 2002 14:07:19 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:07:14 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703E4@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" , sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Wed, 12 Jun 2002 13:07:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A number of comments and suggestions were not integrated into the -01 for lack of time, not for any other reason (for example, splitting the mechanism out into the P-Preferred-Identity header and P-Asserted-Identity header). I think it is reasonable to abandon the term 'hint' in the document and replace it with something like you suggest below - it certainly isn't worth arguing about at this length, anyway. I am less flexible about this matter of the P- header for 'requested identity'. I presented an argument on this mailing list some weeks ago that enumerated the criteria for declaring something a P- header. Based on those considerations, I believe it is out of the question that P-Asserted-Identity should be anything other than a P- header. I also feel (though admittedly, less strongly) that P-Preferred-Identity meets these criteria in sipchange. The applicability of this header is very slight (it is restricted to those cases in which neither the From field, nor any other existing SIP header, nor the means of authentication, can express a desired identity for whatever reason). I do not believe any of the use cases you have raised have substantiated a genuine need for this to be standard SIP behavior. I might also note that I see quite a bit of correspondence between you and I on this matter in the past - I don't exactly feel that we've been ignoring your points. I simply feel it is almost laughable to suggest that we're in need of some standard way for a user to express their preferred identity when there are already so many to choose from in baseline SIP. The need for P-Preferred-Identity only arises in a very aberrant case. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Wednesday, June 12, 2002 5:13 AM > To: sip@ietf.org > Subject: [Sip] draft-ietf-sip-asserted-identity-01 > > > it is very frustrating that the authors of > draft-ietf-sip-asserted-identity-01 don't take any of the comments in > account that they themselves don't like when they issue new > revisions of > their draft. this would be ok if they would publish a private draft, > but we are talking about a wg draft here. > > several people agreed with me that the word "hint" is not good and it > was suggested to use the term "requested identity". also, there was a > proposal to include a parameter to tell what the network must > do in case > it doesn't like the requested identity. > > finally, even if you, against the opinion of several people, decide to > publish the asserted identity as an informational p header document, > because you expect someone at some later day to publish the > real thing, > i don't see how how that argument would apply to requested > identity over > the ua-proxy interface. requested identity is as complete as it gets. > > so at minimum the requested identity header MUST be a non p header. > that is by the way also a very good reason to use another name for the > ua-proxy header. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 14:48:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09051 for ; Wed, 12 Jun 2002 14:48:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18619 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 14:49:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16481; Wed, 12 Jun 2002 14:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16448 for ; Wed, 12 Jun 2002 14:20:05 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07740 for ; Wed, 12 Jun 2002 14:19:29 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17ICix-000122-00; Wed, 12 Jun 2002 21:20:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.37075.691560.935518@harjus.eng.song.fi> Date: Wed, 12 Jun 2002 21:20:03 +0300 To: "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 In-Reply-To: <70565611B164D511957A001083FCDD56018703E4@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703E4@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > I also feel (though admittedly, > less strongly) that P-Preferred-Identity meets these criteria in sipchange. > The applicability of this header is very slight (it is restricted to those > cases in which neither the From field, nor any other existing SIP header, > nor the means of authentication, can express a desired identity for whatever > reason). I do not believe any of the use cases you have raised have > substantiated a genuine need for this to be standard SIP behavior. looks to me that if 3gpp doesn't need it, it not worth doing. i have told several times that a user having multiple sip identities, e.g., phone numbers, is a real life case happening here all the time. if such a user uses Anonymous from header, there is currently no way for the user to tell, which real identity he/she wants to use. therefore sip is clearly lacking that functionality and it needs to be fixed by a real header that i can make vendors to implement (which is not the case for p headers). > I might also note that I see quite a bit of correspondence between you and I > on this matter in the past - I don't exactly feel that we've been ignoring > your points. I simply feel it is almost laughable to suggest that we're in > need of some standard way for a user to express their preferred identity > when there are already so many to choose from in baseline SIP. The need for > P-Preferred-Identity only arises in a very aberrant case. as i have said, there is no existing sip baseline or any other mechanism to handle the above case. also, i don't see anything temporary in the requested-identity header. or are the sip wg rules nowadays such that all new headers by default are p unless there are really good reasons to do real standard headers? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 15:03:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09725 for ; Wed, 12 Jun 2002 15:03:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19832 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 15:04:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17816; Wed, 12 Jun 2002 14:37:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17777 for ; Wed, 12 Jun 2002 14:37:56 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08646 for ; Wed, 12 Jun 2002 14:37:20 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5CIbNHs005914; Wed, 12 Jun 2002 11:37:23 -0700 (PDT) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADD38367; Wed, 12 Jun 2002 11:37:30 -0700 (PDT) From: "Cullen Jennings" To: , Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Wed, 12 Jun 2002 11:42:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15623.15047.806877.854553@harjus.eng.song.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I apologize for the frustration, I should have sent an email out to the list on these topics. Jon, Mark and I have been going around trying to figure out what the consensus is on the 'hint' single header vs. two header issue. It is not clear to me exactly what the consensus is. Even if the consensus was clear, none of us had time to get it correctly written up for the 01 draft. Anyways, long and short is, it was not in 01 draft due to lack of time but it is not clear to me what exactly needs to be done next here. The other issue of "To P or not to P" has been addressed several times on the list - I see it as not being an issue for the sip-asserted-identity draft but as an issue for draft-tsvarea-sipchange. Sorry for the frustration, Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > jh@lohi.eng.song.fi > Sent: Wednesday, June 12, 2002 5:13 AM > To: sip@ietf.org > Subject: [Sip] draft-ietf-sip-asserted-identity-01 > > > it is very frustrating that the authors of > draft-ietf-sip-asserted-identity-01 don't take any of the comments in > account that they themselves don't like when they issue new revisions of > their draft. this would be ok if they would publish a private draft, > but we are talking about a wg draft here. > > several people agreed with me that the word "hint" is not good and it > was suggested to use the term "requested identity". also, there was a > proposal to include a parameter to tell what the network must do in case > it doesn't like the requested identity. > > finally, even if you, against the opinion of several people, decide to > publish the asserted identity as an informational p header document, > because you expect someone at some later day to publish the real thing, > i don't see how how that argument would apply to requested identity over > the ua-proxy interface. requested identity is as complete as it gets. > > so at minimum the requested identity header MUST be a non p header. > that is by the way also a very good reason to use another name for the > ua-proxy header. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 15:09:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09943 for ; Wed, 12 Jun 2002 15:09:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20055 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 15:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18417; Wed, 12 Jun 2002 14:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18386 for ; Wed, 12 Jun 2002 14:45:29 -0400 (EDT) Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08938 for ; Wed, 12 Jun 2002 14:44:53 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m06.mx.aol.com (mail_out_v32.5.) id c.153.f3a56a1 (3940); Wed, 12 Jun 2002 14:43:55 -0400 (EDT) Message-ID: <153.f3a56a1.2a38f06b@aol.com> Date: Wed, 12 Jun 2002 14:43:55 EDT Subject: Re: [Sip] Asserted-Identity - new hint proposal To: mat@cisco.com, jon.peterson@neustar.biz CC: fluffy@cisco.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_153.f3a56a1.2a38f06b_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_153.f3a56a1.2a38f06b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 1:06:16 PM Eastern Daylight Time, mat@cisco.com writes: > The problem I see is that for all intents and > purposes longterm > /dev/null. I'm not alone in > this concern, nor is my concern about this without > precedent. The entire structure of this wg seems > to have become how we can best rationalize range > of the moment hacks. > > What happened to the mindset of doing the > necessary engineering to generalize what the PSTN > did badly instead of slavishly reproducing its > misfeatures, bug for bug? > > Mike > > PS: you are incorrect about the added vulnerablity; > without cryptographic proof, both have > equivalent transitive trust problems. > To all, I agree that "long term" probably means "never implemented". Or it means that there is never any short-term attempt to achieve what is really needed. I have to suspect that one of the purposes of this focus on "long-term" is to avoid any useful identification service in the near future. What is needed is to realize that, unless the means are defined to provide the currently required identification services, SIP can not be used to provide a commercial service which might replace the current (inferior?) telephone system. As a long time participant in the development of the US standards for identification/privacy, and watching the discussion here, it occurs to me that there is a fundamental difference between the two approaches: PSTN (US standards) - the goal was to provide a useful identification service, while recognizing the need for privacy IETF - the goal is to provide foolproof privacy, while maybe providing identification in some cases. Just my thoughts. Mike Pierce Artel --part1_153.f3a56a1.2a38f06b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/12/02 1:06:16 PM Eastern Daylight Time, mat@cisco.com writes:


The problem I see is that for all intents and
purposes longterm > /dev/null. I'm not alone in
this concern, nor is my concern about this without
precedent. The entire structure of this wg seems
to have become how we can best rationalize range
of the moment hacks.

What happened to the mindset of doing the
necessary engineering to generalize what the PSTN
did badly instead of slavishly reproducing its
misfeatures, bug for bug?

         Mike

PS: you are incorrect about the added vulnerablity;
   without cryptographic proof, both have
   equivalent transitive trust problems.


To all,

I agree that "long term" probably means "never implemented". Or it means that there is never any short-term attempt to achieve what is really needed. I have to suspect that one of the purposes of this focus on "long-term" is to avoid any useful identification service in the near future. What is needed is to realize that, unless the means are defined to provide the currently required identification services, SIP can not be used to provide a commercial service which might replace the current (inferior?) telephone system.

As a long time participant in the development of the US standards for identification/privacy, and watching the discussion here, it occurs to me that there is a fundamental difference between the two approaches:

PSTN (US standards) - the goal was to provide a useful identification service, while recognizing the need for privacy
IETF - the goal is to provide foolproof privacy, while maybe providing identification in some cases.

Just my thoughts.

Mike Pierce
Artel

--part1_153.f3a56a1.2a38f06b_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 15:15:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10170 for ; Wed, 12 Jun 2002 15:15:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20247 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 15:16:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18704; Wed, 12 Jun 2002 14:50:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18676 for ; Wed, 12 Jun 2002 14:50:40 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09090 for ; Wed, 12 Jun 2002 14:50:04 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5CIsNV16447 for ; Wed, 12 Jun 2002 13:54:23 -0500 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Jun 2002 13:49:35 -0500 Message-Id: <1023907776.1191.76.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Refer status/adjustment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A set of converging concerns were raised about the REFER draft late in the review process, all centering on draft's use of sip-events (soon to be RFC3265) and the implicit subscription. When investigating those concerns, several things became clear. The draft did not provide sufficient discussion around managing the lifecycle of the implicit subscription (Can you refresh the implicit subscription? unsubscribe? How is the Subscription-State header supposed to be used? How do the two parties know when the subscription is over?) and the draft did not clearly specify some of the things RFC3265 requires of an event package. These need to be corrected. A larger issue centers around the following language from sip-events: Note that any behavior designated with "SHOULD" or "MUST" in this document is not allowed to be weakened by extension documents; however, such documents may elect to strengthen "SHOULD" requirements to "MUST" strength if required by their application. The current draft is not clear enough on one particular point - the examples do not show immediate NOTIFYs for the implicit subscription. I expect that many members of the community believe they are not required (I had drifted into thinking that way before the comments caused me to look at this more closely). The normative text in the current REFER draft calls to RFC3265, and immediate NOTIFYs are very clearly required there. This needs to be pointed out more clearly in the REFER draft. Finally, the current draft makes instantiating a subscription a SHOULD strength requirement, but provides no mechanism for the agent sending the REFER to know whether or not to expect a NOTIFY. We have repeatedly had discussions on the list about how long the agent sending the REFER should keep state waiting for a NOTIFY - and with discomfort deciding that is an implementation decision. Recent discussions have pointed out that there is disagreement about what never receiving a NOTIFY means - should the REFERing party treat that as an error and re-attempt the reference or should it just assume no subscription was created? I've put together an individual submission that adds all the above clarifications. It also proposes a new mechanism to address the problems in the previous paragraph. Basically, it provides a way for the party sending the REFER to indicate that it really wants to be notified, and a way for the agent accepting the refer to signal that it will or will not send notifies in the response to the REFER. I just submitted this draft - until it appears in the repository, you can get it from http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt I propose that this draft replace refer-05 before it advances further in the standardization process. 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 daemon@optimus.ietf.org Wed Jun 12 18:37:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15669 for ; Wed, 12 Jun 2002 18:37:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02163 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 18:38:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01105; Wed, 12 Jun 2002 18:18:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01076 for ; Wed, 12 Jun 2002 18:18:26 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15285 for ; Wed, 12 Jun 2002 18:17:50 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5CMHNT16457; Wed, 12 Jun 2002 17:17:23 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:17:18 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Wed, 12 Jun 2002 17:17:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org For the nth time, if a user selects an anonymous From header field, that does NOT mean that there is no other way in the base SIP specification for them to specify an identity to an intermediary. The point is that 3GPP also rejects any other of the conceivable ways of doing so for various reasons. Your application has never seemed to me to suffer from the same limitations - if there is any disagreement between you and I it seems to be on that point alone, but the description of your application may not have been sufficiently detailed for me to understand all of your requirements. Frankly, Juha, given the fact that you despise the 3GPP process and architecture, I don't see why you aren't content to let 3GPP-specific extensions like asserted identity remain in a P- header ghetto. Making the 'requested identity' a standard header would certainly further encourage the proliferation of the 3GPP architecture by validating some of their extremely unSIPlike architectural assumptions. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Wednesday, June 12, 2002 11:20 AM > To: Peterson, Jon > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > I also feel (though admittedly, > > less strongly) that P-Preferred-Identity meets these > criteria in sipchange. > > The applicability of this header is very slight (it is > restricted to those > > cases in which neither the From field, nor any other > existing SIP header, > > nor the means of authentication, can express a desired > identity for whatever > > reason). I do not believe any of the use cases you have raised have > > substantiated a genuine need for this to be standard SIP behavior. > > looks to me that if 3gpp doesn't need it, it not worth doing. i have > told several times that a user having multiple sip identities, e.g., > phone numbers, is a real life case happening here all the > time. if such > a user uses Anonymous from header, there is currently no way for the > user to tell, which real identity he/she wants to use. > therefore sip is > clearly lacking that functionality and it needs to be fixed by a real > header that i can make vendors to implement (which is not the > case for p > headers). > > > I might also note that I see quite a bit of correspondence > between you and I > > on this matter in the past - I don't exactly feel that > we've been ignoring > > your points. I simply feel it is almost laughable to > suggest that we're in > > need of some standard way for a user to express their > preferred identity > > when there are already so many to choose from in baseline > SIP. The need for > > P-Preferred-Identity only arises in a very aberrant case. > > as i have said, there is no existing sip baseline or any > other mechanism > to handle the above case. also, i don't see anything temporary in the > requested-identity header. or are the sip wg rules nowadays such that > all new headers by default are p unless there are really good > reasons to > do real standard headers? > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 12 22:54:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20492 for ; Wed, 12 Jun 2002 22:54:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11813 for sip-archive@odin.ietf.org; Wed, 12 Jun 2002 22:55:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11402; Wed, 12 Jun 2002 22:39:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11370 for ; Wed, 12 Jun 2002 22:38:58 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-50.dsl.rcsntx.swbell.net [64.217.198.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20269 for ; Wed, 12 Jun 2002 22:38:14 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5D2Dqn32188; Wed, 12 Jun 2002 21:13:53 -0500 Message-ID: <3D080CBE.145E57AF@infravast.com> Date: Wed, 12 Jun 2002 22:08:46 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Michael Thomas , "Peterson, Jon" , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Asserted-Identity - new hint proposal References: <70565611B164D511957A001083FCDD56018703D8@va02.va.neustar.com> <15623.32513.22563.484222@thomasm-u1.cisco.com> <15623.36129.670612.191469@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > Michael Thomas writes: > > > What happened to the mindset of doing the > > necessary engineering to generalize what the PSTN > > did badly instead of slavishly reproducing its > > misfeatures, bug for bug? > > this is exactly what 3gpp is doing. they are trying to re-implement > their existing walled garden with new set of protocols (ip, sip, radius, > etc). ietf should have no part in such a madness. I cant speak for 3GPP (I dont know enough about it) but walled gardens exist and will continue to exist, out of necessity, for reasons of security or lack of resources...yada..yada, within many carrier, corporate, and SOHO networks. The concepts that I have seen discussed regarding asserted identity, hints, etc....are valid for any or all of these infrastructures as well as those that join with one or more infrastructures to offer enhancements or share resources. Sure maybe the names could be worked on but the concepts are valid. From what I have seen 3GPP is adopting SIP and, just as the enterprise and carriers are trying to fit SIP into their infrastructures while maintaining the policies that they must enforce in order to meet legal and protective requirements, and I have seen some very good thoughts and opinions pour out into this list that will become a necessity for SIP as well. I am grateful that the topics have been brought out into the open for discussion now than later. It is one thing to not desire the re-invention of the PSTN, but legalities and business policies must be met in the real world by the entities that will provide the services, whether for profit or not. These issues exist in the PSTN world but that does not make them products of the PSTN world. It makes them products of the communications world that must be met by all communications solutions that are developed with the goal of attempting to provide the types of solutions that SIP will be capable of providing now and in the future to everyone. To continue to perform nothing more than name calling because "they" dont conform to your way of thinking is ludicrous. All of these discussions and attempts to integrate existing architecture (at least those based on IP for our requirements) furthers the development of SIP and aids in the devlopment of new ideas. I want to hear and read more about this and offer what I can when I can, and hope you will too. Chris > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 04:40:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04911 for ; Thu, 13 Jun 2002 04:40:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04484 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 04:40:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03319; Thu, 13 Jun 2002 04:16:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03262 for ; Thu, 13 Jun 2002 04:16:31 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04428; Thu, 13 Jun 2002 04:15:55 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5D8FxV17207; Thu, 13 Jun 2002 03:15:59 -0500 From: "Dean Willis" To: , Date: Thu, 13 Jun 2002 03:15:20 -0500 Message-ID: <002801c212b2$7855e910$57c8d143@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Your're not going to believe this "optional" quirk of some email servers . . . Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This one was new to me. Apparently some sites are blocking emails with the string (ignore the spaces) "o p t i n". So if you misspell "option", I get a bunch of bounce messages. And your email won't have gone to quite as many people as you had hoped . . . What will they think of next? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 05:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05129 for ; Thu, 13 Jun 2002 05:01:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05448 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 05:02:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04625; Thu, 13 Jun 2002 04:48:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04586 for ; Thu, 13 Jun 2002 04:48:45 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04980 for ; Thu, 13 Jun 2002 04:48:04 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5D8n5i28061 for ; Thu, 13 Jun 2002 11:49:05 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Jun 2002 11:48:39 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 13 Jun 2002 11:48:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Date: Thu, 13 Jun 2002 11:48:39 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED51@esebe013.NOE.Nokia.com> Thread-Topic: Question on draft-ietf-sip-digest-aka-03.txt Thread-Index: AcIRicWvI3fd7KCrS62WCkvDeKeflAAVTVbQAAqO72AAK1K+0A== To: , X-OriginalArrivalTime: 13 Jun 2002 08:48:39.0783 (UTC) FILETIME=[1D308770:01C212B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA04587 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Rob, I guess you're right, although I think this is implicitly mentioned in the text although the definitions don't show it. The problem is also that the document is already in the RFC Editor's queue, so changes aren't possible at this point. It would've been really good to get these comments in during the WG/IETF last calls... Cheers, Aki > -----Original Message----- > From: ext Rob Phillips [mailto:rob@netrake.com] > Sent: Wednesday, June 12, 2002 3:08 PM > To: sip@ietf.org > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > So shouldn't the definitions be: > > algorithm = "algorithm" EQUAL (aka-namespace > / algorithm-value) > nonce = "nonce" EQUAL (aka-nonce / nonce-value) > > in order to be compatable with both bis-09 and sip-digest-aka-03? > > - rob > > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Wednesday, June 12, 2002 2:43 AM > To: Rob Phillips; sip@ietf.org > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Hi Rob, > > Digest-aka doesn't replace the algorithm and nonce > definitions of bis-09, but extends them. More specifically, > the draft talks about overloading of the algorithm definition > by adding an AKA prefix to the token values; and extending of > the nonce which in bis-09 is simply a quoted string. > > Cheers, > Aki > > > > -----Original Message----- > > From: ext Rob Phillips [mailto:rob@netrake.com] > > Sent: Tuesday, June 11, 2002 11:51 PM > > To: sip@ietf.org > > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > > replace the definitions of "algorithm" and "nonce" that are > > already defined in bis-09? Or merely to extend the definitions? > > > > - rob > > > > -- > > Rob Phillips, Sr. Software Engineer Netrake > > Corporation > > mailto: rob@netrake.com 3000 > > Technology Drive > > voice: (214) 291-1096 > > Suite 100 > > fax: (214) 291-1010 http://www.netrake.com Plano, > > Texas 75074 > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 07:45:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08129 for ; Thu, 13 Jun 2002 07:45:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13295 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 07:46:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11575; Thu, 13 Jun 2002 07:27:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11546 for ; Thu, 13 Jun 2002 07:26:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07578; Thu, 13 Jun 2002 07:26:19 -0400 (EDT) Message-Id: <200206131126.HAA07578@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 13 Jun 2002 07:26:19 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Security Mechanism Agreement for SIP Sessions Author(s) : J. Arkko et al. Filename : draft-ietf-sip-sec-agree-03.txt Pages : 17 Date : 12-Jun-02 SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol, such as HTTP authentication or secure attachments. These mechanisms have even alternative algorithms and parameters. SIP does not currently provide any mechanism for selecting which security mechanisms to use between two entities. In particular, even if some mechanisms such as OPTIONS were used to make this selection, the selection would be vulnerable against the Bidding-Down attack. This document defines three header fields for negotiating the security mechanisms within SIP between a SIP entity and its next SIP hop. A SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, but the negotiation can agree on which specific minimum security is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-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-sec-agree-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-sec-agree-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: <20020612145530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-agree-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-agree-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020612145530.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 09:35:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11623 for ; Thu, 13 Jun 2002 09:35:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA19944 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 09:35:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17645; Thu, 13 Jun 2002 09:06:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09952 for ; Thu, 13 Jun 2002 07:00:12 -0400 (EDT) Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06811 for ; Thu, 13 Jun 2002 06:59:36 -0400 (EDT) From: Dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.11.6+Sun/8.11.6) with ESMTP id g5DAuuW05410; Thu, 13 Jun 2002 13:56:57 +0300 (IDT) To: aki.niemi@nokia.com Cc: sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Thu, 13 Jun 2002 13:53:58 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 06/13/2002 01:53:59 PM, Serialize complete at 06/13/2002 01:53:59 PM Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Digest-aka does change the definition of the "nonce" field. A "nonce" is an opaque value from the client's perspecfive, and it is completely server-implementation-specific. however, "aka-nonce" is a set of specific fields. Why not define those fields explicitly? e.g. rand=, autn= (the server-specific data IS the original intent of the "nonce" field...) --Original Message To: ; From: aki.niemi@nokia.com Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Hi Rob, Digest-aka doesn't replace the algorithm and nonce definitions of bis-09, but extends them. More specifically, the draft talks about overloading of the algorithm definition by adding an AKA prefix to the token values; and extending of the nonce which in bis-09 is simply a quoted string. Cheers, Aki > -----Original Message----- > From: ext Rob Phillips [mailto:rob@netrake.com] > Sent: Tuesday, June 11, 2002 11:51 PM > To: sip@ietf.org > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > replace the definitions of "algorithm" and "nonce" that are > already defined in bis-09? Or merely to extend the definitions? > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake > Corporation > mailto: rob@netrake.com 3000 > Technology Drive > voice: (214) 291-1096 > Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, > Texas 75074 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Mailing-List: Session Initiation Protocol _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 10:18:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14090 for ; Thu, 13 Jun 2002 10:18:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24221 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 10:18:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20967; Thu, 13 Jun 2002 09:50:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20938 for ; Thu, 13 Jun 2002 09:50:11 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12321 for ; Thu, 13 Jun 2002 09:49:32 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DDnat06103 for ; Thu, 13 Jun 2002 09:49:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 09:49:36 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5E3@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: sip@ietf.org Date: Thu, 13 Jun 2002 09:49:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212E0.EF00F7AC" Subject: [Sip] SOS: RFC Numbers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C212E0.EF00F7AC Content-Type: text/plain; charset="iso-8859-1" Could someone please give me the list of RFC numbers that were assigned in March, or tell me where to find them? I'm updating references in the ITU-T SG 11 documentation. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C212E0.EF00F7AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SOS: RFC Numbers

Could someone please give me the list of RFC numbers = that were assigned in March, or tell me where to find them?  I'm = updating references in the ITU-T SG 11 documentation.

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C212E0.EF00F7AC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 10:31:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14929 for ; Thu, 13 Jun 2002 10:31:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25788 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 10:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23703; Thu, 13 Jun 2002 10:11:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23669 for ; Thu, 13 Jun 2002 10:11:44 -0400 (EDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13776 for ; Thu, 13 Jun 2002 10:11:06 -0400 (EDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g5DEBMh14168; Thu, 13 Jun 2002 10:11:23 -0400 Message-Id: <200206131411.g5DEBMh14168@minotaur.nge.isi.edu> To: "Tom-PT Taylor" cc: sip@ietf.org Reply-To: mankin@isi.edu Subject: From AD -- Re: [Sip] SOS: RFC Numbers In-reply-to: Your message of Thu, 13 Jun 2002 09:49:38 -0400. <4D79C746863DD51197690002A52CDA0001E8A5E3@zcard0kc.ca.nortel.com> Date: Thu, 13 Jun 2002 10:11:22 -0400 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Tom, Important to note: Fast RFC numbers such as we got in March are available only on a limited basis, e.g. for an SDO that must reference numbers due to its deadlines. They are not for public use till the RFCs come out, because otherwise the RFC Editor gets deluged with mail that RFC XXXX is missing from the archive and this is a real waste of their time. I can send you the March numbers today for the ITU reference use. Allison Area Director for SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 11:12:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16887 for ; Thu, 13 Jun 2002 11:12:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28949 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 11:13:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27232; Thu, 13 Jun 2002 10:47:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27187 for ; Thu, 13 Jun 2002 10:47:53 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15736 for ; Thu, 13 Jun 2002 10:47:14 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17IVt4-0001Hg-00; Thu, 13 Jun 2002 17:47:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.45201.949570.935242@harjus.eng.song.fi> Date: Thu, 13 Jun 2002 17:47:45 +0300 To: "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 In-Reply-To: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > For the nth time, if a user selects an anonymous From header field, that > does NOT mean that there is no other way in the base SIP specification for > them to specify an identity to an intermediary. the only other way that i'm aware is having a different username/password for each identity, which is not acceptable to our customers. they want to have a single username/password and multiple sip identities. i would like to hear your base sip solution to this. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 14:42:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25555 for ; Thu, 13 Jun 2002 14:42:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13304 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 14:43:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11837; Thu, 13 Jun 2002 14:22:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11811 for ; Thu, 13 Jun 2002 14:22:27 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24820 for ; Thu, 13 Jun 2002 14:21:49 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5DILNB15320; Thu, 13 Jun 2002 14:21:23 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 13:21:18 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703F1@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Thu, 13 Jun 2002 13:21:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Your users can have multiple identities and a single password with the existing SIP Digest authentication system. Groups of identities can simply use the same password (users do it all the time today when they are known by multiple names): Auth: username=+358-8-XXX-1234, password=foo or Auth: username=+358-8-XXX-1235, password=foo or Auth: username=+358-8-XXX-1236, password=foo Each username expressed with Digest is a different identity that is 'hinted' to the network, while the From field remains anonymous. This is exactly the same, from a protocol perspective, as having headers like this: Auth: username=juha, password=foo Hint: +358-8-XXX-1234 ... except that my way uses one less header. The intermediate 'juha' username adds no useful information to this (the service provider that receives an Authorization can also know administratively that 'juha' owns '+358-8-XXX 1234', if that's important). This technique is also applicable to most other authentication schemes (generally, such systems allow one to express a username). The real point of this whole sidebar, though, is this: if your application has some need to express some second identity in an anonymity case (like 'juha' distinct from '+358-8-XXX 1234'), then I suspect your requirements actually diverge somewhat from those of the short-term identity application anyway, and this would be a subject of further investigation. If it doesn't need this second identity, then the Digest system described above should work for you. The fact that you seem especially concerned with telephone numbers also makes your case a little different from the 3G case. Finally, I'd like to cite your description of your application from an earlier mail: "yes, since it would allow the user to have local identity in each of the 15 calling areas and people can return to the call to the user via a cheaper local call. having a separate username/password for each number is a nightmare not only to the user, but also for the service provider." ... and I would like to ask you what, if anything, this has to do with sending calls with an anonymous From header field. Your application is one in which the owner of those 15 numbers uses them in order to receive calls, not to originate calls. Why is it important that the user be able to choose one of these 15 identities on the fly when they originate (anonymous) calls? Do you really think users should individually select one of these 15 identities based on, perhaps, the telephone number of the person they are calling? Remember, the recipient of the call will never even see the calling party's number, because the From header field is anonymous - this hint will be consumed only by the network. None of the foreseeable effects of this seem powerful or beneficial to me. It sounds to me like the only case in which a user needs to select one of these 15 identities is when they register (a case where you would never have an anonymous From header). As far as I can understand it from your description, your service has little bearing on the anonymous identity assertion problem. In so far as it does, I'm not sure exactly what requirements it introduces. I promise you that if the relevance of your needs were more clear, the remainder of the mailing list would be more responsive to your diatribes. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, June 13, 2002 7:48 AM > To: Peterson, Jon > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > For the nth time, if a user selects an anonymous From > header field, that > > does NOT mean that there is no other way in the base SIP > specification for > > them to specify an identity to an intermediary. > > the only other way that i'm aware is having a different > username/password for each identity, which is not acceptable to our > customers. they want to have a single username/password and multiple > sip identities. i would like to hear your base sip solution to this. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 14:59:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26218 for ; Thu, 13 Jun 2002 14:59:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14040 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 15:00:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13125; Thu, 13 Jun 2002 14:37:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13096 for ; Thu, 13 Jun 2002 14:37:39 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25440 for ; Thu, 13 Jun 2002 14:37:03 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17IZTW-0001Kk-00; Thu, 13 Jun 2002 21:37:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.58993.624549.240319@harjus.eng.song.fi> Date: Thu, 13 Jun 2002 21:37:37 +0300 To: "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 In-Reply-To: <70565611B164D511957A001083FCDD56018703F1@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703F1@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Your users can have multiple identities and a single password with the > existing SIP Digest authentication system. Groups of identities can simply > use the same password (users do it all the time today when they are known by > multiple names): this is not acceptable to our users nor to us. we have a user database that includes one unique username and password per user. that database is not sip specific, but is used for all services that we may be providing for the user. it would thus be totally out question to start introducing new users to the user database if one user wants to have more than one sip identity. > ... and I would like to ask you what, if anything, this has to do with > sending calls with an anonymous From header field. Your application is one > in which the owner of those 15 numbers uses them in order to receive calls, > not to originate calls. Why is it important that the user be able to choose > one of these 15 identities on the fly when they originate (anonymous) > calls? the user simply does want to remain anonymous when he places a certain call, i.e., doesn't want to show any of its 15 sip identities. the user most likely still wants the calling party number to be one that belongs to the same area code to which he is calling to in order to save long distance charges. > Do you really think users should individually select one of these 15 > identities based on, perhaps, the telephone number of the person they are > calling? yes, see above. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 17:09:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00140 for ; Thu, 13 Jun 2002 17:09:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22276 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 17:10:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20173; Thu, 13 Jun 2002 16:48:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20143 for ; Thu, 13 Jun 2002 16:48:51 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29644 for ; Thu, 13 Jun 2002 16:48:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5DKmIYs000497; Thu, 13 Jun 2002 16:48:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:48:20 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1DF@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rob Phillips'" , sip@ietf.org Subject: RE: [Sip] Conflict(?) between sip-reason-01 and sip-events-05 Date: Thu, 13 Jun 2002 16:48:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org That's a really good point. I'd offer to change sip-events, but we're pushing out the RFC Real Soon Now. Henning? /a > -----Original Message----- > From: Rob Phillips [mailto:rob@netrake.com] > Sent: Wednesday, June 12, 2002 6:41 > To: sip@ietf.org > Subject: [Sip] Conflict(?) between sip-reason-01 and sip-events-05 > > > I noticed that there's a rule name conflict between > sip-reason-01 and sip-events-05. Both define BNF rules for > "reason-value" and "reason-extension", but the definitions > are certainly not compatable. While the guideline for > writing SIP extensions does not explicitly deal with this > issue, it seems to me that, to avoid confusion, BNF rules > should have unique names. > > Thoughts? > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake > Corporation > mailto: rob@netrake.com 3000 > Technology Drive > voice: (214) 291-1096 > Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, > Texas 75074 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 17:56:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01849 for ; Thu, 13 Jun 2002 17:56:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25561 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 17:57:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24856; Thu, 13 Jun 2002 17:40:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24820 for ; Thu, 13 Jun 2002 17:40:53 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01310 for ; Thu, 13 Jun 2002 17:40:15 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5DLeLIZ027597; Thu, 13 Jun 2002 14:40:21 -0700 (PDT) Received: from cisco.com (rtp-vpn2-560.cisco.com [10.82.242.48]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA19056; Thu, 13 Jun 2002 14:40:19 -0700 (PDT) Message-ID: <3D091143.528F3711@cisco.com> Date: Thu, 13 Jun 2002 17:40:19 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'jh@lohi.eng.song.fi'" , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 References: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > Frankly, Juha, given the fact that you despise the 3GPP process and > architecture, I don't see why you aren't content to let 3GPP-specific > extensions like asserted identity remain in a P- header ghetto. Ahem, what gave you the impression that this is only for 3GPP ? As you may recall, PacketCable started out requiring this three years ago and subsequently ITU-T SG9 requested this. Although an "acceptable" solution has not managed to materialize in this considerable time-span, it does not imply that the need or interest is gone. I'm sure there are other pragmatic parties that are interested in this as well. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 13 18:50:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03069 for ; Thu, 13 Jun 2002 18:50:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28217 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 18:50:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26935; Thu, 13 Jun 2002 18:22:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26906 for ; Thu, 13 Jun 2002 18:22:03 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02276 for ; Thu, 13 Jun 2002 18:21:27 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5DMB2B19992; Thu, 13 Jun 2002 18:11:02 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 17:10:57 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703F4@va02.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Thu, 13 Jun 2002 17:10:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have a feeling that this is the last email in this thread that I will respond to. Some (most likely wasted) notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, June 13, 2002 11:38 AM > To: Peterson, Jon > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > Your users can have multiple identities and a single password with the > > existing SIP Digest authentication system. Groups of identities can simply > > use the same password (users do it all the time today when they are known by > > multiple names): > > this is not acceptable to our users nor to us. we have a user database > that includes one unique username and password per user. that database > is not sip specific, but is used for all services that we may be > providing for the user. it would thus be totally out question to start > introducing new users to the user database if one user wants to have > more than one sip identity. > Your back-office implementation details are not a persuasive argument for why we should design a protocol one way or another. As I said in my last mail, it would be trivial to derive a unique username (like 'juha') from a hinted identity (a telephone number) in your back-office - the protocol design question (concerning P-Preferred-Identity) is only about what needs to be carried over the wire. Anyway, the system I described does not require you to 'introduce' any new usernames. [snip] > > Why is it important that the user be able to choose > > one of these 15 identities on the fly when they originate (anonymous) > > calls? > > the user simply does want to remain anonymous when he places a certain > call, i.e., doesn't want to show any of its 15 sip identities. the user > most likely still wants the calling party number to be one that belongs > to the same area code to which he is calling to in order to save long > distance charges. > So, you're honestly trying to tell me that users will save on long-distance charges depending on how they hint at their calling party number? Do you actually work for a telephone company? Accepting for a moment the insane proposition that phone companies will allow you to select among multiple identities in order to manipulate the rate that they charge you, why would this be an end-user function at all? Wouldn't the end user always just want the cheapest rate? Why not have the phone company just choose the best phone number for you - after all, they know the set of valid hints (i.e. calling party identities) that a given user can supply. Based on inspecting the numbers themselves, consumers might not always know how to select the cheapest identity. This application doesn't require any support in the SIP protocol, anyway. I'm sorry, Juha, but I don't think this is worth the working group's time anymore. I'd like to ask you to let this (now transparently silly) matter rest. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 22:31:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08706 for ; Thu, 13 Jun 2002 22:31:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07477 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 22:31:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06233; Thu, 13 Jun 2002 22:04:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06204 for ; Thu, 13 Jun 2002 22:04:17 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-50.dsl.rcsntx.swbell.net [64.217.198.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08100 for ; Thu, 13 Jun 2002 22:03:41 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5E1den01083; Thu, 13 Jun 2002 20:39:42 -0500 Message-ID: <3D09563F.63A74FE6@infravast.com> Date: Thu, 13 Jun 2002 21:34:39 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 References: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> <15624.45201.949570.935242@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > Peterson, Jon writes: > > > For the nth time, if a user selects an anonymous From header field, that > > does NOT mean that there is no other way in the base SIP specification for > > them to specify an identity to an intermediary. > > the only other way that i'm aware is having a different > username/password for each identity, which is not acceptable to our > customers. they want to have a single username/password and multiple > sip identities. i would like to hear your base sip solution to this. > Why couldnt you have the same username and password for each profile, it is the same person , right, and each would have to have a From that is recognized within the REALM woudlnt it (this is an actual question on my part not a statement)? Now from a security standpoint I typically dont recommend same username and passwords for multiple accounts in the computing world, but we are talking about this in terms of a network asserted identity for anonymity right with a network that has knowledge of the multiple identities and the username/password pairs? And since we are discussing network asserted identity, IMO, it doesnt mean that the username or password has to be passed outside the network or even within the network, it can merely be used as the method to verify that the proper account is getting the proper asserted identity, does this sound reasonable, or am I off on the topic here, since I am replying to the specific content of this email? > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 22:45:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09333 for ; Thu, 13 Jun 2002 22:45:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07705 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 22:44:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06727; Thu, 13 Jun 2002 22:21:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06698 for ; Thu, 13 Jun 2002 22:21:04 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-50.dsl.rcsntx.swbell.net [64.217.198.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08474 for ; Thu, 13 Jun 2002 22:20:28 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5E1uMn01111; Thu, 13 Jun 2002 20:56:23 -0500 Message-ID: <3D095A29.8973BFE7@infravast.com> Date: Thu, 13 Jun 2002 21:51:21 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: "Peterson, Jon" , "'jh@lohi.eng.song.fi'" , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 References: <70565611B164D511957A001083FCDD56018703E6@va02.va.neustar.com> <3D091143.528F3711@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > "Peterson, Jon" wrote: > > > Frankly, Juha, given the fact that you despise the 3GPP process and > > architecture, I don't see why you aren't content to let 3GPP-specific > > extensions like asserted identity remain in a P- header ghetto. > > Ahem, what gave you the impression that this is only for 3GPP ? As you may > recall, PacketCable started out requiring this three years ago and subsequently > ITU-T SG9 requested this. Although an "acceptable" solution has not managed to > materialize in this considerable time-span, it does not imply that the need or > interest is gone. I'm sure there are other pragmatic parties that are interested > in this as well. Yep, as I stated earlier, the solution is probably required in many areas by many infrastructures. > > -- Flemming > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 13 23:37:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09332 for ; Thu, 13 Jun 2002 22:45:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07723 for sip-archive@odin.ietf.org; Thu, 13 Jun 2002 22:44:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06620; Thu, 13 Jun 2002 22:19:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06596 for ; Thu, 13 Jun 2002 22:19:22 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-50.dsl.rcsntx.swbell.net [64.217.198.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08442 for ; Thu, 13 Jun 2002 22:18:45 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5E1sbn01098; Thu, 13 Jun 2002 20:54:43 -0500 Message-ID: <3D0959C0.AA30F329@infravast.com> Date: Thu, 13 Jun 2002 21:49:36 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 References: <70565611B164D511957A001083FCDD56018703F1@va02.va.neustar.com> <15624.58993.624549.240319@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > Peterson, Jon writes: > > > Your users can have multiple identities and a single password with the > > existing SIP Digest authentication system. Groups of identities can simply > > use the same password (users do it all the time today when they are known by > > multiple names): > > this is not acceptable to our users nor to us. we have a user database > that includes one unique username and password per user. that database > is not sip specific, but is used for all services that we may be > providing for the user. it would thus be totally out question to start > introducing new users to the user database if one user wants to have > more than one sip identity. This answers one of my earlier questions posed (and incorrect assumptions, at least for your application, within the response that I made regarding same un/pw)and is of course an issue of policy(s) which probably exist both for security and business reasons (Which is a good example of my earlier message where I mention these reasons for walled gardens). Hey this makes your application of SIP a type of walled garden too! :^) > > > ... and I would like to ask you what, if anything, this has to do with > > sending calls with an anonymous From header field. Your application is one > > in which the owner of those 15 numbers uses them in order to receive calls, > > not to originate calls. Why is it important that the user be able to choose > > one of these 15 identities on the fly when they originate (anonymous) > > calls? > > the user simply does want to remain anonymous when he places a certain > call, i.e., doesn't want to show any of its 15 sip identities. the user > most likely still wants the calling party number to be one that belongs > to the same area code to which he is calling to in order to save long > distance charges. Then IMO that would be an issue of provisioning at the network of this account based on the un/pw. Good point, gives us some perspective to your complaints. Chris > > > Do you really think users should individually select one of these 15 > > identities based on, perhaps, the telephone number of the person they are > > calling? > > yes, see above. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 02:20:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21251 for ; Fri, 14 Jun 2002 02:20:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA22424 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 02:21:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21138; Fri, 14 Jun 2002 01:54:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21111 for ; Fri, 14 Jun 2002 01:54:00 -0400 (EDT) Received: from mail6.triad.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12448 for ; Fri, 14 Jun 2002 01:53:23 -0400 (EDT) Received: from mail pickup service by mail6.triad.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 01:02:22 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.triad.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 12:23:17 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AGNFIa023667; Mon, 10 Jun 2002 12:23:15 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA05953 for ietf-123-outbound.05@ietf.org; Mon, 10 Jun 2002 12:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA02895 for ; Mon, 10 Jun 2002 07:20:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28687; Mon, 10 Jun 2002 07:19:34 -0400 (EDT) Message-Id: <200206101119.HAA28687@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, 10 Jun 2002 07:19:34 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-05.txt Pages : 18 Date : 07-Jun-02 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-guidelines-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-guidelines-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607140149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140149.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 02:21:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21270 for ; Fri, 14 Jun 2002 02:21:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA22440 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 02:21:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21088; Fri, 14 Jun 2002 01:52:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21057 for ; Fri, 14 Jun 2002 01:52:50 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12390 for ; Fri, 14 Jun 2002 01:52:13 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17Ik0d-0001Uy-00; Fri, 14 Jun 2002 08:52:31 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15625.33951.844512.102691@harjus.eng.song.fi> Date: Fri, 14 Jun 2002 08:52:31 +0300 To: "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 In-Reply-To: <70565611B164D511957A001083FCDD56018703F4@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703F4@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > So, you're honestly trying to tell me that users will save on long-distance > charges depending on how they hint at their calling party number? Do you > actually work for a telephone company? no, but that is how the telephone network works: it charges based on called and calling party numbers. another application is a user having two telephone numbers, one for private and another for company use. when he makes a call, he chooses which "line" to use so that the right calling party number will get charged. there is still only one username/password. users have been seriously asking this also for mobile phones: two calling party numbers with a single sim card. now some vendors have two sim cards in the cell phone in order to accomplish this, which is really silly (your term). so it looks to me that even the 3gpp guys may want what i'm proposing. it is the same thing when i login to my bank. with the same username/password i can manage my private and company accounts. the back doesn't tell me that i need different usernames/passwords for each. > Accepting for a moment the insane proposition that phone companies will > allow you to select among multiple identities in order to manipulate the > rate that they charge you, why would this be an end-user function at all? > Wouldn't the end user always just want the cheapest rate? Why not have the > phone company just choose the best phone number for you - after all, they > know the set of valid hints (i.e. calling party identities) that a given > user can supply. Based on inspecting the numbers themselves, consumers might > not always know how to select the cheapest identity. This application > doesn't require any support in the SIP protocol, anyway. see above, how would the phone company know if i'm making a private or company call? > I'm sorry, Juha, but I don't think this is worth the working group's time > anymore. I'd like to ask you to let this (now transparently silly) matter > rest. are you sure that they are not your opinions that are transparently silly? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 07:59:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25775 for ; Fri, 14 Jun 2002 07:59:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06565 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 08:00:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05747; Fri, 14 Jun 2002 07:41:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05716 for ; Fri, 14 Jun 2002 07:41:30 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25264 for ; Fri, 14 Jun 2002 07:40:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5EBfQrU008702; Fri, 14 Jun 2002 13:41:26 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5EBfQa9000719; Fri, 14 Jun 2002 14:41:26 +0300 (EET DST) Message-ID: <3D09D66A.D1B62EC5@lmf.ericsson.se> Date: Fri, 14 Jun 2002 14:41:30 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <2038BCC78B1AD641891A0D1AE133DBB7C20306@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Is an Allow-header allowed to be empty? > > The syntax in bis-09 suggests that this is not allowed. > > Allow = "Allow" HCOLON Method *(COMMA Method) > > If it is allowed, does it mean that the UAS does not support any methods? It is NOT allowed. And, if there is no header at all, it means that the UA doesn't indicate which methods it supports (chapter 20.5 in bis-9). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 08:53:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27524 for ; Fri, 14 Jun 2002 08:53:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09724 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 08:54:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09321; Fri, 14 Jun 2002 08:35:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09289 for ; Fri, 14 Jun 2002 08:35:35 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26979 for ; Fri, 14 Jun 2002 08:34:57 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5ECZ2N06592 for ; Fri, 14 Jun 2002 08:35:02 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 13:35:01 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E9F5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'jh@lohi.eng.song.fi'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 13:35:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Heavily snipped with response in line below Keith > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 14 June 2002 06:53 > To: Peterson, Jon > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > So, you're honestly trying to tell me that users will save > on long-distance > > charges depending on how they hint at their calling party > number? Do you > > actually work for a telephone company? > > no, but that is how the telephone network works: it charges based on > called and calling party numbers. > > another application is a user having two telephone numbers, one for > private and another for company use. when he makes a call, he chooses > which "line" to use so that the right calling party number will get > charged. there is still only one username/password. > > users have been seriously asking this also for mobile phones: two > calling party numbers with a single sim card. now some > vendors have two > sim cards in the cell phone in order to accomplish this, > which is really > silly (your term). so it looks to me that even the 3gpp guys may want > what i'm proposing. And this is exactly one of the ways that 3GPP are using the current draft. However as the user is already "registered" he does not need a password in 3GPP. We know that he is a valid user relating to one of a set of public user identities, then if that public user identity turns up as the hint, then the associated service profile is the one that he wishes to use. Even if you do not wish to have the 3GPP registration tie ins, you could still do the authorization on a per call basis and get the same capability. I think one of the things you are telling as is that you actually require multiple identities from the user. There are other identities that would have been useful from the 3GPP perspective that would have helped in providing the identification services to remote users, but we will have to wait for the long term approach for that as far as I understand. What we have at the moment is one identity which primarily relates to identifying the user as far as the network is concerned, e.g. in relation to service profile, billing. Where that identity is the same as that used for other identification then it can be used. Where it is not then we have to wait for the long term approach. This if I require an asserted return call number that is different from the asserted identity (i.e. an asserted form of the Reply-To header) then I will have to wait for the long term approach. Therefore even with the P-Asserted-Identity I cannot provide a fully flexible calling line identity presentati! on service. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 09:19:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28424 for ; Fri, 14 Jun 2002 09:19:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11174 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 09:20:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10655; Fri, 14 Jun 2002 09:05:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20022 for ; Fri, 14 Jun 2002 01:26:35 -0400 (EDT) Received: from tweb.telcoware.com ([211.235.252.201]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12011; Fri, 14 Jun 2002 01:25:57 -0400 (EDT) Received: from LocalHost (twclnt57.telcoware.com [211.235.252.57]) by tweb.telcoware.com (8.11.2/8.11.2) with SMTP id g5E5HWN10230; Fri, 14 Jun 2002 14:17:32 +0900 (KST) From: =?ks_c_5601-1987?B?sejA57D8?= To: , , Date: Fri, 14 Jun 2002 14:44:09 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id BAA20025 Subject: [Sip] Question about Proxy-Core "Determine Next-Hop Address, Port and Transport" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I have a question about proxy-core.. in bis-09 chapter 16.6 Request Forwarding line 2737 ~ 2742 as following.. 2737 As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and 2738 proceed through the set in order until the delivery attempt succeeds. 2739 For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send 2740 the request using a new client transaction as detailed in steps 8 through 10. Since each attempt uses a 2741 new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via 2742 header field inserted in step 8 MUST be different for each attempt. In here, "Locating SIP Server" procedure will produce several sets of ip, port, transport.. And Each tuple treated as new client transaction.. But.. How those each tuples treated as new client transaction ? I think each branch of each tuple will be same.. Because.. branch will be made by MD5 of several components of that message. => Route, Proxy-Require, Proxy-Authorization, To Tag, From Tag, Request-URI, Call-ID, CSeq number will be those component.. But Same component will be applied to each tuple.. so, same branch will be produced by each tuple.. Please let me know the correct answer... Have a nice day.. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 10:26:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00713 for ; Fri, 14 Jun 2002 10:26:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14307 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 10:27:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12762; Fri, 14 Jun 2002 09:53:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12731 for ; Fri, 14 Jun 2002 09:53:01 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29593 for ; Fri, 14 Jun 2002 09:52:19 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EDpbY03349; Fri, 14 Jun 2002 09:51:37 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 09:51:37 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5F2@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Peterson, Jon'" , "'jh@lohi.eng.song.fi'" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 09:51:25 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I hadn't realized you were a SIP WG Chair, Jon! I for one thought Juha had a reasonable requirement. Of course, I don't operate a network -- I should let the operators speak up. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Thursday, June 13, 2002 6:11 PM To: 'jh@lohi.eng.song.fi' Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 [snip] I'm sorry, Juha, but I don't think this is worth the working group's time anymore. I'd like to ask you to let this (now transparently silly) matter rest. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 10:46:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01629 for ; Fri, 14 Jun 2002 10:46:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15506 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 10:46:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14195; Fri, 14 Jun 2002 10:23:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14168 for ; Fri, 14 Jun 2002 10:23:28 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00644 for ; Fri, 14 Jun 2002 10:22:35 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EEMYK28701; Fri, 14 Jun 2002 16:22:34 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EEMWh19920; Fri, 14 Jun 2002 15:22:32 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 15:22:32 +0100 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'jh@lohi.eng.song.fi'" Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 15:22:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C213AE.EBC19AAA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C213AE.EBC19AAA Content-Type: text/plain; charset="iso-8859-1" I have a different reason from Juha as to why I think Digest does not fully solve this problem, as suggested by Jon. In the case that there is a secure connection between the user and the proxy (e.g. TLS) then when I have performed Digest authentication once, I do not need to perform it again for subsequent messages on the same connection. The SIP spec fairly strongly encourages the use of secure connections. If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. I suppose I could maintain separate TLS connections for each identity but this does then just become a judgement call between increased complexity (multiple TLS connections) and PDD (extra RTTs - which are l o n g in wireless) vs the addition of a new header. In my view, particularly in high-latency applications, the reduced complexity and PDD justifies the introduction of the new header. Regards...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 13 June 2002 23:11 > To: 'jh@lohi.eng.song.fi' > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > I have a feeling that this is the last email in this thread > that I will > respond to. Some (most likely wasted) notes below. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: Thursday, June 13, 2002 11:38 AM > > To: Peterson, Jon > > Cc: sip@ietf.org > > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > > > > Peterson, Jon writes: > > > > > Your users can have multiple identities and a single > password with the > > > existing SIP Digest authentication system. Groups of > identities can > simply > > > use the same password (users do it all the time today > when they are > known by > > > multiple names): > > > > this is not acceptable to our users nor to us. we have a > user database > > that includes one unique username and password per user. > that database > > is not sip specific, but is used for all services that we may be > > providing for the user. it would thus be totally out > question to start > > introducing new users to the user database if one user wants to have > > more than one sip identity. > > > > Your back-office implementation details are not a persuasive > argument for > why we should design a protocol one way or another. As I said > in my last > mail, it would be trivial to derive a unique username (like > 'juha') from a > hinted identity (a telephone number) in your back-office - > the protocol > design question (concerning P-Preferred-Identity) is only > about what needs > to be carried over the wire. Anyway, the system I described > does not require > you to 'introduce' any new usernames. > > [snip] > > > Why is it important that the user be able to choose > > > one of these 15 identities on the fly when they > originate (anonymous) > > > calls? > > > > the user simply does want to remain anonymous when he > places a certain > > call, i.e., doesn't want to show any of its 15 sip > identities. the user > > most likely still wants the calling party number to be one > that belongs > > to the same area code to which he is calling to in order to > save long > > distance charges. > > > > So, you're honestly trying to tell me that users will save on > long-distance > charges depending on how they hint at their calling party > number? Do you > actually work for a telephone company? > > Accepting for a moment the insane proposition that phone > companies will > allow you to select among multiple identities in order to > manipulate the > rate that they charge you, why would this be an end-user > function at all? > Wouldn't the end user always just want the cheapest rate? Why > not have the > phone company just choose the best phone number for you - > after all, they > know the set of valid hints (i.e. calling party identities) > that a given > user can supply. Based on inspecting the numbers themselves, > consumers might > not always know how to select the cheapest identity. This application > doesn't require any support in the SIP protocol, anyway. > > I'm sorry, Juha, but I don't think this is worth the working > group's time > anymore. I'd like to ask you to let this (now transparently > silly) matter > rest. > > > > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C213AE.EBC19AAA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-asserted-identity-01

I have a different reason from Juha as to why I think = Digest does not fully solve this problem, as suggested by Jon.

In the case that there is a secure connection between = the user and the proxy (e.g. TLS) then when I have performed Digest = authentication once, I do not need to perform it again for subsequent = messages on the same connection. The SIP spec fairly strongly = encourages the use of secure connections.

If I allow subsequent sessions on the same = connection, then this 'hint' becomes useful. Performing Digest = authentication again every time (requiring an additional RTT) seems a = heavy price just to communicate a few extra octets.

I suppose I could maintain separate TLS connections = for each identity but this does then just become a judgement call = between increased complexity (multiple TLS connections) and PDD (extra = RTTs - which are l o n g in wireless) vs the addition of a new = header.

In my view, particularly in high-latency = applications, the reduced complexity and PDD justifies the introduction = of the new header.

Regards...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: 13 June 2002 23:11
> To: 'jh@lohi.eng.song.fi'
> Cc: sip@ietf.org
> Subject: RE: [Sip] = draft-ietf-sip-asserted-identity-01
>
>
> I have a feeling that this is the last email in = this thread
> that I will
> respond to. Some (most likely wasted) notes = below.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> > Sent: Thursday, June 13, 2002 11:38 = AM
> > To: Peterson, Jon
> > Cc: sip@ietf.org
> > Subject: RE: [Sip] = draft-ietf-sip-asserted-identity-01
> >
> >
> > Peterson, Jon writes:
> >
> >  > Your users can have multiple = identities and a single
> password with the
> >  > existing SIP Digest = authentication system. Groups of
> identities can
> simply
> >  > use the same password (users do = it all the time today
> when they are
> known by
> >  > multiple names):
> >
> > this is not acceptable to our users nor to = us.  we have a
> user database
> > that includes one unique username and = password per user. 
> that database
> > is not sip specific, but is used for all = services that we may be
> > providing for the user.  it would = thus be totally out
> question to start
> > introducing new users to the user database = if one user wants to have
> > more than one sip identity.
> >
>
> Your back-office implementation details are not = a persuasive
> argument for
> why we should design a protocol one way or = another. As I said
> in my last
> mail, it would be trivial to derive a unique = username (like
> 'juha') from a
> hinted identity (a telephone number) in your = back-office -
> the protocol
> design question (concerning = P-Preferred-Identity) is only
> about what needs
> to be carried over the wire. Anyway, the system = I described
> does not require
> you to 'introduce' any new usernames.
>
> [snip]
> >  > Why is it important that the = user be able to choose
> >  > one of these 15 identities on = the fly when they
> originate (anonymous)
> >  > calls?
> >
> > the user simply does want to remain = anonymous when he
> places a certain
> > call, i.e., doesn't want to show any of = its 15 sip
> identities.  the user
> > most likely still wants the calling party = number to be one
> that belongs
> > to the same area code to which he is = calling to in order to
> save long
> > distance charges.
> >
>
> So, you're honestly trying to tell me that = users will save on
> long-distance
> charges depending on how they hint at their = calling party
> number? Do you
> actually work for a telephone company?
>
> Accepting for a moment the insane proposition = that phone
> companies will
> allow you to select among multiple identities = in order to
> manipulate the
> rate that they charge you, why would this be an = end-user
> function at all?
> Wouldn't the end user always just want the = cheapest rate? Why
> not have the
> phone company just choose the best phone number = for you -
> after all, they
> know the set of valid hints (i.e. calling party = identities)
> that a given
> user can supply. Based on inspecting the = numbers themselves,
> consumers might
> not always know how to select the cheapest = identity. This application
> doesn't require any support in the SIP = protocol, anyway.
>
> I'm sorry, Juha, but I don't think this is = worth the working
> group's time
> anymore. I'd like to ask you to let this (now = transparently
> silly) matter
> rest.
>
> >
> > -- juha
> >
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C213AE.EBC19AAA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 11:19:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02970 for ; Fri, 14 Jun 2002 11:19:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17369 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 11:20:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16060; Fri, 14 Jun 2002 10:59:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16033 for ; Fri, 14 Jun 2002 10:59:30 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02106 for ; Fri, 14 Jun 2002 10:58:51 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA16735; Fri, 14 Jun 2002 10:58:15 -0400 (EDT) Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 To: "Peterson, Jon" Cc: "'jh@lohi.eng.song.fi'" , sip@ietf.org Date: Fri, 14 Jun 2002 10:58:14 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 06/14/2002 10:58:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >So, you're honestly trying to tell me that users will save on long-distance >charges depending on how they hint at their calling party number? Do you >actually work for a telephone company? Personal and work accounts perhaps. The caller may not be the one paying for the call. He may be working for others who have negotiated their own arrangements. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 11:52:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04228 for ; Fri, 14 Jun 2002 11:52:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18884 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 11:53:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17592; Fri, 14 Jun 2002 11:26:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17562 for ; Fri, 14 Jun 2002 11:26:02 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03349 for ; Fri, 14 Jun 2002 11:25:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5EFPRYs004917; Fri, 14 Jun 2002 11:25:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:25:29 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1E4@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rob Phillips'" , sip@ietf.org Subject: RE: [Sip] Conflict(?) between sip-reason-01 and sip-events-05 Date: Fri, 14 Jun 2002 11:25:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We've taken care of this problem. In the events draft, they are now called "event-reason-value" and "event-reason-extension", respectively. Thanks for catching this! /a > -----Original Message----- > From: Rob Phillips [mailto:rob@netrake.com] > Sent: Wednesday, June 12, 2002 6:41 > To: sip@ietf.org > Subject: [Sip] Conflict(?) between sip-reason-01 and sip-events-05 > > > I noticed that there's a rule name conflict between > sip-reason-01 and sip-events-05. Both define BNF rules for > "reason-value" and "reason-extension", but the definitions > are certainly not compatable. While the guideline for > writing SIP extensions does not explicitly deal with this > issue, it seems to me that, to avoid confusion, BNF rules > should have unique names. > > Thoughts? > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake > Corporation > mailto: rob@netrake.com 3000 > Technology Drive > voice: (214) 291-1096 > Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, > Texas 75074 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 11:59:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04374 for ; Fri, 14 Jun 2002 11:59:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19082 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 11:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18473; Fri, 14 Jun 2002 11:41:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18442 for ; Fri, 14 Jun 2002 11:41:26 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03857 for ; Fri, 14 Jun 2002 11:40:47 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5EFe0V27779; Fri, 14 Jun 2002 10:40:00 -0500 From: "Dean Willis" To: "'Mark Watson'" , "'Peterson, Jon'" , Cc: Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 10:39:16 -0500 Message-ID: <000201c213b9$a4eabd40$657e8640@TXDWILLIS2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C2138F.BC14B540" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C2138F.BC14B540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark suggested: > If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . . but it does seem cleaner to use a preferred-identity indicator. -- Dean ------=_NextPart_000_0003_01C2138F.BC14B540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Mark suggested: 
> If = I allow=20 subsequent sessions on the same connection, then this 'hint' becomes = useful.=20 Performing Digest authentication again every time (requiring an = additional RTT)=20 seems a heavy price just to communicate a few extra octets. 
 
Er,=20 you COULD just include the appropriate credentials using the cached = nonce on=20 future requests, and not bother to actually rechallenge . .=20 .
 
but it=20 does seem cleaner to use a preferred-identity = indicator.
 
--
Dean
 

 
 
 
 
 
 
------=_NextPart_000_0003_01C2138F.BC14B540-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 12:31:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05440 for ; Fri, 14 Jun 2002 12:31:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22658 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 12:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20742; Fri, 14 Jun 2002 12:01:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20699 for ; Fri, 14 Jun 2002 12:01:49 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04475 for ; Fri, 14 Jun 2002 12:01:09 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5EG1DIZ009291; Fri, 14 Jun 2002 09:01:14 -0700 (PDT) Received: from cisco.com (rtp-vpn1-370.cisco.com [10.82.225.114]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA11455; Fri, 14 Jun 2002 09:01:12 -0700 (PDT) Message-ID: <3D0A1347.C155C23C@cisco.com> Date: Fri, 14 Jun 2002 12:01:11 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've been struggling with this too - it would be nice with an update to the unify draft (or something else) that explains how everything works between bis, manyfolks, update, and offer/answer. Mark Watson wrote: > > > Christer, > > As I understand it, the current situation is as follows: > > From the point of view of the UAC (assuming an SDP offer in the INVITE > for simplicity), then if > (i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > 183, 180 , UPDATE, 200 OK to UPDATE etc.), and > (ii) a=sendrecv or a=sendonly in this answer, and > (iii) any manyfolks pre-conditions have been met (i.e. this could be > an answer at the end of several offer/answer exchanges negotiating and > updating preconditions) > > then there is Early Media, and the UAC SHOULD (?) play this to the > caller. > Will this be the case irrespective of whether you got a 180 or a 183 ? My understanding was, that if you get a 180, then you will generate local ringback until you receive RTP (or whatever else you may have negotiated in your media stream(s)), whereas with 183, you do not generate local ringback. As an aside, I personally worry about the robustness of this coupling between signaling and presence of a single RTP packet. > > If there is no Early Media, or if the Early Media is on hold (SDP > answer contains a=recvonly or a=inactive) AND a 180 has been received, > then the UAC SHOULD (?) play local ringing. > > So, if the UAS does not want to generate Early Media then it has the > following choices: > (a) do not supply SDP answer until actual call Answer, or > (b) supply early SDP answer with a=recvonly or a=inactive > Again, I thought there was a distinction between 180 and 183 here ? > > Now, (b) is not much use to a UAS trying to negotiate media with > pre-conditions, since the direction attribute in this exchange will > affect the resources that are reserved, and therefore needs to reflect > the requirements of the eventual session. I don't think that's necessary, since manyfolks has its own direction attributes independent of the media stream direction attributes. Thus you could specify an inactive stream and require sendrevc reservation for it. What is not clear however, is how a UAC can negotiate bidirectional codec support without accepting early media in both directions. > > Therefore it would need to place the media on hold *after* the > pre-conditions have been met, using an UPDATE. > > A workaround at the UAC for dealing with a UAS which did not do this > is that, even if the offer/answer has been completed with a=sendrecv > the UAC pays attention to whether any RTP packets are actually being > received - if there are none, then it generates local ringing. > > Unfortunately, such a workaround is not really applicable to one class > of UACs for whom local ringing is quite important, namely distributed > PSTN to SIP gateways (consisting of Media Gateways and a Media Gateway > Controller as per Megaco model). This is because the information about > presence/absence of actual RTP packets is only available at the media > layer (MG) which does not make decisions for itself about issues such > as tones/announcements/inband ringing. That can be addressed pretty easily by defining the proper event(s). The question is how robust this whole sceheme is in the first place though. > > So, I can only hope that all UAS developers implementing Manyfolks are > aware of the need to put the media on hold as soon as the > pre-conditions have been met (unless thay are going to generate real > Eraly Media). > > A solution to this would be a way of explicitly indicating at the > SIP/SDP layer that a media stream, although not on hold, was > 'provisional', or did not contain actual media yet. I did not think > the Content-Disposition in Manyfolks has formally been given this > meaning. If it has, I'm not sure what 'undoes' this 'provisional' > status - it shouldn't be the 200 OK to the INVITE because the whole > point of UPDATE was to separate media changes from session changes - > so it would have to be another offer/answer without the special > Content-Disposition. But then are people aware they need to do this at > Answer time ? > We used to have a Content-Dispostion of "precondition" in manyfolks to make a distinction here, but it got removed for some reason. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 12:39:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05721 for ; Fri, 14 Jun 2002 12:39:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23150 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 12:39:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21889; Fri, 14 Jun 2002 12:22:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21858 for ; Fri, 14 Jun 2002 12:22:26 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05130 for ; Fri, 14 Jun 2002 12:21:48 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EGLkY03740; Fri, 14 Jun 2002 18:21:47 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EGLiw12619; Fri, 14 Jun 2002 17:21:45 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 17:21:45 +0100 Message-ID: From: "Mark Watson" To: "'Flemming Andreasen'" Cc: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Fri, 14 Jun 2002 17:21:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C213BF.2E5E21FC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C213BF.2E5E21FC Content-Type: text/plain; charset="iso-8859-1" > > Unfortunately, such a workaround is not really applicable > to one class > > of UACs for whom local ringing is quite important, namely > distributed > > PSTN to SIP gateways (consisting of Media Gateways and a > Media Gateway > > Controller as per Megaco model). This is because the > information about > > presence/absence of actual RTP packets is only available at > the media > > layer (MG) which does not make decisions for itself about > issues such > > as tones/announcements/inband ringing. > > That can be addressed pretty easily by defining the proper > event(s). The > question is how robust this whole sceheme is in the first > place though. > I don't think an 'RTP received' event from MG to MGC would be right architecturally for this, even if you could solve the robustness issue. The control layer should be aware of whether there is a media stream or not, and if there is, then it should not care what is inside it - i.e. whether it is 'silent' (=no packets) or not (=packets). i.e. I don't think we should attach control layer semantics to the contents of the media stream. ...Mark ------_=_NextPart_001_01C213BF.2E5E21FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Local vs Remote ringback on 180

> > Unfortunately, such a workaround is not = really applicable
> to one class
> > of UACs for whom local ringing is quite = important, namely
> distributed
> > PSTN to SIP gateways (consisting of Media = Gateways and a
> Media Gateway
> > Controller as per Megaco model). This is = because the
> information about
> > presence/absence of actual RTP packets is = only available at
> the media
> > layer (MG) which does not make decisions = for itself about
> issues such
> > as tones/announcements/inband = ringing.
>
> That can be addressed pretty easily by defining = the proper
> event(s). The
> question is how robust this whole sceheme is in = the first
> place though.
>

I don't think an 'RTP received' event from MG to MGC = would be right architecturally for this, even if you could solve the = robustness issue. The control layer should be aware of whether there is = a media stream or not, and if there is, then it should not care what is = inside it - i.e. whether it is 'silent' (=3Dno packets) or not = (=3Dpackets).

i.e. I don't think we should attach control layer = semantics to the contents of the media stream.

...Mark

------_=_NextPart_001_01C213BF.2E5E21FC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 13:00:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06362 for ; Fri, 14 Jun 2002 13:00:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24325 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 13:00:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23351; Fri, 14 Jun 2002 12:42:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23316 for ; Fri, 14 Jun 2002 12:41:59 -0400 (EDT) Received: from imo-m10.mx.aol.com (imo-m10.mx.aol.com [64.12.136.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05820 for ; Fri, 14 Jun 2002 12:41:23 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m10.mx.aol.com (mail_out_v32.5.) id t.134.fbb2d7b (4263); Fri, 14 Jun 2002 12:40:23 -0400 (EDT) Message-ID: <134.fbb2d7b.2a3b7677@aol.com> Date: Fri, 14 Jun 2002 12:40:23 EDT Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 To: jh@lohi.eng.song.fi, jon.peterson@neustar.biz CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_134.fbb2d7b.2a3b7677_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_134.fbb2d7b.2a3b7677_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/14/02 1:54:09 AM Eastern Daylight Time, jh@lohi.eng.song.fi writes: > another application is a user having two telephone numbers, one for > private and another for company use. when he makes a call, he chooses > which "line" to use so that the right calling party number will get > charged. there is still only one username/password. > > Absolutely correct and a valid application. In my house, served by a real telephone company, we have two telephone lines, each with a different number and each with a different billing plan for local and long distance service. Depending on which phone I pick up and dial, I get different rates. If this were supported with SIP, I can certainly see the possibility that I would have a single device (the computer I'm looking at?) and I need to specify which identity I want to use to originate a call, which may affect the rate I pay and the way the call is handled and the identity that gets delivered (or not) to the other end and whether or not I get a priority service, etc. Incidentally, IMO, watching comments flung back and forth for months, Juha appears to have a good understanding of what an "operator" needs, unlike some others who have been commenting on the subject. Mike Pierce Artel (sitting at home) --part1_134.fbb2d7b.2a3b7677_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/14/02 1:54:09 AM Eastern Daylight Time, jh@lohi.eng.song.fi writes:


another application is a user having two telephone numbers, one for
private and another for company use.  when he makes a call, he chooses
which "line" to use so that the right calling party number will get
charged.  there is still only one username/password.  



Absolutely correct and a valid application. In my house, served by a real telephone company, we have two telephone lines, each with a different number and each with a different billing plan for local and long distance service. Depending on which phone I pick up and dial, I get different rates.

If this were supported with SIP, I can certainly see the possibility that I would have a single device (the computer I'm looking at?) and I need to specify which identity I want to use to originate a call, which may affect the rate I pay and the way the call is handled and the identity that gets delivered (or not) to the other end and whether or not I get a priority service, etc.

Incidentally, IMO, watching comments flung back and forth for months, Juha appears to have a good understanding of what an "operator" needs, unlike some others who have been commenting on the subject.

Mike Pierce
Artel (sitting at home)
--part1_134.fbb2d7b.2a3b7677_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 13:32:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07430 for ; Fri, 14 Jun 2002 13:32:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26326 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 13:33:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24975; Fri, 14 Jun 2002 13:11:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24944 for ; Fri, 14 Jun 2002 13:11:25 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06721 for ; Fri, 14 Jun 2002 13:10:49 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5EHAYuF014697; Fri, 14 Jun 2002 10:10:34 -0700 (PDT) Received: from cisco.com (rtp-vpn1-370.cisco.com [10.82.225.114]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10286; Fri, 14 Jun 2002 10:10:52 -0700 (PDT) Message-ID: <3D0A239C.619B4EDB@cisco.com> Date: Fri, 14 Jun 2002 13:10:52 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > > > > > > Unfortunately, such a workaround is not really applicable > > to one class > > > of UACs for whom local ringing is quite important, namely > > distributed > > > PSTN to SIP gateways (consisting of Media Gateways and a > > Media Gateway > > > Controller as per Megaco model). This is because the > > information about > > > presence/absence of actual RTP packets is only available at > > the media > > > layer (MG) which does not make decisions for itself about > > issues such > > > as tones/announcements/inband ringing. > > > > That can be addressed pretty easily by defining the proper > > event(s). The > > question is how robust this whole sceheme is in the first > > place though. > > > > I don't think an 'RTP received' event from MG to MGC would be right > architecturally for this, even if you could solve the robustness > issue. The control layer should be aware of whether there is a media > stream or not, and if there is, then it should not care what is inside > it - i.e. whether it is 'silent' (=no packets) or not (=packets). > > i.e. I don't think we should attach control layer semantics to the > contents of the media stream. In its present form I agree, but it's been suggested more than once. Also, there is the related issue of clipping which in itself is a good reason for doing early media, but in some environments early media is not seen as a positive (extra bw consumption, can't charge for it). -- Flemming > > > ...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 13:53:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08052 for ; Fri, 14 Jun 2002 13:53:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26940 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 13:54:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26299; Fri, 14 Jun 2002 13:32:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26268 for ; Fri, 14 Jun 2002 13:32:08 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07387 for ; Fri, 14 Jun 2002 13:31:31 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5EHVbT25433 for ; Fri, 14 Jun 2002 12:31:37 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 12:31:32 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703F9@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 12:31:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Good morning all, The proposition that Juha put forward to which I responded in my last mail - that a service provider will bill me at a lesser rate if I select a favorable area code in my calling party number - is absurd: the service provider knows who you are, knows the area codes you can claim in your calling party number, and it seems unlikely that they are granting this flexibility so that you can elect to pay them less money. The milder proposition that Juha subsequently put forward - that a user will select between multiple identities for some unspecified reason, maybe something like charge number (see below) - is essentially what 3GPP is doing, as Keith and others have pointed out. I hope that all these people eagerly leaping to Juha's defense intend to champion the former proposition, the one that was actually attacked, not the latter proposition. If you argue from absurdities, I think you should expect that people on this mailing list with either ignore you or tell you to stop. I don't think it really matters what you are arguing for. I'm not trying to shut down rational discussion about this matter - but I also think we shouldn't waste our time when discussion is clearly in the twilight zone. Also, I'd ask people to remember that Juha put forward these examples in order to argue (as I understand it) for one point: that we need a baseline SIP identity mechanism distinct from any currently available way of expressing identity, and that therefore P-Preferred-Identity should not be a P- header. So let's examine Juha's best proposition to date - the 'charge number' example - in the light of this desired conclusion. We all no doubt agree that you should be able to specify an identity in SIP signaling that indicates the party responsible (in a legal and financial sense) for the call. I think that the authenticated identity, the one that you can cryptographically prove, probably should be the identity to which a call will be billed - you would want a SIP baseline mechanism for ascertaining the responsible party to have cryptographic properties, anyway, so that it can't be trivially spoofed. There is no obvious reason why a charge number should be distinct from the identity I provide when I authenticate - again, you can have multiple charge numbers to choose from, and use the same shared secret for each one of them if you'd like. I would say this though - if I were designing a way in which users could express a 'work' and 'home' charge number, I think it would be desirable to have different credentials for personal identities than for corporate charge numbers. In many architectures and under many policies, companies probably wouldn't like people to be able to charge calls to them on the strength of their personal credentials (which might use weak password schemes, etc). I see this example as further validating the use of SIP authentication is the baseline spec to express this form of identity, not as an argument for the standardization of some other way of expressing identity in baseline SIP (which is of course what this whole argument is about). While we all agree that it would be nice to have a charge-number, it isn't at all clear that we need to add new headers to baseline SIP in order to get one. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Tom_Gray@Mitel.COM [mailto:Tom_Gray@Mitel.COM] > Sent: Friday, June 14, 2002 7:58 AM > To: Peterson, Jon > Cc: 'jh@lohi.eng.song.fi'; sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > > > > > >So, you're honestly trying to tell me that users will save on long-distance > >charges depending on how they hint at their calling party number? Do you > >actually work for a telephone company? > > Personal and work accounts perhaps. The caller may not be the one paying > for the call. He may be working for others who have negotiated their own > arrangements. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 14:07:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08436 for ; Fri, 14 Jun 2002 14:07:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27957 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 14:08:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26750; Fri, 14 Jun 2002 13:45:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26724 for ; Fri, 14 Jun 2002 13:45:27 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07806 for ; Fri, 14 Jun 2002 13:44:51 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5EHiCB05274; Fri, 14 Jun 2002 13:44:13 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 12:44:07 -0500 Message-ID: <70565611B164D511957A001083FCDD56018703FA@va02.va.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" , "'Mark Watson'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 12:44:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C213CB.14E0F090" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C213CB.14E0F090 Content-Type: text/plain; charset="iso-8859-1" Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere. When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header. Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect. I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread. Jon Peterson NeuStar, Inc. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, June 14, 2002 8:39 AM To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Mark suggested: > If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . . but it does seem cleaner to use a preferred-identity indicator. -- Dean ------_=_NextPart_001_01C213CB.14E0F090 Content-Type: text/html; charset="iso-8859-1" Message
Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere.
 
When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header.
 
Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect.
 
I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Friday, June 14, 2002 8:39 AM
To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Mark suggested: 
> If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. 
 
Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . .
 
but it does seem cleaner to use a preferred-identity indicator.
 
--
Dean
 

 
 
 
 
 
 
------_=_NextPart_001_01C213CB.14E0F090-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 15:53:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13544 for ; Fri, 14 Jun 2002 15:53:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02400 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 15:53:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01393; Fri, 14 Jun 2002 15:20:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01362 for ; Fri, 14 Jun 2002 15:20:46 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11860 for ; Fri, 14 Jun 2002 15:20:08 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5EJLAi04138 for ; Fri, 14 Jun 2002 22:21:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Jun 2002 22:20:42 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 22:20:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 22:20:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C213D8.92993D50" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Fri, 14 Jun 2002 22:20:41 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20333@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] draft-ietf-sip-asserted-identity-01 Thread-Index: AcITzJqC1PxED6KPTPeCyPeNmuqPsAAChMvg To: , , Cc: X-OriginalArrivalTime: 14 Jun 2002 19:20:42.0403 (UTC) FILETIME=[933EDF30:01C213D8] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C213D8.92993D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This has nothing to do with the 'hinted' identity. =20 If you want to make a personal call, you provide credentials (user-name = and paw rod) for your personal account. If you want to make a business = call, you provide credentials for your business account, from the same = phone. =20 If you want to make another personal call, use the cached personal = account nonce. If you want to make another business call, use the cached = business account nonce =20 If you have 15 different numbers, you can use one of them as the = username. =20 If you want to use another number, because that number makes your phone = bill smaller, then you need to authenticate yourself to use that number. = Password for all the 15 numbers can be the same. =20 The argument is: Do I have to authenticate myself every time I want to = use a different number out of the 15? and the answer is YES. =20 But, as Jon suggests, the operator knows better how to charge you based = on your location. I would extend that by saying you only need one number = anyhow. =20 Regards, Hisham -----Original Message----- From: ext Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, June 14, 2002 7:40 PM To: jh@lohi.eng.song.fi; jon.peterson@neustar.biz Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 In a message dated 6/14/02 1:54:09 AM Eastern Daylight Time, = jh@lohi.eng.song.fi writes:=20 another application is a user having two telephone numbers, one for=20 private and another for company use. when he makes a call, he chooses=20 which "line" to use so that the right calling party number will get=20 charged. there is still only one username/password. =20 Absolutely correct and a valid application. In my house, served by a = real telephone company, we have two telephone lines, each with a = different number and each with a different billing plan for local and = long distance service. Depending on which phone I pick up and dial, I = get different rates.=20 If this were supported with SIP, I can certainly see the possibility = that I would have a single device (the computer I'm looking at?) and I = need to specify which identity I want to use to originate a call, which = may affect the rate I pay and the way the call is handled and the = identity that gets delivered (or not) to the other end and whether or = not I get a priority service, etc. =20 Incidentally, IMO, watching comments flung back and forth for months, = Juha appears to have a good understanding of what an "operator" needs, = unlike some others who have been commenting on the subject.=20 Mike Pierce=20 Artel (sitting at home)=20 ------_=_NextPart_001_01C213D8.92993D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This=20 has nothing to do with the 'hinted' identity.
 
If you=20 want to make a personal call, you provide credentials (user-name and paw = rod)=20 for your personal account. If you want to make a business call, you = provide=20 credentials for your business account, from the same = phone.
 
If you=20 want to make another personal call, use the cached personal account = nonce.=20 If you want to make another business call, use the cached business = account=20 nonce
 
If you=20 have 15 different numbers, you can use one of them as the=20 username.
 
If you=20 want to use another number, because that number makes your phone bill = smaller,=20 then you need to authenticate yourself to use that number. Password for = all the=20 15 numbers can be the same.
 
The=20 argument is: Do I have to authenticate myself every time I want to use a = different number out of the 15? and the answer is = YES.
 
But,=20 as Jon suggests, the operator knows better how to charge you based on = your=20 location. I would extend that by saying you only need one number=20 anyhow.
 
Regards,
Hisham
-----Original Message-----
From: ext = Mpierce1@aol.com=20 [mailto:Mpierce1@aol.com]
Sent: Friday, June 14, 2002 7:40=20 PM
To: jh@lohi.eng.song.fi; = jon.peterson@neustar.biz
Cc:=20 sip@ietf.org
Subject: Re: [Sip]=20 draft-ietf-sip-asserted-identity-01

In a message dated 6/14/02 1:54:09 AM Eastern Daylight = Time,=20 jh@lohi.eng.song.fi writes:


another application is a user having = two=20 telephone numbers, one for
private and another for company use.=20  when he makes a call, he chooses
which "line" to use so = that the=20 right calling party number will get
charged.  there is = still only=20 one username/password.  



Absolutely correct and a valid application. In = my house,=20 served by a real telephone company, we have two telephone lines, each = with a=20 different number and each with a different billing plan for local and = long=20 distance service. Depending on which phone I pick up and dial, I get = different=20 rates.

If this were supported with SIP, I can certainly see = the=20 possibility that I would have a single device (the computer I'm = looking at?)=20 and I need to specify which identity I want to use to originate a = call, which=20 may affect the rate I pay and the way the call is handled and the = identity=20 that gets delivered (or not) to the other end and whether or not I get = a=20 priority service, etc.   

Incidentally, IMO, = watching=20 comments flung back and forth for months, Juha appears to have a good=20 understanding of what an "operator" needs, unlike some others who have = been=20 commenting on the subject.

Mike Pierce
Artel (sitting at = home)=20
------_=_NextPart_001_01C213D8.92993D50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 17:35:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16134 for ; Fri, 14 Jun 2002 17:35:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08521 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 17:36:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06728; Fri, 14 Jun 2002 17:08:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06700 for ; Fri, 14 Jun 2002 17:08:20 -0400 (EDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15285 for ; Fri, 14 Jun 2002 17:07:42 -0400 (EDT) From: ysong@telcordia.com Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA18547 for ; Fri, 14 Jun 2002 17:04:42 -0400 (EDT) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 14 Jun 2002 17:05:06 -0400 X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at 06/14/2002 05:05:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] "Interoperative SIP interface"? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Does anyone know what is meant by the term, "Interoperative SIP interface"? Thanks for your help. YoungSun _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 18:26:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18079 for ; Fri, 14 Jun 2002 18:26:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11714 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 18:26:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09318; Fri, 14 Jun 2002 17:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09286 for ; Fri, 14 Jun 2002 17:53:25 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16652 for ; Fri, 14 Jun 2002 17:52:45 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5ELrGRb023892; Fri, 14 Jun 2002 23:53:16 +0200 (MEST) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5ELrFa9028391; Sat, 15 Jun 2002 00:53:15 +0300 (EET DST) Message-ID: <3D0A65E4.F7BAFBC9@lmf.ericsson.se> Date: Sat, 15 Jun 2002 00:53:41 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm also curious about 183. Both bis-9 and the ISUP/SIP mapping draft mention only 180 for generating ringback tones - local or remote. The issue here, I guess, is that we don't distinguish between remote ringback and whatever early media - for which I guess(?) 183 CAN be used. And, what about if there are SDPs in other 18x responses? Regards, Christer Holmberg Ericsson Finland Flemming Andreasen wrote: > I've been struggling with this too - it would be nice with an update to > the unify draft (or something else) that explains how everything works > between bis, manyfolks, update, and offer/answer. > > Mark Watson wrote: > > > > > > > Christer, > > > > As I understand it, the current situation is as follows: > > > > From the point of view of the UAC (assuming an SDP offer in the INVITE > > for simplicity), then if > > (i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > > 183, 180 , UPDATE, 200 OK to UPDATE etc.), and > > (ii) a=sendrecv or a=sendonly in this answer, and > > (iii) any manyfolks pre-conditions have been met (i.e. this could be > > an answer at the end of several offer/answer exchanges negotiating and > > updating preconditions) > > > > then there is Early Media, and the UAC SHOULD (?) play this to the > > caller. > > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > My understanding was, that if you get a 180, then you will generate > local ringback until you receive RTP (or whatever else you may have > negotiated in your media stream(s)), whereas with 183, you do not > generate local ringback. > > As an aside, I personally worry about the robustness of this coupling > between signaling and presence of a single RTP packet. > > > > > If there is no Early Media, or if the Early Media is on hold (SDP > > answer contains a=recvonly or a=inactive) AND a 180 has been received, > > then the UAC SHOULD (?) play local ringing. > > > > So, if the UAS does not want to generate Early Media then it has the > > following choices: > > (a) do not supply SDP answer until actual call Answer, or > > (b) supply early SDP answer with a=recvonly or a=inactive > > > > Again, I thought there was a distinction between 180 and 183 here ? > > > > > Now, (b) is not much use to a UAS trying to negotiate media with > > pre-conditions, since the direction attribute in this exchange will > > affect the resources that are reserved, and therefore needs to reflect > > the requirements of the eventual session. > > I don't think that's necessary, since manyfolks has its own direction > attributes independent of the media stream direction attributes. Thus > you could specify an inactive stream and require sendrevc reservation > for it. What is not clear however, is how a UAC can negotiate > bidirectional codec support without accepting early media in both > directions. > > > > > Therefore it would need to place the media on hold *after* the > > pre-conditions have been met, using an UPDATE. > > > > A workaround at the UAC for dealing with a UAS which did not do this > > is that, even if the offer/answer has been completed with a=sendrecv > > the UAC pays attention to whether any RTP packets are actually being > > received - if there are none, then it generates local ringing. > > > > Unfortunately, such a workaround is not really applicable to one class > > of UACs for whom local ringing is quite important, namely distributed > > PSTN to SIP gateways (consisting of Media Gateways and a Media Gateway > > Controller as per Megaco model). This is because the information about > > presence/absence of actual RTP packets is only available at the media > > layer (MG) which does not make decisions for itself about issues such > > as tones/announcements/inband ringing. > > That can be addressed pretty easily by defining the proper event(s). The > question is how robust this whole sceheme is in the first place though. > > > > > So, I can only hope that all UAS developers implementing Manyfolks are > > aware of the need to put the media on hold as soon as the > > pre-conditions have been met (unless thay are going to generate real > > Eraly Media). > > > > A solution to this would be a way of explicitly indicating at the > > SIP/SDP layer that a media stream, although not on hold, was > > 'provisional', or did not contain actual media yet. I did not think > > the Content-Disposition in Manyfolks has formally been given this > > meaning. If it has, I'm not sure what 'undoes' this 'provisional' > > status - it shouldn't be the 200 OK to the INVITE because the whole > > point of UPDATE was to separate media changes from session changes - > > so it would have to be another offer/answer without the special > > Content-Disposition. But then are people aware they need to do this at > > Answer time ? > > > > We used to have a Content-Dispostion of "precondition" in manyfolks to > make a distinction here, but it got removed for some reason. > > -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 14 19:04:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18926 for ; Fri, 14 Jun 2002 19:04:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13762 for sip-archive@odin.ietf.org; Fri, 14 Jun 2002 19:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12857; Fri, 14 Jun 2002 18:43:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12830 for ; Fri, 14 Jun 2002 18:43:14 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18561 for ; Fri, 14 Jun 2002 18:42:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5EMgWYs007911; Fri, 14 Jun 2002 18:42:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:42:35 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Christer Holmberg'" , Flemming Andreasen Cc: Mark Watson , sip@ietf.org Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Fri, 14 Jun 2002 18:42:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org No. No, no, no, no, no. If you know there is user alerting going on, use 180. Sending 183 and playing in-band ringback is not a generally acceptable solution; you're overriding the calling party's user interface's rendering of "remote party is being alerted." Their client may very well not render this using audio at all. Think of the interactions between abusing 183 this way and, say, a deaf user. /a > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, June 14, 2002 16:54 > To: Flemming Andreasen > Cc: Mark Watson; sip@ietf.org > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > > Hi, > > I'm also curious about 183. Both bis-9 and the ISUP/SIP mapping draft > mention only 180 for generating ringback tones - local or > remote. The issue > here, I guess, is that we don't distinguish between remote > ringback and > whatever early media - for which I guess(?) 183 CAN be used. > > And, what about if there are SDPs in other 18x responses? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Flemming Andreasen wrote: > > > I've been struggling with this too - it would be nice with > an update to > > the unify draft (or something else) that explains how > everything works > > between bis, manyfolks, update, and offer/answer. > > > > Mark Watson wrote: > > > > > > > > > > > Christer, > > > > > > As I understand it, the current situation is as follows: > > > > > > From the point of view of the UAC (assuming an SDP offer > in the INVITE > > > for simplicity), then if > > > (i) an SDP answer is received before the 200 OK of the > INVITE (e.g. in > > > 183, 180 , UPDATE, 200 OK to UPDATE etc.), and > > > (ii) a=sendrecv or a=sendonly in this answer, and > > > (iii) any manyfolks pre-conditions have been met (i.e. > this could be > > > an answer at the end of several offer/answer exchanges > negotiating and > > > updating preconditions) > > > > > > then there is Early Media, and the UAC SHOULD (?) play this to the > > > caller. > > > > > > > Will this be the case irrespective of whether you got a 180 > or a 183 ? > > My understanding was, that if you get a 180, then you will generate > > local ringback until you receive RTP (or whatever else you may have > > negotiated in your media stream(s)), whereas with 183, you do not > > generate local ringback. > > > > As an aside, I personally worry about the robustness of > this coupling > > between signaling and presence of a single RTP packet. > > > > > > > > If there is no Early Media, or if the Early Media is on hold (SDP > > > answer contains a=recvonly or a=inactive) AND a 180 has > been received, > > > then the UAC SHOULD (?) play local ringing. > > > > > > So, if the UAS does not want to generate Early Media then > it has the > > > following choices: > > > (a) do not supply SDP answer until actual call Answer, or > > > (b) supply early SDP answer with a=recvonly or a=inactive > > > > > > > Again, I thought there was a distinction between 180 and 183 here ? > > > > > > > > Now, (b) is not much use to a UAS trying to negotiate media with > > > pre-conditions, since the direction attribute in this > exchange will > > > affect the resources that are reserved, and therefore > needs to reflect > > > the requirements of the eventual session. > > > > I don't think that's necessary, since manyfolks has its own > direction > > attributes independent of the media stream direction > attributes. Thus > > you could specify an inactive stream and require sendrevc > reservation > > for it. What is not clear however, is how a UAC can negotiate > > bidirectional codec support without accepting early media in both > > directions. > > > > > > > > Therefore it would need to place the media on hold *after* the > > > pre-conditions have been met, using an UPDATE. > > > > > > A workaround at the UAC for dealing with a UAS which did > not do this > > > is that, even if the offer/answer has been completed with > a=sendrecv > > > the UAC pays attention to whether any RTP packets are > actually being > > > received - if there are none, then it generates local ringing. > > > > > > Unfortunately, such a workaround is not really applicable > to one class > > > of UACs for whom local ringing is quite important, namely > distributed > > > PSTN to SIP gateways (consisting of Media Gateways and a > Media Gateway > > > Controller as per Megaco model). This is because the > information about > > > presence/absence of actual RTP packets is only available > at the media > > > layer (MG) which does not make decisions for itself about > issues such > > > as tones/announcements/inband ringing. > > > > That can be addressed pretty easily by defining the proper > event(s). The > > question is how robust this whole sceheme is in the first > place though. > > > > > > > > So, I can only hope that all UAS developers implementing > Manyfolks are > > > aware of the need to put the media on hold as soon as the > > > pre-conditions have been met (unless thay are going to > generate real > > > Eraly Media). > > > > > > A solution to this would be a way of explicitly indicating at the > > > SIP/SDP layer that a media stream, although not on hold, was > > > 'provisional', or did not contain actual media yet. I did > not think > > > the Content-Disposition in Manyfolks has formally been given this > > > meaning. If it has, I'm not sure what 'undoes' this 'provisional' > > > status - it shouldn't be the 200 OK to the INVITE because > the whole > > > point of UPDATE was to separate media changes from > session changes - > > > so it would have to be another offer/answer without the special > > > Content-Disposition. But then are people aware they need > to do this at > > > Answer time ? > > > > > > > We used to have a Content-Dispostion of "precondition" in > manyfolks to > > make a distinction here, but it got removed for some reason. > > > > -- Flemming > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jun 15 12:48:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11717 for ; Sat, 15 Jun 2002 12:48:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25972 for sip-archive@odin.ietf.org; Sat, 15 Jun 2002 12:48:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24934; Sat, 15 Jun 2002 12:20:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24904 for ; Sat, 15 Jun 2002 12:20:44 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11154 for ; Sat, 15 Jun 2002 12:20:06 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5FGK4u04163; Sat, 15 Jun 2002 18:20:05 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5FGK2G06961; Sat, 15 Jun 2002 17:20:02 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 17:20:03 +0100 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'Dean Willis'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Sat, 15 Jun 2002 17:20:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21488.7F8371C6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21488.7F8371C6 Content-Type: text/plain; charset="iso-8859-1" Ok, so I am not particularly bothered about Preferred Identity being a P-header. But I think it is fair to argue the point that if several users of SIP have found the need to 'diverge' from the standard SIP architecture in this respect, then perhaps it is worth considering enhancement of the standard architecture. There is an assumption in SIP that a given user (from an authentication point of view) has only a single identity/service profile etc. We are just talking about relaxing that assumption. In the case of 3GPP, then the requirement arises from the desire to re-use the SIM-card based authentication mechanism which has already been scaled to .5 billion users or whatever. I think this makes this mechanism just a little more successful than any other authentication scheme of equivalent security that I know of. This in my view is a reasonable case for re-use, even if a slight divergence from the SIP architecture is involved. The properties of this mechanism, and the functional split between the home SIP proxy and the repository of the shared secret make it difficult to use the cached nonce approach. Finally, the reliance on IPSEC for the first hop to avoid re-authentication on subsequent messages is not exactly 'outside the internet model'. ...Mark -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 14 June 2002 18:44 To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere. When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header. Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect. I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread. Jon Peterson NeuStar, Inc. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, June 14, 2002 8:39 AM To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Mark suggested: > If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . . but it does seem cleaner to use a preferred-identity indicator. -- Dean ------_=_NextPart_001_01C21488.7F8371C6 Content-Type: text/html; charset="iso-8859-1" Message
Ok, so I am not particularly bothered about Preferred Identity being a P-header. But I think it is fair to argue the point that if several users of SIP have found the need to 'diverge' from the standard SIP architecture in this respect, then perhaps it is worth considering enhancement of the standard architecture. There is an assumption in SIP that a given user (from an authentication point of view) has only a single identity/service profile etc. We are just talking about relaxing that assumption.
 
In the case of 3GPP, then the requirement arises from the desire to re-use the SIM-card based authentication mechanism which has already been scaled to .5 billion users or whatever. I think this makes this mechanism just a little more successful than any other authentication scheme of equivalent security that I know of. This in my view is a reasonable case for re-use, even if a slight divergence from the SIP architecture is involved.
 
The properties of this mechanism, and the functional split between the home SIP proxy and the repository of the shared secret make it difficult to use the cached nonce approach.
 
Finally, the reliance on IPSEC for the first hop to avoid re-authentication on subsequent messages is not exactly 'outside the internet model'.
 
...Mark
-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: 14 June 2002 18:44
To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere.
 
When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header.
 
Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect.
 
I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Friday, June 14, 2002 8:39 AM
To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Mark suggested: 
> If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. 
 
Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . .
 
but it does seem cleaner to use a preferred-identity indicator.
 
--
Dean
 

 
 
 
 
 
 
------_=_NextPart_001_01C21488.7F8371C6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 02:08:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22576 for ; Mon, 17 Jun 2002 02:08:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23678 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 02:09:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22721; Mon, 17 Jun 2002 01:41:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22690 for ; Mon, 17 Jun 2002 01:41:45 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13816 for ; Mon, 17 Jun 2002 01:41:06 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5H5equF022344; Sun, 16 Jun 2002 22:40:52 -0700 (PDT) Received: from open-131-161-248-85.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAG87738; Sun, 16 Jun 2002 22:41:10 -0700 (PDT) Date: Sun, 16 Jun 2002 22:41:16 -0700 Subject: Re: [Sip] draft-ietf-sip-asserted-identity-01 Content-Type: multipart/alternative; boundary=Apple-Mail-1-888120245 Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Peterson, Jon'" , "'Dean Willis'" , jh@lohi.eng.song.fi, sip@ietf.org To: "Mark Watson" From: Rohan Mahy In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.482) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --Apple-Mail-1-888120245 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Saturday, June 15, 2002, at 09:20 AM, Mark Watson wrote: > Ok, so I am not particularly bothered about Preferred Identity being a=20= > P-header. But I think it is fair to argue the point that if several=20 > users of SIP have found the need to 'diverge' from the standard SIP=20 > architecture in this respect, then perhaps it is worth considering=20 > enhancement of the standard architecture. There is an assumption in = SIP=20 > that a given user (from an authentication point of view) has only a=20 > single identity/service profile etc. We are just talking about = relaxing=20 > that assumption. > =A0 > In the case of 3GPP, then the requirement arises from the desire to=20 > re-use the SIM-card based authentication mechanism which has already=20= > been scaled to .5 billion users or whatever. I think this makes this=20= > mechanism just a little more successful than any other authentication=20= > scheme of equivalent security that I know of. This in my view is a=20 > reasonable case for re-use, even if a slight divergence from the SIP=20= > architecture is involved. Sure you want to reuse the SIM card as an authentication mechanism, but=20= when you map this authentication onto SIP Digest authentication, there=20= is no reason the SIMs private ID has to be 1:1. Why can't it correspond=20= to multiple digest usernames? For example, say my private ID is=20 12345678, i could set the username to 12345678 to login and use the=20 default "account", and use username 12345678.personal or 12345678.1 for=20= my personal identity/account, and 12345678.2 or 12345678.work for my=20 work identity/account. So, I don't think anyone has provided a technical reason my such a=20 mechanism couldn't work, just that a separate header is more natural or=20= elegant or better in some philosophical way which is hard to measure. =20= There is a baseline mechanism available to solve this problem. Several=20= folks want a separate header anyway. Since the benefits of a separate=20= header are impossible to quantify at the moment, we can use a P-header=20= in its "provisional" sense of the word to get some operational=20 experience. Six-months or a year from now we may discover that this=20 mechanism really should be a general purpose header, or we may discover=20= that the "unnatural" mechanism works just fine and really isn't so=20 unnatural after all. Also, I'd like to observe that the reason we are probably having trouble=20= coming to consensus, is that we have no common set of requirements. =20 Therefore I'd like to invite you all to quit bickering about this and=20 write one or more requirements drafts before draft cutoff on Friday. =20 Like all requirements drafts, these should get submitted with a=20 draft-lastname-sipping prefix and discussed on the SIPPING list. =20 Otherwise I expect this thread will continue to go nowhere. thanks, -rohan > The properties of this mechanism, and the functional split between the=20= > home SIP proxy and the repository of the shared secret make it=20 > difficult to use the cached nonce approach. > =A0 > Finally, the reliance on IPSEC for the first hop to avoid=20 > re-authentication on subsequent messages is not exactly 'outside the=20= > internet model'. > =A0 > ...Mark > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 14 June 2002 18:44 > To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > Well, this begins to speak to the matters that in my mind actually=20 > motivated the P-Preferred-Identity header - namely, the fact that=20 > PacketCable-derived networks did not want to use the baseline SIP=20 > authentication mechanisms. If per-request authentication (which, as=20 > Dean correctly points out, can use cached nonces to avoid the extra=20 > RTTs) is infeasible for some reason, you may need a alternate way to=20= > express the identity that would ordinarily be presented by the SIP=20 > authentication system. I have always viewed P-Preferrred-Identity as = an=20 > authentication header with no cryptographic properties - something = like=20 > an unsolicited Proxy-Authorization with no hash=A0- since the=20 > cryptographic properties are being staged elsewhere. > =A0 > When you start to turn your back on the baseline SIP mechanisms, and=20= > instead rely on mechanisms outside the Internet model=A0(yes, loaded=20= > term) for security and authentication, you have entered into the realm=20= > of P- headers. Ultimately, that is what this thread is about - whether=20= > or not P-Preferred-Identity should be a P- header. > =A0 > Maybe this is really the crux of the matter - if your architecture=20 > diverges enough from the SIP model that you can't get access to SIP=20 > authentication as a way of expressing your identity to the network,=20 > then clearly your architecture is not 'baseline', and any argument = that=20 > we need some baseline SIP mechanism (as opposed to a P- header) to=20 > express identity in your architecture is going to seem a little = suspect. > =A0 > I agree, anyway, that inquiries along these lines are more likely to=20= > provide profitable new arguments for doing this one way or another = than=20 > some of=A0the other branches in this thread. > =A0 > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, June 14, 2002 8:39 AM > To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > Mark suggested:=A0 > >=A0If I allow subsequent sessions on the same connection, then this=20= > 'hint' becomes useful. Performing Digest authentication again every=20 > time (requiring an additional RTT) seems a heavy price just to=20 > communicate a few extra octets.=A0 > =A0 > Er, you COULD just include the appropriate credentials using the = cached=20 > nonce on future requests, and not bother to actually rechallenge . . . > =A0 > but it does seem cleaner to use a preferred-identity indicator. > =A0 > -- > Dean > =A0 > > =A0 > =A0 > =A0 > =A0 > =A0 > =A0 > --Apple-Mail-1-888120245 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Saturday, June 15, 2002, at 09:20 AM, Mark Watson wrote: = Verdana0000,0000,FFFFOk, so I am not particularly bothered about Preferred Identity being a P-header. But I think it is fair to argue the point that if several users of SIP have found the need to 'diverge' from the standard SIP architecture in this respect, then perhaps it is worth considering enhancement of the standard architecture. There is an assumption in SIP that a given user (from an authentication point of view) has only a single identity/service profile etc. We are just talking about relaxing that assumption. =A0 = Verdana0000,0000,FFFFIn the case of 3GPP, then the requirement arises from the desire to re-use the SIM-card based authentication mechanism which has already been scaled to .5 billion users or whatever. I think this makes this mechanism just a little more successful than any other authentication scheme of equivalent security that I know of. This in my view is a reasonable case for re-use, even if a slight divergence from the SIP architecture is involved. Sure you want to reuse the SIM card as an authentication mechanism, but when you map this authentication onto SIP Digest authentication, there is no reason the SIMs private ID has to be 1:1. Why can't it correspond to multiple digest usernames? For example, say my private ID is 12345678, i could set the username to 12345678 to login and use the default "account", and use username 12345678.personal or 12345678.1 for my personal identity/account, and 12345678.2 or 12345678.work for my work identity/account.=20 So, I don't think anyone has provided a technical reason my such a mechanism couldn't work, just that a separate header is more natural or elegant or better in some philosophical way which is hard to measure. There is a baseline mechanism available to solve this problem. Several folks want a separate header anyway. Since the benefits of a separate header are impossible to quantify at the moment, we can use a P-header in its "provisional" sense of the word to get some operational experience. Six-months or a year from now we may discover that this mechanism really should be a general purpose header, or we may discover that the "unnatural" mechanism works just fine and really isn't so unnatural after all. Also, I'd like to observe that the reason we are probably having trouble coming to consensus, is that we have no common set of requirements. Therefore I'd like to invite you all to quit bickering about this and write one or more requirements drafts before draft cutoff on Friday. Like all requirements drafts, these should get submitted with a draft-lastname-sipping prefix and discussed on the SIPPING list. Otherwise I expect this thread will continue to go nowhere. thanks, -rohan = Verdana0000,0000,FFFFThe properties of this mechanism, and the functional split between the home SIP proxy and the repository of the shared secret make it difficult to use the cached nonce = approach. =A0 = Verdana0000,0000,FFFFFinally, the reliance on IPSEC for the first hop to avoid re-authentication on subsequent messages is not exactly 'outside the internet = model'. =A0 = Verdana0000,0000,FFFF...Mark -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 14 June 2002 18:44 To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 = Arial0000,0000,FFFFWell, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash=A0- since the cryptographic properties are being staged = elsewhere. =A0 = Arial0000,0000,FFFFWhen you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model=A0(yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- = header. =A0 = Arial0000,0000,FFFFMaybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect. =A0 = Arial0000,0000,FFFFI agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of=A0the other branches in this = thread. =A0 = Arial0000,0000,FFFFJon Peterson = Arial0000,0000,FFFFNeuStar, Inc. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, June 14, 2002 8:39 AM To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Arial0000,0000,FFFFMark suggested:=A0 >=A0If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra = octets.Arial0000,0000,FFFF=A0 =A0 = Arial0000,0000,FFFFEr, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . = . =A0 = Arial0000,0000,FFFFbut it does seem cleaner to use a preferred-identity = indicator. =A0 = Arial0000,0000,FFFF-- = Arial0000,0000,FFFFDean =A0 =A0 =A0 =A0 =A0 =A0 =A0 = --Apple-Mail-1-888120245-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 03:28:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23703 for ; Mon, 17 Jun 2002 03:28:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26959 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 03:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26114; Mon, 17 Jun 2002 03:04:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26062 for ; Mon, 17 Jun 2002 03:04:16 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23376 for ; Mon, 17 Jun 2002 03:03:36 -0400 (EDT) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5H75pW28899 for ; Mon, 17 Jun 2002 10:05:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 17 Jun 2002 10:04:05 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 17 Jun 2002 10:04:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Date: Mon, 17 Jun 2002 10:04:04 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE312@esebe013.NOE.Nokia.com> Thread-Topic: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Thread-Index: AcISyXqOH1Wxe6JqQ0SQnehMGuXbEQDAvdPQ To: Cc: X-OriginalArrivalTime: 17 Jun 2002 07:04:15.0232 (UTC) FILETIME=[30E0E800:01C215CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA26063 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, This was considered at one point along with defining a new HTTP authentication method for AKA. The reason digest-aka is reusing the nonce param is that, the AKA material is then also included in the calculation of the credentials. Basically, digest-aka specifies one particular server implementation of the nonce (plus server specific data can still be appended to the AKA parameters inside the nonce). Cheers, Aki > -----Original Message----- > From: ext Dror@vocaltec.com [mailto:Dror@vocaltec.com] > Sent: Thursday, June 13, 2002 2:54 PM > To: Niemi Aki (NET/Espoo) > Cc: sip@ietf.org > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Digest-aka does change the definition of the "nonce" field. A > "nonce" is > an opaque value from the client's perspecfive, and it is completely > server-implementation-specific. > however, "aka-nonce" is a set of specific fields. Why not > define those > fields explicitly? > e.g. rand=, autn= > (the server-specific data IS the original intent of the > "nonce" field...) > > --Original Message > > > > To: ; > From: aki.niemi@nokia.com > > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > Hi Rob, > > Digest-aka doesn't replace the algorithm and nonce > definitions of bis-09, > but extends them. More specifically, the draft talks about > overloading of > the algorithm definition by adding an AKA prefix to the token > values; and > extending of the nonce which in bis-09 is simply a quoted string. > > Cheers, > Aki > > > > -----Original Message----- > > From: ext Rob Phillips [mailto:rob@netrake.com] > > Sent: Tuesday, June 11, 2002 11:51 PM > > To: sip@ietf.org > > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > > replace the definitions of "algorithm" and "nonce" that are > > already defined in bis-09? Or merely to extend the definitions? > > > > - rob > > > > -- > > Rob Phillips, Sr. Software Engineer Netrake > > Corporation > > mailto: rob@netrake.com 3000 > > Technology Drive > > voice: (214) 291-1096 > > Suite 100 > > fax: (214) 291-1010 http://www.netrake.com Plano, > > Texas 75074 > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 > > Mailing-List: Session Initiation Protocol > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 08:48:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29338 for ; Mon, 17 Jun 2002 08:48:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA11598 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 08:49:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09519; Mon, 17 Jun 2002 08:11:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09494 for ; Mon, 17 Jun 2002 08:11:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27987 for ; Mon, 17 Jun 2002 08:11:16 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5HCBFPI009207; Mon, 17 Jun 2002 05:11:15 -0700 (PDT) Received: from cisco.com (sj-dial-4-124.cisco.com [10.19.235.252]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA26215; Mon, 17 Jun 2002 05:11:02 -0700 (PDT) Message-ID: <3D0D1488.7F8CBB0A@cisco.com> Date: Sun, 16 Jun 2002 18:43:20 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Christer Holmberg'" , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach wrote: > No. > > No, no, no, no, no. > > If you know there is user alerting going on, use 180. > > Sending 183 and playing in-band ringback is not a > generally acceptable solution; you're overriding > the calling party's user interface's rendering of > "remote party is being alerted." Their client may > very well not render this using audio at all. Could you point me to where in SIP this is stated ? Also, how come the unify draft (in Figure 10) contains an example that explicitly uses 183 for inband ringback ? The call-flows draft shows this as well. > > Think of the interactions between abusing 183 this > way and, say, a deaf user. > I would assume that most deaf users would be using a relay or transcoding service of some kind (e.g TDD) rather than having a plain old audio telephone conversation, and hence I'm not sure it makes much difference in that case. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 08:51:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29485 for ; Mon, 17 Jun 2002 08:51:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA11686 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 08:51:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10039; Mon, 17 Jun 2002 08:24:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10014 for ; Mon, 17 Jun 2002 08:24:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28426 for ; Mon, 17 Jun 2002 08:23:55 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5HCONrU014945; Mon, 17 Jun 2002 14:24:23 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5HCONa9000436; Mon, 17 Jun 2002 15:24:23 +0300 (EET DST) Message-ID: <3D0DD4F7.35749C57@lmf.ericsson.se> Date: Mon, 17 Jun 2002 15:24:24 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Adam Roach , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> <3D0D1488.7F8CBB0A@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Assume that the UAC receives an 183, including an SDP, and the UAS may start sending early media (eg an announcement). After that the UAC receives 180 from the same UAS, WITHOUT SDP. Now, according to the spec the UAC should generate a local ringback tone. However, in this case the UAC would stop forwarding the early media because it received a 180 without an SDP (it did not receive an SDP with "inactive" mode). Regards, Christer Holmberg Ericsson Finland Flemming Andreasen wrote: > Adam Roach wrote: > > > No. > > > > No, no, no, no, no. > > > > If you know there is user alerting going on, use 180. > > > > Sending 183 and playing in-band ringback is not a > > generally acceptable solution; you're overriding > > the calling party's user interface's rendering of > > "remote party is being alerted." Their client may > > very well not render this using audio at all. > > Could you point me to where in SIP this is stated ? Also, how come the unify > draft (in Figure 10) contains an example that explicitly uses 183 for inband > ringback ? The call-flows draft shows this as well. > > > > > Think of the interactions between abusing 183 this > > way and, say, a deaf user. > > > > I would assume that most deaf users would be using a relay or transcoding > service of some kind (e.g TDD) rather than having a plain old audio > telephone conversation, and hence I'm not sure it makes much difference in > that case. > > -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 09:20:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01310 for ; Mon, 17 Jun 2002 09:20:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13702 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 09:20:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12807; Mon, 17 Jun 2002 09:02:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12776 for ; Mon, 17 Jun 2002 09:02:37 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29965 for ; Mon, 17 Jun 2002 09:01:58 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id ADE3994C0138; Mon, 17 Jun 2002 09:02:27 -0400 Message-ID: <003301c215ff$478f1b80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Flemming Andreasen" , "Adam Roach" Cc: "'Christer Holmberg'" , "Mark Watson" , References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> <3D0D1488.7F8CBB0A@cisco.com> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Mon, 17 Jun 2002 09:02:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Line 4560 says "The UA receiving the INVITE is trying to alert the user. The response MAY be used to initiate local ringback". Thus from a call signaling state point of view, the UAC does not consider the caller "alerted" unless it sees a 180. A UAC that renders any sort of visual indication of ringing would not do so with a 183. The spec says the 180 MAY initiate local ringback, not SHOULD. It seems to me that if the UAC receives SDP in either a 183 or 180 and there is RTP flowing, then it should play that RTP to the caller. The caller will hear whatever the UAS is sending. It does not matter that it is ringback or other audio. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Flemming Andreasen" To: "Adam Roach" Cc: "'Christer Holmberg'" ; "Mark Watson" ; Sent: Sunday, June 16, 2002 6:43 PM Subject: Re: [Sip] Local vs Remote ringback on 180 > > > Adam Roach wrote: > > > No. > > > > No, no, no, no, no. > > > > If you know there is user alerting going on, use 180. > > > > Sending 183 and playing in-band ringback is not a > > generally acceptable solution; you're overriding > > the calling party's user interface's rendering of > > "remote party is being alerted." Their client may > > very well not render this using audio at all. > > Could you point me to where in SIP this is stated ? Also, how come the unify > draft (in Figure 10) contains an example that explicitly uses 183 for inband > ringback ? The call-flows draft shows this as well. > > > > > Think of the interactions between abusing 183 this > > way and, say, a deaf user. > > > > I would assume that most deaf users would be using a relay or transcoding > service of some kind (e.g TDD) rather than having a plain old audio > telephone conversation, and hence I'm not sure it makes much difference in > that case. > > -- Flemming > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 09:25:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01616 for ; Mon, 17 Jun 2002 09:25:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13882 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 09:26:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13068; Mon, 17 Jun 2002 09:05:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13040 for ; Mon, 17 Jun 2002 09:05:30 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00138 for ; Mon, 17 Jun 2002 09:04:52 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AE983017A; Mon, 17 Jun 2002 09:05:28 -0400 Message-ID: <003901c215ff$b34ce500$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , "Flemming Andreasen" Cc: "Adam Roach" , "Mark Watson" , References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> <3D0D1488.7F8CBB0A@cisco.com> <3D0DD4F7.35749C57@lmf.ericsson.se> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Mon, 17 Jun 2002 09:05:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg" > > Hi, > > Assume that the UAC receives an 183, including an SDP, and the UAS may start > sending early media (eg an announcement). After that the UAC receives 180 from > the same UAS, WITHOUT SDP. Now, according to the spec the UAC should generate a > local ringback tone. Its say MAY, not SHOULD. > However, in this case the UAC would stop forwarding the > early media because it received a 180 without an SDP (it did not receive an SDP > with "inactive" mode). Why would it do that? If the offer/answer has completed and there is an RTP flow established, it would continue unless there was another SDP offer/answer exchange. The session state (of the RTP) is not tied to call signalling state in this way. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > Flemming Andreasen wrote: > > > Adam Roach wrote: > > > > > No. > > > > > > No, no, no, no, no. > > > > > > If you know there is user alerting going on, use 180. > > > > > > Sending 183 and playing in-band ringback is not a > > > generally acceptable solution; you're overriding > > > the calling party's user interface's rendering of > > > "remote party is being alerted." Their client may > > > very well not render this using audio at all. > > > > Could you point me to where in SIP this is stated ? Also, how come the unify > > draft (in Figure 10) contains an example that explicitly uses 183 for inband > > ringback ? The call-flows draft shows this as well. > > > > > > > > Think of the interactions between abusing 183 this > > > way and, say, a deaf user. > > > > > > > I would assume that most deaf users would be using a relay or transcoding > > service of some kind (e.g TDD) rather than having a plain old audio > > telephone conversation, and hence I'm not sure it makes much difference in > > that case. > > > > -- Flemming > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 10:43:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05960 for ; Mon, 17 Jun 2002 10:43:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19437 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 10:43:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17622; Mon, 17 Jun 2002 10:15:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17586 for ; Mon, 17 Jun 2002 10:15:03 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04329 for ; Mon, 17 Jun 2002 10:14:26 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5HEIrV06320 for ; Mon, 17 Jun 2002 09:18:53 -0500 Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Refer status/adjustment] From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 Jun 2002 09:14:08 -0500 Message-Id: <1024323248.1234.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The message I sent last week (copied below) has generated no list comments. I hope it was because I was too subtle with the subject line. I have asked the IESG to delay their consideration of the REFER draft until these concerns have been discussed on this list. Please read the draft below and comment. If you agree with what's in the draft, please post a note saying so. RjS -----Forwarded Message----- > From: Robert Sparks > To: sip@ietf.org > Subject: [Sip] Refer status/adjustment > Date: 12 Jun 2002 13:49:35 -0500 > > A set of converging concerns were raised about the > REFER draft late in the review process, all centering > on draft's use of sip-events (soon to be RFC3265) and > the implicit subscription. > > When investigating those concerns, several things became > clear. > > The draft did not provide sufficient discussion > around managing the lifecycle of the implicit subscription > (Can you refresh the implicit subscription? unsubscribe? > How is the Subscription-State header supposed to be used? > How do the two parties know when the subscription is over?) > and the draft did not clearly specify some of the things > RFC3265 requires of an event package. These need to be > corrected. > > A larger issue centers around the following language from > sip-events: > > Note that any behavior designated with "SHOULD" or "MUST" in this > document is not allowed to be weakened by extension documents; > however, such documents may elect to strengthen "SHOULD" > requirements to "MUST" strength if required by their application. > > The current draft is not clear enough on one particular point - the > examples do not show immediate NOTIFYs for the implicit subscription. > I expect that many members of the community believe they are not > required (I had drifted into thinking that way before the comments > caused me to look at this more closely). The normative text in the > current REFER draft calls to RFC3265, and immediate NOTIFYs are very > clearly required there. This needs to be pointed out more clearly > in the REFER draft. > > Finally, the current draft makes instantiating a subscription a > SHOULD strength requirement, but provides no mechanism for the > agent sending the REFER to know whether or not to expect a NOTIFY. > We have repeatedly had discussions on the list about how long > the agent sending the REFER should keep state waiting for a NOTIFY - > and with discomfort deciding that is an implementation decision. > Recent discussions have pointed out that there is disagreement about > what never receiving a NOTIFY means - should the REFERing party treat > that as an error and re-attempt the reference or should it just > assume no subscription was created? > > I've put together an individual submission that adds all the > above clarifications. It also proposes a new mechanism to > address the problems in the previous paragraph. Basically, it > provides a way for the party sending the REFER to indicate > that it really wants to be notified, and a way for the agent > accepting the refer to signal that it will or will not send > notifies in the response to the REFER. > > I just submitted this draft - until it appears in the repository, > you can get it from > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt > > I propose that this draft replace refer-05 before it advances further > in the standardization process. > > RjS > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 10:43:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05978 for ; Mon, 17 Jun 2002 10:43:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19451 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 10:43:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17849; Mon, 17 Jun 2002 10:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17815 for ; Mon, 17 Jun 2002 10:19:27 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04423 for ; Mon, 17 Jun 2002 10:18:50 -0400 (EDT) From: Jason.Bach@Level3.Com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.12.3/8.12.3) with ESMTP id g5HEIp4b024036; Mon, 17 Jun 2002 14:18:51 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id OAA16492; Mon, 17 Jun 2002 14:19:12 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 08:19:11 -0600 Message-ID: To: fandreas@cisco.com, adam@dynamicsoft.com Cc: christer.holmberg@lmf.ericsson.se, mwatson@nortelnetworks.com, sip@ietf.org Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Mon, 17 Jun 2002 08:19:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jason Bach wrote: Please be aware that in some service provider enviroments, 183 /w SDP is the prefered method of producing ringing given the fact that the alternative, 180 /wo SDP, makes for a clipping condition when using the 200 OK to iniciate RTP cut through. Regards, -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Sunday, June 16, 2002 4:43 PM To: Adam Roach Cc: 'Christer Holmberg'; Mark Watson; sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 Adam Roach wrote: > No. > > No, no, no, no, no. > > If you know there is user alerting going on, use 180. > > Sending 183 and playing in-band ringback is not a > generally acceptable solution; you're overriding > the calling party's user interface's rendering of > "remote party is being alerted." Their client may > very well not render this using audio at all. Could you point me to where in SIP this is stated ? Also, how come the unify draft (in Figure 10) contains an example that explicitly uses 183 for inband ringback ? The call-flows draft shows this as well. > > Think of the interactions between abusing 183 this > way and, say, a deaf user. > I would assume that most deaf users would be using a relay or transcoding service of some kind (e.g TDD) rather than having a plain old audio telephone conversation, and hence I'm not sure it makes much difference in that case. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 12:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10250 for ; Mon, 17 Jun 2002 12:31:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28300 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 12:32:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26063; Mon, 17 Jun 2002 12:10:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26024 for ; Mon, 17 Jun 2002 12:10:03 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09242 for ; Mon, 17 Jun 2002 12:09:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HG9MoF002840; Mon, 17 Jun 2002 12:09:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:09:26 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1F6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Flemming Andreasen'" , Adam Roach Cc: "'Christer Holmberg'" , Mark Watson , sip@ietf.org Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Mon, 17 Jun 2002 12:09:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > If you know there is user alerting going on, use 180. > > > > Sending 183 and playing in-band ringback is not a > > generally acceptable solution; you're overriding > > the calling party's user interface's rendering of > > "remote party is being alerted." Their client may > > very well not render this using audio at all. > > Could you point me to where in SIP this is stated ? 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. Alerting *is* otherwise classified -- as a 180. Keep in mind that the issue of sending SDP in a provisional response is orthagonal to the response used. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 12:31:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10269 for ; Mon, 17 Jun 2002 12:31:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28314 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 12:32:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26848; Mon, 17 Jun 2002 12:17:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26817 for ; Mon, 17 Jun 2002 12:17:42 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09602 for ; Mon, 17 Jun 2002 12:17:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HGH8oF002919 for ; Mon, 17 Jun 2002 12:17:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:17:12 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1F8@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , sip@ietf.org Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref er status/adjustment] Date: Mon, 17 Jun 2002 12:17:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org For the record, I agree with the proposed changes, and with the proposal to use this discussion draft as the REFER draft from this point forward. /a > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > I have asked the IESG to delay their consideration > of the REFER draft until these concerns have been > discussed on this list. > > Please read the draft below and comment. If you > agree with what's in the draft, please post a > note saying so. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 12:32:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10349 for ; Mon, 17 Jun 2002 12:32:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28456 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 12:33:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26696; Mon, 17 Jun 2002 12:15:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26664 for ; Mon, 17 Jun 2002 12:15:21 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09542 for ; Mon, 17 Jun 2002 12:14:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HGEioF002894; Mon, 17 Jun 2002 12:14:45 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:14:48 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1F7@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'aki.niemi@nokia.com'" , rob@netrake.com, sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt Date: Mon, 17 Jun 2002 12:14:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We've fixed *exactly* these kinds of nits in the Author's 48 hours on pending drafts. You can too. /a > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Thursday, June 13, 2002 3:49 > To: rob@netrake.com; sip@ietf.org > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > Rob, > > I guess you're right, although I think this is implicitly > mentioned in the text although the definitions don't show > it. The problem is also that the document is already in the > RFC Editor's queue, so changes aren't possible at this point. > It would've been really good to get these comments in during > the WG/IETF last calls... > > Cheers, > Aki > > > -----Original Message----- > > From: ext Rob Phillips [mailto:rob@netrake.com] > > Sent: Wednesday, June 12, 2002 3:08 PM > > To: sip@ietf.org > > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > > > > So shouldn't the definitions be: > > > > algorithm = "algorithm" EQUAL (aka-namespace > > / algorithm-value) > > nonce = "nonce" EQUAL (aka-nonce / nonce-value) > > > > in order to be compatable with both bis-09 and sip-digest-aka-03? > > > > - rob > > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Wednesday, June 12, 2002 2:43 AM > > To: Rob Phillips; sip@ietf.org > > Subject: RE: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > > > > Hi Rob, > > > > Digest-aka doesn't replace the algorithm and nonce > > definitions of bis-09, but extends them. More specifically, > > the draft talks about overloading of the algorithm definition > > by adding an AKA prefix to the token values; and extending of > > the nonce which in bis-09 is simply a quoted string. > > > > Cheers, > > Aki > > > > > > > -----Original Message----- > > > From: ext Rob Phillips [mailto:rob@netrake.com] > > > Sent: Tuesday, June 11, 2002 11:51 PM > > > To: sip@ietf.org > > > Subject: [Sip] Question on draft-ietf-sip-digest-aka-03.txt > > > > > > > > > Is it the intention of draft-ietf-sip-digest-aka-03 to > > > replace the definitions of "algorithm" and "nonce" that are > > > already defined in bis-09? Or merely to extend the definitions? > > > > > > - rob > > > > > > -- > > > Rob Phillips, Sr. Software Engineer Netrake > > > Corporation > > > mailto: rob@netrake.com 3000 > > > Technology Drive > > > voice: (214) 291-1096 > > > Suite 100 > > > fax: (214) 291-1010 http://www.netrake.com Plano, > > > Texas 75074 > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 12:54:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11246 for ; Mon, 17 Jun 2002 12:54:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29770 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 12:55:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27373; Mon, 17 Jun 2002 12:24:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27342 for ; Mon, 17 Jun 2002 12:24:13 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09835 for ; Mon, 17 Jun 2002 12:23:34 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HGNZoF002975; Mon, 17 Jun 2002 12:23:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:23:39 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1F9@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'matrix@dasecurenetworks.com'" , jh@lohi.eng.song.fi Cc: Michael Thomas , "Peterson, Jon" , Cullen Jennings , sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Mon, 17 Jun 2002 12:23:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Chris, I think you're missing a major point here: The "long-term" solution isn't incompatible with the PSTN model. It's just *also* applicable to the Internet at large and models with multiple domains involved. The short-term solution is applicable only to an idealized single-domain-of-trust model that doesn't even exist in the PSTN today. /a > -----Original Message----- > From: Chris Martin [mailto:chris@infravast.com] > Sent: Wednesday, June 12, 2002 22:09 > To: jh@lohi.eng.song.fi > Cc: Michael Thomas; Peterson, Jon; Cullen Jennings; sip@ietf.org > Subject: Re: [Sip] Asserted-Identity - new hint proposal > > > jh@lohi.eng.song.fi wrote: > > > > Michael Thomas writes: > > > > > What happened to the mindset of doing the > > > necessary engineering to generalize what the PSTN > > > did badly instead of slavishly reproducing its > > > misfeatures, bug for bug? > > > > this is exactly what 3gpp is doing. they are trying to re-implement > > their existing walled garden with new set of protocols (ip, > sip, radius, > > etc). ietf should have no part in such a madness. > > I cant speak for 3GPP (I dont know enough about it) but walled gardens > exist and will continue to exist, out of necessity, for reasons of > security or lack of resources...yada..yada, within many carrier, > corporate, and SOHO networks. The concepts that I have seen discussed > regarding asserted identity, hints, etc....are valid for any or all of > these infrastructures as well as those that join with one or more > infrastructures to offer enhancements or share resources. > Sure maybe the > names could be worked on but the concepts are valid. > > From what I have seen 3GPP is adopting SIP and, just as the enterprise > and carriers are trying to fit SIP into their infrastructures while > maintaining the policies that they must enforce in order to meet legal > and protective requirements, and I have seen some very good > thoughts and > opinions pour out into this list that will become a necessity > for SIP as > well. I am grateful that the topics have been brought out > into the open > for discussion now than later. > > It is one thing to not desire the re-invention of the PSTN, but > legalities and business policies must be met in the real world by the > entities that will provide the services, whether for profit or not. > These issues exist in the PSTN world but that does not make them > products of the PSTN world. It makes them products of the > communications > world that must be met by all communications solutions that are > developed with the goal of attempting to provide the types of > solutions > that SIP will be capable of providing now and in the future > to everyone. > > To continue to perform nothing more than name calling because "they" > dont conform to your way of thinking is ludicrous. All of these > discussions and attempts to integrate existing architecture (at least > those based on IP for our requirements) furthers the > development of SIP > and aids in the devlopment of new ideas. > > I want to hear and read more about this and offer what I can > when I can, > and hope you will too. > > Chris > > > > > -- juha > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 12:55:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11338 for ; Mon, 17 Jun 2002 12:55:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29869 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 12:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28629; Mon, 17 Jun 2002 12:37:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28601 for ; Mon, 17 Jun 2002 12:37:27 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10439 for ; Mon, 17 Jun 2002 12:36:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5HGapoF003077; Mon, 17 Jun 2002 12:36:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:36:56 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A1FA@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Mpierce1@aol.com'" , mat@cisco.com, jon.peterson@neustar.biz Cc: fluffy@cisco.com, sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Mon, 17 Jun 2002 12:36:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] >I agree that "long term" probably means "never implemented". >Or it means that there is never any short-term attempt to >achieve what is really needed. I have to suspect that one >of the purposes of this focus on "long-term" is to avoid >any useful identification service in the near future. What >is needed is to realize that, unless the means are defined >to provide the currently required identification services, >SIP can not be used to provide a commercial service which >might replace the current (inferior?) telephone system. Actually, the "long-term" solution isn't some fuzzy "oh, we'll do that later; we don't want to think about it" solution. What has been called the "long-term" solution is actively being worked on, and will be done in however much time is necessary to do it right. We're not dragging our feet on this. The only reason the "short-term" solution exists is because 3GPP dumped a pile of requirements on the IETF and said "we need all of these requirements fulfiled by your protocol in a ludicrously short period of time." So, we hemed and hawed a bit, and eventually cranked out a ridiculous mechanism with extremely limited applicablity. So, I think that your confusion arises more from the use of the terms "short-term" and "long-term", not from a good understanding of the situation. A more accurate set of terms which would be less prone to misinterpretation would be "the stopgap solution" and "the real solution". >As a long time participant in the development of the US standards >for identification/privacy, and watching the discussion here, >it occurs to me that there is a fundamental difference between the two approaches: > >PSTN (US standards) - the goal was to provide a useful >identification service, while recognizing the need for privacy > >IETF - the goal is to provide foolproof privacy, while maybe >providing identification in some cases. If you disagree with the *requirements*, I propose that you take the concerns to the SIPPING list, where the document that outlines those requirements is supposed to be discussed. Note well that "the real solution" (to use my coined term) is being described in two drafts -- one for privacy, and the other for identity. Based on your comments above, I suspect that you might have only read the one that addresses privacy. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 13:43:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13366 for ; Mon, 17 Jun 2002 13:43:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02638 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 13:44:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01185; Mon, 17 Jun 2002 13:22:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01156 for ; Mon, 17 Jun 2002 13:22:46 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12259 for ; Mon, 17 Jun 2002 13:22:07 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5HHM5IZ017160; Mon, 17 Jun 2002 10:22:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABW62398; Mon, 17 Jun 2002 10:19:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13710; Mon, 17 Jun 2002 10:22:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15630.6844.8642.403622@thomasm-u1.cisco.com> Date: Mon, 17 Jun 2002 10:22:04 -0700 (PDT) To: Adam Roach Cc: "'Mpierce1@aol.com'" , mat@cisco.com, jon.peterson@neustar.biz, fluffy@cisco.com, sip@ietf.org Subject: RE: [Sip] Asserted-Identity - new hint proposal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A1FA@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F377A1FA@DYN-TX-EXCH-001.dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach writes: > So, I think that your confusion arises more from the use of > the terms "short-term" and "long-term", not from a good understanding > of the situation. A more accurate set of terms which would be > less prone to misinterpretation would be "the stopgap solution" > and "the real solution". Adam, I think there is a real and well founded reason to believe that "stopgap" and "real" have no meaning outside of IETF mailing lists and that only "solution" will be ceased upon. If this *really* is a 3GPP hack as it's being advertised, the best possible solution may be to let 3GPP define some X- headers themselves where IETF gives no blessing of any kind at all. Thus when the "real" header comes out, there won't be any room for equivocation about whether it is an IETF standard. With P- headers, there's plenty of room and it's not clear whatsoever that the "real" header will have any chance of adoption, assuming that it is ever finished -- which is the real problem here. I'm probably in la-la land, but given the amount of effort we're gone to polishing this turd, maybe we could have gotten the "real" solution finished. It's not like there is a lot of new ground here from the last several years... Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 14:56:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16352 for ; Mon, 17 Jun 2002 14:56:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06705 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 14:57:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05584; Mon, 17 Jun 2002 14:33:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05553 for ; Mon, 17 Jun 2002 14:33:40 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15403 for ; Mon, 17 Jun 2002 14:33:02 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5HIWjV26649; Mon, 17 Jun 2002 13:32:45 -0500 From: "Dean Willis" To: "'Adam Roach'" , , , Cc: , Subject: RE: [Sip] Asserted-Identity - new hint proposal Date: Mon, 17 Jun 2002 13:31:55 -0500 Message-ID: <06bc01c2162d$42bf06f0$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A1FA@DYN-TX-EXCH-001.dynamicsoft.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > So, I think that your confusion arises more from the use of > the terms "short-term" and "long-term", not from a good > understanding of the situation. A more accurate set of terms > which would be less prone to misinterpretation would be "the > stopgap solution" and "the real solution". I'd take it a little further and call the two "the 3GPP Release 5 kludge" and "the solution". It's not even completely out of the question to incorporate the real solution into Release 5 via the change request process later this year. Or, as Douglas Adams said, "Don't Panic!" Say, that might be a good definition of P-header -- "panic headers". Or maybe not. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 14:58:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16434 for ; Mon, 17 Jun 2002 14:58:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06755 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 14:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05545; Mon, 17 Jun 2002 14:33:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05516 for ; Mon, 17 Jun 2002 14:33:25 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15398 for ; Mon, 17 Jun 2002 14:32:48 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5HIWkV26652; Mon, 17 Jun 2002 13:32:47 -0500 From: "Dean Willis" To: Cc: "'Robert Sparks'" Date: Mon, 17 Jun 2002 13:31:55 -0500 Message-ID: <06bd01c2162d$439e1c50$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1024323248.1234.25.camel@localhost.localdomain> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] More on REFER Changes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rjs asked: > Please read the draft below and comment. If you > agree with what's in the draft, please post a > note saying so. The referenced refer draft (gack!) can also be referred to at: http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-3265disc-00 .txt Please deference, digest (securely) and reference this list on your resulting ruminations. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 15:48:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18097 for ; Mon, 17 Jun 2002 15:48:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09288 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 15:48:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08425; Mon, 17 Jun 2002 15:31:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08386 for ; Mon, 17 Jun 2002 15:30:57 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17659 for ; Mon, 17 Jun 2002 15:30:18 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 17K2Cm-0002NW-00; Mon, 17 Jun 2002 22:30:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15630.14544.280425.531731@harjus.eng.song.fi> Date: Mon, 17 Jun 2002 22:30:24 +0300 To: "Peterson, Jon" Cc: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 In-Reply-To: <70565611B164D511957A001083FCDD56018703F9@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD56018703F9@va02.va.neustar.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > The proposition that Juha put forward to which I responded in my last mail - > that a service provider will bill me at a lesser rate if I select a > favorable area code in my calling party number - is absurd: the service > provider knows who you are, knows the area codes you can claim in your > calling party number, and it seems unlikely that they are granting this > flexibility so that you can elect to pay them less money. in many cases the party that provides the sip proxy that authenticates the user and lets the user to selects its sip identity has nothing to the with the party that provides the pstn service. the pstn service provider simply charges based on called and calling party numbers and doesn't know anything about the sip user and certainly doesn't do any favors for him/her. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 15:53:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18169 for ; Mon, 17 Jun 2002 15:53:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09436 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 15:53:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08734; Mon, 17 Jun 2002 15:37:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08671 for ; Mon, 17 Jun 2002 15:37:49 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17800; Mon, 17 Jun 2002 15:37:09 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5HJbGV27122; Mon, 17 Jun 2002 14:37:16 -0500 From: "Dean Willis" To: , Date: Mon, 17 Jun 2002 14:36:27 -0500 Message-ID: <06cd01c21636$45d18800$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Use of session time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think the following is an excellent set of guidelines for how to use our valuable face-to-face meeting time. -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Monday, June 17, 2002 10:27 AM To: tsv-chairs@ietf.org Subject: reminder about session time thanks to Loa Andersson for this note ------------------ All, just a short reminder to those who have or are requesting agenda slots at the MPLS WG in Yokohama. Please consider this when you prepare for the meeting. It is not the purpose of a WG session to have presentation of the content of a document. It is assumed that all attendees will have read the drafts in advance of the meeting. For documents that are work-in-progress, the presentation should cover issues resolved since the last draft followed by open issues and controversial topics with the intent to reach a resolution of said issues and topics. For new work items, the presentation should focus on what the problem is and why it is necessary for the work group to address it. Further it should be either shown how it falls within the existing charter or why and how the charter should be extended to encompass it. The solution should only be sketched. The appropriate way of bringing new work to the working group is to send a draft to the mailing list and promoting discussion on the list. Slots on the agenda should be used to discuss outstanding topics that has not be solved on the mailing list. For new proposals addressing issues where work-in-progess the presentation should focus on the (perceived) short-fallings of the existing work and why those issues need to be addressed both in terms of why they are required and why they cannot be addressed in the existing work. the new work must be related to existing work (i.e. compatible, mutually exclusive, outright replacement). Finally, the new solution should be skechted, explaining how the solution overcomes those issues. The primary purpose of this last part is to allow commentary from the floor, it should not be orientented toward selling the idea. In all cases only a limited number of slides should be used. Speakers should budget their at least 25% of their time to allow for questions. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 16:27:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18914 for ; Mon, 17 Jun 2002 16:27:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10990 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 16:27:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10127; Mon, 17 Jun 2002 16:05:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10099 for ; Mon, 17 Jun 2002 16:05:03 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18430 for ; Mon, 17 Jun 2002 16:04:20 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5HK4krU011730; Mon, 17 Jun 2002 22:04:46 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5HK4ia9020831; Mon, 17 Jun 2002 23:04:45 +0300 (EET DST) Message-ID: <3D0E40DC.3405FE0@lmf.ericsson.se> Date: Mon, 17 Jun 2002 23:04:45 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Flemming Andreasen , Adam Roach , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> <3D0D1488.7F8CBB0A@cisco.com> <3D0DD4F7.35749C57@lmf.ericsson.se> <003901c215ff$b34ce500$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > >Assume that the UAC receives an 183, including an SDP, and the UAS may > >start sending early media (eg an announcement). After that the UAC receives > >180 from the same UAS, WITHOUT SDP. Now, according to the spec the >UAC > should generate a local ringback tone. > > Its say MAY, not SHOULD. > > >However, in this case the UAC would stop forwarding the > >early media because it received a 180 without an SDP (it did not receive > >an SDP with "inactive" mode). > > Why would it do that? If the offer/answer has completed and there is an RTP > flow established, it would continue unless there was another SDP > offer/answer exchange. The session state (of the RTP) is not tied to call > signalling state in this way. True. However, if the UAC would generate a local ringback tone it probably wouldn't like to mix it with the early media sent by the MGC. My understanding is that the SDP in the 180 really doesn't have anything to do with the offer/answer mechanism to do as such - it simply indicates if the UAC may/should/whatever generate a local ringback, or if remote ringback will be generated. However, if I do receive a 180 without SDP, AFTER I've received a 183 WITH SDP, I would like to be sure that the remote party will not continue generate remote ringback/early media. IF the remote party does that, the SDP should be included also in the 180. Regards, Christer Holmberg Ericsson Finland > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > Flemming Andreasen wrote: > > > > > Adam Roach wrote: > > > > > > > No. > > > > > > > > No, no, no, no, no. > > > > > > > > If you know there is user alerting going on, use 180. > > > > > > > > Sending 183 and playing in-band ringback is not a > > > > generally acceptable solution; you're overriding > > > > the calling party's user interface's rendering of > > > > "remote party is being alerted." Their client may > > > > very well not render this using audio at all. > > > > > > Could you point me to where in SIP this is stated ? Also, how come the > unify > > > draft (in Figure 10) contains an example that explicitly uses 183 for > inband > > > ringback ? The call-flows draft shows this as well. > > > > > > > > > > > Think of the interactions between abusing 183 this > > > > way and, say, a deaf user. > > > > > > > > > > I would assume that most deaf users would be using a relay or > transcoding > > > service of some kind (e.g TDD) rather than having a plain old audio > > > telephone conversation, and hence I'm not sure it makes much difference > in > > > that case. > > > > > > -- Flemming > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 16:31:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19038 for ; Mon, 17 Jun 2002 16:31:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11572 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 16:31:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10228; Mon, 17 Jun 2002 16:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10197 for ; Mon, 17 Jun 2002 16:08:23 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18465 for ; Mon, 17 Jun 2002 16:07:43 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5HK85Rb017404; Mon, 17 Jun 2002 22:08:05 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5HK84a9021096; Mon, 17 Jun 2002 23:08:04 +0300 (EET DST) Message-ID: <3D0E41A4.72444764@lmf.ericsson.se> Date: Mon, 17 Jun 2002 23:08:04 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Flemming Andreasen , Adam Roach , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F2@DYN-TX-EXCH-001.dynamicsoft.com> <3D0D1488.7F8CBB0A@cisco.com> <003301c215ff$478f1b80$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Line 4560 says "The UA receiving the INVITE is trying to alert the user. The > response MAY be used to initiate local ringback". > > Thus from a call signaling state point of view, the UAC does not consider > the caller "alerted" unless it sees a 180. A UAC that renders any sort of > visual indication of ringing would not do so with a 183. > > The spec says the 180 MAY initiate local ringback, not SHOULD. It seems to > me that if the UAC receives SDP in either a 183 or 180 and there is RTP > flowing, then it should play that RTP to the caller. The caller will hear > whatever the UAS is sending. It does not matter that it is ringback or other > audio. My issue now is when the UAC receives 183 (with SDP) AND 180 (no SDP) - a rather normal(?) scenario, I'd say. I do understand the differences in 183 and 180 from a signalling point of view. I think the possible early media (including remote ringback) is the issue. Thanks for your comments! Christer Holmberg Ericsson Finland > > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Flemming Andreasen" > To: "Adam Roach" > Cc: "'Christer Holmberg'" ; "Mark Watson" > ; > Sent: Sunday, June 16, 2002 6:43 PM > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > > > > > Adam Roach wrote: > > > > > No. > > > > > > No, no, no, no, no. > > > > > > If you know there is user alerting going on, use 180. > > > > > > Sending 183 and playing in-band ringback is not a > > > generally acceptable solution; you're overriding > > > the calling party's user interface's rendering of > > > "remote party is being alerted." Their client may > > > very well not render this using audio at all. > > > > Could you point me to where in SIP this is stated ? Also, how come the > unify > > draft (in Figure 10) contains an example that explicitly uses 183 for > inband > > ringback ? The call-flows draft shows this as well. > > > > > > > > Think of the interactions between abusing 183 this > > > way and, say, a deaf user. > > > > > > > I would assume that most deaf users would be using a relay or transcoding > > service of some kind (e.g TDD) rather than having a plain old audio > > telephone conversation, and hence I'm not sure it makes much difference in > > that case. > > > > -- Flemming > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 17:56:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21283 for ; Mon, 17 Jun 2002 17:56:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17561 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 17:56:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16190; Mon, 17 Jun 2002 17:37:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23720 for ; Mon, 17 Jun 2002 11:57:23 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08622; Mon, 17 Jun 2002 11:56:44 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5HFv5p29962; Mon, 17 Jun 2002 11:57:05 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA06574; Mon, 17 Jun 2002 17:57:03 +0200 (MET DST) To: , , , , , , , , , , , Received: from ouranos by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA06555; Mon, 17 Jun 2002 17:56:49 +0200 (MET DST) Message-ID: <01de01c21617$a602b790$9981cdd4@ouranos> Reply-To: "Nikos A. Nikolaou" From: "Nikos A. Nikolaou" Original-To: , , , , , , , , , , , Date: Mon, 17 Jun 2002 18:57:04 +0300 Organization: Lucent Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] CFP: Special Issue in IEEE Network on Network Management Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My apologies if you receive multiple copies of this. A pdf version of this CFP will be available soon at http://www.comsoc.org/pubs/net/ntwrk/special.html Kind regards, Nikos A. Nikolaou ------------------------------------------------------------------------------- Call For Papers IEEE Network Magazine Special Issue on Network Management of Multi-service, Multimedia, IP-based Networks Guest Editors Dr. Nikolaos Nikolaou Dr. Theodore Zahariadis Lucent Technologies Networking & Multimedia Systems Bell Labs - AT, EMEA Ellemedia Technologies Botterstraat 45 Syggrou 223, 1270 AA, Huizen, 171 21, Athens The Netherlands Greece Tel: +31 - 35 - 687 5302 Tel: +30 - 10 - 937 3097 Email: nikolaou@lucent.com Email: zahariad@ellemedia.com Prof. Joan Serrat Dr. Bharat Doshi Telecommunication Engineering Lucent Technologies Universitat Politecnica de Catalunya Bell Labs Sor Eulalia d'Anzizu, s/n, 101 Crawfords Corner Rd, 08034, Barcelona, Holmdel, NJ 07733 Spain USA Tel: +34 - 93 - 401 6786 Tel: +1732 949 0823 Email: serrat@tsc.upc.es Email: bdoshi@lucent.com Objectives During the last decade, innovations concerning optical networking technology, as well as advances in digital compression and transmission over copper and cable have dramatically increased the capabilities and the efficiency of existing and imminent access-, metropolitan- and core-networks. A major breakthrough in communications was the fast deployment of cellular systems. Currently, 3G wireless systems, targeting the transmission of voice, video and high-speed data, are already under preliminary deployment. Furthermore, researchers and vendors are expressing a growing interest in 4G wireless systems that will support even higher rates and cater for global roaming across multiple wireless networks. Meanwhile, based on the TCP/IP protocol suite, the Internet has evolved from a research network, targeting a limited audience of academic and military users, to a huge and commercially operated network. Next-generation IP technology has the potential to prevail, both in the access and in the core, as we are moving toward a worldwide, multi-service, multimedia and high-speed networking environment. The explosion of IP-based multimedia applications led to an exponential growth of IP traffic and initiated a number of research activities that would allow efficient Quality of Service (QoS) support. Additionally, the issue of security became more important and acquired considerable attention owing to the proliferation of IP-based Virtual Private Networks (VPNs). However, apart from efficient compression, sophisticated transmission schemes and support for QoS, mobility and security, contemporary networking applications require significant functionality for management operations, ensuring that the underlining network is both available and capable of supporting the service uninterruptedly. Configuration, performance and fault management over heterogeneous underlying technologies and multi-layered networks, along with end-to-end QoS, traffic management, service control platforms, billing and mobility management are also crucial components of multi-service and high-speed IP-based networks. The goal of this special issue in IEEE Network Magazine is to present to the magazine's audience (1) a comprehensive study of the design, performance and deployment issues and solutions of end-to-end network management over multi-domain, multi-technology, IP-based networks, and (2) a consolidated insight into ongoing research, development and trials' evaluation of network management technologies and platforms, broadening future research directions. To achieve this goal, this special issue seeks for original papers with strong tutorial and/or survey perspective that will consolidate and present the leading-edge research prototype development, trials and early deployment and performance studies in Network Management of multi-service, multimedia, IP-based networks. Topics In particular, focused tutorial and survey contributions are solicited on (but not restricted to) the following areas: * End-to-end IP multimedia network and service management * VoIP, IP Video, streaming, interactive video service management * Provisioning of multimedia networks and services * Wireless LAN and 3G/4G mobile multimedia network management * Management of terminal and network mobility * Inter-domain IP over WDM multimedia network management * Network management models and architectures * Management issues for billing and security for IP multimedia services * Multi-domain, multi-point, multicast services management * Policy-based management for multimedia services * Performance and Fault Management of Multi-layered Networks * QoS management * Multimedia traffic management * Active multimedia network management * Middleware support for management Manuscript Submission Interested authors should submit an electronic version of the manuscript, in either Postscript or PDF format, as an email attachment to one of the guest editors. Additional information including "Guidelines for authors" is available at the IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html Important Dates Submission Deadline: October 1, 2002 Notification of Acceptance: December 21, 2002 Final Manuscript Due: March 1, 2003 Publication Date: May/June 2003 ------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 17:56:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21305 for ; Mon, 17 Jun 2002 17:56:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17575 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 17:57:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16219; Mon, 17 Jun 2002 17:37:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00727 for ; Sun, 16 Jun 2002 18:54:47 -0400 (EDT) Received: from hotmail.com (f35.law12.hotmail.com [64.4.19.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08845 for ; Sun, 16 Jun 2002 18:54:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 16 Jun 2002 15:54:14 -0700 Received: from 142.137.145.108 by lw12fd.law12.hotmail.msn.com with HTTP; Sun, 16 Jun 2002 22:54:14 GMT X-Originating-IP: [142.137.145.108] From: "Taja Ja" To: sip@ietf.org Cc: lmctaja@ericsson.ca, hayanitm@hotmail.com, kais_mnif@hotmail.com Date: Sun, 16 Jun 2002 18:54:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jun 2002 22:54:14.0961 (UTC) FILETIME=[BCF39210:01C21588] Subject: [Sip] SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a project to do using SIP and I need some help. I`ve gone through Gonzalo`s book (SIP Demystified) but still need help. My problem: I need to find out how the protocol works internally and have an UML model for that. Same as as Protocole P1 between MTA( Message Transfer Agent) and another MTA, this concern MHS (message handling system) protocol . It sound straneg but since SIP si not a standard yet I`m having hard time to fin this information. I`m taking the example from Ganozalo`s book (page 151) as an example for my work, it`s clear and detailed: a session between 2 UA with a proxy. Thanks for any help, time spent .... Taher. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 18:01:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21406 for ; Mon, 17 Jun 2002 18:01:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18181 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 18:02:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16169; Mon, 17 Jun 2002 17:37:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00336 for ; Mon, 17 Jun 2002 13:00:51 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11487 for ; Mon, 17 Jun 2002 13:00:12 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5HH0Li11783 for ; Mon, 17 Jun 2002 12:00:21 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5HH0Kx23393 for ; Mon, 17 Jun 2002 12:00:20 -0500 (CDT) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g5HH0KE26453 for ; Mon, 17 Jun 2002 13:00:20 -0400 (EDT) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 13:00:20 -0400 Message-ID: <32CD630F6CBED411AE180008C7894CBCA38517@lmc37.lmc.ericsson.se> From: "Taher Jaafri (LMC)" To: sip@ietf.org Date: Mon, 17 Jun 2002 13:00:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP stack Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Is someone can help find all specification of SIP stack I need this for a University project. I've gone through SIP RFC but I need more than that I need primitives used by SIP to talk to UDP/TCP/IP I need services offered by UDP/TCP/IP to SIP (SAP). Any help is appreciated and thanks for your time. Thanks.Taher. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 18:07:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21481 for ; Mon, 17 Jun 2002 18:07:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18455 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 18:07:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17056; Mon, 17 Jun 2002 17:49:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17025 for ; Mon, 17 Jun 2002 17:49:43 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21115 for ; Mon, 17 Jun 2002 17:49:01 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GXV00101DXW3J@firewall.wcom.com> for sip@ietf.org; Mon, 17 Jun 2002 21:49:08 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GXV000ARDXVI3@firewall.wcom.com>; Mon, 17 Jun 2002 21:49:07 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GXV00501DXKAY@dgismtp04.wcomnet.com>; Mon, 17 Jun 2002 21:49:07 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.138]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GXV00527DVL16@dgismtp04.wcomnet.com>; Mon, 17 Jun 2002 21:47:46 +0000 (GMT) Date: Mon, 17 Jun 2002 16:47:45 -0500 From: Henry Sinnreich Subject: RE: [Sip] SIP stack In-reply-to: <32CD630F6CBED411AE180008C7894CBCA38517@lmc37.lmc.ericsson.se> To: "'Taher Jaafri (LMC)'" , sip@ietf.org Message-id: <008901c21648$9dced730$8ae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Try www.cs.columbia.edu/sip http://www.iptel.org/info/products/index.php?siponly=1&category=stack www.vovida.org http://www.antd.nist.gov/proj/iptel/ Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Taher Jaafri (LMC) > Sent: Monday, June 17, 2002 12:00 PM > To: sip@ietf.org > Subject: [Sip] SIP stack > > > Hi, > > Is someone can help find all specification of SIP stack > I need this for a University project. > > I've gone through SIP RFC but I need more than that > I need primitives used by SIP to talk to UDP/TCP/IP > I need services offered by UDP/TCP/IP to SIP (SAP). > > Any help is appreciated and thanks for your time. > > Thanks.Taher. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 19:08:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22885 for ; Mon, 17 Jun 2002 19:08:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22923 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 19:09:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21303; Mon, 17 Jun 2002 18:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21187 for ; Mon, 17 Jun 2002 18:51:36 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22389 for ; Mon, 17 Jun 2002 18:50:58 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g5HMoZB12955; Mon, 17 Jun 2002 18:50:35 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 17:50:30 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A0273@STNTEXCH2> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Mon, 17 Jun 2002 17:51:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I don't really have anything else to say about this application, except that I doubt it would work in any segment of the PSTN (PSTN service providers do not naively "charge based on called and calling number" in my experience), and that if it did, it still would not provide any compelling argument that P-Preferred-Identity should be a part of baseline SIP. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, June 17, 2002 12:30 PM > To: Peterson, Jon > Cc: 'sip@ietf.org' > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > The proposition that Juha put forward to which I responded in my last mail - > > that a service provider will bill me at a lesser rate if I select a > > favorable area code in my calling party number - is absurd: the service > > provider knows who you are, knows the area codes you can claim in your > > calling party number, and it seems unlikely that they are granting this > > flexibility so that you can elect to pay them less money. > > in many cases the party that provides the sip proxy that authenticates > the user and lets the user to selects its sip identity has nothing to > the with the party that provides the pstn service. the pstn service > provider simply charges based on called and calling party numbers and > doesn't know anything about the sip user and certainly doesn't do any > favors for him/her. > > -- juha > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 17 19:09:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22905 for ; Mon, 17 Jun 2002 19:09:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22940 for sip-archive@odin.ietf.org; Mon, 17 Jun 2002 19:09:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21105; Mon, 17 Jun 2002 18:50:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21073 for ; Mon, 17 Jun 2002 18:50:17 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22347 for ; Mon, 17 Jun 2002 18:49:39 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5HMnmT30485; Mon, 17 Jun 2002 17:49:48 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 17:49:43 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA810A0272@STNTEXCH2> From: "Peterson, Jon" To: "'sip@ietf.org'" , "'mwatson@nortelnetworks.com'" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Mon, 17 Jun 2002 17:51:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21651.7A488410" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21651.7A488410 Content-Type: text/plain; charset="iso-8859-1" A few inline notes below. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Saturday, June 15, 2002 9:20 AM To: 'Peterson, Jon'; 'Dean Willis'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Ok, so I am not particularly bothered about Preferred Identity being a P-header. But I think it is fair to argue the point that if several users of SIP have found the need to 'diverge' from the standard SIP architecture in this respect, then perhaps it is worth considering enhancement of the standard architecture. There is an assumption in SIP that a given user (from an authentication point of view) has only a single identity/service profile etc. We are just talking about relaxing that assumption. [Peterson, Jon] Just to be clear, there is no assumption that a single user has only a single identity in SIP's baseline authentication mechanism. I may have many usernames and passwords that I can provide for different 'realms'. In fact, SIP even has a concept that a given response (a 407) can aggregate challenges from multiple realms, and that a user can provide different credentials to each one of these challenges in a single retried request (so I can cryptographically claim to be both jon.peterson@neustar.biz and mwatson@nortelnetworks.com in the same request, if I have the proper credentials). Also, as we've argued here many times before there are a number of other SIP headers that can all carry identity information at variance with one another in a single SIP message. In the case of 3GPP, then the requirement arises from the desire to re-use the SIM-card based authentication mechanism which has already been scaled to .5 billion users or whatever. I think this makes this mechanism just a little more successful than any other authentication scheme of equivalent security that I know of. This in my view is a reasonable case for re-use, even if a slight divergence from the SIP architecture is involved. [Peterson, Jon] More successful than TLS and Digest in HTTP? The properties of this mechanism, and the functional split between the home SIP proxy and the repository of the shared secret make it difficult to use the cached nonce approach. [Peterson, Jon] That isn't clear to me, actually. Nonces are cached on a per-realm basis. Assuming that you intend to prove identities within the same realm, you can re-use the nonce. The split between a home proxy and a repository of shared secrets (brokered by some kind of AAA protocol, I'd guess? - the concept of realms carries over into many such systems) shouldn't impact that either way. Finally, the reliance on IPSEC for the first hop to avoid re-authentication on subsequent messages is not exactly 'outside the internet model'. [Peterson, Jon] Yes, well, I did acknowledge that 'Internet model' is a loaded term, especially when used to describe SIP (cough). The real issue seems to be the way in which these 3G models segregate authentication from assertion of identity - you provide credentials at some lower layer which are linked, in the back office, with a set of identities that you can legitimately assert in the application layer. In any event, the authentication takes place outside of SIP, so it can at least be said to be outside the scope of the 'SIP model' - SIP is expected to take it on faith that the security properties of authentication are handled appropriately elsewhere (much as it is expected to take confidentiality and integrity on faith when IPSec with security gateways is used). It is also my understanding that 3G's architecture requires that some properties of sub-IP layers in the network contribute to security services. ...Mark -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 14 June 2002 18:44 To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere. When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header. Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect. I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread. Jon Peterson NeuStar, Inc. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, June 14, 2002 8:39 AM To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Mark suggested: > If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . . but it does seem cleaner to use a preferred-identity indicator. -- Dean ------_=_NextPart_001_01C21651.7A488410 Content-Type: text/html; charset="iso-8859-1" Message
A few inline notes below.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Saturday, June 15, 2002 9:20 AM
To: 'Peterson, Jon'; 'Dean Willis'; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Ok, so I am not particularly bothered about Preferred Identity being a P-header. But I think it is fair to argue the point that if several users of SIP have found the need to 'diverge' from the standard SIP architecture in this respect, then perhaps it is worth considering enhancement of the standard architecture. There is an assumption in SIP that a given user (from an authentication point of view) has only a single identity/service profile etc. We are just talking about relaxing that assumption.
[Peterson, Jon] Just to be clear, there is no assumption that a single user has only a single identity in SIP's baseline authentication mechanism. I may have many usernames and passwords that I can provide for different 'realms'. In fact, SIP even has a concept that a given response (a 407) can aggregate challenges from multiple realms, and that a user can provide different credentials to each one of these challenges in a single retried request (so I can cryptographically claim to be both jon.peterson@neustar.biz and mwatson@nortelnetworks.com in the same request, if I have the proper credentials). Also, as we've argued here many times before there are a number of other SIP headers that can all carry identity information at variance with one another in a single SIP message.
 
In the case of 3GPP, then the requirement arises from the desire to re-use the SIM-card based authentication mechanism which has already been scaled to .5 billion users or whatever. I think this makes this mechanism just a little more successful than any other authentication scheme of equivalent security that I know of. This in my view is a reasonable case for re-use, even if a slight divergence from the SIP architecture is involved.
[Peterson, Jon] More successful than TLS and Digest in HTTP?
 
The properties of this mechanism, and the functional split between the home SIP proxy and the repository of the shared secret make it difficult to use the cached nonce approach.
[Peterson, Jon] That isn't clear to me, actually. Nonces are cached on a per-realm basis. Assuming that you intend to prove identities within the same realm, you can re-use the nonce. The split between a home proxy and a repository of shared secrets (brokered by some kind of AAA protocol, I'd guess? - the concept of realms carries over into many such systems) shouldn't impact that either way.
 
Finally, the reliance on IPSEC for the first hop to avoid re-authentication on subsequent messages is not exactly 'outside the internet model'.
[Peterson, Jon] Yes, well, I did acknowledge that 'Internet model' is a loaded term, especially when used to describe SIP (cough). The real issue seems to be the way in which these 3G models segregate authentication from assertion of identity - you provide credentials at some lower layer which are linked, in the back office, with a set of identities that you can legitimately assert in the application layer. In any event, the authentication takes place outside of SIP, so it can at least be said to be outside the scope of the 'SIP model' - SIP is expected to take it on faith that the security properties of authentication are handled appropriately elsewhere (much as it is expected to take confidentiality and integrity on faith when IPSec with security gateways is used). It is also my understanding that 3G's architecture requires that some properties of sub-IP layers in the network contribute to security services.
 
...Mark
-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: 14 June 2002 18:44
To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Well, this begins to speak to the matters that in my mind actually motivated the P-Preferred-Identity header - namely, the fact that PacketCable-derived networks did not want to use the baseline SIP authentication mechanisms. If per-request authentication (which, as Dean correctly points out, can use cached nonces to avoid the extra RTTs) is infeasible for some reason, you may need a alternate way to express the identity that would ordinarily be presented by the SIP authentication system. I have always viewed P-Preferrred-Identity as an authentication header with no cryptographic properties - something like an unsolicited Proxy-Authorization with no hash - since the cryptographic properties are being staged elsewhere.
 
When you start to turn your back on the baseline SIP mechanisms, and instead rely on mechanisms outside the Internet model (yes, loaded term) for security and authentication, you have entered into the realm of P- headers. Ultimately, that is what this thread is about - whether or not P-Preferred-Identity should be a P- header.
 
Maybe this is really the crux of the matter - if your architecture diverges enough from the SIP model that you can't get access to SIP authentication as a way of expressing your identity to the network, then clearly your architecture is not 'baseline', and any argument that we need some baseline SIP mechanism (as opposed to a P- header) to express identity in your architecture is going to seem a little suspect.
 
I agree, anyway, that inquiries along these lines are more likely to provide profitable new arguments for doing this one way or another than some of the other branches in this thread.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Friday, June 14, 2002 8:39 AM
To: 'Mark Watson'; 'Peterson, Jon'; jh@lohi.eng.song.fi
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Mark suggested: 
> If I allow subsequent sessions on the same connection, then this 'hint' becomes useful. Performing Digest authentication again every time (requiring an additional RTT) seems a heavy price just to communicate a few extra octets. 
 
Er, you COULD just include the appropriate credentials using the cached nonce on future requests, and not bother to actually rechallenge . . .
 
but it does seem cleaner to use a preferred-identity indicator.
 
--
Dean
 

 
 
 
 
 
 
------_=_NextPart_001_01C21651.7A488410-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 18 03:45:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09486 for ; Tue, 18 Jun 2002 03:45:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23908 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 03:46:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22618; Tue, 18 Jun 2002 03:24:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22586 for ; Tue, 18 Jun 2002 03:24:11 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09161 for ; Tue, 18 Jun 2002 03:23:34 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5I7OZi28213 for ; Tue, 18 Jun 2002 10:24:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Jun 2002 10:24:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 10:24:06 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 10:24:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 Date: Tue, 18 Jun 2002 10:24:08 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20348@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] draft-ietf-sip-asserted-identity-01 Thread-Index: AcIWNaRLoPsoX1jHQ169KgtSY+RK7wAYx7yQ To: , Cc: X-OriginalArrivalTime: 18 Jun 2002 07:24:00.0062 (UTC) FILETIME=[1D815DE0:01C21699] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA22588 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, June 17, 2002 10:30 PM > To: Peterson, Jon > Cc: 'sip@ietf.org' > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01 > > > Peterson, Jon writes: > > > The proposition that Juha put forward to which I responded > in my last mail - > > that a service provider will bill me at a lesser rate if I select a > > favorable area code in my calling party number - is > absurd: the service > > provider knows who you are, knows the area codes you can > claim in your > > calling party number, and it seems unlikely that they are > granting this > > flexibility so that you can elect to pay them less money. > > in many cases the party that provides the sip proxy that authenticates > the user and lets the user to selects its sip identity has nothing to > the with the party that provides the pstn service. the pstn service > provider simply charges based on called and calling party numbers and > doesn't know anything about the sip user and certainly doesn't do any > favors for him/her. Wouldn't that sip entity be your PSTN gateway? the gateway can authenticate the user. Hisham > > -- juha > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 18 05:07:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10644 for ; Tue, 18 Jun 2002 05:07:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29363 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 05:08:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27717; Tue, 18 Jun 2002 04:36:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27684 for ; Tue, 18 Jun 2002 04:36:53 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10305 for ; Tue, 18 Jun 2002 04:36:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5I8bKi00912 for ; Tue, 18 Jun 2002 11:37:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 18 Jun 2002 11:36:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 11:36:51 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 11:36:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Tue, 18 Jun 2002 11:36:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2034B@esebe019.NOE.Nokia.com> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWCX1CSlWGUDPFTFid1ds9KZO6+wAmGF9Q To: , X-OriginalArrivalTime: 18 Jun 2002 08:36:51.0125 (UTC) FILETIME=[4ADCA650:01C216A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA27685 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I agree with the changes. Just a couple of minor nits: Section 2 mentions that a "REFER might create a dialog". Might? Should it say "MAY" or better extent this sentence to say "REFER creates a dialog when an implicit subscription has been created." Also section 2 references section 2.4.5 referring to the section of the cases when a REFER implicitly establishes a subscription. Should that reference be sections 2.4.1-2.4.3? (Section 2.4.5 actually describes the behaviour once a subscription has been created). Section 2.4.5 Its not clear that a SUBSCRIBE is used to refresh and not a REFER. How about "The agent issuing the REFER may extend its subscription by sending a SUBSCRIBE request using the subscription refresh mechanisms described in [2]." Regards, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, June 17, 2002 5:14 PM > To: sip@ietf.org > Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > The message I sent last week (copied below) > has generated no list comments. I hope it > was because I was too subtle with the subject > line. > > I have asked the IESG to delay their consideration > of the REFER draft until these concerns have been > discussed on this list. > > Please read the draft below and comment. If you > agree with what's in the draft, please post a > note saying so. > > RjS > > -----Forwarded Message----- > > > From: Robert Sparks > > To: sip@ietf.org > > Subject: [Sip] Refer status/adjustment > > Date: 12 Jun 2002 13:49:35 -0500 > > > > A set of converging concerns were raised about the > > REFER draft late in the review process, all centering > > on draft's use of sip-events (soon to be RFC3265) and > > the implicit subscription. > > > > When investigating those concerns, several things became > > clear. > > > > The draft did not provide sufficient discussion > > around managing the lifecycle of the implicit subscription > > (Can you refresh the implicit subscription? unsubscribe? > > How is the Subscription-State header supposed to be used? > > How do the two parties know when the subscription is over?) > > and the draft did not clearly specify some of the things > > RFC3265 requires of an event package. These need to be > > corrected. > > > > A larger issue centers around the following language from > > sip-events: > > > > Note that any behavior designated with "SHOULD" or "MUST" in this > > document is not allowed to be weakened by extension documents; > > however, such documents may elect to strengthen "SHOULD" > > requirements to "MUST" strength if required by their application. > > > > The current draft is not clear enough on one particular point - the > > examples do not show immediate NOTIFYs for the implicit > subscription. > > I expect that many members of the community believe they are not > > required (I had drifted into thinking that way before the comments > > caused me to look at this more closely). The normative text in the > > current REFER draft calls to RFC3265, and immediate NOTIFYs are very > > clearly required there. This needs to be pointed out more clearly > > in the REFER draft. > > > > Finally, the current draft makes instantiating a subscription a > > SHOULD strength requirement, but provides no mechanism for the > > agent sending the REFER to know whether or not to expect a NOTIFY. > > We have repeatedly had discussions on the list about how long > > the agent sending the REFER should keep state waiting for a NOTIFY - > > and with discomfort deciding that is an implementation decision. > > Recent discussions have pointed out that there is disagreement about > > what never receiving a NOTIFY means - should the REFERing > party treat > > that as an error and re-attempt the reference or should it just > > assume no subscription was created? > > > > I've put together an individual submission that adds all the > > above clarifications. It also proposes a new mechanism to > > address the problems in the previous paragraph. Basically, it > > provides a way for the party sending the REFER to indicate > > that it really wants to be notified, and a way for the agent > > accepting the refer to signal that it will or will not send > > notifies in the response to the REFER. > > > > I just submitted this draft - until it appears in the repository, > > you can get it from > > > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265di sc-00.txt > > I propose that this draft replace refer-05 before it advances further > in the standardization process. > > RjS > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 18 10:21:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18855 for ; Tue, 18 Jun 2002 10:21:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15632 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 10:22:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13440; Tue, 18 Jun 2002 09:54:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13409 for ; Tue, 18 Jun 2002 09:54:42 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17539 for ; Tue, 18 Jun 2002 09:54:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Tue, 18 Jun 2002 08:54:04 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A80@NREXCH.netrake.net> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWDEbGlPzw6OZ/Sva8F+dVG9RsCAAwEJyg From: "Rob Phillips" To: Cc: "Robert Sparks" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA13410 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I have a nit on the Examples section of 2.1. The following two examples don't parse: Refer-To: sip:bob@biloxi.com?Accept-Contact%3Dsip:bobsdesk. biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com Refer-To: sip:dave@denver.com?Replaces%3D12345%40192.168.118.3%3B to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 I think what you would want to have would be something like this: Refer-To: sip:bob@biloxi.com;method=REFER?Accept-Contact%3Dsip:bobsdesk. biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com Refer-To: sip:dave@denver.com;method=REFER?Replaces%3D12345%40192.168.118.3%3B to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 Also, while this is pretty well spelled out in the document, I'd like to see somewhere (either in section 2.1 or 2.2) where you have this information: Header field where REFER ____________ _____ _____ Refer-To R m - rob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 18 10:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19558 for ; Tue, 18 Jun 2002 10:34:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16722 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 10:34:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14830; Tue, 18 Jun 2002 10:10:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14800 for ; Tue, 18 Jun 2002 10:09:58 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18249 for ; Tue, 18 Jun 2002 10:09:18 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5IE8Zd10251 for ; Tue, 18 Jun 2002 17:08:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Jun 2002 17:09:55 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 17:09:55 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 18 Jun 2002 17:09:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Tue, 18 Jun 2002 17:09:53 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20351@esebe019.NOE.Nokia.com> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWDEbGlPzw6OZ/Sva8F+dVG9RsCAAwEJygAAEbvoA= To: , Cc: X-OriginalArrivalTime: 18 Jun 2002 14:09:54.0806 (UTC) FILETIME=[D2106160:01C216D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA14801 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Rob Phillips [mailto:rob@netrake.com] > Sent: Tuesday, June 18, 2002 4:54 PM > To: sip@ietf.org > Cc: Robert Sparks > Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > I have a nit on the Examples section of 2.1. The following > two examples don't parse: > > Refer-To: sip:bob@biloxi.com?Accept-Contact%3Dsip:bobsdesk. > biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com > > Refer-To: > sip:dave@denver.com?Replaces%3D12345%40192.168.118.3%3B > to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 > > I think what you would want to have would be something like this: > > Refer-To: > sip:bob@biloxi.com;method=REFER?Accept-Contact%3Dsip:bobsdesk. > biloxi.com&Call-ID%3D55432%40alicepc.atlanta.com > > Refer-To: > sip:dave@denver.com;method=REFER?Replaces%3D12345%40192.168.118.3%3B > to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 This is wrong. method=REFER in this case means that you are asking the referee to send a REFER. This is what you want Refer-To: > sip:dave@denver.com;method=INVITE?Replaces%3D12345%40192.168.118.3%3B > to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 But since INVITE is the default, then its not needed. If you want to refer someone to subscribe to someone else, then you would have Refer-To: > sip:dave@denver.com;method=SUBSCRIBE By the way, do we need <> around the sip uri examples there? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 11:05:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21284 for ; Tue, 18 Jun 2002 11:05:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19762 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 11:06:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17829; Tue, 18 Jun 2002 10:51:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17801 for ; Tue, 18 Jun 2002 10:50:57 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20456 for ; Tue, 18 Jun 2002 10:50:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Tue, 18 Jun 2002 09:50:20 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A81@NREXCH.netrake.net> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWDEbGlPzw6OZ/Sva8F+dVG9RsCAAwEJygAAEbvoAAASEB4A== From: "Rob Phillips" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17802 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit >This is what you want >Refer-To: >> sip:dave@denver.com;method=INVITE?Replaces%3D12345%40192.168.118.3%3B >> to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 >But since INVITE is the default, then its not needed. Forgive my ignorance here, I'm mainly concerned with the parsing of the request as opposed to how it works, which is why I chose "method=REFER". I see that this seems to be the case for other examples as well in the SIP draft, but where is it listed that the uri-parameter field is optional? In the BNF, the uri-parameters field is listed as a mandatory field: SIP-URI = "sip:" [ userinfo "@" ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo "@" ] hostport uri-parameters [ headers ] And at least in bis-09 section 19.1.1, there isn't a reference to the uri-parameters field being optional. So is this a problem with bis-09? It's certainly an inconsistency. - rob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 11:47:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23581 for ; Tue, 18 Jun 2002 11:47:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23902 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 11:47:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22255; Tue, 18 Jun 2002 11:30:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22197 for ; Tue, 18 Jun 2002 11:30:26 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22677 for ; Tue, 18 Jun 2002 11:29:46 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5IFTooF010188; Tue, 18 Jun 2002 11:29:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 11:29:52 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A210@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rob Phillips'" , hisham.khartabil@nokia.com, sip@ietf.org Cc: Robert Sparks Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref erstatus/adjustment] Date: Tue, 18 Jun 2002 11:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Look more closely at the definition of "uri-parameters". uri-parameters = *( ";" uri-parameter) See that "*" in the front? That means "zero or more." And zero happens to be a very popular choice for this particular case. /a > -----Original Message----- > From: Rob Phillips [mailto:rob@netrake.com] > Sent: Tuesday, June 18, 2002 9:50 > To: hisham.khartabil@nokia.com; sip@ietf.org > Cc: rsparks@dynamicsoft.com > Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > >This is what you want > >Refer-To: > >> > sip:dave@denver.com;method=INVITE?Replaces%3D12345%40192.168.118.3%3B > >> to-tag%3D12345%3Bfrom-tag%3D5FFE-3994 > >But since INVITE is the default, then its not needed. > > Forgive my ignorance here, I'm mainly concerned with the > parsing of the request as opposed to how it works, which is > why I chose "method=REFER". > > I see that this seems to be the case for other examples as > well in the SIP draft, but where is it listed that the > uri-parameter field is optional? In the BNF, the > uri-parameters field is listed as a mandatory field: > > SIP-URI = "sip:" [ userinfo "@" ] hostport > uri-parameters [ headers ] > SIPS-URI = "sips:" [ userinfo "@" ] hostport > uri-parameters [ headers ] > > And at least in bis-09 section 19.1.1, there isn't a > reference to the uri-parameters field being optional. So is > this a problem with bis-09? It's certainly an inconsistency. > > - rob > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 13:38:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27813 for ; Tue, 18 Jun 2002 13:38:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02395 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 13:39:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00679; Tue, 18 Jun 2002 13:19:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00648 for ; Tue, 18 Jun 2002 13:19:00 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27081 for ; Tue, 18 Jun 2002 13:18:20 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IHIOYH016533; Tue, 18 Jun 2002 13:18:25 -0400 (EDT) Message-ID: <3D0F6B60.7080300@dynamicsoft.com> Date: Tue, 18 Jun 2002 13:18:24 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pnath@hss.hns.com CC: sip@ietf.org References: <65256BAA.004B6EB1.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Regarding sending of Min-SE header in the re-INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit More old emails... inline: pnath@hss.hns.com wrote: > > Hello > I have doubt regarding the following statement of the > draft-ietf-sip-session-timer-08.txt > > "The UAC MUST insert the Min-SE header into a re-INVITE request for a > particular call leg if it has ever received a 422 response to a > previous > INVITE on the same leg" > > When a UAC receives 422 response for a INVITE request, it retries with > by > removing the tag field. > So once the call is established, there will not be any Min-SE for that > call > leg. Correct. > > The example in draft also says same thing. > > What value in the Min-SE header should go out ?. None, unless the UAC has one it wishes to impose. > > > The draft also specifes > > "In an INVITE that is within a call leg with an active session timer, > the > header SHOULD be present, and SHOULD contain the the larger of the > current value of the session interval and the value of the Min-SE, if > present" > > So how can be the re-INVITE get 422 response, so that next re-INVITE > will > go out with Min-SE header. Once the dialog is established, the min-SE is "cleared", as the draft states. So, the UAC could, for example, send a re-INVITE with a very low session expiration. This would result in a 422 if some proxy objects, and that 422 would have a Min-SE. The retried INVITE then has a Min-SE once again. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 14:43:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00220 for ; Tue, 18 Jun 2002 14:43:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06291 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 14:43:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05101; Tue, 18 Jun 2002 14:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05069 for ; Tue, 18 Jun 2002 14:21:54 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29404 for ; Tue, 18 Jun 2002 14:21:15 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IIL5YH016633; Tue, 18 Jun 2002 14:21:06 -0400 (EDT) Message-ID: <3D0F7A11.3050208@dynamicsoft.com> Date: Tue, 18 Jun 2002 14:21:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org, Jan Janak Subject: Re: [Sip] REGISTER Processing References: <5.1.0.14.0.20020423235232.030a2ec8@iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit sorry for the immensely late response... combing the list now for old bis issues: Jiri Kuthan wrote: > There seems to be insufficient guidance in bis-09 on usage of Call-ID > in REGISTERs. The only thing which I found there is in 10.2.4: > > "A UA SHOULD use the same Call-ID for all registrations during a > single boot cycle. " > > I think that does NOT require Call-ID to change across reboots. Correct. > UAs with no memory are not explicitely mandated to change Call-ID > (ignoring that bis asks to deny REGISTERs with Call-ID== and CSeq <= > values in registrar's bindings). If the UACs actually do not change > Call-ID, REGISTERs after reboots with low CSeq will be ignored. Right, which is way the guidelines for CSeq say: > CSeq: The CSeq value guarantees proper ordering of REGISTER requests. > A UA MUST increment the CSeq value by one for each REGISTER > request with the same Call-ID. This would seem to explicitly address the issue, no? > > Which actually happened during two tests in SIPIt. > > Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if not > doing so does not break things, which is not the case here. I think SHOULD is sufficient so long as you also properly follow the MUST strength requirement on CSeq incremeting. > > -- > > Other confusing thing is which SIP reply a request failure for > out-of-order REGISTERs in line 1740 implies. I could connect it to > the next paragraph "....if binding update fails...the request MUST > fail with 500..." but I am not sure that 500 is a good choice. No, that status code is correct. Its the same error response used when you receive a request on a dialog with a CSeq lower than the current one. From line 2033 in bis09 PDF, a 500 is returned there too. You want a 500, since the client can retry the request and it can work the second time (since the CSeq will change as a natural consequence of retrying the request). Given that the error code is correct, do you still find it confusing to have the two paragraphs connected? > > -- > > Yet anothet thing, which Jan pointed out, is that handling of > out-or-order in lines 1738-40 also includes retransmissions (CSeq and > CallID in request and bindings equal). Retransmissions would have already been handled in the transaction layer. Thus, a totally new transaction with the same call-id/cseq is indeed an error. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 15:03:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00958 for ; Tue, 18 Jun 2002 15:03:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07601 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 15:03:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05949; Tue, 18 Jun 2002 14:34:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05913 for ; Tue, 18 Jun 2002 14:34:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29965 for ; Tue, 18 Jun 2002 14:34:08 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IIYFYH016649; Tue, 18 Jun 2002 14:34:15 -0400 (EDT) Message-ID: <3D0F7D26.5040603@dynamicsoft.com> Date: Tue, 18 Jun 2002 14:34:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hussam Jarada CC: sip@ietf.org Subject: Re: [Sip] tel URI in SIP spec bis-09 References: <004901c1f093$6aa1c550$ee9e82cc@ulticomdal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hussam Jarada wrote: > Hi, > > In section 7.1, line 787 states that: > [SIP elements MAY support Request-URIs with schemes other than "sip" and > "sips", for example the > "tel" URI scheme of RFC 2806] > > But in section 8.1.12, line 997 state that: > [All SIP implementations MUST support the SIP and URI scheme] > > I think URI is just an error typing and it should be SIPS in line 997, > cause > you have MAY in section 7.1 but MUST in section 8.1.12. The SIPS URI scheme is not mandatory. The text should read: All SIP implementations MUST support the SIP URI scheme. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 15:30:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01813 for ; Tue, 18 Jun 2002 15:30:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08966 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 15:31:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07744; Tue, 18 Jun 2002 15:07:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07712 for ; Tue, 18 Jun 2002 15:07:03 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01036 for ; Tue, 18 Jun 2002 15:06:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IJ6WYH016714; Tue, 18 Jun 2002 15:06:32 -0400 (EDT) Message-ID: <3D0F84B8.4030805@dynamicsoft.com> Date: Tue, 18 Jun 2002 15:06:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Itamar Gilad CC: SIP list , Adi Even-Tzur Subject: Re: [Sip] To-tag in REGISTER References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The To tag shouldn't be there, since REGISTER doesn't establish a dialog. Since the spec doesn't specify handling for each and every one of the million error cases, behavior in this case is not defined, and left implementation dependent. Generally, you should be gracious with what you receive, so I would recommend ignoring the tag. Thanks, Jonathan R. Itamar Gilad wrote: > This is question we ran into in the last SIPit. How should an incoming > REGISTER request be handled if it has a To tag: > > 1. Reject the request with a 4xx response code (Invalid Registration) > or > 2. Accept the request but ignore the To tag at the address-of-record > stored > at the location DB (the record is stored without the tag). > > Thanks in advance > > Itamar Gilad > RADVISION > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 15:54:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00959 for ; Tue, 18 Jun 2002 15:03:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07629 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 15:03:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06352; Tue, 18 Jun 2002 14:44:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06321 for ; Tue, 18 Jun 2002 14:44:36 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00255 for ; Tue, 18 Jun 2002 14:43:52 -0400 (EDT) From: vganapathy@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g5IIaiH26582; Wed, 19 Jun 2002 00:06:45 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BDC.00659FB6 ; Wed, 19 Jun 2002 00:00:00 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: Jiri Kuthan , sip@ietf.org, Jan Janak Message-ID: <65256BDC.00659FA5.00@sampark.hss.hns.com> Date: Tue, 18 Jun 2002 23:59:59 +0530 Subject: Re: [Sip] REGISTER Processing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a few doubts regarding the way out of sequence REGISTER requests are handled. The Algorithm given in 10.3 seems to define different behaviours in handling out sequence REGISTER requests while updation and de-Registration. Bullet 6 which defines de-Registration (Contact with *) specifies that if CSeq doesn't match the binding MUST be left as is. (The request succeeds) Bullet 7 which defines updation specifies that if the CSeq doesn't match the update MUST be aborted and the "request fails". Why is the behaviour different for de-Registration and updation. What I feel is that even during updation the request shouldn't fail but the binding that doesn't agree with the CSeq should not be updated. But the updation of other bindings should be allowed. this way it is made sure that the Out of Sequence request received does not change the binding registered by the highet CSeq request. Am I missing out something. Please correct me if my understanding is wrong. Thanx & Regards, - Vijay Jonathan Rosenberg on 06/18/2002 11:51:05 PM To: Jiri Kuthan cc: sip@ietf.org, Jan Janak (bcc: Vijay Ganapathy/HSSBLR) Subject: Re: [Sip] REGISTER Processing sorry for the immensely late response... combing the list now for old bis issues: Jiri Kuthan wrote: > There seems to be insufficient guidance in bis-09 on usage of Call-ID > in REGISTERs. The only thing which I found there is in 10.2.4: > > "A UA SHOULD use the same Call-ID for all registrations during a > single boot cycle. " > > I think that does NOT require Call-ID to change across reboots. Correct. > UAs with no memory are not explicitely mandated to change Call-ID > (ignoring that bis asks to deny REGISTERs with Call-ID== and CSeq <= > values in registrar's bindings). If the UACs actually do not change > Call-ID, REGISTERs after reboots with low CSeq will be ignored. Right, which is way the guidelines for CSeq say: > CSeq: The CSeq value guarantees proper ordering of REGISTER requests. > A UA MUST increment the CSeq value by one for each REGISTER > request with the same Call-ID. This would seem to explicitly address the issue, no? > > Which actually happened during two tests in SIPIt. > > Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if not > doing so does not break things, which is not the case here. I think SHOULD is sufficient so long as you also properly follow the MUST strength requirement on CSeq incremeting. > > -- > > Other confusing thing is which SIP reply a request failure for > out-of-order REGISTERs in line 1740 implies. I could connect it to > the next paragraph "....if binding update fails...the request MUST > fail with 500..." but I am not sure that 500 is a good choice. No, that status code is correct. Its the same error response used when you receive a request on a dialog with a CSeq lower than the current one. From line 2033 in bis09 PDF, a 500 is returned there too. You want a 500, since the client can retry the request and it can work the second time (since the CSeq will change as a natural consequence of retrying the request). Given that the error code is correct, do you still find it confusing to have the two paragraphs connected? > > -- > > Yet anothet thing, which Jan pointed out, is that handling of > out-or-order in lines 1738-40 also includes retransmissions (CSeq and > CallID in request and bindings equal). Retransmissions would have already been handled in the transaction layer. Thus, a totally new transaction with the same call-id/cseq is indeed an error. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 16:45:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04363 for ; Tue, 18 Jun 2002 16:45:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13325 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 16:45:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11616; Tue, 18 Jun 2002 16:24:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11584 for ; Tue, 18 Jun 2002 16:24:41 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03592 for ; Tue, 18 Jun 2002 16:24:01 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IKO5YH016791; Tue, 18 Jun 2002 16:24:05 -0400 (EDT) Message-ID: <3D0F96E4.80301@dynamicsoft.com> Date: Tue, 18 Jun 2002 16:24:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Vijay K. Gurbani" , sip Subject: Re: [Sip] Reason version 01 References: <3CE36C71.7B160EA8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hi Vijay, > > Good point. I forgot completely about updating the references. > > I believe that Jonathan wants to wait for a while before advancing the > 155 stuff to RFC (Jonathan, can you confirm this point?). Yes. I am not confident it is correct. > But we have to > advance 3pcc and Reason together. > > However, I do not think we have any problem. The reason draft can speak > about 155 responses without referencing any RFC. It is enough that the > 155 status code is registered wherever we are registering status codes > (is it already in IANA or we still have a temporary repository?). > > Does anybiody see a problem with this approach? I think its fine to be vague, or to simply strike the references completely from reason, so that the herfp draft defines the usage of Reason in 155. However, the change you suggest above was not made, and it seems reason-01 has been approved..... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 16:53:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04579 for ; Tue, 18 Jun 2002 16:53:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13691 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 16:53:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12674; Tue, 18 Jun 2002 16:35:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10686 for ; Tue, 18 Jun 2002 16:03:29 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02910 for ; Tue, 18 Jun 2002 16:02:49 -0400 (EDT) Received: from jku2.iptel.org (port-212-202-171-58.reverse.qdsl-home.de [212.202.171.58]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g5IK2hC12106; Tue, 18 Jun 2002 22:02:43 +0200 Message-Id: <5.1.0.14.0.20020618203638.02260e80@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 21:59:14 +0200 To: Jonathan Rosenberg From: Jiri Kuthan Subject: Re: [Sip] REGISTER Processing Cc: sip@ietf.org, Jan Janak In-Reply-To: <3D0F7A11.3050208@dynamicsoft.com> References: <5.1.0.14.0.20020423235232.030a2ec8@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org inline At 08:21 PM 6/18/2002, Jonathan Rosenberg wrote: >sorry for the immensely late response... combing the list now for old >bis issues: > >Jiri Kuthan wrote: >> There seems to be insufficient guidance in bis-09 on usage of Call-ID >> in REGISTERs. The only thing which I found there is in 10.2.4: >> >> "A UA SHOULD use the same Call-ID for all registrations during a >> single boot cycle. " >> >> I think that does NOT require Call-ID to change across reboots. > >Correct. > > >> UAs with no memory are not explicitely mandated to change Call-ID >> (ignoring that bis asks to deny REGISTERs with Call-ID== and CSeq <= >> values in registrar's bindings). If the UACs actually do not change >> Call-ID, REGISTERs after reboots with low CSeq will be ignored. > >Right, which is way the guidelines for CSeq say: > >> CSeq: The CSeq value guarantees proper ordering of REGISTER requests. >> A UA MUST increment the CSeq value by one for each REGISTER >> request with the same Call-ID. > >This would seem to explicitly address the issue, no? Agreed -- I missed that. >> Which actually happened during two tests in SIPIt. >> >> Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if not >> doing so does not break things, which is not the case here. > >I think SHOULD is sufficient so long as you also properly follow the MUST strength requirement on CSeq incremeting. Yes. > >> Other confusing thing is which SIP reply a request failure for >> out-of-order REGISTERs in line 1740 implies. I could connect it to >> the next paragraph "....if binding update fails...the request MUST >> fail with 500..." but I am not sure that 500 is a good choice. > >No, that status code is correct. Its the same error response used when you receive a request on a dialog with a CSeq lower than the current one. From line 2033 in bis09 PDF, a 500 is returned there too. You want a 500, since the client can retry the request and it can work the second time (since the CSeq will change as a natural consequence of retrying the request). I'm not particularly happy about 5xx in neither context. 5xx stands for server error ("the server failed to fulfill an apparently valid request"), whereas this sounds to me much more like "4xx - client error -- the request contains bad syntax or cannot be fulfilled at server". I don't think there is a big interop issue for UACs, it is primarily of diagnostic value. I'm a fan of rich and correct diagnostic info, which makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS. My preference is "4xx out-of-order". >> Yet anothet thing, which Jan pointed out, is that handling of >> out-or-order in lines 1738-40 also includes retransmissions (CSeq and >> CallID in request and bindings equal). > >Retransmissions would have already been handled in the transaction layer. Thus, a totally new transaction with the same call-id/cseq is indeed an error. UAs, including registrars, may be stateless. Such registrars would be then forced by spec to send an error on retransmission, resulting in a UAC believing it is not registered. As long as contacts are unchanged, I'm willing to send 200 to request with current CSeq. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 16:54:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04610 for ; Tue, 18 Jun 2002 16:54:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13727 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 16:54:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12465; Tue, 18 Jun 2002 16:32:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12440 for ; Tue, 18 Jun 2002 16:32:31 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03922 for ; Tue, 18 Jun 2002 16:31:51 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IKVDYH016794; Tue, 18 Jun 2002 16:31:14 -0400 (EDT) Message-ID: <3D0F9890.7090804@dynamicsoft.com> Date: Tue, 18 Jun 2002 16:31:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: salreyca@teleco.upv.es CC: sip@ietf.org Subject: Re: [Sip] via header References: <39228BD5.13877.1515E3BE@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Salva Rey Calatayud wrote: > Hi, > > I have a doubt regarding how the Via header is completed at > the transport layer. > > Should the transport indicated in the sent-protocol parameter > be modified, if the request was solicited to be sent on UDP, and > the transport layer decided to send it on TCP? Yes. From 8.1.1.7: Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). 1077 That includes any reason that a transport is selected, not just the DNS procedures in 4. That said, the section in transport would be clearer if it explicitly pointed this out, as it does appear to be a source of confusion. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 16:55:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04698 for ; Tue, 18 Jun 2002 16:55:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13839 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 16:55:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12910; Tue, 18 Jun 2002 16:39:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12878 for ; Tue, 18 Jun 2002 16:39:19 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04063 for ; Tue, 18 Jun 2002 16:38:39 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IKckYH016801; Tue, 18 Jun 2002 16:38:46 -0400 (EDT) Message-ID: <3D0F9A54.800@dynamicsoft.com> Date: Tue, 18 Jun 2002 16:38:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CE53421.1050903@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > [...] > >>>Looking at Figure 5, it seems that UAC will also benefit from a >>>dynamic transaction timeout window. Furthermore, why set Timer B in >>>the "Calling" state? If UDP is being used, we will know on the second >>>retx that a UAS does not exist (if the socket is bind()'ed to the UAS >> > -- > >>>funny, this is missing from -09bis). If TCP (or TLS, or I believe >> > even > >>>SCTP) is being used, the connection will fail right away. So, a >>>transport error is bound to occur in the "Calling" state if a UAS does >>>not exist. Is it possible to set timer B in the "Proceeding" state >> > and > >>>initalize it to the value of the Expires header (if present, T1*64 if >>>not) and then dynamically updated on provisionals, just like proxies? >> >> >>I'm lost. Timer B handles time outs because of no response whatsoever. > > > OK; let me explain...in Figure 5, Calling state is exited when either of > the following events occur: > > (1) Receipt of a 2xx > (2) Receipt of a 1xx > (3) Timer B fires > (4) Transport error > > In case of UDP, a transport error will occur when the request is retx'd > on a bound socket where a server is not listening. In case of TCP > (TLS/TCP) and SCTP, a transport error will occur as soon as an attempt > is made to establish a connection to an address where a server is not > listening. Control thus always goes to Terminated state in case of a > transport error (event (4)). Control also goes to Terminated state when > a 2xx is received while in Calling state (event (1)). > > So that leaves events (2) and (3) for exiting Calling state. If we > receive a 1xx (event (2)), we transit to Proceeding state as normal and > *then* start Timer B. > > If we do not start Timer B in the Calling state, we are guaranteed to > have exited Calling state either through events (4) (2) or (1). If we > exit Calling state due to event (2), we can *then* start Timer B. This > has the nice side-effect of maintaining a dynamic Timer B (mirroring > Timer C for proxies). But that is not the point of timer B. There is also a "timer C" for UA, but its sufficiently flexible that it can be a matter of local implementation. You can give up at any time. > > BTW, in -09bis I notice that binding UDP sockets to destination > addresses (so that a ECONNREFUSED is generated on a retx) has been > taken out. Was this intentional or a an error. What I describe > above depends on a bound UDP socket. Intentional; we are not writing an implementors guide. We tried to remove as much as possible (and still look at the size...) > > Also note that even if a UAC core does put an "Expires: 60" in a > request, the client transaction will still time out in 32 s (T1*64) as > per -09bis. Not with the current definition of timer B. It should get an immediate 1xx and thus move into proceeding. Suggested change to the sentence on line 3274 (-09bis, > PDF): > "For any transport, the client transaction MUST start timer B > with a value of the Expires header, if present, or 64*T1 if not." I disagree. Timer B is not an application layer timer. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 16:56:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04743 for ; Tue, 18 Jun 2002 16:56:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13881 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 16:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12658; Tue, 18 Jun 2002 16:35:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18408 for ; Mon, 17 Jun 2002 18:06:47 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-219-168-146.dsl.rcsntx.swbell.net [64.219.168.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21469 for ; Mon, 17 Jun 2002 18:06:09 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5HLg9V08375; Mon, 17 Jun 2002 16:42:10 -0500 Message-ID: <3D0E64A8.A9C2EB3C@infravast.com> Date: Mon, 17 Jun 2002 17:37:28 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'matrix@dasecurenetworks.com'" , jh@lohi.eng.song.fi, Michael Thomas , "Peterson, Jon" , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Asserted-Identity - new hint proposal References: <9BF66EBF6BEFD942915B4D4D45C051F377A1F9@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Chris, I think you're missing a major point here: > > The "long-term" solution isn't incompatible with the PSTN > model. It's just *also* applicable to the Internet at large > and models with multiple domains involved. > > The short-term solution is applicable only to an idealized > single-domain-of-trust model that doesn't even exist in > the PSTN today. I can agree with that, to the extent of my experience with the PSTN. I merely wanted to emphasize that the use of this mechanism (NAI) is applicable to other architectures than just 3GPP, as had been argued back and forth for some time now, and that the requirement wasnt a re-creation of the PSTN or a by-product of the PSTN (Since some of the mechanisms argued about often are blamed on the PSTN from what I can see), or a mechanism that benefits only 3GPP, rather that it is a communications problem related to security, laws and business policies, etc, for all archtectures planning on offering communitations, of any kind, at large. Thanks for your response. Chris > > /a > > > -----Original Message----- > > From: Chris Martin [mailto:chris@infravast.com] > > Sent: Wednesday, June 12, 2002 22:09 > > To: jh@lohi.eng.song.fi > > Cc: Michael Thomas; Peterson, Jon; Cullen Jennings; sip@ietf.org > > Subject: Re: [Sip] Asserted-Identity - new hint proposal > > > > > > jh@lohi.eng.song.fi wrote: > > > > > > Michael Thomas writes: > > > > > > > What happened to the mindset of doing the > > > > necessary engineering to generalize what the PSTN > > > > did badly instead of slavishly reproducing its > > > > misfeatures, bug for bug? > > > > > > this is exactly what 3gpp is doing. they are trying to re-implement > > > their existing walled garden with new set of protocols (ip, > > sip, radius, > > > etc). ietf should have no part in such a madness. > > > > I cant speak for 3GPP (I dont know enough about it) but walled gardens > > exist and will continue to exist, out of necessity, for reasons of > > security or lack of resources...yada..yada, within many carrier, > > corporate, and SOHO networks. The concepts that I have seen discussed > > regarding asserted identity, hints, etc....are valid for any or all of > > these infrastructures as well as those that join with one or more > > infrastructures to offer enhancements or share resources. > > Sure maybe the > > names could be worked on but the concepts are valid. > > > > From what I have seen 3GPP is adopting SIP and, just as the enterprise > > and carriers are trying to fit SIP into their infrastructures while > > maintaining the policies that they must enforce in order to meet legal > > and protective requirements, and I have seen some very good > > thoughts and > > opinions pour out into this list that will become a necessity > > for SIP as > > well. I am grateful that the topics have been brought out > > into the open > > for discussion now than later. > > > > It is one thing to not desire the re-invention of the PSTN, but > > legalities and business policies must be met in the real world by the > > entities that will provide the services, whether for profit or not. > > These issues exist in the PSTN world but that does not make them > > products of the PSTN world. It makes them products of the > > communications > > world that must be met by all communications solutions that are > > developed with the goal of attempting to provide the types of > > solutions > > that SIP will be capable of providing now and in the future > > to everyone. > > > > To continue to perform nothing more than name calling because "they" > > dont conform to your way of thinking is ludicrous. All of these > > discussions and attempts to integrate existing architecture (at least > > those based on IP for our requirements) furthers the > > development of SIP > > and aids in the devlopment of new ideas. > > > > I want to hear and read more about this and offer what I can > > when I can, > > and hope you will too. > > > > Chris > > > > > > > > -- juha > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 17:34:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05855 for ; Tue, 18 Jun 2002 17:34:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16580 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 17:35:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15485; Tue, 18 Jun 2002 17:15:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15455 for ; Tue, 18 Jun 2002 17:15:02 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05395 for ; Tue, 18 Jun 2002 17:14:22 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5ILEOYH016818; Tue, 18 Jun 2002 17:14:24 -0400 (EDT) Message-ID: <3D0FA2AD.30908@dynamicsoft.com> Date: Tue, 18 Jun 2002 17:14:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aymeric MOIZARD CC: sip@ietf.org Subject: Re: [Sip] Matching request for server transaction References: <3CEE254A.FAB45662@wellx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Aymeric MOIZARD wrote: > Reading the 17.23 section about the rules used to > match a request, I found a possible issue. > > The spec says: [we must check the via branch, via sent-by > parameter] "and in the case of a CANCEL > request, the method of the request that created > the transaction was also CANCEL. > > In the case where a pending CANCEL is going on and > we are receiving an retransmission of INVITE. The > INVITE will contains the same via branch and sent-by > and is not a CANCEL, so it will match the CANCEL > transaction according the rules defined. (the test > expect us to test the method only for CANCEL request!) You are correct. Good catch. > > I am true if I say that the cseq method must always > be compared and not only for CSeq? I assume you mean "not only for CANCEL?". Almost. The exception is ACK. So, for all requests BUT ACK, the method of the request has to match the method of the request which created the transaction. In the case of ACK, the method of the request that created the transaction has to be INVITE. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 17:44:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06043 for ; Tue, 18 Jun 2002 17:44:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17089 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 17:45:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15655; Tue, 18 Jun 2002 17:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15616 for ; Tue, 18 Jun 2002 17:21:21 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05621 for ; Tue, 18 Jun 2002 17:20:40 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5ILKlYH016822; Tue, 18 Jun 2002 17:20:48 -0400 (EDT) Message-ID: <3D0FA42C.3080302@dynamicsoft.com> Date: Tue, 18 Jun 2002 17:20:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Salva Rey CC: sip@ietf.org Subject: Re: [Sip] transaction layer References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Salva Rey wrote: > Sorry, I posted a very similar question before, the change and addition > are > in between quote marks. > > if sending a response on a server transaction a transport error occurs, > should the "transaction layer" try on all the destinations resolved by > draft-ietf-sip-srv-06.txt (used as reference [4] in draft > rfc-2534bis-09), > before informing the transaction user of the error, "and transitioning > to > the terminated state"? Yes. See section 17.2.4 which says this explicitly. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 17:44:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06065 for ; Tue, 18 Jun 2002 17:44:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17104 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 17:45:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15794; Tue, 18 Jun 2002 17:25:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15763 for ; Tue, 18 Jun 2002 17:25:11 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05705 for ; Tue, 18 Jun 2002 17:24:31 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5ILOdYH016825; Tue, 18 Jun 2002 17:24:39 -0400 (EDT) Message-ID: <3D0FA513.1060600@dynamicsoft.com> Date: Tue, 18 Jun 2002 17:24:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt References: <00c001c208b2$e620b7e0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob, I don't make the policy. I just follow it. See: http://www.rfc-editor.org/policy.html which seems pretty clear to me. -Jonathan R. Bob Penfield wrote: > ----- Original Message ----- > From: "Jonathan Rosenberg" > >>The title needs to have the acronym SIP expanded. > > > I know this is a really minor point, but why does SIP need to be > expanded in > the title? Most other I-Ds and RFCs (besides the base spec of course) > use > the acronym of the protocol in their title. The problem we've had in the > past is that the title did not even include the acronym. Why not require > the > expansion in the abstract? > > cheers, > (-:bob -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 18:15:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06602 for ; Tue, 18 Jun 2002 18:15:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19518 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 18:16:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17988; Tue, 18 Jun 2002 17:58:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17959 for ; Tue, 18 Jun 2002 17:58:18 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06303 for ; Tue, 18 Jun 2002 17:57:37 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5ILvhYH016863; Tue, 18 Jun 2002 17:57:43 -0400 (EDT) Message-ID: <3D0FACD3.6050702@dynamicsoft.com> Date: Tue, 18 Jun 2002 17:57:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.derks@philips.com CC: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-rfc2543bis-09 and the offer/answer model References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit frank.derks@philips.com wrote: > The latest version of the SIP draft contains the following text: > > "The offer/answer model defines restrictions on when offers and answers > can be made. This results in restrictions on where the offers and > answers can appear in SIP messages. In this specification, offers and > answers can only appear in INVITE requests and responses, and ACK. The > usage of offers and answers is further restricted." > > The first sentence states that the offer/answer model defines when > offers > and answers can be made. From draft-ietf-mmusic-sdp-offer-answer-02, it > does not really become clear that this is the case. Which restrictions > are being referred to? Its referring to this paragraph: At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 18:23:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06835 for ; Tue, 18 Jun 2002 18:23:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20164 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 18:24:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18934; Tue, 18 Jun 2002 18:04:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18903 for ; Tue, 18 Jun 2002 18:04:31 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06423 for ; Tue, 18 Jun 2002 18:03:50 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5IM4SA09580; Tue, 18 Jun 2002 18:04:28 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA19395; Tue, 18 Jun 2002 17:04:25 -0500 (CDT) Message-ID: <3D0FAE28.8060108@lucent.com> Date: Tue, 18 Jun 2002 17:03:20 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3CE53421.1050903@lucent.com> <3D0F9A54.800@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] >> Also note that even if a UAC core does put an "Expires: 60" in a >> request, the client transaction will still time out in 32 s (T1*64) as >> per -09bis. > > Not with the current definition of timer B. It should get an immediate > 1xx and thus move into proceeding. But -09bis does not instruct turning Timer B off when "Proceeding" is entered, so presumably Timer B is still ticking away. 32 s after the transaction started, it will be torn down. The UAS, on the other hand, thinks that it has 60 s to generate a final response (since it saw an Expires: 60 in the request), so it is still searching the callee. In fact, Timer B should not be turned off on entering the Proceeding state since without it, a UAC will remain in the Proceeding state if the UAS dies after sending a 1xx. >> Suggested change to the sentence on line 3274 (-09bis, PDF): >> "For any transport, the client transaction MUST start timer B >> with a value of the Expires header, if present, or 64*T1 if not." > > > I disagree. Timer B is not an application layer timer. No, but transaction timeouts should honor the Expires header, right? Otherwise, we should simply say that the Expires header value must be <= (T1*64). Setting Timer B in the Proceeding state and making its value be that of Expires header if present, or 64*T1 if not, makes the state machine more resilient, I think. As my previous email detailed, the "Calling" state is guaranteed to have been egressed due to other events occuring. We can safely start Timer B in the Proceeding state. This enables the state machine to recover even if the UAS crashes after sending a 1xx. While I agree whole heartedly with you about not turning -09bis into a programming manual, to the extent that we can make the state machine unambiguous, we should. Best regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 18:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06940 for ; Tue, 18 Jun 2002 18:27:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20404 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 18:28:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18683; Tue, 18 Jun 2002 18:01:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18644 for ; Tue, 18 Jun 2002 18:01:16 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06379 for ; Tue, 18 Jun 2002 18:00:36 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IM0bYH016866; Tue, 18 Jun 2002 18:00:38 -0400 (EDT) Message-ID: <3D0FAD81.8070605@dynamicsoft.com> Date: Tue, 18 Jun 2002 18:00:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <3D09D66A.D1B62EC5@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer is correct, although I am not sure this is as it should be. It is allowed for a UA to JUST be a UAC, and have no UAS capabilities. There are legitimate uses cases for that, I suppose, although its not common I would expect. In such a case, the UA would support no methods. -Jonathan R. Christer Holmberg wrote: > Hi, > > >>Is an Allow-header allowed to be empty? >> >>The syntax in bis-09 suggests that this is not allowed. >> >>Allow = "Allow" HCOLON Method *(COMMA Method) >> >>If it is allowed, does it mean that the UAS does not support any > > methods? > > It is NOT allowed. > > And, if there is no header at all, it means that the UA doesn't indicate > which methods it supports (chapter 20.5 in bis-9). > > Regards, > > Christer Holmberg > Ericsson Finland > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 18 18:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07319 for ; Tue, 18 Jun 2002 18:45:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21785 for sip-archive@odin.ietf.org; Tue, 18 Jun 2002 18:45:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20068; Tue, 18 Jun 2002 18:23:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20041 for ; Tue, 18 Jun 2002 18:23:05 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06783 for ; Tue, 18 Jun 2002 18:22:24 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.125]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5IMMPYH016871; Tue, 18 Jun 2002 18:22:25 -0400 (EDT) Message-ID: <3D0FB29D.7070505@dynamicsoft.com> Date: Tue, 18 Jun 2002 18:22:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: Mark Watson , "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: >>From the point of view of the UAC (assuming an SDP offer in the INVITE >>for simplicity), then if >>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in >>183, 180 , UPDATE, 200 OK to UPDATE etc.), and >>(ii) a=sendrecv or a=sendonly in this answer, and >>(iii) any manyfolks pre-conditions have been met (i.e. this could be >>an answer at the end of several offer/answer exchanges negotiating and >>updating preconditions) >> >>then there is Early Media, and the UAC SHOULD (?) play this to the >>caller. >> > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > My understanding was, that if you get a 180, then you will generate > local ringback until you receive RTP (or whatever else you may have > negotiated in your media stream(s)), whereas with 183, you do not > generate local ringback. Egads, this is all getting out of hand. First off, the 180 is an indication from the UAS that the called party is being "alerted" for some definition of alerted (screen pop, ring, etc.). How that information is used at the UAC is a matter of user interface. Last I checked, SIP didn't specify user interfaces. It merely says that you can do the obvious thing, which is play a local ringback. >>If there is no Early Media, or if the Early Media is on hold (SDP >>answer contains a=recvonly or a=inactive) AND a 180 has been received, >>then the UAC SHOULD (?) play local ringing. >> >>So, if the UAS does not want to generate Early Media then it has the >>following choices: >>(a) do not supply SDP answer until actual call Answer, or >>(b) supply early SDP answer with a=recvonly or a=inactive >> > > > Again, I thought there was a distinction between 180 and 183 here ? The offer/answer exchange defines the flow of media in a session, and that is irrespective of the response code it appears in. The response code provides status updates about the UAS. That is orthogonal to the offer/answer model. > > > >>Now, (b) is not much use to a UAS trying to negotiate media with >>pre-conditions, since the direction attribute in this exchange will >>affect the resources that are reserved, and therefore needs to reflect >>the requirements of the eventual session. > > > I don't think that's necessary, since manyfolks has its own direction > attributes independent of the media stream direction attributes. Thus > you could specify an inactive stream and require sendrevc reservation > for it. What is not clear however, is how a UAC can negotiate > bidirectional codec support without accepting early media in both > directions. You are making a distinction between early media and regular media, when there isn't and shouldn't be one. This was the real idea behind the unify model. If I offer you to receive media, that means, I am willing to receive media, period. >>So, I can only hope that all UAS developers implementing Manyfolks are >>aware of the need to put the media on hold as soon as the >>pre-conditions have been met (unless thay are going to generate real >>Eraly Media). >> >>A solution to this would be a way of explicitly indicating at the >>SIP/SDP layer that a media stream, although not on hold, was >>'provisional', or did not contain actual media yet. I did not think >>the Content-Disposition in Manyfolks has formally been given this >>meaning. If it has, I'm not sure what 'undoes' this 'provisional' >>status - it shouldn't be the 200 OK to the INVITE because the whole >>point of UPDATE was to separate media changes from session changes - >>so it would have to be another offer/answer without the special >>Content-Disposition. But then are people aware they need to do this at >>Answer time ? >> > > > We used to have a Content-Dispostion of "precondition" in manyfolks to > make a distinction here, but it got removed for some reason. For good reason. The reason was that manyfolks was trying to be "special" and outside of the general offer/answer model. That is no longer the case. By making it all fall under the general offer/answer model, a lot of things became easy (like integration with 3pcc), since we only had one model, rather than a dizzying number of them (once you added in early media too, which was also special for a while. No longer). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 01:08:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14795 for ; Wed, 19 Jun 2002 01:08:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA12985 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 01:09:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08368; Wed, 19 Jun 2002 00:45:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08339 for ; Wed, 19 Jun 2002 00:45:56 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13990 for ; Wed, 19 Jun 2002 00:45:15 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J4jNYH016980; Wed, 19 Jun 2002 00:45:25 -0400 (EDT) Message-ID: <3D100C60.40101@dynamicsoft.com> Date: Wed, 19 Jun 2002 00:45:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nirmalya@icr.a-star.edu.sg CC: sip@ietf.org Subject: Re: [Sip] REGISTER Processing References: <000601c21748$b1ea4640$810210ac@cwc.nus.edu.sg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Nirmalya Ghosh wrote: > Hi Jonathan, > I have a question regarding what happens when a user wants to fetch its > current bindings (maybe after rebooting his/her PC). I understand that > the Call-ID need not be the same across reboots, but what I am not sure > of is whether for a dummy REGISTER request (containing no Contact or > Expires) sent to fetch its bindings after rebooting, would/should get a > 500 response from the registrar just because its CSeq does not match > that of existing bindings. No. Follow the processing steps in section 10.3. The registrar would come to step 6, at which point it has authenticated the request and verified that the AOR in the To is valid for the domain. If there is no contact in the REGISTER (in the case of fetch), step 6 instructs the registrar to go to the last step. The last step, 8, has the registrar returning the current bindings in the 200 OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 01:28:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15200 for ; Wed, 19 Jun 2002 01:28:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16633 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 01:29:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10469; Wed, 19 Jun 2002 01:06:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10379 for ; Wed, 19 Jun 2002 01:06:13 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14725 for ; Wed, 19 Jun 2002 01:05:32 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5J565xc014316; Wed, 19 Jun 2002 01:06:06 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-149-031.arcor-ip.net [212.144.149.31]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5J55xpf003223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jun 2002 01:06:03 -0400 (EDT) Message-ID: <3D101112.6030203@cs.columbia.edu> Date: Wed, 19 Jun 2002 01:05:22 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Christer Holmberg , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <3D09D66A.D1B62EC5@lmf.ericsson.se> <3D0FAD81.8070605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There may well be legitimate cases for your example, such as one-time (anonymous) identifiers that can't be called back or "don't call us, we'll call you" SIP phones operated by movie moguls. In general, unless there's a really strong reason, the empty set should always be legal for these types of headers. Jonathan Rosenberg wrote: > Christer is correct, although I am not sure this is as it should be. It > is allowed for a UA to JUST be a UAC, and have no UAS capabilities. > There are legitimate uses cases for that, I suppose, although its not > common I would expect. In such a case, the UA would support no methods. > > -Jonathan R. > > Christer Holmberg wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 01:50:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15542 for ; Wed, 19 Jun 2002 01:50:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA17957 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 01:51:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17217; Wed, 19 Jun 2002 01:31:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17191 for ; Wed, 19 Jun 2002 01:31:37 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15240 for ; Wed, 19 Jun 2002 01:30:56 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J5V3YH017034; Wed, 19 Jun 2002 01:31:04 -0400 (EDT) Message-ID: <3D101715.1020801@dynamicsoft.com> Date: Wed, 19 Jun 2002 01:31:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: SIP LIST Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling References: <3D0FAE28.8060108@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > [...] > >>>Also note that even if a UAC core does put an "Expires: 60" in a >>>request, the client transaction will still time out in 32 s (T1*64) >> > as > >>>per -09bis. >> >>Not with the current definition of timer B. It should get an immediate > > >>1xx and thus move into proceeding. > > > But -09bis does not instruct turning Timer B off when "Proceeding" is > entered, so presumably Timer B is still ticking away. No, it is not. The spec doesn't tell you to "turn it off", but no state transitions are defined if it fires outside of the calling state. So, your implementation can turn it off if it likes. Note that it doesn't instruct you to ever turn off any of the other timers either. > In fact, Timer B should not be turned off on entering the Proceeding > state since without it, a UAC will remain in the Proceeding state if > the UAS dies after sending a 1xx. The UAC decides how long the phone should ring. Irregardless of what the UAS does, it will give up (or the proxies will, based on timer C) resulting in termination of the transaction. >>> Suggested change to the sentence on line 3274 (-09bis, PDF): >>> "For any transport, the client transaction MUST start timer B >>> with a value of the Expires header, if present, or 64*T1 if >>> not." >> >>I disagree. Timer B is not an application layer timer. > > > No, but transaction timeouts should honor the Expires header, right? > Otherwise, we should simply say that the Expires header value must be > <= (T1*64). No. This is based on your misinterpretation of timer B above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:01:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17664 for ; Wed, 19 Jun 2002 02:01:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18895 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17834; Wed, 19 Jun 2002 01:47:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17695 for ; Wed, 19 Jun 2002 01:47:39 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15478 for ; Wed, 19 Jun 2002 01:46:57 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5J5lQrU018687; Wed, 19 Jun 2002 07:47:26 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5J5lQa9021183; Wed, 19 Jun 2002 08:47:26 +0300 (EET DST) Message-ID: <3D101AEF.2C1EB915@lmf.ericsson.se> Date: Wed, 19 Jun 2002 08:47:27 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Flemming Andreasen , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > Flemming Andreasen wrote: > >>From the point of view of the UAC (assuming an SDP offer in the INVITE > >>for simplicity), then if > >>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > >>183, 180 , UPDATE, 200 OK to UPDATE etc.), and > >>(ii) a=sendrecv or a=sendonly in this answer, and > >>(iii) any manyfolks pre-conditions have been met (i.e. this could be > >>an answer at the end of several offer/answer exchanges negotiating and > >>updating preconditions) > >> > >>then there is Early Media, and the UAC SHOULD (?) play this to the > >>caller. > >> > > > > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > > My understanding was, that if you get a 180, then you will generate > > local ringback until you receive RTP (or whatever else you may have > > negotiated in your media stream(s)), whereas with 183, you do not > > generate local ringback. > > Egads, this is all getting out of hand. > > First off, the 180 is an indication from the UAS that the called party > is being "alerted" for some definition of alerted (screen pop, ring, > etc.). How that information is used at the UAC is a matter of user > interface. Last I checked, SIP didn't specify user interfaces. It merely > says that you can do the obvious thing, which is play a local ringback. I'm not sure it's that easy eg when we talk about a SIP/PSTN gateway, because it's not only about how the GW informs the caller but also how the MG handles the media. Chapter 7.2.3 of draft-ietf-sipping-isup-02.txt says: "If the reception of a `180 Ringing' response without media description, the MG generates the ringback tone to be heard by the caller. If the MGC receives any 1xx response (except 100) with a session description present for media setup, it sets up the session being described. The call progress media (e.g. ringback tone or announcement) is generated by an entity downstream (in the SIP network or by a PSTN exchange in SIP bridging situations)." As a general rule, for a basic SIP implementation, I assume this works fine. My original issue, however, was if this really works in more advanced scenarios. There may be situations, due to offer/answer negoatiations, manyfolks, and/or PRACK for which we must include an SDP in a 180 response, which really hasn't anything to do with the ringback. My other issue was, what happens if we have received a 183 with SDP, ie early-media may be established, and then we receive a 180 without SDP? Again, for normal UACs this may not be a big problem, but for a GW it may. The GW doesn't know if the UAS will stop transmitting early-media, and wants to GW to generate a local ringback tone, or if the UAS will continue transmitting early-media, and only wants to GW to indicate that the called party has been alerted. Regards, Christer Holmberg Ericsson Finland > > > >>If there is no Early Media, or if the Early Media is on hold (SDP > >>answer contains a=recvonly or a=inactive) AND a 180 has been received, > >>then the UAC SHOULD (?) play local ringing. > >> > >>So, if the UAS does not want to generate Early Media then it has the > >>following choices: > >>(a) do not supply SDP answer until actual call Answer, or > >>(b) supply early SDP answer with a=recvonly or a=inactive > >> > > > > > > Again, I thought there was a distinction between 180 and 183 here ? > > The offer/answer exchange defines the flow of media in a session, and > that is irrespective of the response code it appears in. The response > code provides status updates about the UAS. That is orthogonal to the > offer/answer model. > > > > > > > > >>Now, (b) is not much use to a UAS trying to negotiate media with > >>pre-conditions, since the direction attribute in this exchange will > >>affect the resources that are reserved, and therefore needs to reflect > >>the requirements of the eventual session. > > > > > > I don't think that's necessary, since manyfolks has its own direction > > attributes independent of the media stream direction attributes. Thus > > you could specify an inactive stream and require sendrevc reservation > > for it. What is not clear however, is how a UAC can negotiate > > bidirectional codec support without accepting early media in both > > directions. > > You are making a distinction between early media and regular media, when > there isn't and shouldn't be one. This was the real idea behind the > unify model. If I offer you to receive media, that means, I am willing > to receive media, period. > > >>So, I can only hope that all UAS developers implementing Manyfolks are > >>aware of the need to put the media on hold as soon as the > >>pre-conditions have been met (unless thay are going to generate real > >>Eraly Media). > >> > >>A solution to this would be a way of explicitly indicating at the > >>SIP/SDP layer that a media stream, although not on hold, was > >>'provisional', or did not contain actual media yet. I did not think > >>the Content-Disposition in Manyfolks has formally been given this > >>meaning. If it has, I'm not sure what 'undoes' this 'provisional' > >>status - it shouldn't be the 200 OK to the INVITE because the whole > >>point of UPDATE was to separate media changes from session changes - > >>so it would have to be another offer/answer without the special > >>Content-Disposition. But then are people aware they need to do this at > >>Answer time ? > >> > > > > > > We used to have a Content-Dispostion of "precondition" in manyfolks to > > make a distinction here, but it got removed for some reason. > > For good reason. The reason was that manyfolks was trying to be > "special" and outside of the general offer/answer model. That is no > longer the case. By making it all fall under the general offer/answer > model, a lot of things became easy (like integration with 3pcc), since > we only had one model, rather than a dizzying number of them (once you > added in early media too, which was also special for a while. No longer). > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:03:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20722 for ; Wed, 19 Jun 2002 02:03:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19070 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:04:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17569; Wed, 19 Jun 2002 01:42:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17542 for ; Wed, 19 Jun 2002 01:42:22 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15424 for ; Wed, 19 Jun 2002 01:41:41 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J5fnYH017053; Wed, 19 Jun 2002 01:41:49 -0400 (EDT) Message-ID: <3D10199A.7010402@dynamicsoft.com> Date: Wed, 19 Jun 2002 01:41:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org, Jan Janak Subject: Re: [Sip] REGISTER Processing References: <5.1.0.14.0.20020618203638.02260e80@iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Jiri Kuthan wrote: >>>Other confusing thing is which SIP reply a request failure for >>>out-of-order REGISTERs in line 1740 implies. I could connect it to >>>the next paragraph "....if binding update fails...the request MUST >>>fail with 500..." but I am not sure that 500 is a good choice. >> >>No, that status code is correct. Its the same error response used when >> you receive a request on a dialog with a CSeq lower than the current >> one. From line 2033 in bis09 PDF, a 500 is returned there too. You want >> a 500, since the client can retry the request and it can work the second >> time (since the CSeq will change as a natural consequence of retrying >> the request). > > I'm not particularly happy about 5xx in neither context. 5xx stands for > server error > ("the server failed to fulfill an apparently valid request"), whereas > this sounds to > me much more like "4xx - client error -- the request contains bad syntax > or cannot > be fulfilled at server". I don't think there is a big interop issue for > UACs, it is > primarily of diagnostic value. I'm a fan of rich and correct diagnostic > info, which > makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS. > My preference > is "4xx out-of-order". Its not about finger-pointing, its about taking the proper actions upon getting the error. Generally, 5xx is supposed to mean, "you can retry this request later on without change, and it might succeed". The 4xx responses indicated that the client needs to change the request in some way, and if it can't, there is no point in trying again. In this case here, the client CAN indeed simply retry the request again later on, without change (of course, things like the cseq, call-id, via do change as per normal operation), and it can work. Thats why we used 500. > > >>>Yet anothet thing, which Jan pointed out, is that handling of >>>out-or-order in lines 1738-40 also includes retransmissions (CSeq and >>>CallID in request and bindings equal). >> >>Retransmissions would have already been handled in the transaction >> layer. Thus, a totally new transaction with the same call-id/cseq is >> indeed an error. > > UAs, including registrars, may be stateless. The notion of stateless UAS is really for unauthenticated requests. Its not a general thing. Indeed, in the case of REGISTER, there are other problems. Each retransmission would effectively update the expiration time of the contact. Eaech response would therefore have a different expiration time in the contact. As a result, the "retransmits" of each response are different, and the UAC would need to use the last one in order to obtain the proper expiration time. Not a big issue, but its not supposed to work that way. I would argue that this points to a need for clarification in 8.2.7 of additional requirements on stateless UAS; namely, a UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:05:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22666 for ; Wed, 19 Jun 2002 02:05:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19154 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:05:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18134; Wed, 19 Jun 2002 01:54:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18093 for ; Wed, 19 Jun 2002 01:54:46 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15600 for ; Wed, 19 Jun 2002 01:54:05 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J5sCYH017072; Wed, 19 Jun 2002 01:54:12 -0400 (EDT) Message-ID: <3D101C81.3040104@dynamicsoft.com> Date: Wed, 19 Jun 2002 01:54:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.derks@philips.com CC: sip@ietf.org Subject: Re: [Sip] Timer D in the INVITE client transaction MUST inform the TU when it fires???? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit frank.derks@philips.com wrote: > 17.1.12 (lines 3312, 3313) states: > > "If timer D fires while the client transaction is in the "Completed" > state, > the client transaction MUST move to the terminated state, and it MUST > inform the TU of the timeout." > > This does not apply to the cases when timers I, J, K fire in the other > types > of transactions. Moreover, I do not think that the above statement for > timer > D is correct: there is no purpose in informing the transaction user. The > > sentence should therefore be removed. I agree. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:07:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24470 for ; Wed, 19 Jun 2002 02:07:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19229 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18002; Wed, 19 Jun 2002 01:52:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17972 for ; Wed, 19 Jun 2002 01:52:17 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15560 for ; Wed, 19 Jun 2002 01:51:36 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5J5qCrU019327; Wed, 19 Jun 2002 07:52:12 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5J5qBa9021439; Wed, 19 Jun 2002 08:52:11 +0300 (EET DST) Message-ID: <3D101C0C.60F8180@lmf.ericsson.se> Date: Wed, 19 Jun 2002 08:52:13 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne , Jonathan Rosenberg , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <3D09D66A.D1B62EC5@lmf.ericsson.se> <3D0FAD81.8070605@dynamicsoft.com> <3D101112.6030203@cs.columbia.edu> <3D101BB3.C350C3A9@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit To have a look at the HEADERS, that is... Christer Holmberg Ericsson Finland > Hi, > > Would it be a good idea to have a look at the heards, and see for which > headers an empty value (like Allow) really has a specific meaning, and define > that specific meaning? Also, for those headers the ABNF should also be > changed to allow that. > > Regards, > > Christer Holmberg > Ericsson Finland > > > There may well be legitimate cases for your example, such as one-time > > (anonymous) identifiers that can't be called back or "don't call us, > > we'll call you" SIP phones operated by movie moguls. In general, unless > > there's a really strong reason, the empty set should always be legal for > > these types of headers. > > > > Jonathan Rosenberg wrote: > > > Christer is correct, although I am not sure this is as it should be. It > > > is allowed for a UA to JUST be a UAC, and have no UAS capabilities. > > > There are legitimate uses cases for that, I suppose, although its not > > > common I would expect. In such a case, the UA would support no methods. > > > > > > -Jonathan R. > > > > > > Christer Holmberg wrote: > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:08:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24488 for ; Wed, 19 Jun 2002 02:08:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19243 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17942; Wed, 19 Jun 2002 01:50:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17910 for ; Wed, 19 Jun 2002 01:50:48 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15537 for ; Wed, 19 Jun 2002 01:50:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5J5ogRb029263; Wed, 19 Jun 2002 07:50:42 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5J5oga9021237; Wed, 19 Jun 2002 08:50:42 +0300 (EET DST) Message-ID: <3D101BB3.C350C3A9@lmf.ericsson.se> Date: Wed, 19 Jun 2002 08:50:43 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <3D09D66A.D1B62EC5@lmf.ericsson.se> <3D0FAD81.8070605@dynamicsoft.com> <3D101112.6030203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Would it be a good idea to have a look at the heards, and see for which headers an empty value (like Allow) really has a specific meaning, and define that specific meaning? Also, for those headers the ABNF should also be changed to allow that. Regards, Christer Holmberg Ericsson Finland > There may well be legitimate cases for your example, such as one-time > (anonymous) identifiers that can't be called back or "don't call us, > we'll call you" SIP phones operated by movie moguls. In general, unless > there's a really strong reason, the empty set should always be legal for > these types of headers. > > Jonathan Rosenberg wrote: > > Christer is correct, although I am not sure this is as it should be. It > > is allowed for a UA to JUST be a UAC, and have no UAS capabilities. > > There are legitimate uses cases for that, I suppose, although its not > > common I would expect. In such a case, the UA would support no methods. > > > > -Jonathan R. > > > > Christer Holmberg wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:13:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24561 for ; Wed, 19 Jun 2002 02:13:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19406 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:14:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18980; Wed, 19 Jun 2002 02:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18915 for ; Wed, 19 Jun 2002 02:02:30 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18280; Wed, 19 Jun 2002 02:01:49 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J61MYH017075; Wed, 19 Jun 2002 02:01:23 -0400 (EDT) Message-ID: <3D101E32.6040606@dynamicsoft.com> Date: Wed, 19 Jun 2002 02:01:22 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , rohc References: <3CD10F64.D62B1E78@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit more old email. So sue me. Responses inline: Gonzalo Camarillo wrote: > Jonathan, >>> A proxy performing Record-Route inspects the Record-Route and the >>> Contact header fields in the response. It looks for the URI of >> the >>> next upstream (closer to the user agent client) hop in the route >> set. >>> If this URI contains the parameter comp=sigcomp, the proxy SHOULD >>add >>> comp=sigcomp to its entry in the Record-Route header field. >> >>Why? If the upstream element doesn't support this extension, the >>sigcomp >>parameter is ignored, and the message is sent uncompressed. Thats what >>you want. The decision about whether to insert a URI with the comp >>parameter should be entirely a local one. > > > This covers the following scenario: > > UAC----P1-----P2-----UAS > > The UAC sends an INITE to UAS. P2 records route, but P1 does not. > When the 200 OK for the INVITE reaches P2, the contact and RR header > fields will look like this: > > Contact: UAS@domain.com;comp=sigcomp > RR: P2 > > If P2 does not add comp=sigcomp to his entry in the RR, UAC will be able > to receive compressed traffic (the contact has comp=sigcomp), but will > be unable to send compress traffic (the RR entry for P2 does not have > it). Why doesn't it? If a proxy is sigcomp enabled, it should have record-routed with sigcomp parameter in the first place. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:34:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09070 for ; Wed, 19 Jun 2002 02:34:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03317 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:34:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02370; Wed, 19 Jun 2002 02:19:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02340 for ; Wed, 19 Jun 2002 02:19:25 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28498 for ; Wed, 19 Jun 2002 02:18:42 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5J6JExc018705; Wed, 19 Jun 2002 02:19:14 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-150-172.arcor-ip.net [212.144.150.172]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5J6J8pf004999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jun 2002 02:19:12 -0400 (EDT) Message-ID: <3D102237.30505@cs.columbia.edu> Date: Wed, 19 Jun 2002 02:18:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Jonathan Rosenberg , hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] Empty Allow header References: <3D09D66A.D1B62EC5@lmf.ericsson.se> <3D0FAD81.8070605@dynamicsoft.com> <3D101112.6030203@cs.columbia.edu> <3D101BB3.C350C3A9@lmf.ericsson.se> <3D101C0C.60F8180@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit From a quick inspection, the candidate headers are at least Via: empty list doesn't make sense Allow-*: debatable, probably similar to "Allow" *-Info: harmless, probably equivalent to no header Contact: not sure what that would mean - in an INVITE (where Contact is 'm') would this occur for a UAC-only UA? This is a bit of a stretch, but Christer Holmberg wrote: > To have a look at the HEADERS, that is... > > Christer Holmberg > Ericsson Finland > > >>Hi, >> >>Would it be a good idea to have a look at the heards, and see for which >>headers an empty value (like Allow) really has a specific meaning, and define >>that specific meaning? Also, for those headers the ABNF should also be >>changed to allow that. >> >>Regards, >> >>Christer Holmberg >>Ericsson Finland >> >> >>>There may well be legitimate cases for your example, such as one-time >>>(anonymous) identifiers that can't be called back or "don't call us, >>>we'll call you" SIP phones operated by movie moguls. In general, unless >>>there's a really strong reason, the empty set should always be legal for >>>these types of headers. >>> >>>Jonathan Rosenberg wrote: >>> >>>>Christer is correct, although I am not sure this is as it should be. It >>>>is allowed for a UA to JUST be a UAC, and have no UAS capabilities. >>>>There are legitimate uses cases for that, I suppose, although its not >>>>common I would expect. In such a case, the UA would support no methods. >>>> >>>>-Jonathan R. >>>> >>>>Christer Holmberg wrote: >>> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:36:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09104 for ; Wed, 19 Jun 2002 02:36:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03360 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:36:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02514; Wed, 19 Jun 2002 02:24:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02484 for ; Wed, 19 Jun 2002 02:24:36 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05349 for ; Wed, 19 Jun 2002 02:23:55 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J6NdYH017080; Wed, 19 Jun 2002 02:23:39 -0400 (EDT) Message-ID: <3D10236A.3030300@dynamicsoft.com> Date: Wed, 19 Jun 2002 02:23:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Paulsamy CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Was the Translate heade used? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline. Victor Paulsamy wrote: > Jonathan Rosenberg wrote: > >>Victor Paulsamy wrote: >> >>>In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph >>> last >>>but >>>one reads, "... From this 200 OK, the STUN agent knows whether or >>>not >>>the >>>Translate header was used or not." >>> >>>In the example shown, the STUN agent learnt the public IP by >>> querying >>>STUN >>>sever and changed the outgoing REGISTER appropriately to reflect >>> this. > >>>When >>>this request reaches the proxy, it checks the sent-by value against >>> the >>>received address; they are same in this case (hence no received= >>> param). > >>No, they wouldn't be the same. The registration is sent over TCP, and >>uses a different port than was used to communicate with the STUN >> server. > > The example message corresponding to the text is: > > REGISTER sip:provider.com SIP/2.0 > Via: SIP/2.0/UDP 1.2.3.4:5678 > From: sip:user@provider.com > To: sip:user@provider.com > Call-ID: 88sdasdlasd0 > Contact: sip:user@1.2.3.4:5678 > Translate: sip:user@1.2.3.4:5678 > CSeq: 88790 REGISTER > > Here, the request is indeed, sent using UDP. Hmm. Don't know why I thought it was sent over TCP. That is a valid mode of operation, but it doesn't appear to be whats here. >>>Say, the proxy supports SIP extensions for NAT. The proxy then >>>rewrites >>>the >>>Translate header with sent-by value (in this case) which is same as >>> the >>>original value it carried in it. When returned in the 200 OK >>> response, >>>the >>>STUN agent sees that, the Translate header has the same value that >>> it >>>put >>>in, yet, the proxy supports the extension for NAT. >> >>Since the source port is different than the Contact port, the contact >>would be rewritten and the client would know. >> > > The source port (10) has been natted to 5678 (hence the port in Contact > holds 5678). The original request sent by the client: > > REGISTER sip:provider.com SIP/2.0 > Via: SIP/2.0/UDP 10.0.1.1 > From: sip:user@provider.com > To: sip:user@provider.com > Call-ID: 99asdasd98hnn > Contact: sip:user@10.0.1.1:5060 > CSeq: 88790 REGISTER > > The STUN agent finds out the address and port (as seen by the proxy) by > querying the STUN server; rewrites the message to: > > REGISTER sip:provider.com SIP/2.0 > Via: SIP/2.0/UDP 1.2.3.4:5678 > From: sip:user@provider.com > To: sip:user@provider.com > Call-ID: 88sdasdlasd0 > Contact: sip:user@1.2.3.4:5678 > Translate: sip:user@1.2.3.4:5678 > CSeq: 88790 REGISTER > > When sent out, the NAT rewrites the source address and port (to > 1.2.3.4:5678), finally reached the proxy. At the proxy, it sees a > Translate > header hence, finds out a matching Contact header. The host value is > replaced with the sent-by field from the Via (which in this case, is > same as > the value that's already present). The port number is replaced with the > sent-by field (again, the same value that's carried in it). Though, the > entire Contact header is rewritten, it results in the very same value it > has > already been carrying! Right. But, the STUN Agent can know whether the proxy translated the contact by the mere presence of the Translate header. If the proxy didn't support the extension, there would be no translate header. To be honest, looking back at this flow, the Translate header is not needed here at all. STUN provides an alternative. I'm not sure what I was thinking..... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 02:53:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09305 for ; Wed, 19 Jun 2002 02:53:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03699 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 02:53:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03414; Wed, 19 Jun 2002 02:37:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03383 for ; Wed, 19 Jun 2002 02:37:32 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09133 for ; Wed, 19 Jun 2002 02:36:53 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J6ZsYH017084; Wed, 19 Jun 2002 02:35:54 -0400 (EDT) Message-ID: <3D102649.3050503@dynamicsoft.com> Date: Wed, 19 Jun 2002 02:35:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] SDP in 200 with PRACK References: <3D003CBB.87436885@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Thanks for the comment! > > So, I guess I also can assume the following: > > There is no offer in the INVITE, so the offer from the UAS comes in the > first > reliable provisional response, and the answer to that comes in the > PRACK. > Now, in this case the offer is NOT needed in the 200, and the answer is > NOT > needed in the ACK (which is the case for a non-PRACK implementation). > Right? Right. > > A couple of other questions related to this: > > Q1: Bis-09 says that after the UAC has received an answer to an offer, > it may > generate subsequent offers in requests. The PRACK draft doesn't say > anything > about this, so from a protocol point of view I assume there could be a > new > offer in every PRACK? However, I think there was once a discussion if > that > really should be allowed, so... There can only be an offer in the first PRACK, based on the rules in 100rel. According to 100rel: If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. But, you can only get one reliable provisional response with an answer (when the INVITE had the offer), so its a one time deal. bis means to say that there can be offers in subsequent requests, based on rules defined for that request method. > > > Q2: Bis-09 says that once the UAS has sent or received an answer to the > initial offer, it must not generate subsequent offers in any responses > to the > initial INVITE. > > However, bis-09, nor the PRACK draft, says anything about if the UAS is > allowed to send a new offer in a reliable 18x, within the INVITE > transaction, > if it has received (in a PRACK) an answer to a previous offer. Sure it says something. It says if cannot generate subsequent offers in any responses to the initial INVITE, period. That would include reliable 18x. > Q3: A "cosmetic" question > > "The UAC MUST treat the first session description it receives as the > answer, > and MUST ignore any > session descriptions in subsequent responses to the initial INVITE." > > Should it be mentioned that this is per early dialog? An INVITE may be > forked, so the UAC may receive multiple different session descriptions, > so > there is nothing saying that the first session description is going to > be the > one which finally be used (ie will be included in the 200). Generally, the O/A exchange is per dialog. That could be made clearer. All of this is actually quite complicated. This is on my list to "simplify for draft standard". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 03:10:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09611 for ; Wed, 19 Jun 2002 03:10:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04765 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 03:10:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03775; Wed, 19 Jun 2002 02:54:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03741 for ; Wed, 19 Jun 2002 02:54:46 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09322 for ; Wed, 19 Jun 2002 02:54:06 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5J6s9YH017094; Wed, 19 Jun 2002 02:54:09 -0400 (EDT) Message-ID: <3D102A90.9020002@dynamicsoft.com> Date: Wed, 19 Jun 2002 02:54:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Flemming Andreasen , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D101AEF.2C1EB915@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, >>Egads, this is all getting out of hand. >> >>First off, the 180 is an indication from the UAS that the called party >>is being "alerted" for some definition of alerted (screen pop, ring, >>etc.). How that information is used at the UAC is a matter of user >>interface. Last I checked, SIP didn't specify user interfaces. It >> merely >>says that you can do the obvious thing, which is play a local >> ringback. > > I'm not sure it's that easy eg when we talk about a SIP/PSTN gateway, > because > it's not only about how the GW informs the caller but also how the MG > handles > the media. > > Chapter 7.2.3 of draft-ietf-sipping-isup-02.txt says: > > "If the reception of a `180 Ringing' response without media > description, the MG generates the ringback tone to be heard by the > caller. > > If the MGC receives any 1xx response (except 100) with a session > description present for media setup, it sets up the session being > described. The call progress media (e.g. ringback tone or > announcement) is generated by an entity downstream (in the SIP > network or by a PSTN exchange in SIP bridging situations)." > > As a general rule, for a basic SIP implementation, I assume this works > fine. > > My original issue, however, was if this really works in more advanced > scenarios. There may be situations, due to offer/answer negoatiations, > manyfolks, and/or PRACK for which we must include an SDP in a 180 > response, > which really hasn't anything to do with the ringback. This is purely an issue for PSTN interop. If there is a session established, there is a session. Playing local alerting makes no sense. Therefore, I would suggest that the sip-isup draft recommend that local ringback be used only if the session is not established yet. > > My other issue was, what happens if we have received a 183 with SDP, ie > early-media may be established, and then we receive a 180 without SDP? > Again, > for normal UACs this may not be a big problem, but for a GW it may. See above. The > GW > doesn't know if the UAS will stop transmitting early-media, and wants to > GW > to generate a local ringback tone, or if the UAS will continue > transmitting > early-media, and only wants to GW to indicate that the called party has > been > alerted. I can't imagine a case where a PSTN gateway receives a call, and generates a 18x with SDP to establish an early session (presumably because there is media in the circuit in the reverse direction), and THEN decides it needs the calling gateway to generate local ringback. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 03:42:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10155 for ; Wed, 19 Jun 2002 03:42:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06458 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 03:43:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05212; Wed, 19 Jun 2002 03:19:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05181 for ; Wed, 19 Jun 2002 03:19:33 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09734 for ; Wed, 19 Jun 2002 03:18:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5J7JMrU009553; Wed, 19 Jun 2002 09:19:23 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5J7JKa9027317; Wed, 19 Jun 2002 10:19:20 +0300 (EET DST) Message-ID: <3D103079.9F0FBAE3@lmf.ericsson.se> Date: Wed, 19 Jun 2002 10:19:22 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Flemming Andreasen , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D101AEF.2C1EB915@lmf.ericsson.se> <3D102A90.9020002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > >>Egads, this is all getting out of hand. > >> > >>First off, the 180 is an indication from the UAS that the called party > >>is being "alerted" for some definition of alerted (screen pop, ring, > >>etc.). How that information is used at the UAC is a matter of user > >>interface. Last I checked, SIP didn't specify user interfaces. It > >> merely > >>says that you can do the obvious thing, which is play a local > >> ringback. > > > > I'm not sure it's that easy eg when we talk about a SIP/PSTN gateway, > > because > > it's not only about how the GW informs the caller but also how the MG > > handles > > the media. > > > > Chapter 7.2.3 of draft-ietf-sipping-isup-02.txt says: > > > > "If the reception of a `180 Ringing' response without media > > description, the MG generates the ringback tone to be heard by the > > caller. > > > > If the MGC receives any 1xx response (except 100) with a session > > description present for media setup, it sets up the session being > > described. The call progress media (e.g. ringback tone or > > announcement) is generated by an entity downstream (in the SIP > > network or by a PSTN exchange in SIP bridging situations)." > > > > As a general rule, for a basic SIP implementation, I assume this works > > fine. > > > > My original issue, however, was if this really works in more advanced > > scenarios. There may be situations, due to offer/answer negoatiations, > > manyfolks, and/or PRACK for which we must include an SDP in a 180 > > response, > > which really hasn't anything to do with the ringback. > > This is purely an issue for PSTN interop. If there is a session > established, there is a session. Playing local alerting makes no sense. > Therefore, I would suggest that the sip-isup draft recommend that local > ringback be used only if the session is not established yet. This would probably work fine in most cases, especially when the UAC receives the early media and the 180 from the same node. Later in this mail I describe a scenario where this may not work. > >My other issue was, what happens if we have received a 183 with SDP, ie > >early-media may be established, and then we receive a 180 without SDP? > >Again, > >for normal UACs this may not be a big problem, but for a GW it may. > > See above. > > >The GW doesn't know if the UAS will stop transmitting early-media, and > wants to > >GW to generate a local ringback tone, or if the UAS will continue > >transmitting early-media, and only wants to GW to indicate that the called > party has > >been alerted. > > I can't imagine a case where a PSTN gateway receives a call, and > generates a 18x with SDP to establish an early session (presumably > because there is media in the circuit in the reverse direction), and > THEN decides it needs the calling gateway to generate local ringback. I am not sure how it will work on the PSTN side, but let's assume the following SIP scenario. I try to call my boss. I reach the company "switch" (which, I guess, in this case has be implemented as some kind of SIP B2BUA) which sends me a 183 (with SDP) and start transmitting early media telling me that I have now reached this company, please wait, press this button for this, press that button for that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP phone I'm calling to. Now, this SIP phone is not able to generate any early media at all, so it sends a 180 (without SDP). Now I assume the switch could only forward the 180 to the caller (via the PSTN GW), stop transmitting the early media, and expect the PSTN GW to generate a local ringback tone, since the called party has been reached. Now, one can argue that this is a complicated scenario, which has nothing to do with the basic SIP etc etc. BUT, from the caller's point of view this is a normal session setup. It receives the 183 (with SDP) and 180 (without SDP) within the same dialog, and has no idea what is happening at the remote site. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 06:10:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12091 for ; Wed, 19 Jun 2002 06:10:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14591 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 06:11:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13668; Wed, 19 Jun 2002 05:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13641 for ; Wed, 19 Jun 2002 05:51:16 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11918 for ; Wed, 19 Jun 2002 05:50:35 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5J9pCrU005711; Wed, 19 Jun 2002 11:51:12 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5J9pCa9006249; Wed, 19 Jun 2002 12:51:12 +0300 (EET DST) Message-ID: <3D105411.E4343FDD@lmf.ericsson.se> Date: Wed, 19 Jun 2002 12:51:13 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] SDP in 200 with PRACK + 180 Ringback References: <3D003CBB.87436885@lmf.ericsson.se> <3D102649.3050503@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A couple of issues in this thread, are related to the thread on 180 and Ringback generation, so I'll bring them up here too. > >Q1: Bis-09 says that after the UAC has received an answer to an offer, > >it may generate subsequent offers in requests. The PRACK draft doesn't say > > >anything about this, so from a protocol point of view I assume there could > be a > >new offer in every PRACK? However, I think there was once a discussion if > >that really should be allowed, so... > > There can only be an offer in the first PRACK, based on the rules in > 100rel. According to 100rel: > > If the UAC receives > a reliable provisional response with an answer, it MAY generate an > additional offer in the PRACK. The rule also say that the session description in the PRACK should not affect the response code of the PRACK (ie if the reliability function of the PRACK is ok we return 200 - no matter if the session description is accepted by the application or not). Also, the rule says that, if the PRACK contained an offer, the response must contain the answer. Now, if we DO receive a subsequent PRACK with SDP (which is not allowed) we will still return 200. But: do we also include an SDP, ie with the ports set to zero, or can we leave the message body empty? I guess this is an implementation issue, but it would be nice to hear some oppinions on it (I know we have discussed the issue of allowing SDPs in PRACKs in the first place before, so we don't have to bring that discussion up again). > But, you can only get one reliable provisional response with an answer > (when the INVITE had the offer), so its a one time deal. The UAS MAY send the SAME SDP in subsequent provisional responses (and in the final response), eg in a 180 for the ringback generation purpose, but that has of course nothing to do with the answer/offer mechanism. > >Q2: Bis-09 says that once the UAS has sent or received an answer to the > >initial offer, it must not generate subsequent offers in any responses > >to the initial INVITE. > > > > However, bis-09, nor the PRACK draft, says anything about if the UAS is > > allowed to send a new offer in a reliable 18x, within the INVITE > > transaction, > > if it has received (in a PRACK) an answer to a previous offer. > > Sure it says something. It says if cannot generate subsequent offers in > any responses to the initial INVITE, period. That would include reliable > 18x. > > >Q3: A "cosmetic" question > > > >"The UAC MUST treat the first session description it receives as the > >answer, and MUST ignore any session descriptions in subsequent responses > to the initial INVITE." > > > >Should it be mentioned that this is per early dialog? An INVITE may be > >forked, so the UAC may receive multiple different session descriptions, > >so there is nothing saying that the first session description is going to > >be the one which finally be used (ie will be included in the 200). > > Generally, the O/A exchange is per dialog. That could be made clearer. The "MUST ignore any session description in subsequent responses" statement is only related to the answer/offer mechanism. Again, there may be 180 with session descriptions for the ringback tone generation purpose. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 07:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14540 for ; Wed, 19 Jun 2002 07:52:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA21138 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 07:52:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18725; Wed, 19 Jun 2002 07:28:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18694 for ; Wed, 19 Jun 2002 07:28:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13554; Wed, 19 Jun 2002 07:27:47 -0400 (EDT) Message-Id: <200206191127.HAA13554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Jun 2002 07:27:47 -0400 Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Private Session Initiation Protocol Extension for Access Network Information Author(s) : D. Mills Filename : draft-mills-sip-access-network-info-03.txt Pages : 8 Date : 18-Jun-02 This mechanism is useful in SIP networks that provide layer 2/layer 3 connectivity through different access technologies. This document defines the private SIP extension header P-Access- Network-Info. SIP User Agents may use this header to relay information about the access technology to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service provider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-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-mills-sip-access-network-info-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-mills-sip-access-network-info-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: <20020618132145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mills-sip-access-network-info-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-mills-sip-access-network-info-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020618132145.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 08:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15333 for ; Wed, 19 Jun 2002 08:18:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23038 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 08:19:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22248; Wed, 19 Jun 2002 08:04:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07403 for ; Wed, 19 Jun 2002 00:21:50 -0400 (EDT) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13588 for ; Wed, 19 Jun 2002 00:21:07 -0400 (EDT) Received: from nirmalya (cwc-zw7j5gdv1j4.cwc.nus.edu.sg [172.16.2.129] (may be forged)) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id MAA17487; Wed, 19 Jun 2002 12:20:21 +0800 (SGT) Reply-To: From: "Nirmalya Ghosh" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] REGISTER Processing Date: Wed, 19 Jun 2002 12:20:48 +0800 Organization: Institute For Communications Research, Singapore Message-ID: <000601c21748$b1ea4640$810210ac@cwc.nus.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3D0F7A11.3050208@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan, I have a question regarding what happens when a user wants to fetch its current bindings (maybe after rebooting his/her PC). I understand that the Call-ID need not be the same across reboots, but what I am not sure of is whether for a dummy REGISTER request (containing no Contact or Expires) sent to fetch its bindings after rebooting, would/should get a 500 response from the registrar just because its CSeq does not match that of existing bindings. Or am I misinterpreting things here? Thanks & Regards, Nirmalya -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, June 19, 2002 2:21 AM To: Jiri Kuthan Cc: sip@ietf.org; Jan Janak Subject: Re: [Sip] REGISTER Processing sorry for the immensely late response... combing the list now for old bis issues: Jiri Kuthan wrote: > There seems to be insufficient guidance in bis-09 on usage of Call-ID > in REGISTERs. The only thing which I found there is in 10.2.4: > > "A UA SHOULD use the same Call-ID for all registrations during a > single boot cycle. " > > I think that does NOT require Call-ID to change across reboots. Correct. > UAs with no memory are not explicitely mandated to change Call-ID > (ignoring that bis asks to deny REGISTERs with Call-ID== and CSeq <= > values in registrar's bindings). If the UACs actually do not change > Call-ID, REGISTERs after reboots with low CSeq will be ignored. Right, which is way the guidelines for CSeq say: > CSeq: The CSeq value guarantees proper ordering of REGISTER requests. > A UA MUST increment the CSeq value by one for each REGISTER > request with the same Call-ID. This would seem to explicitly address the issue, no? > > Which actually happened during two tests in SIPIt. > > Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if not > doing so does not break things, which is not the case here. I think SHOULD is sufficient so long as you also properly follow the MUST strength requirement on CSeq incremeting. > > -- > > Other confusing thing is which SIP reply a request failure for > out-of-order REGISTERs in line 1740 implies. I could connect it to > the next paragraph "....if binding update fails...the request MUST > fail with 500..." but I am not sure that 500 is a good choice. No, that status code is correct. Its the same error response used when you receive a request on a dialog with a CSeq lower than the current one. From line 2033 in bis09 PDF, a 500 is returned there too. You want a 500, since the client can retry the request and it can work the second time (since the CSeq will change as a natural consequence of retrying the request). Given that the error code is correct, do you still find it confusing to have the two paragraphs connected? > > -- > > Yet anothet thing, which Jan pointed out, is that handling of > out-or-order in lines 1738-40 also includes retransmissions (CSeq and > CallID in request and bindings equal). Retransmissions would have already been handled in the transaction layer. Thus, a totally new transaction with the same call-id/cseq is indeed an error. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 08:18:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15350 for ; Wed, 19 Jun 2002 08:18:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23052 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 08:19:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22234; Wed, 19 Jun 2002 08:04:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11890 for ; Wed, 19 Jun 2002 05:21:55 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11518 for ; Wed, 19 Jun 2002 05:21:14 -0400 (EDT) Received: from jku2.iptel.org (port-212-202-171-58.reverse.qdsl-home.de [212.202.171.58]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g5J9LEC04523; Wed, 19 Jun 2002 11:21:14 +0200 Message-Id: <5.1.0.14.0.20020619084601.033236f8@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Jun 2002 11:17:32 +0200 To: Jonathan Rosenberg From: Jiri Kuthan Subject: 5xx on o-o-o (was Re: [Sip] REGISTER Processing Cc: sip@ietf.org, Jan Janak In-Reply-To: <3D10199A.7010402@dynamicsoft.com> References: <5.1.0.14.0.20020618203638.02260e80@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 07:41 AM 6/19/2002, Jonathan Rosenberg wrote: >>I'm not particularly happy about 5xx in neither context. 5xx stands for >>server error >>("the server failed to fulfill an apparently valid request"), whereas >>this sounds to >>me much more like "4xx - client error -- the request contains bad syntax >>or cannot >>be fulfilled at server". I don't think there is a big interop issue for >>UACs, it is >>primarily of diagnostic value. I'm a fan of rich and correct diagnostic >>info, which >>makes bug location easier. 5xx makes me hunt a bug mistakenly in a UAS. >>My preference is "4xx out-of-order". > >Its not about finger-pointing, That is my concern -- lack of finger pointing makes life difficult. (Do you remember those ancient compilers whose only error message was "syntax error"?) The spec tells 4xx is a request failure, 5xx is a server failure. Out-of-order requests are not a server failure -- these are messages invalid within a call-id space context. Ignoring whether 4xx or 5xx makes a better interop job, having a special o-o-o response code seems very helpful to me -- it would encourage server implementors to be more specific than {4|5}00 "some error". >its about taking the proper actions upon getting the error. Generally, 5xx is supposed to mean, "you can retry this request later on without change, and it might succeed". The 4xx responses indicated that the client needs to change the request in some way, and if it can't, there is no point in trying again. >In this case here, the client CAN indeed simply retry the request again later on, without change (of course, things like the cseq, call-id, via do change as per normal operation), and it can work. Thats why we used 500. I see now -- a noble lie. UAS tells the buggy UAC "5xx I'm guilty please retry, as soon as my current bindings expire or you reach my Cseq you'll be ok" (as opposed to honest "4xx don't resubmit until you fix your buggy CSeq"). It is ugly, though I admit 5xx is doing little a bit better in this case -- we trade better interoperability with buggy UACs for diagnostic value of status code (is it worth it?). Again, compensating that by a specific status code seems very helpful to me. >The notion of stateless UAS is really for unauthenticated requests. Its not a general thing. Please no -- forbidding undocumented uses of an entity is too limiting. There are for sure other valid uses of stateless UASs. For example, a stateless redirect server copes better with heavy load than a stateful one. >Indeed, in the case of REGISTER, there are other problems. Each retransmission would effectively update the expiration time of the contact. It may or may not, subject to how the transactionally-stateless registrar is implemented. >Eaech response would therefore have a different expiration time in the contact. As a result, the "retransmits" of each response are different, and the UAC would need to use the last one in order to obtain the proper expiration time. Not a big issue, but its not supposed to work that way. That is fixeable with a stateless registrar. I am only opposed to forcing a stateless registrar to send a negative reply on REGISTER retransmisssion. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 11:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22531 for ; Wed, 19 Jun 2002 11:17:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03804 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 11:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01506; Wed, 19 Jun 2002 10:42:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01473 for ; Wed, 19 Jun 2002 10:42:39 -0400 (EDT) Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21041 for ; Wed, 19 Jun 2002 10:42:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Wed, 19 Jun 2002 09:42:04 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414093A82@NREXCH.netrake.net> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWDEbGlPzw6OZ/Sva8F+dVG9RsCAAwEJygAAEbvoAAM0mFIA== From: "Rob Phillips" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01474 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit >By the way, do we need <> around the sip uri examples there? I think the answer is yes. There's a paragraph in bis-09 chapter 20 that seems to support this: The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. I think that, although the first sentence gives the impression this paragraph is meant only for the Contact, From, and To headers, it's a general comment on URIs in SIP. Would this be the consensus? - rob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 19 11:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24202 for ; Wed, 19 Jun 2002 11:51:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06033 for sip-archive@odin.ietf.org; Wed, 19 Jun 2002 11:52:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04168; Wed, 19 Jun 2002 11:23:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04144 for ; Wed, 19 Jun 2002 11:23:30 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22800 for ; Wed, 19 Jun 2002 11:22:50 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5JFMVuF014118; Wed, 19 Jun 2002 08:22:31 -0700 (PDT) Received: from cisco.com (rtp-vpn1-525.cisco.com [10.82.226.13]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA20130; Wed, 19 Jun 2002 08:22:51 -0700 (PDT) Message-ID: <3D10A1CA.8EC93753@cisco.com> Date: Wed, 19 Jun 2002 11:22:50 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Mark Watson , "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Flemming Andreasen wrote: > >>From the point of view of the UAC (assuming an SDP offer in the INVITE > >>for simplicity), then if > >>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > >>183, 180 , UPDATE, 200 OK to UPDATE etc.), and > >>(ii) a=sendrecv or a=sendonly in this answer, and > >>(iii) any manyfolks pre-conditions have been met (i.e. this could be > >>an answer at the end of several offer/answer exchanges negotiating and > >>updating preconditions) > >> > >>then there is Early Media, and the UAC SHOULD (?) play this to the > >>caller. > >> > > > > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > > My understanding was, that if you get a 180, then you will generate > > local ringback until you receive RTP (or whatever else you may have > > negotiated in your media stream(s)), whereas with 183, you do not > > generate local ringback. > > Egads, this is all getting out of hand. > > First off, the 180 is an indication from the UAS that the called party > is being "alerted" for some definition of alerted (screen pop, ring, > etc.). How that information is used at the UAC is a matter of user > interface. Last I checked, SIP didn't specify user interfaces. It merely > says that you can do the obvious thing, which is play a local ringback. > So to be clear: There is no requirement to send back a 180 when the far-end is providing in-band ringback. By virtue of the fact that the offer allowed media to be sent to the UAC, we can simply start sending in-band ringback, irrespective of which response code was sent back last (say 183 etc. in case we had used manyfolks). > > > > > I don't think that's necessary, since manyfolks has its own direction > > attributes independent of the media stream direction attributes. Thus > > you could specify an inactive stream and require sendrevc reservation > > for it. What is not clear however, is how a UAC can negotiate > > bidirectional codec support without accepting early media in both > > directions. > > You are making a distinction between early media and regular media, when > there isn't and shouldn't be one. This was the real idea behind the > unify model. If I offer you to receive media, that means, I am willing > to receive media, period. > The trouble is, that in some QoS enabled environments (PacketCable for example), you don't want to allow use of bidirectional media until the call is answered (and charging starts), however you want to make sure that bidirectional media can in fact be supported (succesful codec negotiation) before alerting the called party. How do you solve this with the tools at hand ? -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 20 01:46:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11749 for ; Thu, 20 Jun 2002 01:46:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28560 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 01:47:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27523; Thu, 20 Jun 2002 01:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27492 for ; Thu, 20 Jun 2002 01:21:34 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11322 for ; Thu, 20 Jun 2002 01:20:52 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5K5LORb005375; Thu, 20 Jun 2002 07:21:24 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.78]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5K5LNa9028249; Thu, 20 Jun 2002 08:21:23 +0300 (EET DST) Message-ID: <3D116653.9E4E706B@lmf.ericsson.se> Date: Thu, 20 Jun 2002 08:21:23 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > >>>From the point of view of the UAC (assuming an SDP offer in the INVITE > >>>for simplicity), then if > >>>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > >>>183, 180 , UPDATE, 200 OK to UPDATE etc.), and > >>>(ii) a=sendrecv or a=sendonly in this answer, and > >>>(iii) any manyfolks pre-conditions have been met (i.e. this could be > >>>an answer at the end of several offer/answer exchanges negotiating and > >>>updating preconditions) > >>> > >>>then there is Early Media, and the UAC SHOULD (?) play this to the > >>>caller. > >>> > >> > >> > >>Will this be the case irrespective of whether you got a 180 or a 183 ? > >>My understanding was, that if you get a 180, then you will generate > >>local ringback until you receive RTP (or whatever else you may have > >>negotiated in your media stream(s)), whereas with 183, you do not > >>generate local ringback. > > > >Egads, this is all getting out of hand. > > > > First off, the 180 is an indication from the UAS that the called party > > is being "alerted" for some definition of alerted (screen pop, ring, > > etc.). How that information is used at the UAC is a matter of user > > interface. Last I checked, SIP didn't specify user interfaces. It merely > > says that you can do the obvious thing, which is play a local ringback. > > > > So to be clear: There is no requirement to send back a 180 when the far-end > is providing in-band ringback. By virtue of the fact that the offer allowed > media to be sent to the UAC, we can simply start sending in-band ringback, > irrespective of which response code was sent back last (say 183 etc. in case > we had used manyfolks). We should remember that the remote party may also be a GW, so "dropping" ISUP messages (ie not map them to a specific 18x response) will affect the ISUP/SIP mapping, and the ISUP transparency (ISUP MIME) mechanism. Regards, Christer Holmberg Ericsson Finland > >>I don't think that's necessary, since manyfolks has its own direction > >>attributes independent of the media stream direction attributes. Thus > >>you could specify an inactive stream and require sendrevc reservation > >>for it. What is not clear however, is how a UAC can negotiate > >>bidirectional codec support without accepting early media in both > >>directions. > > > >You are making a distinction between early media and regular media, when > >there isn't and shouldn't be one. This was the real idea behind the > >unify model. If I offer you to receive media, that means, I am willing > >to receive media, period. > > > > The trouble is, that in some QoS enabled environments (PacketCable for > example), you don't want to allow use of bidirectional media until the call > is answered (and charging starts), however you want to make sure that > bidirectional media can in fact be supported (succesful codec negotiation) > before alerting the called party. How do you solve this with the tools at > hand? > > > -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 09:11:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28682 for ; Thu, 20 Jun 2002 09:11:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20361 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 09:12:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18614; Thu, 20 Jun 2002 08:48:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18583 for ; Thu, 20 Jun 2002 08:48:46 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27786 for ; Thu, 20 Jun 2002 08:48:03 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AF2BFB8A005A; Thu, 20 Jun 2002 08:48:43 -0400 Message-ID: <005401c21858$b6d50e40$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , "Jonathan Rosenberg" Cc: "Flemming Andreasen" , "Mark Watson" , References: <3D101AEF.2C1EB915@lmf.ericsson.se> <3D102A90.9020002@dynamicsoft.com> <3D103079.9F0FBAE3@lmf.ericsson.se> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Thu, 20 Jun 2002 08:48:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg" > > I am not sure how it will work on the PSTN side, but let's assume the > following SIP scenario. > > I try to call my boss. I reach the company "switch" (which, I guess, in this > case has be implemented as some kind of SIP B2BUA) which sends me a 183 (with > SDP) and start transmitting early media telling me that I have now reached > this company, please wait, press this button for this, press that button for > that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP > phone I'm calling to. Now, this SIP phone is not able to generate any early > media at all, so it sends a 180 (without SDP). Now I assume the switch could > only forward the 180 to the caller (via the PSTN GW), stop transmitting the > early media, and expect the PSTN GW to generate a local ringback tone, since > the called party has been reached. > > Now, one can argue that this is a complicated scenario, which has nothing to > do with the basic SIP etc etc. BUT, from the caller's point of view this is a > normal session setup. It receives the 183 (with SDP) and 180 (without SDP) > within the same dialog, and has no idea what is happening at the remote site. > The RTP session is controlled by SDP offers and answers. If a session is established, there would need to be a new offer/answer exchange to change it. Stopping the RTP flow because the 180 does not have SDP is the wrong thing to do. Scenarios like this can be done with the UPDATE method which allow the UAS to change the session. The UAS is explicitly forbidden from sending subsequent offers in 18x responses (bis-09 line 2119), but it could send them in UPDATE requests. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 09:13:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28768 for ; Thu, 20 Jun 2002 09:13:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20482 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 09:14:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18092; Thu, 20 Jun 2002 08:39:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18064 for ; Thu, 20 Jun 2002 08:39:41 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27583 for ; Thu, 20 Jun 2002 08:38:58 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AD09A1CB0184; Thu, 20 Jun 2002 08:39:37 -0400 Message-ID: <003e01c21857$7208dcc0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Flemming Andreasen" , "Jonathan Rosenberg" Cc: "Mark Watson" , "'Christer Holmberg'" , References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Thu, 20 Jun 2002 08:38:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Flemming Andreasen" > > Jonathan Rosenberg wrote: > > > Flemming Andreasen wrote: > > >>From the point of view of the UAC (assuming an SDP offer in the INVITE > > >>for simplicity), then if > > >>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > > >>183, 180 , UPDATE, 200 OK to UPDATE etc.), and > > >>(ii) a=sendrecv or a=sendonly in this answer, and > > >>(iii) any manyfolks pre-conditions have been met (i.e. this could be > > >>an answer at the end of several offer/answer exchanges negotiating and > > >>updating preconditions) > > >> > > >>then there is Early Media, and the UAC SHOULD (?) play this to the > > >>caller. > > >> > > > > > > > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > > > My understanding was, that if you get a 180, then you will generate > > > local ringback until you receive RTP (or whatever else you may have > > > negotiated in your media stream(s)), whereas with 183, you do not > > > generate local ringback. > > > > Egads, this is all getting out of hand. > > > > First off, the 180 is an indication from the UAS that the called party > > is being "alerted" for some definition of alerted (screen pop, ring, > > etc.). How that information is used at the UAC is a matter of user > > interface. Last I checked, SIP didn't specify user interfaces. It merely > > says that you can do the obvious thing, which is play a local ringback. > > > > So to be clear: There is no requirement to send back a 180 when the far-end > is providing in-band ringback. By virtue of the fact that the offer allowed > media to be sent to the UAC, we can simply start sending in-band ringback, > irrespective of which response code was sent back last (say 183 etc. in case > we had used manyfolks). > That does not seem correct to me. There is no way for the signaling layer to know that there is in-band ringback. The only standard mechanism to tell the caller that the calling party is being alerted is the 180 response. The signaling layer does know whether or not the session (RTP) has been established. If one has not been established when the UAC receives the 180, it MAY generate ringback locally. If a session is established, the fact that there is no SDP in the 180 does not change that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 11:38:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03589 for ; Thu, 20 Jun 2002 11:38:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00204 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 11:39:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28347; Thu, 20 Jun 2002 11:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28316 for ; Thu, 20 Jun 2002 11:12:14 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h77s128a211n47.user.nortelnetworks.com [47.211.128.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02869 for ; Thu, 20 Jun 2002 11:11:30 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5KFBc124336 for ; Thu, 20 Jun 2002 16:11:38 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 16:11:39 +0100 Message-ID: From: "Mark Watson" To: "'sip@ietf.org'" Date: Thu, 20 Jun 2002 16:11:31 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] Manyfolks questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If the UAC knows of no preconditions for a session, but supports the manyfolks mechanism, what should it indicate in the INVITE in order to give the UAS the opportunity to indicate that it has (presumably local) preconditions ? 1) Indicate 'Supported: preconditions' in the INVITE, but do not include a=cur: a=des: etc. in the SDP offer. Then the UAS can return the a=cur: a=des: in the SDP answer. OR 2) Indicate 'Supported: preconditions' in the INVITE and include the attributes but with desired status 'none' If it's (1), we need description of the answerer adding the pre-condition attributes when they were not present in the offer. If it's (2), then it should be mandatory to include the pre-condition attributes if you include 'Supported: preconditions'. I couldn't find either in the specification, but perhaps I didn't look hard enough! Regards, Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 12:12:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04791 for ; Thu, 20 Jun 2002 12:12:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02998 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 12:12:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00976; Thu, 20 Jun 2002 11:53:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00940 for ; Thu, 20 Jun 2002 11:53:53 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03938 for ; Thu, 20 Jun 2002 11:53:11 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jun 2002 10:52:42 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE43@jupiter> From: David Oliver To: "'Christer Holmberg'" Cc: sip@ietf.org Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Thu, 20 Jun 2002 10:52:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org An interesting feature of this scenario is that for incoming calls from the PSTN, the company IP-switch/PBX will need to generate ringback on behalf of the callee's no-early-media phone until it answers the call. This would reasonably be generated by the same subsystem which provides the "press this button" features, until the IP phone is answered. If the phone is not answered, the subsystem would provide the opportunity to redirect the caller to voice-mail, etc. It seems appropriate to use exactly the same mechanism for IP calls, as this would simplify the implementation (the PSTN GW would be handled like IP-only calls), and prevent confusing the caller. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: doliver@securelogix.com Tel: 210.402.9669 Fax: 210.402.6996 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, June 19, 2002 2:19 AM To: Jonathan Rosenberg Cc: Flemming Andreasen; Mark Watson; sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 Hi, <...> I am not sure how it will work on the PSTN side, but let's assume the following SIP scenario. I try to call my boss. I reach the company "switch" (which, I guess, in this case has be implemented as some kind of SIP B2BUA) which sends me a 183 (with SDP) and start transmitting early media telling me that I have now reached this company, please wait, press this button for this, press that button for that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP phone I'm calling to. Now, this SIP phone is not able to generate any early media at all, so it sends a 180 (without SDP). Now I assume the switch could only forward the 180 to the caller (via the PSTN GW), stop transmitting the early media, and expect the PSTN GW to generate a local ringback tone, since the called party has been reached. Now, one can argue that this is a complicated scenario, which has nothing to do with the basic SIP etc etc. BUT, from the caller's point of view this is a normal session setup. It receives the 183 (with SDP) and 180 (without SDP) within the same dialog, and has no idea what is happening at the remote site. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 17:47:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13715 for ; Thu, 20 Jun 2002 17:47:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23673 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 17:48:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21239; Thu, 20 Jun 2002 17:26:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21208 for ; Thu, 20 Jun 2002 17:26:21 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13066 for ; Thu, 20 Jun 2002 17:25:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KLQ7Rb009962; Thu, 20 Jun 2002 23:26:07 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5KLQ6a9016452; Fri, 21 Jun 2002 00:26:06 +0300 (EET DST) Message-ID: <3D124869.4F7D1F47@lmf.ericsson.se> Date: Fri, 21 Jun 2002 00:26:01 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Jonathan Rosenberg , Flemming Andreasen , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D101AEF.2C1EB915@lmf.ericsson.se> <3D102A90.9020002@dynamicsoft.com> <3D103079.9F0FBAE3@lmf.ericsson.se> <005401c21858$b6d50e40$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > ----- Original Message ----- > From: "Christer Holmberg" > > > > > I am not sure how it will work on the PSTN side, but let's assume the > > following SIP scenario. > > > > I try to call my boss. I reach the company "switch" (which, I guess, in > this > > case has be implemented as some kind of SIP B2BUA) which sends me a 183 > (with > > SDP) and start transmitting early media telling me that I have now reached > > this company, please wait, press this button for this, press that button > for > > that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP > > phone I'm calling to. Now, this SIP phone is not able to generate any > early > > media at all, so it sends a 180 (without SDP). Now I assume the switch > could > > only forward the 180 to the caller (via the PSTN GW), stop transmitting > the > > early media, and expect the PSTN GW to generate a local ringback tone, > since > > the called party has been reached. > > > > Now, one can argue that this is a complicated scenario, which has nothing > to > > do with the basic SIP etc etc. BUT, from the caller's point of view this > is a > > normal session setup. It receives the 183 (with SDP) and 180 (without SDP) > > within the same dialog, and has no idea what is happening at the remote > site. > > > The RTP session is controlled by SDP offers and answers. If a session is > established, there would need to be a new offer/answer exchange to change > it. Stopping the RTP flow because the 180 does not have SDP is the wrong > thing to do. Scenarios like this can be done with the UPDATE method which > allow the UAS to change the session. The UAS is explicitly forbidden from > sending subsequent offers in 18x responses (bis-09 line 2119), but it could > send them in UPDATE requests. First, I agree that the UAS is forbidden from sending a subsequent offer in a 18x, and I also think that using something like UPDATE for this purpose is too "expensive". However, let's assume the following thing: we do NOT update the session. So, if the UAC receives a 183 with SDP an early session can be established, and there MAY be early media - nobody says there MUST be early media. Then, when the UAS sends 180 without SDP the session still exists from a signalling point of view, but the UAS indicates that I will stop sending early media and wants the UAC to generate a local ringback tone. I don't think this idea would break any rule, would it (the session still exist, but the UAS simply indicates it won't send any early media - even if it would be "allowed" to do so from a SIP point of view). Then, if the UAS for whatever reason is going to start transmitting early media again, it could send eg a new 183, with the same SDP as in the previous 183. Again, this SDP would not be a new offer, simply an indication that the GW should stop generating local ringback, and start "passing" the RTP media to the PSTN side again (in general, eg in a PSTN GW case, even if we have an early media session established between the GW and the UAS, the GW may still, for whatever reason, choose NOT to send any media to the PSTN side...). How does this sound? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 17:49:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13749 for ; Thu, 20 Jun 2002 17:49:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23707 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 17:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21829; Thu, 20 Jun 2002 17:29:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21795 for ; Thu, 20 Jun 2002 17:29:48 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13220 for ; Thu, 20 Jun 2002 17:29:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KLTZrU013704; Thu, 20 Jun 2002 23:29:36 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5KLTYa9016632; Fri, 21 Jun 2002 00:29:35 +0300 (EET DST) Message-ID: <3D12493E.2EA34E08@lmf.ericsson.se> Date: Fri, 21 Jun 2002 00:29:35 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Flemming Andreasen , Jonathan Rosenberg , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > ----- Original Message ----- > From: "Flemming Andreasen" > > > > Jonathan Rosenberg wrote: > > > > > Flemming Andreasen wrote: > > > >>From the point of view of the UAC (assuming an SDP offer in the INVITE > > > >>for simplicity), then if > > > >>(i) an SDP answer is received before the 200 OK of the INVITE (e.g. in > > > >>183, 180 , UPDATE, 200 OK to UPDATE etc.), and > > > >>(ii) a=sendrecv or a=sendonly in this answer, and > > > >>(iii) any manyfolks pre-conditions have been met (i.e. this could be > > > >>an answer at the end of several offer/answer exchanges negotiating and > > > >>updating preconditions) > > > >> > > > >>then there is Early Media, and the UAC SHOULD (?) play this to the > > > >>caller. > > > >> > > > > > > > > > > > > Will this be the case irrespective of whether you got a 180 or a 183 ? > > > > My understanding was, that if you get a 180, then you will generate > > > > local ringback until you receive RTP (or whatever else you may have > > > > negotiated in your media stream(s)), whereas with 183, you do not > > > > generate local ringback. > > > > > > Egads, this is all getting out of hand. > > > > > > First off, the 180 is an indication from the UAS that the called party > > > is being "alerted" for some definition of alerted (screen pop, ring, > > > etc.). How that information is used at the UAC is a matter of user > > > interface. Last I checked, SIP didn't specify user interfaces. It merely > > > says that you can do the obvious thing, which is play a local ringback. > > > > > > > So to be clear: There is no requirement to send back a 180 when the > far-end > > is providing in-band ringback. By virtue of the fact that the offer > allowed > > media to be sent to the UAC, we can simply start sending in-band ringback, > > irrespective of which response code was sent back last (say 183 etc. in > case > > we had used manyfolks). > > > That does not seem correct to me. There is no way for the signaling layer to > know that there is in-band ringback. The only standard mechanism to tell the > caller that the calling party is being alerted is the 180 response. The > signaling layer does know whether or not the session (RTP) has been > established. If one has not been established when the UAC receives the 180, > it MAY generate ringback locally. If a session is established, the fact that > there is no SDP in the 180 does not change that. Like I wrote in the other mail, even if the session is established, the UAS could use the 180 without SDP to indicate that it will not send any early media/local ringback, and that the UAC should generate a local ringback tone, until another response, provisional or final, is received. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 18:39:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14587 for ; Thu, 20 Jun 2002 18:39:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26964 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 18:40:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25863; Thu, 20 Jun 2002 18:18:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25831 for ; Thu, 20 Jun 2002 18:18:31 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14172 for ; Thu, 20 Jun 2002 18:17:49 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A4B3C8A4013E; Thu, 20 Jun 2002 18:18:27 -0400 Message-ID: <001301c218a8$2a16b9e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" Cc: "Jonathan Rosenberg" , "Flemming Andreasen" , "Mark Watson" , References: <3D101AEF.2C1EB915@lmf.ericsson.se> <3D102A90.9020002@dynamicsoft.com> <3D103079.9F0FBAE3@lmf.ericsson.se> <005401c21858$b6d50e40$2300000a@acmepacket.com> <3D124869.4F7D1F47@lmf.ericsson.se> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Thu, 20 Jun 2002 18:16:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg" > > Hi, > > > ----- Original Message ----- > > From: "Christer Holmberg" > > > > > > > > I am not sure how it will work on the PSTN side, but let's assume the > > > following SIP scenario. > > > > > > I try to call my boss. I reach the company "switch" (which, I guess, in > > this > > > case has be implemented as some kind of SIP B2BUA) which sends me a 183 > > (with > > > SDP) and start transmitting early media telling me that I have now reached > > > this company, please wait, press this button for this, press that button > > for > > > that etc etc etc. Then, the switch "forwards" the INVITE to the actual SIP > > > phone I'm calling to. Now, this SIP phone is not able to generate any > > early > > > media at all, so it sends a 180 (without SDP). Now I assume the switch > > could > > > only forward the 180 to the caller (via the PSTN GW), stop transmitting > > the > > > early media, and expect the PSTN GW to generate a local ringback tone, > > since > > > the called party has been reached. > > > > > > Now, one can argue that this is a complicated scenario, which has nothing > > to > > > do with the basic SIP etc etc. BUT, from the caller's point of view this > > is a > > > normal session setup. It receives the 183 (with SDP) and 180 (without SDP) > > > within the same dialog, and has no idea what is happening at the remote > > site. > > > > > The RTP session is controlled by SDP offers and answers. If a session is > > established, there would need to be a new offer/answer exchange to change > > it. Stopping the RTP flow because the 180 does not have SDP is the wrong > > thing to do. Scenarios like this can be done with the UPDATE method which > > allow the UAS to change the session. The UAS is explicitly forbidden from > > sending subsequent offers in 18x responses (bis-09 line 2119), but it could > > send them in UPDATE requests. > > First, I agree that the UAS is forbidden from sending a subsequent offer in a > 18x, and I also think that using something like > UPDATE for this purpose is too "expensive". > > However, let's assume the following thing: we do NOT update the session. > > So, if the UAC receives a 183 with SDP an early session can be established, and > there MAY be early media - nobody says there MUST be early media. Then, when the > UAS sends 180 without SDP the session still exists from a signalling point of > view, but the UAS indicates that I will stop sending early media and wants the > UAC to generate a local ringback tone. I don't think this idea would break any > rule, would it (the session still exist, but the UAS simply indicates it won't > send any early media - even if it would be "allowed" to do so from a SIP point > of view). How does the UAS tell the UAC that it will stop sending media without updating the session description? A 180 does not mean that the UAS will stop sending media. What you are proposing would require that the meaning of 180 change and then the UAC would be required generate local ringback (it MAY now). Or are you proposing that there will be additional info in the response that will tell the UAC the media will stop? Either way it is not backward compatible with either 2543 or bis-09. Also, there would be two mechisms to do the same thing. > > Then, if the UAS for whatever reason is going to start transmitting early media > again, it could send eg a new 183, with the same SDP as in the previous 183. > Again, this SDP would not be a new offer, simply an indication that the GW > should stop generating local ringback, and start "passing" the RTP media to the > PSTN side again (in general, eg in a PSTN GW case, even if we have an early > media session established between the GW and the UAS, the GW may still, for > whatever reason, choose NOT to send any media to the PSTN side...). > > How does this sound? > I'm sorry, I really do not like it because it changes the way session state is maintained. I think is is much cleaner to do session state maintenance in a consistent way with SDP offers and answers. I don't agree that using UPDATE is too expensive. The 2 extra messages would only happen in scenarios where you need to stop or change the media. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 19:28:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15320 for ; Thu, 20 Jun 2002 19:28:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28624 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 19:29:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28145; Thu, 20 Jun 2002 19:11:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28115 for ; Thu, 20 Jun 2002 19:11:50 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15069 for ; Thu, 20 Jun 2002 19:11:08 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5KNBIV22401 for ; Thu, 20 Jun 2002 18:11:18 -0500 From: "Dean Willis" To: Date: Thu, 20 Jun 2002 18:10:19 -0500 Message-ID: <008901c218af$a5f22b10$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] New SIP draft on congestion safety Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben and I tossed together a draft on making SIP congestion-safe. This should help quite a bit with some usages of SIP, such as in SIMPLE. Please review -- I promise it'll be a controversial topic. The draft is available from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-congestsafe-00.tx t http://www.softarmor.com/sipwg/drafts/draft-willis-sip-congestsafe-00.ht ml http://www.softarmor.com/sipwg/drafts/draft-willis-sip-congestsafe-00.xm l And is being sent to the internet-drafts repository as well. - Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 20 22:25:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18999 for ; Thu, 20 Jun 2002 22:25:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA06206 for sip-archive@odin.ietf.org; Thu, 20 Jun 2002 22:25:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04731; Thu, 20 Jun 2002 22:03:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04700 for ; Thu, 20 Jun 2002 22:03:18 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18469 for ; Thu, 20 Jun 2002 22:02:37 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5L1tJVa009854; Thu, 20 Jun 2002 19:02:39 -0700 (PDT) Received: from cisco.com (rtp-vpn1-525.cisco.com [10.82.226.13]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA15860; Thu, 20 Jun 2002 18:41:22 -0700 (PDT) Message-ID: <3D128443.DB0C87FC@cisco.com> Date: Thu, 20 Jun 2002 21:41:23 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Bob Penfield , Jonathan Rosenberg , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> <3D12493E.2EA34E08@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Bob Penfield wrote: > > > > > > That does not seem correct to me. There is no way for the signaling layer to > > know that there is in-band ringback. The only standard mechanism to tell the > > caller that the calling party is being alerted is the 180 response. The > > signaling layer does know whether or not the session (RTP) has been > > established. If one has not been established when the UAC receives the 180, > > it MAY generate ringback locally. If a session is established, the fact that > > there is no SDP in the 180 does not change that. > > Like I wrote in the other mail, even if the session is established, the UAS > could use the 180 without SDP to indicate that it will not send any early > media/local ringback, and that the UAC should generate a local ringback tone, > until another response, provisional or final, is received. > Details aside, I agree that if there is a way to have locally generated ringback replaced by far-end ringback, there must also be a way to have far-end ringback replaced by locally generated ringback. I also agree that this should all be driven by signaling. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 21 00:50:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21985 for ; Fri, 21 Jun 2002 00:50:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA12454 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 00:51:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11988; Fri, 21 Jun 2002 00:36:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11955 for ; Fri, 21 Jun 2002 00:36:37 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21751 for ; Fri, 21 Jun 2002 00:35:55 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5KHOoph014948; Thu, 20 Jun 2002 10:24:54 -0700 (PDT) Received: from cisco.com (rtp-vpn1-525.cisco.com [10.82.226.13]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA18461; Thu, 20 Jun 2002 10:24:47 -0700 (PDT) Message-ID: <3D120FDF.CD01A376@cisco.com> Date: Thu, 20 Jun 2002 13:24:47 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Jonathan Rosenberg , Mark Watson , "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bob Penfield wrote: > ----- Original Message ----- > From: "Flemming Andreasen" > > > So to be clear: There is no requirement to send back a 180 when the > far-end > > is providing in-band ringback. By virtue of the fact that the offer > allowed > > media to be sent to the UAC, we can simply start sending in-band ringback, > > irrespective of which response code was sent back last (say 183 etc. in > case > > we had used manyfolks). > > > That does not seem correct to me. There is no way for the signaling layer to > know that there is in-band ringback. The only standard mechanism to tell the > caller that the calling party is being alerted is the 180 response. The > signaling layer does know whether or not the session (RTP) has been > established. If one has not been established when the UAC receives the 180, > it MAY generate ringback locally. If a session is established, the fact that > there is no SDP in the 180 does not change that. How do you define "RTP session establishment" ? Are you saying, that if the INVITE contains an offer to receive media, and the 180 includes an answer to send media, then this is by definition an indication of early media and hence there shall not be any local ringback ? -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 21 02:24:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02390 for ; Fri, 21 Jun 2002 02:24:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23247 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 02:24:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22646; Fri, 21 Jun 2002 02:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22614 for ; Fri, 21 Jun 2002 02:06:27 -0400 (EDT) Received: from web21108.mail.yahoo.com (web21108.mail.yahoo.com [216.136.227.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26873 for ; Fri, 21 Jun 2002 02:05:44 -0400 (EDT) Message-ID: <20020621060623.69298.qmail@web21108.mail.yahoo.com> Received: from [203.200.31.14] by web21108.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 23:06:23 PDT Date: Thu, 20 Jun 2002 23:06:23 -0700 (PDT) From: Ranjit Avasarala Reply-To: ranjitka2002@yahoo.com Subject: RE: [Sip] Local vs. Remote ringback on 180 To: David Oliver , "'Christer Holmberg'" Cc: sip@ietf.org In-Reply-To: <493BB8BDBB5AD511A7BB00104B62EE280105FE43@jupiter> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi David I have a query on ur suggestion: like how long are u goin gto wait i.e "press this button" until phone answers. say if the person is on phone for a long time, then what should be the solution Ranjit --- David Oliver wrote: > An interesting feature of this scenario is that for > incoming calls from the > PSTN, the company IP-switch/PBX will need to > generate ringback on behalf of > the callee's no-early-media phone until it answers > the call. This would > reasonably be generated by the same subsystem which > provides the "press this > button" features, until the IP phone is answered. If > the phone is not > answered, the subsystem would provide the > opportunity to redirect the caller > to voice-mail, etc. > > It seems appropriate to use exactly the same > mechanism for IP calls, as this > would simplify the implementation (the PSTN GW would > be handled like IP-only > calls), and prevent confusing the caller. > > Regards, > > David C. Oliver > Principal Engineer > SecureLogix Corp > Email: doliver@securelogix.com > > Tel: 210.402.9669 > Fax: 210.402.6996 > > > -----Original Message----- > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, June 19, 2002 2:19 AM > To: Jonathan Rosenberg > Cc: Flemming Andreasen; Mark Watson; sip@ietf.org > Subject: Re: [Sip] Local vs Remote ringback on 180 > > Hi, > > <...> > > I am not sure how it will work on the PSTN side, but > let's assume the > following SIP scenario. > > I try to call my boss. I reach the company "switch" > (which, I guess, in this > case has be implemented as some kind of SIP B2BUA) > which sends me a 183 > (with > SDP) and start transmitting early media telling me > that I have now reached > this company, please wait, press this button for > this, press that button for > that etc etc etc. Then, the switch "forwards" the > INVITE to the actual SIP > phone I'm calling to. Now, this SIP phone is not > able to generate any early > media at all, so it sends a 180 (without SDP). Now I > assume the switch could > only forward the 180 to the caller (via the PSTN > GW), stop transmitting the > early media, and expect the PSTN GW to generate a > local ringback tone, since > the called party has been reached. > > Now, one can argue that this is a complicated > scenario, which has nothing to > do with the basic SIP etc etc. BUT, from the > caller's point of view this is > a > normal session setup. It receives the 183 (with SDP) > and 180 (without SDP) > within the same dialog, and has no idea what is > happening at the remote > site. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 21 07:08:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07313 for ; Fri, 21 Jun 2002 07:08:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05152 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 07:09:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03853; Fri, 21 Jun 2002 06:42:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03823 for ; Fri, 21 Jun 2002 06:42:49 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06752 for ; Fri, 21 Jun 2002 06:42:05 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5LAgarU014595; Fri, 21 Jun 2002 12:42:36 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5LAgZa9017519; Fri, 21 Jun 2002 13:42:35 +0300 (EET DST) Message-ID: <3D130315.B563BAE0@lmf.ericsson.se> Date: Fri, 21 Jun 2002 13:42:29 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Jonathan Rosenberg , Flemming Andreasen , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D101AEF.2C1EB915@lmf.ericsson.se> <3D102A90.9020002@dynamicsoft.com> <3D103079.9F0FBAE3@lmf.ericsson.se> <005401c21858$b6d50e40$2300000a@acmepacket.com> <3D124869.4F7D1F47@lmf.ericsson.se> <001301c218a8$2a16b9e0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Bob Penfield wrote: > ----- Original Message ----- > From: "Christer Holmberg" > > > > Hi, > > > > > ----- Original Message ----- > > > From: "Christer Holmberg" > > > > > > > > > > > I am not sure how it will work on the PSTN side, but let's assume the > > > > following SIP scenario. > > > > > > > > I try to call my boss. I reach the company "switch" (which, I guess, > in > > > this > > > > case has be implemented as some kind of SIP B2BUA) which sends me a > 183 > > > (with > > > > SDP) and start transmitting early media telling me that I have now > reached > > > > this company, please wait, press this button for this, press that > button > > > for > > > > that etc etc etc. Then, the switch "forwards" the INVITE to the actual > SIP > > > > phone I'm calling to. Now, this SIP phone is not able to generate any > > > early > > > > media at all, so it sends a 180 (without SDP). Now I assume the switch > > > could > > > > only forward the 180 to the caller (via the PSTN GW), stop > transmitting > > > the > > > > early media, and expect the PSTN GW to generate a local ringback tone, > > > since > > > > the called party has been reached. > > > > > > > > Now, one can argue that this is a complicated scenario, which has > nothing > > > to > > > > do with the basic SIP etc etc. BUT, from the caller's point of view > this > > > is a > > > > normal session setup. It receives the 183 (with SDP) and 180 (without > SDP) > > > > within the same dialog, and has no idea what is happening at the > remote > > > site. > > > > > > > The RTP session is controlled by SDP offers and answers. If a session is > > > established, there would need to be a new offer/answer exchange to > change > > > it. Stopping the RTP flow because the 180 does not have SDP is the wrong > > > thing to do. Scenarios like this can be done with the UPDATE method > which > > > allow the UAS to change the session. The UAS is explicitly forbidden > from > > > sending subsequent offers in 18x responses (bis-09 line 2119), but it > could > > > send them in UPDATE requests. > > > > First, I agree that the UAS is forbidden from sending a subsequent offer > in a > > 18x, and I also think that using something like > > UPDATE for this purpose is too "expensive". > > > > However, let's assume the following thing: we do NOT update the session. > > > > So, if the UAC receives a 183 with SDP an early session can be > established, and > > there MAY be early media - nobody says there MUST be early media. Then, > when the > > UAS sends 180 without SDP the session still exists from a signalling point > of > > view, but the UAS indicates that I will stop sending early media and wants > the > > UAC to generate a local ringback tone. I don't think this idea would break > any > > rule, would it (the session still exist, but the UAS simply indicates it > won't > > send any early media - even if it would be "allowed" to do so from a SIP > point > > of view). > > How does the UAS tell the UAC that it will stop sending media without > updating the session description? A 180 does not mean that the UAS will stop > sending media. It DOES indicate that the UAC may/should/whatever generate local ringback, so my proposal was that it at the same time shoud indicate that the UAS is not sending early media -. again, even if the session on a SIGNALLING level remains unchanged. > What you are proposing would require that the meaning of 180 change and then > the UAC would be required generate local ringback (it MAY > now). The UAC would not be required to play ringback. The text bis can still remain as "MAY play ringback tone". That would be an implementation issue (also, the decission can be based what kind of node the UAC is, where in the network it is situated etc etc etc), but the main point is that the UAC would be aware that remote early media/ringback is NOT sent. > Or are you proposing that there will be additional info in the response that > will tell the UAC the media will stop? Either way it is not > backward compatible with either 2543 or bis-09. Also, there would be two > mechisms to do the same thing. My original question WAS if the SDP is a good way to indicate local/remote ringback in the first place, but that is really not related to my proposal above (where I do assume that the SDP is still used as a ringback indicator). > >Then, if the UAS for whatever reason is going to start transmitting early > >media again, it could send eg a new 183, with the same SDP as in the previous > > >183. Again, this SDP would not be a new offer, simply an indication that the > GW > >should stop generating local ringback, and start "passing" the RTP media > >to the PSTN side again (in general, eg in a PSTN GW case, even if we have an > >early media session established between the GW and the UAS, the GW may still, > > >for whatever reason, choose NOT to send any media to the PSTN side...). > > > > How does this sound? > > > I'm sorry, I really do not like it because it changes the way session state > is maintained. I think is is much cleaner to do session state maintenance in > a consistent way with SDP offers and answers. I don't think it changes the session state. The session still remains (like I said earlier, just because we have a session it doesn't mean that media MUST be sent). The UAC would simply choose not to forward any possible media received (if the UAS, even if it sent 180 without SDP still for whatever reason sends media) to the listener (to the PSTN network in the case of a GW). > I don't agree that using UPDATE is too expensive. The 2 extra messages would > only happen in scenarios > where you need to stop or change the media. I still don't understand why I would have to update the signalling session state just because I choose not to send early media at some stage... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 21 07:10:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07353 for ; Fri, 21 Jun 2002 07:10:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05190 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 07:11:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04080; Fri, 21 Jun 2002 06:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04051 for ; Fri, 21 Jun 2002 06:48:12 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06867 for ; Fri, 21 Jun 2002 06:47:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5LAlxRb021707; Fri, 21 Jun 2002 12:47:59 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5LAlwa9017721; Fri, 21 Jun 2002 13:47:58 +0300 (EET DST) Message-ID: <3D13045E.A3A539D5@lmf.ericsson.se> Date: Fri, 21 Jun 2002 13:47:58 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Bob Penfield , Jonathan Rosenberg , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> <3D12493E.2EA34E08@lmf.ericsson.se> <3D128443.DB0C87FC@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Flemming Andreasen wrote: > Christer Holmberg wrote: > > > Bob Penfield wrote: > > > > > > > > > That does not seem correct to me. There is no way for the signaling layer to > > > know that there is in-band ringback. The only standard mechanism to tell the > > > caller that the calling party is being alerted is the 180 response. The > > > signaling layer does know whether or not the session (RTP) has been > > > established. If one has not been established when the UAC receives the 180, > > > it MAY generate ringback locally. If a session is established, the fact that > > > there is no SDP in the 180 does not change that. > > > > Like I wrote in the other mail, even if the session is established, the UAS > > could use the 180 without SDP to indicate that it will not send any early > > media/local ringback, and that the UAC should generate a local ringback tone, > > until another response, provisional or final, is received. > > > > Details aside, I agree that if there is a way to have locally generated ringback > replaced by far-end ringback, there must also be a way to have far-end ringback > replaced by locally generated ringback. I also agree that this should all be > driven by signaling. I agree. I don't think it's a good idea to make the decission based on received media (RTP packages). Even if the UAS stops sending early media, and wants the 180 to generate local ringback, it may still send comfort noise eg, which the media handler can not separate from "real" media. When the UAC recieves 180 without SDP it MAY simply choose not to "forward" the RTP packages to the listener, and instead generate local ringback. Again, from a SIP signalling point of view the session changes unchanged, though. Regards, Christer Holmberg Ericsson Finland > > > -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 21 08:23:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09724 for ; Fri, 21 Jun 2002 08:23:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08475 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 08:24:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07208; Fri, 21 Jun 2002 07:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07019 for ; Fri, 21 Jun 2002 07:54:49 -0400 (EDT) Received: from hotmail.com (f13.law10.hotmail.com [64.4.15.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08750 for ; Fri, 21 Jun 2002 07:54:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Jun 2002 04:54:17 -0700 Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 21 Jun 2002 11:54:17 GMT X-Originating-IP: [192.35.17.22] From: "Salva Rey" To: sip@ietf.org Date: Fri, 21 Jun 2002 11:54:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jun 2002 11:54:17.0636 (UTC) FILETIME=[5F2C0640:01C2191A] Subject: [Sip] Transport Layer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, what should do the transport layer if it receives a messages on a different transport than the one stated in the topmost via Header? I havent read anywhere that the received parameter can contain a transport. best regards, Salva _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 21 09:19:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11416 for ; Fri, 21 Jun 2002 09:19:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA10999 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 09:19:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09975; Fri, 21 Jun 2002 08:57:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09944 for ; Fri, 21 Jun 2002 08:57:37 -0400 (EDT) Received: from seimg0.sei.co.jp (seimg0e.sei.co.jp [133.153.22.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10730 for ; Fri, 21 Jun 2002 08:56:38 -0400 (EDT) Received: from sei-is.sei.co.jp (sei-is.sei.co.jp [133.153.208.201]) by seimg0.sei.co.jp (8.11.6/3.7W) with ESMTP id g5LCuqd10539 for ; Fri, 21 Jun 2002 21:56:52 +0900 Received: from seimh1.seimh.sei.co.jp by sei-is.sei.co.jp (8.8.8/3.6W-02/02/99) id VAA09094; Fri, 21 Jun 2002 21:56:51 +0900 (JST) Received: from pop2.osaka.sei.co.jp ([133.153.206.3]) by seimh1.seimh.sei.co.jp (8.11.6/3.7W) with ESMTP id g5LCucX08515 for ; Fri, 21 Jun 2002 21:56:38 +0900 Received: from [133.153.240.229] by pop2.osaka.sei.co.jp (8.8.8/R8-sei-generic/solaris-1.0-02/27/98) with ESMTP id VAA12705; Fri, 21 Jun 2002 21:56:48 +0900 (JST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 21 Jun 2002 21:56:45 +0900 From: Eiji Tomimura To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about URI parameter "user" and URI Comparison in bis-09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dear all, I have a question regarding "user" URI parameter and URI comparison described in section 19.1.4 of bis-09 In section 19.1.1, it says that if user of SIP-URI is a telephone number, user parameter value "phone" should be present. In section 19.1.4, in case of comparison of two SIP-URIs, if user URI parameter appears in only one URI, they never match. It means, <1234@provider.com> and <1234@provider.com;user=phone> is not equivalent. --- Consider if the location server follows the logic in 19.1.4. If SIP-UA-a register its address-of-record with user URI parameter (i.e., <1234@provider.com;user=phone>), and SIP-UA-b send INVITE without user URI parameter(i.e. <1234@provider.com>), it would receive "404 Not Found" error, because of no matching due to the existence of user URI parameter. How could we solve this scenario. Off course, SIP-UA-a could register both SIP-URI with and without user URI parameter, but I think the spec does not request to do so. Thank you very much for your assistance. Regards, - Eiji Tomimura -- Eiji Tomimura Senior Engineer Communications Technology Dept., Information Technology R&D Laboratories Sumitomo Electric Industries, Ltd. Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: tomimura@sei.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 21 10:17:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14061 for ; Fri, 21 Jun 2002 10:17:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13502 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 10:18:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12288; Fri, 21 Jun 2002 09:53:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12254 for ; Fri, 21 Jun 2002 09:53:54 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12762 for ; Fri, 21 Jun 2002 09:53:12 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jun 2002 08:52:53 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE45@jupiter> From: David Oliver To: "'ranjitka2002@yahoo.com'" , David Oliver , "'Christer Holmberg'" Cc: sip@ietf.org Subject: RE: [Sip] Local vs. Remote ringback on 180 Date: Fri, 21 Jun 2002 08:52:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ranjit, By "press this button", I was referring to Christer's description of traversing a PBX menu system. Regarding how long to wait for a reply, there are several scenarios: o The called IP phone may issue a 480 Temporarily Unavailable or 484 Busy Here after the initial 180 Ringing, due either to policy or user action (e.g. pressing the DND button). o The called IP phone might cease sending 180 Ringing, due to equipment failure or extreme user action (e.g. "yanking the cord") and the switch times out. In these cases, the switch should change from sending ringback to either Send a number unavailable tone, with a 480 Temporarily Unavailable/486 Busy Here message, or Return the caller to the voice mail system. o The called IP phone sends 180 Ringing indefinitely. In this case, the switch will wait indefinitely, or until local policy overrides, or the caller takes action, such as hanging up, or dialing DTMF digits to try another extension. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: doliver@securelogix.com Tel: 210.402.9669 Fax: 210.402.6996 -----Original Message----- From: Ranjit Avasarala [mailto:ranjitka2002@yahoo.com] Sent: Friday, June 21, 2002 1:06 AM To: David Oliver; 'Christer Holmberg' Cc: sip@ietf.org Subject: RE: [Sip] Local vs. Remote ringback on 180 Hi David I have a query on ur suggestion: like how long are u goin gto wait i.e "press this button" until phone answers. say if the person is on phone for a long time, then what should be the solution Ranjit --- David Oliver wrote: > An interesting feature of this scenario is that for > incoming calls from the > PSTN, the company IP-switch/PBX will need to > generate ringback on behalf of > the callee's no-early-media phone until it answers > the call. This would > reasonably be generated by the same subsystem which > provides the "press this > button" features, until the IP phone is answered. If > the phone is not > answered, the subsystem would provide the > opportunity to redirect the caller > to voice-mail, etc. > > It seems appropriate to use exactly the same > mechanism for IP calls, as this > would simplify the implementation (the PSTN GW would > be handled like IP-only > calls), and prevent confusing the caller. > > Regards, > > David C. Oliver > Principal Engineer > SecureLogix Corp > Email: doliver@securelogix.com > > Tel: 210.402.9669 > Fax: 210.402.6996 > > > -----Original Message----- > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, June 19, 2002 2:19 AM > To: Jonathan Rosenberg > Cc: Flemming Andreasen; Mark Watson; sip@ietf.org > Subject: Re: [Sip] Local vs Remote ringback on 180 > > Hi, > > <...> > > I am not sure how it will work on the PSTN side, but > let's assume the > following SIP scenario. > > I try to call my boss. I reach the company "switch" > (which, I guess, in this > case has be implemented as some kind of SIP B2BUA) > which sends me a 183 > (with > SDP) and start transmitting early media telling me > that I have now reached > this company, please wait, press this button for > this, press that button for > that etc etc etc. Then, the switch "forwards" the > INVITE to the actual SIP > phone I'm calling to. Now, this SIP phone is not > able to generate any early > media at all, so it sends a 180 (without SDP). Now I > assume the switch could > only forward the 180 to the caller (via the PSTN > GW), stop transmitting the > early media, and expect the PSTN GW to generate a > local ringback tone, since > the called party has been reached. > > Now, one can argue that this is a complicated > scenario, which has nothing to > do with the basic SIP etc etc. BUT, from the > caller's point of view this is > a > normal session setup. It receives the 183 (with SDP) > and 180 (without SDP) > within the same dialog, and has no idea what is > happening at the remote > site. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 21 11:06:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16147 for ; Fri, 21 Jun 2002 11:06:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16419 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 11:07:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15143; Fri, 21 Jun 2002 10:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15112 for ; Fri, 21 Jun 2002 10:49:00 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15311 for ; Fri, 21 Jun 2002 10:48:18 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.12.3/8.12.3) with ESMTP id g5LElKkX026885; Fri, 21 Jun 2002 14:47:20 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id OAA01320; Fri, 21 Jun 2002 14:48:40 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 08:48:40 -0600 Message-ID: <95CCE2787FB8C2498901DCC301017BE2053EF8@idc1exc0003.corp.global.level3.com> To: christer.holmberg@lmf.ericsson.se Cc: jdrosen@dynamicsoft.com, fandreas@cisco.com, mwatson@nortelnetworks.com, sip@ietf.org, bpenfield@acmepacket.com Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Fri, 21 Jun 2002 08:39:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Christer, A question about all this. Is this possibility of switching from far end generated ringback(or other tones/announcements) to near end generated ringback just theorectical, or do you know of an actual implementation or planned implementation? I'd have to agree with Bob, there are defined mechanisms for changing early media, and it may not be wise to special case ringback. Those mechanisms define what to do entirely based on signaling, no awareness is required of what media may or may not be flowing. I suppose you do have a point though that if media from the UAS stops, a concrete way to signal the UAC to begin locally generated ringback may be useful. If there is such a need, I suggest you write a draft for it. John Hearty Level3 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, June 21, 2002 4:42 AM > To: Bob Penfield > Cc: Jonathan Rosenberg; Flemming Andreasen; Mark Watson; sip@ietf.org > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > > Hi, > > Bob Penfield wrote: > > > ----- Original Message ----- > > From: "Christer Holmberg" > > > > > > Hi, > > > > > > > ----- Original Message ----- > > > > From: "Christer Holmberg" > > > > > > > > > > > > > > I am not sure how it will work on the PSTN side, but > let's assume the > > > > > following SIP scenario. > > > > > > > > > > I try to call my boss. I reach the company "switch" > (which, I guess, > > in > > > > this > > > > > case has be implemented as some kind of SIP B2BUA) > which sends me a > > 183 > > > > (with > > > > > SDP) and start transmitting early media telling me > that I have now > > reached > > > > > this company, please wait, press this button for > this, press that > > button > > > > for > > > > > that etc etc etc. Then, the switch "forwards" the > INVITE to the actual > > SIP > > > > > phone I'm calling to. Now, this SIP phone is not able > to generate any > > > > early > > > > > media at all, so it sends a 180 (without SDP). Now I > assume the switch > > > > could > > > > > only forward the 180 to the caller (via the PSTN GW), stop > > transmitting > > > > the > > > > > early media, and expect the PSTN GW to generate a > local ringback tone, > > > > since > > > > > the called party has been reached. > > > > > > > > > > Now, one can argue that this is a complicated > scenario, which has > > nothing > > > > to > > > > > do with the basic SIP etc etc. BUT, from the caller's > point of view > > this > > > > is a > > > > > normal session setup. It receives the 183 (with SDP) > and 180 (without > > SDP) > > > > > within the same dialog, and has no idea what is > happening at the > > remote > > > > site. > > > > > > > > > The RTP session is controlled by SDP offers and > answers. If a session is > > > > established, there would need to be a new offer/answer > exchange to > > change > > > > it. Stopping the RTP flow because the 180 does not have > SDP is the wrong > > > > thing to do. Scenarios like this can be done with the > UPDATE method > > which > > > > allow the UAS to change the session. The UAS is > explicitly forbidden > > from > > > > sending subsequent offers in 18x responses (bis-09 line > 2119), but it > > could > > > > send them in UPDATE requests. > > > > > > First, I agree that the UAS is forbidden from sending a > subsequent offer > > in a > > > 18x, and I also think that using something like > > > UPDATE for this purpose is too "expensive". > > > > > > However, let's assume the following thing: we do NOT > update the session. > > > > > > So, if the UAC receives a 183 with SDP an early session can be > > established, and > > > there MAY be early media - nobody says there MUST be > early media. Then, > > when the > > > UAS sends 180 without SDP the session still exists from a > signalling point > > of > > > view, but the UAS indicates that I will stop sending > early media and wants > > the > > > UAC to generate a local ringback tone. I don't think this > idea would break > > any > > > rule, would it (the session still exist, but the UAS > simply indicates it > > won't > > > send any early media - even if it would be "allowed" to > do so from a SIP > > point > > > of view). > > > > How does the UAS tell the UAC that it will stop sending > media without > > updating the session description? A 180 does not mean that > the UAS will stop > > sending media. > > It DOES indicate that the UAC may/should/whatever generate > local ringback, so my > proposal was that it at the same time shoud indicate that the > UAS is not sending > early media -. again, even if the session on a SIGNALLING > level remains > unchanged. > > > What you are proposing would require that the meaning of > 180 change and then > > the UAC would be required generate local ringback (it MAY > > now). > > The UAC would not be required to play ringback. The text bis > can still remain as > "MAY play ringback tone". That would be an implementation > issue (also, the > decission can be based what kind of node the UAC is, where in > the network it is > situated etc etc etc), but the main point is that the UAC > would be aware that > remote early media/ringback is NOT sent. > > > Or are you proposing that there will be additional info in > the response that > > will tell the UAC the media will stop? Either way it is not > > backward compatible with either 2543 or bis-09. Also, there > would be two > > mechisms to do the same thing. > > My original question WAS if the SDP is a good way to indicate > local/remote > ringback in the first place, but that is really not related > to my proposal above > (where I do assume that the SDP is still used as a ringback > indicator). > > > >Then, if the UAS for whatever reason is going to start > transmitting early > > >media again, it could send eg a new 183, with the same SDP > as in the previous > > > > >183. Again, this SDP would not be a new offer, simply an > indication that the > > GW > > >should stop generating local ringback, and start "passing" > the RTP media > > >to the PSTN side again (in general, eg in a PSTN GW case, > even if we have an > > >early media session established between the GW and the > UAS, the GW may still, > > > > >for whatever reason, choose NOT to send any media to the > PSTN side...). > > > > > > How does this sound? > > > > > > I'm sorry, I really do not like it because it changes the > way session state > > is maintained. I think is is much cleaner to do session > state maintenance in > > a consistent way with SDP offers and answers. > > I don't think it changes the session state. The session still > remains (like I > said earlier, just because we have a session it doesn't mean > that media MUST be > sent). The UAC would simply choose not to forward any > possible media received > (if the UAS, even if it sent 180 without SDP still for > whatever reason sends > media) to the listener (to the PSTN network in the case of a GW). > > > I don't agree that using UPDATE is too expensive. The 2 > extra messages would > > only happen in scenarios > > where you need to stop or change the media. > > I still don't understand why I would have to update the > signalling session state > just because I choose not to send early media at some stage... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 21 12:24:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20660 for ; Fri, 21 Jun 2002 12:24:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22226 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 12:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21216; Fri, 21 Jun 2002 12:03:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21189 for ; Fri, 21 Jun 2002 12:03:05 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19265 for ; Fri, 21 Jun 2002 12:02:24 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AE362A40228; Fri, 21 Jun 2002 12:03:02 -0400 Message-ID: <00d701c2193c$984e5dc0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , "Flemming Andreasen" Cc: "Jonathan Rosenberg" , "Mark Watson" , References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> <3D12493E.2EA34E08@lmf.ericsson.se> <3D128443.DB0C87FC@cisco.com> <3D13045E.A3A539D5@lmf.ericsson.se> Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Fri, 21 Jun 2002 11:59:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, one last time, then I will shut up. This is my opinion/understanding of how this should work based on bis-09, offer/answer, 100rel, and update drafts. There are 2 layers here. The SIP messages control the state of the dialog(s). The SDP contained in the SIP messages control the state of the multimedia session. When a UAC has made an SDP offer and received an SDP answer that indicates that the UAS is sending one or more streams, then the UAC can expect to receive RTP packets on the accepted streams. This is independent from which SIP messages the SDP is in. If the answer was contained in a reliable provisional response, a subsequent response without SDP does not affect the state of the multimedia session as established by the previous offer/answer. Therefore, a reliable 183 with the SDP answer will establish the multimedia session. A subsequent 180 without SDP does not change the state of that multimedia session. It simply indicates that the called party of the "dialog" is being alerted. The UAC should still be ready to receive RTP on the previously accepted streams. It cannot assume that the UAS has stopped the media flow. The only mechanism defined in the specs for the UAS to indicate that it will stop sending media is an UPDATE with a new offer. Now, as the whether the UI on the UAC actually plays the received RTP, I agree that this is an implementation issue since the specs do not define UIs. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg" To: "Flemming Andreasen" Cc: "Bob Penfield" ; "Jonathan Rosenberg" ; "Mark Watson" ; Sent: Friday, June 21, 2002 6:47 AM Subject: Re: [Sip] Local vs Remote ringback on 180 > > Hi, > > Flemming Andreasen wrote: > > > Christer Holmberg wrote: > > > > > Bob Penfield wrote: > > > > > > > > > > > > That does not seem correct to me. There is no way for the signaling layer to > > > > know that there is in-band ringback. The only standard mechanism to tell the > > > > caller that the calling party is being alerted is the 180 response. The > > > > signaling layer does know whether or not the session (RTP) has been > > > > established. If one has not been established when the UAC receives the 180, > > > > it MAY generate ringback locally. If a session is established, the fact that > > > > there is no SDP in the 180 does not change that. > > > > > > Like I wrote in the other mail, even if the session is established, the UAS > > > could use the 180 without SDP to indicate that it will not send any early > > > media/local ringback, and that the UAC should generate a local ringback tone, > > > until another response, provisional or final, is received. > > > > > > > Details aside, I agree that if there is a way to have locally generated ringback > > replaced by far-end ringback, there must also be a way to have far-end ringback > > replaced by locally generated ringback. I also agree that this should all be > > driven by signaling. > > I agree. I don't think it's a good idea to make the decission based on received > media (RTP packages). Even if the UAS stops sending early media, and wants the 180 > to generate local ringback, it may still send comfort noise eg, which the media > handler can not separate from "real" media. When the UAC recieves 180 without SDP it > MAY simply choose not to "forward" the RTP packages to the listener, and instead > generate local ringback. Again, from a SIP signalling point of view the session > changes unchanged, though. > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > -- Flemming > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 21 16:24:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00395 for ; Fri, 21 Jun 2002 16:24:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07212 for sip-archive@odin.ietf.org; Fri, 21 Jun 2002 16:25:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06474; Fri, 21 Jun 2002 16:03:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06443 for ; Fri, 21 Jun 2002 16:03:27 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29858 for ; Fri, 21 Jun 2002 16:02:46 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5LK2loF008306; Fri, 21 Jun 2002 16:02:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 16:02:52 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A241@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Salva Rey'" , sip@ietf.org Subject: RE: [Sip] Transport Layer Date: Fri, 21 Jun 2002 16:02:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Honor the stated transport. That is, if you receive a message via TCP with a topmost via starting with "SIP/2.0/UDP", you don't modify it in any way -- and, when it comes time to send the response, you use UDP. Note, however, that this shouldn't really happen much, if at all, in practice. /a > -----Original Message----- > From: Salva Rey [mailto:salreyca@hotmail.com] > Sent: Friday, June 21, 2002 6:54 > To: sip@ietf.org > Subject: [Sip] Transport Layer > > > > > Hi, > > what should do the transport layer if it receives a messages > on a different > transport than the one stated in the topmost via Header? I > havent read > anywhere that the received parameter can contain a transport. > > best regards, > Salva > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat Jun 22 06:11:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23203 for ; Sat, 22 Jun 2002 06:11:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11650 for sip-archive@odin.ietf.org; Sat, 22 Jun 2002 06:12:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10926; Sat, 22 Jun 2002 05:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10894 for ; Sat, 22 Jun 2002 05:52:45 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22936 for ; Sat, 22 Jun 2002 05:52:01 -0400 (EDT) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g5M9irH10055; Sat, 22 Jun 2002 15:14:59 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BE0.003633B1 ; Sat, 22 Jun 2002 15:22:01 +0530 X-Lotus-FromDomain: HSSBLR To: Eiji Tomimura cc: sip@ietf.org Message-ID: <65256BE0.003632BE.00@sampark.hss.hns.com> Date: Sat, 22 Jun 2002 15:21:58 +0530 Subject: Re: [Sip] Question about URI parameter "user" and URI Comparison in bis-09 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Eiji, As a registrar you are expected to canonicalize the To header URL before storing it as the address-of-record in your location service. Similarly, when a request is received by your proxy, it should canonicalize the Request-URI before looking it up in the location-service. Canonicalizing the address involves removal of all URL parameters (including the URI parameters). In other words, the address-of-record in your case should just be <1234@provider.com> irrespective of whether the user registers as <1234@provider.com> or <1234@provider.com;user=phone> Ref: Lines 1704-1708 for Registrar behaviour and Lines 2558-2560 that describes the proxy behaviour with respect to the above. Regards, Subhash Nayak Hughes Software Systems http://www.hssworld.com Eiji Tomimura on 06/21/2002 06:26:45 PM To: sip@ietf.org cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Sip] Question about URI parameter "user" and URI Comparison in bis-09 Dear all, I have a question regarding "user" URI parameter and URI comparison described in section 19.1.4 of bis-09 In section 19.1.1, it says that if user of SIP-URI is a telephone number, user parameter value "phone" should be present. In section 19.1.4, in case of comparison of two SIP-URIs, if user URI parameter appears in only one URI, they never match. It means, <1234@provider.com> and <1234@provider.com;user=phone> is not equivalent. --- Consider if the location server follows the logic in 19.1.4. If SIP-UA-a register its address-of-record with user URI parameter (i.e., <1234@provider.com;user=phone>), and SIP-UA-b send INVITE without user URI parameter(i.e. <1234@provider.com>), it would receive "404 Not Found" error, because of no matching due to the existence of user URI parameter. How could we solve this scenario. Off course, SIP-UA-a could register both SIP-URI with and without user URI parameter, but I think the spec does not request to do so. Thank you very much for your assistance. Regards, - Eiji Tomimura -- Eiji Tomimura Senior Engineer Communications Technology Dept., Information Technology R&D Laboratories Sumitomo Electric Industries, Ltd. Phone: +81-6-6466-5643 Fax: +81-6-6466-5732 Email: tomimura@sei.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jun 23 06:25:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23509 for ; Sun, 23 Jun 2002 06:25:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04023 for sip-archive@odin.ietf.org; Sun, 23 Jun 2002 06:25:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03722; Sun, 23 Jun 2002 06:01:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03689 for ; Sun, 23 Jun 2002 06:01:20 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23272 for ; Sun, 23 Jun 2002 06:00:37 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5NA0orU006842; Sun, 23 Jun 2002 12:00:51 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5NA0ma9004351; Sun, 23 Jun 2002 13:00:49 +0300 (EET DST) Message-ID: <3D159C4B.7081E4AB@lmf.ericsson.se> Date: Sun, 23 Jun 2002 13:00:43 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: jdrosen@dynamicsoft.com, fandreas@cisco.com, mwatson@nortelnetworks.com, sip@ietf.org, bpenfield@acmepacket.com Subject: Re: [Sip] Local vs Remote ringback on 180 References: <95CCE2787FB8C2498901DCC301017BE2053EF8@idc1exc0003.corp.global.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > A question about all this. Is this possibility of switching from far end > generated ringback(or other tones/announcements) to near end generated > ringback just theorectical, or do you know of an actual implementation or > planned implementation? Like I wrote earlier, this "switch" is very unlikely to take place if the remote side consists of a single SIP node. I did give a scenario, where the remote side consists of a "system" of SIP nodes, where this switch DID take place. I guess I'm the wrong person to say if a scenario like that, or similar, is only theoretical or not. I would be very interested in hearing the operators point of view on this. > I'd have to agree with Bob, there are defined mechanisms for changing early > media, and it may not be wise to special case ringback. Those mechanisms > define what to do entirely based on signaling, no awareness is required of > what media may or may not be flowing. Again, I am NOT proposing any change in the early media mechanism. I see it more as CLARIFYING what IS already written (in bis-09 and the ISUP/SIP drafts). > I suppose you do have a point though that if media from the UAS stops, a > concrete way to signal the UAC to begin locally generated ringback may be > useful. If there is such a need, I suggest you write a draft for it. Again, that was my original question: can we really use the current 180-with/without-SDP mechanism for this (with the SDP simply as a ringback indicator), or DO we need to define something new? :) Thanks for your comments! Regards, Christer Holmberg Ericsson Finland > > > John Hearty > Level3 > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, June 21, 2002 4:42 AM > > To: Bob Penfield > > Cc: Jonathan Rosenberg; Flemming Andreasen; Mark Watson; sip@ietf.org > > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > > > > > > Hi, > > > > Bob Penfield wrote: > > > > > ----- Original Message ----- > > > From: "Christer Holmberg" > > > > > > > > Hi, > > > > > > > > > ----- Original Message ----- > > > > > From: "Christer Holmberg" > > > > > > > > > > > > > > > > > I am not sure how it will work on the PSTN side, but > > let's assume the > > > > > > following SIP scenario. > > > > > > > > > > > > I try to call my boss. I reach the company "switch" > > (which, I guess, > > > in > > > > > this > > > > > > case has be implemented as some kind of SIP B2BUA) > > which sends me a > > > 183 > > > > > (with > > > > > > SDP) and start transmitting early media telling me > > that I have now > > > reached > > > > > > this company, please wait, press this button for > > this, press that > > > button > > > > > for > > > > > > that etc etc etc. Then, the switch "forwards" the > > INVITE to the actual > > > SIP > > > > > > phone I'm calling to. Now, this SIP phone is not able > > to generate any > > > > > early > > > > > > media at all, so it sends a 180 (without SDP). Now I > > assume the switch > > > > > could > > > > > > only forward the 180 to the caller (via the PSTN GW), stop > > > transmitting > > > > > the > > > > > > early media, and expect the PSTN GW to generate a > > local ringback tone, > > > > > since > > > > > > the called party has been reached. > > > > > > > > > > > > Now, one can argue that this is a complicated > > scenario, which has > > > nothing > > > > > to > > > > > > do with the basic SIP etc etc. BUT, from the caller's > > point of view > > > this > > > > > is a > > > > > > normal session setup. It receives the 183 (with SDP) > > and 180 (without > > > SDP) > > > > > > within the same dialog, and has no idea what is > > happening at the > > > remote > > > > > site. > > > > > > > > > > > The RTP session is controlled by SDP offers and > > answers. If a session is > > > > > established, there would need to be a new offer/answer > > exchange to > > > change > > > > > it. Stopping the RTP flow because the 180 does not have > > SDP is the wrong > > > > > thing to do. Scenarios like this can be done with the > > UPDATE method > > > which > > > > > allow the UAS to change the session. The UAS is > > explicitly forbidden > > > from > > > > > sending subsequent offers in 18x responses (bis-09 line > > 2119), but it > > > could > > > > > send them in UPDATE requests. > > > > > > > > First, I agree that the UAS is forbidden from sending a > > subsequent offer > > > in a > > > > 18x, and I also think that using something like > > > > UPDATE for this purpose is too "expensive". > > > > > > > > However, let's assume the following thing: we do NOT > > update the session. > > > > > > > > So, if the UAC receives a 183 with SDP an early session can be > > > established, and > > > > there MAY be early media - nobody says there MUST be > > early media. Then, > > > when the > > > > UAS sends 180 without SDP the session still exists from a > > signalling point > > > of > > > > view, but the UAS indicates that I will stop sending > > early media and wants > > > the > > > > UAC to generate a local ringback tone. I don't think this > > idea would break > > > any > > > > rule, would it (the session still exist, but the UAS > > simply indicates it > > > won't > > > > send any early media - even if it would be "allowed" to > > do so from a SIP > > > point > > > > of view). > > > > > > How does the UAS tell the UAC that it will stop sending > > media without > > > updating the session description? A 180 does not mean that > > the UAS will stop > > > sending media. > > > > It DOES indicate that the UAC may/should/whatever generate > > local ringback, so my > > proposal was that it at the same time shoud indicate that the > > UAS is not sending > > early media -. again, even if the session on a SIGNALLING > > level remains > > unchanged. > > > > > What you are proposing would require that the meaning of > > 180 change and then > > > the UAC would be required generate local ringback (it MAY > > > now). > > > > The UAC would not be required to play ringback. The text bis > > can still remain as > > "MAY play ringback tone". That would be an implementation > > issue (also, the > > decission can be based what kind of node the UAC is, where in > > the network it is > > situated etc etc etc), but the main point is that the UAC > > would be aware that > > remote early media/ringback is NOT sent. > > > > > Or are you proposing that there will be additional info in > > the response that > > > will tell the UAC the media will stop? Either way it is not > > > backward compatible with either 2543 or bis-09. Also, there > > would be two > > > mechisms to do the same thing. > > > > My original question WAS if the SDP is a good way to indicate > > local/remote > > ringback in the first place, but that is really not related > > to my proposal above > > (where I do assume that the SDP is still used as a ringback > > indicator). > > > > > >Then, if the UAS for whatever reason is going to start > > transmitting early > > > >media again, it could send eg a new 183, with the same SDP > > as in the previous > > > > > > >183. Again, this SDP would not be a new offer, simply an > > indication that the > > > GW > > > >should stop generating local ringback, and start "passing" > > the RTP media > > > >to the PSTN side again (in general, eg in a PSTN GW case, > > even if we have an > > > >early media session established between the GW and the > > UAS, the GW may still, > > > > > > >for whatever reason, choose NOT to send any media to the > > PSTN side...). > > > > > > > > How does this sound? > > > > > > > > > I'm sorry, I really do not like it because it changes the > > way session state > > > is maintained. I think is is much cleaner to do session > > state maintenance in > > > a consistent way with SDP offers and answers. > > > > I don't think it changes the session state. The session still > > remains (like I > > said earlier, just because we have a session it doesn't mean > > that media MUST be > > sent). The UAC would simply choose not to forward any > > possible media received > > (if the UAS, even if it sent 180 without SDP still for > > whatever reason sends > > media) to the listener (to the PSTN network in the case of a GW). > > > > > I don't agree that using UPDATE is too expensive. The 2 > > extra messages would > > > only happen in scenarios > > > where you need to stop or change the media. > > > > I still don't understand why I would have to update the > > signalling session state > > just because I choose not to send early media at some stage... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sun Jun 23 06:32:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23641 for ; Sun, 23 Jun 2002 06:32:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04671 for sip-archive@odin.ietf.org; Sun, 23 Jun 2002 06:32:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03997; Sun, 23 Jun 2002 06:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03956 for ; Sun, 23 Jun 2002 06:20:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23463 for ; Sun, 23 Jun 2002 06:19:19 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5NAJprU007711; Sun, 23 Jun 2002 12:19:51 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5NAJoa9005061; Sun, 23 Jun 2002 13:19:50 +0300 (EET DST) Message-ID: <3D15A0C5.872C08C1@lmf.ericsson.se> Date: Sun, 23 Jun 2002 13:19:50 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Flemming Andreasen , Jonathan Rosenberg , Mark Watson , sip@ietf.org Subject: Re: [Sip] Local vs Remote ringback on 180 References: <3D0A1347.C155C23C@cisco.com> <3D0FB29D.7070505@dynamicsoft.com> <3D10A1CA.8EC93753@cisco.com> <003e01c21857$7208dcc0$2300000a@acmepacket.com> <3D12493E.2EA34E08@lmf.ericsson.se> <3D128443.DB0C87FC@cisco.com> <3D13045E.A3A539D5@lmf.ericsson.se> <00d701c2193c$984e5dc0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bob, > OK, one last time, then I will shut up. I'll TRY to do the same :) If people think this is not worth discussing I will assume it's all implementation issue and stop the thread. IF people want to discuss it more, maybe we can do it private, and/or in Yokohama? > This is my opinion/understanding of how this should work based on bis-09, > offer/answer, 100rel, and update > drafts. > > There are 2 layers here. The SIP messages control the state of the > dialog(s). The SDP contained in the SIP messages control the state of the > multimedia session. > > When a UAC has made an SDP offer and received an SDP answer that indicates > that the UAS is sending one or more streams, then the UAC can expect to > receive RTP packets on the accepted streams. This is independent from which > SIP messages the SDP is in. Agree. > If the answer was contained in a reliable provisional response, a subsequent > response without SDP does not affect the state of the multimedia session as > established by the previous offer/answer. If you mean that it doesn't change the state from a SIP signalling point of view I still agree :) However, if you mean that it doesn't change what is sent to the listener either I think what is written in some drafts is wrong. It IS said (at least that is my understanding) that SDP/no-SDP in 180 DOES indicate if a remote ringback tone will be generated or not. > Therefore, a reliable 183 with the SDP answer will establish the multimedia > session. A subsequent 180 without SDP does not change the state of that > multimedia session. It simply indicates that the called party of the > "dialog" is being alerted. The UAC should still be ready to receive RTP on > the previously accepted streams. I never said it shouldn't accept media - I simply said the UAC could choose not to play that media to the caller, and may instead choose to generate a local ringback tone. Again, from a SIP point of view the early session is still "active". > It cannot assume that the UAS has stopped the media flow. Well, this is where you hit the orginial question of this thread :) So, we can NOT have a way to indicate there there will be no "useful" media (again, the session IS active and unchanged, and the UAS CAN still send RTP packages), and that we instead will have to change the whole signalling state of the session? > The only mechanism defined in the specs for the UAS to > indicate that it will stop sending media is an UPDATE with a new offer. I agree, but I think that that is a separate issue. I am not talking about making "forbidding" the UAS to send early media (ie changing the media mode to "inactive", or something similar), I am simply talking about indicating that the possible media is of no interest, that the UAC MAY choose not to play it to the caller, and that the UAC MAY choose to generate a local ringback tone. > Now, as the whether the UI on the UAC actually plays the received RTP, I > agree that this is an implementation issue since the specs do not define > UIs. I agree it could be an implementation issue, but in that case I wonder why the bis-09- and ISUP/SIP mapping drafts talk about SDP in 180 and ringback tone generation in the first place the way it is written now... I am just proposing a clarification on that. Regards, Christer Holmberg Ericsson Finland > > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Flemming Andreasen" > Cc: "Bob Penfield" ; "Jonathan Rosenberg" > ; "Mark Watson" ; > > Sent: Friday, June 21, 2002 6:47 AM > Subject: Re: [Sip] Local vs Remote ringback on 180 > > > > > Hi, > > > > Flemming Andreasen wrote: > > > > > Christer Holmberg wrote: > > > > > > > Bob Penfield wrote: > > > > > > > > > > > > > > > That does not seem correct to me. There is no way for the signaling > layer to > > > > > know that there is in-band ringback. The only standard mechanism to > tell the > > > > > caller that the calling party is being alerted is the 180 response. > The > > > > > signaling layer does know whether or not the session (RTP) has been > > > > > established. If one has not been established when the UAC receives > the 180, > > > > > it MAY generate ringback locally. If a session is established, the > fact that > > > > > there is no SDP in the 180 does not change that. > > > > > > > > Like I wrote in the other mail, even if the session is established, > the UAS > > > > could use the 180 without SDP to indicate that it will not send any > early > > > > media/local ringback, and that the UAC should generate a local > ringback tone, > > > > until another response, provisional or final, is received. > > > > > > > > > > Details aside, I agree that if there is a way to have locally generated > ringback > > > replaced by far-end ringback, there must also be a way to have far-end > ringback > > > replaced by locally generated ringback. I also agree that this should > all be > > > driven by signaling. > > > > I agree. I don't think it's a good idea to make the decission based on > received > > media (RTP packages). Even if the UAS stops sending early media, and wants > the 180 > > to generate local ringback, it may still send comfort noise eg, which the > media > > handler can not separate from "real" media. When the UAC recieves 180 > without SDP it > > MAY simply choose not to "forward" the RTP packages to the listener, and > instead > > generate local ringback. Again, from a SIP signalling point of view the > session > > changes unchanged, though. > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > -- Flemming > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 24 00:46:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12554 for ; Mon, 24 Jun 2002 00:46:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10884 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 00:47:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09747; Mon, 24 Jun 2002 00:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09685 for ; Mon, 24 Jun 2002 00:26:41 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12258; Mon, 24 Jun 2002 00:25:58 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5O4Q9dg000665; Sun, 23 Jun 2002 21:26:09 -0700 (PDT) Received: from open-131-161-248-85.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with ESMTP id AAH99481; Sun, 23 Jun 2002 21:26:08 -0700 (PDT) Date: Sun, 23 Jun 2002 21:26:26 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: "'sipping@ietf.org'" , sip@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8C58D7FA-872A-11D6-838E-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Subject: [Sip] 3gpp P-headers in combined form Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A new draft was just submitted that contains several of the 3GPP proposed P- headers in one document: P-Associated-URI P-Called-Party-ID P-Visited-Network-ID P-Access-Network-Info P-Charging-Function-Addresses P-Charging-Vector Other than editorial and restructuring changes, a couple of "SHOULD use hop-by-hop message integrity" statements were upgraded to MUST strength. If you reviewed the original documents please look over the combined work over the next few days to make sure that no errors were introduced during the combining. Until it appears in the archive, it is available on softarmor: http://www.softarmor.com/sipping/drafts/draft-garcia-sipping-3gpp-p-headers-00. html http://www.softarmor.com/sipping/drafts/draft-garcia-sipping-3gpp-p-headers-00. txt 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 daemon@ns.ietf.org Mon Jun 24 03:54:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25000 for ; Mon, 24 Jun 2002 03:54:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26578 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 03:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26075; Mon, 24 Jun 2002 03:40:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26009 for ; Mon, 24 Jun 2002 03:40:07 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24719; Mon, 24 Jun 2002 03:39:24 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5O7e4Rb009068; Mon, 24 Jun 2002 09:40:04 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5O7e3a9026066; Mon, 24 Jun 2002 10:40:03 +0300 (EET DST) Message-ID: <3D16CCD2.909AE477@lmf.ericsson.se> Date: Mon, 24 Jun 2002 10:40:02 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip , rohc References: <3CD10F64.D62B1E78@lmf.ericsson.se> <3D101E32.6040606@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, inline: Jonathan Rosenberg wrote: > > more old email. So sue me. Responses inline: > > Gonzalo Camarillo wrote: > > Jonathan, > > >>> A proxy performing Record-Route inspects the Record-Route and the > >>> Contact header fields in the response. It looks for the URI of > >> the > >>> next upstream (closer to the user agent client) hop in the route > >> set. > >>> If this URI contains the parameter comp=sigcomp, the proxy SHOULD > >>add > >>> comp=sigcomp to its entry in the Record-Route header field. > >> > >>Why? If the upstream element doesn't support this extension, the > >>sigcomp > >>parameter is ignored, and the message is sent uncompressed. Thats what > >>you want. The decision about whether to insert a URI with the comp > >>parameter should be entirely a local one. > > > > > > This covers the following scenario: > > > > UAC----P1-----P2-----UAS > > > > The UAC sends an INITE to UAS. P2 records route, but P1 does not. > > When the 200 OK for the INVITE reaches P2, the contact and RR header > > fields will look like this: > > > > Contact: UAS@domain.com;comp=sigcomp > > RR: P2 > > > > If P2 does not add comp=sigcomp to his entry in the RR, UAC will be able > > to receive compressed traffic (the contact has comp=sigcomp), but will > > be unable to send compress traffic (the RR entry for P2 does not have > > it). > > Why doesn't it? If a proxy is sigcomp enabled, it should have > record-routed with sigcomp parameter in the first place. > If we specified that a proxy that supports SigComp MUST use it, everything would work as you stated. However, I would like a proxy to have the possibility of not using SigComp even if it supports it. Section 7 of: http://search.ietf.org/internet-drafts/draft-camarillo-sip-compression-01.txt contains an example about the scenario I was describing in my previous mail. Thanks for the comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 24 04:03:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25158 for ; Mon, 24 Jun 2002 04:03:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27408 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 04:04:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26386; Mon, 24 Jun 2002 03:48:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26355 for ; Mon, 24 Jun 2002 03:48:12 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24831 for ; Mon, 24 Jun 2002 03:47:29 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5O7m8Rb012267; Mon, 24 Jun 2002 09:48:08 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5O7m7a9026901; Mon, 24 Jun 2002 10:48:08 +0300 (EET DST) Message-ID: <3D16CEB7.7646A16A@lmf.ericsson.se> Date: Mon, 24 Jun 2002 10:48:07 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , sip Subject: Re: [Sip] Reason version 01 References: <3CE36C71.7B160EA8@lmf.ericsson.se> <3D0F96E4.80301@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, inline: Gonzalo wrote: > > However, I do not think we have any problem. The reason draft can speak > > about 155 responses without referencing any RFC. It is enough that the > > 155 status code is registered wherever we are registering status codes > > (is it already in IANA or we still have a temporary repository?). > > > > Does anybody see a problem with this approach? > Jonathan wrote: > I think its fine to be vague, or to simply strike the references > completely from reason, so that the herfp draft defines the usage of > Reason in 155. However, the change you suggest above was not made, and > it seems reason-01 has been approved..... The references of reason-01 look like this: 8 Normative References [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [2] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. references [1] and [2] need to be updated anyway. The RFC editor will take care of that. Then, the first time 155 is mentioned, there is a reference to [2]. I can remove the reference, and speak about 155 without referencing any document. Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jun 24 06:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27742 for ; Mon, 24 Jun 2002 06:01:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05305 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 06:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03441; Mon, 24 Jun 2002 05:31:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03397 for ; Mon, 24 Jun 2002 05:30:59 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27026 for ; Mon, 24 Jun 2002 05:30:16 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 24 Jun 2002 11:29:30 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 11:30:06 +0200 Message-Id: From: "Jesske, R" To: Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org Cc: "Pinker, Gerold" , Robert.Benz@telekom.de, "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , DieterK@telekom.de, "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: AW: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Mon, 24 Jun 2002 11:30:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA03398 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Dear all, I'm sorry about opening a new issue regarding the Reason draft. At the moment the Reason Draft doesn't contain the location and diagnostic field of the Q.763/Q.730 Cause indicators parameters (described within Q.850 1998). The location and diagnostic field is in some cases important for services and procedures within the network. E.g. Cause Value 34 could be a normal release indicating a congestion in a transit or international network but Cause Value 34 with a diagnostic field including the CCBS possible indication coming from a private network indicates a busy network where the CCBS service is possible. CCBS is within ISDN networks a frequently used service. For the future interworking of SIP with ISDN networks the indication of location and diagnostics is a extension that enables the CCBS over networks. The reason draft is OK for only indicating the reason of a release but for service interworking with the PSTN it would be better to have also the location and reason available. Best regards Roland Jesske Deutsche Telekom AG T Com Zentrale Section T38; Signalling, Gateways and Switching Systems Roland Jesske, T38a12 Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone:  +49 6151 83-5940 Fax:    +49 6151 83-4577 mailto: r.jesske@telekom.de > -----Ursprüngliche Nachricht----- > Von: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Gesendet am: Dienstag, 14. Mai 2002 12:19 > An: sip > Betreff: [Sip] Reason version 01 > > Folks, > > I have just released version 01 of the Reason draft. Until it > appears in > the archives, you can fetch it from: > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-re > ason-01.txt > > Only minor modifications has been done since version 00. > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 10:30:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08875 for ; Mon, 24 Jun 2002 10:30:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19150 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 10:31:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17060; Mon, 24 Jun 2002 09:52:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17029 for ; Mon, 24 Jun 2002 09:52:06 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06921 for ; Mon, 24 Jun 2002 09:51:23 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5ODq0o22897; Mon, 24 Jun 2002 09:52:00 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA04521; Mon, 24 Jun 2002 08:51:58 -0500 (CDT) Message-ID: <3D1723F9.504@lucent.com> Date: Mon, 24 Jun 2002 08:51:53 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Jonathan Rosenberg , sip Subject: Re: [Sip] Reason version 01 References: <3CE36C71.7B160EA8@lmf.ericsson.se> <3D0F96E4.80301@dynamicsoft.com> <3D16CEB7.7646A16A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Then, the first time 155 is mentioned, there is a reference to [2]. I > can remove the reference, and speak about 155 without referencing any > document. That will lead to some confusion; people familiar with the base SIP spec will instinctively look at it for the definition of 155. But, if that's the best that can be done, then so be it. At least it is a 1xx class provisional response, which kind of explains its intention. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 10:39:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09571 for ; Mon, 24 Jun 2002 10:39:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19438 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 10:40:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18097; Mon, 24 Jun 2002 10:07:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18066 for ; Mon, 24 Jun 2002 10:07:22 -0400 (EDT) Received: from ronda.convergentnet.com (firebox.ConvergentNet.COM [204.253.57.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07621 for ; Mon, 24 Jun 2002 10:06:38 -0400 (EDT) Received: by RONDA with Internet Mail Service (5.5.2655.55) id ; Mon, 24 Jun 2002 09:56:17 -0400 Message-ID: From: "Gokhale, Nandini" To: "'sip@ietf.org'" Date: Mon, 24 Jun 2002 09:56:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] UAC behavior: Final Reponse received before completion of PRACK Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, A Question about UAC behavior when Final response for Invite is received before, PRACK for the previously received 18x is not yet complete. If the UAS and UAC have agreed to support PRACK, but for some reason, UAS does not send a 200 OK in response to PRACK, The UAC is in the state of retransmitting PRACK. In this state, if the UAS sends a 200 OK (Final response) for the Invite: should the UAC accept this 200 OK (final response) , and connect the call, and continue with PRACK. Or should the UAC wait till the PRACK method is completed and then accept the 200 OK (Final response) for Invite. I can think of two scenarios: -------------------------------- Case 1: SIP UAS SIP-UAC -------------------------------- <------- Invite 100 Trying ---> 18x ----------> (No SDP) <------- PRACK 18x ----------> (No SDP) <------- PRACK <------- PRACK (retransmission) 200 OK -------> (Final Response with SDP) <------- PRACK (retransmission) -------------------------------- Case 2: SIP UAS SIP-UAC -------------------------------- <------- Invite 100 Trying ---> 18x ----------> (with SDP) <------- PRACK 18x ----------> (with SDP) <------- PRACK <------- PRACK (retransmission) 200 OK -------> (Final Response No SDP) <------- PRACK (retransmission) -------------------------------- Thanks, Nandini Gokhale Convergent Networks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 12:11:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14879 for ; Mon, 24 Jun 2002 12:11:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25100 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 12:11:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22581; Mon, 24 Jun 2002 11:44:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22550 for ; Mon, 24 Jun 2002 11:44:24 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12736 for ; Mon, 24 Jun 2002 11:43:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5OFheN7002710; Mon, 24 Jun 2002 11:43:41 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 11:43:47 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A246@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Jesske, R'" , Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org Cc: "Pinker, Gerold" , Robert.Benz@telekom.de, "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , DieterK@telekom.de, "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Mon, 24 Jun 2002 11:43:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@telekom.de] > > E.g. Cause Value 34 could be a normal release indicating a > congestion in a transit or international network but Cause > Value 34 with a diagnostic field including the CCBS possible > indication coming from a private network indicates a busy > network where the CCBS service is possible. > > CCBS is within ISDN networks a frequently used service. For > the future interworking of SIP with ISDN networks the > indication of location and diagnostics is a extension that > enables the CCBS over networks. > > The reason draft is OK for only indicating the reason of a > release but for service interworking with the PSTN it would > be better to have also the location and reason available. The idea behind including Q.850 in the reason draft is certainly not to push ISUP semantics like this into the SIP network. For your suggestion to be useful, it would require every device on the network to implement detailed ISUP semantics in addition to normal SIP semantics. Further, the level of service interworking you are hinting at requires a much better defined mechanism than simply conveying the every last bit of the Q.850 cause code. For example, if we accepted your suggestion, how would the SIP node go about ordering CCBS? Would we expect normal SIP nodes to have the ability to generate and tunnel TCAP through M3UA back to the MGC? That seems a bit extreme -- and, even if we accepted this as a solution, it requires much more rigorous specification than merely adding location values to the Q.850 cause codes sent to the SIP network (e.g. how do you route the tunneled TCAP?). Am I saying such service interworking is impossible? Of course not. I'm just saying that such interworking necessarily *must* allow the PSTN network to do things in a PSTN way, and *must* allow the SIP network to do things in a SIP way. Here's a mile-high sketch of how CCBS interworking would be specified: upon receipt of a REL with cause 34 and a diagnostic indicating that CCBS is available, the MGC would send a normal 486, with an "Allow-Events" header of "dialog" (see draft-rosenberg-sip-call-package-01.txt). The UAC, if it supports CCBS, would subscribe to the state of the dialog at the gateway. The gateway would take appropriate actions (e.g. generation of TCAP messages) based on this subscription. The remainder of the interactions are left as an excercise for the reader, but can be deduced from the call-package draft and normal PSTN CCBS procedures. (Note that the information returned in the "dialog" event notifications might be a very limited subset of what is specified in the call-package draft; this will not cause any problems that I am aware of). /a P.S. As an aside, the application you describe would be predicated on including Q.850 codes in a *RESPONSE*. The Reason draft is currently specified such that reason headers can appear only in *REQUESTS* (and in 155 responses). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 13:43:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20406 for ; Mon, 24 Jun 2002 13:43:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00015 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 13:43:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28452; Mon, 24 Jun 2002 13:14:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28421 for ; Mon, 24 Jun 2002 13:14:51 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18459 for ; Mon, 24 Jun 2002 13:14:07 -0400 (EDT) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5OHEcRb014667; Mon, 24 Jun 2002 19:14:38 +0200 (MEST) Received: from lmf.ericsson.se (arbru3m16.eu.ericsson.se [164.48.163.17]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g5OHEZqn014241; Mon, 24 Jun 2002 19:14:36 +0200 (MET DST) Message-ID: <3D17537F.8F810E7D@lmf.ericsson.se> Date: Mon, 24 Jun 2002 20:14:39 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gokhale, Nandini" CC: "'sip@ietf.org'" Subject: Re: [Sip] UAC behavior: Final Reponse received before completion of PRACK References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Chapter 3 in draft-ietf-sip-100rel-06 says: "The UAS MAY send a final response to the initial request before having recevied PRACKs for all unacknowleged reliable provisional responses, unless the final response is 2xx and any of the unacknowleged reliable provisional responses contained a session description." If the UAC doesn't receive a final response for a PRACK I would say it's an implementation issue what the UAC does, depending on if the PRACK contained a session description, if the PRACK response is supposed to contain a session description, etc etc etc. If the UAC doesn't receive any response at all for the PRACK, something is obviously very wrong, since the UAC DOES receive responses (provisional and final) to the INVITE... Regards, Christer Holmberg Ericsson Finland "Gokhale, Nandini" wrote: > Hello, > > A Question about UAC behavior when Final response for Invite is received > before, > PRACK for the previously received 18x is not yet complete. > > If the UAS and UAC have agreed to support PRACK, but for some reason, > UAS does not send a 200 OK in response to PRACK, The UAC is in the > state of retransmitting PRACK. In this state, if the UAS sends a 200 OK > (Final response) for the Invite: > > should the UAC accept this 200 OK (final response) , and connect the > call, and continue with PRACK. > Or > should the UAC wait till the PRACK method is completed and then accept > the 200 OK (Final response) for Invite. > > I can think of two scenarios: > -------------------------------- > Case 1: > > SIP UAS SIP-UAC > -------------------------------- > > <------- Invite > 100 Trying ---> > 18x ----------> > (No SDP) > <------- PRACK > 18x ----------> > (No SDP) > <------- PRACK > <------- PRACK (retransmission) > 200 OK -------> > (Final Response with SDP) > <------- PRACK (retransmission) > > -------------------------------- > Case 2: > > SIP UAS SIP-UAC > -------------------------------- > > <------- Invite > 100 Trying ---> > 18x ----------> > (with SDP) > <------- PRACK > 18x ----------> > (with SDP) > <------- PRACK > <------- PRACK (retransmission) > 200 OK -------> > (Final Response No SDP) > <------- PRACK (retransmission) > -------------------------------- > Thanks, > Nandini Gokhale > Convergent Networks. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 16:34:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28880 for ; Mon, 24 Jun 2002 16:34:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10091 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 16:35:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08328; Mon, 24 Jun 2002 16:11:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08263 for ; Mon, 24 Jun 2002 16:11:06 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27840; Mon, 24 Jun 2002 16:10:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5OKAWYH021658; Mon, 24 Jun 2002 16:10:32 -0400 (EDT) Message-ID: <3D177CB8.7070403@dynamicsoft.com> Date: Mon, 24 Jun 2002 16:10:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , rohc References: <3D16CCD2.909AE477@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Jonathan, > > inline: > > Jonathan Rosenberg wrote: > >>more old email. So sue me. Responses inline: >> >>Gonzalo Camarillo wrote: >> >>>Jonathan, >> >>>>>A proxy performing Record-Route inspects the Record-Route and the >>>>> Contact header fields in the response. It looks for the URI of >>>> >>>>the >>>> >>>>> next upstream (closer to the user agent client) hop in the route >>>> >>>>set. >>>> >>>>> If this URI contains the parameter comp=sigcomp, the proxy >>>> > SHOULD > >>>>add >>>> >>>>> comp=sigcomp to its entry in the Record-Route header field. >>>> >>>>Why? If the upstream element doesn't support this extension, the >>>>sigcomp >>>>parameter is ignored, and the message is sent uncompressed. Thats >>> > what > >>>>you want. The decision about whether to insert a URI with the comp >>>>parameter should be entirely a local one. >>> >>> >>>This covers the following scenario: >>> >>>UAC----P1-----P2-----UAS >>> >>>The UAC sends an INITE to UAS. P2 records route, but P1 does not. >>>When the 200 OK for the INVITE reaches P2, the contact and RR header >>>fields will look like this: >>> >>>Contact: UAS@domain.com;comp=sigcomp >>>RR: P2 >>> >>>If P2 does not add comp=sigcomp to his entry in the RR, UAC will be >> > able > >>>to receive compressed traffic (the contact has comp=sigcomp), but >> > will > >>>be unable to send compress traffic (the RR entry for P2 does not >> > have > >>>it). >> >>Why doesn't it? If a proxy is sigcomp enabled, it should have >>record-routed with sigcomp parameter in the first place. >> > > > If we specified that a proxy that supports SigComp MUST use it, > everything would work as you stated. However, I would like a proxy to > have the possibility of not using SigComp even if it supports it. > > Section 7 of: > http://search.ietf.org/internet-drafts/draft-camarillo-sip-compression-0 > 1.txt > > contains an example about the scenario I was describing in my previous > mail. Well, you are trying to achieve the (somewhat odd) goal of allowing the proxy to indicate that it would prefer not to use sigcomp, unless someone around it doesn't record-route, so that sigcomp would be needed in order to avoid unidirectional compression. Is there a reason for supporting this case? For any individual dialog, either a proxy indicates it can do compression, or it doesn't. I don't see the need for this case, and it complicates what is otherwise a fairly simple and elegant solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 16:35:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28919 for ; Mon, 24 Jun 2002 16:35:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10152 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 16:36:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08095; Mon, 24 Jun 2002 16:06:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08052 for ; Mon, 24 Jun 2002 16:06:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27635 for ; Mon, 24 Jun 2002 16:06:02 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5OK65YH021649; Mon, 24 Jun 2002 16:06:06 -0400 (EDT) Message-ID: <3D177BAD.5050407@dynamicsoft.com> Date: Mon, 24 Jun 2002 16:06:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Vijay K. Gurbani" , sip Subject: Re: [Sip] Reason version 01 References: <3D16CEB7.7646A16A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Jonathan, > > inline: > > Gonzalo wrote: > >>>However, I do not think we have any problem. The reason draft can >> > speak > >>>about 155 responses without referencing any RFC. It is enough that >> > the > >>>155 status code is registered wherever we are registering status >> > codes > >>>(is it already in IANA or we still have a temporary repository?). >>> >>>Does anybody see a problem with this approach? >> > > Jonathan wrote: > >>I think its fine to be vague, or to simply strike the references >>completely from reason, so that the herfp draft defines the usage of >>Reason in 155. However, the change you suggest above was not made, and >>it seems reason-01 has been approved..... > > > The references of reason-01 look like this: > > 8 Normative References > > [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation > protocol," Internet Draft, Internet Engineering Task Force, Feb. > 2002. Work in progress. > > [2] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet > Engineering Task Force, Mar. 2002. Work in progress. > > [3] S. Bradner, "Key words for use in RFCs to indicate requirement > levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. > > > references [1] and [2] need to be updated anyway. The RFC editor will > take care of that. > > Then, the first time 155 is mentioned, there is a reference to [2]. I > can remove the reference, and speak about 155 without referencing any > document. I'd prefer to remove the reference, and not speak specifically about 155, but rather about a response code that might need to carry additional reason phrases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 16:43:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29400 for ; Mon, 24 Jun 2002 16:43:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10863 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 16:44:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08442; Mon, 24 Jun 2002 16:14:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08410 for ; Mon, 24 Jun 2002 16:14:56 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28014 for ; Mon, 24 Jun 2002 16:14:11 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5OKEJYH021661; Mon, 24 Jun 2002 16:14:19 -0400 (EDT) Message-ID: <3D177D9A.2040108@dynamicsoft.com> Date: Mon, 24 Jun 2002 16:14:18 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Salva Rey'" , sip@ietf.org Subject: Re: [Sip] Transport Layer References: <9BF66EBF6BEFD942915B4D4D45C051F377A241@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It should never happen. It is disallowed in the spec. Let me also add this. I've said it countless times, but it is worth continuously repeating. The spec *does not* specify handling procedures for every error case, where error case is defined as a situation that is expressly prohibited by the spec. The set of such error cases is far larger than the set of normal operating cases. Under these cases, the behavior is implementation specific. I generally recommend being as gratious as you can, in order to recover. -Jonathan R. Adam Roach wrote: > Honor the stated transport. That is, if you receive a message > via TCP with a topmost via starting with "SIP/2.0/UDP", you don't > modify it in any way -- and, when it comes time to send the response, > you use UDP. > > Note, however, that this shouldn't really happen much, if at all, > in practice. > > /a > > >>-----Original Message----- >>From: Salva Rey [mailto:salreyca@hotmail.com] >>Sent: Friday, June 21, 2002 6:54 >>To: sip@ietf.org >>Subject: [Sip] Transport Layer >> >> >> >> >>Hi, >> >>what should do the transport layer if it receives a messages >>on a different >>transport than the one stated in the topmost via Header? I >>havent read >>anywhere that the received parameter can contain a transport. >> >>best regards, >>Salva >> >>_________________________________________________________________ >>MSN Photos is the easiest way to share and print your photos: >>http://photos.msn.com/support/worldwide.aspx >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 16:49:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29769 for ; Mon, 24 Jun 2002 16:49:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11334 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 16:50:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09215; Mon, 24 Jun 2002 16:27:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09184 for ; Mon, 24 Jun 2002 16:27:06 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28519 for ; Mon, 24 Jun 2002 16:26:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5OKPwYH021671; Mon, 24 Jun 2002 16:26:00 -0400 (EDT) Message-ID: <3D178055.7070707@dynamicsoft.com> Date: Mon, 24 Jun 2002 16:25:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nirmalya@icr.a-star.edu.sg CC: sip@ietf.org Subject: Re: [Sip] REGISTER Processing References: <000601c21748$b1ea4640$810210ac@cwc.nus.edu.sg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Nirmalya Ghosh wrote: > Hi Jonathan, > I have a question regarding what happens when a user wants to fetch its > current bindings (maybe after rebooting his/her PC). I understand that > the Call-ID need not be the same across reboots, but what I am not sure > of is whether for a dummy REGISTER request (containing no Contact or > Expires) sent to fetch its bindings after rebooting, would/should get a > 500 response from the registrar just because its CSeq does not match > that of existing bindings. Or am I misinterpreting things here? Things work fine. Please read the rules in 10.3 and follow them through for this case. You will arrive at step 6, which says: The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. 1710 The last step involves sending a 200 OK with the list of registered contacts. The intermediate steps which are skipped are the ones that check the CSeq and Call-ID. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 17:55:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03887 for ; Mon, 24 Jun 2002 17:55:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19722 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 17:56:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17699; Mon, 24 Jun 2002 17:33:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15345 for ; Mon, 24 Jun 2002 17:14:06 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01287 for ; Mon, 24 Jun 2002 17:13:20 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5OLDRdg014139; Mon, 24 Jun 2002 14:13:27 -0700 (PDT) Received: from fluffyw2k (dhcp-128-107-142-72.cisco.com [128.107.142.72]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADF85908; Mon, 24 Jun 2002 14:13:33 -0700 (PDT) From: "Cullen Jennings" To: "Adam Roach" , "'Jesske, R'" , , Cc: "Pinker, Gerold" , , "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , , "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Mon, 24 Jun 2002 14:13:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A246@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Adam > Roach > > The idea behind including Q.850 in the reason draft is certainly > not to push ISUP semantics like this into the SIP network. For > I agree with Adam but just out of curiosity, why is the Q.850 stuff in the SIP network? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 18:08:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04428 for ; Mon, 24 Jun 2002 18:08:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21059 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 18:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18896; Mon, 24 Jun 2002 17:46:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18867 for ; Mon, 24 Jun 2002 17:46:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03281; Mon, 24 Jun 2002 17:46:02 -0400 (EDT) Message-Id: <200206242146.RAA03281@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Mon, 24 Jun 2002 17:46:01 -0400 Subject: [Sip] Protocol Action: A Privacy Mechanism for the Session Initiation Protocol (SIP) to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved the Internet-Draft A Privacy Mechanism for the Session Initiation Protocol (SIP) for publication as a Proposed Standard The IESG also approved publication of the following Internet-Drafts for publication as Informational RFCs: o Extensions to the Session Initiation Protocol (SIP) for Asserted Identity o Short term requirements for Network Asserted Identity These documents are the product of the Session Initiation Protocol Working Group and the Session Initiation Proposal Investigation (sipping) Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The document 'A Privacy Mechanism for the Session Initiation Protocol (SIP)' defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. In this context, privacy is defined as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. Withholding the identity of a user will, among other things, render the other parties in the dialog unable to send new SIP requests to the user outside of the context of the current dialog. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to address some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. SIP allows users to assert their identity in a number of ways e.g. using the From: header. However, there is no requirement for these identities to be anything other than the users desired alias. The document 'Short term requirements for Network Asserted Identity' describes the requirements for a Network Asserted Identity which is an identity initially derived by a SIP network intermediary as a result of an authentication process. The document 'Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks' describes optional SIP extensions for the use of Network Asserted Identities within a trusted network. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. Working Group Summary The SIP working group supported publication of these documents though some of the discussions were protracted. Protocol Quality These documents were reviewed for the IESG by Allison Mankin Note to RFC Editor: 1. Please change the title of draft-ietf-sip-asserted-identity-01.txt From: Extensions to the Session Initiation Protocol (SIP) for Asserted Identity To: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity 2. In draft-ietf-sip-privacy-general-01.txt, please make the following changes: Section 4.2: Old: < Note that requesting session privacy when end-to-end session < encryption is not possible raises serious security concerns (see < Section 6.2). New: > Note that requesting session privacy in the absence of any end-to- > end session encryption raises some serious security concerns (see < Section 6.2). Section 4.2: Old: < user: This privacy level is set only by intermediaries, in order to < communicate that user level privacy functions (as discussed in < Section 5.3) must be provided by the network, presumably because < the user agent is unable to provide them. User agents MUST NOT < set the "user" privacy level. New: > user: This privacy level is usually set only by intermediaries, in > order to communicate that user level privacy functions (as > discussed in Section 5.3) must be provided by the network, > presumably because the user agent is unable to provide them. User > agents MAY however set this privacy level for REGISTER requests, > but SHOULD NOT set 'user' level privacy for other requests. Section 4.4: Old: < record. The user would then register their normal address-of-record < as a contact address with the third-party service. New: > record. A privacy service provider might offer these anonymous > callback URIs to users in the same way that an ordinary SIP service > provider grants addresses-of-record. The user would then register > their normal address-of-record as a contact address with the third- > party service. Section 5: Old: < not be capable of fulfilling the requested level of privacy. It MAY, < however, re-route the request to another server which is capable of < providing the needed functions, if it can. If the 'critical' privacy < level is present in the Privacy header of a request, then if the < privacy service is incapable of performing all of the levels of < privacy specified in the Privacy header then it MUST either fail the < request, or it MUST forward the request to another privacy service < which can fulfill these functions (note that before forwarding the < request, the privacy service SHOULD complete a subset of the < functions if it can). New: > not be capable of fulfilling the requested level of privacy. If the > 'critical' privacy level is present in the Privacy header of a > request, then if the privacy service is incapable of performing all > of the levels of privacy specified in the Privacy header then it MUST > fail the request with a 500 (Server Error) response code. > The reason phrase of the > status line of the response SHOULD contain appropriate text > indicating that there has been a privacy failure as well as an > enumeration of the priv-value(s) which were not supported by the > privacy service (the reason phrase SHOULD also respect any Accept- > Language header in the request if possible). Section 7: Old: < IANA registration for "Privacy" header field values is required. < Only approved RFCs of the SIP WG can register "Privacy" header field < values. New: > New values for the "Privacy" header can only be defined by IETF > Consensus including RFC publication (RFC 2434). > IANA registration for the "Privacy" > header field values is required along with the RFC publication. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 18:08:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04522 for ; Mon, 24 Jun 2002 18:08:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21123 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 18:09:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19040; Mon, 24 Jun 2002 17:47:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18994 for ; Mon, 24 Jun 2002 17:47:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03339; Mon, 24 Jun 2002 17:46:45 -0400 (EDT) Message-Id: <200206242146.RAA03339@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org, sipping@ietf.org From: The IESG Date: Mon, 24 Jun 2002 17:46:45 -0400 Subject: [Sip] Protocol Action: The Reason Header Field for the Session Initiation Protocol to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o The Reason Header Field for the Session Initiation Protocol o SIP Extension for Registering Non-Adjacent Contacts These documents are the product of the Session Initiation Protocol Working Group and the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The document 'The Reason Header Field for the Session Initiation Protocol' defines a header field, Reason, that can be used to say why a particular SIP request was issued. The same SIP request can be issued for a variety of reasons. For example, a SIP CANCEL request can be issued if the call has completed on another branch or was abandoned before answer. While the protocol and system behavior is the same in both cases, namely, alerting will cease, the user interface may well differ. In the second case, the call may be logged as a missed call, while this would not be appropriate if the call was picked up elsewhere. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", or HERFP. The document 'Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts' defines a SIP extension header "Path" which can be used when network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The Path header is used to discover and record the sequence of proxies in the registrar. Working Group Summary The SIP working group supported publication of these documents. Both were deemed to have broad applicability and merit the extension of the set of SIP headers. Protocol Quality These documents were reviewed for the IESG by Allison Mankin. Note to RFC Editor: The "protocol" item in the ABNF says: protocol = SIP / Q.850 / token but SIP and Q.850 are literal strings, so it should say: protocol = "SIP" / "Q.850" / token _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jun 24 18:52:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06091 for ; Mon, 24 Jun 2002 18:52:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24064 for sip-archive@odin.ietf.org; Mon, 24 Jun 2002 18:53:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22120; Mon, 24 Jun 2002 18:24:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22086 for ; Mon, 24 Jun 2002 18:24:27 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05068 for ; Mon, 24 Jun 2002 18:23:45 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5OMO3a08420; Mon, 24 Jun 2002 17:24:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 17:23:49 -0500 Message-ID: From: "Sriram Parameswar" To: "'Robert Sparks'" , sip@ietf.org Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref er status/adjustment] Date: Mon, 24 Jun 2002 17:23:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21BCD.CFB97A40" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21BCD.CFB97A40 Content-Type: text/plain; charset="iso-8859-1" Robert, Apologize for the delay in submitting comments - was on an extended vacation. I have not fully caught up on my email so please pardon any duplicate comments. Here goes: 1. The entity sending the REFER uses the Supported header with a option tag 'referevent' to which the responding UA sends the Require with referevent in the 202. Given the way Supported and Require are defined in Bis09/3261 - it does not allow the entity sending the REFER to invoke the following semantic "If you are not going to be able to send a NOTIFY then dont process the REFER". For this semantic we need the UA sending the REFER to be able to use Require: referevent, or define another mechanism to do so. 2. Question - if there are multiple REFER's and you want to unsubscribe to a particular REFER in that set, how is that possible? I am guessing the 'id' associated with the REFER could be reflected in event of the SUBSCRIBE (Event: refer; id=1234) - that would be one way to do it. At any rate - we need a mechanism to perform selective unsubscribe and to be noted in the draft. 3. Sec 3.10 - do we need a way for the REFER initiator to be able say - "Just send me the immediate and final NOTIFYs only and none of the intermediate NOTIFYs" and vice-versa i.e. indicate its interest in intermediate NOTIFYs. I see some usefulness in such a mechanism, this allows the REFER initiator control over the number/type of notifications he will receive. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Monday, June 17, 2002 9:14 AM To: sip@ietf.org Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Refer status/adjustment] The message I sent last week (copied below) has generated no list comments. I hope it was because I was too subtle with the subject line. I have asked the IESG to delay their consideration of the REFER draft until these concerns have been discussed on this list. Please read the draft below and comment. If you agree with what's in the draft, please post a note saying so. RjS -----Forwarded Message----- > From: Robert Sparks > To: sip@ietf.org > Subject: [Sip] Refer status/adjustment > Date: 12 Jun 2002 13:49:35 -0500 > > A set of converging concerns were raised about the > REFER draft late in the review process, all centering > on draft's use of sip-events (soon to be RFC3265) and > the implicit subscription. > > When investigating those concerns, several things became > clear. > > The draft did not provide sufficient discussion > around managing the lifecycle of the implicit subscription > (Can you refresh the implicit subscription? unsubscribe? > How is the Subscription-State header supposed to be used? > How do the two parties know when the subscription is over?) > and the draft did not clearly specify some of the things > RFC3265 requires of an event package. These need to be > corrected. > > A larger issue centers around the following language from > sip-events: > > Note that any behavior designated with "SHOULD" or "MUST" in this > document is not allowed to be weakened by extension documents; > however, such documents may elect to strengthen "SHOULD" > requirements to "MUST" strength if required by their application. > > The current draft is not clear enough on one particular point - the > examples do not show immediate NOTIFYs for the implicit subscription. > I expect that many members of the community believe they are not > required (I had drifted into thinking that way before the comments > caused me to look at this more closely). The normative text in the > current REFER draft calls to RFC3265, and immediate NOTIFYs are very > clearly required there. This needs to be pointed out more clearly > in the REFER draft. > > Finally, the current draft makes instantiating a subscription a > SHOULD strength requirement, but provides no mechanism for the > agent sending the REFER to know whether or not to expect a NOTIFY. > We have repeatedly had discussions on the list about how long > the agent sending the REFER should keep state waiting for a NOTIFY - > and with discomfort deciding that is an implementation decision. > Recent discussions have pointed out that there is disagreement about > what never receiving a NOTIFY means - should the REFERing party treat > that as an error and re-attempt the reference or should it just > assume no subscription was created? > > I've put together an individual submission that adds all the > above clarifications. It also proposes a new mechanism to > address the problems in the previous paragraph. Basically, it > provides a way for the party sending the REFER to indicate > that it really wants to be notified, and a way for the agent > accepting the refer to signal that it will or will not send > notifies in the response to the REFER. > > I just submitted this draft - until it appears in the repository, > you can get it from > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt > > I propose that this draft replace refer-05 before it advances further > in the standardization process. > > RjS > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C21BCD.CFB97A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] = Refer status/adjustment]

Robert,

Apologize for the delay in submitting comments - was = on an extended vacation. I have not fully caught up on my email so = please pardon any duplicate comments. Here goes:

1. The entity sending the REFER uses the Supported = header with a option tag 'referevent' to which the responding UA sends = the Require with referevent in the 202. Given the way Supported and = Require are defined in Bis09/3261 - it does not allow the entity = sending the REFER to invoke the following semantic "If you are not = going to be able to send a NOTIFY then dont process the REFER". = For this semantic we need the UA sending the REFER to be able to use = Require: referevent, or define another mechanism to do so.

2. Question - if there are multiple REFER's and you = want to unsubscribe to a particular REFER in that set, how is that = possible? I am guessing the 'id' associated with the REFER could be = reflected in event of the SUBSCRIBE (Event: refer; id=3D1234) - that = would be one way to do it. At any rate - we need a mechanism to perform = selective unsubscribe and to be noted in the draft.

3. Sec 3.10 - do we need a way for the REFER = initiator to be able say - "Just send me the immediate and final = NOTIFYs only and none of the intermediate NOTIFYs" and vice-versa = i.e. indicate its interest in intermediate NOTIFYs. I see some = usefulness in such a mechanism, this allows the REFER initiator control = over the number/type of notifications he will receive.

Regards,

Sriram

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


-----Original Message-----
From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
Sent: Monday, June 17, 2002 9:14 AM
To: sip@ietf.org
Subject: IMPORTANT: Comments on REFER changes needed = : [Fwd: [Sip] Refer
status/adjustment]


The message I sent last week (copied below)
has generated no list comments. I hope it
was because I was too subtle with the subject
line.

I have asked the IESG to delay their = consideration
of the REFER draft until these concerns have = been
discussed on this list.

Please read the draft below and comment. If you =
agree with what's in the draft, please post a
note saying so.

RjS

-----Forwarded Message-----

> From: Robert Sparks = <rsparks@dynamicsoft.com>
> To: sip@ietf.org
> Subject: [Sip] Refer status/adjustment
> Date: 12 Jun 2002 13:49:35 -0500
>
> A set of converging concerns were raised about = the
> REFER draft late in the review process, all = centering
> on draft's use of sip-events (soon to be = RFC3265) and
> the implicit subscription.
>
> When investigating those concerns, several = things became
> clear.
>
> The draft did not provide sufficient = discussion
> around managing the lifecycle of the implicit = subscription
> (Can you refresh the implicit subscription? = unsubscribe?
>  How is the Subscription-State header = supposed to be used?
>  How do the two parties know when the = subscription is over?)
> and the draft did not clearly specify some of = the things
> RFC3265 requires of an event package. These = need to be
> corrected.
>
> A larger issue centers around the following = language from
> sip-events:
>
>   Note that any behavior designated = with "SHOULD" or "MUST" in this
>   document is not allowed to be = weakened by extension documents;
>   however, such documents may elect = to strengthen "SHOULD"
>   requirements to "MUST" = strength if required by their application.
>
> The current draft is not clear enough on one = particular point - the
> examples do not show immediate NOTIFYs for the = implicit subscription.
> I expect that many members of the community = believe they are not
> required (I had drifted into thinking that way = before the comments
> caused me to look at this more closely). The = normative text in the
> current REFER draft calls to RFC3265, and = immediate NOTIFYs are very
> clearly required there. This needs to be = pointed out more clearly
> in the REFER draft.
>
> Finally, the current draft makes instantiating = a subscription a
> SHOULD strength requirement, but provides no = mechanism for the
> agent sending the REFER to know whether or not = to expect a NOTIFY.
> We have repeatedly had discussions on the list = about how long
> the agent sending the REFER should keep state = waiting for a NOTIFY -
> and with discomfort deciding that is an = implementation decision.
> Recent discussions have pointed out that there = is disagreement about
> what never receiving a NOTIFY means - should = the REFERing party treat
> that as an error and re-attempt the reference = or should it just
> assume no subscription was created?
>
> I've put together an individual submission that = adds all the
> above clarifications. It also proposes a new = mechanism to
> address the problems in the previous paragraph. = Basically, it
> provides a way for the party sending the REFER = to indicate
> that it really wants to be notified, and a way = for the agent
> accepting the refer to signal that it will or = will not send
> notifies in the response to the REFER.
>
> I just submitted this draft - until it appears = in the repository,
> you can get it from
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-refe= r-3265disc-00.txt
>
> I propose that this draft replace refer-05 = before it advances further
> in the standardization process.
>
> RjS
>
>
>
>
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip



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

------_=_NextPart_001_01C21BCD.CFB97A40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 01:27:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14054 for ; Tue, 25 Jun 2002 01:27:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16093 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 01:28:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08274; Tue, 25 Jun 2002 01:00:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08221 for ; Tue, 25 Jun 2002 01:00:34 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@user3.pingtel.com [65.220.123.3] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13663 for ; Tue, 25 Jun 2002 00:59:51 -0400 (EDT) Received: from pingtel.com ([192.168.0.3]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g5P4ufj03624; Tue, 25 Jun 2002 00:56:41 -0400 Message-ID: <3D17F899.A5D25374@pingtel.com> Date: Tue, 25 Jun 2002 00:59:05 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Refer status/adjustment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The following comments pertain to draft-sparks-sip-refer-3265disc-00.txt Overall I think this draft is mostly harmless. I think that it is good to make things consistant with the latest SIP events. On the other hand there are a lot of small changes for not much functionaly increase. My major concern relates to the existing installed base implemented on prior drafts of REFER. There is a significant installed base of products and services that depend upon prior versions of the REFER draft. There are some upward compatability issues in the changes proposed in this draft. Some mostly minor comments are included below. I assume the rules for name-addr vs. addr-spec from RFC3261 apply in the same way. That is in the Refer-To header examples that have ? followed by header parameters, the name-addr form should be used with angle brackets. Ignoring the installed base I have no technical issues with the use of the referevent token to indicate the desire for notification of outcome. However, in the real world this presents an upward compatability issue. If the transferor is a prior refer-3261 implementation, it will not send the referevent token in the Supported header. If the transferee is a post refer-3261 implementation it will not send a notify and the transferor will wait a long time for the NOTIFY request and at best give a false indication of transfer failure. It is a little ugly, but reversing the sense is upward compatable (e.g. noreferevent token). It seems that last paragraph in section 2.4.2 gives the REFER recipient the choice of whether it wants to send a NOTIFY event or not. I am not sure if I object to this or not, but is there a reason or example of why this is useful? It does make things a little more complicated in that there are more possible outcomes (there is no shortage of error cases even without this possibility). 2.4.3 I think there is a possible race condition here. Though the possiblity is remote the user agent sending the REFER request should be prepared to receive the NOTIFY prior to the 2xx response to the REFER. Oh I see that is pointed out in 2.4.5 2.5.6 Is it not valid to send any provisional response in the sipfrag body (e.g. 180) when the subscription state is pending? Cheers, Dan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 04:45:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26811 for ; Tue, 25 Jun 2002 04:45:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27083 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 04:46:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25060; Tue, 25 Jun 2002 04:19:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24989 for ; Tue, 25 Jun 2002 04:19:49 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26213; Tue, 25 Jun 2002 04:19:04 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5P8JjRb029620; Tue, 25 Jun 2002 10:19:45 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5P8Jja9005379; Tue, 25 Jun 2002 11:19:45 +0300 (EET DST) Message-ID: <3D1827A0.3D0AE8C2@lmf.ericsson.se> Date: Tue, 25 Jun 2002 11:19:44 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip , rohc References: <3D16CCD2.909AE477@lmf.ericsson.se> <3D177CB8.7070403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Jonathan Rosenberg wrote: > Well, you are trying to achieve the (somewhat odd) goal of allowing the > proxy to indicate that it would prefer not to use sigcomp, unless > someone around it doesn't record-route, so that sigcomp would be needed > in order to avoid unidirectional compression. Is there a reason for > supporting this case? For any individual dialog, either a proxy > indicates it can do compression, or it doesn't. I don't see the need for > this case, and it complicates what is otherwise a fairly simple and > elegant solution. > The trade-off we have is the following: If we go for the simplest mechanism, every time two adjacent proxies support SigComp, they will exchange compressed messages. This means that when two wireless terminals exchange SIP signalling thru a set of SigComp capable proxies, all the messages will be compressed, even between proxies. We can avoid this and make that compression is used only over the air interface (i.e., not between the proxies in our example), but we have to have proxies inspect Record-Route header fields. If folks think that it is OK that two proxies that support SigComp MUST always exhange compressed messages, I will be glad to simplify the draft. If people feel that compressing when it is not really needed is unacceptable, we will keep the current Record-Route inspection mechanism. Personally, if nobody has big concerns about performance of precessing power, I would suggest that we simplify the mechanism and make it mandatory the use of compression for all entities that support SigComp (as suggested by Jonathan). Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 05:06:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27141 for ; Tue, 25 Jun 2002 05:06:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28516 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 05:07:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27293; Tue, 25 Jun 2002 04:48:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27231 for ; Tue, 25 Jun 2002 04:48:36 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26850; Tue, 25 Jun 2002 04:47:51 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5P8n3i03534; Tue, 25 Jun 2002 11:49:03 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Jun 2002 11:48:26 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 11:48:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 11:48:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: [rohc] SigComp and SIP Date: Tue, 25 Jun 2002 11:48:24 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2036B@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Re: [rohc] SigComp and SIP Thread-Index: AcIcIR6cuc+Yk4xITQKVisyE45PRBgAAui0A To: , Cc: , X-OriginalArrivalTime: 25 Jun 2002 08:48:25.0450 (UTC) FILETIME=[119A7CA0:01C21C25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA27232 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Looking at Gonzalo's example: UAC----P1-----P2-----UAS If P2 wants to receive compressed requests, then it adds comp=sigcomp in the RR header. If P2 does not want to receive compressed requests, then it does not include the param. Now, if UAC wants to compress, it looks at the record-route header and finds out if the next hop (P2) wants to receive compressed data or not. In the case above, P2 did not want to receive compressed data, so UAC can't override P2's wish by sending it compressed data. If you view the param comp=sigcomp and as an indication of willingness rather than capability, then doing it as described above makes sense. If a UAC refuses to send uncompressed data, then perhaps a proxy-require: sigcomp (or something similar) can be sent. Regards, Hisham > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, June 25, 2002 11:20 AM > To: Jonathan Rosenberg > Cc: sip; rohc > Subject: [Sip] Re: [rohc] SigComp and SIP > > > Hello, > > Jonathan Rosenberg wrote: > > Well, you are trying to achieve the (somewhat odd) goal of > allowing the > > proxy to indicate that it would prefer not to use sigcomp, unless > > someone around it doesn't record-route, so that sigcomp > would be needed > > in order to avoid unidirectional compression. Is there a reason for > > supporting this case? For any individual dialog, either a proxy > > indicates it can do compression, or it doesn't. I don't see > the need for > > this case, and it complicates what is otherwise a fairly simple and > > elegant solution. > > > > The trade-off we have is the following: > > If we go for the simplest mechanism, every time two adjacent proxies > support SigComp, they will exchange compressed messages. This > means that > when two wireless terminals exchange SIP signalling thru a set of > SigComp capable proxies, all the messages will be compressed, even > between proxies. > > We can avoid this and make that compression is used only over the air > interface (i.e., not between the proxies in our example), but > we have to > have proxies inspect Record-Route header fields. > > > If folks think that it is OK that two proxies that support > SigComp MUST > always exhange compressed messages, I will be glad to simplify the > draft. If people feel that compressing when it is not really needed is > unacceptable, we will keep the current Record-Route inspection > mechanism. > > Personally, if nobody has big concerns about performance of precessing > power, I would suggest that we simplify the mechanism and make it > mandatory the use of compression for all entities that support SigComp > (as suggested by Jonathan). > > Regards, > > Gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 06:57:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28858 for ; Tue, 25 Jun 2002 06:57:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02897 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 06:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01668; Tue, 25 Jun 2002 06:28:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01637 for ; Tue, 25 Jun 2002 06:27:54 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28387 for ; Tue, 25 Jun 2002 06:27:10 -0400 (EDT) Received: from [10.10.13.95] (helo=RaviRaj) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17MnVS-0001MP-00; Tue, 25 Jun 2002 15:55:06 +0530 Message-ID: <003301c21c33$3b1f1dc0$5f0d0a0a@SIGMA> From: "Ranjit Avasarala" To: Cc: Date: Tue, 25 Jun 2002 15:59:47 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C21C61.54BD6920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sip] subscribe - event package Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C21C61.54BD6920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi This is with ref to draft-ietf-sip-events-05.txt I have a doubt in the implementation of events template package. = What should this package contain. Say I am implementing the call waiting = feature on Server=20 Now A calls B and B is busy. So i get a Busy Here msg to A. Then I can = SUBSCRIBE a event on my server and ask it to NOTIFY me when B is Free.=20 so any suggestions? Thanks Ranjit ------=_NextPart_000_0030_01C21C61.54BD6920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
    This is with ref to=20 draft-ietf-sip-events-05.txt
 
    I have a doubt in = the=20 implementation of events template package. What should this package = contain. Say=20 I am implementing the call waiting feature on Server
 
Now A calls B and B is busy. So i get a = Busy Here=20 msg to A. Then I can SUBSCRIBE a event on my server and ask it to NOTIFY = me when=20 B is Free.
 
so any suggestions?
 
Thanks
Ranjit
 
------=_NextPart_000_0030_01C21C61.54BD6920-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 08:41:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03049 for ; Tue, 25 Jun 2002 08:41:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07963 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 08:41:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06506; Tue, 25 Jun 2002 08:12:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06453 for ; Tue, 25 Jun 2002 08:12:55 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02000; Tue, 25 Jun 2002 08:12:11 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g5PCCnl24401; Tue, 25 Jun 2002 07:12:49 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5PCCmc05832; Tue, 25 Jun 2002 07:12:48 -0500 (CDT) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g5PCCmE26733; Tue, 25 Jun 2002 08:12:48 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Jun 2002 08:14:16 -0400 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0377EE@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "Gonzalo Camarillo Gonzalez (LMF)" , Jonathan Rosenberg Cc: sip , rohc Subject: RE: [Sip] Re: [rohc] SigComp and SIP Date: Tue, 25 Jun 2002 08:12:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > The trade-off we have is the following: > > If we go for the simplest mechanism, every time two adjacent proxies > support SigComp, they will exchange compressed messages. This > means that > when two wireless terminals exchange SIP signalling thru a set of > SigComp capable proxies, all the messages will be compressed, even > between proxies. > > We can avoid this and make that compression is used only over the air > interface (i.e., not between the proxies in our example), but > we have to > have proxies inspect Record-Route header fields. > > > If folks think that it is OK that two proxies that support > SigComp MUST > always exhange compressed messages, I will be glad to simplify the > draft. If people feel that compressing when it is not really needed is > unacceptable, we will keep the current Record-Route inspection > mechanism. > > Personally, if nobody has big concerns about performance of precessing > power, I would suggest that we simplify the mechanism and make it > mandatory the use of compression for all entities that support SigComp > (as suggested by Jonathan). > > Regards, > > Gonzalo Compression between proxies that support SIGCOMP cannot be a MUST. Not only does the processing power become an issue which will increase the cost of the equipment without any *real value* added. The call set up delay can be seriously impacted when you have 5 or 6 proxies to traverse in a typical 3G-3G call. Furthermore, when we talk about simplification what are we really simplifying, the RR needs to be examined anyway for potential rewrites. So, I would stick to the original proposal. It must be an option and a local policy to SIGCOMP or not. Rggds/gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 11:55:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11977 for ; Tue, 25 Jun 2002 11:55:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19796 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 11:56:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17507; Tue, 25 Jun 2002 11:18:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17400 for ; Tue, 25 Jun 2002 11:18:40 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10060 for ; Tue, 25 Jun 2002 11:17:55 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5PFMJV07707; Tue, 25 Jun 2002 10:22:26 -0500 Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref er status/adjustment] From: Robert Sparks To: Sriram Parameswar Cc: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2002 10:17:07 -0500 Message-Id: <1025018235.1690.224.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2002-06-24 at 17:23, Sriram Parameswar wrote: > Robert, > > Apologize for the delay in submitting comments - was on an extended > vacation. I have not fully caught up on my email so please pardon any > duplicate comments. Here goes: > > 1. The entity sending the REFER uses the Supported header with a option > tag 'referevent' to which the responding UA sends the Require with > referevent in the 202. Given the way Supported and Require are defined > in Bis09/3261 - it does not allow the entity sending the REFER to invoke > the following semantic "If you are not going to be able to send a NOTIFY > then dont process the REFER". For this semantic we need the UA sending > the REFER to be able to use Require: referevent, or define another > mechanism to do so. Require: referevent is the right way to do what you want to do. The draft doesn't preclude that normal use of Require in a request. I'll add text explicitly calling it out. > > 2. Question - if there are multiple REFER's and you want to unsubscribe > to a particular REFER in that set, how is that possible? I am guessing > the 'id' associated with the REFER could be reflected in event of the > SUBSCRIBE (Event: refer; id=1234) - that would be one way to do it. At > any rate - we need a mechanism to perform selective unsubscribe and to > be noted in the draft. Your guess of using the id parameter was correct. Again, I'll add text making that explicit. > > 3. Sec 3.10 - do we need a way for the REFER initiator to be able say - > "Just send me the immediate and final NOTIFYs only and none of the > intermediate NOTIFYs" and vice-versa i.e. indicate its interest in > intermediate NOTIFYs. I see some usefulness in such a mechanism, this > allows the REFER initiator control over the number/type of notifications > he will receive. We're seeing a similar kind of pressure in other event packages. Often its called event-filtering. I'm still not sure whether a filter approach or a separate event is the better approach. In any case, this problem is not an event refer specific one, so we shouldn't solve it in this draft. > > Regards, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > -----Original Message----- > From: Robert Sparks [ mailto:rsparks@dynamicsoft.com > ] > Sent: Monday, June 17, 2002 9:14 AM > To: sip@ietf.org > Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Refer > > status/adjustment] > > > The message I sent last week (copied below) > has generated no list comments. I hope it > was because I was too subtle with the subject > line. > > I have asked the IESG to delay their consideration > of the REFER draft until these concerns have been > discussed on this list. > > Please read the draft below and comment. If you > agree with what's in the draft, please post a > note saying so. > > RjS > > -----Forwarded Message----- > > > From: Robert Sparks > > To: sip@ietf.org > > Subject: [Sip] Refer status/adjustment > > Date: 12 Jun 2002 13:49:35 -0500 > > > > A set of converging concerns were raised about the > > REFER draft late in the review process, all centering > > on draft's use of sip-events (soon to be RFC3265) and > > the implicit subscription. > > > > When investigating those concerns, several things became > > clear. > > > > The draft did not provide sufficient discussion > > around managing the lifecycle of the implicit subscription > > (Can you refresh the implicit subscription? unsubscribe? > > How is the Subscription-State header supposed to be used? > > How do the two parties know when the subscription is over?) > > and the draft did not clearly specify some of the things > > RFC3265 requires of an event package. These need to be > > corrected. > > > > A larger issue centers around the following language from > > sip-events: > > > > Note that any behavior designated with "SHOULD" or "MUST" in this > > document is not allowed to be weakened by extension documents; > > however, such documents may elect to strengthen "SHOULD" > > requirements to "MUST" strength if required by their application. > > > > The current draft is not clear enough on one particular point - the > > examples do not show immediate NOTIFYs for the implicit subscription. > > I expect that many members of the community believe they are not > > required (I had drifted into thinking that way before the comments > > caused me to look at this more closely). The normative text in the > > current REFER draft calls to RFC3265, and immediate NOTIFYs are very > > clearly required there. This needs to be pointed out more clearly > > in the REFER draft. > > > > Finally, the current draft makes instantiating a subscription a > > SHOULD strength requirement, but provides no mechanism for the > > agent sending the REFER to know whether or not to expect a NOTIFY. > > We have repeatedly had discussions on the list about how long > > the agent sending the REFER should keep state waiting for a NOTIFY - > > and with discomfort deciding that is an implementation decision. > > Recent discussions have pointed out that there is disagreement about > > what never receiving a NOTIFY means - should the REFERing party treat > > that as an error and re-attempt the reference or should it just > > assume no subscription was created? > > > > I've put together an individual submission that adds all the > > above clarifications. It also proposes a new mechanism to > > address the problems in the previous paragraph. Basically, it > > provides a way for the party sending the REFER to indicate > > that it really wants to be notified, and a way for the agent > > accepting the refer to signal that it will or will not send > > notifies in the response to the REFER. > > > > I just submitted this draft - until it appears in the repository, > > you can get it from > > > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt > > > > > > I propose that this draft replace refer-05 before it advances further > > in the standardization process. > > > > RjS > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 11:56:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12024 for ; Tue, 25 Jun 2002 11:56:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19812 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 11:56:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17745; Tue, 25 Jun 2002 11:23:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17682 for ; Tue, 25 Jun 2002 11:23:01 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10258; Tue, 25 Jun 2002 11:22:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PFMJN7009988; Tue, 25 Jun 2002 11:22:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 11:22:26 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A25B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Gonzalo Camarillo'" , Jonathan Rosenberg Cc: sip , rohc Date: Tue, 25 Jun 2002 11:22:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > If folks think that it is OK that two proxies that support > SigComp MUST > always exhange compressed messages, I will be glad to simplify the > draft. If people feel that compressing when it is not really needed is > unacceptable, we will keep the current Record-Route inspection > mechanism. This is *NOT* acceptable. The performance impacts of any realistic compression algorithm are substantial. Over the air, the decreased throughput (and ultimately increased hardware costs) is justified by decreased latency. Between nodes operating on a wired network, it's merely a losing proposition. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 11:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12038 for ; Tue, 25 Jun 2002 11:56:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19854 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 11:56:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17394; Tue, 25 Jun 2002 11:18:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17349 for ; Tue, 25 Jun 2002 11:18:34 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10055 for ; Tue, 25 Jun 2002 11:17:49 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5PFMEV07703; Tue, 25 Jun 2002 10:22:17 -0500 Subject: Re: [Sip] Refer status/adjustment From: Robert Sparks To: "Daniel G. Petrie" Cc: sip@ietf.org In-Reply-To: <3D17F899.A5D25374@pingtel.com> References: <3D17F899.A5D25374@pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2002 10:17:02 -0500 Message-Id: <1025018225.1689.222.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2002-06-24 at 23:59, Daniel G. Petrie wrote: > The following comments pertain to > draft-sparks-sip-refer-3265disc-00.txt > > Overall I think this draft is mostly harmless. I think that it is > good to make things consistant with the latest SIP events. > On the other hand there are a lot of small changes for > not much functionaly increase. My major concern relates > to the existing installed base implemented on prior drafts > of REFER. There is a significant installed base of > products and services that depend upon prior versions > of the REFER draft. There are some upward compatability > issues in the changes proposed in this draft. Some mostly > minor comments are included below. > > I assume the rules for name-addr vs. addr-spec from RFC3261 apply > in the same way. That is in the Refer-To header examples that > have ? followed by header parameters, the name-addr form should > be used with angle brackets. Yes. > > Ignoring the installed base I have no technical issues with the use of > the referevent token to indicate the desire for notification of outcome. > > However, in the real world this presents an upward compatability > issue. If the transferor is a prior refer-3261 implementation, it > will not send the referevent token in the Supported header. If > the transferee is a post refer-3261 implementation it will not > send a notify and the transferor will wait a long time for the > NOTIFY request and at best give a false indication of transfer > failure. It is a little ugly, but reversing the sense is upward > compatable (e.g. noreferevent token). That just moves the compatibility shoe to another foot. Taking this route you step back into the mess of something that wants notification having no way to know whether its going to get it or not until after the first notify arrives. > > It seems that last paragraph in section 2.4.2 gives the REFER > recipient the choice of whether it wants to send a NOTIFY > event or not. I am not sure if I object to this or not, but > is there a reason or example of why this is useful? It does > make things a little more complicated in that there are > more possible outcomes (there is no shortage of error > cases even without this possibility). Well, if it didn't have that choice, we wouldn't have the problems motivating this referevent token at all. The choice exists exactly to allow elements to accept REFER but not create a subscription. Those arguing for it claim that events is to heavy to require its implementation (think _way_ back to the rather intense discussions we had on this at the Feb 2001 interim). > > 2.4.3 I think there is a possible race condition here. Though > the possiblity is remote the user agent sending the REFER > request should be prepared to receive the NOTIFY prior > to the 2xx response to the REFER. Oh I see that is pointed > out in 2.4.5 > > 2.5.6 Is it not valid to send any provisional response in the > sipfrag body (e.g. 180) when the subscription state is pending? If the subscription state is pending, the notifications carry a "nuetral" state. 100 fits that bill nicely. How were you seeing using 18x's? To carry information about the progress of obtaining authorization for the subscription? That information should go into the subscription-state header or somewhere else, but not in this body. This body carries the state of the referred event. > > Cheers, > Dan > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 12:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12955 for ; Tue, 25 Jun 2002 12:13:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22532 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 12:13:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19117; Tue, 25 Jun 2002 11:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19080 for ; Tue, 25 Jun 2002 11:46:09 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11539 for ; Tue, 25 Jun 2002 11:45:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PFjMN7010221; Tue, 25 Jun 2002 11:45:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 11:45:30 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A25D@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Daniel Petrie , Robert Sparks , sip@ietf.org Subject: RE: [Sip] Refer status/adjustment Date: Tue, 25 Jun 2002 11:45:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] > > My major concern relates > to the existing installed base implemented on prior drafts > of REFER. There is a significant installed base of > products and services that depend upon prior versions > of the REFER draft. There are some upward compatability > issues in the changes proposed in this draft. I understand what you're saying -- call transfer functionality fills a real need, and has been under construction for some time now. However, I fear that imposing backwards-compatibility requirements based on internet-drafts is a dangerous precedent that we need to avoid with all possible vigor. Historically, we've been pretty good about doing this; in particular, you'll notice a lack of provisions in the current draft for the TRANSFER verb, using the REFER response to convey the INVITE status, or for using the "Also" header in BYE messages. All of these omissions break backwards compatibilty with earlier work-in-progress. I think this situation points to the need for field-upgradable equipment as a risk management strategy, especially when implementing towards works-in-progress. Luckily, I beleive you had the foresight to address this. :) /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 12:24:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13572 for ; Tue, 25 Jun 2002 12:24:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23748 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 12:25:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19302; Tue, 25 Jun 2002 11:51:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19270 for ; Tue, 25 Jun 2002 11:51:56 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11745 for ; Tue, 25 Jun 2002 11:51:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PFpEN7010288; Tue, 25 Jun 2002 11:51:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 11:51:21 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A25E@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Robert Sparks , Sriram Parameswar Cc: sip@ietf.org Date: Tue, 25 Jun 2002 11:51:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] Event Filtering Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > We're seeing a similar kind of pressure in other event packages. Often > its called event-filtering. I'm still not sure whether a > filter approach > or a separate event is the better approach. In any case, this problem > is not an event refer specific one, so we shouldn't solve it in this > draft. We left this up to event packages in sip-events on purpose. (We say the SUBSCRIBE bodies can define filters and throttles, but don't define specifics). I don't beleive that it is even possible to define a useful general-purpose filtering mechanism, precisely because the variety of things you'll want to filter based on varies widely, and will need to be tailored to the exact type of state being conveyed. If I'm wrong, please make a proposal for such a mechanism. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 12:30:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13889 for ; Tue, 25 Jun 2002 12:30:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24515 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 12:30:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22136; Tue, 25 Jun 2002 12:05:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22107 for ; Tue, 25 Jun 2002 12:05:21 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12482 for ; Tue, 25 Jun 2002 12:04:38 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5PG4ug11980; Tue, 25 Jun 2002 11:04:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 11:04:42 -0500 Message-ID: From: "Sriram Parameswar" To: "'Adam Roach'" , Robert Sparks Cc: sip@ietf.org Date: Tue, 25 Jun 2002 11:04:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21C62.00F73950" Subject: [Sip] RE: Event Filtering Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C21C62.00F73950 Content-Type: text/plain; charset="iso-8859-1" Adam, I agree with you on the fact that each event package should define its own filters. I would tend to say that using different events for filtering would not work, simply because we can filter on various different criteria. However there was a draft that attempted a generic filtering architecture (draft-moran-sipping-filter-arch-00.txt), which did not get very much traction. Maybe the working group could take a look at that draft one more time? Thx, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Tuesday, June 25, 2002 10:51 AM To: Robert Sparks; Parameswar, Sriram [NGC:B615:EXCH] Cc: sip@ietf.org Subject: Event Filtering > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > We're seeing a similar kind of pressure in other event packages. Often > its called event-filtering. I'm still not sure whether a > filter approach > or a separate event is the better approach. In any case, this problem > is not an event refer specific one, so we shouldn't solve it in this > draft. We left this up to event packages in sip-events on purpose. (We say the SUBSCRIBE bodies can define filters and throttles, but don't define specifics). I don't beleive that it is even possible to define a useful general-purpose filtering mechanism, precisely because the variety of things you'll want to filter based on varies widely, and will need to be tailored to the exact type of state being conveyed. If I'm wrong, please make a proposal for such a mechanism. /a ------_=_NextPart_001_01C21C62.00F73950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Event Filtering

Adam,

I agree with you on the fact that each event package = should define its own filters. I would tend to say that using different = events for filtering would not work, simply because we can filter on = various different criteria. However there was a draft that attempted a = generic filtering architecture = (draft-moran-sipping-filter-arch-00.txt), which did not get very much = traction.

Maybe the working group could take a look at that = draft one more time?

Thx,

Sriram

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


-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: Tuesday, June 25, 2002 10:51 AM
To: Robert Sparks; Parameswar, Sriram = [NGC:B615:EXCH]
Cc: sip@ietf.org
Subject: Event Filtering


> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
>
> We're seeing a similar kind of pressure in = other event packages. Often
> its called event-filtering. I'm still not sure = whether a
> filter approach
> or a separate event is the better approach. In = any case, this problem
> is not an event refer specific one, so we = shouldn't solve it in this
> draft.

We left this up to event packages in sip-events on = purpose. (We say
the SUBSCRIBE bodies can define filters and = throttles, but don't
define specifics). I don't beleive that it is even = possible to define
a useful general-purpose filtering mechanism, = precisely because the
variety of things you'll want to filter based on = varies widely, and
will need to be tailored to the exact type of state = being conveyed.

If I'm wrong, please make a proposal for such a = mechanism.

/a

------_=_NextPart_001_01C21C62.00F73950-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jun 25 13:36:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17785 for ; Tue, 25 Jun 2002 13:36:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00557 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 13:37:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28392; Tue, 25 Jun 2002 13:14:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28362 for ; Tue, 25 Jun 2002 13:14:05 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@user3.pingtel.com [65.220.123.3] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16432 for ; Tue, 25 Jun 2002 13:13:22 -0400 (EDT) Received: from pingtel.com (cdhcp163.pingtel.com [10.1.1.163]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g5PHAAj16454; Tue, 25 Jun 2002 13:10:10 -0400 Message-ID: <3D18A487.6A95CB55@pingtel.com> Date: Tue, 25 Jun 2002 13:12:39 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Refer status/adjustment References: <9BF66EBF6BEFD942915B4D4D45C051F377A25D@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree that you generally should not look at drafts as having installed base. However this is not a precedent. Strict routing was never completely defined in RFC2543. It was clarified and defined in drafts. Yet a choice was made to make strict routing upward compatible in RFC3261. The previous changes to transfer (that you listed) were very significant and were not compatible. However the implementations were few and mostly only deployed in labs. The latest draft of REFER has been around for quite a while with few compatibility changes. There is a very significant installed base that implements it. This presents a difficult challenge for service providers and enterprises that have multi-vendor solutions. They cannot move forward until all the vendors do. I will ignore the dependency nightmare that occurs if you look at the cross enterprise and service provider interoperability problem. As a bit of a side note: I as a vendor have had to support BYE Also until very recently. There were some compatibility tricks for the transfer changes (e.g. method name support is easy to query using OPTIONS). SIP, the protocol supported the the various changes in the way transfer was implemented. Even if it had not it was less of an impact when those changes were made due to the side of the installed base. Sorry I did not mean to go on. I guess my main point is do not underestimate the power of the market to sanction a draft into a standard. Adam Roach wrote: > > -----Original Message----- > > From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] > > > > My major concern relates > > to the existing installed base implemented on prior drafts > > of REFER. There is a significant installed base of > > products and services that depend upon prior versions > > of the REFER draft. There are some upward compatability > > issues in the changes proposed in this draft. > > I understand what you're saying -- call transfer functionality > fills a real need, and has been under construction for some time > now. However, I fear that imposing backwards-compatibility > requirements based on internet-drafts is a dangerous precedent > that we need to avoid with all possible vigor. > > Historically, we've been pretty good about doing this; in > particular, you'll notice a lack of provisions in the current > draft for the TRANSFER verb, using the REFER response to convey > the INVITE status, or for using the "Also" header in BYE messages. > All of these omissions break backwards compatibilty with earlier > work-in-progress. > > I think this situation points to the need for field-upgradable > equipment as a risk management strategy, especially when > implementing towards works-in-progress. Luckily, I beleive you > had the foresight to address this. :) > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 25 15:38:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24662 for ; Tue, 25 Jun 2002 15:38:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11680 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 15:38:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09812; Tue, 25 Jun 2002 15:08:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09751 for ; Tue, 25 Jun 2002 15:08:17 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23424; Tue, 25 Jun 2002 15:07:32 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5PJC6V08294; Tue, 25 Jun 2002 14:12:06 -0500 From: Robert Sparks To: sip@ietf.org, sipping@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Jun 2002 14:05:44 -0500 Message-Id: <1025031945.9781.267.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 11 Information Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Information on SIPIT 11 is available at http://www.pulver.com/sipit11 Registration is open. 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 daemon@ns.ietf.org Tue Jun 25 16:58:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28489 for ; Tue, 25 Jun 2002 16:58:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16553 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 16:59:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15168; Tue, 25 Jun 2002 16:31:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15097 for ; Tue, 25 Jun 2002 16:31:11 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27487; Tue, 25 Jun 2002 16:30:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PKURN7012880; Tue, 25 Jun 2002 16:30:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 16:30:33 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A264@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Gonzalo Camarillo'" , Jonathan Rosenberg Cc: sip , rohc Subject: RE: [Sip] Re: [rohc] SigComp and SIP Date: Tue, 25 Jun 2002 16:30:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > This covers the following scenario: > > UAC----P1-----P2-----UAS > > The UAC sends an INITE to UAS. P2 records route, but P1 does not. > When the 200 OK for the INVITE reaches P2, the contact and RR header > fields will look like this: > > Contact: UAS@domain.com;comp=sigcomp > RR: P2 > > If P2 does not add comp=sigcomp to his entry in the RR, UAC > will be able > to receive compressed traffic (the contact has comp=sigcomp), but will > be unable to send compress traffic (the RR entry for P2 does not have > it). > > Making P2 add comp=sigcomp resolves this asymmetry I would argue that any network that uses compression like this will almost certainly have a compression/decompression node (P1 in your example) in the path, and record-routing. I don't beleive the extra complexity you describe is worth the effort of what amounts to trying to work around poorly-designed networks. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 25 17:18:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29291 for ; Tue, 25 Jun 2002 17:18:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18554 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 17:18:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16191; Tue, 25 Jun 2002 16:51:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16168 for ; Tue, 25 Jun 2002 16:51:42 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28273 for ; Tue, 25 Jun 2002 16:50:56 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5PKoX502921; Tue, 25 Jun 2002 15:50:33 -0500 From: "Dean Willis" To: "'Ranjit Avasarala'" , Cc: Subject: RE: [Sip] subscribe - event package Date: Tue, 25 Jun 2002 15:50:23 -0500 Message-ID: <015001c21c89$ed721850$eb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0151_01C21C60.049C1050" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <003301c21c33$3b1f1dc0$5f0d0a0a@SIGMA> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0151_01C21C60.049C1050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Perhaps the "presence" event package (see SIMPLE wg) would suffice for your needs? really, what you want to subscribe to is the availability of B, which is probably not known by your server but may be known by B's server. -- dean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Ranjit Avasarala Sent: Tuesday, June 25, 2002 5:30 AM To: sip@ietf.org Cc: sip-implementors@cs.columbia.org Subject: [Sip] subscribe - event package Hi This is with ref to draft-ietf-sip-events-05.txt I have a doubt in the implementation of events template package. What should this package contain. Say I am implementing the call waiting feature on Server Now A calls B and B is busy. So i get a Busy Here msg to A. Then I can SUBSCRIBE a event on my server and ask it to NOTIFY me when B is Free. so any suggestions? Thanks Ranjit ------=_NextPart_000_0151_01C21C60.049C1050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Perhaps the "presence" event package (see SIMPLE wg) =  would suffice=20 for your needs?
 
really, what you want to subscribe to is the availability of B, = which is=20 probably not known by your server but may be known by B's=20 server.
 
--
dean
 
 ------=_NextPart_000_0151_01C21C60.049C1050-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 25 17:54:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00593 for ; Tue, 25 Jun 2002 17:54:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20314 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 17:54:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19544; Tue, 25 Jun 2002 17:33:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19517 for ; Tue, 25 Jun 2002 17:33:40 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29775 for ; Tue, 25 Jun 2002 17:32:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PLX1N7013378; Tue, 25 Jun 2002 17:33:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 17:33:07 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A266@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] subscribe - event package Date: Tue, 25 Jun 2002 17:33:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I already responded to this personally (actually, I attempted to pare the distribution back to sip-implementors, but later realized that it bounced). I'll repeat the answer here in an attemtp to prevent a dogpile of answers. What you seem to want is an event package that will inform you when the called user's dialog state transitions to idle. There is work ongoing to define a package that gives you exactly this information; see draft-rosenberg-sip-call-package-01.txt. Note that, in the most common case, the subscription will actually be sent to the called party, not to a proxy; keep in mind that SIP doesn't actually require a server to be in the call path for all calls. /a -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, June 25, 2002 15:50 To: 'Ranjit Avasarala'; sip@ietf.org Cc: sip-implementors@cs.columbia.org Subject: RE: [Sip] subscribe - event package Perhaps the "presence" event package (see SIMPLE wg) would suffice for your needs? really, what you want to subscribe to is the availability of B, which is probably not known by your server but may be known by B's server. -- dean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Ranjit Avasarala Sent: Tuesday, June 25, 2002 5:30 AM To: sip@ietf.org Cc: sip-implementors@cs.columbia.org Subject: [Sip] subscribe - event package Hi This is with ref to draft-ietf-sip-events-05.txt I have a doubt in the implementation of events template package. What should this package contain. Say I am implementing the call waiting feature on Server Now A calls B and B is busy. So i get a Busy Here msg to A. Then I can SUBSCRIBE a event on my server and ask it to NOTIFY me when B is Free. so any suggestions? Thanks Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jun 25 18:46:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02222 for ; Tue, 25 Jun 2002 18:46:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23835 for sip-archive@odin.ietf.org; Tue, 25 Jun 2002 18:47:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22414; Tue, 25 Jun 2002 18:26:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22382 for ; Tue, 25 Jun 2002 18:26:20 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01639 for ; Tue, 25 Jun 2002 18:25:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5PMPgN7013820; Tue, 25 Jun 2002 18:25:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 18:25:48 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A26A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" , "'gonzalo.camarillo@ericsson.com'" Date: Tue, 25 Jun 2002 18:25:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP and SigComp draft comment. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There has been a bit of discussion about how to handle Contact, Route, and Record-Route with the "comp=sigcomp" parameter. There's a closely related issue that hasn't yet been touched on, though: when the called party issues a request, the "comp=sigcomp" headers end up being essentially in the wrong place. I'll demonstrate by way of an example. +---+ +----+ +----+ +----+ +---+ | A |...| P1 |---| P2 |---| P3 |...| B | +---+ +----+ +----+ +----+ +---+ A and B are wireless terminals with very low bandwidth links (and, consequently, use SigComp). P1, P2, and P3 are all proxies on the network. A sends an INVITE to B. Assuming that each proxy inserts its record-routes so that A gets the proper route-set, you get the following at B: Record-Route: Record-Route: Record-Route: Contact: This is, of course, stored in B as the route set: ,,, The response to the request delivers the same set of Record-Routes to A, but with a contact of "sip:userb@B;comp=sigcomp": ,,, So, A's route is absolutely correct; it will compress the message sent to P1, and P3 will compress the message sent to B. Unfortunately, B's route is really screwy. If it obeys the "comp" parameters, B *won't* compress any requests in this dialog, so you'll be sending uncompressed messages over the radio link. And, in a bitter irony, P2 will waste cycles compressing the messages sent to P1 -- which turns out to be completely unnecessary. In fact, it exacerbates the fact that the B -> P3 request was sent uncompressed. If we have the proxies tailor the route set for B, the same problem happens, in the opposite direction. The solution lies in step 8, detailed in section 16.7 of 2543bis-09. In this case, the proxies would tailor the inserted "Record-Routes" in the request for B's consumption: Record-Route: Record-Route: Record-Route: Contact: Then, as the INVITE response passes back through P3 and P1, they would each modify the Record-Route headers so that they are appropriate for A's consumption: Record-Route: Record-Route: Record-Route: Contact: Even though it's described in SIP, this usage should probably be explicitly mentioned in in the SIP SigComp draft; otherwise, we run the risk of having nodes do strange things. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 26 06:14:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09618 for ; Wed, 26 Jun 2002 06:14:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15183 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 06:15:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13060; Wed, 26 Jun 2002 05:41:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13020 for ; Wed, 26 Jun 2002 05:41:01 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h77s128a211n47.user.nortelnetworks.com [47.211.128.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08913 for ; Wed, 26 Jun 2002 05:40:15 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5Q9e5f27830; Wed, 26 Jun 2002 10:40:06 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 10:40:07 +0100 Message-ID: From: "Chris Hogg" To: "'Christer Holmberg'" Cc: Flemming Andreasen , Jonathan Rosenberg , "Mark Watson" , sip@ietf.org, Bob Penfield Subject: Re: [Sip] Local vs Remote ringback on 180 Date: Wed, 26 Jun 2002 10:40:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21CF5.745AF61E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21CF5.745AF61E Content-Type: text/plain; charset="ISO-8859-1" Hi Christer, I'm a bit late into this discussion, but I'll put my thoughts in anyway. >>However, if you mean that it doesn't change what is sent to the listener either >>I think what is written in some drafts is wrong. It IS said (at least that is my >>understanding) that SDP/no-SDP in 180 DOES indicate if a remote ringback tone >>will be generated or not. [CH] It is my understanding that previous (pre-"UNIFY" draft) versions of the bis did indicate that you could use the presence or absence of SDP to indicate whether or not the UAC should generate local ringback or play media. If my understanding is correct, this was removed because of the need to solve many other problems (e.g. HERFP, early media etc) which all arose out of the dependence of session state on the SIP signalling. By creating the offer-answer model (and the additional SIP specific offer-answer rules within RFC3261) then independence of session state from SIP signalling state was achieved. I believe the current version of SIP only says that the 180 MAY be used to generate local ringback but does not say how this is achieved since it is implementation dependent. I believe that the most likely way to do this currently is to initiate a new offer-answer exchange in an UPDATE/200 OK(UPDATE) with the new offer (from the UAS) indicating that the media stream direction is a=recvonly or a=inactive. Its' then up to the UAC/implementation to decide what to do now that it knows that there is no media coming from the far end. This could be playing local ringback or playing an announcement or popping a window up on a screen. I understand the reasoning behind trying to reduce the number of messages sent to achieve this aim, however I am also concerned about creating a special case for local ringing. Just my 2 cents. Best Regards, Cheers Chris Chris Hogg Nortel Networks ------_=_NextPart_001_01C21CF5.745AF61E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] Local vs Remote ringback on 180

Hi Christer,

I'm a bit late into this discussion, but I'll put my = thoughts in anyway.


>>However, if you mean that it doesn't change = what is sent to the listener either
>>I think what is written in some drafts is = wrong. It IS said (at least that is my
>>understanding) that SDP/no-SDP in 180 DOES = indicate if a remote ringback tone
>>will be generated or not.



[CH] It is my understanding that previous = (pre-"UNIFY" draft) versions of the bis did indicate that you = could use the presence or absence of SDP to indicate whether or not the = UAC should generate local ringback or play media.  If my = understanding is correct, this was removed because of the need to solve = many other problems (e.g. HERFP, early media etc) which all arose out = of the dependence of session state on the SIP signalling.  By = creating the offer-answer model (and the additional SIP specific = offer-answer rules within RFC3261) then independence of session state = from SIP signalling state was achieved.  I believe the current = version of SIP only says that the 180 MAY be used to generate local = ringback but does not say how this is achieved since it is = implementation dependent. 

I believe that the most likely way to do this = currently is to initiate a new offer-answer exchange in an UPDATE/200 = OK(UPDATE) with the new offer (from the UAS) indicating that the media = stream direction is a=3Drecvonly or a=3Dinactive.  Its' then up to = the UAC/implementation to decide what to do now that it knows that = there is no media coming from the far end.  This could be playing = local ringback or playing an announcement or popping a window up on a = screen. I understand the reasoning behind trying to reduce the number = of messages sent to achieve this aim, however I am also concerned about = creating a special case for local ringing.

Just my 2 cents.


Best Regards,


Cheers
Chris

Chris Hogg
Nortel Networks

------_=_NextPart_001_01C21CF5.745AF61E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 26 07:09:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11916 for ; Wed, 26 Jun 2002 07:09:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19147 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 07:09:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17554; Wed, 26 Jun 2002 06:47:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17531 for ; Wed, 26 Jun 2002 06:46:57 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11256 for ; Wed, 26 Jun 2002 06:46:12 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 26 Jun 2002 12:45:32 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 12:46:22 +0200 Message-Id: From: "Jesske, R" To: adam@dynamicsoft.com, Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org Cc: "Pinker, Gerold" , Robert.Benz@telekom.de, "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , DieterK@telekom.de, "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: AW: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Wed, 26 Jun 2002 12:46:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA17532 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Thank you for your answer and possible solutions. comments below. Roland > -----Ursprüngliche Nachricht----- > Von: Adam Roach [mailto:adam@dynamicsoft.com] > Gesendet am: Montag, 24. Juni 2002 17:44 > An: Jesske, Roland; Gonzalo.Camarillo@lmf.ericsson.se; sip@ietf.org > Cc: Pinker, Gerold; Benz, Robert; Alexeitsev, Denis; Tolksdorf, > Christian; Pötzl, Joachim; Schütte, Wolfgang; Köhler, Dieter; > Hülsemann, > Martin; Martinez Rebordosa, Anna > Betreff: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics > > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@telekom.de] > > > > E.g. Cause Value 34 could be a normal release indicating a > > congestion in a transit or international network but Cause > > Value 34 with a diagnostic field including the CCBS possible > > indication coming from a private network indicates a busy > > network where the CCBS service is possible. > > > > CCBS is within ISDN networks a frequently used service. For > > the future interworking of SIP with ISDN networks the > > indication of location and diagnostics is a extension that > > enables the CCBS over networks. > > > > The reason draft is OK for only indicating the reason of a > > release but for service interworking with the PSTN it would > > be better to have also the location and reason available. > > The idea behind including Q.850 in the reason draft is certainly > not to push ISUP semantics like this into the SIP network. For > your suggestion to be useful, it would require every device > on the network to implement detailed ISUP semantics in addition > to normal SIP semantics. It is not my Idea to force SIP network elements to understand the whole ISUP. From my understanding the Reason Draft was created to give SIP elements additional information to react on these. What I didn't realised (because of my Ideas in my head) is that the reason Draft is only for *REQUESTS* (and in 155 responses. And I saw that the draft is already approved, therefore my comments are not longer valid. > > Further, the level of service interworking you are hinting at > requires a much better defined mechanism than simply conveying > the every last bit of the Q.850 cause code. For example, if > we accepted your suggestion, how would the SIP node go about > ordering CCBS? Would we expect normal SIP nodes to have the > ability to generate and tunnel TCAP through M3UA back to the MGC? > That seems a bit extreme -- and, even if we accepted this as a > solution, it requires much more rigorous specification than merely > adding location values to the Q.850 cause codes sent to the SIP > network (e.g. how do you route the tunneled TCAP?). You are right that the inclusion of location and the diagnostic field is not the solution of this problem. It was for me only the start. And I thought not of tunnelling the SCCP thought the SIP network. What I thought was to find appropriate SIP Messages and procedures that allows the interworking of TCAP/SCCP Messages to SIP. > > Am I saying such service interworking is impossible? Of course not. > I'm just saying that such interworking necessarily *must* allow > the PSTN network to do things in a PSTN way, and *must* allow the > SIP network to do things in a SIP way. agreed ! For such kind of scenario there should be a SIP - TCAP/SCCP interworking. I think that will be driven by operators, service provider and vendors that will offer such kind of services. The problem is that the TC Messages will be send after the call is finished. I don't know (at the moment) how SIP can support such kind of scenario. > > Here's a mile-high sketch of how CCBS interworking would be specified: > upon receipt of a REL with cause 34 and a diagnostic indicating that > CCBS is available, the MGC would send a normal 486, with an > "Allow-Events" > header of "dialog" (see draft-rosenberg-sip-call-package-01.txt). The Ok! This is the proposed mapping of cause 17 and 34 with CCBS possible within the ITU mapping spec (Q.1912.sip). > UAC, if it supports CCBS, would subscribe to the state of the dialog > at the gateway. The gateway would take appropriate actions (e.g. > generation of TCAP messages) based on this subscription. The remainder Yes! The generation of the TCAP/SCCP CCBS Messages should be done by the interworking function (Gateway). If I understand you correct, than it would be possible with this subscription that the SIP user can indicate that he will use the CCBS Service and he get also the indication back if the called user is free. So that the UA can initiate a new call or the GW can initiate a new call to the both parties. > of the interactions are left as an excercise for the reader, > but can be > deduced from the call-package draft and normal PSTN CCBS procedures. > (Note that the information returned in the "dialog" event > notifications > might be a very limited subset of what is specified in the > call-package > draft; this will not cause any problems that I am aware of). Thank you for your answer and for your considerations regarding CCBS > > /a > > P.S. As an aside, the application you describe would be predicated > on including Q.850 codes in a *RESPONSE*. The Reason draft is > currently specified such that reason headers can appear only > in *REQUESTS* (and in 155 responses). > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 26 07:10:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11960 for ; Wed, 26 Jun 2002 07:10:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19242 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 07:11:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17009; Wed, 26 Jun 2002 06:41:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16977 for ; Wed, 26 Jun 2002 06:41:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10407; Wed, 26 Jun 2002 06:41:03 -0400 (EDT) Message-Id: <200206261041.GAA10407@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Jun 2002 06:41:03 -0400 Subject: [Sip] I-D ACTION:draft-schulzrinne-sip-bind-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Binding Generic URIs to SIP URIs Author(s) : H. Schulzrinne Filename : draft-schulzrinne-sip-bind-00.txt Pages : 12 Date : 25-Jun-02 For many services, it is useful to be able to associate data, represented by URLs, with SIP user identifiers, both address-of- records and host-based user names. This draft proposes a solution that addresses most of the requirements for such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-bind-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-sip-bind-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-sip-bind-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020625141722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-sip-bind-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-sip-bind-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625141722.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 08:54:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16339 for ; Wed, 26 Jun 2002 08:54:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27183 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 08:55:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24478; Wed, 26 Jun 2002 08:29:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18845 for ; Tue, 25 Jun 2002 02:09:35 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23470 for ; Tue, 25 Jun 2002 02:08:50 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5P69NRb024046; Tue, 25 Jun 2002 08:09:23 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g5P69Ma9025761; Tue, 25 Jun 2002 09:09:23 +0300 (EET DST) Message-ID: <3D180912.DD1D79A6@lmf.ericsson.se> Date: Tue, 25 Jun 2002 09:09:22 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: "'Cullen Jennings'" , "'Jesske, R'" , sip@ietf.org, "Pinker, Gerold" , Robert.Benz@telekom.de, "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , DieterK@telekom.de, "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: Re: [Sip] Reason version 01 - Q.850 Location and diagnostics References: <9BF66EBF6BEFD942915B4D4D45C051F377A251@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam, As you pointed out in a later mail, this draft has been already approved, so we will not have the opportunity to include motivational text any more (although a small clarification would be always possible). Anyway, the idea behind including a name space in this header (Q.850, SIP, etc...) is to make debugging easier. Sometimes it is useful to know what is going on in the gateway. As you pointed out as well, for a complete mapping, encapsulating the ISUP REL message seems like a much better idea. It is also useful to include the Q.850 cause value in CANCELs, where it is not ensured that the REL in the body will be transmitted end-to-end. Regards, Gonzalo Adam Roach wrote: > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > > Behalf Of Adam > > > Roach > > > > > > The idea behind including Q.850 in the reason draft is certainly > > > not to push ISUP semantics like this into the SIP network. For > > > > > > > I agree with Adam but just out of curiosity, why is the Q.850 > > stuff in the > > SIP network? > > Cullen has a good point -- one that has occured to me before. The > draft needs some motivating text around this. If there isn't a > really compelling motivation, it probably needs to be removed. > > /a -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 08:56:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16471 for ; Wed, 26 Jun 2002 08:56:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27366 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 08:57:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24406; Wed, 26 Jun 2002 08:29:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12220 for ; Tue, 25 Jun 2002 15:50:33 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25088; Tue, 25 Jun 2002 15:49:48 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5PJoSrU008970; Tue, 25 Jun 2002 21:50:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 21:50:27 +0200 Message-ID: From: "Lars-Erik Jonsson (EPL)" To: "'Adam Roach'" , "Gonzalo Camarillo Gonzalez (LMF)" , Jonathan Rosenberg Cc: sip , rohc Date: Tue, 25 Jun 2002 21:49:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > If folks think that it is OK that two proxies that support > > SigComp MUST always exchange compressed messages, I will be glad > > to simplify the draft. If people feel that compressing when it > > is not really needed is unacceptable, we will keep the current > > Record-Route inspection mechanism. > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > This is *NOT* acceptable. The performance impacts of any realistic > compression algorithm are substantial. Over the air, the decreased > throughput (and ultimately increased hardware costs) is justified > by decreased latency. Between nodes operating on a wired network, > it's merely a losing proposition. I tend to agree with Adam, it should not be mandatory for a proxy to use compression just because compression is supported. /L-E _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 08:57:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16548 for ; Wed, 26 Jun 2002 08:57:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27443 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 08:58:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24437; Wed, 26 Jun 2002 08:29:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18952 for ; Mon, 24 Jun 2002 17:47:29 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03331 for ; Mon, 24 Jun 2002 17:46:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5OLkhN7005858; Mon, 24 Jun 2002 17:46:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 17:46:48 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A251@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , "'Jesske, R'" , Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org Cc: "Pinker, Gerold" , Robert.Benz@telekom.de, "Alexeitsev, D" , "Tolksdorf, Christian" , "Poetzl, Joachim" , "Schuette, Wolfgang" , DieterK@telekom.de, "Huelsemann, Martin" , "Martinez-Rebordosa, Anna" Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Mon, 24 Jun 2002 17:46:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of Adam > > Roach > > > > The idea behind including Q.850 in the reason draft is certainly > > not to push ISUP semantics like this into the SIP network. For > > > > I agree with Adam but just out of curiosity, why is the Q.850 > stuff in the > SIP network? Cullen has a good point -- one that has occured to me before. The draft needs some motivating text around this. If there isn't a really compelling motivation, it probably needs to be removed. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 09:04:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16879 for ; Wed, 26 Jun 2002 09:04:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28225 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 09:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24458; Wed, 26 Jun 2002 08:29:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19383 for ; Mon, 24 Jun 2002 17:50:02 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03583 for ; Mon, 24 Jun 2002 17:49:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5OLnLN7005879; Mon, 24 Jun 2002 17:49:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 17:49:26 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A253@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Adam Roach , "'Cullen Jennings'" , "'Jesske, R'" , "'Gonzalo.Camarillo@lmf.ericsson.se'" , "'sip@ietf.org'" Cc: "'Pinker, Gerold'" , "'Robert.Benz@telekom.de'" , "'Alexeitsev, D'" , "'Tolksdorf, Christian'" , "'Poetzl, Joachim'" , "'Schuette, Wolfgang'" , "'DieterK@telekom.de'" , "'Huelsemann, Martin'" , "'Martinez-Rebordosa, Anna'" Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics Date: Mon, 24 Jun 2002 17:49:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry; I didn't realize the draft was about to be approved. I withdraw my concerns. /a > -----Original Message----- > From: Adam Roach > Sent: Monday, June 24, 2002 16:47 > To: 'Cullen Jennings'; Adam Roach; 'Jesske, R'; > Gonzalo.Camarillo@lmf.ericsson.se; sip@ietf.org > Cc: Pinker, Gerold; Robert.Benz@telekom.de; Alexeitsev, D; Tolksdorf, > Christian; Poetzl, Joachim; Schuette, Wolfgang; DieterK@telekom.de; > Huelsemann, Martin; Martinez-Rebordosa, Anna > Subject: RE: [Sip] Reason version 01 - Q.850 Location and diagnostics > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > > Behalf Of Adam > > > Roach > > > > > > The idea behind including Q.850 in the reason draft is certainly > > > not to push ISUP semantics like this into the SIP network. For > > > > > > > I agree with Adam but just out of curiosity, why is the Q.850 > > stuff in the > > SIP network? > > Cullen has a good point -- one that has occured to me before. The > draft needs some motivating text around this. If there isn't a > really compelling motivation, it probably needs to be removed. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 13:31:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01274 for ; Wed, 26 Jun 2002 13:31:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17471 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 13:32:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13572; Wed, 26 Jun 2002 12:44:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13505 for ; Wed, 26 Jun 2002 12:43:59 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28392; Wed, 26 Jun 2002 12:43:15 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5QGlWj08050; Wed, 26 Jun 2002 11:47:32 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Jun 2002 11:43:56 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 26 Jun 2002 11:43:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Jun 2002 11:43:16 -0500 Message-ID: Thread-Topic: [rohc] SigComp and SIP Thread-Index: AcIcIR6SFmZX+VopTTCN8HgIMKP39ABDiD8w To: , Cc: , X-OriginalArrivalTime: 26 Jun 2002 16:43:17.0227 (UTC) FILETIME=[927063B0:01C21D30] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA13506 Subject: [Sip] RE: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > If folks think that it is OK that two proxies that support SigComp MUST > always exhange compressed messages, I will be glad to simplify the > draft. If people feel that compressing when it is not really needed is > unacceptable, we will keep the current Record-Route inspection > mechanism. I probably missed something here but why do we mix the support of SigComp with the use of it? Looking at one direction, the sender needs to know if the receiver supports SigComp. But beyond that, it is the sender's choice whether to send compressed message. In other words, once a receiver says "I support SigComp", it's out of its control and it must prepare for receiving both compressed and uncompressed message. Zhigang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 14:59:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05724 for ; Wed, 26 Jun 2002 14:59:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23187 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 15:00:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20786; Wed, 26 Jun 2002 14:21:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20755 for ; Wed, 26 Jun 2002 14:21:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03807 for ; Wed, 26 Jun 2002 14:21:04 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5QILEi28940 for ; Wed, 26 Jun 2002 13:21:14 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5QILEk07287 for ; Wed, 26 Jun 2002 13:21:14 -0500 (CDT) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g5QILDE06034 for ; Wed, 26 Jun 2002 14:21:13 -0400 (EDT) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Jun 2002 14:22:42 -0400 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF8302AFFFB7@eammlnt051.lmc.ericsson.se> From: "Andre Poulin (LMC)" To: "'sip@ietf.org'" Date: Wed, 26 Jun 2002 14:21:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Authentication-Info header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have a question regarding Authentication headers. What is the reason to have only one Authentication-Info header instead of having both www-Authentication-Info and proxy- Authentication-Info headers? This does not seem to be consistent with the other related authentication headers which have both cases (www and proxy) Thanks, /Andre _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 15:38:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07745 for ; Wed, 26 Jun 2002 15:38:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25911 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 15:39:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23321; Wed, 26 Jun 2002 15:00:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23265 for ; Wed, 26 Jun 2002 15:00:20 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05737 for ; Wed, 26 Jun 2002 14:59:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QIwWYH023080; Wed, 26 Jun 2002 14:58:32 -0400 (EDT) Message-ID: <3D1A0ED7.1040009@dynamicsoft.com> Date: Wed, 26 Jun 2002 14:58:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] subscribe - event package References: <9BF66EBF6BEFD942915B4D4D45C051F377A266@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam is right, the dialog package is exactly the right thing. It now exists as a standalone I-D: http://www.jdrosen.net/papers/draft-ietf-sipping-dialog-package-00.txt which should appear in the I-D archives sometime this week. -Jonathan R. Adam Roach wrote: > I already responded to this personally (actually, I attempted to pare > the distribution back to sip-implementors, but later realized that it > bounced). I'll repeat the answer here in an attemtp to prevent a > dogpile of answers. > > What you seem to want is an event package that will inform you when the > called user's dialog state transitions to idle. There is work ongoing > to define a package that gives you exactly this information; see > draft-rosenberg-sip-call-package-01.txt. > > Note that, in the most common case, the subscription will actually > be sent to the called party, not to a proxy; keep in mind that > SIP doesn't actually require a server to be in the call path for > all calls. > > /a > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, June 25, 2002 15:50 > To: 'Ranjit Avasarala'; sip@ietf.org > Cc: sip-implementors@cs.columbia.org > Subject: RE: [Sip] subscribe - event package > > > Perhaps the "presence" event package (see SIMPLE wg) would suffice for > your > needs? > > really, what you want to subscribe to is the availability of B, which is > probably not known by your server but may be known by B's server. > > -- > dean > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Ranjit > Avasarala > Sent: Tuesday, June 25, 2002 5:30 AM > To: sip@ietf.org > Cc: sip-implementors@cs.columbia.org > Subject: [Sip] subscribe - event package > > > Hi > > This is with ref to draft-ietf-sip-events-05.txt > > I have a doubt in the implementation of events template package. > What > should this package contain. Say I am implementing the call waiting > feature > on Server > > Now A calls B and B is busy. So i get a Busy Here msg to A. Then I can > SUBSCRIBE a event on my server and ask it to NOTIFY me when B is Free. > > so any suggestions? > > Thanks > Ranjit > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jun 26 19:05:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14893 for ; Wed, 26 Jun 2002 19:05:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07555 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 19:06:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04744; Wed, 26 Jun 2002 18:22:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04715 for ; Wed, 26 Jun 2002 18:22:27 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@user3.pingtel.com [65.220.123.3] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13730 for ; Wed, 26 Jun 2002 18:21:44 -0400 (EDT) Received: from pingtel.com (cdhcp163.pingtel.com [10.1.1.163]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g5QMIIj13472; Wed, 26 Jun 2002 18:18:18 -0400 Message-ID: <3D1A3E49.4A795013@pingtel.com> Date: Wed, 26 Jun 2002 18:20:57 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Refer status/adjustment References: <3D17F899.A5D25374@pingtel.com> <1025018225.1689.222.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Coments below: Robert Sparks wrote: > On Mon, 2002-06-24 at 23:59, Daniel G. Petrie wrote: > > The following comments pertain to > > draft-sparks-sip-refer-3265disc-00.txt > > ... > > > > > Ignoring the installed base I have no technical issues with the use of > > the referevent token to indicate the desire for notification of outcome. > > > > However, in the real world this presents an upward compatability > > issue. If the transferor is a prior refer-3261 implementation, it > > will not send the referevent token in the Supported header. If > > the transferee is a post refer-3261 implementation it will not > > send a notify and the transferor will wait a long time for the > > NOTIFY request and at best give a false indication of transfer > > failure. It is a little ugly, but reversing the sense is upward > > compatable (e.g. noreferevent token). > > That just moves the compatibility shoe to another foot. > Taking this route you step back into the mess of something that > wants notification having no way to know whether its going to > get it or not until after the first notify arrives. Sorry I may have missed something in your point. Let me clarify what I was suggesting to make sure that is not the problem. In prior REFER drafts it was assumed that the NOTIFY was manditory. Even so, a robust implementation which is tolerent of error conditions MUST tolerate the case where the NOTIFY never gets delivered (e.g. due to network failures). Otherwise your user agent hangs forever waiting for a NOTIFY that dropped on the floor. With or without the Supported token in either sense this is necessary. My suggestion was to make the implied subscription the default (I think that you will find that most existing implementations do this.). Then use the Supported token (e.g. noreferevent) as a way to say that a subscription is not desired. This way the risk of interoperability is that a UA gets an implied subscription that it does not want. This is easily solved with a 481 response or worst case just ignored. On the server side of the REFER, a server which does not implement the subscription SHOULD either send an error if the noreferevent tag is not present or it SHOULD send a single immediate NOTIFY indicating the subscription is terminated. This is fairly light weight as the full subscription framework is not needed only a trivial NOTIFY. It also does not require any subscription state (which I am guessing is the major objection to events being too heavy weight to implement in this case). The NOTIFY should probably have either a 180 or failure code. So the assumtion is that a UA sending a REFER will receive a NOTIFY unless the noreferevent token is present. This is the source of my confusion with your statement above. > > > > > > It seems that last paragraph in section 2.4.2 gives the REFER > > recipient the choice of whether it wants to send a NOTIFY > > event or not. I am not sure if I object to this or not, but > > is there a reason or example of why this is useful? It does > > make things a little more complicated in that there are > > more possible outcomes (there is no shortage of error > > cases even without this possibility). > > Well, if it didn't have that choice, we wouldn't have the > problems motivating this referevent token at all. > > The choice exists exactly to allow elements to accept REFER but > not create a subscription. Those arguing for it claim that events > is to heavy to require its implementation (think _way_ back to the > rather intense discussions we had on this at the Feb 2001 interim). > I have been poking through the list trying to find a more recent discussion of this requirement without much luck. Could you point me at the dates of some message. I guess that in pursuing the NOTIFY solution we had concluded that it was ok to require events. I am still wondering if this is a requirement we really need to satisfy. I worry about interoperability (of implementation of this draft, not different versions of the refer draft) with this requirement. If events support is not required or at least a SHOULD you end up bringing the whole experience down to a lowest common denominator. It ends up making both solutions (with and without events) more complicated in terms of error cases that can occur. I appologize if this was already discussed recently on the list. I guess I find the claim that events is too heavy weight to be a weak rational. I disagree with the requirement to make events optional. > > > > > 2.4.3 I think there is a possible race condition here. Though > > the possiblity is remote the user agent sending the REFER > > request should be prepared to receive the NOTIFY prior > > to the 2xx response to the REFER. Oh I see that is pointed > > out in 2.4.5 > > > > 2.5.6 Is it not valid to send any provisional response in the > > sipfrag body (e.g. 180) when the subscription state is pending? > > If the subscription state is pending, the notifications carry a > "nuetral" state. 100 fits that bill nicely. How were you seeing using > 18x's? To carry information about the progress of obtaining > authorization for the subscription? That information should go > into the subscription-state header or somewhere else, but not in > this body. This body carries the state of the referred event. > Ignore the 18x issue. My mistake. Sorry. > > > > > Cheers, > > Dan > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 26 19:44:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15928 for ; Wed, 26 Jun 2002 19:44:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08894 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 19:45:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07626; Wed, 26 Jun 2002 19:07:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07585 for ; Wed, 26 Jun 2002 19:07:47 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14938 for ; Wed, 26 Jun 2002 19:07:03 -0400 (EDT) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5QN7krU020608 for ; Thu, 27 Jun 2002 01:07:46 +0200 (MEST) Received: from lmf.ericsson.se (arbru3m03.eu.ericsson.se [164.48.163.4]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g5QN7iqn001764 for ; Thu, 27 Jun 2002 01:07:44 +0200 (MET DST) Message-ID: <3D1A4955.353CAAFA@lmf.ericsson.se> Date: Thu, 27 Jun 2002 02:08:05 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Small question on UPDATE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a couple of small clarification question on UPDATE. Q1: Chapter 13.2.1 in bis-09 says: "If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE." Now, if the UAC receives a 155, and sends a new offer, it will never receive an answer in a non-failure message for the INVITE. Or, is the message (UPDATE) carrying the new offer assumed to be "correlated" to the INVITE? Q2: Is the UAS allowed to send 155 AFTER it has sent other provisional response(s) to the INVITE? The draft doesn't specifically say it, only that 155 shall be sent before the called party is alarmed. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jun 26 19:44:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15931 for ; Wed, 26 Jun 2002 19:44:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08905 for sip-archive@odin.ietf.org; Wed, 26 Jun 2002 19:45:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07670; Wed, 26 Jun 2002 19:08:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07635 for ; Wed, 26 Jun 2002 19:08:10 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14946 for ; Wed, 26 Jun 2002 19:07:26 -0400 (EDT) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5QN7xRb026624; Thu, 27 Jun 2002 01:07:59 +0200 (MEST) Received: from lmf.ericsson.se (arbru3m03.eu.ericsson.se [164.48.163.4]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g5QN7tqn001777; Thu, 27 Jun 2002 01:07:56 +0200 (MET DST) Message-ID: <3D1A4960.82A45126@lmf.ericsson.se> Date: Thu, 27 Jun 2002 02:08:17 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Hogg CC: Flemming Andreasen , Jonathan Rosenberg , Mark Watson , sip@ietf.org, Bob Penfield Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Chris, Chris Hogg wrote: > > > Hi Christer, > > I'm a bit late into this discussion, but I'll put my thoughts in > anyway. > > >>However, if you mean that it doesn't change what is sent to the > listener either > >>I think what is written in some drafts is wrong. It IS said (at > least that is my > >>understanding) that SDP/no-SDP in 180 DOES indicate if a remote > ringback tone > >>will be generated or not. > > > [CH] It is my understanding that previous (pre-"UNIFY" draft) versions > of the bis did indicate that you could use the presence or absence of > SDP to indicate whether or not the UAC should generate local ringback > or play media. If my understanding is correct, this was removed > because of the need to solve many other problems (e.g. HERFP, early > media etc) which all arose out of the dependence of session state on > the SIP signalling. By creating the offer-answer model (and the > additional SIP specific offer-answer rules within RFC3261) then > independence of session state from SIP signalling state was achieved. > I believe the current version of SIP only says that the 180 MAY be > used to generate local ringback but does not say how this is achieved > since it is implementation dependent. Yes. My UAC MAY choose to stop forwarding any possible early media (again, without changing the state of the session) to the caller, and instead generate local ringback, if 180 without SDP is received. My proposal was that a 180 without SDP should be used to indicate that the UAS is currently not sending any early media (announcement or early media) on the session, and that the UAC therefore MAY choose to generate local ringback. > I believe that the most likely way to do this currently is to initiate > a new offer-answer exchange in an UPDATE/200 OK(UPDATE) with the new > offer (from the UAS) indicating that the media stream direction is > a=recvonly or a=inactive. Its' then up to the UAC/implementation to > decide what to do now that it knows that there is no media coming from > the far end. This could be playing local ringback or playing an > announcement or popping a window up on a screen. I understand the > reasoning behind trying to reduce the number of messages sent to > achieve this aim, however I am also concerned about creating a special > case for local ringing. I don't think that is a good idea. Just because the UAS sends UPDATE, and stop sending media, it doesn't mean the called party has been reached. I think the 180 shall, the way it is defined today, be the ringback "trigger". Regards, Christer Holmberg Ericsson Finland > > > Just my 2 cents. > > Best Regards, > > Cheers > Chris > > Chris Hogg > Nortel Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 00:42:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22721 for ; Thu, 27 Jun 2002 00:42:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA22071 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 00:43:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19493; Wed, 26 Jun 2002 23:54:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19464 for ; Wed, 26 Jun 2002 23:54:50 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21773 for ; Wed, 26 Jun 2002 23:54:01 -0400 (EDT) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g5R3kDH02363; Thu, 27 Jun 2002 09:16:13 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BE5.0015689A ; Thu, 27 Jun 2002 09:23:50 +0530 X-Lotus-FromDomain: HSSBLR To: "Andre Poulin (LMC)" cc: "'sip@ietf.org'" Message-ID: <65256BE5.00156809.00@sampark.hss.hns.com> Date: Thu, 27 Jun 2002 09:23:48 +0530 Subject: Re: [Sip] Authentication-Info header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Andre, Proxy-Authentication-Info header syntax does not allow a proxy to identify itself to the endpoint. It will work fine if there is a single proxy, but in a chain of proxies, if each proxy inserts a Proxy-Authentication-Info header, the endpoint would find it hard to figure out which username/password is to be used with each header. This was an open issue, and more details/resolution can be found at: http://www.sipwg.org/bugzilla/show_bug.cgi?id=164 Regards, Subhash Nayak Hughes Software Systems http://www.hssworld.com "Andre Poulin (LMC)" on 06/26/2002 11:51:12 PM To: "'sip@ietf.org'" cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Sip] Authentication-Info header I have a question regarding Authentication headers. What is the reason to have only one Authentication-Info header instead of having both www-Authentication-Info and proxy- Authentication-Info headers? This does not seem to be consistent with the other related authentication headers which have both cases (www and proxy) Thanks, /Andre _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 04:20:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06039 for ; Thu, 27 Jun 2002 04:20:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11267 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 04:21:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08023; Thu, 27 Jun 2002 03:39:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07958 for ; Thu, 27 Jun 2002 03:39:17 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04814; Thu, 27 Jun 2002 03:38:33 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5R7ceYH023453; Thu, 27 Jun 2002 03:38:40 -0400 (EDT) Message-ID: <3D1AC100.500@dynamicsoft.com> Date: Thu, 27 Jun 2002 03:38:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhigang.c.liu@nokia.com CC: Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org, rohc@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] SigComp and SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit zhigang.c.liu@nokia.com wrote: >>If folks think that it is OK that two proxies that support SigComp > > MUST > >>always exhange compressed messages, I will be glad to simplify the >>draft. I agree with others that this cannot be mandated. I was not proposing that it be mandated. See below. >> If people feel that compressing when it is not really needed is >>unacceptable, we will keep the current Record-Route inspection >>mechanism. > > > I probably missed something here but why do we mix the support of > SigComp with the use of it? Looking at one direction, the sender > needs to know if the receiver supports SigComp. But beyond that, > it is the sender's choice whether to send compressed message. > In other words, once a receiver says "I support SigComp", it's > out of its control and it must prepare for receiving both > compressed and uncompressed message. I agree. This is what I thought the comp=sigcomp parameter meant - "I support sigcomp". The sender then has the option of using it. With this definition, it makes little sense to have a proxy rewrite the record-route to include teh parameter in one direction, and not another. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 04:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06414 for ; Thu, 27 Jun 2002 04:38:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12868 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 04:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09212; Thu, 27 Jun 2002 04:00:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09166 for ; Thu, 27 Jun 2002 04:00:06 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05336 for ; Thu, 27 Jun 2002 03:59:21 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.192]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5R7xUYH023457; Thu, 27 Jun 2002 03:59:31 -0400 (EDT) Message-ID: <3D1AC5E2.4030302@dynamicsoft.com> Date: Thu, 27 Jun 2002 03:59:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sriram Parameswar CC: "'Adam Roach'" , Robert Sparks , sip@ietf.org Subject: Re: [Sip] RE: Event Filtering References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I acutally like the idea of a more generic filter/trigger mechanism that would apply cross-packages. The tradeoff is one of generality vs. complexity. The single mechanism will be more general, but probably more complex than an event-specific one. How much more complex? Impossible to say, of course. I generally favor generality, so if its not to omuch more complex, I think its a good thing. However, unless you plan on enumerating the set of filters and triggers allowed in a package, I suspect that the general one won't be that much more complex. Saying "only send me notifies once an hour on alternate thursdays, if the value of the foo parameter is bar" is going to be complex in any case. I think the Moran draft is a good start, but not quite there yet. Part of the problem is scope. What exactly do we wish to support, in terms of filter/trigger policies? You don't want to boil the ocean with the first version. I think that, if we go for a general solution, we should do JUST enough to meet the *real* problems people are trying to solve, and we can make it extensible to handle more down the road. I would postulate that, realistically, the scope of triggers is going to be limited to: * waiting for a certain event to occur within a certain state, * waiting for a certain variable to take a certain value Things like the mathematical and temporal conditions are interesting, but I doubt would really be used in practice. Similarly, the filtering conditions are probably limited to asking for notifications to contain only certain variables. With a well scoped set of requirements, as I have proposed above, I think you can get a pretty straightforward language that would apply cross-packages. I'll also note that, if we assume that all notifications contain XML as bodies (I know its not true, bear with me), then the filter could possibly be an XSLT document. This might be overkill. For things that are not XML, you'd need to specify an XML mapping for it to work (yuck). Just a thought. So, I would propose that, in order to make progress on this issue, we agree upon a realistic scope for these things, in terms of requirements on filters and triggers, and then we can see how complex the general-purpose filtering language is. -Jonathan R. Sriram Parameswar wrote: > Adam, > > I agree with you on the fact that each event package should define its > own filters. I would tend to say that using different events for > filtering would not work, simply because we can filter on various > different criteria. However there was a draft that attempted a generic > filtering architecture (draft-moran-sipping-filter-arch-00.txt), which > did not get very much traction. > > Maybe the working group could take a look at that draft one more time? > > Thx, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > -----Original Message----- > From: Adam Roach [ mailto:adam@dynamicsoft.com > ] > Sent: Tuesday, June 25, 2002 10:51 AM > To: Robert Sparks; Parameswar, Sriram [NGC:B615:EXCH] > Cc: sip@ietf.org > Subject: Event Filtering > > > >>-----Original Message----- >>From: Robert Sparks [ mailto:rsparks@dynamicsoft.com > > ] > >>We're seeing a similar kind of pressure in other event packages. Often > > >>its called event-filtering. I'm still not sure whether a >>filter approach >>or a separate event is the better approach. In any case, this problem >>is not an event refer specific one, so we shouldn't solve it in this >>draft. > > > We left this up to event packages in sip-events on purpose. (We say > the SUBSCRIBE bodies can define filters and throttles, but don't > define specifics). I don't beleive that it is even possible to define > a useful general-purpose filtering mechanism, precisely because the > variety of things you'll want to filter based on varies widely, and > will need to be tailored to the exact type of state being conveyed. > > If I'm wrong, please make a proposal for such a mechanism. > > /a > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 05:53:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07790 for ; Thu, 27 Jun 2002 05:53:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA16764 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 05:53:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14692; Thu, 27 Jun 2002 05:13:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14660 for ; Thu, 27 Jun 2002 05:13:45 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (h77s128a211n47.user.nortelnetworks.com [47.211.128.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07045 for ; Thu, 27 Jun 2002 05:12:59 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5R9CZJ13566; Thu, 27 Jun 2002 10:12:35 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 10:12:36 +0100 Message-ID: From: "Chris Hogg" To: "'Christer Holmberg'" Cc: Flemming Andreasen , Jonathan Rosenberg , "Mark Watson" , sip@ietf.org, Bob Penfield Subject: RE: [Sip] Local vs Remote ringback on 180 Date: Thu, 27 Jun 2002 10:12:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DBA.C61AF254" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21DBA.C61AF254 Content-Type: text/plain; charset="ISO-8859-1" Hi Christer, Comments in-line. Thanks, Cheers Chris. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: 27 June 2002 00:08 To: Hogg, Chris [MOP:MA01:EXCH] Cc: Flemming Andreasen; Jonathan Rosenberg; Watson, Mark [MDN05:EP10:EXCH]; sip@ietf.org; Bob Penfield Subject: Re: [Sip] Local vs Remote ringback on 180 Hi Chris, Chris Hogg wrote: > > > Hi Christer, > > I'm a bit late into this discussion, but I'll put my thoughts in > anyway. > > >>However, if you mean that it doesn't change what is sent to the > listener either > >>I think what is written in some drafts is wrong. It IS said (at > least that is my > >>understanding) that SDP/no-SDP in 180 DOES indicate if a remote > ringback tone > >>will be generated or not. > > > >>[CH] It is my understanding that previous (pre-"UNIFY" draft) versions > >>of the bis did indicate that you could use the presence or absence of > >>SDP to indicate whether or not the UAC should generate local ringback > >>or play media. If my understanding is correct, this was removed > >>because of the need to solve many other problems (e.g. HERFP, early > >>media etc) which all arose out of the dependence of session state on > >>the SIP signalling. By creating the offer-answer model (and the > >>additional SIP specific offer-answer rules within RFC3261) then > >>independence of session state from SIP signalling state was achieved. > >>I believe the current version of SIP only says that the 180 MAY be > >>used to generate local ringback but does not say how this is achieved > >>since it is implementation dependent. >Yes. My UAC MAY choose to stop forwarding any possible early media >(again, without changing the state of the session) to the caller, and >instead generate local ringback, if 180 without SDP is received. My >proposal was that a 180 without SDP should be used to indicate that the >UAS is currently not sending any early media (announcement or early >media) on the session, and that the UAC therefore MAY choose to generate >local ringback. [CH] I think the problem you have here is that you are creating a difference between session state and the caller's perceived view of the session state and this is confusing the discussion. I don't think its' quite right to say that a 180 without SDP is not sending any early media, however I think that the 180 could still give the UAC the option of playing early media as currently defined. Let me have a go at trying to understand your solution. As I understand it, when a Manyfolks/preconditions call setup is underway, if you send a 180 Ringing after the preconditions have been met then (according to the rules of offer-answer and SIP specific rules surrounding offer-answer) then the 180 Ringing will normally not contain any SDP. In this case, your proposal would mean that in the Manyfolks call setup scenario the 180 Ringing would always result in local ringing. Your implementation would then treat receipt of the 200 OK(INVITE) as the trigger to switch off local ringing and back to media (the session for which is already setup). In a non-manyfolks call / non 100 REL / basic call setup flow the 180 Ringing may or may not contain SDP. If it contains SDP (which is a pre-answer) then your implementation would play out early media, if it does not contain SDP then local ringing may be played instead. Is this a fair analysis of your solution? If this is the case, then I don't think there are any changes needed to SIP to be able to support this. >> I believe that the most likely way to do this currently is to initiate >> a new offer-answer exchange in an UPDATE/200 OK(UPDATE) with the new >> offer (from the UAS) indicating that the media stream direction is >> a=recvonly or a=inactive. Its' then up to the UAC/implementation to >> decide what to do now that it knows that there is no media coming from >> the far end. This could be playing local ringback or playing an >> announcement or popping a window up on a screen. I understand the >> reasoning behind trying to reduce the number of messages sent to >> achieve this aim, however I am also concerned about creating a special >> case for local ringing. >I don't think that is a good idea. Just because the UAS sends UPDATE, >and stop sending media, it doesn't mean the called party has been >reached. I think the 180 shall, the way it is defined today, be the >ringback "trigger". [CH] The call flow I had in mind was something like: <-----180 Ringing <----UPDATE(SDP offer) -----200 OK(UPDATE) (SDP answer) Where the UPDATE and 200 OK(UPDATE) are being used to alter the session state (effectively signalling that the direction of the media (from the UAS point of view) is now a=inactive or a=recvonly. The 180 Ringing is still sent but the additional messages allow the UAS to signal to the UAC that the far-end media is on hold. The implementation can then do what it likes (e.g. play local ringing / play a local announcement etc). Cheers Chris. Nortel Networks Regards, Christer Holmberg Ericsson Finland > > > Just my 2 cents. > > Best Regards, > > Cheers > Chris > > Chris Hogg > Nortel Networks ------_=_NextPart_001_01C21DBA.C61AF254 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Local vs Remote ringback on 180

Hi Christer,

Comments in-line.

Thanks,

Cheers
Chris.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: 27 June 2002 00:08
To: Hogg, Chris [MOP:MA01:EXCH]
Cc: Flemming Andreasen; Jonathan Rosenberg; Watson, = Mark
[MDN05:EP10:EXCH]; sip@ietf.org; Bob Penfield
Subject: Re: [Sip] Local vs Remote ringback on = 180



Hi Chris,

Chris Hogg wrote:

>
>
> Hi Christer,
>
> I'm a bit late into this discussion, but I'll = put my thoughts in
> anyway.
>
> >>However, if you mean that it doesn't = change what is sent to the
> listener either
> >>I think what is written in some drafts = is wrong. It IS said (at
> least that is my
> >>understanding) that SDP/no-SDP in 180 = DOES indicate if a remote
> ringback tone
> >>will be generated or not.
>
>
> >>[CH] It is my understanding that = previous (pre-"UNIFY" draft) versions
> >>of the bis did indicate that you could = use the presence or absence of
> >>SDP to indicate whether or not the UAC = should generate local ringback
> >>or play media.  If my = understanding is correct, this was removed
> >>because of the need to solve many other = problems (e.g. HERFP, early
> >>media etc) which all arose out of the = dependence of session state on
> >>the SIP signalling.  By creating = the offer-answer model (and the
> >>additional SIP specific offer-answer = rules within RFC3261) then
> >>independence of session state from SIP = signalling state was achieved.
> >>I believe the current version of SIP = only says that the 180 MAY be
> >>used to generate local ringback but = does not say how this is achieved
> >>since it is implementation = dependent.

>Yes. My UAC MAY choose to stop forwarding any = possible early media
>(again, without changing the state of the = session) to the caller, and
>instead generate local ringback, if 180 without = SDP is received. My
>proposal was that a 180 without SDP should be = used to indicate that the
>UAS is currently not sending any early media = (announcement or early
>media) on the session, and that the UAC = therefore MAY choose to generate
>local ringback.

[CH] I think the problem you have here is that you = are creating a difference between session state and the caller's = perceived view of the session state and this is confusing the = discussion.  I don't think its' quite right to say that a 180 = without SDP is not sending any early media, however I think that the = 180 could still give the UAC the option of playing early media as = currently defined.  

Let me have a go at trying to understand your = solution.  As I understand it, when a Manyfolks/preconditions call = setup is underway, if you send a 180 Ringing after the preconditions = have been met then (according to the rules of offer-answer and SIP = specific rules surrounding offer-answer) then the 180 Ringing will = normally not contain any SDP.  In this case, your proposal would = mean that in the Manyfolks call setup scenario the 180 Ringing would = always result in local ringing.  Your implementation would then = treat receipt of the 200 OK(INVITE) as the trigger to switch off local = ringing and back to media (the session for which is already setup). =

In a non-manyfolks call / non 100 REL / basic call = setup flow the 180 Ringing may or may not contain SDP.  If it = contains SDP (which is a pre-answer) then your implementation would = play out early media, if it does not contain SDP then local ringing may = be played instead.

Is this a fair analysis of your solution?  If = this is the case, then I don't think there are any changes needed to = SIP to be able to support this.


>> I believe that the most likely way to do = this currently is to initiate
>> a new offer-answer exchange in an = UPDATE/200 OK(UPDATE) with the new
>> offer (from the UAS) indicating that the = media stream direction is
>> a=3Drecvonly or a=3Dinactive.  Its' = then up to the UAC/implementation to
>> decide what to do now that it knows that = there is no media coming from
>> the far end.  This could be playing = local ringback or playing an
>> announcement or popping a window up on a = screen. I understand the
>> reasoning behind trying to reduce the = number of messages sent to
>> achieve this aim, however I am also = concerned about creating a special
>> case for local ringing.

>I don't think that is a good idea. Just because = the UAS sends UPDATE,
>and stop sending media, it doesn't mean the = called party has been
>reached. I think the 180 shall, the way it is = defined today, be the
>ringback "trigger".

[CH] The call flow I had in mind was something = like:

 <-----180 Ringing
 <----UPDATE(SDP offer)
 -----200 OK(UPDATE) (SDP answer)

Where the UPDATE and 200 OK(UPDATE) are being used to = alter the session state (effectively signalling that the direction of = the media (from the UAS point of view) is now a=3Dinactive or = a=3Drecvonly.  The 180 Ringing is still sent but the additional = messages allow the UAS to signal to the UAC that the far-end media is = on hold.  The implementation can then do what it likes (e.g. play = local ringing / play a local announcement etc).


Cheers

Chris.
Nortel Networks


Regards,

Christer Holmberg
Ericsson Finland



>
>
> Just my 2 cents.
>
> Best Regards,
>
> Cheers
> Chris
>
> Chris Hogg
> Nortel Networks

------_=_NextPart_001_01C21DBA.C61AF254-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 06:18:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08372 for ; Thu, 27 Jun 2002 06:18:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA18630 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 06:19:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16167; Thu, 27 Jun 2002 05:40:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16139 for ; Thu, 27 Jun 2002 05:40:30 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07544 for ; Thu, 27 Jun 2002 05:39:44 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2002 09:40:53 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 27 Jun 2002 10:41:24 +0100 Message-ID: <45730E094814E44488F789C1CDED27AEC55301@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: draft-schulzrinne-sip-bind Thread-Index: AcIdvs0PCk6BEpw4SxORa5kzoDTnIg== From: "James Undery" To: "Henning Schulzrinne (E-mail)" Cc: "SIP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA16140 Subject: [Sip] draft-schulzrinne-sip-bind Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I generally like this draft, although would like to suggest a change. Having "expires=1" a special value isn't very clean, a "usagecount" parameter that shows how many times a URL will be valid for seems much more flexible. The combination of usagecount and expires would also allow for a one-shot URL that's valid for 60 seconds say, i.e. Binding: ;disposition=token ;expires=60 ;usagecount=1 James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 07:11:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11076 for ; Thu, 27 Jun 2002 07:11:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23674 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 07:12:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19777; Thu, 27 Jun 2002 06:38:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19749 for ; Thu, 27 Jun 2002 06:38:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08814; Thu, 27 Jun 2002 06:38:01 -0400 (EDT) Message-Id: <200206271038.GAA08814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Jun 2002 06:38:01 -0400 Subject: [Sip] I-D ACTION:draft-olson-sip-content-indirect-mech-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Mechanism for Content Indirection in SIP Messages Author(s) : S. Olson Filename : draft-olson-sip-content-indirect-mech-00.txt Pages : 12 Date : 26-Jun-02 This Internet-Draft proposes an extension to the URL MIME External- Body Access-Type as defined in RFC2017 [7] to satisfy the content indirection requirements defined in draft-ietf-sipping-content- indirect-00 [1]. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URL [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-olson-sip-content-indirect-mech-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-olson-sip-content-indirect-mech-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-olson-sip-content-indirect-mech-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020626134514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-olson-sip-content-indirect-mech-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-olson-sip-content-indirect-mech-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626134514.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 09:27:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17023 for ; Thu, 27 Jun 2002 09:27:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04688 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 09:27:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02406; Thu, 27 Jun 2002 08:59:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02377 for ; Thu, 27 Jun 2002 08:59:47 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15702 for ; Thu, 27 Jun 2002 08:59:03 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5RCwMd24975 for ; Thu, 27 Jun 2002 15:58:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 15:59:46 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 15:59:38 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 15:59:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Thu, 27 Jun 2002 15:59:37 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20387@esebe019.NOE.Nokia.com> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWCX1CSlWGUDPFTFid1ds9KZO6+wH0Ip9gAAASoXA= To: , , X-OriginalArrivalTime: 27 Jun 2002 12:59:37.0774 (UTC) FILETIME=[7E3C1CE0:01C21DDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA02378 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sory, I meant to say Why can't we use the event-header in REFER/200 instead of Supported and Require headers? If event-header is not returned in the response, no implicit subscription is created. Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, June 27, 2002 3:58 PM > To: rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > Why can't we use the event-header in SUBSCRIBE/200 instead of > Supported and Require headers? If event-header is not > returned, no implicit subscription is created. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Monday, June 17, 2002 5:14 PM > > To: sip@ietf.org > > Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > > Referstatus/adjustment] > > > > > > The message I sent last week (copied below) > > has generated no list comments. I hope it > > was because I was too subtle with the subject > > line. > > > > I have asked the IESG to delay their consideration > > of the REFER draft until these concerns have been > > discussed on this list. > > > > Please read the draft below and comment. If you > > agree with what's in the draft, please post a > > note saying so. > > > > RjS > > > > -----Forwarded Message----- > > > > > From: Robert Sparks > > > To: sip@ietf.org > > > Subject: [Sip] Refer status/adjustment > > > Date: 12 Jun 2002 13:49:35 -0500 > > > > > > A set of converging concerns were raised about the > > > REFER draft late in the review process, all centering > > > on draft's use of sip-events (soon to be RFC3265) and > > > the implicit subscription. > > > > > > When investigating those concerns, several things became > > > clear. > > > > > > The draft did not provide sufficient discussion > > > around managing the lifecycle of the implicit subscription > > > (Can you refresh the implicit subscription? unsubscribe? > > > How is the Subscription-State header supposed to be used? > > > How do the two parties know when the subscription is over?) > > > and the draft did not clearly specify some of the things > > > RFC3265 requires of an event package. These need to be > > > corrected. > > > > > > A larger issue centers around the following language from > > > sip-events: > > > > > > Note that any behavior designated with "SHOULD" or > "MUST" in this > > > document is not allowed to be weakened by extension documents; > > > however, such documents may elect to strengthen "SHOULD" > > > requirements to "MUST" strength if required by their > application. > > > > > > The current draft is not clear enough on one particular > point - the > > > examples do not show immediate NOTIFYs for the implicit > > subscription. > > > I expect that many members of the community believe they are not > > > required (I had drifted into thinking that way before the comments > > > caused me to look at this more closely). The normative text in the > > > current REFER draft calls to RFC3265, and immediate > NOTIFYs are very > > > clearly required there. This needs to be pointed out more clearly > > > in the REFER draft. > > > > > > Finally, the current draft makes instantiating a subscription a > > > SHOULD strength requirement, but provides no mechanism for the > > > agent sending the REFER to know whether or not to expect a NOTIFY. > > > We have repeatedly had discussions on the list about how long > > > the agent sending the REFER should keep state waiting for > a NOTIFY - > > > and with discomfort deciding that is an implementation decision. > > > Recent discussions have pointed out that there is > disagreement about > > > what never receiving a NOTIFY means - should the REFERing > > party treat > > > that as an error and re-attempt the reference or should it just > > > assume no subscription was created? > > > > > > I've put together an individual submission that adds all the > > > above clarifications. It also proposes a new mechanism to > > > address the problems in the previous paragraph. Basically, it > > > provides a way for the party sending the REFER to indicate > > > that it really wants to be notified, and a way for the agent > > > accepting the refer to signal that it will or will not send > > > notifies in the response to the REFER. > > > > > > I just submitted this draft - until it appears in the repository, > > > you can get it from > > > > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265di sc-00.txt > > I propose that this draft replace refer-05 before it advances further > in the standardization process. > > RjS > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 09:33:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17706 for ; Thu, 27 Jun 2002 09:33:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06049 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 09:34:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02256; Thu, 27 Jun 2002 08:57:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02224 for ; Thu, 27 Jun 2002 08:57:45 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15627 for ; Thu, 27 Jun 2002 08:57:01 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5RCuKd24221 for ; Thu, 27 Jun 2002 15:56:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 15:57:43 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 15:57:41 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 15:57:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Date: Thu, 27 Jun 2002 15:57:37 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20386@esebe019.NOE.Nokia.com> Thread-Topic: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Referstatus/adjustment] Thread-Index: AcIWCX1CSlWGUDPFTFid1ds9KZO6+wH0Ip9g To: , X-OriginalArrivalTime: 27 Jun 2002 12:57:38.0636 (UTC) FILETIME=[373918C0:01C21DDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA02225 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Why can't we use the event-header in SUBSCRIBE/200 instead of Supported and Require headers? If event-header is not returned, no implicit subscription is created. Regards, Hisham > -----Original Message----- > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, June 17, 2002 5:14 PM > To: sip@ietf.org > Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > The message I sent last week (copied below) > has generated no list comments. I hope it > was because I was too subtle with the subject > line. > > I have asked the IESG to delay their consideration > of the REFER draft until these concerns have been > discussed on this list. > > Please read the draft below and comment. If you > agree with what's in the draft, please post a > note saying so. > > RjS > > -----Forwarded Message----- > > > From: Robert Sparks > > To: sip@ietf.org > > Subject: [Sip] Refer status/adjustment > > Date: 12 Jun 2002 13:49:35 -0500 > > > > A set of converging concerns were raised about the > > REFER draft late in the review process, all centering > > on draft's use of sip-events (soon to be RFC3265) and > > the implicit subscription. > > > > When investigating those concerns, several things became > > clear. > > > > The draft did not provide sufficient discussion > > around managing the lifecycle of the implicit subscription > > (Can you refresh the implicit subscription? unsubscribe? > > How is the Subscription-State header supposed to be used? > > How do the two parties know when the subscription is over?) > > and the draft did not clearly specify some of the things > > RFC3265 requires of an event package. These need to be > > corrected. > > > > A larger issue centers around the following language from > > sip-events: > > > > Note that any behavior designated with "SHOULD" or "MUST" in this > > document is not allowed to be weakened by extension documents; > > however, such documents may elect to strengthen "SHOULD" > > requirements to "MUST" strength if required by their application. > > > > The current draft is not clear enough on one particular point - the > > examples do not show immediate NOTIFYs for the implicit > subscription. > > I expect that many members of the community believe they are not > > required (I had drifted into thinking that way before the comments > > caused me to look at this more closely). The normative text in the > > current REFER draft calls to RFC3265, and immediate NOTIFYs are very > > clearly required there. This needs to be pointed out more clearly > > in the REFER draft. > > > > Finally, the current draft makes instantiating a subscription a > > SHOULD strength requirement, but provides no mechanism for the > > agent sending the REFER to know whether or not to expect a NOTIFY. > > We have repeatedly had discussions on the list about how long > > the agent sending the REFER should keep state waiting for a NOTIFY - > > and with discomfort deciding that is an implementation decision. > > Recent discussions have pointed out that there is disagreement about > > what never receiving a NOTIFY means - should the REFERing > party treat > > that as an error and re-attempt the reference or should it just > > assume no subscription was created? > > > > I've put together an individual submission that adds all the > > above clarifications. It also proposes a new mechanism to > > address the problems in the previous paragraph. Basically, it > > provides a way for the party sending the REFER to indicate > > that it really wants to be notified, and a way for the agent > > accepting the refer to signal that it will or will not send > > notifies in the response to the REFER. > > > > I just submitted this draft - until it appears in the repository, > > you can get it from > > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt > > I propose that this draft replace refer-05 before it advances further > in the standardization process. > > RjS > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 10:04:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19148 for ; Thu, 27 Jun 2002 10:04:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08488 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 10:04:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06261; Thu, 27 Jun 2002 09:36:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06224 for ; Thu, 27 Jun 2002 09:36:11 -0400 (EDT) Received: from bitstreamconsulting.com ([216.250.65.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17781 for ; Thu, 27 Jun 2002 09:35:25 -0400 (EDT) Received: from bituy ([64.47.18.54]) by bitstreamconsulting.com ( IA Mail Server Version: 3.2.2. Build: 1087 ) ) ; Thu, 27 Jun 2002 08:30:51 -0500 Message-ID: <004a01c21df0$248a86d0$9b321e0a@bituy> From: "uy do" To: References: <493BB8BDBB5AD511A7BB00104B62EE280105FE45@jupiter> Date: Thu, 27 Jun 2002 08:34:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] 100 Trying question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, As soon as the UAS receives an INVITE, it sends back to the client a TRYING. My question is the UAS only send one TRYING, or it keeps sending TRYING at a regular time? If the latter is correct, how long does it take the UAS to resend the TRYING? Thanks, Uy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 11:02:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22259 for ; Thu, 27 Jun 2002 11:02:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13848 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 11:03:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11042; Thu, 27 Jun 2002 10:37:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10910 for ; Thu, 27 Jun 2002 10:36:50 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20740 for ; Thu, 27 Jun 2002 10:36:05 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5REeZV15414; Thu, 27 Jun 2002 09:40:37 -0500 Subject: Re: [Sip] Refer status/adjustment From: Robert Sparks To: "Daniel G. Petrie" Cc: sip@ietf.org In-Reply-To: <3D1A3E49.4A795013@pingtel.com> References: <3D17F899.A5D25374@pingtel.com> <1025018225.1689.222.camel@localhost.localdomain> <3D1A3E49.4A795013@pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Jun 2002 09:35:06 -0500 Message-Id: <1025188509.2344.23.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2002-06-26 at 17:20, Daniel G. Petrie wrote: > Coments below: > > Robert Sparks wrote: > > > On Mon, 2002-06-24 at 23:59, Daniel G. Petrie wrote: > > > The following comments pertain to > > > draft-sparks-sip-refer-3265disc-00.txt > > > > > ... > > > > > > > > > Ignoring the installed base I have no technical issues with the use of > > > the referevent token to indicate the desire for notification of outcome. > > > > > > However, in the real world this presents an upward compatability > > > issue. If the transferor is a prior refer-3261 implementation, it > > > will not send the referevent token in the Supported header. If > > > the transferee is a post refer-3261 implementation it will not > > > send a notify and the transferor will wait a long time for the > > > NOTIFY request and at best give a false indication of transfer > > > failure. It is a little ugly, but reversing the sense is upward > > > compatable (e.g. noreferevent token). > > > > That just moves the compatibility shoe to another foot. > > Taking this route you step back into the mess of something that > > wants notification having no way to know whether its going to > > get it or not until after the first notify arrives. > > Sorry I may have missed something in your point. Let me clarify > what I was suggesting to make sure that is not the problem. In prior > REFER drafts it was assumed that the NOTIFY was manditory. No, it wasn't. That's probably where our disconnect was. This was made optional when we first decided to go with implicit subscriptions. > Even so, a robust implementation which is tolerent of error > conditions MUST tolerate the case where the NOTIFY never > gets delivered (e.g. due to network failures). Otherwise your > user agent hangs forever waiting for a NOTIFY that dropped > on the floor. With or without the Supported token in either > sense this is necessary. > > My suggestion was to make the implied subscription the > default (I think that you will find that most existing > implementations do this.). Then use the Supported token > (e.g. noreferevent) as a way to say that a subscription is > not desired. This way the risk of interoperability is that > a UA gets an implied subscription that it does not want. > This is easily solved with a 481 response or worst > case just ignored. And you have a similar compatibility issue as motivates your concern. There may be existing systems out there that don't create subscriptions. They won't look for a noreferevent token. As a client, you would really have no way to know whether or not you are going to get a NOTIFY until one shows up. > > On the server side of the REFER, a server which does > not implement the subscription SHOULD either send > an error if the noreferevent tag is not present or it > SHOULD send a single immediate NOTIFY indicating > the subscription is terminated. This is fairly light weight > as the full subscription framework is not needed only > a trivial NOTIFY. It also does not require any > subscription state (which I am guessing is the major > objection to events being too heavy weight to > implement in this case). The NOTIFY should > probably have either a 180 or failure code. > > So the assumtion is that a UA sending a REFER will > receive a NOTIFY unless the noreferevent token is > present. This is the source of my confusion with your > statement above. > > > > > > > > > > > It seems that last paragraph in section 2.4.2 gives the REFER > > > recipient the choice of whether it wants to send a NOTIFY > > > event or not. I am not sure if I object to this or not, but > > > is there a reason or example of why this is useful? It does > > > make things a little more complicated in that there are > > > more possible outcomes (there is no shortage of error > > > cases even without this possibility). > > > > Well, if it didn't have that choice, we wouldn't have the > > problems motivating this referevent token at all. > > > > The choice exists exactly to allow elements to accept REFER but > > not create a subscription. Those arguing for it claim that events > > is to heavy to require its implementation (think _way_ back to the > > rather intense discussions we had on this at the Feb 2001 interim). > > > > I have been poking through the list trying to find a more recent > discussion of this requirement without much luck. Could you point > me at the dates of some message. I guess that in pursuing the NOTIFY > solution we had concluded that it was ok to require events. I am still > wondering > if this is a requirement we really need to satisfy. I worry about > interoperability > (of implementation of this draft, not different versions of the refer draft) > with this requirement. If events support is not required or at least a > SHOULD you end up bringing the whole experience down to a > lowest common denominator. It ends up making both solutions It is and has been SHOULD, but even so, it forces you to code those peers that believe they have good reason not to play. > (with and without events) more complicated in terms of error > cases that can occur. > > I appologize if this was already discussed recently on the list. I guess I > find the claim that events is too heavy weight to be a weak > rational. I disagree with the requirement to make events optional. Well, as I said before, that is a _very_ old decision, made when we first brought in subscriptions to get around the finite-length non-INVITE transaction. I don't believe it has been revisited on the list since. As I said above, if we had been able to make participation in this subscription a MUST, none of the problems motivating the referevent token would exist. The draft would be much simpler. I believe implementations would be simpler, even if it did mean bringing in event handling code (the simple "I refuse to accept any subscriptions" implementation you describe above points out that this is not that heavy a burden. I am very hesitant to reopen yet another decision. But it would be useful to know if the original proponents (or anybody else) of making sending any NOTIFYs at all optional still care. Even better, has anyone implemented this? If nobody speaks up to either of those points, we could change that SHOULD to MUST and toss the referevent idea. RjS > > > > > > > > > 2.4.3 I think there is a possible race condition here. Though > > > the possiblity is remote the user agent sending the REFER > > > request should be prepared to receive the NOTIFY prior > > > to the 2xx response to the REFER. Oh I see that is pointed > > > out in 2.4.5 > > > > > > 2.5.6 Is it not valid to send any provisional response in the > > > sipfrag body (e.g. 180) when the subscription state is pending? > > > > If the subscription state is pending, the notifications carry a > > "nuetral" state. 100 fits that bill nicely. How were you seeing using > > 18x's? To carry information about the progress of obtaining > > authorization for the subscription? That information should go > > into the subscription-state header or somewhere else, but not in > > this body. This body carries the state of the referred event. > > > > Ignore the 18x issue. My mistake. Sorry. > > > > > > > > > Cheers, > > > Dan > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 11:10:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22706 for ; Thu, 27 Jun 2002 11:10:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14670 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 11:11:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10059; Thu, 27 Jun 2002 10:30:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10019 for ; Thu, 27 Jun 2002 10:30:22 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20377 for ; Thu, 27 Jun 2002 10:29:38 -0400 (EDT) Received: from millcity.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5REUMOK001985 for ; Thu, 27 Jun 2002 10:30:23 -0400 (EDT) Received: from KENJW2K1 (che-vpn1-64.cisco.com [10.86.240.64]) by millcity.cisco.com (Mirapoint) with SMTP id AAK95984; Thu, 27 Jun 2002 10:24:16 -0400 (EDT) Reply-To: From: "Ken Jordan" To: "Sipietf \(E-mail\)" Date: Thu, 27 Jun 2002 10:31:52 -0400 Message-ID: <005b01c21de7$61d62430$3c02a8c0@cisco.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.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Authorization policy change after SUBSCRIBE dialog established Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If authorization policy changes during an existing subscription dialog, how does the notifier cause the subscriber to authenticate (or reauthenticate)? Is the expires values explicitly set to zero in an immediate notify? Is the dialog terminated as a 401? -Ken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 11:19:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23430 for ; Thu, 27 Jun 2002 11:19:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16060 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 11:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12269; Thu, 27 Jun 2002 10:48:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12237 for ; Thu, 27 Jun 2002 10:48:01 -0400 (EDT) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21343 for ; Thu, 27 Jun 2002 10:47:16 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g5REptV15443; Thu, 27 Jun 2002 09:51:55 -0500 From: Robert Sparks To: "Daniel G. Petrie" Cc: sip@ietf.org In-Reply-To: <3D1A3E49.4A795013@pingtel.com> References: <3D17F899.A5D25374@pingtel.com> <1025018225.1689.222.camel@localhost.localdomain> <3D1A3E49.4A795013@pingtel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Jun 2002 09:46:23 -0500 Message-Id: <1025189183.2344.35.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] REFER: Who has implemented REFER without creating subscriptions? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This was part of the last message I sent, but it was buried pretty deep. When we made the decision to go with implicit subscriptions work around the finite length non-INVITE transaction, we made serving that subscription SHOULD strength to allow for implementations that couldn't deal with the weight of serving subscriptions. Do the original proponents of allowing implementations to never send a notify still see this need? Are there any implementations out there that accept a REFER but don't send NOTIFYs? The subscription concept has substantially matured (in particular, Subscription-State is explicitly communicated). As Dan points out in his last note, an implementation that needed to be very lightweight could send exactly one NOTIFY terminating the subscription. If serving the subscription (even if it involved sending just that one NOTIFY) were strictly mandatory, the error space is much smaller. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 13:29:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02924 for ; Thu, 27 Jun 2002 13:29:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27233 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 13:29:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25225; Thu, 27 Jun 2002 12:49:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25196 for ; Thu, 27 Jun 2002 12:49:07 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00656 for ; Thu, 27 Jun 2002 12:48:23 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5RGn3E04853; Thu, 27 Jun 2002 12:49:03 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA23680; Thu, 27 Jun 2002 11:49:02 -0500 (CDT) Message-ID: <3D1B41FC.90505@lucent.com> Date: Thu, 27 Jun 2002 11:49:00 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" , "'gonzalo.camarillo@ericsson.com'" Subject: Re: [Sip] SIP and SigComp draft comment. References: <9BF66EBF6BEFD942915B4D4D45C051F377A26A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Inline. Adam Roach wrote: > There's a closely related issue that hasn't yet been touched > on, though: when the called party issues a request, the > "comp=sigcomp" headers end up being essentially in the wrong > place. > > I'll demonstrate by way of an example. > > +---+ +----+ +----+ +----+ +---+ > | A |...| P1 |---| P2 |---| P3 |...| B | > +---+ +----+ +----+ +----+ +---+ > > A and B are wireless terminals with very low bandwidth > links (and, consequently, use SigComp). P1, P2, and P3 are > all proxies on the network. > > A sends an INVITE to B. Assuming that each proxy > inserts its record-routes so that A gets the proper > route-set, you get the following at B: > > Record-Route: > Record-Route: > Record-Route: > Contact: > > This is, of course, stored in B as the route set: > ,,, > > > The response to the request delivers the same set of Record-Routes > to A, but with a contact of "sip:userb@B;comp=sigcomp": > ,,, > > > So, A's route is absolutely correct; it will compress the message > sent to P1, and P3 will compress the message sent to B. Unfortunately, > B's route is really screwy. If it obeys the "comp" parameters, B > *won't* compress any requests in this dialog, so you'll be sending > uncompressed messages over the radio link. And, in a bitter irony, > P2 will waste cycles compressing the messages sent to P1 -- which > turns out to be completely unnecessary. In fact, it exacerbates the > fact that the B -> P3 request was sent uncompressed. > > If we have the proxies tailor the route set for B, the same problem > happens, in the opposite direction. > > The solution lies in step 8, detailed in section 16.7 of > 2543bis-09. > > In this case, the proxies would tailor the inserted "Record-Routes" > in the request for B's consumption: > > Record-Route: > Record-Route: > Record-Route: > Contact: Adam: Correct me if I am mistaken, but won't it be best (since in your scenario, P3 supports sigcomp) for P3 to simply indicate it's sigcomp support in the R-R going downstream, leaving P1's R-R alone. Thus, the R-R list from P3 will contain: Record-Route: Record-Route: Record-Route: Contact: The Route list is now congruent on both ends; B knows that it can compress the request across the first hop (P3) as does A (first hop for it is P1). This way, no re-writing of R-R's is necessary in the response. If P3 is a stateless proxy for instance, it may not be able to correlate the response to the request for R-R re-writing. > Then, as the INVITE response passes back through P3 and P1, they > would each modify the Record-Route headers so that they are > appropriate for A's consumption: > > Record-Route: > Record-Route: > Record-Route: > Contact: > > Even though it's described in SIP, this usage should probably be > explicitly mentioned in in the SIP SigComp draft; otherwise, we > run the risk of having nodes do strange things. I believe step 8 of Section 16.7 of -09bis assumes that a proxy is modifying *it's* own R-R in a response that it inserted in the earlier request, not someone else's (although, no harm is done if the 'foreign' R-R is duplicated faithfully in the response). Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 13:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04351 for ; Thu, 27 Jun 2002 13:50:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29570 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 13:51:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27886; Thu, 27 Jun 2002 13:32:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27833 for ; Thu, 27 Jun 2002 13:32:40 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03065 for ; Thu, 27 Jun 2002 13:31:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RHW1N7027566; Thu, 27 Jun 2002 13:32:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:32:08 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A282@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'kenj@cisco.com'" , "'sip@ietf.org'" Subject: RE: [Sip] Authorization policy change after SUBSCRIBE dialog esta blished Date: Thu, 27 Jun 2002 13:09:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If *authorization* policy changes, I would take that to mean that the user is no longer authorized to subscribe to the state. Re-authentication will have no useful effect. You will send a NOTIFY with a header of Subscription-State: terminated;reason=rejected The subscriber will not re-authenticate, because the problem is not *authentication* -- it is *authorization*. If you simply want to re-authenticate for whatever reason, a NOTIFY with a header of Subscription-State: terminated;reason=deactivated will prompt the user to re-subscribe. This subscribe can then be challenged. /a > -----Original Message----- > From: Ken Jordan [mailto:kenj@cisco.com] > Sent: Thursday, June 27, 2002 9:32 > To: Sipietf (E-mail) > Subject: [Sip] Authorization policy change after SUBSCRIBE dialog > established > > > > > If authorization policy changes during an existing > subscription dialog, how > does the notifier cause the subscriber to authenticate (or > reauthenticate)? > Is the expires values explicitly set to zero in an immediate > notify? Is the > dialog terminated as a 401? > > -Ken > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 13:57:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04738 for ; Thu, 27 Jun 2002 13:57:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00056 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 13:57:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28321; Thu, 27 Jun 2002 13:38:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28978 for ; Wed, 26 Jun 2002 16:39:22 -0400 (EDT) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09985 for ; Wed, 26 Jun 2002 16:38:36 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 16:38:59 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D690140C08A@mail.ss8.ca> From: Li Li To: "'sip@ietf.org'" Date: Wed, 26 Jun 2002 16:38:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] UA running on TCP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the new bis, it is mandatory that UA should support TCP transport. Assume a UA with a TCP connection 1 sending to the proxy, and a TCP connection 2 for receiving from the proxy. Now assume that the TCP connection 1 and 2 go down/timed out. This may due to a temporary failure. The proxy recovers asap and sets up a new TCP connection for sending to the UA. What should the UA do? Should the UA try to set up a connection to the proxy so that requests can be sent/resent? Or the UA would just release all the calls it has with the proxy and try for another proxy if available? Li > -----Original Message----- > From: Andre Poulin (LMC) [mailto:Andre.Poulin@ericsson.ca] > Sent: Wednesday, June 26, 2002 2:21 PM > To: 'sip@ietf.org' > Subject: [Sip] Authentication-Info header > > > > > I have a question regarding Authentication headers. > > What is the reason to have only one Authentication-Info > header instead of > having both www-Authentication-Info and proxy- > Authentication-Info headers? This does not seem to be > consistent with the > other related authentication headers which have both > cases (www and proxy) > > Thanks, > /Andre > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 13:58:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04818 for ; Thu, 27 Jun 2002 13:58:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00294 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 13:58:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28266; Thu, 27 Jun 2002 13:38:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29861 for ; Wed, 26 Jun 2002 09:34:30 -0400 (EDT) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18195 for ; Wed, 26 Jun 2002 09:33:46 -0400 (EDT) Received: from boolard ([10.37.1.56]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g5QDYRV22418 for ; Wed, 26 Jun 2002 14:34:27 +0100 From: "Shane McCormack" To: Date: Wed, 26 Jun 2002 14:37:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] QoS for complete session Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi there, I have been trawlling through various archives for a while but nothing specifically answers my question which is: Q.Say I use Sip to set up a VoIP call between to PC user agents. How I provide a level of QoS from Call setup, duration of call to call teardown. Anybody. Sorry if this is a bit obvious to some people but I am just wondering. Regards Shane _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 13:58:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04869 for ; Thu, 27 Jun 2002 13:58:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00319 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 13:59:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27927; Thu, 27 Jun 2002 13:32:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27890 for ; Thu, 27 Jun 2002 13:32:45 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03073 for ; Thu, 27 Jun 2002 13:32:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RHW1N7027569; Thu, 27 Jun 2002 13:32:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:32:08 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A281@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Robert Sparks , sip@ietf.org Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref erstatus/adjustment] Date: Thu, 27 Jun 2002 13:01:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Because that's not really what Event means. Event means "you *can* subscribe to this event", not "you have been forcibly subscribed to this event, possibly against your will". /a > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, June 27, 2002 8:00 > To: hisham.khartabil@nokia.com; rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > Referstatus/adjustment] > > > Sory, I meant to say > > Why can't we use the event-header in REFER/200 instead of > Supported and Require headers? If event-header is not > returned in the response, no implicit subscription is created. > > Hisham > > > -----Original Message----- > > From: ext hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > Sent: Thursday, June 27, 2002 3:58 PM > > To: rsparks@dynamicsoft.com; sip@ietf.org > > Subject: RE: IMPORTANT: Comments on REFER changes needed : > [Fwd: [Sip] > > Referstatus/adjustment] > > > > > > Why can't we use the event-header in SUBSCRIBE/200 instead of > > Supported and Require headers? If event-header is not > > returned, no implicit subscription is created. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > Sent: Monday, June 17, 2002 5:14 PM > > > To: sip@ietf.org > > > Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] > > > Referstatus/adjustment] > > > > > > > > > The message I sent last week (copied below) > > > has generated no list comments. I hope it > > > was because I was too subtle with the subject > > > line. > > > > > > I have asked the IESG to delay their consideration > > > of the REFER draft until these concerns have been > > > discussed on this list. > > > > > > Please read the draft below and comment. If you > > > agree with what's in the draft, please post a > > > note saying so. > > > > > > RjS > > > > > > -----Forwarded Message----- > > > > > > > From: Robert Sparks > > > > To: sip@ietf.org > > > > Subject: [Sip] Refer status/adjustment > > > > Date: 12 Jun 2002 13:49:35 -0500 > > > > > > > > A set of converging concerns were raised about the > > > > REFER draft late in the review process, all centering > > > > on draft's use of sip-events (soon to be RFC3265) and > > > > the implicit subscription. > > > > > > > > When investigating those concerns, several things became > > > > clear. > > > > > > > > The draft did not provide sufficient discussion > > > > around managing the lifecycle of the implicit subscription > > > > (Can you refresh the implicit subscription? unsubscribe? > > > > How is the Subscription-State header supposed to be used? > > > > How do the two parties know when the subscription is over?) > > > > and the draft did not clearly specify some of the things > > > > RFC3265 requires of an event package. These need to be > > > > corrected. > > > > > > > > A larger issue centers around the following language from > > > > sip-events: > > > > > > > > Note that any behavior designated with "SHOULD" or > > "MUST" in this > > > > document is not allowed to be weakened by extension documents; > > > > however, such documents may elect to strengthen "SHOULD" > > > > requirements to "MUST" strength if required by their > > application. > > > > > > > > The current draft is not clear enough on one particular > > point - the > > > > examples do not show immediate NOTIFYs for the implicit > > > subscription. > > > > I expect that many members of the community believe > they are not > > > > required (I had drifted into thinking that way before > the comments > > > > caused me to look at this more closely). The normative > text in the > > > > current REFER draft calls to RFC3265, and immediate > > NOTIFYs are very > > > > clearly required there. This needs to be pointed out > more clearly > > > > in the REFER draft. > > > > > > > > Finally, the current draft makes instantiating a subscription a > > > > SHOULD strength requirement, but provides no mechanism for the > > > > agent sending the REFER to know whether or not to > expect a NOTIFY. > > > > We have repeatedly had discussions on the list about how long > > > > the agent sending the REFER should keep state waiting for > > a NOTIFY - > > > > and with discomfort deciding that is an implementation > decision. > > > > Recent discussions have pointed out that there is > > disagreement about > > > > what never receiving a NOTIFY means - should the REFERing > > > party treat > > > > that as an error and re-attempt the reference or should it just > > > > assume no subscription was created? > > > > > > > > I've put together an individual submission that adds all the > > > > above clarifications. It also proposes a new mechanism to > > > > address the problems in the previous paragraph. Basically, it > > > > provides a way for the party sending the REFER to indicate > > > > that it really wants to be notified, and a way for the agent > > > > accepting the refer to signal that it will or will not send > > > > notifies in the response to the REFER. > > > > > > > > I just submitted this draft - until it appears in the > repository, > > > > you can get it from > > > > > > http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265di > sc-00.txt > > > > I propose that this draft replace refer-05 before it > advances further > > in the standardization process. > > > > RjS > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jun 27 14:08:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05671 for ; Thu, 27 Jun 2002 14:08:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01646 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 14:09:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28345; Thu, 27 Jun 2002 13:38:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14438 for ; Thu, 27 Jun 2002 05:09:12 -0400 (EDT) Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06935; Thu, 27 Jun 2002 05:08:24 -0400 (EDT) Received: from boolard ([10.37.1.56]) by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g5R994V02267; Thu, 27 Jun 2002 10:09:04 +0100 From: "Shane McCormack" To: , Date: Thu, 27 Jun 2002 10:11:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] QoS for complete session Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi there, I have been trawlling through various archives for a while but nothing specifically answers my question which is: Q.Say I use Sip to set up a VoIP call between two PC user agents. How do I provide a level of QoS from Call setup, duration of call to call teardown. Anybody. Sorry if this is a bit obvious to some people but I am just wondering. Regards Shane _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 14:31:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07251 for ; Thu, 27 Jun 2002 14:31:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04032 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 14:31:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01483; Thu, 27 Jun 2002 14:06:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01452 for ; Thu, 27 Jun 2002 14:06:19 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05465 for ; Thu, 27 Jun 2002 14:05:34 -0400 (EDT) Received: from millcity.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5RI6Dis020309; Thu, 27 Jun 2002 14:06:13 -0400 (EDT) Received: from KENJW2K1 (che-vpn2-33.cisco.com [10.86.244.33]) by millcity.cisco.com (Mirapoint) with SMTP id AAK96977; Thu, 27 Jun 2002 14:00:06 -0400 (EDT) Reply-To: From: "Ken Jordan" To: "'Adam Roach'" , Subject: RE: [Sip] Authorization policy change after SUBSCRIBE dialog established Date: Thu, 27 Jun 2002 14:07:42 -0400 Message-ID: <007201c21e05$882ac7d0$3c02a8c0@cisco.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.2910.0) In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F377A282@DYN-TX-EXCH-001.dynamicsoft.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A follow-up question; The allow-events header is used by the server to indicate what events it supports. For the rejected response below, can the allow-events header take on a more specific meaning to indicate what events this particular authenticated subscriber is allowed to subscribe to? I.e. does the server have a means to tell the authenticated subscriber what events they are authorized for? (I was not sure if section 4.3.7 of sip-events-05 allowed this usage) -Ken > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Adam > Roach > Sent: Thursday, June 27, 2002 1:09 PM > To: 'kenj@cisco.com'; 'sip@ietf.org' > Subject: RE: [Sip] Authorization policy change after SUBSCRIBE dialog > established > > > If *authorization* policy changes, I would take that to mean > that the user is no longer authorized to subscribe to the state. > Re-authentication will have no useful effect. You will send a > NOTIFY with a header of > > Subscription-State: terminated;reason=rejected > > The subscriber will not re-authenticate, because the problem is > not *authentication* -- it is *authorization*. > > If you simply want to re-authenticate for whatever reason, a > NOTIFY with a header of > > Subscription-State: terminated;reason=deactivated > > will prompt the user to re-subscribe. This subscribe can then be > challenged. > > /a > > > -----Original Message----- > > From: Ken Jordan [mailto:kenj@cisco.com] > > Sent: Thursday, June 27, 2002 9:32 > > To: Sipietf (E-mail) > > Subject: [Sip] Authorization policy change after SUBSCRIBE dialog > > established > > > > > > > > > > If authorization policy changes during an existing > > subscription dialog, how > > does the notifier cause the subscriber to authenticate (or > > reauthenticate)? > > Is the expires values explicitly set to zero in an immediate > > notify? Is the > > dialog terminated as a 401? > > > > -Ken > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 14:42:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08099 for ; Thu, 27 Jun 2002 14:42:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04727 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 14:43:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02542; Thu, 27 Jun 2002 14:20:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02511 for ; Thu, 27 Jun 2002 14:20:47 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06373 for ; Thu, 27 Jun 2002 14:20:02 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5RIKhxc005479; Thu, 27 Jun 2002 14:20:43 -0400 (EDT) Received: from cs.columbia.edu (dialin-212-144-143-022.arcor-ip.net [212.144.143.22]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5RIKcpf027619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jun 2002 14:20:41 -0400 (EDT) Message-ID: <3D1B574C.6070402@cs.columbia.edu> Date: Thu, 27 Jun 2002 14:19:56 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Undery , sip@ietf.org Subject: Re: [Sip] draft-schulzrinne-sip-bind References: <45730E094814E44488F789C1CDED27AEC55301@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with your assessment of kludginess and the solution. Thanks! James Undery wrote: > Hi, > > I generally like this draft, although would like to suggest a change. > > Having "expires=1" a special value isn't very clean, a "usagecount" > parameter that shows how many times a URL will be valid for seems much > more flexible. The combination of usagecount and expires would also > allow for a one-shot URL that's valid for 60 seconds say, i.e. Binding: > ;disposition=token > ;expires=60 ;usagecount=1 > > James > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 15:30:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11006 for ; Thu, 27 Jun 2002 15:30:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15761 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 15:31:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12587; Thu, 27 Jun 2002 15:05:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12553 for ; Thu, 27 Jun 2002 15:05:09 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09449 for ; Thu, 27 Jun 2002 15:04:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RJ4QN7028631; Thu, 27 Jun 2002 15:04:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 15:04:33 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A287@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Vijay K. Gurbani'" , Adam Roach Cc: "'sip@ietf.org'" , "'gonzalo.camarillo@ericsson.com'" Subject: RE: [Sip] SIP and SigComp draft comment. Date: Thu, 27 Jun 2002 15:04:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > I believe step 8 of Section 16.7 of -09bis assumes that a proxy is > modifying *it's* own R-R in a response that it inserted in the earlier > request, not someone else's I'm sorry I didn't show the route headers at every hop. My proposal (and this is precisely *why* I cited bis-09) is that P1 would modify P1's own header, and P3 would modify P3's own header. With this in mind, go re-read my proposal. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 15:46:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11930 for ; Thu, 27 Jun 2002 15:46:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16605 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 15:46:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14305; Thu, 27 Jun 2002 15:11:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14273 for ; Thu, 27 Jun 2002 15:11:34 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09807 for ; Thu, 27 Jun 2002 15:10:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RJAuN7028681; Thu, 27 Jun 2002 15:10:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 15:11:03 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A289@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'kenj@cisco.com'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] Authorization policy change after SUBSCRIBE dialog esta blished Date: Thu, 27 Jun 2002 15:11:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The meaning of the "Allow-Events" header is tied to capabilities, not authorization. So, no. /a P.S. Keep in mind that any single subscription will use only *one* events package. If I read your motivation correctly, you may be under a different impression. > -----Original Message----- > From: Ken Jordan [mailto:kenj@cisco.com] > Sent: Thursday, June 27, 2002 13:08 > To: 'Adam Roach'; sip@ietf.org > Subject: RE: [Sip] Authorization policy change after SUBSCRIBE dialog > established > > > > A follow-up question; The allow-events header is used by the > server to > indicate what events it supports. For the rejected response > below, can the > allow-events header take on a more specific meaning to > indicate what events > this particular authenticated subscriber is allowed to > subscribe to? I.e. > does the server have a means to tell the authenticated subscriber what > events they are authorized for? (I was not sure if section 4.3.7 of > sip-events-05 allowed this usage) > > -Ken > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of Adam > > Roach > > Sent: Thursday, June 27, 2002 1:09 PM > > To: 'kenj@cisco.com'; 'sip@ietf.org' > > Subject: RE: [Sip] Authorization policy change after > SUBSCRIBE dialog > > established > > > > > > If *authorization* policy changes, I would take that to mean > > that the user is no longer authorized to subscribe to the state. > > Re-authentication will have no useful effect. You will send a > > NOTIFY with a header of > > > > Subscription-State: terminated;reason=rejected > > > > The subscriber will not re-authenticate, because the problem is > > not *authentication* -- it is *authorization*. > > > > If you simply want to re-authenticate for whatever reason, a > > NOTIFY with a header of > > > > Subscription-State: terminated;reason=deactivated > > > > will prompt the user to re-subscribe. This subscribe can then be > > challenged. > > > > /a > > > > > -----Original Message----- > > > From: Ken Jordan [mailto:kenj@cisco.com] > > > Sent: Thursday, June 27, 2002 9:32 > > > To: Sipietf (E-mail) > > > Subject: [Sip] Authorization policy change after SUBSCRIBE dialog > > > established > > > > > > > > > > > > > > > If authorization policy changes during an existing > > > subscription dialog, how > > > does the notifier cause the subscriber to authenticate (or > > > reauthenticate)? > > > Is the expires values explicitly set to zero in an immediate > > > notify? Is the > > > dialog terminated as a 401? > > > > > > -Ken > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 15:59:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12833 for ; Thu, 27 Jun 2002 15:59:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17776 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 16:00:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15307; Thu, 27 Jun 2002 15:29:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15276 for ; Thu, 27 Jun 2002 15:29:51 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10944 for ; Thu, 27 Jun 2002 15:29:06 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GYD00E01Q3E2J@firewall.wcom.com> for sip@ietf.org; Thu, 27 Jun 2002 19:28:26 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GYD00D8QQ39JQ@firewall.wcom.com>; Thu, 27 Jun 2002 19:28:26 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GYD00H01Q2OB4@dgismtp04.wcomnet.com>; Thu, 27 Jun 2002 19:28:22 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.168]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GYD00G8MQ1GPJ@dgismtp04.wcomnet.com>; Thu, 27 Jun 2002 19:27:38 +0000 (GMT) Date: Thu, 27 Jun 2002 14:27:17 -0500 From: Henry Sinnreich Subject: RE: [Sip] QoS for complete session In-reply-to: To: "'Shane McCormack'" , sip@ietf.org Cc: greg.king@wcom.com Message-id: <000601c21e10$b325e3b0$a8202aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >How I provide a level of QoS from Call setup, >duration of call to call teardown. The non-PC answer is QoS is a non-issue except on bandwidth starved access lines. In such cases I personally like the approach using SIP session counting for RTP voice packets and manage the remaining TCP traffic with a QoS appliance, see: http://www.nwfusion.com/reviews/2002/0603rev.html The edge-to-edge TCP control by QoS appliances seems to be pretty architecturally correct. This is admittedly a simplistic approach and I look forward for other approaches people may suggest. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Shane McCormack > Sent: Wednesday, June 26, 2002 8:37 AM > To: sip@ietf.org > Subject: [Sip] QoS for complete session > > > Hi there, > I have been trawlling through various archives for a while > but nothing specifically answers my question which is: > > Q.Say I use Sip to set up a VoIP call between to PC user > agents. How I provide a level of QoS from Call setup, > duration of call to call teardown. Anybody. Sorry if this is > a bit obvious to some people but I am just wondering. > > Regards > > Shane > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 16:14:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13619 for ; Thu, 27 Jun 2002 16:14:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19149 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 16:15:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16477; Thu, 27 Jun 2002 15:43:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16446 for ; Thu, 27 Jun 2002 15:43:56 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11844 for ; Thu, 27 Jun 2002 15:43:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g5RJhHN8028951; Thu, 27 Jun 2002 15:43:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 15:43:25 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A28B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Shane McCormack'" , sip@ietf.org Subject: RE: [Sip] QoS for complete session Date: Thu, 27 Jun 2002 15:43:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Shane McCormack [mailto:smccormack@tssg.org] > > I have been trawlling through various archives for a while but nothing > specifically answers my question which is: > > Q.Say I use Sip to set up a VoIP call between two PC user > agents. How do I > provide a level of QoS from Call setup, duration of call to > call teardown. A. See RFC 2205. Although that is sufficient, additional interworking can be acheived using the mechanism described in http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-07.txt /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 16:18:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13838 for ; Thu, 27 Jun 2002 16:18:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19336 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 16:19:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17035; Thu, 27 Jun 2002 15:52:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17004 for ; Thu, 27 Jun 2002 15:52:49 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12323 for ; Thu, 27 Jun 2002 15:52:03 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5RJqGR18504; Thu, 27 Jun 2002 15:52:16 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA27753; Thu, 27 Jun 2002 14:52:15 -0500 (CDT) Message-ID: <3D1B6CED.7030403@lucent.com> Date: Thu, 27 Jun 2002 14:52:13 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] SIP and SigComp draft comment. References: <9BF66EBF6BEFD942915B4D4D45C051F377A287@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Adam Roach wrote: >>-----Original Message----- >>From: Vijay K. Gurbani [mailto:vkg@lucent.com] >> >>I believe step 8 of Section 16.7 of -09bis assumes that a proxy is >>modifying *it's* own R-R in a response that it inserted in the earlier >>request, not someone else's > > > I'm sorry I didn't show the route headers at every hop. > > My proposal (and this is precisely *why* I cited bis-09) is > that P1 would modify P1's own header, and P3 would modify P3's > own header. > > With this in mind, go re-read my proposal. Ah, okay. It was not clear to me on the initial reading if you intended the last two set of R-Rs to be from P3's point of view only. But what you intended was that P1 does not add the 'comp=sigcomp' parameter on the request (but does so on the response), and vice versa for P3. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jun 27 22:36:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27505 for ; Thu, 27 Jun 2002 22:36:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11068 for sip-archive@odin.ietf.org; Thu, 27 Jun 2002 22:37:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09316; Thu, 27 Jun 2002 21:56:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09288 for ; Thu, 27 Jun 2002 21:56:36 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26408 for ; Thu, 27 Jun 2002 21:55:50 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GYE0070181GCD@firewall.wcom.com> for sip@ietf.org; Fri, 28 Jun 2002 01:56:04 +0000 (GMT) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GYE0049E81GZJ@firewall.wcom.com>; Fri, 28 Jun 2002 01:56:04 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GYE0030181FIZ@dgismtp05.wcomnet.com>; Fri, 28 Jun 2002 01:56:03 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.168]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GYE00M4S81EGY@dgismtp05.wcomnet.com>; Fri, 28 Jun 2002 01:56:03 +0000 (GMT) Date: Thu, 27 Jun 2002 20:56:02 -0500 From: Henry Sinnreich Subject: RE: [Sip] QoS for complete session In-reply-to: <108d01c21e16$d265b5b0$743c0198@ecew2k.ncsu.edu> To: "'Prabhas Sinha'" , "'Shane McCormack'" , sip@ietf.org Cc: greg.king@wcom.com Message-id: <000501c21e46$f5db01f0$a8202aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > How 'bout making use of RSVP if possible ? Though I worked on RSVP validation in a coast to coast network some time ago, lately I don't like it any more because of cost, complexity and added call setup delay. I like PRACK even less, since it is a close emulation if the circuit switched network. These are just personal biases. Using SIP phones for most of the calls in the office, from home and travel, QoS is the least of the problems. Even when using dial-access, the G.723.1 in Windows Messenger 4.6 provides business quality voice in transatlantic calls. Except when e-mail kicks in and produces voice clipping because it takes over all the dial-up link bandwidth. That's where MCML PPP or the TCP windows based control comes in for TCP applications. In conclusion, there are better approaches than RSVP IMHO. Henry > -----Original Message----- > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > Sent: Thursday, June 27, 2002 3:11 PM > To: Henry Sinnreich; 'Shane McCormack'; sip@ietf.org > Cc: greg.king@wcom.com > Subject: Re: [Sip] QoS for complete session > > > How 'bout making use of RSVP if possible ? > I am attaching a small picture to illustrate the same. What > will fit the scenario depends upon the network infrastructure > being used in his case. In simplistic case, I second your approach. > > Prabhas > Research Assistant > Dept of Computer Engineering > North Carolina State University > Raleigh, NC 27695 > > > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Shane McCormack'" ; > Cc: > Sent: Thursday, June 27, 2002 3:27 PM > Subject: RE: [Sip] QoS for complete session > > > > >How I provide a level of QoS from Call setup, > > >duration of call to call teardown. > > > > The non-PC answer is QoS is a non-issue except on bandwidth starved > > access lines. In such cases I personally like the approach > using SIP > > session counting for RTP voice packets and manage the remaining TCP > > traffic with a QoS appliance, see: > > > > http://www.nwfusion.com/reviews/2002/0603rev.html > > > > The edge-to-edge TCP control by QoS appliances seems to be pretty > > architecturally correct. > > > > This is admittedly a simplistic approach and I look forward > for other > > approaches people may suggest. > > > > Henry > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > > Shane McCormack > > > Sent: Wednesday, June 26, 2002 8:37 AM > > > To: sip@ietf.org > > > Subject: [Sip] QoS for complete session > > > > > > > > > Hi there, > > > I have been trawlling through various archives for a while but > > > nothing specifically answers my question which is: > > > > > > Q.Say I use Sip to set up a VoIP call between to PC user > agents. How > > > I provide a level of QoS from Call setup, duration of > call to call > > > teardown. Anybody. Sorry if this is a bit obvious to some > people but > > > I am just wondering. > > > > > > Regards > > > > > > Shane > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 28 00:23:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29782 for ; Fri, 28 Jun 2002 00:23:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15559 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 00:24:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13638; Thu, 27 Jun 2002 23:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13609 for ; Thu, 27 Jun 2002 23:54:32 -0400 (EDT) Received: from btlmail.bplmail.com ([203.200.31.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29126 for ; Thu, 27 Jun 2002 23:53:44 -0400 (EDT) Received: from [10.10.13.95] (helo=RaviRaj) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 17Nmmq-0000uw-00; Fri, 28 Jun 2002 09:21:08 +0530 Message-ID: <003901c21e57$b21e1860$5f0d0a0a@SIGMA> From: "Ranjit Avasarala" To: "Li Li" , References: <8BAF8B40C4D2D411ADC300508BD63D690140C08A@mail.ss8.ca> Subject: Re: [Sip] UA running on TCP Date: Fri, 28 Jun 2002 09:25:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Currently our sip stack runs on UDP, but TCP support is yet to be implemented. DOes that mean the sip stack is not confirming to standards? Ranjit ----- Original Message ----- From: Li Li To: Sent: Thursday, June 27, 2002 2:08 AM Subject: [Sip] UA running on TCP > In the new bis, it is mandatory that UA should support > TCP transport. Assume a UA with a TCP connection 1 sending to > the proxy, and a TCP connection 2 for receiving from the > proxy. Now assume that the TCP connection 1 and 2 go down/timed out. > This may due to a temporary failure. The proxy recovers asap and > sets up a new TCP connection for sending to the UA. > What should the UA do? Should the UA try to set up a connection > to the proxy so that requests can be sent/resent? Or the UA > would just release all the calls it has with the proxy and try for > another proxy if available? > > > Li > > > -----Original Message----- > > From: Andre Poulin (LMC) [mailto:Andre.Poulin@ericsson.ca] > > Sent: Wednesday, June 26, 2002 2:21 PM > > To: 'sip@ietf.org' > > Subject: [Sip] Authentication-Info header > > > > > > > > > > I have a question regarding Authentication headers. > > > > What is the reason to have only one Authentication-Info > > header instead of > > having both www-Authentication-Info and proxy- > > Authentication-Info headers? This does not seem to be > > consistent with the > > other related authentication headers which have both > > cases (www and proxy) > > > > Thanks, > > /Andre > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 28 01:35:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01935 for ; Fri, 28 Jun 2002 01:35:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26967 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 01:36:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19963; Fri, 28 Jun 2002 01:07:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19932 for ; Fri, 28 Jun 2002 01:07:17 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01380 for ; Fri, 28 Jun 2002 01:06:32 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5S56kYH023956 for ; Fri, 28 Jun 2002 01:06:47 -0400 (EDT) Message-ID: <3D1BEEE5.5010005@dynamicsoft.com> Date: Fri, 28 Jun 2002 01:06:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Proposed change in draft-ietf-sip-nat Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I would like to propose a change in draft-ietf-sip-nat. Right now, this document specifies two very independent and orthogonal things. One of them is the rport parameter. This is a Via param that makes sure that the SIP response gets routed back to the source IP and port where the request came from. Without it, SIP over UDP doesn't work through any NATs. It allows SIP to work like most other protocols in terms of its port usage. I think its uncontroversial and should move forward as is. THe other aspect is the Translate header. Its aimed at making registrations work through NAT. However, there are several problems with the Translate header right now: 1. It "competes" with other solutions, such as STUN and TURN/SPAN, which would allow for incoming INVITEs through NAT without any SIP specific extensions. 2. It tries to optimize for the full-cone case, by including a parameter that indicates whether the client is behind a full-cone or symmetric NAT. I would rather not pollute SIP with this kind of NAT-specific stuff; rather, relegate it to STUN/TURN. 3. UDP registrations through NAT are really troublesome. They require very frequent re-registrations to maintain the binding (under a minute). This poses a serious load. If you have to use UDP, a STUN or TURN solution is much better, since refreshes of the NAT bindings would occur through those protocols, rather than SIP, and they scale much better. So, if you consider TCP (which works even better still, since you don't need to refresh the registration in order to keep the binding active), the problem is not really translating the contact header as it is TCP connection reuse for incoming requests. Indeed, the same problem occurs in record-routing - you want to be able to specify to your peer to reuse the connection for incoming requests. Thats not even a nat-specific thing; its just a capability that, if we had a better story on, would be useful for NAT. As a result, I would propose that draft-ietf-sip-nat move forward with just the rport stuff, and we look at the registration problem separately. I would like a solution for SIP that didn't depend on STUN/TURN, but I have convinced myself that this solution needs to be TCP-based, and that it is best viewed as a problem of connection reuse. ROhan has posted a requirement draft on that topic. Flame away.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 28 01:35:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01948 for ; Fri, 28 Jun 2002 01:35:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26981 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 01:36:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24134; Fri, 28 Jun 2002 01:15:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24090 for ; Fri, 28 Jun 2002 01:15:22 -0400 (EDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01532 for ; Fri, 28 Jun 2002 01:13:29 -0400 (EDT) Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g5S5DUe19131 for ; Fri, 28 Jun 2002 10:43:32 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GYEH6600.42H for ; Fri, 28 Jun 2002 10:43:18 +0530 Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 10:43:18 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9d37fabc-9ff0-4277-b8fa-86eb25b63cf6" Subject: RE: [Sip] UA running on TCP X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 28 Jun 2002 10:43:17 +0530 Message-ID: <60614B15188EBB4FA59F85310C2AC7D6165E27@blr-m1-msg.wipro.com> Thread-Topic: [Sip] UA running on TCP Thread-Index: AcIeWFt31h8EYoYgR6KUgirXMuPyNQACcchQ From: "Vijay S Kamath" To: X-OriginalArrivalTime: 28 Jun 2002 05:13:18.0101 (UTC) FILETIME=[83769450:01C21E62] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-9d37fabc-9ff0-4277-b8fa-86eb25b63cf6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is mandatory to support TCP,UDP. Quoting bis09, section 18 line 3563:- "All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols." Rgds... Vijay -----Original Message----- From: Ranjit Avasarala [mailto:ranjit.avasarala@bplmail.com]=20 Sent: Friday, June 28, 2002 9:26 AM To: Li Li; sip@ietf.org Subject: Re: [Sip] UA running on TCP Hi Currently our sip stack runs on UDP, but TCP support is yet to be implemented. DOes that mean the sip stack is not confirming to standards? Ranjit ----- Original Message ----- From: Li Li To: Sent: Thursday, June 27, 2002 2:08 AM Subject: [Sip] UA running on TCP > In the new bis, it is mandatory that UA should support > TCP transport. Assume a UA with a TCP connection 1 sending to the=20 > proxy, and a TCP connection 2 for receiving from the proxy. Now assume > that the TCP connection 1 and 2 go down/timed out. This may due to a=20 > temporary failure. The proxy recovers asap and sets up a new TCP=20 > connection for sending to the UA. What should the UA do? Should the UA > try to set up a connection to the proxy so that requests can be=20 > sent/resent? Or the UA would just release all the calls it has with=20 > the proxy and try for another proxy if available? > > > Li > > > -----Original Message----- > > From: Andre Poulin (LMC) [mailto:Andre.Poulin@ericsson.ca] > > Sent: Wednesday, June 26, 2002 2:21 PM > > To: 'sip@ietf.org' > > Subject: [Sip] Authentication-Info header > > > > > > > > > > I have a question regarding Authentication headers. > > > > What is the reason to have only one Authentication-Info header=20 > > instead of having both www-Authentication-Info and proxy- > > Authentication-Info headers? This does not seem to be > > consistent with the > > other related authentication headers which have both > > cases (www and proxy) > > > > Thanks, > > /Andre > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > 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=20 > 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 ------=_NextPartTM-000-9d37fabc-9ff0-4277-b8fa-86eb25b63cf6 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-9d37fabc-9ff0-4277-b8fa-86eb25b63cf6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 28 01:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02356 for ; Fri, 28 Jun 2002 01:47:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27415 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 01:47:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26196; Fri, 28 Jun 2002 01:26:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26172 for ; Fri, 28 Jun 2002 01:26:43 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01765 for ; Fri, 28 Jun 2002 01:25:58 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5S5QCYH023963 for ; Fri, 28 Jun 2002 01:26:13 -0400 (EDT) Message-ID: <3D1BF373.3030806@dynamicsoft.com> Date: Fri, 28 Jun 2002 01:26:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] A change in the presentation of caller preferences Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, The caller preferences specification (which has actually expired :( ): http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-05.txt had been shoved on the back burner for a while as we worked on more pressing drafts. Beyond the general lack of priority, another problem that arose during WGLC, mostly in private comments, was that the specification lacked clarity on what the lists of contact and accept-contact parameters meant. Were these sets? Where these boolean expressions? The definitions were inconsistent between the contact header and the accept-contact header. There were also concerns raised about the amount of code in the spec. I felt it was necesary to properly get the algorithm right. The final issue, which was nagging me, was that this whole thing was REALLY reinventing the wheel. There exists IETF work on specifying capabilities and preferences, and then matching them together - RFC 2533. We had considered this mechanism in the early days of caller preferences, but discarded it as "too complex". I was concerned that this would not be a sufficiently good reason for ignoring that work. At the same time, I don't want to discard the syntax and general operation of caller-prefs, since its been used in many other specs so far. So, I have come up with a change in the *presentation* of the extension. The syntax will stay as is. However, the specification will show how to map the syntax into the standard structures of RFC 2533, and then it will point to RFC 2533 for the matching algorithms. Now, the matching algorithm in 2533 is not-trivial. Turns out, you can simplify it if you restrict the scope of the expressiveness of the feature sets. If you specify that all feature sets have to specify constraints on each feature orthogonally, the algorithm can be much simplified. Indeed, it can be simplified to whats currently documented in caller-prefs, since the caller prefs spec assumes orthogonal feature constraints. A benefit of making use of RFC 2533 is that the meaning of the contact and accept-contact params becomes well-defined - both represent feature sets as defined in 2533. Another benefit is that the caller prefs spec becomes a lot shorter. All the code can go, as can the description of the matching algorithm. I will attempt to complete this rework in time for the cutoff on Monday. However, I wanted to make the group aware of this proposed change, and seek input on it. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jun 28 02:08:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11413 for ; Fri, 28 Jun 2002 02:08:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28239 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 02:09:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27467; Fri, 28 Jun 2002 01:48:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27436 for ; Fri, 28 Jun 2002 01:48:27 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02373 for ; Fri, 28 Jun 2002 01:47:41 -0400 (EDT) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5S5mMrU014628; Fri, 28 Jun 2002 07:48:22 +0200 (MEST) Received: from lmf.ericsson.se (arbru3m18.eu.ericsson.se [164.48.163.19]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g5S5mIqn012425; Fri, 28 Jun 2002 07:48:19 +0200 (MET DST) Message-ID: <3D1BF8BF.E4E9F384@lmf.ericsson.se> Date: Fri, 28 Jun 2002 08:48:47 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] A change in the presentation of caller preferences References: <3D1BF373.3030806@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan, I think the link you gave points to version -04 of the draft, OR you have forgot to change the text at the beginning of the draft :) "Internet Engineering Task Force SIP WG Internet Draft Schulzrinne/Rosenberg draft-ietf-sip-callerprefs-04.txt Columbia U./dynamicsoft November 21, 2001 Expires: December 2001" Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > Folks, > > The caller preferences specification (which has actually expired :( ): > http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-05.txt > > had been shoved on the back burner for a while as we worked on more > pressing drafts. Beyond the general lack of priority, another problem > that arose during WGLC, mostly in private comments, was that the > specification lacked clarity on what the lists of contact and > accept-contact parameters meant. Were these sets? Where these boolean > expressions? The definitions were inconsistent between the contact > header and the accept-contact header. There were also concerns raised > about the amount of code in the spec. I felt it was necesary to properly > get the algorithm right. The final issue, which was nagging me, was that > this whole thing was REALLY reinventing the wheel. There exists IETF > work on specifying capabilities and preferences, and then matching them > together - RFC 2533. We had considered this mechanism in the early days > of caller preferences, but discarded it as "too complex". I was > concerned that this would not be a sufficiently good reason for ignoring > that work. At the same time, I don't want to discard the syntax and > general operation of caller-prefs, since its been used in many other > specs so far. > > So, I have come up with a change in the *presentation* of the extension. > The syntax will stay as is. However, the specification will show how > to map the syntax into the standard structures of RFC 2533, and then it > will point to RFC 2533 for the matching algorithms. Now, the matching > algorithm in 2533 is not-trivial. Turns out, you can simplify it if you > restrict the scope of the expressiveness of the feature sets. If you > specify that all feature sets have to specify constraints on each > feature orthogonally, the algorithm can be much simplified. Indeed, it > can be simplified to whats currently documented in caller-prefs, since > the caller prefs spec assumes orthogonal feature constraints. > > A benefit of making use of RFC 2533 is that the meaning of the contact > and accept-contact params becomes well-defined - both represent feature > sets as defined in 2533. Another benefit is that the caller prefs spec > becomes a lot shorter. All the code can go, as can the description of > the matching algorithm. > > I will attempt to complete this rework in time for the cutoff on Monday. > However, I wanted to make the group aware of this proposed change, and > seek input on it. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 06:01:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16287 for ; Fri, 28 Jun 2002 06:01:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA09863 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 06:02:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08696; Fri, 28 Jun 2002 05:36:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08665 for ; Fri, 28 Jun 2002 05:36:23 -0400 (EDT) Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15793 for ; Fri, 28 Jun 2002 05:35:36 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix1-2.free.fr (Postfix) with ESMTP id 44BAFAB2D6 for ; Fri, 28 Jun 2002 11:36:16 +0200 (CEST) Received: by imp1-2.free.fr (Postfix, from userid 33) id F308C8736A; Fri, 28 Jun 2002 11:36:15 +0200 (MEST) To: sip@ietf.org Message-ID: <1025256975.3d1c2e0fd89fa@imp.free.fr> Date: Fri, 28 Jun 2002 11:36:15 +0200 (MEST) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 64.208.49.160 Content-Transfer-Encoding: 8bit Subject: [Sip] SIP session without SDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sir, My understanding of bis-09 (and 2543) is that I am allowed to establish a SIP sesion (INVITE, ..../OK /ACK ) without any SDP description. Am i right ? TIA Patrick _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 09:13:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24840 for ; Fri, 28 Jun 2002 09:13:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24677 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 09:14:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22738; Fri, 28 Jun 2002 08:45:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22706 for ; Fri, 28 Jun 2002 08:45:40 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23652 for ; Fri, 28 Jun 2002 08:44:54 -0400 (EDT) Received: from OranLT.cisco.com ([161.44.238.34]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5SCj1L0004222; Fri, 28 Jun 2002 05:45:01 -0700 (PDT) Date: Fri, 28 Jun 2002 08:43:24 -0400 From: "David R. Oran" To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat Message-ID: <1068069502.1025253804@OranLT.cisco.com> In-Reply-To: <3D1BEEE5.5010005@dynamicsoft.com> References: <3D1BEEE5.5010005@dynamicsoft.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think this is a reasonable way forward. The less NAT-specific stuff we embed in SIP itself the more likely generic solutions will make their way into the market, and the less baggage we add to SIP itself. Dave. --On Friday, June 28, 2002 1:06 AM -0400 Jonathan Rosenberg wrote: > Folks, > > I would like to propose a change in draft-ietf-sip-nat. > > Right now, this document specifies two very independent and orthogonal > things. One of them is the rport parameter. This is a Via param that > makes sure that the SIP response gets routed back to the source IP and > port where the request came from. Without it, SIP over UDP doesn't work > through any NATs. It allows SIP to work like most other protocols in > terms of its port usage. I think its uncontroversial and should move > forward as is. > > THe other aspect is the Translate header. Its aimed at making > registrations work through NAT. However, there are several problems with > the Translate header right now: > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN, which > would allow for incoming INVITEs through NAT without any SIP specific > extensions. > > 2. It tries to optimize for the full-cone case, by including a parameter > that indicates whether the client is behind a full-cone or symmetric NAT. > I would rather not pollute SIP with this kind of NAT-specific stuff; > rather, relegate it to STUN/TURN. > > 3. UDP registrations through NAT are really troublesome. They require > very frequent re-registrations to maintain the binding (under a minute). > This poses a serious load. If you have to use UDP, a STUN or TURN > solution is much better, since refreshes of the NAT bindings would occur > through those protocols, rather than SIP, and they scale much better. So, > if you consider TCP (which works even better still, since you don't need > to refresh the registration in order to keep the binding active), the > problem is not really translating the contact header as it is TCP > connection reuse for incoming requests. Indeed, the same problem occurs > in record-routing - you want to be able to specify to your peer to reuse > the connection for incoming requests. Thats not even a nat-specific > thing; its just a capability that, if we had a better story on, would be > useful for NAT. > > > As a result, I would propose that draft-ietf-sip-nat move forward with > just the rport stuff, and we look at the registration problem separately. > I would like a solution for SIP that didn't depend on STUN/TURN, but I > have convinced myself that this solution needs to be TCP-based, and that > it is best viewed as a problem of connection reuse. ROhan has posted a > requirement draft on that topic. > > Flame away.... > > -Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ----------------------------------------------------------- David R. Oran Phone/Fax: +1 978 264 2048 Cisco Systems VoIP: +1 408 571 4576 7 Ladyslipper Lane Email: oran@cisco.com Acton, MA 01720 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 09:29:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25510 for ; Fri, 28 Jun 2002 09:29:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25263 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 09:30:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24227; Fri, 28 Jun 2002 09:02:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24199 for ; Fri, 28 Jun 2002 09:02:40 -0400 (EDT) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24333 for ; Fri, 28 Jun 2002 09:01:53 -0400 (EDT) Received: by mail.ss8.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 09:02:09 -0400 Message-ID: <8BAF8B40C4D2D411ADC300508BD63D690140C09D@mail.ss8.ca> From: Li Li To: "'Vijay S Kamath'" , sip@ietf.org Subject: RE: [Sip] UA running on TCP Date: Fri, 28 Jun 2002 09:02:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree with you that the TCP support is mandatory. But I'm not quite sure the behavior of a UA running on TCP when the TCP connection has a temporary problem. Anything in the bis describes this? Thanks, Li > -----Original Message----- > From: Vijay S Kamath [mailto:vijay.kamath@wipro.com] > Sent: Friday, June 28, 2002 1:13 AM > To: sip@ietf.org > Subject: RE: [Sip] UA running on TCP > > > It is mandatory to support TCP,UDP. > Quoting bis09, section 18 line 3563:- > "All SIP elements MUST implement UDP and TCP. SIP elements MAY > implement other protocols." > > Rgds... Vijay > > ----- Original Message ----- > From: Li Li > To: > Sent: Thursday, June 27, 2002 2:08 AM > Subject: [Sip] UA running on TCP > > > In the new bis, it is mandatory that UA should support > TCP transport. Assume a UA with a TCP connection 1 sending to the > proxy, and a TCP connection 2 for receiving from the proxy. > Now assume that the TCP connection 1 and 2 go down/timed out. This may > due to a temporary failure. The proxy recovers asap and sets up a new TCP > connection for sending to the UA. What should the UA do? > Should the UA try to set up a connection to the proxy so that requests can be > sent/resent? Or the UA would just release all the calls it has with > the proxy and try for another proxy if available? > > >Li > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 10:20:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27897 for ; Fri, 28 Jun 2002 10:20:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28628 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 10:21:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26336; Fri, 28 Jun 2002 09:50:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07267 for ; Fri, 28 Jun 2002 05:15:10 -0400 (EDT) Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15303 for ; Fri, 28 Jun 2002 05:14:23 -0400 (EDT) Received: from host213-122-153-158.in-addr.btopenworld.com ([213.122.153.158] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #8) id 17NrqH-0006kv-00; Fri, 28 Jun 2002 10:15:01 +0100 Message-ID: <004601c21e84$8d200f00$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , References: <3D1BEEE5.5010005@dynamicsoft.com> Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat Date: Fri, 28 Jun 2002 10:16:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sounds reasonable except that to be in line with the pre-midcom / midcom work all references to TURN should be to SPAN (Simple Protocol for Augmenting NATs), at least for the time being. For those that are interested, a candidate for SPAN is at: http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt But be advised that this is iteration 1 and so subject to change. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: Sent: 28 June 2002 06:06 Subject: [Sip] Proposed change in draft-ietf-sip-nat > Folks, > > I would like to propose a change in draft-ietf-sip-nat. > > Right now, this document specifies two very independent and orthogonal > things. One of them is the rport parameter. This is a Via param that > makes sure that the SIP response gets routed back to the source IP and > port where the request came from. Without it, SIP over UDP doesn't work > through any NATs. It allows SIP to work like most other protocols in > terms of its port usage. I think its uncontroversial and should move > forward as is. > > THe other aspect is the Translate header. Its aimed at making > registrations work through NAT. However, there are several problems with > the Translate header right now: > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN, which > would allow for incoming INVITEs through NAT without any SIP specific > extensions. > > 2. It tries to optimize for the full-cone case, by including a parameter > that indicates whether the client is behind a full-cone or symmetric > NAT. I would rather not pollute SIP with this kind of NAT-specific > stuff; rather, relegate it to STUN/TURN. > > 3. UDP registrations through NAT are really troublesome. They require > very frequent re-registrations to maintain the binding (under a minute). > This poses a serious load. If you have to use UDP, a STUN or TURN > solution is much better, since refreshes of the NAT bindings would occur > through those protocols, rather than SIP, and they scale much better. > So, if you consider TCP (which works even better still, since you don't > need to refresh the registration in order to keep the binding active), > the problem is not really translating the contact header as it is TCP > connection reuse for incoming requests. Indeed, the same problem occurs > in record-routing - you want to be able to specify to your peer to reuse > the connection for incoming requests. Thats not even a nat-specific > thing; its just a capability that, if we had a better story on, would be > useful for NAT. > > > As a result, I would propose that draft-ietf-sip-nat move forward with > just the rport stuff, and we look at the registration problem > separately. I would like a solution for SIP that didn't depend on > STUN/TURN, but I have convinced myself that this solution needs to be > TCP-based, and that it is best viewed as a problem of connection reuse. > ROhan has posted a requirement draft on that topic. > > Flame away.... > > -Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 10:23:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28056 for ; Fri, 28 Jun 2002 10:23:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28754 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 10:23:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26317; Fri, 28 Jun 2002 09:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13545 for ; Thu, 27 Jun 2002 23:49:57 -0400 (EDT) Received: from services1.dasecurenetworks.com (adsl-64-217-197-215.dsl.rcsntx.swbell.net [64.217.197.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29065 for ; Thu, 27 Jun 2002 23:49:10 -0400 (EDT) Received: from infravast.com (main1.localdomain [192.168.0.151]) by services1.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g5S3QrV32511; Thu, 27 Jun 2002 22:26:54 -0500 Message-ID: <3D1BE4AA.7C826624@infravast.com> Date: Thu, 27 Jun 2002 23:23:06 -0500 From: Chris Martin Reply-To: matrix@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich CC: "'Prabhas Sinha'" , "'Shane McCormack'" , sip@ietf.org, greg.king@wcom.com Subject: Re: [Sip] QoS for complete session References: <000501c21e46$f5db01f0$a8202aa6@hsinnreich2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > > > How 'bout making use of RSVP if possible ? > > Though I worked on RSVP validation in a coast to coast network some time > ago, lately I don't like it any more because of cost, complexity and > added call setup delay. I like PRACK even less, since it is a close > emulation if the circuit switched network. These are just personal > biases. > > Using SIP phones for most of the calls in the office, from home and > travel, QoS is the least of the problems. Even when using dial-access, > the G.723.1 in Windows Messenger 4.6 provides business quality voice in > transatlantic calls. Except when e-mail kicks in and produces voice > clipping because it takes over all the dial-up link bandwidth. This most likely also produces cpu and memory resource starvation during the exchange (especially the way many individuals run dozens of apps in memory, as often seen by largely populated taskbars)...some of the percieved quality issues in PC scenarios are often associated at this level before the bandwidth even comes into play (whether dial up or network based) ...just my opinion. An analyzer could indicate more accurately which is which. Then again, as you said, email does take up quite a bit of bandwidth all by itself. :^) Chris >That's > where MCML PPP or the TCP windows based control comes in for TCP > applications. In conclusion, there are better approaches than RSVP IMHO. > > Henry > > > -----Original Message----- > > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu] > > Sent: Thursday, June 27, 2002 3:11 PM > > To: Henry Sinnreich; 'Shane McCormack'; sip@ietf.org > > Cc: greg.king@wcom.com > > Subject: Re: [Sip] QoS for complete session > > > > > > How 'bout making use of RSVP if possible ? > > I am attaching a small picture to illustrate the same. What > > will fit the scenario depends upon the network infrastructure > > being used in his case. In simplistic case, I second your approach. > > > > Prabhas > > Research Assistant > > Dept of Computer Engineering > > North Carolina State University > > Raleigh, NC 27695 > > > > > > > > ----- Original Message ----- > > From: "Henry Sinnreich" > > To: "'Shane McCormack'" ; > > Cc: > > Sent: Thursday, June 27, 2002 3:27 PM > > Subject: RE: [Sip] QoS for complete session > > > > > > > >How I provide a level of QoS from Call setup, > > > >duration of call to call teardown. > > > > > > The non-PC answer is QoS is a non-issue except on bandwidth starved > > > access lines. In such cases I personally like the approach > > using SIP > > > session counting for RTP voice packets and manage the remaining TCP > > > traffic with a QoS appliance, see: > > > > > > http://www.nwfusion.com/reviews/2002/0603rev.html > > > > > > The edge-to-edge TCP control by QoS appliances seems to be pretty > > > architecturally correct. > > > > > > This is admittedly a simplistic approach and I look forward > > for other > > > approaches people may suggest. > > > > > > Henry > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > > > Shane McCormack > > > > Sent: Wednesday, June 26, 2002 8:37 AM > > > > To: sip@ietf.org > > > > Subject: [Sip] QoS for complete session > > > > > > > > > > > > Hi there, > > > > I have been trawlling through various archives for a while but > > > > nothing specifically answers my question which is: > > > > > > > > Q.Say I use Sip to set up a VoIP call between to PC user > > agents. How > > > > I provide a level of QoS from Call setup, duration of > > call to call > > > > teardown. Anybody. Sorry if this is a bit obvious to some > > people but > > > > I am just wondering. > > > > > > > > Regards > > > > > > > > Shane > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 11:37:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01391 for ; Fri, 28 Jun 2002 11:37:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03051 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 11:38:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01771; Fri, 28 Jun 2002 11:12:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01736 for ; Fri, 28 Jun 2002 11:12:08 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00158 for ; Fri, 28 Jun 2002 11:11:19 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5SFBXr10275; Fri, 28 Jun 2002 10:11:33 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:11:19 -0500 Message-ID: From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" Cc: "'Adam Roach'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] RE: Event Filtering Date: Fri, 28 Jun 2002 10:11:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21EB6.0C2270A0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21EB6.0C2270A0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Looking at it from a requirements perspective, we could trim it down to a small set. We could start with something as small as: * Rate of Notification - here all the subscriber says is - do not exceed 'x' notifications per minute. * Content of Notification - they subscriber indicates support for full or partial/incremental notification bodies. This would help UA's that can handle only full event notification documents and do not have the computation power to deal with incremental notifications. Support for content indirection could be optional here - this would allow a UA to indicate that it is capable of retrieving event notification bodies using an alternate mechanism like HTTP. Any other filtering requirements may be treated as extensions by individual event packages. I strongly support the use of XML for the filter language. Thanks, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, June 27, 2002 2:59 AM To: Parameswar, Sriram [NGC:B615:EXCH] Cc: 'Adam Roach'; Robert Sparks; sip@ietf.org Subject: Re: [Sip] RE: Event Filtering I acutally like the idea of a more generic filter/trigger mechanism that would apply cross-packages. The tradeoff is one of generality vs. complexity. The single mechanism will be more general, but probably more complex than an event-specific one. How much more complex? Impossible to say, of course. I generally favor generality, so if its not to omuch more complex, I think its a good thing. However, unless you plan on enumerating the set of filters and triggers allowed in a package, I suspect that the general one won't be that much more complex. Saying "only send me notifies once an hour on alternate thursdays, if the value of the foo parameter is bar" is going to be complex in any case. I think the Moran draft is a good start, but not quite there yet. Part of the problem is scope. What exactly do we wish to support, in terms of filter/trigger policies? You don't want to boil the ocean with the first version. I think that, if we go for a general solution, we should do JUST enough to meet the *real* problems people are trying to solve, and we can make it extensible to handle more down the road. I would postulate that, realistically, the scope of triggers is going to be limited to: * waiting for a certain event to occur within a certain state, * waiting for a certain variable to take a certain value Things like the mathematical and temporal conditions are interesting, but I doubt would really be used in practice. Similarly, the filtering conditions are probably limited to asking for notifications to contain only certain variables. With a well scoped set of requirements, as I have proposed above, I think you can get a pretty straightforward language that would apply cross-packages. I'll also note that, if we assume that all notifications contain XML as bodies (I know its not true, bear with me), then the filter could possibly be an XSLT document. This might be overkill. For things that are not XML, you'd need to specify an XML mapping for it to work (yuck). Just a thought. So, I would propose that, in order to make progress on this issue, we agree upon a realistic scope for these things, in terms of requirements on filters and triggers, and then we can see how complex the general-purpose filtering language is. -Jonathan R. Sriram Parameswar wrote: > Adam, > > I agree with you on the fact that each event package should define its > own filters. I would tend to say that using different events for > filtering would not work, simply because we can filter on various > different criteria. However there was a draft that attempted a generic > filtering architecture (draft-moran-sipping-filter-arch-00.txt), which > did not get very much traction. > > Maybe the working group could take a look at that draft one more time? > > Thx, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > -----Original Message----- > From: Adam Roach [ mailto:adam@dynamicsoft.com > ] > Sent: Tuesday, June 25, 2002 10:51 AM > To: Robert Sparks; Parameswar, Sriram [NGC:B615:EXCH] > Cc: sip@ietf.org > Subject: Event Filtering > > > >>-----Original Message----- >>From: Robert Sparks [ mailto:rsparks@dynamicsoft.com > > ] > >>We're seeing a similar kind of pressure in other event packages. Often > > >>its called event-filtering. I'm still not sure whether a >>filter approach >>or a separate event is the better approach. In any case, this problem >>is not an event refer specific one, so we shouldn't solve it in this >>draft. > > > We left this up to event packages in sip-events on purpose. (We say > the SUBSCRIBE bodies can define filters and throttles, but don't > define specifics). I don't beleive that it is even possible to define > a useful general-purpose filtering mechanism, precisely because the > variety of things you'll want to filter based on varies widely, and > will need to be tailored to the exact type of state being conveyed. > > If I'm wrong, please make a proposal for such a mechanism. > > /a > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com ------_=_NextPart_001_01C21EB6.0C2270A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: Event Filtering

Jonathan,

Looking at it from a requirements perspective, we = could trim it down to a small set. We could start with something as = small as:

        * Rate of = Notification - here all the subscriber says is - do not exceed 'x' = notifications per minute.
        * Content = of Notification - they subscriber indicates support for full or = partial/incremental notification bodies.

          = This would help UA's that can handle only full event notification = documents and do not have the computation power

          to = deal with incremental notifications. Support for content indirection = could be optional here - this would allow

          a = UA to indicate that it is capable of retrieving event notification = bodies using an alternate mechanism like
          = HTTP.

Any other filtering requirements may be treated as = extensions by individual event packages. I strongly support the use of = XML for the filter language.

Thanks,

Sriram

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


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 27, 2002 2:59 AM
To: Parameswar, Sriram [NGC:B615:EXCH]
Cc: 'Adam Roach'; Robert Sparks; sip@ietf.org
Subject: Re: [Sip] RE: Event Filtering


I acutally like the idea of a more generic = filter/trigger mechanism that
would apply cross-packages. The tradeoff is one of = generality vs.
complexity. The single mechanism will be more = general, but probably more
complex than an event-specific one. How much more = complex? Impossible to
say, of course. I generally favor generality, so if = its not to omuch
more complex, I think its a good thing. However, = unless you plan on
enumerating the set of filters and triggers allowed = in a package, I
suspect that the general one won't be that much more = complex. Saying
"only send me notifies once an hour on = alternate thursdays, if the value
of the foo parameter is bar" is going to be = complex in any case.

I think the Moran draft is a good start, but not = quite there yet. Part
of the problem is scope. What exactly do we wish to = support, in terms of
filter/trigger policies? You don't want to boil the = ocean with the first
version. I think that, if we go for a general = solution, we should do
JUST enough to meet the *real* problems people are = trying to solve, and
we can make it extensible to handle more down the = road.

I would postulate that, realistically, the scope of = triggers is going to
be limited to:

   * waiting for a certain event to occur = within a certain state,
   * waiting for a certain variable to = take a certain value

Things like the mathematical and temporal conditions = are interesting,
but I doubt would really be used in practice. = Similarly, the filtering
conditions are probably limited to asking for = notifications to contain
only certain variables.

With a well scoped set of requirements, as I have = proposed above, I
think you can get a pretty straightforward language = that would apply
cross-packages.

I'll also note that, if we assume that all = notifications contain XML as
bodies (I know its not true, bear with me), then the = filter could
possibly be an XSLT document. This might be = overkill. For things that
are not XML, you'd need to specify an XML mapping = for it to work (yuck).
  Just a thought.

So, I would propose that, in order to make progress = on this issue, we
agree upon a realistic scope for these things, in = terms of requirements
on filters and triggers, and then we can see how = complex the
general-purpose filtering language is.

-Jonathan R.


Sriram Parameswar wrote:
> Adam,
>
> I agree with you on the fact that each event = package should define its
> own filters. I would tend to say that using = different events for
> filtering would not work, simply because we can = filter on various
> different criteria. However there was a draft = that attempted a generic
> filtering architecture = (draft-moran-sipping-filter-arch-00.txt), which
> did not get very much traction.
>
> Maybe the working group could take a look at = that draft one more time?
>
> Thx,
>
> Sriram
>
> __________________________________________ =
> Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax: = 972-684-3986
> Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com
>
>
> -----Original Message-----
> From: Adam Roach [ mailto:adam@dynamicsoft.com
> <mailto:adam@dynamicsoft.com>= ]
> Sent: Tuesday, June 25, 2002 10:51 AM
> To: Robert Sparks; Parameswar, Sriram = [NGC:B615:EXCH]
> Cc: sip@ietf.org
> Subject: Event Filtering
>
>
>
>>-----Original Message-----
>>From: Robert Sparks [ mailto:rsparks@dynamicsoft.com
>
> <mailto:rsparks@dynamicsoft.com> ]
>
>>We're seeing a similar kind of pressure in = other event packages. Often
>
>
>>its called event-filtering. I'm still not = sure whether a
>>filter approach
>>or a separate event is the better approach. = In any case, this problem
>>is not an event refer specific one, so we = shouldn't solve it in this
>>draft.
>
>
> We left this up to event packages in sip-events = on purpose. (We say
> the SUBSCRIBE bodies can define filters and = throttles, but don't
> define specifics). I don't beleive that it is = even possible to define
> a useful general-purpose filtering mechanism, = precisely because the
> variety of things you'll want to filter based = on varies widely, and
> will need to be tailored to the exact type of = state being conveyed.
>
> If I'm wrong, please make a proposal for such a = mechanism.
>
> /a
>
>


--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ = 07936
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com

------_=_NextPart_001_01C21EB6.0C2270A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 13:21:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08196 for ; Fri, 28 Jun 2002 13:21:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15583 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 13:22:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13343; Fri, 28 Jun 2002 12:53:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13316 for ; Fri, 28 Jun 2002 12:53:00 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06482 for ; Fri, 28 Jun 2002 12:52:13 -0400 (EDT) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5SGqjrU019047; Fri, 28 Jun 2002 18:52:46 +0200 (MEST) Received: from lmf.ericsson.se (arbru3m14.eu.ericsson.se [164.48.163.15]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g5SGqeqn015754; Fri, 28 Jun 2002 18:52:42 +0200 (MET DST) Message-ID: <3D1C947B.1342557F@lmf.ericsson.se> Date: Fri, 28 Jun 2002 19:53:15 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Hogg CC: Flemming Andreasen , Jonathan Rosenberg , Mark Watson , sip@ietf.org, Bob Penfield Subject: Re: [Sip] Local vs Remote ringback on 180 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Chris, Thanks for your comments! > >Yes. My UAC MAY choose to stop forwarding any possible early media > >(again, without changing the state of the session) to the caller, and > > >instead generate local ringback, if 180 without SDP is received. My > >proposal was that a 180 without SDP should be used to indicate that > the > >UAS is currently not sending any early media (announcement or early > >media) on the session, and that the UAC therefore MAY choose to > generate > >local ringback. > > [CH] I think the problem you have here is that you are creating a > difference between session state and the caller's perceived view of > the session state and this is confusing the discussion. I don't think > its' quite right to say that a 180 without SDP is not sending any > early media, however I think that the 180 could still give the UAC the > option of playing early media as currently defined. [CHH] The UAS may still send early media, but since it sends 180 without SDP it allows the UAC to generate local ringback tone, so the UAC now can assume that it can "cut" the early media from the caller during that time. If the UAS does NOT want the UAC to generate local ringback, the 180 would also contain SDP (the same SDP which was used in the 183 to establish the early dialog, ie the SDP is not a new offer/answer - simply a ringback "indicator"). > Let me have a go at trying to understand your solution. As I > understand it, when a Manyfolks/preconditions call setup is underway, > if you send a 180 Ringing after the preconditions have been met then > (according to the rules of offer-answer and SIP specific rules > surrounding offer-answer) then the 180 Ringing will normally not > contain any SDP. In this case, your proposal would mean that in the > Manyfolks call setup scenario the 180 Ringing would always result in > local ringing. Your implementation would then treat receipt of the > 200 OK(INVITE) as the trigger to switch off local ringing and back to > media (the session for which is already setup). > > In a non-manyfolks call / non 100 REL / basic call setup flow the 180 > Ringing may or may not contain SDP. If it contains SDP (which is a > pre-answer) then your implementation would play out early media, if it > does not contain SDP then local ringing may be played instead. [CHH] My case is when the UAC FIRST receive 183 with SDP, with possible early media, and THEN receives 180 without SDP. My question is what the UAC does when it receives that 180? I know bis says that the UAC MAY play ringback, but the problem is that since it is a MAY it means some servers may still send early ringback, while other servers actually want me to generate local ringback (and they will not send early media during that time, EVEN if the are "allowed" to from a session state point of view), and THAT is what I am trying to get a clarification on :) Another issue here is if have a early dialog established in this case in the first place. Yes, the 183, and/or 180, may contain SDP, but since they are not sent reliably can they SDP be treated like an answer???? Bis-09 says that the answer MUST be sent reliable, which in a basic SIP node is in the 200 for INVITE... > Is this a fair analysis of your solution? If this is the case, then I > don't think there are any changes needed to SIP to be able to support > this. [CHH] Again, I don't think I am proposing any changes in SIP - all I want is a general clarification on what is already written in bis- and the ISUP/SIP mapping drafts :) >I don't think that is a good idea. Just because the UAS sends UPDATE, > >and stop sending media, it doesn't mean the called party has been > >reached. I think the 180 shall, the way it is defined today, be the > >ringback "trigger". > > [CH] The call flow I had in mind was something like: > > <-----180 Ringing > <----UPDATE(SDP offer) > -----200 OK(UPDATE) (SDP answer) > Where the UPDATE and 200 OK(UPDATE) are being used to alter the > session state (effectively signalling that the direction of the media > (from the UAS point of view) is now a=inactive or a=recvonly. The 180 > Ringing is still sent but the additional messages allow the UAS to > signal to the UAC that the far-end media is on hold. The > implementation can then do what it likes (e.g. play local ringing / > play a local announcement etc). So, assuming we DO use UPDATE for this, I have a couple of questions on that: 1. When the called party answers, the UAS has to send a second UPDATE, to allow media again, because to my understanding it is not allowed to send a new offer in the 200 for INVITE? In that case we are actually talking about TWO UPDATE transactions, instead of one, for this purpose... 2. If the called party answers before the second, or first AND second, UPDATE transactions have been completed, does the UAS have to "buffer" the 200 for INVITE until the the UPDATE transactions are completed (since they both contain offers/answers)? OR, is the UAS in this scenario allowed to send 200 for INVITE even if there are active UPDATE transactions with offers/answers? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 14:40:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13408 for ; Fri, 28 Jun 2002 14:40:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21085 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 14:41:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18395; Fri, 28 Jun 2002 14:07:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18365 for ; Fri, 28 Jun 2002 14:07:40 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10955 for ; Fri, 28 Jun 2002 14:06:54 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5SI72LH008528; Fri, 28 Jun 2002 11:07:02 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADG95274; Fri, 28 Jun 2002 11:07:08 -0700 (PDT) From: "Cullen Jennings" To: "Jonathan Rosenberg" , Date: Fri, 28 Jun 2002 11:08:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3D1BEEE5.5010005@dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] refreshing NAT binding for SIP with UDP registrations Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit One point about UDP registrations, I don't know if you really need to send a true registration, you can just send any message that creates minimal load on the proxy. For example the UA could send a single CRLF to the proxy. The proxy could have some code to silently ignore any message that is clearly too short to be a valid SIP message. Obviously this won't work in the cases where the UA sends to a proxy inside the NAT then the proxy sends to a another proxy outside the NAT. It also has the problems with no response so you don't know if the message made it to the NAT or not. Do folks see this as an ideal worth pursing or a really bad idea that we should suggest people don't do? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 15:00:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14712 for ; Fri, 28 Jun 2002 15:00:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22454 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 15:00:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20336; Fri, 28 Jun 2002 14:34:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20309 for ; Fri, 28 Jun 2002 14:34:10 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12836 for ; Fri, 28 Jun 2002 14:33:24 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5SIXTLH003941; Fri, 28 Jun 2002 11:33:29 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADG96370; Fri, 28 Jun 2002 11:33:35 -0700 (PDT) From: "Cullen Jennings" To: "Pete Cordell" , Cc: "Jonathan Rosenberg" Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat Date: Fri, 28 Jun 2002 11:35:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <004601c21e84$8d200f00$0200000a@tkw> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My read of the SPAN document was it did not even represent consensus of the design team much less the midcom WG. Why should references to TURN or SPAM be changed to just SPAN? Thanks, Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Pete > Cordell > Sent: Friday, June 28, 2002 2:16 AM > To: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat > > > Sounds reasonable except that to be in line with the pre-midcom / midcom > work all references to TURN should be to SPAN (Simple Protocol for > Augmenting NATs), at least for the time being. > > For those that are interested, a candidate for SPAN is at: > > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt > > But be advised that this is iteration 1 and so subject to change. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: > Sent: 28 June 2002 06:06 > Subject: [Sip] Proposed change in draft-ietf-sip-nat > > > > Folks, > > > > I would like to propose a change in draft-ietf-sip-nat. > > > > Right now, this document specifies two very independent and orthogonal > > things. One of them is the rport parameter. This is a Via param that > > makes sure that the SIP response gets routed back to the source IP and > > port where the request came from. Without it, SIP over UDP doesn't work > > through any NATs. It allows SIP to work like most other protocols in > > terms of its port usage. I think its uncontroversial and should move > > forward as is. > > > > THe other aspect is the Translate header. Its aimed at making > > registrations work through NAT. However, there are several problems with > > the Translate header right now: > > > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN, which > > would allow for incoming INVITEs through NAT without any SIP specific > > extensions. > > > > 2. It tries to optimize for the full-cone case, by including a parameter > > that indicates whether the client is behind a full-cone or symmetric > > NAT. I would rather not pollute SIP with this kind of NAT-specific > > stuff; rather, relegate it to STUN/TURN. > > > > 3. UDP registrations through NAT are really troublesome. They require > > very frequent re-registrations to maintain the binding (under a minute). > > This poses a serious load. If you have to use UDP, a STUN or TURN > > solution is much better, since refreshes of the NAT bindings would occur > > through those protocols, rather than SIP, and they scale much better. > > So, if you consider TCP (which works even better still, since you don't > > need to refresh the registration in order to keep the binding active), > > the problem is not really translating the contact header as it is TCP > > connection reuse for incoming requests. Indeed, the same problem occurs > > in record-routing - you want to be able to specify to your peer to reuse > > the connection for incoming requests. Thats not even a nat-specific > > thing; its just a capability that, if we had a better story on, would be > > useful for NAT. > > > > > > As a result, I would propose that draft-ietf-sip-nat move forward with > > just the rport stuff, and we look at the registration problem > > separately. I would like a solution for SIP that didn't depend on > > STUN/TURN, but I have convinced myself that this solution needs to be > > TCP-based, and that it is best viewed as a problem of connection reuse. > > ROhan has posted a requirement draft on that topic. > > > > Flame away.... > > > > -Jonathan R. > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 15:06:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15068 for ; Fri, 28 Jun 2002 15:06:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23513 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 15:07:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21265; Fri, 28 Jun 2002 14:43:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21237 for ; Fri, 28 Jun 2002 14:43:12 -0400 (EDT) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13614 for ; Fri, 28 Jun 2002 14:42:26 -0400 (EDT) Message-ID: <20020628184310.22301.qmail@web11603.mail.yahoo.com> Received: from [207.46.137.9] by web11603.mail.yahoo.com via HTTP; Fri, 28 Jun 2002 11:43:10 PDT Date: Fri, 28 Jun 2002 11:43:10 -0700 (PDT) From: Sean Olson Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations To: Cullen Jennings , Jonathan Rosenberg , sip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This seems to have too many holes. However, it *might* be useful to define a lightweight SIP keep-alive mechanism. /sean --- Cullen Jennings wrote: > > One point about UDP registrations, I don't know if > you really need to send a > true registration, you can just send any message > that creates minimal load > on the proxy. For example the UA could send a single > CRLF to the proxy. The > proxy could have some code to silently ignore any > message that is clearly > too short to be a valid SIP message. Obviously this > won't work in the cases > where the UA sends to a proxy inside the NAT then > the proxy sends to a > another proxy outside the NAT. It also has the > problems with no response so > you don't know if the message made it to the NAT or > not. > > Do folks see this as an ideal worth pursing or a > really bad idea that we > should suggest people don't do? > > Cullen > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 16:58:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21562 for ; Fri, 28 Jun 2002 16:58:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01535 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 16:58:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29238; Fri, 28 Jun 2002 16:25:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29201 for ; Fri, 28 Jun 2002 16:25:53 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19800 for ; Fri, 28 Jun 2002 16:25:06 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5SKPBYH024592; Fri, 28 Jun 2002 16:25:11 -0400 (EDT) Message-ID: <3D1CC624.5050304@dynamicsoft.com> Date: Fri, 28 Jun 2002 16:25:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Pete Cordell , sip@ietf.org Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > My read of the SPAN document was it did not even represent consensus of > the > design team much less the midcom WG. Correct. > > Why should references to TURN or SPAM be changed to just SPAN? More importantly, this issue is totally irrelevant to this thread. Draft-ietf-sip-nat will have references to neither TURN, nor SPAN, nor STUN. Connection reuse has nothing to do with it either. THe only place TURN/SPAN/STUN should show up is the nat-scenarios document. That one is on the backburner until these issues are sorted out, and is not what this thread is about in any case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 17:07:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22143 for ; Fri, 28 Jun 2002 17:07:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03043 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 17:08:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00105; Fri, 28 Jun 2002 16:32:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00069 for ; Fri, 28 Jun 2002 16:32:40 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20226 for ; Fri, 28 Jun 2002 16:31:54 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5SKW8YH024598; Fri, 28 Jun 2002 16:32:08 -0400 (EDT) Message-ID: <3D1CC7C3.6090802@dynamicsoft.com> Date: Fri, 28 Jun 2002 16:32:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] refreshing NAT binding for SIP with UDP registrations References: <20020628184310.22301.qmail@web11603.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The holes that this "CRLF approach" has are similar to some of the generic problems of STUN, which I would prefer be kept isolated there. THe main one really is that the frequency of the refreshes is dependent on the binding lifetime; that is not generally known, either to the UA, or the registrar. TCP works better there. Because TCP connections have an explicit teardown, they are held in NATs for a long time without keepalives. There is also the needless network traffic from these 1 byte UDP packets flying around (with 8 bytes UDP, 20 bytes IPv4 headers), a huge waste. -Jonathan R. Sean Olson wrote: > This seems to have too many holes. > However, it *might* be useful to define a > lightweight SIP keep-alive mechanism. > > /sean > > --- Cullen Jennings wrote: > >>One point about UDP registrations, I don't know if >>you really need to send a >>true registration, you can just send any message >>that creates minimal load >>on the proxy. For example the UA could send a single >>CRLF to the proxy. The >>proxy could have some code to silently ignore any >>message that is clearly >>too short to be a valid SIP message. Obviously this >>won't work in the cases >>where the UA sends to a proxy inside the NAT then >>the proxy sends to a >>another proxy outside the NAT. It also has the >>problems with no response so >>you don't know if the message made it to the NAT or >>not. >> >>Do folks see this as an ideal worth pursing or a >>really bad idea that we >>should suggest people don't do? >> >>Cullen >> >> >>_______________________________________________ >>Sip mailing list >>https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP >>Protocol >>Use sip-implementors@cs.columbia.edu for questions >>on current sip >>Use sipping@ietf.org for new developments on the >>application of sip > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jun 28 20:58:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00803 for ; Fri, 28 Jun 2002 20:58:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17759 for sip-archive@odin.ietf.org; Fri, 28 Jun 2002 20:59:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16605; Fri, 28 Jun 2002 20:29:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16575 for ; Fri, 28 Jun 2002 20:29:15 -0400 (EDT) Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com [192.84.19.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00091 for ; Fri, 28 Jun 2002 20:28:27 -0400 (EDT) Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25396 for ; Fri, 28 Jun 2002 17:27:45 -0700 (PDT) Received: from acm.org (ronin.8x8.com [192.84.17.139]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id RAA23616 for ; Fri, 28 Jun 2002 17:27:44 -0700 (PDT) Message-ID: <3D1CFEFE.8040909@acm.org> Date: Fri, 28 Jun 2002 17:27:42 -0700 From: Marc Petit-Huguenin Organization: 8x8, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 X-Accept-Language: en MIME-Version: 1.0 To: IETF SIP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Characters # in SIP URL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The text in rfc2543bis-09 at line 5700 says: "The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped." The characters # is authorized by the BNF in RFC2806, but not in RFC2543bis, so I guess that this means that the # must be escaped. But this seems not compatible with RFC2543 that explicitely authorizes # in the BNF. So must # be escaped or not? Thanks. -- Marc Petit-Huguenin Home: mailto:marc@petit-huguenin.org Work: mailto:petithug@8x8.com "So much to do and so little time" The Joker - Batman (The Movie) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Ranjit=20 Avasarala
Sent: Tuesday, June 25, 2002 5:30 AM
To: = sip@ietf.org
Cc: = sip-implementors@cs.columbia.org
Subject:=20 [Sip] subscribe - event package

Hi
 
    This is with ref = to=20 draft-ietf-sip-events-05.txt
 
    I have a doubt in = the=20 implementation of events template package. What should this package = contain.=20 Say I am implementing the call waiting feature on Server
 
Now A calls B and B is busy. So i get = a Busy Here=20 msg to A. Then I can SUBSCRIBE a event on my server and ask it to = NOTIFY me=20 when B is Free.
 
so any suggestions?
 
Thanks
Ranjit