From sip-bounces@ietf.org Sat Oct 01 15:03:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELme8-0005KT-KX; Sat, 01 Oct 2005 15:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELme5-0005FD-BC; Sat, 01 Oct 2005 15:03:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14083; Sat, 1 Oct 2005 15:03:37 -0400 (EDT) Received: from bay104-f1.bay104.hotmail.com ([65.54.175.11] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELmmB-0005Rj-N5; Sat, 01 Oct 2005 15:12:05 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 Oct 2005 12:03:29 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Sat, 01 Oct 2005 19:03:29 GMT X-Originating-IP: [65.49.203.195] X-Originating-Email: [whitakercd@hotmail.com] X-Sender: whitakercd@hotmail.com In-Reply-To: <02265A6A-15FF-413D-98C1-12004A238D46@softarmor.com> From: "Chris Whitaker" To: dean.willis@softarmor.com, frank.derks@philips.com Subject: Re: [Sip] Connected Destination in SIP Date: Sat, 01 Oct 2005 15:03:29 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Oct 2005 19:03:29.0952 (UTC) FILETIME=[CFA01A00:01C5C6BA] X-Spam-Score: 0.9 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >From: Dean Willis >To: Frank Derks >CC: sip@ietf.org, sip-bounces@ietf.org >Subject: Re: [Sip] Connected Destination in SIP >Date: Thu, 29 Sep 2005 11:48:25 -0500 > > >On Sep 29, 2005, at 9:35 AM, Frank Derks wrote: > >> >>What is the real problem? >> > >The real problem is that: > >1) The call could go to some agent with whom you do not have a pre- >established relationship, making it a "general public" scope problem. > Not having read any of the supporting drafts I may be wasting time with this Q, but: Why is it someone you do not have a pre-established relationship with? Is there not a chain of trust? If A calls B and forwards to C, A need not trust that C is who he claims to be A need only trust B and B assert that C is really C. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 01 16:31:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELo14-0005z2-JR; Sat, 01 Oct 2005 16:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELo11-0005yr-P7; Sat, 01 Oct 2005 16:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17982; Sat, 1 Oct 2005 16:31:24 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELo94-0007Rh-NU; Sat, 01 Oct 2005 16:39:52 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1128198671!8020935!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 23310 invoked from network); 1 Oct 2005 20:31:11 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-4.tower-120.messagelabs.com with SMTP; 1 Oct 2005 20:31:11 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 4336CAB7000FAE18; Sat, 1 Oct 2005 16:31:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Connected Destination in SIP Date: Sat, 1 Oct 2005 15:31:09 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0BBAC@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Connected Destination in SIP Thread-Index: AcXGu2HFgTglFrfPS+yqGGfFjUqrTwACtYnw From: "Dolly, Martin C, ALABS" To: "Chris Whitaker" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org this is simple, relay the ID of the connected party backward....this is all in a semi-trusted domain...we are not talking about the "OPEN" internet. If the IETF can not address this need...(reality check... vendors...services providers need this....so chill paul) please...some sanity.. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Chris Whitaker > Sent: Saturday, October 01, 2005 3:03 PM > To: dean.willis@softarmor.com; frank.derks@philips.com > Cc: sip@ietf.org; sip-bounces@ietf.org > Subject: Re: [Sip] Connected Destination in SIP >=20 >=20 >=20 >=20 >=20 > >From: Dean Willis > >To: Frank Derks > >CC: sip@ietf.org, sip-bounces@ietf.org > >Subject: Re: [Sip] Connected Destination in SIP > >Date: Thu, 29 Sep 2005 11:48:25 -0500 > > > > > >On Sep 29, 2005, at 9:35 AM, Frank Derks wrote: > > > >> > >>What is the real problem? > >> > > > >The real problem is that: > > > >1) The call could go to some agent with whom you do not have a pre-=20 > >established relationship, making it a "general public" scope problem. > > >=20 > Not having read any of the supporting drafts I may be wasting=20 > time with this=20 > Q, but: > Why is it someone you do not have a pre-established relationship with? > Is there not a chain of trust? >=20 > If A calls B and forwards to C, A need not trust that C is=20 > who he claims to=20 > be A need only trust B and B assert that C is really C. >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Oct 02 15:24:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM9RJ-0008Rl-Uj; Sun, 02 Oct 2005 15:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM9RH-0008RS-LX for sip@megatron.ietf.org; Sun, 02 Oct 2005 15:23:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29296 for ; Sun, 2 Oct 2005 15:23:58 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EM9Zc-0000Rc-3Y for sip@ietf.org; Sun, 02 Oct 2005 15:32:36 -0400 Received: by zproxy.gmail.com with SMTP id n1so180712nzf for ; Sun, 02 Oct 2005 12:23:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=ZKW+h/yeavHaESuhPMDC9nEN/gzn9zzX9r6sIplLmM4hh9icEfPnxIaFy78IaWvSvLx2T8YWAMo1iEHaJny1kvgu5fV9KTXF5k7xErI1izlZfaPVzkgzMQ/3/aB+nw5JVl4Y//9q3r/lJcnlpzigD73JQNxHzanVTTBKPTPlLWs= Received: by 10.36.126.9 with SMTP id y9mr3925772nzc; Sun, 02 Oct 2005 12:23:43 -0700 (PDT) Received: by 10.37.22.70 with HTTP; Sun, 2 Oct 2005 12:23:43 -0700 (PDT) Message-ID: <8320074d0510021223j7d2af0e7yfecec6e220a23cc9@mail.gmail.com> Date: Mon, 3 Oct 2005 00:53:43 +0530 From: Rohan Sen To: SIP MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Sip] Any help would be highly appreciated X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Sen List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263145837==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1263145837== Content-Type: multipart/alternative; boundary="----=_Part_3369_28231742.1128281023440" ------=_Part_3369_28231742.1128281023440 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When a proxy server encounters a transport error when forwarding should it send a 500 response upstream ? What message should a user agent (or a proxy) send to a registrar to find out about the eixtsing bindings ? How, when and why should a stateful proxy transition to state less operatio= n and for that does it need to remain stateless for the rest of the transaction ? When it says that a proxy may arbitrarily group the target set and then do parallel processing of the addresses in a single group. Is it right to assume that such grouping can b= e done based on q parameter ? How can a proxy determine the transport used to connect to the next proxy downstream ? In Selection of a next hop, for a particular request-URI can that be configured manually by means other than SIP or if using SIP protocol itself= , how can that be done ? How can a proxy ensure that all proxies which may be traversed by the request (say INVITE) are loose routers ? An element is supposed to forward the SIP message to be sent directly to th= e transport layer in case the transaction layer is no longer available. When can exactly a transaction be not available ? Can it be that it has crashed for some reason ? Will there be any manifestation of any behavioral change for that element in which the transaction in progress is no more available = ? What exactly is a local outbound proxy ? Any light on these above issues would be highly appreciated. -- thanks, Rohan Sen ------=_Part_3369_28231742.1128281023440 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable When a proxy server encounters a transport error when forwarding should it = send a 500 response upstream ?

What message should a user agent (or a proxy) send to a registrar to find o= ut about the eixtsing bindings ?

How, when and why should a stateful proxy transition to state less operation and for that does it need to remain stateless for the rest of the transaction ?

When it says that a proxy may arbitrarily group the target set and then do = parallel processing of the
addresses in a single group. Is it right to assume that such grouping can b= e done based on q parameter ?

How can a proxy determine the transport used to connect to the next proxy d= ownstream ?

In Selection of a next hop, for a particular request-URI can that be configured manually by means other than SIP or if using SIP protocol itself, how can that be done ?

How can a proxy ensure that all proxies which may be traversed by the reque= st (say INVITE) are loose routers ?

An element is supposed to forward the SIP message to be sent directly to the transport layer in case the transaction layer is no longer available. When can exactly a transaction be not available ? Can it be that it has crashed for some reason ? Will there be any manifestation of any behavioral change for that element in which the transaction in progress is no more available ?

What exactly is a local outbound proxy ?

Any light on these above issues would be highly appreciated.


--
thanks,
Rohan Sen ------=_Part_3369_28231742.1128281023440-- --===============1263145837== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1263145837==-- From sip-bounces@ietf.org Mon Oct 03 00:04:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMHZ8-00068N-Ef; Mon, 03 Oct 2005 00:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMHZ6-000675-Fx; Mon, 03 Oct 2005 00:04:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16350; Mon, 3 Oct 2005 00:04:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMHhT-0001Zl-FD; Mon, 03 Oct 2005 00:13:17 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2005 21:04:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,166,1125903600"; d="scan'208"; a="12116364:sNHT24711676" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9344KQl006507; Mon, 3 Oct 2005 00:04:20 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 00:04:19 -0400 Received: from [192.168.1.100] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 00:04:19 -0400 Message-ID: <4340ADC1.2050308@cisco.com> Date: Mon, 03 Oct 2005 00:04:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dolly, Martin C, ALABS" Subject: Re: [Sip] Connected Destination in SIP References: <28F05913385EAC43AF019413F674A0170DE0BBAC@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0BBAC@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2005 04:04:19.0397 (UTC) FILETIME=[876A3750:01C5C7CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: frank.derks@philips.com, Chris Whitaker , sip@ietf.org, sip-bounces@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree that this is needed, and I believe that what you are basically describing - convey the called party identity in the reverse direction, can be made to work and work securely against a specific (albeit limited) set of attacks. What Jon's document has clearly illustrated is that, should an attacker maliciously forward a request (i.e., by provisioning false forwarding information into a proxy), there is simply no way to detect or prevent this attack. So, we should not even try. The attack that I am more worried about is that user A calls user B, and the call is forwarded to C (as it should have been). It arrives at C's UA, but C, being a prankster, inserts a faked called-party-identity into the response, saying that they are D, and forwards it upstream. A now mistakenly thinks they've reached D, when they've actually reached C. This attack can be prevented under certain circumstances. The easy way to provide this functionality is the following. When user C registers, they do so over a tls connection to their proxy. Authentication is done, so their proxy knows C's identity. When the 200 OK to the invite arrives from C at C's proxy, C's proxy inserts some kind of identifying header containing C's identity. Of course, the proxy also removes any existing identity header if one was present. This is basically the analogous mechanism to P-asserted-ID, but in the reverse direction. Slightly better, I think, is the inverse of the sip-identity mechanism. The UAS (user C), would modify the To header field in the 200 OK response, to contain its actual identity. User C's proxy would add a signature to this, draft-ietf-sip-identity style, if it agrees that the called party had this identity. The reverse sip-identity approach doesn't deal with the fundamental forwarding problem; the UAC won't have any way to know whether its call was really intended to reach joe@goodprovider.com or joe@badprovider.com, both of which could provide signatures over the response. Indeed, the endpoint itself could sign the response using any domain it had certs for. However, the endpoint could not claim that they were joe@goodprovider.com. They could not impersonate another user that the caller knows a SIP URI for. If C's domain supports the mechanism, it could strip any Identity information in the response, and thus prevent attacks where the endpoint acquires domains like witehouse.com and signs the response george.bush@witehouse.com. The net/net is that there definitely is a clear need for this connected party identity from a functional perspective, and we should seek to provide a mechanism that we can secure to the greatest extent possible. That doesnt prevent all of the attacks, but nothing ever can. So, rather than the perfect being the enemy of the good, we should strive to do something here rather than nothing. Thanks, Jonathan R. Dolly, Martin C, ALABS wrote: > this is simple, relay the ID of the connected party backward....this is > all in a semi-trusted domain...we are not talking about the "OPEN" > internet. If the IETF can not address this need...(reality check... > vendors...services providers need this....so chill paul) > > please...some sanity.. > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>Chris Whitaker >>Sent: Saturday, October 01, 2005 3:03 PM >>To: dean.willis@softarmor.com; frank.derks@philips.com >>Cc: sip@ietf.org; sip-bounces@ietf.org >>Subject: Re: [Sip] Connected Destination in SIP >> >> >> >> >> >> >>>From: Dean Willis >>>To: Frank Derks >>>CC: sip@ietf.org, sip-bounces@ietf.org >>>Subject: Re: [Sip] Connected Destination in SIP >>>Date: Thu, 29 Sep 2005 11:48:25 -0500 >>> >>> >>>On Sep 29, 2005, at 9:35 AM, Frank Derks wrote: >>> >>> >>>>What is the real problem? >>>> >>> >>>The real problem is that: >>> >>>1) The call could go to some agent with whom you do not have a pre- >>>established relationship, making it a "general public" scope problem. >>> >> >>Not having read any of the supporting drafts I may be wasting >>time with this >>Q, but: >>Why is it someone you do not have a pre-established relationship with? >>Is there not a chain of trust? >> >>If A calls B and forwards to C, A need not trust that C is >>who he claims to >>be A need only trust B and B assert that C is really C. >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Mon Oct 03 02:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMK9h-0000NS-EE; Mon, 03 Oct 2005 02:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMK9g-0000N0-0m; Mon, 03 Oct 2005 02:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06619; Mon, 3 Oct 2005 02:50:30 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMKI5-00053G-F5; Mon, 03 Oct 2005 02:59:14 -0400 Received: from [192.168.2.27] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j936t7tD028654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2005 01:55:07 -0500 Message-ID: <4340D4A9.9090702@softarmor.com> Date: Mon, 03 Oct 2005 01:50:17 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dolly, Martin C, ALABS" Subject: Re: [Sip] Connected Destination in SIP References: <28F05913385EAC43AF019413F674A0170DE0BBAC@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0BBAC@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: frank.derks@philips.com, Chris Whitaker , sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dolly, Martin C, ALABS wrote: > this is simple, relay the ID of the connected party backward....this is > all in a semi-trusted domain...we are not talking about the "OPEN" > internet. If the IETF can not address this need...(reality check... > vendors...services providers need this....so chill paul) Sorry, Martin! This IS the IETF. We ARE talking about the open Internet (that's the I in IETF, right? They didn't change the acronym to "Interiornet" or something when I wasn't looking?). In general, it's not in our charter to really consider something else -- and when we do have to write up something that works in only a small, walled corner of the net, it carries severe "applicability statement" warnings. You want to talk a lot about approaches that only work in a walled garden, you need the ITU. ;-). -- 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 sip-bounces@ietf.org Mon Oct 03 03:37:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMKsx-0002oe-90; Mon, 03 Oct 2005 03:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMKsv-0002oW-Ox; Mon, 03 Oct 2005 03:37:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08332; Mon, 3 Oct 2005 03:37:16 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EML1K-000672-LS; Mon, 03 Oct 2005 03:46:01 -0400 Received: from [192.168.2.27] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j937e1GG028773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2005 02:40:02 -0500 Message-ID: <4340DF30.4080907@softarmor.com> Date: Mon, 03 Oct 2005 02:35:12 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Whitaker Subject: Re: [Sip] Connected Destination in SIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: frank.derks@philips.com, sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Chris Whitaker wrote: >> 1) The call could go to some agent with whom you do not have a pre- >> established relationship, making it a "general public" scope problem. >> > > Not having read any of the supporting drafts I may be wasting time with > this Q, but: > Why is it someone you do not have a pre-established relationship with? > Is there not a chain of trust? > > If A calls B and forwards to C, A need not trust that C is who he claims > to be A need only trust B and B assert that C is really C. Depends on the forwarding mechanism that's used. Problem case: Alice knows Bob. Bob forwards his calls to Jack. Alice calls Bob. Bob's proxy returns a 302, saying "Talk to Jack". Alice sends a new invite to Jack. Jack's proxy sends the request to Jane, because Jack told it to. Jane answers. Alice doesn't know Jane. She doesn't know even know Jack. What does she do? Now, if everybody subscribes to an identity service, and Bob identified Jack to Alice in terms of the identity service, and Jack identified Jane to Alice(which probably required that he 302 her, not proxy her, to Jane) then we have a network of trusted introducers, with the trust anchorprovided externally (in the identity service, or federation of identity services). Works great. Doesn't work with proxies that actually proxy -- works only with redirect servers. This is the model of the SIP "identity" draft that works for response identity. Another variant, and what I think you're proposing: Alice knows Bob. Bob forwards his calls to Jack, who forwards to Jane. Alice calls Bob, who returns her a 302 pointing to Jack, along with a half-key (like X, Z, Z^XY). Bob sends the other half-key (Y, Z, Z^XY) to Jack via some undefined mechanism (the new, undocumented because I just made it up REFERPREP request, perhaps). Alice calls Jack, and uses her half-key to validate Jack (sends him X, he sends back Y, both validate z^XY, proving the other party had the correct other half-key). Now Alice knows Bob sent the other half-key to Jack, and that he's therefore "trusted". Jack also knows Alice is that caller Bob warned him about, and that he can safely pass her on to Jane. Jack forwards to Jane to the same way, and Alice and Jane repeat the key-matching process. Works great. Doesn't work with proxies that actually proxy -- works only with redirect servers. Requires only a small SIP extension, and some careful timing management to make sure that the 3rd party has the introduction-key before the first party talks to them. You can do some slightly fancier crypto to make a session key if you want, or improve the crypto in other ways. And my crypto is probably wrong here anyhow, but we could get a real Zimmerman to fix it. Alternative for trusting people: If you're just willing to assume that all the proxies do the right thing all the time, then you can just believe whatever comes back in the P-Called-Party-ID (but READ the applicability statement, it's a P-header, and not suitable for use in the Internet). But I bet you'll be spending a lot of time talking to high-dollar reverse-charge operators in the Carribbean. Heck, I might install a proxy on my phone just to do that for you, ok? Now, we can work around this a little bit by eliminating network-serviced 302 operations, or by constraining them and forcing the proxy that executes the redirection to check identity for you, or by policing route headers at the edge so that we know that no other proxies got added (which breaks many service and composition models, but it's in IMS release 6, which IMHO, is broken in this regard). And frankly, these are all half-measure hacks with serious side effects. -- 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 sip-bounces@ietf.org Mon Oct 03 08:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOzu-0008GN-IB; Mon, 03 Oct 2005 08:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMOzt-0008Fy-8S; Mon, 03 Oct 2005 08:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23065; Mon, 3 Oct 2005 08:00:44 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EMP8H-0004mg-3z; Mon, 03 Oct 2005 08:09:30 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-126.messagelabs.com!1128340751!7961996!7 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 15606 invoked from network); 3 Oct 2005 12:00:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-14.tower-126.messagelabs.com with SMTP; 3 Oct 2005 12:00:02 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 4336CAB700111C71; Mon, 3 Oct 2005 08:00:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Connected Destination in SIP Date: Mon, 3 Oct 2005 07:00:00 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0BBAE@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Connected Destination in SIP Thread-Index: AcXH5rmMaVZMFlnVS8Wl+ABDrXrqDAAKyhdQ From: "Dolly, Martin C, ALABS" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: frank.derks@philips.com, Chris Whitaker , sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Understand, but... > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, October 03, 2005 2:50 AM > To: Dolly, Martin C, ALABS > Cc: Chris Whitaker; frank.derks@philips.com; sip@ietf.org; > sip-bounces@ietf.org > Subject: Re: [Sip] Connected Destination in SIP >=20 >=20 > Dolly, Martin C, ALABS wrote: > > this is simple, relay the ID of the connected party=20 > backward....this is > > all in a semi-trusted domain...we are not talking about the "OPEN" > > internet. If the IETF can not address this need...(reality check... > > vendors...services providers need this....so chill paul) >=20 > Sorry, Martin! This IS the IETF. We ARE talking about the=20 > open Internet=20 > (that's the I in IETF, right? They didn't change the acronym to=20 > "Interiornet" or something when I wasn't looking?). > In general, it's not in our charter to really consider=20 > something else --=20 > and when we do have to write up something that works in only a small,=20 > walled corner of the net, it carries severe "applicability statement"=20 > warnings. >=20 > You want to talk a lot about approaches that only work in a walled=20 > garden, you need the ITU. ;-). >=20 > -- > Dean >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 03 13:06:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTlp-0000va-Hi; Mon, 03 Oct 2005 13:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTlo-0000vS-Q8 for sip@megatron.ietf.org; Mon, 03 Oct 2005 13:06:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18597 for ; Mon, 3 Oct 2005 13:06:30 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler2.mail.eds.com ([192.85.154.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTuH-00065d-GM for sip@ietf.org; Mon, 03 Oct 2005 13:15:20 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j93H644C028899; Mon, 3 Oct 2005 13:06:06 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j93H58QO029361; Mon, 3 Oct 2005 13:05:08 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j93H58YN029355; Mon, 3 Oct 2005 13:05:08 -0400 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Mon, 3 Oct 2005 13:11:49 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/03/2005 10:05:08 AM, Serialize complete at 10/03/2005 10:05:08 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP IETF Subject: [Sip] Hold SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1904350504==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1904350504== Content-Type: multipart/alternative; boundary="=_alternative 005DB46A8525708F_=" This is a multipart message in MIME format. --=_alternative 005DB46A8525708F_= Content-Type: text/plain; charset="US-ASCII" Hi, As per RFC 3264, user agent indicate hold by sending "sendonly attribute (assuming sendrecv mode stream). So when UAS receives this SDP, it should respond with "recvonly" attribute. But same mechanism can be used by user agent if he wants to play announcement or music to user, so it can send "sendonly" attribute for media stream. I mean if it simply wants one-way connection (this is not hold). For 3PCC (as B2B), if it wants to provide MOH service, how can it differentiate between two SDP because it will play MOH only in the first scenario when user press hold. Is there any other way where user agent can indicate that this is hold scenario and not one-way audio. Thanks, Udit --=_alternative 005DB46A8525708F_= Content-Type: text/html; charset="US-ASCII"
Hi,

As per RFC 3264, user agent indicate hold by sending "sendonly attribute (assuming sendrecv mode stream).
So when UAS receives this SDP, it should respond with "recvonly" attribute.

But same mechanism can be used by user agent if he wants to play announcement or music to user, so it can send "sendonly" attribute for media stream.
I mean if it simply wants one-way connection (this is not hold).

For 3PCC (as B2B), if it wants to provide MOH service, how can it differentiate between two SDP because it will play MOH only in the first scenario when user press hold.

Is there any other way where user agent can indicate that this is hold scenario and not one-way audio.

Thanks,
Udit
--=_alternative 005DB46A8525708F_=-- --===============1904350504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1904350504==-- From sip-bounces@ietf.org Mon Oct 03 18:34:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMYsz-0001Lh-BG; Mon, 03 Oct 2005 18:34:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMYss-0001Ku-L1; Mon, 03 Oct 2005 18:34:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21768; Mon, 3 Oct 2005 18:34:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMZ1R-00033g-JC; Mon, 03 Oct 2005 18:43:01 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EMYsr-0001oz-SG; Mon, 03 Oct 2005 18:34:09 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 03 Oct 2005 18:34:09 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'Communications Resource Priority for the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has approved the following documents: - 'Extending the Session Initiation Protocol Reason Header for Preemption Events ' as a Proposed Standard - 'Communications Resource Priority for the Session Initiation Protocol (SIP) ' as a Proposed Standard These documents are products of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-10.txt Technical Summary The resource priority specification defines two new SIP header fields for call priority in the SIP user agents, namely "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence call handling by SIP user agents, such as telephone gateways and IP telephones, and SIP proxies. The specification extending the SIP reason header to add preemption is a companion to the above specification. When a call is ended in a SIP user agent due to a resource management choice, the extensions in this specification allow communicating specific causes. Working Group Summary The working group had a fair amount of difficulty getting the details of this to its liking, because it had to accomodate goals of groups with current requirements, while still leaving room for generality. The solution of independent namespaces and reuse of the SIP authorization and authentication mechanisms was reviewed and much discussed till consensus was reached. The specification received detailed word-by-word review and comment until consensus was reached, and it required intensive efforts by the chairs and members of the working group, as well as the editor and the responsible AD. Protocol Quality These headers have been implemented by at least one vendor for several namespaces. In some cases, implemented systems associate router resource management with the RP in SIP, somewhat ahead of the scope of IETF design. Note to the RFC Editor draft-ietf-sip-resource-priority: OLD: e.g., in an ISUP IAM message originated by the gateway. NEW: e.g., on an ISUP (ISDN User Part) IAM (Initial Address Message) originated by a SIP gateway with the PSTN. OLD: There should not be a unique namespace for different jurisdictions. This will greatly increase interoperability and reduce development time, and probably reduce future confusion if there is ever a need to map one namespace to another in an interworking function. NEW: There should be a single namespace for all jurisdictions. This will greatly increase interoperability and reduce development time, and probably reduce future confusion if there is ever a need to map one namespace to another in an interworking function. [Only the first sentence is changed, for readability] draft-ietf-sipping-reason-header-for-preemption: Introduction OLD: What is proposed here is extending SIP NEW: What is proposed here is extending SIP [2] [add the citation; it's in the Normative References already] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 02:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMgD7-0003MK-7J; Tue, 04 Oct 2005 02:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMgD2-0003M1-CO for sip@megatron.ietf.org; Tue, 04 Oct 2005 02:23:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29337 for ; Tue, 4 Oct 2005 02:23:26 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMgLd-00070O-RR for sip@ietf.org; Tue, 04 Oct 2005 02:32:23 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j946W8Wi000209 for ; Mon, 3 Oct 2005 23:32:08 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j946VdDw024909 for ; Tue, 4 Oct 2005 01:31:41 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Oct 2005 14:23:15 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0F081D@ZMY16EXM66.ds.mot.com> Thread-Topic: [Sip-implementors] Hold SDP Thread-Index: AcXIUjtVgMEqOJPNQpWIjvU1BzAS9AAWaUaA From: "Avasarala Ranjit-A20990" To: , "SIP Implementors" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF Subject: [Sip] RE: [Sip-implementors] Hold SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Udit You can use c=3DIN IP4 0.0.0.0 to indicate hold in addition to = a-sendonly. Regards Ranjit -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Udit_Goyal@3com.com Sent: Monday, October 03, 2005 10:42 PM To: SIP Implementors Cc: SIP IETF Subject: [Sip-implementors] Hold SDP Hi, As per RFC 3264, user agent indicate hold by sending "sendonly attribute (assuming sendrecv mode stream). So when UAS receives this SDP, it should respond with "recvonly"=20 attribute. But same mechanism can be used by user agent if he wants to play announcement or music to user, so it can send "sendonly" attribute for media stream. I mean if it simply wants one-way connection (this is not hold). For 3PCC (as B2B), if it wants to provide MOH service, how can it differentiate between two SDP because it will play MOH only in the first scenario when user press hold. Is there any other way where user agent can indicate that this is hold scenario and not one-way audio. Thanks, Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 03:06:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMgst-0003b4-SU; Tue, 04 Oct 2005 03:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELX2W-0001GD-IF for sip@megatron.ietf.org; Fri, 30 Sep 2005 22:23:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04113 for ; Fri, 30 Sep 2005 22:23:50 -0400 (EDT) Received: from adsl-66-138-117-27.dsl.wchtks.swbell.net ([66.138.117.27] helo=CUA-MAIL.CUOFAMERICA.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELXAT-0006MD-UE for sip@ietf.org; Fri, 30 Sep 2005 22:32:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 30 Sep 2005 21:23:34 -0500 Message-ID: Thread-Topic: No dual concurrent registration Thread-Index: AcXGLx+bhBdkUx78Rxil5g8L+mpS0A== From: "Richard Logan" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Tue, 04 Oct 2005 03:06:42 -0400 Subject: [Sip] No dual concurrent registration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0419178010==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0419178010== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C62F.1FAD0AE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C62F.1FAD0AE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, We recently implemented a SIP phone system and are using the SIP SRST = fall back on our phones. The phones do not support dual concurrent = registration. We were able to get the phones to fail over to the server = which works great. What were NOT able to do was to get the to fail back = over to the SIP server. In other words once the phones fail over to the = router and since the service never stops the phones never fail back = over to the phone system. It doesn't sound like a big problem but any = time we reboot our SIP phone system the phones fail over. We have been = performing a reload on the switches which kills the power over Ethernet = on the phones to get them operating again. Since the phones don't support dual registration Cisco won't help. = Anyone got any ideas? Do I have something configured incorrectly on my = routers? Thanks, Richard Logan ------_=_NextPart_001_01C5C62F.1FAD0AE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No dual concurrent registration

Hello,
We recently implemented a SIP phone = system and are using the SIP SRST fall back on our phones.  The = phones do not support dual concurrent registration.  We were able = to get the phones to fail over to the server which works great.  = What were NOT able to do was to get the to fail back over to the SIP = server.  In other words once the phones fail over to the router and = since the service never stops  the phones never fail back over to = the phone system.  It doesn't sound like a big problem but any time = we reboot our SIP phone system the phones fail over.  We have been = performing a reload on the switches which kills the power over Ethernet = on the phones to get them operating again.

Since the phones don't support dual = registration Cisco won't help.  Anyone got any ideas?  Do I = have something configured incorrectly on my routers?

Thanks,
Richard Logan

------_=_NextPart_001_01C5C62F.1FAD0AE9-- --===============0419178010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0419178010==-- From sip-bounces@ietf.org Tue Oct 04 08:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMlvA-0004Fy-81; Tue, 04 Oct 2005 08:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMlv7-0004FZ-To for sip@megatron.ietf.org; Tue, 04 Oct 2005 08:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14676 for ; Tue, 4 Oct 2005 08:29:20 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMm3m-0007Mc-06 for sip@ietf.org; Tue, 04 Oct 2005 08:38:20 -0400 Received: by xproxy.gmail.com with SMTP id t6so371251wxc for ; Tue, 04 Oct 2005 05:29:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=RJAn+mwfnD/dVm/R8tb0adBU3JxB5rr3xoQMw6oYQ6Aqp2ltVptullbLq8IIAnLCzn1cvBVRIDYOUl5321Kn+MlOzn+DiQf7yGcgxlSXjKhFahucGRTt+ryiHS85RDbP+1zJJPXKTJ7dpE9CARLmXU1CcBWOC//0uYhtuPHPhV8= Received: by 10.70.48.16 with SMTP id v16mr2336981wxv; Tue, 04 Oct 2005 05:29:08 -0700 (PDT) Received: by 10.70.38.8 with HTTP; Tue, 4 Oct 2005 05:29:08 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2005 17:59:08 +0530 From: ayan To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Sip] aka querry X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ayan List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855646676==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0855646676== Content-Type: multipart/alternative; boundary="----=_Part_5967_9862911.1128428948525" ------=_Part_5967_9862911.1128428948525 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi all, for registration using akav1algorithm, the nonce value of the WWW-Authenticate header of 401 response for REGISTER contains the base 64 encoded RAND, AUTN and Server Specific Data. how do we parse the RAND, AUTN and Server Specific Data from the nonce value? according to rfc 3310 example in section 3.2 : ___________________________________________________________________________= _______ Example: nonce=3D"MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK=3D" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AUTN | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Data... +-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Generating the nonce value. ___________________________________________________________________________= _____________ here a 32 bit value is given for RAND and AUTN. each base 64 digit will be 6 bit long. so how do we fit it into 32 bits? i'm a little confused on this one? kindly help me out. Thnx n Rgds. /ayan ------=_Part_5967_9862911.1128428948525 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
hi all,
 
for registration using akav1algorithm,
the nonce value of the WWW-Authenticate header of 401 response for REG= ISTER
contains the base 64 encoded RAND, AUTN and Server Specific Data.
 
how do we parse the RAND, AUTN and Server Specific Data from the nonce= value?
 
according to rfc 3310 example in section 3.2 :
 
______________________________________________________________________= ____________
 
Example:

         = nonce=3D"MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK=3D"
       0     &n= bsp;            = ; 1            =        2      &= nbsp;            3       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
      |  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          |
  = ;    |         =             &nb= sp;      RAND      &= nbsp;           &nbs= p;            |
      |      &nb= sp;            =             &nb= sp;            =             &nb= sp;      |
      |&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            |
&= nbsp;     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
      |      &nb= sp;            =             &nb= sp;            =             &nb= sp;      |
      |&nbs= p;            &= nbsp;           &nbs= p;  AUTN          &n= bsp;            = ;        |
    &n= bsp; |           &nb= sp;            =             &nb= sp;            =             &nb= sp; |
      |      &nb= sp;            =             &nb= sp;            =             &nb= sp;      |
      +-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = ;    |  Server Data...
     = ; +-+-+-+-+-+-+-+-+-+-+-+

       =              Fi= gure 1: Generating the nonce value.
 
______________________________________________________________________= __________________
 
here a 32 bit value is given for RAND and AUTN.
each base 64 digit will be 6 bit long.
so how do we fit it into 32 bits?
 
i'm a little confused on this one?
kindly help me out.
 
 
Thnx n Rgds.
/ayan
 
------=_Part_5967_9862911.1128428948525-- --===============0855646676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0855646676==-- From sip-bounces@ietf.org Tue Oct 04 09:47:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMn8g-0002bW-OS; Tue, 04 Oct 2005 09:47:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMn8e-0002Zl-TJ for sip@megatron.ietf.org; Tue, 04 Oct 2005 09:47:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19744 for ; Tue, 4 Oct 2005 09:47:22 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler3.mail.eds.com ([192.85.154.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMnHK-0001P0-BT for sip@ietf.org; Tue, 04 Oct 2005 09:56:23 -0400 Received: from ahmlir2.mail.eds.com (ahmlir2-2.mail.eds.com [192.85.154.132]) by ahmler3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94Dl1tJ030545; Tue, 4 Oct 2005 09:47:03 -0400 Received: from ahmlir2.mail.eds.com (localhost [127.0.0.1]) by ahmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94Dk9GZ011378; Tue, 4 Oct 2005 09:46:09 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94Dk8WB011369; Tue, 4 Oct 2005 09:46:09 -0400 In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0F081D@ZMY16EXM66.ds.mot.com> To: "Avasarala Ranjit-A20990" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 4 Oct 2005 09:52:51 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/04/2005 06:46:08 AM, Serialize complete at 10/04/2005 06:46:08 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: SIP IETF , SIP Implementors Subject: [Sip] RE: [Sip-implementors] Hold SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024551993==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1024551993== Content-Type: multipart/alternative; boundary="=_alternative 004B7C9485257090_=" This is a multipart message in MIME format. --=_alternative 004B7C9485257090_= Content-Type: text/plain; charset="US-ASCII" I want to know is it the genral behaviour of all UAC? because as per RFC, c=0 has not been recommended for RTCP purposes, anyway in these cases, we might need RTCP reports also, Why cant we have one more attribute "a=hold" which indicates its meant for hold and not for one-way media audio stream, Thanks, Udit "Avasarala Ranjit-A20990" Sent by: sip-implementors-bounces@cs.columbia.edu 10/04/2005 02:23 AM To Udit Goyal/C/US/3Com@3Com, "SIP Implementors" cc SIP IETF Subject RE: [Sip-implementors] Hold SDP Udit You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. Regards Ranjit -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Udit_Goyal@3com.com Sent: Monday, October 03, 2005 10:42 PM To: SIP Implementors Cc: SIP IETF Subject: [Sip-implementors] Hold SDP Hi, As per RFC 3264, user agent indicate hold by sending "sendonly attribute (assuming sendrecv mode stream). So when UAS receives this SDP, it should respond with "recvonly" attribute. But same mechanism can be used by user agent if he wants to play announcement or music to user, so it can send "sendonly" attribute for media stream. I mean if it simply wants one-way connection (this is not hold). For 3PCC (as B2B), if it wants to provide MOH service, how can it differentiate between two SDP because it will play MOH only in the first scenario when user press hold. Is there any other way where user agent can indicate that this is hold scenario and not one-way audio. Thanks, Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --=_alternative 004B7C9485257090_= Content-Type: text/html; charset="US-ASCII"
I want to know is it the genral behaviour of all UAC?

because as per RFC, c=0 has not been recommended for RTCP purposes,
anyway in these cases, we might need RTCP reports also,

Why cant we have one more attribute "a=hold" which indicates its meant for hold and not for one-way media audio stream,

Thanks,
Udit




"Avasarala Ranjit-A20990" <ranjit@motorola.com>
Sent by: sip-implementors-bounces@cs.columbia.edu

10/04/2005 02:23 AM

To
Udit Goyal/C/US/3Com@3Com, "SIP Implementors" <sip-implementors@cs.columbia.edu>
cc
SIP IETF <sip@ietf.org>
Subject
RE: [Sip-implementors] Hold SDP





Udit
You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly.


Regards
Ranjit



-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of
Udit_Goyal@3com.com
Sent: Monday, October 03, 2005 10:42 PM
To: SIP Implementors
Cc: SIP IETF
Subject: [Sip-implementors] Hold SDP
Hi,
As per RFC 3264, user agent indicate hold by sending "sendonly attribute
(assuming sendrecv mode stream).
So when UAS receives this SDP, it should respond with "recvonly"
attribute.
But same mechanism can be used by user agent if he wants to play
announcement or music to user, so it can send "sendonly" attribute for
media stream.
I mean if it simply wants one-way connection (this is not hold).
For 3PCC (as B2B), if it wants to provide MOH service, how can it
differentiate between two SDP because it will play MOH only in the first
scenario when user press hold.
Is there any other way where user agent can indicate that this is hold
scenario and not one-way audio.
Thanks,
Udit
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--=_alternative 004B7C9485257090_=-- --===============1024551993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1024551993==-- From sip-bounces@ietf.org Tue Oct 04 10:08:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnT9-0000Rr-2n; Tue, 04 Oct 2005 10:08:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMnT7-0000PZ-5u for sip@megatron.ietf.org; Tue, 04 Oct 2005 10:08:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21232 for ; Tue, 4 Oct 2005 10:08:30 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMnbn-0001yf-U6 for sip@ietf.org; Tue, 04 Oct 2005 10:17:32 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2005 07:08:23 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="216876003:sNHT27321892" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j94E7k4t002966; Tue, 4 Oct 2005 07:08:20 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 10:08:17 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 10:08:17 -0400 Message-ID: <43428CD1.50201@cisco.com> Date: Tue, 04 Oct 2005 10:08:17 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Udit_Goyal@3com.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 14:08:17.0562 (UTC) FILETIME=[11751FA0:01C5C8ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: SIP IETF , SIP Implementors Subject: [Sip] Re: [Sip-implementors] Hold SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Udit_Goyal@3com.com wrote: > I want to know is it the genral behaviour of all UAC? There are a lot of UAs out there. Its hard to say what the "general" behavior is. > because as per RFC, c=0 has not been recommended for RTCP purposes, > anyway in these cases, we might need RTCP reports also, The use of c=0 is an old (now deprecated) action in response to a request to initiate hold. The mechanism still exists, and is still important for some call flows unrelated to hold. There is of course nothing to prevent a UA from using it when initiating Hold, and the peer should do something reasonable in response. > Why cant we have one more attribute "a=hold" which indicates its meant for > hold and not for one-way media audio stream, I think mostly because hold is a feature, and IETF doesn't standardize features. The existing directionality attributes are mechanisms that may be used for hold or other things. If you introduced a hold attribute, then there would be a lot of call to have different flavors of hold - one way, two way, with music, without music, etc. And of course you would need to get into the precise semantics of hold. As things stand, Hold is a local feature on an endpoint. The corresponding signaling should not really be considered as signaling "hold" - it is only signaling the desired media behavior. I think there is no expectation, or need, for the other UA, or servers in the path to be able to determine that the call is "held". Paul > Thanks, > Udit > > > > > > "Avasarala Ranjit-A20990" > Sent by: sip-implementors-bounces@cs.columbia.edu > 10/04/2005 02:23 AM > > To > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > cc > SIP IETF > Subject > RE: [Sip-implementors] Hold SDP > > > > > > > Udit > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > Regards > Ranjit > > > > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > Udit_Goyal@3com.com > Sent: Monday, October 03, 2005 10:42 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip-implementors] Hold SDP > > Hi, > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > (assuming sendrecv mode stream). > So when UAS receives this SDP, it should respond with "recvonly" > attribute. > > But same mechanism can be used by user agent if he wants to play > announcement or music to user, so it can send "sendonly" attribute for > media stream. > I mean if it simply wants one-way connection (this is not hold). > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > differentiate between two SDP because it will play MOH only in the first > scenario when user press hold. > > Is there any other way where user agent can indicate that this is hold > scenario and not one-way audio. > > Thanks, > Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 12:22:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpVj-0005Xk-PF; Tue, 04 Oct 2005 12:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpVg-0005VN-IY; Tue, 04 Oct 2005 12:19:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07127; Tue, 4 Oct 2005 12:19:17 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMpeO-0008IZ-7P; Tue, 04 Oct 2005 12:28:20 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4819E2009C; Tue, 4 Oct 2005 12:19:06 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 03129-01-14; Tue, 4 Oct 2005 12:19:05 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 50949200A2; Tue, 4 Oct 2005 12:19:05 -0400 (EDT) To: Paul Kyzivat Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Tue, 4 Oct 2005 12:22:56 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 10/04/2005 12:19:02 PM, Serialize complete at 10/04/2005 12:19:02 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: SIP IETF , SIP Implementors , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1897032911==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1897032911== Content-Type: multipart/alternative; boundary="=_alternative 0059A60185257090_=" This is a multipart message in MIME format. --=_alternative 0059A60185257090_= Content-Type: text/plain; charset="us-ascii" Some related discussion has also gone on in SIP Forum context recently. I believe an additional issue here is that, in many practical deployments, there is something in between the UAs (softswitch, ip-pbx, SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and take the wrong action based on assumptions. For example the middle entity could see the sendonly attribute, assume it is for Hold when it actually being used to implement (say) a one-way audio conference/listen session, and go ahead and insert it's own music on hold. Oops! There are many, many such scenarios. This can certainly happen, no matter how well-behaved the UA is (... and not all UAs are well behaved of course ;-). I'm NOT saying such middle boxes are good, bad or indifferent. (I'm sure others will chime in that they are inherently evil ;-) However, they are a practical reality. Having some form of explicit "reason" indicator, likely at SIP level not in SDP, could be a big help to solve this issue, and similar ones. Would potentially help clean up both middle box and UA behavior. Thinking out loud ... Peter Blatherwick Paul Kyzivat Sent by: sip-bounces@ietf.org 04.10.05 10:08 To: Udit_Goyal@3com.com cc: SIP IETF , SIP Implementors Subject: [Sip] Re: [Sip-implementors] Hold SDP Udit_Goyal@3com.com wrote: > I want to know is it the genral behaviour of all UAC? There are a lot of UAs out there. Its hard to say what the "general" behavior is. > because as per RFC, c=0 has not been recommended for RTCP purposes, > anyway in these cases, we might need RTCP reports also, The use of c=0 is an old (now deprecated) action in response to a request to initiate hold. The mechanism still exists, and is still important for some call flows unrelated to hold. There is of course nothing to prevent a UA from using it when initiating Hold, and the peer should do something reasonable in response. > Why cant we have one more attribute "a=hold" which indicates its meant for > hold and not for one-way media audio stream, I think mostly because hold is a feature, and IETF doesn't standardize features. The existing directionality attributes are mechanisms that may be used for hold or other things. If you introduced a hold attribute, then there would be a lot of call to have different flavors of hold - one way, two way, with music, without music, etc. And of course you would need to get into the precise semantics of hold. As things stand, Hold is a local feature on an endpoint. The corresponding signaling should not really be considered as signaling "hold" - it is only signaling the desired media behavior. I think there is no expectation, or need, for the other UA, or servers in the path to be able to determine that the call is "held". Paul > Thanks, > Udit > > > > > > "Avasarala Ranjit-A20990" > Sent by: sip-implementors-bounces@cs.columbia.edu > 10/04/2005 02:23 AM > > To > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > cc > SIP IETF > Subject > RE: [Sip-implementors] Hold SDP > > > > > > > Udit > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > Regards > Ranjit > > > > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > Udit_Goyal@3com.com > Sent: Monday, October 03, 2005 10:42 PM > To: SIP Implementors > Cc: SIP IETF > Subject: [Sip-implementors] Hold SDP > > Hi, > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > (assuming sendrecv mode stream). > So when UAS receives this SDP, it should respond with "recvonly" > attribute. > > But same mechanism can be used by user agent if he wants to play > announcement or music to user, so it can send "sendonly" attribute for > media stream. > I mean if it simply wants one-way connection (this is not hold). > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > differentiate between two SDP because it will play MOH only in the first > scenario when user press hold. > > Is there any other way where user agent can indicate that this is hold > scenario and not one-way audio. > > Thanks, > Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0059A60185257090_= Content-Type: text/html; charset="us-ascii"
Some related discussion has also gone on in SIP Forum context recently.  

I believe an additional issue here is that, in many practical deployments, there is something in between the UAs (softswitch, ip-pbx, SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and take the wrong action based on assumptions.  For example the middle entity could see the sendonly attribute, assume it is for Hold when it actually being used to implement (say) a one-way audio conference/listen session, and go ahead and insert it's own music on hold.  Oops!   There are many, many such scenarios.  This can certainly happen, no matter how well-behaved the UA is (... and not all UAs are well behaved of course ;-).  

I'm NOT saying such middle boxes are good, bad or indifferent.  (I'm sure others will chime in that they are inherently evil ;-)  However, they are a practical reality.  

Having some form of explicit "reason" indicator, likely at SIP level not in SDP, could be a big help to solve this issue, and similar ones.  Would potentially help clean up both middle box and UA behavior.  

Thinking out loud ...

Peter Blatherwick





Paul Kyzivat <pkyzivat@cisco.com>
Sent by: sip-bounces@ietf.org

04.10.05 10:08

       
        To:        Udit_Goyal@3com.com
        cc:        SIP IETF <sip@ietf.org>, SIP Implementors <sip-implementors@cs.columbia.edu>
        Subject:        [Sip] Re: [Sip-implementors] Hold SDP





Udit_Goyal@3com.com wrote:
> I want to know is it the genral behaviour of all UAC?

There are a lot of UAs out there. Its hard to say what the "general"
behavior is.

> because as per RFC, c=0 has not been recommended for RTCP purposes,
> anyway in these cases, we might need RTCP reports also,

The use of c=0 is an old (now deprecated) action in response to a
request to initiate hold. The mechanism still exists, and is still
important for some call flows unrelated to hold. There is of course
nothing to prevent a UA from using it when initiating Hold, and the peer
should do something reasonable in response.

> Why cant we have one more attribute "a=hold" which indicates its meant for
> hold and not for one-way media audio stream,

I think mostly because hold is a feature, and IETF doesn't standardize
features. The existing directionality attributes are mechanisms that may
be used for hold or other things.

If you introduced a hold attribute, then there would be a lot of call to
have different flavors of hold - one way, two way, with music, without
music, etc. And of course you would need to get into the precise
semantics of hold.

As things stand, Hold is a local feature on an endpoint. The
corresponding signaling should not really be considered as signaling
"hold" - it is only signaling the desired media behavior. I think there
is no expectation, or need, for the other UA, or servers in the path to
be able to determine that the call is "held".

                Paul

> Thanks,
> Udit
>
>
>
>
>
> "Avasarala Ranjit-A20990" <ranjit@motorola.com>
> Sent by: sip-implementors-bounces@cs.columbia.edu
> 10/04/2005 02:23 AM
>
> To
> Udit Goyal/C/US/3Com@3Com, "SIP Implementors"
> <sip-implementors@cs.columbia.edu>
> cc
> SIP IETF <sip@ietf.org>
> Subject
> RE: [Sip-implementors] Hold SDP
>
>
>
>
>
>
> Udit
>
> You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly.
>
>
>
> Regards
> Ranjit
>
>
>
>
> -----Original Message-----
> From: sip-implementors-bounces@cs.columbia.edu
> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of
> Udit_Goyal@3com.com
> Sent: Monday, October 03, 2005 10:42 PM
> To: SIP Implementors
> Cc: SIP IETF
> Subject: [Sip-implementors] Hold SDP
>
> Hi,
>
> As per RFC 3264, user agent indicate hold by sending "sendonly attribute
> (assuming sendrecv mode stream).
> So when UAS receives this SDP, it should respond with "recvonly"
> attribute.
>
> But same mechanism can be used by user agent if he wants to play
> announcement or music to user, so it can send "sendonly" attribute for
> media stream.
> I mean if it simply wants one-way connection (this is not hold).
>
> For 3PCC (as B2B), if it wants to provide MOH service, how can it
> differentiate between two SDP because it will play MOH only in the first
> scenario when user press hold.
>
> Is there any other way where user agent can indicate that this is hold
> scenario and not one-way audio.
>
> Thanks,
> Udit
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

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

--=_alternative 0059A60185257090_=-- --===============1897032911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1897032911==-- From sip-bounces@ietf.org Tue Oct 04 12:51:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMq0a-0007A5-D2; Tue, 04 Oct 2005 12:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMq0Y-00079Y-Du; Tue, 04 Oct 2005 12:51:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09318; Tue, 4 Oct 2005 12:51:11 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMq9G-0000uY-Ia; Tue, 04 Oct 2005 13:00:15 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 09:51:05 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="663373443:sNHT28107420" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94Go95Q015612; Tue, 4 Oct 2005 09:51:02 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 12:50:57 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 12:50:56 -0400 Message-ID: <4342B2F0.8080209@cisco.com> Date: Tue, 04 Oct 2005 12:50:56 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: peter_blatherwick@mitel.com Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 16:50:56.0759 (UTC) FILETIME=[CA646870:01C5C903] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Cc: SIP IETF , SIP Implementors , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org peter_blatherwick@mitel.com wrote: > > Some related discussion has also gone on in SIP Forum context recently. > > I believe an additional issue here is that, in many practical > deployments, there is something in between the UAs (softswitch, ip-pbx, > SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and > take the wrong action based on assumptions. For example the middle > entity could see the sendonly attribute, assume it is for Hold when it > actually being used to implement (say) a one-way audio conference/listen > session, and go ahead and insert it's own music on hold. Oops! There > are many, many such scenarios. This can certainly happen, no matter how > well-behaved the UA is (... and not all UAs are well behaved of course > ;-). > > I'm NOT saying such middle boxes are good, bad or indifferent. (I'm > sure others will chime in that they are inherently evil ;-) However, > they are a practical reality. > > Having some form of explicit "reason" indicator, likely at SIP level not > in SDP, could be a big help to solve this issue, and similar ones. > Would potentially help clean up both middle box and UA behavior. Peter, I think this is a matter of philosophy. IMO the development of sip has been predicated on the assumtion that the UA is the one that knows what is going on, and that at least coordinates actions, if it doesn't do them itself. The other elements of the network have much less information about what is going on, and hence have a much harder time of deciding on their own how to "help" without "hurting" instead. Certainly the sip signaling gives intermediates *some* information about what is going on, enough to do the limited sets of things that have been proposed that they do. But they certainly don't have the big picture. In the case of hold, there is no problem as long as the endpoints do what they should and the intermediates just stay out of the way. The problem comes in when intermediates want to "help" without having adequate information to do so correctly. There are two solutions to this problem: they could stop trying to help, or they can be provided with more information so they can do a better job of helping. Before proposing that more information be provided, I think it is first necessary to decide if this is the appropriate direction to be going. Paul > Thinking out loud ... > > Peter Blatherwick > > > > > > *Paul Kyzivat * > Sent by: sip-bounces@ietf.org > > 04.10.05 10:08 > > > To: Udit_Goyal@3com.com > cc: SIP IETF , SIP Implementors > > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > Udit_Goyal@3com.com wrote: > > I want to know is it the genral behaviour of all UAC? > > There are a lot of UAs out there. Its hard to say what the "general" > behavior is. > > > because as per RFC, c=0 has not been recommended for RTCP purposes, > > anyway in these cases, we might need RTCP reports also, > > The use of c=0 is an old (now deprecated) action in response to a > request to initiate hold. The mechanism still exists, and is still > important for some call flows unrelated to hold. There is of course > nothing to prevent a UA from using it when initiating Hold, and the peer > should do something reasonable in response. > > > Why cant we have one more attribute "a=hold" which indicates its > meant for > > hold and not for one-way media audio stream, > > I think mostly because hold is a feature, and IETF doesn't standardize > features. The existing directionality attributes are mechanisms that may > be used for hold or other things. > > If you introduced a hold attribute, then there would be a lot of call to > have different flavors of hold - one way, two way, with music, without > music, etc. And of course you would need to get into the precise > semantics of hold. > > As things stand, Hold is a local feature on an endpoint. The > corresponding signaling should not really be considered as signaling > "hold" - it is only signaling the desired media behavior. I think there > is no expectation, or need, for the other UA, or servers in the path to > be able to determine that the call is "held". > > Paul > > > Thanks, > > Udit > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > Sent by: sip-implementors-bounces@cs.columbia.edu > > 10/04/2005 02:23 AM > > > > To > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > cc > > SIP IETF > > Subject > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > Udit > > > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > > > > > Regards > > Ranjit > > > > > > > > > > -----Original Message----- > > From: sip-implementors-bounces@cs.columbia.edu > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > Udit_Goyal@3com.com > > Sent: Monday, October 03, 2005 10:42 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip-implementors] Hold SDP > > > > Hi, > > > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > > (assuming sendrecv mode stream). > > So when UAS receives this SDP, it should respond with "recvonly" > > attribute. > > > > But same mechanism can be used by user agent if he wants to play > > announcement or music to user, so it can send "sendonly" attribute for > > media stream. > > I mean if it simply wants one-way connection (this is not hold). > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > differentiate between two SDP because it will play MOH only in the first > > scenario when user press hold. > > > > Is there any other way where user agent can indicate that this is hold > > scenario and not one-way audio. > > > > Thanks, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 13:17:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqPj-0007qS-9E; Tue, 04 Oct 2005 13:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqPg-0007qF-Ja; Tue, 04 Oct 2005 13:17:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10822; Tue, 4 Oct 2005 13:17:08 -0400 (EDT) From: peter_blatherwick@mitel.com Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMqYO-0001dE-4r; Tue, 04 Oct 2005 13:26:13 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id A77B5200C1; Tue, 4 Oct 2005 13:17:01 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10124) with LMTP id 12150-01-10; Tue, 4 Oct 2005 13:17:01 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 21250200AE; Tue, 4 Oct 2005 13:17:01 -0400 (EDT) To: Paul Kyzivat Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Tue, 4 Oct 2005 13:20:52 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 10/04/2005 01:16:58 PM, Serialize complete at 10/04/2005 01:16:58 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Cc: SIP IETF , SIP Implementors , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2066318974==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============2066318974== Content-Type: multipart/alternative; boundary="=_alternative 005EF3BD85257090_=" This is a multipart message in MIME format. --=_alternative 005EF3BD85257090_= Content-Type: text/plain; charset="us-ascii" Hi Paul, Agree on all points Just pointing out an additional practical issue in the Hold scenarios (and trying not to get flamed ;-). -- Peter Paul Kyzivat 04.10.05 12:50 To: peter_blatherwick@mitel.com cc: SIP IETF , sip-bounces@ietf.org, SIP Implementors , Udit_Goyal@3com.com Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP peter_blatherwick@mitel.com wrote: > > Some related discussion has also gone on in SIP Forum context recently. > > I believe an additional issue here is that, in many practical > deployments, there is something in between the UAs (softswitch, ip-pbx, > SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and > take the wrong action based on assumptions. For example the middle > entity could see the sendonly attribute, assume it is for Hold when it > actually being used to implement (say) a one-way audio conference/listen > session, and go ahead and insert it's own music on hold. Oops! There > are many, many such scenarios. This can certainly happen, no matter how > well-behaved the UA is (... and not all UAs are well behaved of course > ;-). > > I'm NOT saying such middle boxes are good, bad or indifferent. (I'm > sure others will chime in that they are inherently evil ;-) However, > they are a practical reality. > > Having some form of explicit "reason" indicator, likely at SIP level not > in SDP, could be a big help to solve this issue, and similar ones. > Would potentially help clean up both middle box and UA behavior. Peter, I think this is a matter of philosophy. IMO the development of sip has been predicated on the assumtion that the UA is the one that knows what is going on, and that at least coordinates actions, if it doesn't do them itself. The other elements of the network have much less information about what is going on, and hence have a much harder time of deciding on their own how to "help" without "hurting" instead. Certainly the sip signaling gives intermediates *some* information about what is going on, enough to do the limited sets of things that have been proposed that they do. But they certainly don't have the big picture. In the case of hold, there is no problem as long as the endpoints do what they should and the intermediates just stay out of the way. The problem comes in when intermediates want to "help" without having adequate information to do so correctly. There are two solutions to this problem: they could stop trying to help, or they can be provided with more information so they can do a better job of helping. Before proposing that more information be provided, I think it is first necessary to decide if this is the appropriate direction to be going. Paul > Thinking out loud ... > > Peter Blatherwick > > > > > > *Paul Kyzivat * > Sent by: sip-bounces@ietf.org > > 04.10.05 10:08 > > > To: Udit_Goyal@3com.com > cc: SIP IETF , SIP Implementors > > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > Udit_Goyal@3com.com wrote: > > I want to know is it the genral behaviour of all UAC? > > There are a lot of UAs out there. Its hard to say what the "general" > behavior is. > > > because as per RFC, c=0 has not been recommended for RTCP purposes, > > anyway in these cases, we might need RTCP reports also, > > The use of c=0 is an old (now deprecated) action in response to a > request to initiate hold. The mechanism still exists, and is still > important for some call flows unrelated to hold. There is of course > nothing to prevent a UA from using it when initiating Hold, and the peer > should do something reasonable in response. > > > Why cant we have one more attribute "a=hold" which indicates its > meant for > > hold and not for one-way media audio stream, > > I think mostly because hold is a feature, and IETF doesn't standardize > features. The existing directionality attributes are mechanisms that may > be used for hold or other things. > > If you introduced a hold attribute, then there would be a lot of call to > have different flavors of hold - one way, two way, with music, without > music, etc. And of course you would need to get into the precise > semantics of hold. > > As things stand, Hold is a local feature on an endpoint. The > corresponding signaling should not really be considered as signaling > "hold" - it is only signaling the desired media behavior. I think there > is no expectation, or need, for the other UA, or servers in the path to > be able to determine that the call is "held". > > Paul > > > Thanks, > > Udit > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > Sent by: sip-implementors-bounces@cs.columbia.edu > > 10/04/2005 02:23 AM > > > > To > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > cc > > SIP IETF > > Subject > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > Udit > > > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > > > > > Regards > > Ranjit > > > > > > > > > > -----Original Message----- > > From: sip-implementors-bounces@cs.columbia.edu > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > Udit_Goyal@3com.com > > Sent: Monday, October 03, 2005 10:42 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip-implementors] Hold SDP > > > > Hi, > > > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > > (assuming sendrecv mode stream). > > So when UAS receives this SDP, it should respond with "recvonly" > > attribute. > > > > But same mechanism can be used by user agent if he wants to play > > announcement or music to user, so it can send "sendonly" attribute for > > media stream. > > I mean if it simply wants one-way connection (this is not hold). > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > differentiate between two SDP because it will play MOH only in the first > > scenario when user press hold. > > > > Is there any other way where user agent can indicate that this is hold > > scenario and not one-way audio. > > > > Thanks, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > --=_alternative 005EF3BD85257090_= Content-Type: text/html; charset="us-ascii"
Hi Paul,
Agree on all points   Just pointing out an additional practical issue in the Hold scenarios (and trying not to get flamed ;-).  
-- Peter




Paul Kyzivat <pkyzivat@cisco.com>

04.10.05 12:50

       
        To:        peter_blatherwick@mitel.com
        cc:        SIP IETF <sip@ietf.org>, sip-bounces@ietf.org, SIP Implementors <sip-implementors@cs.columbia.edu>, Udit_Goyal@3com.com
        Subject:        Re: [Sip] Re: [Sip-implementors] Hold SDP





peter_blatherwick@mitel.com wrote:
>
> Some related discussion has also gone on in SIP Forum context recently.  
>
> I believe an additional issue here is that, in many practical
> deployments, there is something in between the UAs (softswitch, ip-pbx,
> SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and
> take the wrong action based on assumptions.  For example the middle
> entity could see the sendonly attribute, assume it is for Hold when it
> actually being used to implement (say) a one-way audio conference/listen
> session, and go ahead and insert it's own music on hold.  Oops!   There
> are many, many such scenarios.  This can certainly happen, no matter how
> well-behaved the UA is (... and not all UAs are well behaved of course
> ;-).  
>
> I'm NOT saying such middle boxes are good, bad or indifferent.  (I'm
> sure others will chime in that they are inherently evil ;-)  However,
> they are a practical reality.  
>
> Having some form of explicit "reason" indicator, likely at SIP level not
> in SDP, could be a big help to solve this issue, and similar ones.
>  Would potentially help clean up both middle box and UA behavior.  

Peter,

I think this is a matter of philosophy. IMO the development of sip has
been predicated on the assumtion that the UA is the one that knows what
is going on, and that at least coordinates actions, if it doesn't do
them itself. The other elements of the network have much less
information about what is going on, and hence have a much harder time of
deciding on their own how to "help" without "hurting" instead.

Certainly the sip signaling gives intermediates *some* information about
what is going on, enough to do the limited sets of things that have been
proposed that they do. But they certainly don't have the big picture.

In the case of hold, there is no problem as long as the endpoints do
what they should and the intermediates just stay out of the way. The
problem comes in when intermediates want to "help" without having
adequate information to do so correctly. There are two solutions to this
problem: they could stop trying to help, or they can be provided with
more information so they can do a better job of helping.

Before proposing that more information be provided, I think it is first
necessary to decide if this is the appropriate direction to be going.

                Paul

> Thinking out loud ...
>
> Peter Blatherwick
>
>
>
>
>
>                  *Paul Kyzivat <pkyzivat@cisco.com>*
> Sent by: sip-bounces@ietf.org
>
> 04.10.05 10:08
>
>                        
>         To:        Udit_Goyal@3com.com
>         cc:        SIP IETF <sip@ietf.org>, SIP Implementors
> <sip-implementors@cs.columbia.edu>
>         Subject:        [Sip] Re: [Sip-implementors] Hold SDP
>
>
>
>
>
>
> Udit_Goyal@3com.com wrote:
>  > I want to know is it the genral behaviour of all UAC?
>
> There are a lot of UAs out there. Its hard to say what the "general"
> behavior is.
>
>  > because as per RFC, c=0 has not been recommended for RTCP purposes,
>  > anyway in these cases, we might need RTCP reports also,
>
> The use of c=0 is an old (now deprecated) action in response to a
> request to initiate hold. The mechanism still exists, and is still
> important for some call flows unrelated to hold. There is of course
> nothing to prevent a UA from using it when initiating Hold, and the peer
> should do something reasonable in response.
>
>  > Why cant we have one more attribute "a=hold" which indicates its
> meant for
>  > hold and not for one-way media audio stream,
>
> I think mostly because hold is a feature, and IETF doesn't standardize
> features. The existing directionality attributes are mechanisms that may
> be used for hold or other things.
>
> If you introduced a hold attribute, then there would be a lot of call to
> have different flavors of hold - one way, two way, with music, without
> music, etc. And of course you would need to get into the precise
> semantics of hold.
>
> As things stand, Hold is a local feature on an endpoint. The
> corresponding signaling should not really be considered as signaling
> "hold" - it is only signaling the desired media behavior. I think there
> is no expectation, or need, for the other UA, or servers in the path to
> be able to determine that the call is "held".
>
>                 Paul
>
>  > Thanks,
>  > Udit
>  >
>  >
>  >
>  >
>  >
>  > "Avasarala Ranjit-A20990" <ranjit@motorola.com>
>  > Sent by: sip-implementors-bounces@cs.columbia.edu
>  > 10/04/2005 02:23 AM
>  >
>  > To
>  > Udit Goyal/C/US/3Com@3Com, "SIP Implementors"
>  > <sip-implementors@cs.columbia.edu>
>  > cc
>  > SIP IETF <sip@ietf.org>
>  > Subject
>  > RE: [Sip-implementors] Hold SDP
>  >
>  >
>  >
>  >
>  >
>  >
>  > Udit
>  >
>  > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly.
>  >
>  >
>  >
>  > Regards
>  > Ranjit
>  >
>  >
>  >
>  >
>  > -----Original Message-----
>  > From: sip-implementors-bounces@cs.columbia.edu
>  > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of
>  > Udit_Goyal@3com.com
>  > Sent: Monday, October 03, 2005 10:42 PM
>  > To: SIP Implementors
>  > Cc: SIP IETF
>  > Subject: [Sip-implementors] Hold SDP
>  >
>  > Hi,
>  >
>  > As per RFC 3264, user agent indicate hold by sending "sendonly attribute
>  > (assuming sendrecv mode stream).
>  > So when UAS receives this SDP, it should respond with "recvonly"
>  > attribute.
>  >
>  > But same mechanism can be used by user agent if he wants to play
>  > announcement or music to user, so it can send "sendonly" attribute for
>  > media stream.
>  > I mean if it simply wants one-way connection (this is not hold).
>  >
>  > For 3PCC (as B2B), if it wants to provide MOH service, how can it
>  > differentiate between two SDP because it will play MOH only in the first
>  > scenario when user press hold.
>  >
>  > Is there any other way where user agent can indicate that this is hold
>  > scenario and not one-way audio.
>  >
>  > Thanks,
>  > Udit
>  > _______________________________________________
>  > Sip-implementors mailing list
>  > Sip-implementors@cs.columbia.edu
>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>  >
>  > _______________________________________________
>  > Sip-implementors mailing list
>  > Sip-implementors@cs.columbia.edu
>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>  > _______________________________________________
>  > Sip-implementors mailing list
>  > Sip-implementors@cs.columbia.edu
>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>  >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>


--=_alternative 005EF3BD85257090_=-- --===============2066318974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2066318974==-- From sip-bounces@ietf.org Tue Oct 04 13:19:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqS6-00083z-KG; Tue, 04 Oct 2005 13:19:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqS0-00083c-CB for sip@megatron.ietf.org; Tue, 04 Oct 2005 13:19:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10936 for ; Tue, 4 Oct 2005 13:19:30 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler7.mail.eds.com ([192.85.154.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMqab-0001gS-AJ for sip@ietf.org; Tue, 04 Oct 2005 13:28:35 -0400 Received: from ahmlir5.mail.eds.com (ahmlir5-2.mail.eds.com [192.85.154.135]) by ahmler7.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94HJ7db019144; Tue, 4 Oct 2005 13:19:13 -0400 Received: from ahmlir5.mail.eds.com (localhost [127.0.0.1]) by ahmlir5.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94HIZOM002391; Tue, 4 Oct 2005 13:18:35 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir5.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94HIZRL002375; Tue, 4 Oct 2005 13:18:35 -0400 In-Reply-To: <8019F8581B5FC14DBD94BAF86844868E86B4EE@viridis.IPeria.local> To: "Gordon Ledgard" Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 4 Oct 2005 13:25:16 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/04/2005 10:18:34 AM, Serialize complete at 10/04/2005 10:18:34 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: SIP IETF , Paul Kyzivat , SIP Implementors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472552466==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0472552466== Content-Type: multipart/alternative; boundary="=_alternative 005EEF3E85257090_=" This is a multipart message in MIME format. --=_alternative 005EEF3E85257090_= Content-Type: text/plain; charset="US-ASCII" At one point we are saying that hold is a feature, and in RFC 3264, we are saying if you want to put streams on hold, then use "sendonly" attribute, So basically we are giving guidelines for UAC to indicate when it wants to put streams on hold, but not differnetiating when it wants to open one-way media stream. Actually, from UAC to UAS perspective, it is not much of an issue, but for B2B applications, it is certainly an issue. Regarding the different flavous of hold, why do we need to define all flavours, let it be the service responsibilty. I have seen similar thread going on SIPForum-techwg for UA behaviour regarding MOH.. "sendonly" attribute indicates that it wants to play some music or announcements... What if UAC does not want to play music and want to hold stream, and services wants to play MOH to other party. Its better if we can just convey the information in SDP, that this is for hold. Regads, Udit "Gordon Ledgard" 10/04/2005 10:32 AM To "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com cc Subject RE: [Sip] Re: [Sip-implementors] Hold SDP You guys have piqued my curiosity here. I agree with just about everything you said, Paul, except that I'm not quite sure its so simple to say that hold is a "feature" and not an "attribute". The semantics are fuzzy. To the caller, the action of pressing some "hold" button is an expectation for a particular sort of behavior, music or not. From the perspective of the service receiving the request, the request for the behavior from the caller can be interpreted in a few ways, and thus becomes a "feature". But in any event there seems to be no way to differentiate the users "intent" simply by examining the send/receive attributes of the SDP. Is this not at the heart of the complaint? If so, I think Udit, and many others who have whined about the inadequacy of the send/receive semantics, have a point... why can there not be something to signal this intent? Perhaps we can hash out the distinctions. Gordon. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Tuesday, October 04, 2005 10:08 AM > To: Udit_Goyal@3com.com > Cc: SIP IETF; SIP Implementors > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > Udit_Goyal@3com.com wrote: > > I want to know is it the genral behaviour of all UAC? > > There are a lot of UAs out there. Its hard to say what the "general" > behavior is. > > > because as per RFC, c=0 has not been recommended for RTCP purposes, > > anyway in these cases, we might need RTCP reports also, > > The use of c=0 is an old (now deprecated) action in response to a > request to initiate hold. The mechanism still exists, and is still > important for some call flows unrelated to hold. There is of course > nothing to prevent a UA from using it when initiating Hold, and the peer > should do something reasonable in response. > > > Why cant we have one more attribute "a=hold" which indicates its meant > for > > hold and not for one-way media audio stream, > > I think mostly because hold is a feature, and IETF doesn't standardize > features. The existing directionality attributes are mechanisms that may > be used for hold or other things. > > If you introduced a hold attribute, then there would be a lot of call to > have different flavors of hold - one way, two way, with music, without > music, etc. And of course you would need to get into the precise > semantics of hold. > > As things stand, Hold is a local feature on an endpoint. The > corresponding signaling should not really be considered as signaling > "hold" - it is only signaling the desired media behavior. I think there > is no expectation, or need, for the other UA, or servers in the path to > be able to determine that the call is "held". > > Paul > > > Thanks, > > Udit > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > Sent by: sip-implementors-bounces@cs.columbia.edu > > 10/04/2005 02:23 AM > > > > To > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > cc > > SIP IETF > > Subject > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > Udit > > > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > > > > > Regards > > Ranjit > > > > > > > > > > -----Original Message----- > > From: sip-implementors-bounces@cs.columbia.edu > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > Udit_Goyal@3com.com > > Sent: Monday, October 03, 2005 10:42 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip-implementors] Hold SDP > > > > Hi, > > > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > > (assuming sendrecv mode stream). > > So when UAS receives this SDP, it should respond with "recvonly" > > attribute. > > > > But same mechanism can be used by user agent if he wants to play > > announcement or music to user, so it can send "sendonly" attribute for > > media stream. > > I mean if it simply wants one-way connection (this is not hold). > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > differentiate between two SDP because it will play MOH only in the first > > scenario when user press hold. > > > > Is there any other way where user agent can indicate that this is hold > > scenario and not one-way audio. > > > > Thanks, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 005EEF3E85257090_= Content-Type: text/html; charset="US-ASCII"
At one point we are saying that hold is a feature,
and in RFC 3264, we are saying if you want to put streams on hold, then use "sendonly" attribute,

So basically we are giving guidelines for UAC to indicate when it wants to put streams on hold, but not differnetiating when it wants to open one-way media stream.

Actually, from UAC to UAS perspective, it is not much of an issue, but for B2B applications, it is certainly an issue.

Regarding the different flavous of hold, why do we need to define all flavours, let it be the service responsibilty.

I have seen similar thread going on SIPForum-techwg for UA behaviour regarding MOH..

"sendonly" attribute indicates that it wants to play some music or announcements...
What if UAC does not want to play music and want to hold stream, and services wants to play MOH to other party.

Its better if we can just convey the information in SDP, that this is for hold.

Regads,
Udit





"Gordon Ledgard" <gledgard@iperia.com>

10/04/2005 10:32 AM

To
"Paul Kyzivat" <pkyzivat@cisco.com>, Udit Goyal/C/US/3Com@3Com
cc
Subject
RE: [Sip] Re: [Sip-implementors] Hold SDP






You guys have piqued my curiosity here.  I agree with just about
everything
you said, Paul, except that I'm not quite sure its so simple to say that
hold is a "feature" and not an "attribute".  The semantics are fuzzy.
To the caller, the action of pressing some "hold" button is an
expectation
for a particular sort of behavior, music or not. From the perspective of
the
service receiving the request, the request for the behavior from the
caller
can be interpreted in a few ways, and thus becomes a "feature".  But in
any
event there seems to be no way to differentiate the users "intent"
simply
by examining the send/receive attributes of the SDP.  Is this not at the
heart of the complaint?

If so, I think Udit, and many others who have whined about the
inadequacy of
the send/receive semantics, have a point... why can there not be
something to signal this intent?  Perhaps we can hash out the
distinctions.

Gordon.



> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Paul
> Kyzivat
> Sent: Tuesday, October 04, 2005 10:08 AM
> To: Udit_Goyal@3com.com
> Cc: SIP IETF; SIP Implementors
> Subject: [Sip] Re: [Sip-implementors] Hold SDP
>
>
>
> Udit_Goyal@3com.com wrote:
> > I want to know is it the genral behaviour of all UAC?
>
> There are a lot of UAs out there. Its hard to say what the "general"
> behavior is.
>
> > because as per RFC, c=0 has not been recommended for RTCP purposes,
> > anyway in these cases, we might need RTCP reports also,
>
> The use of c=0 is an old (now deprecated) action in response to a
> request to initiate hold. The mechanism still exists, and is still
> important for some call flows unrelated to hold. There is of course
> nothing to prevent a UA from using it when initiating Hold, and the
peer
> should do something reasonable in response.
>
> > Why cant we have one more attribute "a=hold" which indicates its
meant
> for
> > hold and not for one-way media audio stream,
>
> I think mostly because hold is a feature, and IETF doesn't standardize
> features. The existing directionality attributes are mechanisms that
may
> be used for hold or other things.
>
> If you introduced a hold attribute, then there would be a lot of call
to
> have different flavors of hold - one way, two way, with music, without
> music, etc. And of course you would need to get into the precise
> semantics of hold.
>
> As things stand, Hold is a local feature on an endpoint. The
> corresponding signaling should not really be considered as signaling
> "hold" - it is only signaling the desired media behavior. I think
there
> is no expectation, or need, for the other UA, or servers in the path
to
> be able to determine that the call is "held".
>
>         Paul
>
> > Thanks,
> > Udit
> >
> >
> >
> >
> >
> > "Avasarala Ranjit-A20990" <ranjit@motorola.com>
> > Sent by: sip-implementors-bounces@cs.columbia.edu
> > 10/04/2005 02:23 AM
> >
> > To
> > Udit Goyal/C/US/3Com@3Com, "SIP Implementors"
> > <sip-implementors@cs.columbia.edu>
> > cc
> > SIP IETF <sip@ietf.org>
> > Subject
> > RE: [Sip-implementors] Hold SDP
> >
> >
> >
> >
> >
> >
> > Udit
> >
> > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to
a-sendonly.
> >
> >
> >
> > Regards
> > Ranjit
> >
> >
> >
> >
> > -----Original Message-----
> > From: sip-implementors-bounces@cs.columbia.edu
> > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of
> > Udit_Goyal@3com.com
> > Sent: Monday, October 03, 2005 10:42 PM
> > To: SIP Implementors
> > Cc: SIP IETF
> > Subject: [Sip-implementors] Hold SDP
> >
> > Hi,
> >
> > As per RFC 3264, user agent indicate hold by sending "sendonly
attribute
> > (assuming sendrecv mode stream).
> > So when UAS receives this SDP, it should respond with "recvonly"
> > attribute.
> >
> > But same mechanism can be used by user agent if he wants to play
> > announcement or music to user, so it can send "sendonly" attribute
for
> > media stream.
> > I mean if it simply wants one-way connection (this is not hold).
> >
> > For 3PCC (as B2B), if it wants to provide MOH service, how can it
> > differentiate between two SDP because it will play MOH only in the
first
> > scenario when user press hold.
> >
> > Is there any other way where user agent can indicate that this is
hold
> > scenario and not one-way audio.
> >
> > Thanks,
> > Udit
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

--=_alternative 005EEF3E85257090_=-- --===============0472552466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0472552466==-- From sip-bounces@ietf.org Tue Oct 04 13:54:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqzn-0005Yf-KN; Tue, 04 Oct 2005 13:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqzl-0005Ya-TF for sip@megatron.ietf.org; Tue, 04 Oct 2005 13:54:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13518 for ; Tue, 4 Oct 2005 13:54:28 -0400 (EDT) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMr8T-0002yD-Th for sip@ietf.org; Tue, 04 Oct 2005 14:03:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP Date: Tue, 4 Oct 2005 13:54:04 -0400 Message-ID: <8019F8581B5FC14DBD94BAF86844868E86B525@viridis.IPeria.local> Thread-Topic: [Sip] Re: [Sip-implementors] Hold SDP Thread-Index: AcXJB8rT90PmIZDQSDu3FAHWFL/u1QAAEqCw From: "Gordon Ledgard" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: dbff4f0114574f59c864b843e06aef4e Cc: SIP IETF , Paul Kyzivat , SIP Implementors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263931657==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1263931657== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C90C.9CA07C3F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C90C.9CA07C3F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 With Paul's response to Peter Blatherwick, I think I now understand Paul's perspective. =20 Historically, a Hold operation involved a scene using three pieces of equipment; caller A's phone, some intermediate equipment (a PBX) and caller B's phone. The semantics of the operation here are that Caller B forces the PBX equipment to behave a certain way such that caller A now here's something else, while caller B does some other thing. Simple enough and apologies for the obvious. =20 Maybe the issue here, to Paul's point, is that emulating this behavior using the SIP model, is the wrong thing to attempt. In current implementations of this three-piece equipment emulation of Hold, the equipment (B2BUA? App Server?) in the middle tries to interpret some REINVITE from Caller B to mean that it needs to alter Caller A's media, and starts spewing MOH to it. =20 Inventing a mechanism for Caller B to tell the intermediate equipment specifically to "go into this Hold mode" is probably evil, since the behavior would be undefined if there were lots of intervening equipment between Caller A and Caller B. Unfortunately, that is precisely what we have done by building stuff that interprets the SDP exchange as meaning "go into Hold". =20 But maybe inventing a mechanism to allow Caller B to tell Caller A DIRECTLY to "go do whatever you do when you are waiting" is NOT inappropriate. Caller A is now free to play its own music to itself, or to=20 flip over to a music service or whatever. Perhaps this still crosses Paul's line of "IETF does not standardize features". I dunno. =20 This also, I realize, does not address the situation where Caller B's equipment wishes to control the content. :-) But in that event, why do you need to alter Caller A's media at all? =20 =20 Gordon Ledgard, IPeria, Inc. =20 =20 =20 ________________________________ From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]=20 Sent: Tuesday, October 04, 2005 1:25 PM To: Gordon Ledgard Cc: Paul Kyzivat; SIP IETF; SIP Implementors Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP =20 At one point we are saying that hold is a feature,=20 and in RFC 3264, we are saying if you want to put streams on hold, then use "sendonly" attribute,=20 So basically we are giving guidelines for UAC to indicate when it wants to put streams on hold, but not differnetiating when it wants to open one-way media stream.=20 Actually, from UAC to UAS perspective, it is not much of an issue, but for B2B applications, it is certainly an issue.=20 Regarding the different flavous of hold, why do we need to define all flavours, let it be the service responsibilty.=20 I have seen similar thread going on SIPForum-techwg for UA behaviour regarding MOH..=20 "sendonly" attribute indicates that it wants to play some music or announcements...=20 What if UAC does not want to play music and want to hold stream, and services wants to play MOH to other party.=20 Its better if we can just convey the information in SDP, that this is for hold.=20 Regads,=20 Udit=20 "Gordon Ledgard" =20 10/04/2005 10:32 AM=20 To "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com=20 cc =20 Subject RE: [Sip] Re: [Sip-implementors] Hold SDP =20 =20 =20 You guys have piqued my curiosity here. I agree with just about everything you said, Paul, except that I'm not quite sure its so simple to say that hold is a "feature" and not an "attribute". The semantics are fuzzy. To the caller, the action of pressing some "hold" button is an expectation for a particular sort of behavior, music or not. From the perspective of the service receiving the request, the request for the behavior from the caller can be interpreted in a few ways, and thus becomes a "feature". But in any event there seems to be no way to differentiate the users "intent" simply by examining the send/receive attributes of the SDP. Is this not at the heart of the complaint? If so, I think Udit, and many others who have whined about the inadequacy of the send/receive semantics, have a point... why can there not be something to signal this intent? Perhaps we can hash out the distinctions. Gordon. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: Tuesday, October 04, 2005 10:08 AM > To: Udit_Goyal@3com.com > Cc: SIP IETF; SIP Implementors > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > Udit_Goyal@3com.com wrote: > > I want to know is it the genral behaviour of all UAC? > > There are a lot of UAs out there. Its hard to say what the "general" > behavior is. > > > because as per RFC, c=3D0 has not been recommended for RTCP = purposes, > > anyway in these cases, we might need RTCP reports also, > > The use of c=3D0 is an old (now deprecated) action in response to a > request to initiate hold. The mechanism still exists, and is still > important for some call flows unrelated to hold. There is of course > nothing to prevent a UA from using it when initiating Hold, and the peer > should do something reasonable in response. > > > Why cant we have one more attribute "a=3Dhold" which indicates its meant > for > > hold and not for one-way media audio stream, > > I think mostly because hold is a feature, and IETF doesn't standardize > features. The existing directionality attributes are mechanisms that may > be used for hold or other things. > > If you introduced a hold attribute, then there would be a lot of call to > have different flavors of hold - one way, two way, with music, without > music, etc. And of course you would need to get into the precise > semantics of hold. > > As things stand, Hold is a local feature on an endpoint. The > corresponding signaling should not really be considered as signaling > "hold" - it is only signaling the desired media behavior. I think there > is no expectation, or need, for the other UA, or servers in the path to > be able to determine that the call is "held". > > Paul > > > Thanks, > > Udit > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > Sent by: sip-implementors-bounces@cs.columbia.edu > > 10/04/2005 02:23 AM > > > > To > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > cc > > SIP IETF > > Subject > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > Udit > > > > You can use c=3DIN IP4 0.0.0.0 to indicate hold in addition to a-sendonly. > > > > > > > > Regards > > Ranjit > > > > > > > > > > -----Original Message----- > > From: sip-implementors-bounces@cs.columbia.edu > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > Udit_Goyal@3com.com > > Sent: Monday, October 03, 2005 10:42 PM > > To: SIP Implementors > > Cc: SIP IETF > > Subject: [Sip-implementors] Hold SDP > > > > Hi, > > > > As per RFC 3264, user agent indicate hold by sending "sendonly attribute > > (assuming sendrecv mode stream). > > So when UAS receives this SDP, it should respond with "recvonly" > > attribute. > > > > But same mechanism can be used by user agent if he wants to play > > announcement or music to user, so it can send "sendonly" attribute for > > media stream. > > I mean if it simply wants one-way connection (this is not hold). > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > differentiate between two SDP because it will play MOH only in the first > > scenario when user press hold. > > > > Is there any other way where user agent can indicate that this is hold > > scenario and not one-way audio. > > > > Thanks, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C5C90C.9CA07C3F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

With Paul’s response to Peter = Blatherwick, I think I now understand Paul’s = perspective.

 

Historically, a Hold operation = involved a scene using three pieces of equipment; caller A’s = phone,

some intermediate equipment (a PBX) = and caller B’s phone. The semantics of the operation here = are

that Caller B forces the PBX = equipment to behave a certain way such that caller A now here’s = something

else, while caller B does some = other thing.  Simple enough and apologies for the = obvious.

 

Maybe the issue here, to = Paul’s point, is that emulating this behavior using the SIP model, is = the

wrong thing to attempt.  In = current implementations of this three-piece equipment emulation of = Hold,

the equipment (B2BUA? App Server?) = in the middle tries to interpret some REINVITE from Caller = B

to mean that it needs to alter = Caller A’s media, and starts spewing MOH to it.

 

Inventing a mechanism for Caller B = to tell the intermediate equipment specifically to “go into this Hold = mode”

is probably evil, since the = behavior would be undefined if there were lots of intervening equipment = between

Caller A and Caller B. = Unfortunately, that is precisely what we have done by building stuff that interprets = the

SDP exchange as meaning “go = into Hold”.

 

But maybe inventing a mechanism to = allow Caller B to tell Caller A DIRECTLY to “go do whatever you = do

when you are waiting” is NOT inappropriate. Caller A is now free to play its own music to itself, or = to

flip over to a music service or = whatever. Perhaps this still crosses Paul’s line of “IETF does not standardize features”.

I = dunno.

 

This also, I realize, does not = address the situation where Caller B’s equipment wishes to control the = content. J

But in that event, why do you need = to alter Caller A’s media at all?

 

 

Gordon = Ledgard,

IPeria, = Inc.

 

 

 

From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]
Sent: Tuesday, October = 04, 2005 1:25 PM
To: Gordon Ledgard
Cc: Paul Kyzivat; SIP = IETF; SIP Implementors
Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP

 


At one point we are saying that hold is a = feature,
and in RFC 3264, we are saying if you want to put streams on hold, then use "sendonly" attribute,

So basically we are giving guidelines for UAC to indicate when it wants to = put streams on hold, but not differnetiating when it wants to open one-way = media stream.

Actually, from UAC to UAS perspective, it is not much of an issue, but for B2B applications, it is certainly an issue.

Regarding the different flavous of hold, why do we need to define all flavours, = let it be the service responsibilty.

I have seen similar thread going on SIPForum-techwg for UA behaviour = regarding MOH..

"sendonly" attribute indicates that it wants to play some music or = announcements...
What if UAC does not want to play music and want to hold stream, and services = wants to play MOH to other party.

Its better if we can just convey the information in SDP, that this is for = hold.

Regads,
Udit




"Gordon = Ledgard" <gledgard@iperia.com> =

10/04/2005 10:32 AM

To

"Paul Kyzivat" <pkyzivat@cisco.com>, Udit Goyal/C/US/3Com@3Com =

cc

 

Subject

RE: [Sip] Re: [Sip-implementors] Hold = SDP

 

 

 





You guys have piqued my curiosity here.  I agree with just = about
everything
you said, Paul, except that I'm not quite = sure its so simple to say that
hold is a "feature" and not an "attribute".  The semantics are fuzzy.

To the caller, the action of pressing some "hold" button is = an
expectation
for a particular sort of behavior, music = or not. >From the perspective of
the
service receiving the request, the = request for the behavior from the
caller
can be interpreted in a few ways, and = thus becomes a "feature".  But in
any
event there seems to be no way to = differentiate the users "intent"
simply
by examining the send/receive attributes = of the SDP.  Is this not at the
heart of the complaint?


If so, I think Udit, and many others who have whined about = the
inadequacy of
the send/receive semantics, have a = point... why can there not be
something to signal this intent? =  Perhaps we can hash out the
distinctions.


Gordon.




> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Paul
> Kyzivat
> Sent: Tuesday, October 04, 2005 = 10:08 AM
> To: = Udit_Goyal@3com.com
> Cc: SIP IETF; SIP = Implementors
> Subject: [Sip] Re: = [Sip-implementors] Hold SDP
>
>
>
> Udit_Goyal@3com.com = wrote:
> > I want to know is it the genral behaviour of all UAC?
>
> There are a lot of UAs out there. = Its hard to say what the "general"
> behavior is.
>
> > because as per RFC, c=3D0 has = not been recommended for RTCP purposes,
> > anyway in these cases, we might = need RTCP reports also,
>
> The use of c=3D0 is an old (now = deprecated) action in response to a
> request to initiate hold. The = mechanism still exists, and is still
> important for some call flows = unrelated to hold. There is of course
> nothing to prevent a UA from using = it when initiating Hold, and the
peer
> should do something reasonable in = response.
>
> > Why cant we have one more = attribute "a=3Dhold" which indicates its
meant
> for
> > hold and not for one-way media = audio stream,
>
> I think mostly because hold is a = feature, and IETF doesn't standardize
> features. The existing = directionality attributes are mechanisms that
may
> be used for hold or other = things.
>
> If you introduced a hold attribute, = then there would be a lot of call
to
> have different flavors of hold - one = way, two way, with music, without
> music, etc. And of course you would = need to get into the precise
> semantics of hold.
>
> As things stand, Hold is a local = feature on an endpoint. The
> corresponding signaling should not = really be considered as signaling
> "hold" - it is only = signaling the desired media behavior. I think
there
> is no expectation, or need, for the = other UA, or servers in the path
to
> be able to determine that the call = is "held".
>
>         = Paul
>
> > Thanks,
> > Udit
> >
> >
> >
> >
> >
> > "Avasarala = Ranjit-A20990" <ranjit@motorola.com>
> > Sent by: sip-implementors-bounces@cs.columbia.edu
> > 10/04/2005 02:23 = AM
> >
> > To
> > Udit Goyal/C/US/3Com@3Com, = "SIP Implementors"
> > = <sip-implementors@cs.columbia.edu>
> > cc
> > SIP IETF = <sip@ietf.org>
> > Subject
> > RE: [Sip-implementors] Hold = SDP
> >
> >
> >
> >
> >
> >
> > Udit
> >
> > You can use c=3DIN IP4 0.0.0.0 = to indicate hold in addition to
a-sendonly.
> >
> >
> >
> > Regards
> > Ranjit
> >
> >
> >
> >
> > -----Original = Message-----
> > From: sip-implementors-bounces@cs.columbia.edu
> > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf = Of
> > = Udit_Goyal@3com.com
> > Sent: Monday, October 03, 2005 = 10:42 PM
> > To: SIP = Implementors
> > Cc: SIP IETF
> > Subject: [Sip-implementors] = Hold SDP
> >
> > Hi,
> >
> > As per RFC 3264, user agent = indicate hold by sending "sendonly
attribute
> > (assuming sendrecv mode = stream).
> > So when UAS receives this SDP, = it should respond with "recvonly"
> > attribute.
> >
> > But same mechanism can be used = by user agent if he wants to play
> > announcement or music to user, = so it can send "sendonly" attribute
for
> > media stream.
> > I mean if it simply wants = one-way connection (this is not hold).
> >
> > For 3PCC (as B2B), if it wants = to provide MOH service, how can it
> > differentiate between two SDP = because it will play MOH only in the
first
> > scenario when user press = hold.
> >
> > Is there any other way where = user agent can indicate that this is
hold
> > scenario and not one-way = audio.
> >
> > Thanks,
> > Udit
> > _______________________________________________
> > Sip-implementors mailing = list
> > = Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing = list
> > = Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > _______________________________________________
> > Sip-implementors mailing = list
> > = Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of = the core SIP Protocol
> Use sip-implementors@cs.columbia.edu = for questions on current sip
> Use sipping@ietf.org for new = developments on the application of sip

------_=_NextPart_001_01C5C90C.9CA07C3F-- --===============1263931657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1263931657==-- From sip-bounces@ietf.org Tue Oct 04 15:29:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsTX-00022x-C3; Tue, 04 Oct 2005 15:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsTV-0001yC-B4 for sip@megatron.ietf.org; Tue, 04 Oct 2005 15:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19954 for ; Tue, 4 Oct 2005 15:29:15 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMscD-0005dZ-V9 for sip@ietf.org; Tue, 04 Oct 2005 15:38:19 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j94JXtej004117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 4 Oct 2005 14:33:56 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] No dual concurrent registration Date: Tue, 4 Oct 2005 14:29:14 -0500 To: Richard Logan X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Sep 30, 2005, at 9:23 PM, Richard Logan wrote: > Hello, > We recently implemented a SIP phone system and are using the SIP > SRST fall back on our phones. The phones do not support dual > concurrent registration. We were able to get the phones to fail > over to the server which works great. What were NOT able to do was > to get the to fail back over to the SIP server. In other words > once the phones fail over to the router and since the service never > stops the phones never fail back over to the phone system. It > doesn't sound like a big problem but any time we reboot our SIP > phone system the phones fail over. We have been performing a > reload on the switches which kills the power over Ethernet on the > phones to get them operating again. > > Since the phones don't support dual registration Cisco won't help. > Anyone got any ideas? Do I have something configured incorrectly > on my routers? > > Probably not a topic for the SIP list, but I'll be happy to talk to you about it off-list. -- 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 sip-bounces@ietf.org Tue Oct 04 16:29:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtPI-0001FA-CZ; Tue, 04 Oct 2005 16:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtPG-0001F2-Dn; Tue, 04 Oct 2005 16:28:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00332; Tue, 4 Oct 2005 16:28:56 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMtY0-0001Q8-Jp; Tue, 04 Oct 2005 16:38:01 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j94KSPL23437; Tue, 4 Oct 2005 13:28:25 -0700 (PDT) Message-Id: <200510042028.j94KSPL23437@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Oct 2005 13:28:25 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4168 on The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4168 Title: The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) Author(s): J. Rosenberg, H. Schulzrinne, G. Camarillo Status: Standards Track Date: October 2005 Mailbox: jdrosen@cisco.com, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com Pages: 10 Characters: 21079 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-sctp-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4168.txt This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. This document is a product of the Session Initation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051004132714.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4168 --OtherAccess Content-Type: Message/External-body; name="rfc4168.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051004132714.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Tue Oct 04 17:35:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMuRU-0002yl-Gb; Tue, 04 Oct 2005 17:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMuRR-0002yf-UD for sip@megatron.ietf.org; Tue, 04 Oct 2005 17:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10331 for ; Tue, 4 Oct 2005 17:35:15 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMuaB-0005UK-UU for sip@ietf.org; Tue, 04 Oct 2005 17:44:21 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 04 Oct 2005 14:35:06 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="348231071:sNHT31113168" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94LXoh8021939; Wed, 5 Oct 2005 05:34:49 +0800 (CST) Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 05:34:26 +0800 Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 17:32:49 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 17:32:48 -0400 Message-ID: <4342F500.7060602@cisco.com> Date: Tue, 04 Oct 2005 17:32:48 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP References: <072C5B76F7CEAB488172C6F64B30B5E3A2E01C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3A2E01C@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 04 Oct 2005 21:32:48.0677 (UTC) FILETIME=[2AAE4D50:01C5C92B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA10331 Cc: SIP IETF , SIP Implementors , Gordon Ledgard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael Hammer (mhammer) wrote: > Why not a=3Dno-send/no-recv or something equivalent? That would be a=3Dinactive > I think people got too hung up over the character sequence "hold" to=20 > mean exactly the same thing. The problem seems to be that some people want something that means: "I want to keep this call around, and I don't want to deal with the=20 media, but I am hoping some other network element will take care of that=20 for me, without me doing anything more than saying this." I don't buy it, but that seems to be what people are asking for. As far as I am concerned, HOLD is a concept that is known to the UA that=20 initiates it, and nobody else. Others may know that a media stream is=20 sendonly or inactive, but they can't really tell if that is because they=20 have been put on hold or merely that the other party doesn't want to=20 receive their audio. (E.g. I might reinvite with recvonly because my=20 MUTE button was pressed. That doesn't mean the other end put me on hold.) Trying to *define* hold will be a slippery slope. I don't see much=20 upside to trying. Paul > Mike > =20 >=20 > -------------------------------------------------------------------= ----- > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > Behalf Of *Gordon Ledgard > *Sent:* Tuesday, October 04, 2005 1:54 PM > *To:* Udit_Goyal@3com.com > *Cc:* SIP IETF; Paul Kyzivat (pkyzivat); SIP Implementors > *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP >=20 > =20 >=20 > With Paul=92s response to Peter Blatherwick, I think I now understa= nd > Paul=92s perspective. >=20 > =20 >=20 > Historically, a Hold operation involved a scene using three pieces > of equipment; caller A=92s phone, >=20 > some intermediate equipment (a PBX) and caller B=92s phone. The > semantics of the operation here are >=20 > that Caller B forces the PBX equipment to behave a certain way such > that caller A now here=92s something >=20 > else, while caller B does some other thing. Simple enough and > apologies for the obvious. >=20 > =20 >=20 > Maybe the issue here, to Paul=92s point, is that emulating this > behavior using the SIP model, is the >=20 > wrong thing to attempt. In current implementations of this > three-piece equipment emulation of Hold, >=20 > the equipment (B2BUA? App Server?) in the middle tries to interpret > some REINVITE from Caller B >=20 > to mean that it needs to alter Caller A=92s media, and starts spewi= ng > MOH to it. >=20 > =20 >=20 > Inventing a mechanism for Caller B to tell the intermediate > equipment specifically to =93go into this Hold mode=94 >=20 > is probably evil, since the behavior would be undefined if there > were lots of intervening equipment between >=20 > Caller A and Caller B. Unfortunately, that is precisely what we hav= e > done by building stuff that interprets the >=20 > SDP exchange as meaning =93go into Hold=94. >=20 > =20 >=20 > But maybe inventing a mechanism to allow Caller B to tell Caller A > DIRECTLY to =93go do whatever you do >=20 > when you are waiting=94 is NOT inappropriate. Caller A is now free = to > play its own music to itself, or to >=20 > flip over to a music service or whatever. Perhaps this still crosse= s > Paul=92s line of =93IETF does not standardize features=94. >=20 > I dunno. >=20 > =20 >=20 > This also, I realize, does not address the situation where Caller > B=92s equipment wishes to control the content. J >=20 > But in that event, why do you need to alter Caller A=92s media at a= ll? >=20 > =20 >=20 > =20 >=20 > Gordon Ledgard, >=20 > IPeria, Inc. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > -------------------------------------------------------------------= ----- >=20 > *From:* Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] > *Sent:* Tuesday, October 04, 2005 1:25 PM > *To:* Gordon Ledgard > *Cc:* Paul Kyzivat; SIP IETF; SIP Implementors > *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP >=20 > =20 >=20 >=20 > At one point we are saying that hold is a feature, > and in RFC 3264, we are saying if you want to put streams on hold, > then use "sendonly" attribute, >=20 > So basically we are giving guidelines for UAC to indicate when it > wants to put streams on hold, but not differnetiating when it wants > to open one-way media stream. >=20 > Actually, from UAC to UAS perspective, it is not much of an issue, > but for B2B applications, it is certainly an issue. >=20 > Regarding the different flavous of hold, why do we need to define > all flavours, let it be the service responsibilty. >=20 > I have seen similar thread going on SIPForum-techwg for UA behaviou= r > regarding MOH.. >=20 > "sendonly" attribute indicates that it wants to play some music or > announcements... > What if UAC does not want to play music and want to hold stream, an= d > services wants to play MOH to other party. >=20 > Its better if we can just convey the information in SDP, that this > is for hold. >=20 > Regads, > Udit >=20 >=20 >=20 >=20 > *"Gordon Ledgard" * >=20 > 10/04/2005 10:32 AM >=20 > =09 >=20 > To >=20 > =09 >=20 > "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com >=20 > cc >=20 > =09 >=20 > =20 >=20 > Subject >=20 > =09 >=20 > RE: [Sip] Re: [Sip-implementors] Hold SDP >=20 > =20 >=20 > =20 >=20 > =09 >=20 > =20 >=20 >=20 >=20 >=20 >=20 > You guys have piqued my curiosity here. I agree with just about > everything > you said, Paul, except that I'm not quite sure its so simple to say= that > hold is a "feature" and not an "attribute". The semantics are fuzz= y. >=20 > To the caller, the action of pressing some "hold" button is an > expectation > for a particular sort of behavior, music or not. >From the > perspective of > the > service receiving the request, the request for the behavior from th= e > caller > can be interpreted in a few ways, and thus becomes a "feature". Bu= t in > any > event there seems to be no way to differentiate the users "intent" > simply > by examining the send/receive attributes of the SDP. Is this not a= t the > heart of the complaint? >=20 >=20 > If so, I think Udit, and many others who have whined about the > inadequacy of > the send/receive semantics, have a point... why can there not be > something to signal this intent? Perhaps we can hash out the > distinctions. >=20 >=20 > Gordon. >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul >> Kyzivat >> Sent: Tuesday, October 04, 2005 10:08 AM >> To: Udit_Goyal@3com.com >> Cc: SIP IETF; SIP Implementors >> Subject: [Sip] Re: [Sip-implementors] Hold SDP >> >> >> >> Udit_Goyal@3com.com wrote: >> > I want to know is it the genral behaviour of all UAC? >> >> There are a lot of UAs out there. Its hard to say what the "general" >> behavior is. >> >> > because as per RFC, c=3D0 has not been recommended for RTCP purpose= s, >> > anyway in these cases, we might need RTCP reports also, >> >> The use of c=3D0 is an old (now deprecated) action in response to a >> request to initiate hold. The mechanism still exists, and is still >> important for some call flows unrelated to hold. There is of course >> nothing to prevent a UA from using it when initiating Hold, and the > peer >> should do something reasonable in response. >> >> > Why cant we have one more attribute "a=3Dhold" which indicates its > meant >> for >> > hold and not for one-way media audio stream, >> >> I think mostly because hold is a feature, and IETF doesn't standardiz= e >> features. The existing directionality attributes are mechanisms that > may >> be used for hold or other things. >> >> If you introduced a hold attribute, then there would be a lot of call > to >> have different flavors of hold - one way, two way, with music, withou= t >> music, etc. And of course you would need to get into the precise >> semantics of hold. >> >> As things stand, Hold is a local feature on an endpoint. The >> corresponding signaling should not really be considered as signaling >> "hold" - it is only signaling the desired media behavior. I think > there >> is no expectation, or need, for the other UA, or servers in the path > to >> be able to determine that the call is "held". >> >> Paul >> >> > Thanks, >> > Udit >> > >> > >> > >> > >> > >> > "Avasarala Ranjit-A20990" >> > Sent by: sip-implementors-bounces@cs.columbia.edu >> > 10/04/2005 02:23 AM >> > >> > To >> > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" >> > >> > cc >> > SIP IETF >> > Subject >> > RE: [Sip-implementors] Hold SDP >> > >> > >> > >> > >> > >> > >> > Udit >> > >> > You can use c=3DIN IP4 0.0.0.0 to indicate hold in addition to > a-sendonly. >> > >> > >> > >> > Regards >> > Ranjit >> > >> > >> > >> > >> > -----Original Message----- >> > From: sip-implementors-bounces@cs.columbia.edu >> > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of >> > Udit_Goyal@3com.com >> > Sent: Monday, October 03, 2005 10:42 PM >> > To: SIP Implementors >> > Cc: SIP IETF >> > Subject: [Sip-implementors] Hold SDP >> > >> > Hi, >> > >> > As per RFC 3264, user agent indicate hold by sending "sendonly > attribute >> > (assuming sendrecv mode stream). >> > So when UAS receives this SDP, it should respond with "recvonly" >> > attribute. >> > >> > But same mechanism can be used by user agent if he wants to play >> > announcement or music to user, so it can send "sendonly" attribute > for >> > media stream. >> > I mean if it simply wants one-way connection (this is not hold). >> > >> > For 3PCC (as B2B), if it wants to provide MOH service, how can it >> > differentiate between two SDP because it will play MOH only in the > first >> > scenario when user press hold. >> > >> > Is there any other way where user agent can indicate that this is > hold >> > scenario and not one-way audio. >> > >> > Thanks, >> > Udit >> > _______________________________________________ >> > Sip-implementors mailing list >> > Sip-implementors@cs.columbia.edu >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > >> > _______________________________________________ >> > Sip-implementors mailing list >> > Sip-implementors@cs.columbia.edu >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ >> > Sip-implementors mailing list >> > Sip-implementors@cs.columbia.edu >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 17:49:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMufD-0000Ik-Ix; Tue, 04 Oct 2005 17:49:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMufB-0000Ia-JM for sip@megatron.ietf.org; Tue, 04 Oct 2005 17:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11136 for ; Tue, 4 Oct 2005 17:49:26 -0400 (EDT) Received: from bay104-f24.bay104.hotmail.com ([65.54.175.34] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMunu-0005sY-6n for sip@ietf.org; Tue, 04 Oct 2005 17:58:33 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Oct 2005 14:49:17 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Tue, 04 Oct 2005 21:49:16 GMT X-Originating-IP: [65.49.203.195] X-Originating-Email: [whitakercd@hotmail.com] X-Sender: whitakercd@hotmail.com In-Reply-To: <8019F8581B5FC14DBD94BAF86844868E86B525@viridis.IPeria.local> From: "Chris Whitaker" To: gledgard@iperia.com, Udit_Goyal@3com.com Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP Date: Tue, 04 Oct 2005 17:49:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Oct 2005 21:49:17.0457 (UTC) FILETIME=[780A2810:01C5C92D] X-Spam-Score: 0.9 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: sip@ietf.org, pkyzivat@cisco.com, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So after re-reading the original post I am left with the same question I have always had WRT to hold and SDPs. RFC 3264 is a very nice document but why not just tell the truth. If I have gone on hold and my flavour of hold is neither sending nor receiving why would I mark my SDP as sendonly? I am not sendonly. I should HONESTLY state I am inactive no matter what my stream was before. If on the other hand my flavour of hold involves playing music to the other endpoint then I should HONESTLY state I am sendonly [or heck maybe my music oh hold server is a DTMF driven juke box, what fun... ie sendrecv] If a B2B in the middle sees that you are NOT sending then if it wishes to get in the way... let it... after all, some might say it is not in the middle... there are two calls. [A called the B2B and the B2B called B]. As for c=0... well that is very similar to being either inactive or sendonly in so much as you refuse to recv, but it does nothing to indicate if you are sending. An agent in the middle cannot start MoH just because c=0, it is too weak. An agent in the middle must have positive indication that you are NOT sending. c=0 just dosn't cut it. So there is no need for MORE info for an agent in the middle positively know that you are not sending. You just need all UAs to tell the truth [in spite of RFC 3264's recommendation that you fib a little and claim you are sending even if you are not]. Chris >From: "Gordon Ledgard" >To: >CC: SIP IETF , Paul Kyzivat ,SIP >Implementors >Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP >Date: Tue, 4 Oct 2005 13:54:04 -0400 > > > >With Paul's response to Peter Blatherwick, I think I now understand >Paul's perspective. > > > >Historically, a Hold operation involved a scene using three pieces of >equipment; caller A's phone, > >some intermediate equipment (a PBX) and caller B's phone. The semantics >of the operation here are > >that Caller B forces the PBX equipment to behave a certain way such that >caller A now here's something > >else, while caller B does some other thing. Simple enough and apologies >for the obvious. > > > >Maybe the issue here, to Paul's point, is that emulating this behavior >using the SIP model, is the > >wrong thing to attempt. In current implementations of this three-piece >equipment emulation of Hold, > >the equipment (B2BUA? App Server?) in the middle tries to interpret some >REINVITE from Caller B > >to mean that it needs to alter Caller A's media, and starts spewing MOH >to it. > > > >Inventing a mechanism for Caller B to tell the intermediate equipment >specifically to "go into this Hold mode" > >is probably evil, since the behavior would be undefined if there were >lots of intervening equipment between > >Caller A and Caller B. Unfortunately, that is precisely what we have >done by building stuff that interprets the > >SDP exchange as meaning "go into Hold". > > > >But maybe inventing a mechanism to allow Caller B to tell Caller A >DIRECTLY to "go do whatever you do > >when you are waiting" is NOT inappropriate. Caller A is now free to play >its own music to itself, or to > >flip over to a music service or whatever. Perhaps this still crosses >Paul's line of "IETF does not standardize features". > >I dunno. > > > >This also, I realize, does not address the situation where Caller B's >equipment wishes to control the content. :-) > >But in that event, why do you need to alter Caller A's media at all? > > > > > >Gordon Ledgard, > >IPeria, Inc. > > > > > > > >________________________________ > >From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] >Sent: Tuesday, October 04, 2005 1:25 PM >To: Gordon Ledgard >Cc: Paul Kyzivat; SIP IETF; SIP Implementors >Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP > > > > >At one point we are saying that hold is a feature, >and in RFC 3264, we are saying if you want to put streams on hold, then >use "sendonly" attribute, > >So basically we are giving guidelines for UAC to indicate when it wants >to put streams on hold, but not differnetiating when it wants to open >one-way media stream. > >Actually, from UAC to UAS perspective, it is not much of an issue, but >for B2B applications, it is certainly an issue. > >Regarding the different flavous of hold, why do we need to define all >flavours, let it be the service responsibilty. > >I have seen similar thread going on SIPForum-techwg for UA behaviour >regarding MOH.. > >"sendonly" attribute indicates that it wants to play some music or >announcements... >What if UAC does not want to play music and want to hold stream, and >services wants to play MOH to other party. > >Its better if we can just convey the information in SDP, that this is >for hold. > >Regads, >Udit > > > > > > >"Gordon Ledgard" > >10/04/2005 10:32 AM > >To > >"Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com > >cc > > > >Subject > >RE: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > > > > > >You guys have piqued my curiosity here. I agree with just about >everything >you said, Paul, except that I'm not quite sure its so simple to say that >hold is a "feature" and not an "attribute". The semantics are fuzzy. > >To the caller, the action of pressing some "hold" button is an >expectation >for a particular sort of behavior, music or not. From the perspective of >the >service receiving the request, the request for the behavior from the >caller >can be interpreted in a few ways, and thus becomes a "feature". But in >any >event there seems to be no way to differentiate the users "intent" >simply >by examining the send/receive attributes of the SDP. Is this not at the >heart of the complaint? > > >If so, I think Udit, and many others who have whined about the >inadequacy of >the send/receive semantics, have a point... why can there not be >something to signal this intent? Perhaps we can hash out the >distinctions. > > >Gordon. > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Paul > > Kyzivat > > Sent: Tuesday, October 04, 2005 10:08 AM > > To: Udit_Goyal@3com.com > > Cc: SIP IETF; SIP Implementors > > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > > Udit_Goyal@3com.com wrote: > > > I want to know is it the genral behaviour of all UAC? > > > > There are a lot of UAs out there. Its hard to say what the "general" > > behavior is. > > > > > because as per RFC, c=0 has not been recommended for RTCP purposes, > > > anyway in these cases, we might need RTCP reports also, > > > > The use of c=0 is an old (now deprecated) action in response to a > > request to initiate hold. The mechanism still exists, and is still > > important for some call flows unrelated to hold. There is of course > > nothing to prevent a UA from using it when initiating Hold, and the >peer > > should do something reasonable in response. > > > > > Why cant we have one more attribute "a=hold" which indicates its >meant > > for > > > hold and not for one-way media audio stream, > > > > I think mostly because hold is a feature, and IETF doesn't standardize > > features. The existing directionality attributes are mechanisms that >may > > be used for hold or other things. > > > > If you introduced a hold attribute, then there would be a lot of call >to > > have different flavors of hold - one way, two way, with music, without > > music, etc. And of course you would need to get into the precise > > semantics of hold. > > > > As things stand, Hold is a local feature on an endpoint. The > > corresponding signaling should not really be considered as signaling > > "hold" - it is only signaling the desired media behavior. I think >there > > is no expectation, or need, for the other UA, or servers in the path >to > > be able to determine that the call is "held". > > > > Paul > > > > > Thanks, > > > Udit > > > > > > > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > > Sent by: sip-implementors-bounces@cs.columbia.edu > > > 10/04/2005 02:23 AM > > > > > > To > > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > > > cc > > > SIP IETF > > > Subject > > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > > > > > > > > Udit > > > > > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to >a-sendonly. > > > > > > > > > > > > Regards > > > Ranjit > > > > > > > > > > > > > > > -----Original Message----- > > > From: sip-implementors-bounces@cs.columbia.edu > > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > > Udit_Goyal@3com.com > > > Sent: Monday, October 03, 2005 10:42 PM > > > To: SIP Implementors > > > Cc: SIP IETF > > > Subject: [Sip-implementors] Hold SDP > > > > > > Hi, > > > > > > As per RFC 3264, user agent indicate hold by sending "sendonly >attribute > > > (assuming sendrecv mode stream). > > > So when UAS receives this SDP, it should respond with "recvonly" > > > attribute. > > > > > > But same mechanism can be used by user agent if he wants to play > > > announcement or music to user, so it can send "sendonly" attribute >for > > > media stream. > > > I mean if it simply wants one-way connection (this is not hold). > > > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > > differentiate between two SDP because it will play MOH only in the >first > > > scenario when user press hold. > > > > > > Is there any other way where user agent can indicate that this is >hold > > > scenario and not one-way audio. > > > > > > Thanks, > > > Udit > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 17:58:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMunq-00023b-UN; Tue, 04 Oct 2005 17:58:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMuno-00023A-RV for sip@megatron.ietf.org; Tue, 04 Oct 2005 17:58:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11576 for ; Tue, 4 Oct 2005 17:58:21 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMuwY-00066k-E1 for sip@ietf.org; Tue, 04 Oct 2005 18:07:28 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2005 14:57:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="12402267:sNHT185438792" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j94LjhQr005306; Tue, 4 Oct 2005 17:45:49 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 17:45:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP Date: Tue, 4 Oct 2005 17:45:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3A2E03E@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Re: [Sip-implementors] Hold SDP Thread-Index: AcXJKyrptTMOD3MzRtu8tG7mNz0RMAAAHQGw From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 04 Oct 2005 21:45:14.0013 (UTC) FILETIME=[E6EF8CD0:01C5C92C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF , SIP Implementors , Gordon Ledgard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks. That was what I was trying to remember. Agree with your analysis. Even in the PSTN worlds there are differing views about what going on hold means. But, back to the need. Given that the four possible cases (inactive, sendonly, recvonly, sendrecv) are possible, is the issue really about what the far end is expected to do when offered each of these, or is it that the wrong indication is being sent? Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Tuesday, October 04, 2005 5:33 PM > To: Michael Hammer (mhammer) > Cc: Gordon Ledgard; Udit_Goyal@3com.com; SIP IETF; SIP Implementors > Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Why not a=3Dno-send/no-recv or something equivalent? >=20 > That would be a=3Dinactive >=20 > > I think people got too hung up over the character sequence=20 > "hold" to=20 > > mean exactly the same thing. >=20 > The problem seems to be that some people want something that means: >=20 > "I want to keep this call around, and I don't want to deal=20 > with the media, but I am hoping some other network element=20 > will take care of that for me, without me doing anything more=20 > than saying this." >=20 > I don't buy it, but that seems to be what people are asking for. >=20 > As far as I am concerned, HOLD is a concept that is known to=20 > the UA that initiates it, and nobody else. Others may know=20 > that a media stream is sendonly or inactive, but they can't=20 > really tell if that is because they have been put on hold or=20 > merely that the other party doesn't want to receive their=20 > audio. (E.g. I might reinvite with recvonly because my MUTE=20 > button was pressed. That doesn't mean the other end put me on hold.) >=20 > Trying to *define* hold will be a slippery slope. I don't see=20 > much upside to trying. >=20 > Paul >=20 > > Mike > > =20 > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > > Behalf Of *Gordon Ledgard > > *Sent:* Tuesday, October 04, 2005 1:54 PM > > *To:* Udit_Goyal@3com.com > > *Cc:* SIP IETF; Paul Kyzivat (pkyzivat); SIP Implementors > > *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP > >=20 > > =20 > >=20 > > With Paul's response to Peter Blatherwick, I think I=20 > now understand > > Paul's perspective. > >=20 > > =20 > >=20 > > Historically, a Hold operation involved a scene using=20 > three pieces > > of equipment; caller A's phone, > >=20 > > some intermediate equipment (a PBX) and caller B's phone. The > > semantics of the operation here are > >=20 > > that Caller B forces the PBX equipment to behave a=20 > certain way such > > that caller A now here's something > >=20 > > else, while caller B does some other thing. Simple enough and > > apologies for the obvious. > >=20 > > =20 > >=20 > > Maybe the issue here, to Paul's point, is that emulating this > > behavior using the SIP model, is the > >=20 > > wrong thing to attempt. In current implementations of this > > three-piece equipment emulation of Hold, > >=20 > > the equipment (B2BUA? App Server?) in the middle tries=20 > to interpret > > some REINVITE from Caller B > >=20 > > to mean that it needs to alter Caller A's media, and=20 > starts spewing > > MOH to it. > >=20 > > =20 > >=20 > > Inventing a mechanism for Caller B to tell the intermediate > > equipment specifically to "go into this Hold mode" > >=20 > > is probably evil, since the behavior would be undefined if there > > were lots of intervening equipment between > >=20 > > Caller A and Caller B. Unfortunately, that is precisely=20 > what we have > > done by building stuff that interprets the > >=20 > > SDP exchange as meaning "go into Hold". > >=20 > > =20 > >=20 > > But maybe inventing a mechanism to allow Caller B to=20 > tell Caller A > > DIRECTLY to "go do whatever you do > >=20 > > when you are waiting" is NOT inappropriate. Caller A is=20 > now free to > > play its own music to itself, or to > >=20 > > flip over to a music service or whatever. Perhaps this=20 > still crosses > > Paul's line of "IETF does not standardize features". > >=20 > > I dunno. > >=20 > > =20 > >=20 > > This also, I realize, does not address the situation=20 > where Caller > > B's equipment wishes to control the content. J > >=20 > > But in that event, why do you need to alter Caller A's=20 > media at all? > >=20 > > =20 > >=20 > > =20 > >=20 > > Gordon Ledgard, > >=20 > > IPeria, Inc. > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > > =20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > *From:* Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] > > *Sent:* Tuesday, October 04, 2005 1:25 PM > > *To:* Gordon Ledgard > > *Cc:* Paul Kyzivat; SIP IETF; SIP Implementors > > *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP > >=20 > > =20 > >=20 > >=20 > > At one point we are saying that hold is a feature, > > and in RFC 3264, we are saying if you want to put=20 > streams on hold, > > then use "sendonly" attribute, > >=20 > > So basically we are giving guidelines for UAC to=20 > indicate when it > > wants to put streams on hold, but not differnetiating=20 > when it wants > > to open one-way media stream. > >=20 > > Actually, from UAC to UAS perspective, it is not much=20 > of an issue, > > but for B2B applications, it is certainly an issue. > >=20 > > Regarding the different flavous of hold, why do we need=20 > to define > > all flavours, let it be the service responsibilty. > >=20 > > I have seen similar thread going on SIPForum-techwg for=20 > UA behaviour > > regarding MOH.. > >=20 > > "sendonly" attribute indicates that it wants to play=20 > some music or > > announcements... > > What if UAC does not want to play music and want to=20 > hold stream, and > > services wants to play MOH to other party. > >=20 > > Its better if we can just convey the information in=20 > SDP, that this > > is for hold. > >=20 > > Regads, > > Udit > >=20 > >=20 > >=20 > >=20 > > *"Gordon Ledgard" * > >=20 > > 10/04/2005 10:32 AM > >=20 > > =09 > >=20 > > To > >=20 > > =09 > >=20 > > "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com > >=20 > > cc > >=20 > > =09 > >=20 > > =20 > >=20 > > Subject > >=20 > > =09 > >=20 > > RE: [Sip] Re: [Sip-implementors] Hold SDP > >=20 > > =20 > >=20 > > =20 > >=20 > > =09 > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > > You guys have piqued my curiosity here. I agree with just about > > everything > > you said, Paul, except that I'm not quite sure its so=20 > simple to say that > > hold is a "feature" and not an "attribute". The=20 > semantics are fuzzy. > >=20 > > To the caller, the action of pressing some "hold" button is an > > expectation > > for a particular sort of behavior, music or not. >From the > > perspective of > > the > > service receiving the request, the request for the=20 > behavior from the > > caller > > can be interpreted in a few ways, and thus becomes a=20 > "feature". But in > > any > > event there seems to be no way to differentiate the=20 > users "intent" > > simply > > by examining the send/receive attributes of the SDP. =20 > Is this not at the > > heart of the complaint? > >=20 > >=20 > > If so, I think Udit, and many others who have whined about the > > inadequacy of > > the send/receive semantics, have a point... why can there not be > > something to signal this intent? Perhaps we can hash out the > > distinctions. > >=20 > >=20 > > Gordon. > >=20 > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 > On Behalf=20 > >> Of > > Paul > >> Kyzivat > >> Sent: Tuesday, October 04, 2005 10:08 AM > >> To: Udit_Goyal@3com.com > >> Cc: SIP IETF; SIP Implementors > >> Subject: [Sip] Re: [Sip-implementors] Hold SDP > >> > >> > >> > >> Udit_Goyal@3com.com wrote: > >> > I want to know is it the genral behaviour of all UAC? > >> > >> There are a lot of UAs out there. Its hard to say what=20 > the "general" > >> behavior is. > >> > >> > because as per RFC, c=3D0 has not been recommended for RTCP=20 > >> purposes, > anyway in these cases, we might need RTCP=20 > reports also, > >> > >> The use of c=3D0 is an old (now deprecated) action in=20 > response to a =20 > >> request to initiate hold. The mechanism still exists, and=20 > is still =20 > >> important for some call flows unrelated to hold. There is=20 > of course =20 > >> nothing to prevent a UA from using it when initiating Hold, and the > > peer > >> should do something reasonable in response. > >> > >> > Why cant we have one more attribute "a=3Dhold" which indicates = its > > meant > >> for > >> > hold and not for one-way media audio stream, > >> > >> I think mostly because hold is a feature, and IETF doesn't=20 > >> standardize features. The existing directionality attributes are=20 > >> mechanisms that > > may > >> be used for hold or other things. > >> > >> If you introduced a hold attribute, then there would be a lot of=20 > >> call > > to > >> have different flavors of hold - one way, two way, with music,=20 > >> without music, etc. And of course you would need to get into the=20 > >> precise semantics of hold. > >> > >> As things stand, Hold is a local feature on an endpoint. The =20 > >> corresponding signaling should not really be considered as=20 > signaling =20 > >> "hold" - it is only signaling the desired media behavior. I think > > there > >> is no expectation, or need, for the other UA, or servers=20 > in the path > > to > >> be able to determine that the call is "held". > >> > >> Paul > >> > >> > Thanks, > >> > Udit > >> > > >> > > >> > > >> > > >> > > >> > "Avasarala Ranjit-A20990" > Sent by:=20 > >> sip-implementors-bounces@cs.columbia.edu > >> > 10/04/2005 02:23 AM > >> > > >> > To > >> > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > >> > > >> > cc > >> > SIP IETF > >> > Subject > >> > RE: [Sip-implementors] Hold SDP > >> > > >> > > >> > > >> > > >> > > >> > > >> > Udit > >> > > >> > You can use c=3DIN IP4 0.0.0.0 to indicate hold in addition to > > a-sendonly. > >> > > >> > > >> > > >> > Regards > >> > Ranjit > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: sip-implementors-bounces@cs.columbia.edu > >> > [mailto:sip-implementors-bounces@cs.columbia.edu] On=20 > Behalf Of >=20 > >> Udit_Goyal@3com.com > Sent: Monday, October 03, 2005=20 > 10:42 PM > To:=20 > >> SIP Implementors > Cc: SIP IETF > Subject:=20 > [Sip-implementors] Hold=20 > >> SDP > > Hi, > > As per RFC 3264, user agent indicate hold by=20 > >> sending "sendonly > > attribute > >> > (assuming sendrecv mode stream). > >> > So when UAS receives this SDP, it should respond with "recvonly" > >> > attribute. > >> > > >> > But same mechanism can be used by user agent if he=20 > wants to play =20 > >> > announcement or music to user, so it can send "sendonly"=20 > attribute > > for > >> > media stream. > >> > I mean if it simply wants one-way connection (this is not hold). > >> > > >> > For 3PCC (as B2B), if it wants to provide MOH service,=20 > how can it =20 > >> > differentiate between two SDP because it will play MOH=20 > only in the > > first > >> > scenario when user press hold. > >> > > >> > Is there any other way where user agent can indicate=20 > that this is > > hold > >> > scenario and not one-way audio. > >> > > >> > Thanks, > >> > Udit > >> > _______________________________________________ > >> > Sip-implementors mailing list > >> > Sip-implementors@cs.columbia.edu > >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > > >> > _______________________________________________ > >> > Sip-implementors mailing list > >> > Sip-implementors@cs.columbia.edu > >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > _______________________________________________ > >> > Sip-implementors mailing list > >> > Sip-implementors@cs.columbia.edu > >> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 04 19:18:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMw3U-00006G-Ad; Tue, 04 Oct 2005 19:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMw3P-000068-59 for sip@megatron.ietf.org; Tue, 04 Oct 2005 19:18:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15694 for ; Tue, 4 Oct 2005 19:18:31 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler6.mail.eds.com ([199.228.142.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMwCA-0007kU-0u for sip@ietf.org; Tue, 04 Oct 2005 19:27:39 -0400 Received: from plmlir4.mail.eds.com (plmlir4-2.mail.eds.com [199.228.142.134]) by plmler6.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94NF2Mj020820; Tue, 4 Oct 2005 18:15:04 -0500 Received: from plmlir4.mail.eds.com (localhost [127.0.0.1]) by plmlir4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94NEf1x005183; Tue, 4 Oct 2005 18:14:41 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j94NEfe7005178; Tue, 4 Oct 2005 18:14:41 -0500 In-Reply-To: To: "Chris Whitaker" Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 4 Oct 2005 19:21:21 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/04/2005 04:14:40 PM, Serialize complete at 10/04/2005 04:14:40 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 193ac915f0d0b0cc806e665843f7920d Cc: sip@ietf.org, pkyzivat@cisco.com, sip-implementors@cs.columbia.edu, gledgard@iperia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0549467270==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0549467270== Content-Type: multipart/alternative; boundary="=_alternative 007F88F985257090_=" This is a multipart message in MIME format. --=_alternative 007F88F985257090_= Content-Type: text/plain; charset="US-ASCII" "Chris Whitaker" 10/04/2005 05:49 PM To gledgard@iperia.com, Udit Goyal/C/US/3Com@3Com cc sip@ietf.org, pkyzivat@cisco.com, sip-implementors@cs.columbia.edu Subject RE: [Sip] Re: [Sip-implementors] Hold SDP So after re-reading the original post I am left with the same question I have always had WRT to hold and SDPs. RFC 3264 is a very nice document but why not just tell the truth. If I have gone on hold and my flavour of hold is neither sending nor receiving why would I mark my SDP as sendonly? I am not sendonly. I should HONESTLY state I am inactive no matter what my stream was before. >>[Udit] a="inactive" has one more different meaning as per RFC 3264 where you can use it to do capabilities negotiation without actually opening >>media [Udit] streams..same problem will arise as we will have two differnet interpretation of this mode.. RFC 3264 specifically say if media streams >>have to be put on hold, it should use "sendonly attribute, rather it should be if you want to play media/music then it must be sendonly,.. If on the other hand my flavour of hold involves playing music to the other endpoint then I should HONESTLY state I am sendonly [or heck maybe my music oh hold server is a DTMF driven juke box, what fun... ie sendrecv] >>[Udit] This seems ok, and thats what the main concern is, if he doesnt want to d oanything and any third >>party wants to do something, how can it indicate this? If a B2B in the middle sees that you are NOT sending then if it wishes to get in the way... let it... after all, some might say it is not in the middle... there are two calls. [A called the B2B and the B2B called B]. As for c=0... well that is very similar to being either inactive or sendonly in so much as you refuse to recv, but it does nothing to indicate if you are sending. An agent in the middle cannot start MoH just because c=0, it is too weak. An agent in the middle must have positive indication that you are NOT sending. c=0 just dosn't cut it. So there is no need for MORE info for an agent in the middle positively know that you are not sending. You just need all UAs to tell the truth [in spite of RFC 3264's recommendation that you fib a little and claim you are sending even if you are not]. Chris >From: "Gordon Ledgard" >To: >CC: SIP IETF , Paul Kyzivat ,SIP >Implementors >Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP >Date: Tue, 4 Oct 2005 13:54:04 -0400 > > > >With Paul's response to Peter Blatherwick, I think I now understand >Paul's perspective. > > > >Historically, a Hold operation involved a scene using three pieces of >equipment; caller A's phone, > >some intermediate equipment (a PBX) and caller B's phone. The semantics >of the operation here are > >that Caller B forces the PBX equipment to behave a certain way such that >caller A now here's something > >else, while caller B does some other thing. Simple enough and apologies >for the obvious. > > > >Maybe the issue here, to Paul's point, is that emulating this behavior >using the SIP model, is the > >wrong thing to attempt. In current implementations of this three-piece >equipment emulation of Hold, > >the equipment (B2BUA? App Server?) in the middle tries to interpret some >REINVITE from Caller B > >to mean that it needs to alter Caller A's media, and starts spewing MOH >to it. > > > >Inventing a mechanism for Caller B to tell the intermediate equipment >specifically to "go into this Hold mode" > >is probably evil, since the behavior would be undefined if there were >lots of intervening equipment between > >Caller A and Caller B. Unfortunately, that is precisely what we have >done by building stuff that interprets the > >SDP exchange as meaning "go into Hold". > > > >But maybe inventing a mechanism to allow Caller B to tell Caller A >DIRECTLY to "go do whatever you do > >when you are waiting" is NOT inappropriate. Caller A is now free to play >its own music to itself, or to > >flip over to a music service or whatever. Perhaps this still crosses >Paul's line of "IETF does not standardize features". > >I dunno. > > > >This also, I realize, does not address the situation where Caller B's >equipment wishes to control the content. :-) > >But in that event, why do you need to alter Caller A's media at all? > > > > > >Gordon Ledgard, > >IPeria, Inc. > > > > > > > >________________________________ > >From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] >Sent: Tuesday, October 04, 2005 1:25 PM >To: Gordon Ledgard >Cc: Paul Kyzivat; SIP IETF; SIP Implementors >Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP > > > > >At one point we are saying that hold is a feature, >and in RFC 3264, we are saying if you want to put streams on hold, then >use "sendonly" attribute, > >So basically we are giving guidelines for UAC to indicate when it wants >to put streams on hold, but not differnetiating when it wants to open >one-way media stream. > >Actually, from UAC to UAS perspective, it is not much of an issue, but >for B2B applications, it is certainly an issue. > >Regarding the different flavous of hold, why do we need to define all >flavours, let it be the service responsibilty. > >I have seen similar thread going on SIPForum-techwg for UA behaviour >regarding MOH.. > >"sendonly" attribute indicates that it wants to play some music or >announcements... >What if UAC does not want to play music and want to hold stream, and >services wants to play MOH to other party. > >Its better if we can just convey the information in SDP, that this is >for hold. > >Regads, >Udit > > > > > > >"Gordon Ledgard" > >10/04/2005 10:32 AM > >To > >"Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com > >cc > > > >Subject > >RE: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > > > > > >You guys have piqued my curiosity here. I agree with just about >everything >you said, Paul, except that I'm not quite sure its so simple to say that >hold is a "feature" and not an "attribute". The semantics are fuzzy. > >To the caller, the action of pressing some "hold" button is an >expectation >for a particular sort of behavior, music or not. From the perspective of >the >service receiving the request, the request for the behavior from the >caller >can be interpreted in a few ways, and thus becomes a "feature". But in >any >event there seems to be no way to differentiate the users "intent" >simply >by examining the send/receive attributes of the SDP. Is this not at the >heart of the complaint? > > >If so, I think Udit, and many others who have whined about the >inadequacy of >the send/receive semantics, have a point... why can there not be >something to signal this intent? Perhaps we can hash out the >distinctions. > > >Gordon. > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Paul > > Kyzivat > > Sent: Tuesday, October 04, 2005 10:08 AM > > To: Udit_Goyal@3com.com > > Cc: SIP IETF; SIP Implementors > > Subject: [Sip] Re: [Sip-implementors] Hold SDP > > > > > > > > Udit_Goyal@3com.com wrote: > > > I want to know is it the genral behaviour of all UAC? > > > > There are a lot of UAs out there. Its hard to say what the "general" > > behavior is. > > > > > because as per RFC, c=0 has not been recommended for RTCP purposes, > > > anyway in these cases, we might need RTCP reports also, > > > > The use of c=0 is an old (now deprecated) action in response to a > > request to initiate hold. The mechanism still exists, and is still > > important for some call flows unrelated to hold. There is of course > > nothing to prevent a UA from using it when initiating Hold, and the >peer > > should do something reasonable in response. > > > > > Why cant we have one more attribute "a=hold" which indicates its >meant > > for > > > hold and not for one-way media audio stream, > > > > I think mostly because hold is a feature, and IETF doesn't standardize > > features. The existing directionality attributes are mechanisms that >may > > be used for hold or other things. > > > > If you introduced a hold attribute, then there would be a lot of call >to > > have different flavors of hold - one way, two way, with music, without > > music, etc. And of course you would need to get into the precise > > semantics of hold. > > > > As things stand, Hold is a local feature on an endpoint. The > > corresponding signaling should not really be considered as signaling > > "hold" - it is only signaling the desired media behavior. I think >there > > is no expectation, or need, for the other UA, or servers in the path >to > > be able to determine that the call is "held". > > > > Paul > > > > > Thanks, > > > Udit > > > > > > > > > > > > > > > > > > "Avasarala Ranjit-A20990" > > > Sent by: sip-implementors-bounces@cs.columbia.edu > > > 10/04/2005 02:23 AM > > > > > > To > > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" > > > > > > cc > > > SIP IETF > > > Subject > > > RE: [Sip-implementors] Hold SDP > > > > > > > > > > > > > > > > > > > > > Udit > > > > > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to >a-sendonly. > > > > > > > > > > > > Regards > > > Ranjit > > > > > > > > > > > > > > > -----Original Message----- > > > From: sip-implementors-bounces@cs.columbia.edu > > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of > > > Udit_Goyal@3com.com > > > Sent: Monday, October 03, 2005 10:42 PM > > > To: SIP Implementors > > > Cc: SIP IETF > > > Subject: [Sip-implementors] Hold SDP > > > > > > Hi, > > > > > > As per RFC 3264, user agent indicate hold by sending "sendonly >attribute > > > (assuming sendrecv mode stream). > > > So when UAS receives this SDP, it should respond with "recvonly" > > > attribute. > > > > > > But same mechanism can be used by user agent if he wants to play > > > announcement or music to user, so it can send "sendonly" attribute >for > > > media stream. > > > I mean if it simply wants one-way connection (this is not hold). > > > > > > For 3PCC (as B2B), if it wants to provide MOH service, how can it > > > differentiate between two SDP because it will play MOH only in the >first > > > scenario when user press hold. > > > > > > Is there any other way where user agent can indicate that this is >hold > > > scenario and not one-way audio. > > > > > > Thanks, > > > Udit > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip --=_alternative 007F88F985257090_= Content-Type: text/html; charset="US-ASCII"


"Chris Whitaker" <whitakercd@hotmail.com>

10/04/2005 05:49 PM

To
gledgard@iperia.com, Udit Goyal/C/US/3Com@3Com
cc
sip@ietf.org, pkyzivat@cisco.com, sip-implementors@cs.columbia.edu
Subject
RE: [Sip] Re: [Sip-implementors] Hold SDP





So after re-reading the original post I am left with the same question I
have always had WRT to hold and SDPs.  RFC 3264 is a very nice document but
why not just tell the truth.
If I have gone on hold and my flavour of hold is neither sending nor
receiving why would I mark my SDP as sendonly?  I am not sendonly.  I should
HONESTLY state I am inactive no matter what my stream was before.

>>[Udit] a="inactive" has one more different meaning as per RFC 3264 where you can use it to do capabilities negotiation without actually opening >>media [Udit] streams..same problem will arise as we will have two differnet interpretation of this mode.. RFC 3264 specifically say if media streams >>have to be put on hold, it should use "sendonly attribute, rather it should be if you want to play media/music then it must be sendonly,..

If on the other hand my flavour of hold involves playing music to the other
endpoint then I should HONESTLY state I am sendonly [or heck maybe my music
oh hold server is a DTMF driven juke box, what fun... ie sendrecv]
>>[Udit] This seems ok, and thats what the main concern is, if he doesnt want to d oanything and any third >>party wants to do something, how can it indicate this?

If a B2B in the middle sees that you are NOT sending then if it wishes to
get in the way... let it... after all, some might say it is not in the
middle... there are two calls.  [A called the B2B and the B2B called B].
As for c=0... well that is very similar to being either inactive or sendonly
in so much as you refuse to recv, but it does nothing to indicate if you are
sending.  An agent in the middle cannot start MoH just because c=0, it is
too weak.  An agent in the middle must have positive indication that you are
NOT sending.  c=0 just dosn't cut it.
So there is no need for MORE info for an agent in the middle positively know
that you are not sending.  You just need all UAs to tell the truth [in spite
of RFC 3264's recommendation that you fib a little and claim you are sending
even if you are not].
Chris

>From: "Gordon Ledgard" <gledgard@iperia.com>
>To: <Udit_Goyal@3com.com>
>CC: SIP IETF <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,SIP
>Implementors <sip-implementors@cs.columbia.edu>
>Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP
>Date: Tue, 4 Oct 2005 13:54:04 -0400
>
>
>
>With Paul's response to Peter Blatherwick, I think I now understand
>Paul's perspective.
>
>
>
>Historically, a Hold operation involved a scene using three pieces of
>equipment; caller A's phone,
>
>some intermediate equipment (a PBX) and caller B's phone. The semantics
>of the operation here are
>
>that Caller B forces the PBX equipment to behave a certain way such that
>caller A now here's something
>
>else, while caller B does some other thing.  Simple enough and apologies
>for the obvious.
>
>
>
>Maybe the issue here, to Paul's point, is that emulating this behavior
>using the SIP model, is the
>
>wrong thing to attempt.  In current implementations of this three-piece
>equipment emulation of Hold,
>
>the equipment (B2BUA? App Server?) in the middle tries to interpret some
>REINVITE from Caller B
>
>to mean that it needs to alter Caller A's media, and starts spewing MOH
>to it.
>
>
>
>Inventing a mechanism for Caller B to tell the intermediate equipment
>specifically to "go into this Hold mode"
>
>is probably evil, since the behavior would be undefined if there were
>lots of intervening equipment between
>
>Caller A and Caller B. Unfortunately, that is precisely what we have
>done by building stuff that interprets the
>
>SDP exchange as meaning "go into Hold".
>
>
>
>But maybe inventing a mechanism to allow Caller B to tell Caller A
>DIRECTLY to "go do whatever you do
>
>when you are waiting" is NOT inappropriate. Caller A is now free to play
>its own music to itself, or to
>
>flip over to a music service or whatever. Perhaps this still crosses
>Paul's line of "IETF does not standardize features".
>
>I dunno.
>
>
>
>This also, I realize, does not address the situation where Caller B's
>equipment wishes to control the content. :-)
>
>But in that event, why do you need to alter Caller A's media at all?
>
>
>
>
>
>Gordon Ledgard,
>
>IPeria, Inc.
>
>
>
>
>
>
>
>________________________________
>
>From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]
>Sent: Tuesday, October 04, 2005 1:25 PM
>To: Gordon Ledgard
>Cc: Paul Kyzivat; SIP IETF; SIP Implementors
>Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP
>
>
>
>
>At one point we are saying that hold is a feature,
>and in RFC 3264, we are saying if you want to put streams on hold, then
>use "sendonly" attribute,
>
>So basically we are giving guidelines for UAC to indicate when it wants
>to put streams on hold, but not differnetiating when it wants to open
>one-way media stream.
>
>Actually, from UAC to UAS perspective, it is not much of an issue, but
>for B2B applications, it is certainly an issue.
>
>Regarding the different flavous of hold, why do we need to define all
>flavours, let it be the service responsibilty.
>
>I have seen similar thread going on SIPForum-techwg for UA behaviour
>regarding MOH..
>
>"sendonly" attribute indicates that it wants to play some music or
>announcements...
>What if UAC does not want to play music and want to hold stream, and
>services wants to play MOH to other party.
>
>Its better if we can just convey the information in SDP, that this is
>for hold.
>
>Regads,
>Udit
>
>
>
>
>
>
>"Gordon Ledgard" <gledgard@iperia.com>
>
>10/04/2005 10:32 AM
>
>To
>
>"Paul Kyzivat" <pkyzivat@cisco.com>, Udit Goyal/C/US/3Com@3Com
>
>cc
>
>
>
>Subject
>
>RE: [Sip] Re: [Sip-implementors] Hold SDP
>
>
>
>
>
>
>
>
>
>
>
>You guys have piqued my curiosity here.  I agree with just about
>everything
>you said, Paul, except that I'm not quite sure its so simple to say that
>hold is a "feature" and not an "attribute".  The semantics are fuzzy.
>
>To the caller, the action of pressing some "hold" button is an
>expectation
>for a particular sort of behavior, music or not. From the perspective of
>the
>service receiving the request, the request for the behavior from the
>caller
>can be interpreted in a few ways, and thus becomes a "feature".  But in
>any
>event there seems to be no way to differentiate the users "intent"
>simply
>by examining the send/receive attributes of the SDP.  Is this not at the
>heart of the complaint?
>
>
>If so, I think Udit, and many others who have whined about the
>inadequacy of
>the send/receive semantics, have a point... why can there not be
>something to signal this intent?  Perhaps we can hash out the
>distinctions.
>
>
>Gordon.
>
>
>
>
> > -----Original Message-----
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
>Paul
> > Kyzivat
> > Sent: Tuesday, October 04, 2005 10:08 AM
> > To: Udit_Goyal@3com.com
> > Cc: SIP IETF; SIP Implementors
> > Subject: [Sip] Re: [Sip-implementors] Hold SDP
> >
> >
> >
> > Udit_Goyal@3com.com wrote:
> > > I want to know is it the genral behaviour of all UAC?
> >
> > There are a lot of UAs out there. Its hard to say what the "general"
> > behavior is.
> >
> > > because as per RFC, c=0 has not been recommended for RTCP purposes,
> > > anyway in these cases, we might need RTCP reports also,
> >
> > The use of c=0 is an old (now deprecated) action in response to a
> > request to initiate hold. The mechanism still exists, and is still
> > important for some call flows unrelated to hold. There is of course
> > nothing to prevent a UA from using it when initiating Hold, and the
>peer
> > should do something reasonable in response.
> >
> > > Why cant we have one more attribute "a=hold" which indicates its
>meant
> > for
> > > hold and not for one-way media audio stream,
> >
> > I think mostly because hold is a feature, and IETF doesn't standardize
> > features. The existing directionality attributes are mechanisms that
>may
> > be used for hold or other things.
> >
> > If you introduced a hold attribute, then there would be a lot of call
>to
> > have different flavors of hold - one way, two way, with music, without
> > music, etc. And of course you would need to get into the precise
> > semantics of hold.
> >
> > As things stand, Hold is a local feature on an endpoint. The
> > corresponding signaling should not really be considered as signaling
> > "hold" - it is only signaling the desired media behavior. I think
>there
> > is no expectation, or need, for the other UA, or servers in the path
>to
> > be able to determine that the call is "held".
> >
> >         Paul
> >
> > > Thanks,
> > > Udit
> > >
> > >
> > >
> > >
> > >
> > > "Avasarala Ranjit-A20990" <ranjit@motorola.com>
> > > Sent by: sip-implementors-bounces@cs.columbia.edu
> > > 10/04/2005 02:23 AM
> > >
> > > To
> > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors"
> > > <sip-implementors@cs.columbia.edu>
> > > cc
> > > SIP IETF <sip@ietf.org>
> > > Subject
> > > RE: [Sip-implementors] Hold SDP
> > >
> > >
> > >
> > >
> > >
> > >
> > > Udit
> > >
> > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to
>a-sendonly.
> > >
> > >
> > >
> > > Regards
> > > Ranjit
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: sip-implementors-bounces@cs.columbia.edu
> > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of
> > > Udit_Goyal@3com.com
> > > Sent: Monday, October 03, 2005 10:42 PM
> > > To: SIP Implementors
> > > Cc: SIP IETF
> > > Subject: [Sip-implementors] Hold SDP
> > >
> > > Hi,
> > >
> > > As per RFC 3264, user agent indicate hold by sending "sendonly
>attribute
> > > (assuming sendrecv mode stream).
> > > So when UAS receives this SDP, it should respond with "recvonly"
> > > attribute.
> > >
> > > But same mechanism can be used by user agent if he wants to play
> > > announcement or music to user, so it can send "sendonly" attribute
>for
> > > media stream.
> > > I mean if it simply wants one-way connection (this is not hold).
> > >
> > > For 3PCC (as B2B), if it wants to provide MOH service, how can it
> > > differentiate between two SDP because it will play MOH only in the
>first
> > > scenario when user press hold.
> > >
> > > Is there any other way where user agent can indicate that this is
>hold
> > > scenario and not one-way audio.
> > >
> > > Thanks,
> > > Udit
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > Sip-implementors@cs.columbia.edu
> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > Sip-implementors@cs.columbia.edu
> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > Sip-implementors@cs.columbia.edu
> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>
>
>

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

--=_alternative 007F88F985257090_=-- --===============0549467270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0549467270==-- From sip-bounces@ietf.org Wed Oct 05 01:10:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN1Xp-000682-7C; Wed, 05 Oct 2005 01:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN1Xm-00067s-UP for sip@megatron.ietf.org; Wed, 05 Oct 2005 01:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29033 for ; Wed, 5 Oct 2005 01:10:17 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler6.mail.eds.com ([192.85.154.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN1gb-0006jk-Ky for sip@ietf.org; Wed, 05 Oct 2005 01:19:26 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler6.mail.eds.com (8.13.4/8.12.10) with ESMTP id j955A49f022883; Wed, 5 Oct 2005 01:10:07 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9559fgj004416; Wed, 5 Oct 2005 01:09:41 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9559fpU004411; Wed, 5 Oct 2005 01:09:41 -0400 To: "SIP IETF" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 5 Oct 2005 01:16:23 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/04/2005 10:09:41 PM, Serialize complete at 10/04/2005 10:09:41 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: SIP Implementors Subject: [Sip] Offer-answer model X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775045943==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0775045943== Content-Type: multipart/alternative; boundary="=_alternative 001C33F585257091_=" This is a multipart message in MIME format. --=_alternative 001C33F585257091_= Content-Type: text/plain; charset="US-ASCII" Hi, I just want to check if following offer-answer model is valid: Offer: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 Answer: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 c=IN IP4 host.example.com // can it send its own "c" value m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 Thanks, Udit --=_alternative 001C33F585257091_= Content-Type: text/html; charset="US-ASCII"
Hi,

I just want to check if following offer-answer model is valid:

Offer:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

Answer:
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
c=IN IP4 host.example.com // can it send its own "c" value
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000


Thanks,
Udit



--=_alternative 001C33F585257091_=-- --===============0775045943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0775045943==-- From sip-bounces@ietf.org Wed Oct 05 02:32:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2p6-0001B6-81; Wed, 05 Oct 2005 02:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN2p3-0001AS-Qg for sip@megatron.ietf.org; Wed, 05 Oct 2005 02:32:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29980 for ; Wed, 5 Oct 2005 02:32:12 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler8.mail.eds.com ([192.85.154.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN2xr-000083-8X for sip@ietf.org; Wed, 05 Oct 2005 02:41:21 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler8.mail.eds.com (8.13.4/8.12.10) with ESMTP id j956W14n008012; Wed, 5 Oct 2005 02:32:03 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j956VD4q005876; Wed, 5 Oct 2005 02:31:13 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j956VD1o005870; Wed, 5 Oct 2005 02:31:13 -0400 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 5 Oct 2005 02:37:56 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/04/2005 11:31:13 PM, Serialize complete at 10/04/2005 11:31:13 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP IETF Subject: [Sip] Codec negotiation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561273730==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0561273730== Content-Type: multipart/alternative; boundary="=_alternative 0023AB2385257091_=" This is a multipart message in MIME format. --=_alternative 0023AB2385257091_= Content-Type: text/plain; charset="US-ASCII" Hi, As per RFC 3264, mode "inactive" ca nbe used for codec negoitation, Consider the scenario where there is a call established between A and B using codec 1, If A sends Re-invite with media line having direction as "inactive" and codec as 0 and 2 What should be the behaviour of B? If it sends answer with codec 0 and 2 and mode as "inactive" (assume it supports codec 0 and 2), will it indicate that it had only answer the negoitated codec and A and B are still talking using codec 0? OR there is no media between A and B now, if A wants, it can make it active by another offer with the answer codec and "sendrecv" direction? Regards, Udit --=_alternative 0023AB2385257091_= Content-Type: text/html; charset="US-ASCII"
Hi,

As per RFC 3264, mode "inactive" ca nbe used for codec negoitation,

Consider the scenario where there is a call established between A and B using codec 1,

If A sends Re-invite with media line having direction as "inactive" and codec as 0 and 2

What should be the behaviour of B?

If it sends answer with codec 0 and 2 and mode as "inactive" (assume it supports codec 0 and 2),
will it indicate that it had only answer the negoitated codec
and A and B are still talking using codec 0?

OR

there is no media between A and B now, if A wants, it can make it active by another offer with the answer codec and "sendrecv" direction?

Regards,
Udit

--=_alternative 0023AB2385257091_=-- --===============0561273730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0561273730==-- From sip-bounces@ietf.org Wed Oct 05 02:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN32n-0007LI-Re; Wed, 05 Oct 2005 02:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN32m-0007LD-L8 for sip@megatron.ietf.org; Wed, 05 Oct 2005 02:46:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01189 for ; Wed, 5 Oct 2005 02:46:23 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN3BZ-0000X1-CI for sip@ietf.org; Wed, 05 Oct 2005 02:55:32 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0INV00701K0IJ5@siemenscomms.co.uk> for sip@ietf.org; Wed, 05 Oct 2005 07:43:31 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0INV0047OK0IRQ@siemenscomms.co.uk>; Wed, 05 Oct 2005 07:43:30 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 05 Oct 2005 07:45:58 +0100 Content-return: allowed Date: Wed, 05 Oct 2005 07:45:57 +0100 From: "Elwell, John" Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP To: Chris Whitaker , gledgard@iperia.com, Udit_Goyal@3com.com Message-id: <50B1CBA96870A34799A506B2313F26670693F149@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org, pkyzivat@cisco.com, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Chris, You wrote: > So after re-reading the original post I am left with the same > question I > have always had WRT to hold and SDPs. RFC 3264 is a very > nice document but > why not just tell the truth. > > If I have gone on hold and my flavour of hold is neither sending nor > receiving why would I mark my SDP as sendonly? I am not > sendonly. I should > HONESTLY state I am inactive no matter what my stream was before. RFC 3264 does indeed tell you to do that. In section 5.1 it states: "If the offerer wishes to communicate, but wishes to neither send nor receive media at this time, it MUST mark the stream with an "a=inactive" attribute." The problem is, this appears to be contradicted elsewhere. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 05 07:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN7Lj-0006CP-Dc; Wed, 05 Oct 2005 07:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN7Lh-0006CK-RM for sip@megatron.ietf.org; Wed, 05 Oct 2005 07:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16116 for ; Wed, 5 Oct 2005 07:22:12 -0400 (EDT) Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN7UV-00008V-2n for sip@ietf.org; Wed, 05 Oct 2005 07:31:24 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Sip] Offer-answer model Date: Wed, 5 Oct 2005 12:21:45 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23772@veg-brk-svr-pri.vegastream> Thread-Topic: [Sip] Offer-answer model thread-index: AcXJa3uztp6A3A1eRW6jZK/vbOqUrQAM5dDw From: "Attila Sipos" To: , "SIP IETF" X-Spam-Score: 0.3 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: SIP Implementors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582706558==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0582706558== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C99E.F7FDBFE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C99E.F7FDBFE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Udit, =20 I feel your offer-answer is valid with respect to the "m=3D" and "c=3D" lines (make sure that you include all mandatory lines). =20 If the audio media has a different connection address then it is completely valid to put the extra "c=3D" under the "m=3Daudio" line. =20 It is also valid because for every "m=3D" line in the offer, there is a matching "m=3D" line in the offer. =20 Regards, Attila =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: 05 October 2005 06:16 To: SIP IETF Cc: SIP Implementors Subject: [Sip] Offer-answer model Hi,=20 I just want to check if following offer-answer model is valid:=20 Offer:=20 v=3D0=20 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com=20 s=3D=20 c=3DIN IP4 host.anywhere.com=20 t=3D0 0=20 m=3Daudio 49170 RTP/AVP 0=20 a=3Drtpmap:0 PCMU/8000=20 m=3Dvideo 51372 RTP/AVP 31=20 a=3Drtpmap:31 H261/90000=20 m=3Dvideo 53000 RTP/AVP 32=20 a=3Drtpmap:32 MPV/90000=20 Answer:=20 v=3D0=20 o=3Dbob 2890844730 2890844730 IN IP4 host.example.com=20 s=3D=20 c=3DIN IP4 host.example.com=20 t=3D0 0=20 m=3Daudio 49920 RTP/AVP 0=20 a=3Drtpmap:0 PCMU/8000=20 c=3DIN IP4 host.example.com // can it send its own "c" value=20 m=3Dvideo 0 RTP/AVP 31=20 m=3Dvideo 53000 RTP/AVP 32=20 a=3Drtpmap:32 MPV/90000=20 Thanks,=20 Udit=20 ------_=_NextPart_001_01C5C99E.F7FDBFE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Udit,
 
I feel=20 your offer-answer is valid with respect to the = "m=3D"
and=20 "c=3D" lines (make sure that you include all mandatory = lines).
 
If the=20 audio media has a different connection address
then=20 it is completely valid to put the extra = "c=3D" under
the=20 "m=3Daudio" line.
 
It is=20 also valid because for every "m=3D" line in the offer, = there
is a=20 matching "m=3D" line in the offer.
 
Regards,

Attila
 
Attila Sipos
http://www.vegastream.com
 
 
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of=20 Udit_Goyal@3com.com
Sent: 05 October 2005 = 06:16
To:=20 SIP IETF
Cc: SIP Implementors
Subject: [Sip] = Offer-answer=20 model


Hi,=20

I just want to check if = following=20 offer-answer model is valid:

Offer:
v=3D0
o=3Dalice 2890844526 2890844526 IN IP4=20 host.anywhere.com
s=3D
c=3DIN IP4 host.anywhere.com =
t=3D0 0
m=3Daudio=20 49170 RTP/AVP 0
a=3Drtpmap:0=20 PCMU/8000
m=3Dvideo 51372 = RTP/AVP=20 31
a=3Drtpmap:31 = H261/90000=20
m=3Dvideo 53000 RTP/AVP 32 =
a=3Drtpmap:32 MPV/90000 =

Answer:
v=3D0
o=3Dbob = 2890844730 2890844730=20 IN IP4 host.example.com
s=3D=20
c=3DIN IP4 = host.example.com
t=3D0 0
m=3Daudio=20 49920 RTP/AVP 0
a=3Drtpmap:0=20 PCMU/8000
c=3DIN IP4 = host.example.com=20 // can it send its own "c" value
m=3Dvideo 0 RTP/AVP 31
m=3Dvideo=20 53000 RTP/AVP 32
a=3Drtpmap:32=20 MPV/90000


Thanks,=20
Udit=20



------_=_NextPart_001_01C5C99E.F7FDBFE8-- --===============0582706558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0582706558==-- From sip-bounces@ietf.org Wed Oct 05 08:55:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8nz-0006Tf-LZ; Wed, 05 Oct 2005 08:55:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN8nx-0006Ta-00 for sip@megatron.ietf.org; Wed, 05 Oct 2005 08:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21160 for ; Wed, 5 Oct 2005 08:55:27 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN8wp-0002td-2b for sip@ietf.org; Wed, 05 Oct 2005 09:04:40 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 05 Oct 2005 05:55:18 -0700 X-IronPort-AV: i="3.97,177,1125903600"; d="scan'208"; a="348467922:sNHT24848362" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j95CssKQ011687; Wed, 5 Oct 2005 05:55:16 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 08:55:10 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 08:55:10 -0400 Message-ID: <4343CD2D.3000709@cisco.com> Date: Wed, 05 Oct 2005 08:55:09 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Udit_Goyal@3com.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 12:55:10.0189 (UTC) FILETIME=[04CAE1D0:01C5C9AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: SIP IETF , SIP Implementors Subject: [Sip] Re: [Sip-implementors] Codec negotiation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Udit_Goyal@3com.com wrote: > Hi, > > As per RFC 3264, mode "inactive" ca nbe used for codec negoitation, > > Consider the scenario where there is a call established between A and B > using codec 1, > > If A sends Re-invite with media line having direction as "inactive" and > codec as 0 and 2 > > What should be the behaviour of B? > > If it sends answer with codec 0 and 2 and mode as "inactive" (assume it > supports codec 0 and 2), > will it indicate that it had only answer the negoitated codec > and A and B are still talking using codec 0? This is clearly wrong. The offer/answer has succeeded, and the direction is "inactive", so this has superceded the previous agreement. > OR > > there is no media between A and B now, if A wants, it can make it active > by another offer with the answer codec and "sendrecv" direction? This must be the interpretation. 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 sip-bounces@ietf.org Wed Oct 05 09:15:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN96v-0005q8-8x; Wed, 05 Oct 2005 09:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN96t-0005nE-2x for sip@megatron.ietf.org; Wed, 05 Oct 2005 09:15:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22205 for ; Wed, 5 Oct 2005 09:15:01 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN9Fl-0003Qb-Ld for sip@ietf.org; Wed, 05 Oct 2005 09:24:14 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2005 15:14:51 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j95DEGTI010493; Wed, 5 Oct 2005 15:14:48 +0200 (MEST) Received: from xbh-rtp-211.amer.cisco.com ([64.102.31.102]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 15:14:40 +0200 Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 09:14:34 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 09:14:33 -0400 Message-ID: <4343D1B9.1030906@cisco.com> Date: Wed, 05 Oct 2005 09:14:33 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP References: <072C5B76F7CEAB488172C6F64B30B5E3A2E03E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3A2E03E@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 13:14:33.0916 (UTC) FILETIME=[BA6D87C0:01C5C9AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc Content-Transfer-Encoding: 7bit Cc: SIP IETF , SIP Implementors , Gordon Ledgard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael Hammer (mhammer) wrote: > Thanks. That was what I was trying to remember. Agree with your > analysis. Even in the PSTN worlds there are differing views about what > going on hold means. But, back to the need. Given that the four > possible cases (inactive, sendonly, recvonly, sendrecv) are possible, is > the issue really about what the far end is expected to do when offered > each of these, or is it that the wrong indication is being sent? IMO it is pretty clear what the far end is supposed to do: - if offered inactive, it MUST answer inactive. It should not expect to receive anything. What to do if it happens to receive something is not specified. (But see below.) It SHOULD NOT send anything. (But see below.) - if offered sendonly, it may answer recvonly or inactive. Which to answer is unspecified and up to it. It then does not send anything. If it answered recvonly it should receive. What it does with the stuff it receives is up to it. - if offered recvonly, it may answer sendonly or inactive. Which to answer is unspecified and up to it. It should expect not to receive anything. What it should do if it happens to receive something is not specified. (But see below.) If it answered sendonly, then it MAY send. Where it gets the stuff it sends is up to it. - if offered sendrecv, it may answer with any of the four directionalities. Which to answer is unspecified and up to it. It then sends and receives according to its answer, as above. As always, where it gets the stuff it sends, and what it does with the stuff it receives is up to it. ICE and NAT traversal lead to a requirement to violate the directionality requirements slightly. For inactive and recvonly, you may still need to send occasionally - a STUN packet, or a noop packet, or perhaps some comfort noise. I haven't been following this closely, so I won't try to spell this out in detail. But the point is to trickle something to keep a NAT binding open for traffic in the reverse direction. The flip side of that is that one should be prepared to receive this traffic, and presumably ignore it. (Well, for STUN, you would have to respond to it.) None of this expects or requires one side to know that the other side has "put it on hold". In fact, it is impossible to know that, since these directionality attributes are needed for other call flows that have nothing to do with hold. Paul > Mike > > > >>-----Original Message----- >>From: Paul Kyzivat (pkyzivat) >>Sent: Tuesday, October 04, 2005 5:33 PM >>To: Michael Hammer (mhammer) >>Cc: Gordon Ledgard; Udit_Goyal@3com.com; SIP IETF; SIP Implementors >>Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP >> >> >> >>Michael Hammer (mhammer) wrote: >> >>>Why not a=no-send/no-recv or something equivalent? >> >>That would be a=inactive >> >> >>>I think people got too hung up over the character sequence >> >>"hold" to >> >>>mean exactly the same thing. >> >>The problem seems to be that some people want something that means: >> >>"I want to keep this call around, and I don't want to deal >>with the media, but I am hoping some other network element >>will take care of that for me, without me doing anything more >>than saying this." >> >>I don't buy it, but that seems to be what people are asking for. >> >>As far as I am concerned, HOLD is a concept that is known to >>the UA that initiates it, and nobody else. Others may know >>that a media stream is sendonly or inactive, but they can't >>really tell if that is because they have been put on hold or >>merely that the other party doesn't want to receive their >>audio. (E.g. I might reinvite with recvonly because my MUTE >>button was pressed. That doesn't mean the other end put me on hold.) >> >>Trying to *define* hold will be a slippery slope. I don't see >>much upside to trying. >> >> Paul >> >> >>>Mike >>> >>> >>> >> >>-------------------------------------------------------------- >>---------- >> >>> *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On >>> Behalf Of *Gordon Ledgard >>> *Sent:* Tuesday, October 04, 2005 1:54 PM >>> *To:* Udit_Goyal@3com.com >>> *Cc:* SIP IETF; Paul Kyzivat (pkyzivat); SIP Implementors >>> *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP >>> >>> >>> >>> With Paul's response to Peter Blatherwick, I think I >> >>now understand >> >>> Paul's perspective. >>> >>> >>> >>> Historically, a Hold operation involved a scene using >> >>three pieces >> >>> of equipment; caller A's phone, >>> >>> some intermediate equipment (a PBX) and caller B's phone. The >>> semantics of the operation here are >>> >>> that Caller B forces the PBX equipment to behave a >> >>certain way such >> >>> that caller A now here's something >>> >>> else, while caller B does some other thing. Simple enough and >>> apologies for the obvious. >>> >>> >>> >>> Maybe the issue here, to Paul's point, is that emulating this >>> behavior using the SIP model, is the >>> >>> wrong thing to attempt. In current implementations of this >>> three-piece equipment emulation of Hold, >>> >>> the equipment (B2BUA? App Server?) in the middle tries >> >>to interpret >> >>> some REINVITE from Caller B >>> >>> to mean that it needs to alter Caller A's media, and >> >>starts spewing >> >>> MOH to it. >>> >>> >>> >>> Inventing a mechanism for Caller B to tell the intermediate >>> equipment specifically to "go into this Hold mode" >>> >>> is probably evil, since the behavior would be undefined if there >>> were lots of intervening equipment between >>> >>> Caller A and Caller B. Unfortunately, that is precisely >> >>what we have >> >>> done by building stuff that interprets the >>> >>> SDP exchange as meaning "go into Hold". >>> >>> >>> >>> But maybe inventing a mechanism to allow Caller B to >> >>tell Caller A >> >>> DIRECTLY to "go do whatever you do >>> >>> when you are waiting" is NOT inappropriate. Caller A is >> >>now free to >> >>> play its own music to itself, or to >>> >>> flip over to a music service or whatever. Perhaps this >> >>still crosses >> >>> Paul's line of "IETF does not standardize features". >>> >>> I dunno. >>> >>> >>> >>> This also, I realize, does not address the situation >> >>where Caller >> >>> B's equipment wishes to control the content. J >>> >>> But in that event, why do you need to alter Caller A's >> >>media at all? >> >>> >>> >>> >>> >>> Gordon Ledgard, >>> >>> IPeria, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>> *From:* Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] >>> *Sent:* Tuesday, October 04, 2005 1:25 PM >>> *To:* Gordon Ledgard >>> *Cc:* Paul Kyzivat; SIP IETF; SIP Implementors >>> *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP >>> >>> >>> >>> >>> At one point we are saying that hold is a feature, >>> and in RFC 3264, we are saying if you want to put >> >>streams on hold, >> >>> then use "sendonly" attribute, >>> >>> So basically we are giving guidelines for UAC to >> >>indicate when it >> >>> wants to put streams on hold, but not differnetiating >> >>when it wants >> >>> to open one-way media stream. >>> >>> Actually, from UAC to UAS perspective, it is not much >> >>of an issue, >> >>> but for B2B applications, it is certainly an issue. >>> >>> Regarding the different flavous of hold, why do we need >> >>to define >> >>> all flavours, let it be the service responsibilty. >>> >>> I have seen similar thread going on SIPForum-techwg for >> >>UA behaviour >> >>> regarding MOH.. >>> >>> "sendonly" attribute indicates that it wants to play >> >>some music or >> >>> announcements... >>> What if UAC does not want to play music and want to >> >>hold stream, and >> >>> services wants to play MOH to other party. >>> >>> Its better if we can just convey the information in >> >>SDP, that this >> >>> is for hold. >>> >>> Regads, >>> Udit >>> >>> >>> >>> >>> *"Gordon Ledgard" * >>> >>> 10/04/2005 10:32 AM >>> >>> >>> >>> To >>> >>> >>> >>> "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com >>> >>> cc >>> >>> >>> >>> >>> >>> Subject >>> >>> >>> >>> RE: [Sip] Re: [Sip-implementors] Hold SDP >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> You guys have piqued my curiosity here. I agree with just about >>> everything >>> you said, Paul, except that I'm not quite sure its so >> >>simple to say that >> >>> hold is a "feature" and not an "attribute". The >> >>semantics are fuzzy. >> >>> To the caller, the action of pressing some "hold" button is an >>> expectation >>> for a particular sort of behavior, music or not. >From the >>> perspective of >>> the >>> service receiving the request, the request for the >> >>behavior from the >> >>> caller >>> can be interpreted in a few ways, and thus becomes a >> >>"feature". But in >> >>> any >>> event there seems to be no way to differentiate the >> >>users "intent" >> >>> simply >>> by examining the send/receive attributes of the SDP. >> >>Is this not at the >> >>> heart of the complaint? >>> >>> >>> If so, I think Udit, and many others who have whined about the >>> inadequacy of >>> the send/receive semantics, have a point... why can there not be >>> something to signal this intent? Perhaps we can hash out the >>> distinctions. >>> >>> >>> Gordon. >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] >> >>On Behalf >> >>>>Of >>> >>> Paul >>> >>>> Kyzivat >>>> Sent: Tuesday, October 04, 2005 10:08 AM >>>> To: Udit_Goyal@3com.com >>>> Cc: SIP IETF; SIP Implementors >>>> Subject: [Sip] Re: [Sip-implementors] Hold SDP >>>> >>>> >>>> >>>> Udit_Goyal@3com.com wrote: >>>> > I want to know is it the genral behaviour of all UAC? >>>> >>>> There are a lot of UAs out there. Its hard to say what >> >>the "general" >> >>>> behavior is. >>>> >>>> > because as per RFC, c=0 has not been recommended for RTCP >>>>purposes, > anyway in these cases, we might need RTCP >> >>reports also, >> >>>> The use of c=0 is an old (now deprecated) action in >> >>response to a >> >>>>request to initiate hold. The mechanism still exists, and >> >>is still >> >>>>important for some call flows unrelated to hold. There is >> >>of course >> >>>>nothing to prevent a UA from using it when initiating Hold, and the >>> >>> peer >>> >>>> should do something reasonable in response. >>>> >>>> > Why cant we have one more attribute "a=hold" which indicates its >>> >>> meant >>> >>>> for >>>> > hold and not for one-way media audio stream, >>>> >>>> I think mostly because hold is a feature, and IETF doesn't >>>>standardize features. The existing directionality attributes are >>>>mechanisms that >>> >>> may >>> >>>> be used for hold or other things. >>>> >>>> If you introduced a hold attribute, then there would be a lot of >>>>call >>> >>> to >>> >>>> have different flavors of hold - one way, two way, with music, >>>>without music, etc. And of course you would need to get into the >>>>precise semantics of hold. >>>> >>>> As things stand, Hold is a local feature on an endpoint. The >>>>corresponding signaling should not really be considered as >> >>signaling >> >>>>"hold" - it is only signaling the desired media behavior. I think >>> >>> there >>> >>>> is no expectation, or need, for the other UA, or servers >> >>in the path >> >>> to >>> >>>> be able to determine that the call is "held". >>>> >>>> Paul >>>> >>>> > Thanks, >>>> > Udit >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > "Avasarala Ranjit-A20990" > Sent by: >>>>sip-implementors-bounces@cs.columbia.edu >>>> > 10/04/2005 02:23 AM >>>> > >>>> > To >>>> > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" >>>> > >>>> > cc >>>> > SIP IETF >>>> > Subject >>>> > RE: [Sip-implementors] Hold SDP >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Udit >>>> > >>>> > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to >>> >>> a-sendonly. >>> >>>> > >>>> > >>>> > >>>> > Regards >>>> > Ranjit >>>> > >>>> > >>>> > >>>> > >>>> > -----Original Message----- >>>> > From: sip-implementors-bounces@cs.columbia.edu >>>> > [mailto:sip-implementors-bounces@cs.columbia.edu] On >> >>Behalf Of > >> >>>>Udit_Goyal@3com.com > Sent: Monday, October 03, 2005 >> >>10:42 PM > To: >> >>>>SIP Implementors > Cc: SIP IETF > Subject: >> >>[Sip-implementors] Hold >> >>>>SDP > > Hi, > > As per RFC 3264, user agent indicate hold by >>>>sending "sendonly >>> >>> attribute >>> >>>> > (assuming sendrecv mode stream). >>>> > So when UAS receives this SDP, it should respond with "recvonly" >>>> > attribute. >>>> > >>>> > But same mechanism can be used by user agent if he >> >>wants to play >> >>>>>announcement or music to user, so it can send "sendonly" >> >>attribute >> >>> for >>> >>>> > media stream. >>>> > I mean if it simply wants one-way connection (this is not hold). >>>> > >>>> > For 3PCC (as B2B), if it wants to provide MOH service, >> >>how can it >> >>>>>differentiate between two SDP because it will play MOH >> >>only in the >> >>> first >>> >>>> > scenario when user press hold. >>>> > >>>> > Is there any other way where user agent can indicate >> >>that this is >> >>> hold >>> >>>> > scenario and not one-way audio. >>>> > >>>> > Thanks, >>>> > Udit >>>> > _______________________________________________ >>>> > Sip-implementors mailing list >>>> > Sip-implementors@cs.columbia.edu >>>> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> > >>>> > _______________________________________________ >>>> > Sip-implementors mailing list >>>> > Sip-implementors@cs.columbia.edu >>>> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> > _______________________________________________ >>>> > Sip-implementors mailing list >>>> > Sip-implementors@cs.columbia.edu >>>> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> > >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 05 09:22:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9EE-0007Qb-D1; Wed, 05 Oct 2005 09:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9EC-0007QW-62 for sip@megatron.ietf.org; Wed, 05 Oct 2005 09:22:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22609 for ; Wed, 5 Oct 2005 09:22:34 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN9N4-0003dw-5c for sip@ietf.org; Wed, 05 Oct 2005 09:31:47 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 Oct 2005 06:22:25 -0700 X-IronPort-AV: i="3.97,177,1125903600"; d="scan'208"; a="348473450:sNHT30205444" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j95DMF4b003688; Wed, 5 Oct 2005 06:22:23 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 09:22:05 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 09:22:05 -0400 Message-ID: <4343D37D.3020809@cisco.com> Date: Wed, 05 Oct 2005 09:22:05 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Whitaker Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2005 13:22:05.0522 (UTC) FILETIME=[C79B2320:01C5C9AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, gledgard@iperia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Chris Whitaker wrote: > So after re-reading the original post I am left with the same question I > have always had WRT to hold and SDPs. RFC 3264 is a very nice document > but why not just tell the truth. I haven't read it recently. But from memory I believe that 3264 is probably over-reaching in its statements about hold. At best I think they should be *examples* of what one *might* do upon local invocation of a HOLD feature. > If I have gone on hold and my flavour of hold is neither sending nor > receiving why would I mark my SDP as sendonly? I am not sendonly. I > should HONESTLY state I am inactive no matter what my stream was before. I agree with you. > If on the other hand my flavour of hold involves playing music to the > other endpoint then I should HONESTLY state I am sendonly [or heck maybe > my music oh hold server is a DTMF driven juke box, what fun... ie sendrecv] Yes. > If a B2B in the middle sees that you are NOT sending then if it wishes > to get in the way... let it... after all, some might say it is not in > the middle... there are two calls. [A called the B2B and the B2B called > B]. Well, given that a B2BUA can do pretty much anything, I agree with you. To the extent that the B2BUA is trying to be mostly transparent, and "just trying to help", I think it will be making a mistake to do this. There are many cases where butting in and sending something, in lieu of the endpoint doing so, will be just plain wrong. Of course, if the B2BUA knows its UAs well, and is certain there are no such cases, then this may be appropriate for it to do. But not in general. > As for c=0... well that is very similar to being either inactive or > sendonly in so much as you refuse to recv, but it does nothing to > indicate if you are sending. An agent in the middle cannot start MoH > just because c=0, it is too weak. An agent in the middle must have > positive indication that you are NOT sending. c=0 just dosn't cut it. So I agree with you here, except that I don't think the other case is any stronger than this one. Paul > So there is no need for MORE info for an agent in the middle positively > know that you are not sending. You just need all UAs to tell the truth > [in spite of RFC 3264's recommendation that you fib a little and claim > you are sending even if you are not]. > > Chris > > >> From: "Gordon Ledgard" >> To: >> CC: SIP IETF , Paul Kyzivat ,SIP >> Implementors >> Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP >> Date: Tue, 4 Oct 2005 13:54:04 -0400 >> >> >> >> With Paul's response to Peter Blatherwick, I think I now understand >> Paul's perspective. >> >> >> >> Historically, a Hold operation involved a scene using three pieces of >> equipment; caller A's phone, >> >> some intermediate equipment (a PBX) and caller B's phone. The semantics >> of the operation here are >> >> that Caller B forces the PBX equipment to behave a certain way such that >> caller A now here's something >> >> else, while caller B does some other thing. Simple enough and apologies >> for the obvious. >> >> >> >> Maybe the issue here, to Paul's point, is that emulating this behavior >> using the SIP model, is the >> >> wrong thing to attempt. In current implementations of this three-piece >> equipment emulation of Hold, >> >> the equipment (B2BUA? App Server?) in the middle tries to interpret some >> REINVITE from Caller B >> >> to mean that it needs to alter Caller A's media, and starts spewing MOH >> to it. >> >> >> >> Inventing a mechanism for Caller B to tell the intermediate equipment >> specifically to "go into this Hold mode" >> >> is probably evil, since the behavior would be undefined if there were >> lots of intervening equipment between >> >> Caller A and Caller B. Unfortunately, that is precisely what we have >> done by building stuff that interprets the >> >> SDP exchange as meaning "go into Hold". >> >> >> >> But maybe inventing a mechanism to allow Caller B to tell Caller A >> DIRECTLY to "go do whatever you do >> >> when you are waiting" is NOT inappropriate. Caller A is now free to play >> its own music to itself, or to >> >> flip over to a music service or whatever. Perhaps this still crosses >> Paul's line of "IETF does not standardize features". >> >> I dunno. >> >> >> >> This also, I realize, does not address the situation where Caller B's >> equipment wishes to control the content. :-) >> >> But in that event, why do you need to alter Caller A's media at all? >> >> >> >> >> >> Gordon Ledgard, >> >> IPeria, Inc. >> >> >> >> >> >> >> >> ________________________________ >> >> From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] >> Sent: Tuesday, October 04, 2005 1:25 PM >> To: Gordon Ledgard >> Cc: Paul Kyzivat; SIP IETF; SIP Implementors >> Subject: RE: [Sip] Re: [Sip-implementors] Hold SDP >> >> >> >> >> At one point we are saying that hold is a feature, >> and in RFC 3264, we are saying if you want to put streams on hold, then >> use "sendonly" attribute, >> >> So basically we are giving guidelines for UAC to indicate when it wants >> to put streams on hold, but not differnetiating when it wants to open >> one-way media stream. >> >> Actually, from UAC to UAS perspective, it is not much of an issue, but >> for B2B applications, it is certainly an issue. >> >> Regarding the different flavous of hold, why do we need to define all >> flavours, let it be the service responsibilty. >> >> I have seen similar thread going on SIPForum-techwg for UA behaviour >> regarding MOH.. >> >> "sendonly" attribute indicates that it wants to play some music or >> announcements... >> What if UAC does not want to play music and want to hold stream, and >> services wants to play MOH to other party. >> >> Its better if we can just convey the information in SDP, that this is >> for hold. >> >> Regads, >> Udit >> >> >> >> >> >> >> "Gordon Ledgard" >> >> 10/04/2005 10:32 AM >> >> To >> >> "Paul Kyzivat" , Udit Goyal/C/US/3Com@3Com >> >> cc >> >> >> >> Subject >> >> RE: [Sip] Re: [Sip-implementors] Hold SDP >> >> >> >> >> >> >> >> >> >> >> >> You guys have piqued my curiosity here. I agree with just about >> everything >> you said, Paul, except that I'm not quite sure its so simple to say that >> hold is a "feature" and not an "attribute". The semantics are fuzzy. >> >> To the caller, the action of pressing some "hold" button is an >> expectation >> for a particular sort of behavior, music or not. From the perspective of >> the >> service receiving the request, the request for the behavior from the >> caller >> can be interpreted in a few ways, and thus becomes a "feature". But in >> any >> event there seems to be no way to differentiate the users "intent" >> simply >> by examining the send/receive attributes of the SDP. Is this not at the >> heart of the complaint? >> >> >> If so, I think Udit, and many others who have whined about the >> inadequacy of >> the send/receive semantics, have a point... why can there not be >> something to signal this intent? Perhaps we can hash out the >> distinctions. >> >> >> Gordon. >> >> >> >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Paul >> > Kyzivat >> > Sent: Tuesday, October 04, 2005 10:08 AM >> > To: Udit_Goyal@3com.com >> > Cc: SIP IETF; SIP Implementors >> > Subject: [Sip] Re: [Sip-implementors] Hold SDP >> > >> > >> > >> > Udit_Goyal@3com.com wrote: >> > > I want to know is it the genral behaviour of all UAC? >> > >> > There are a lot of UAs out there. Its hard to say what the "general" >> > behavior is. >> > >> > > because as per RFC, c=0 has not been recommended for RTCP purposes, >> > > anyway in these cases, we might need RTCP reports also, >> > >> > The use of c=0 is an old (now deprecated) action in response to a >> > request to initiate hold. The mechanism still exists, and is still >> > important for some call flows unrelated to hold. There is of course >> > nothing to prevent a UA from using it when initiating Hold, and the >> peer >> > should do something reasonable in response. >> > >> > > Why cant we have one more attribute "a=hold" which indicates its >> meant >> > for >> > > hold and not for one-way media audio stream, >> > >> > I think mostly because hold is a feature, and IETF doesn't standardize >> > features. The existing directionality attributes are mechanisms that >> may >> > be used for hold or other things. >> > >> > If you introduced a hold attribute, then there would be a lot of call >> to >> > have different flavors of hold - one way, two way, with music, without >> > music, etc. And of course you would need to get into the precise >> > semantics of hold. >> > >> > As things stand, Hold is a local feature on an endpoint. The >> > corresponding signaling should not really be considered as signaling >> > "hold" - it is only signaling the desired media behavior. I think >> there >> > is no expectation, or need, for the other UA, or servers in the path >> to >> > be able to determine that the call is "held". >> > >> > Paul >> > >> > > Thanks, >> > > Udit >> > > >> > > >> > > >> > > >> > > >> > > "Avasarala Ranjit-A20990" >> > > Sent by: sip-implementors-bounces@cs.columbia.edu >> > > 10/04/2005 02:23 AM >> > > >> > > To >> > > Udit Goyal/C/US/3Com@3Com, "SIP Implementors" >> > > >> > > cc >> > > SIP IETF >> > > Subject >> > > RE: [Sip-implementors] Hold SDP >> > > >> > > >> > > >> > > >> > > >> > > >> > > Udit >> > > >> > > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to >> a-sendonly. >> > > >> > > >> > > >> > > Regards >> > > Ranjit >> > > >> > > >> > > >> > > >> > > -----Original Message----- >> > > From: sip-implementors-bounces@cs.columbia.edu >> > > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of >> > > Udit_Goyal@3com.com >> > > Sent: Monday, October 03, 2005 10:42 PM >> > > To: SIP Implementors >> > > Cc: SIP IETF >> > > Subject: [Sip-implementors] Hold SDP >> > > >> > > Hi, >> > > >> > > As per RFC 3264, user agent indicate hold by sending "sendonly >> attribute >> > > (assuming sendrecv mode stream). >> > > So when UAS receives this SDP, it should respond with "recvonly" >> > > attribute. >> > > >> > > But same mechanism can be used by user agent if he wants to play >> > > announcement or music to user, so it can send "sendonly" attribute >> for >> > > media stream. >> > > I mean if it simply wants one-way connection (this is not hold). >> > > >> > > For 3PCC (as B2B), if it wants to provide MOH service, how can it >> > > differentiate between two SDP because it will play MOH only in the >> first >> > > scenario when user press hold. >> > > >> > > Is there any other way where user agent can indicate that this is >> hold >> > > scenario and not one-way audio. >> > > >> > > Thanks, >> > > Udit >> > > _______________________________________________ >> > > Sip-implementors mailing list >> > > Sip-implementors@cs.columbia.edu >> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > >> > > _______________________________________________ >> > > Sip-implementors mailing list >> > > Sip-implementors@cs.columbia.edu >> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > _______________________________________________ >> > > Sip-implementors mailing list >> > > Sip-implementors@cs.columbia.edu >> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> >> >> > > >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 05 11:39:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBMh-0006sj-GS; Wed, 05 Oct 2005 11:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMuaU-0006CV-E8 for sip@megatron.ietf.org; Tue, 04 Oct 2005 17:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10846 for ; Tue, 4 Oct 2005 17:44:35 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMujE-0005kh-Cb for sip@ietf.org; Tue, 04 Oct 2005 17:53:41 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 14:44:27 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="663450537:sNHT34209168" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94Lhv5K018481; Tue, 4 Oct 2005 14:44:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 14:44:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] No dual concurrent registration Date: Tue, 4 Oct 2005 14:44:24 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52B87C58@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Sip] No dual concurrent registration Thread-Index: AcXJBU3Qx/F3aUziQZyQDoPg5ljHYQAJflcA From: "Michael Tasker \(mtasker\)" To: "Dave Oran \(oran\)" , X-OriginalArrivalTime: 04 Oct 2005 21:44:25.0175 (UTC) FILETIME=[C9D37670:01C5C92C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 05 Oct 2005 10:12:11 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Richard It really is up to the algorithm that's implemented in the phone to control the re-home to primary behavior. Possibly you could set the expires time on the SIP-SRST registrar to a short value - and maybe this would trigger the phones to do a periodic re-evaluate? Possibly you could go kill the SIP-SRST service itself as an alternative to power cycling the ethernet power? Note that the effect of power cycling the phone is simply to force the phone to re-evaluate which Proxy/Registrar it wants to register to. So what you really need is some less brute-force way to trigger the phone to do the re-evaluate - which has to be phone vendor specific I think. But the intent of SIP-SRST is to be a safe haven for any phone that has been stranded by it's primary Registrar/Proxy (for whatever reason) - so if the phone requests service - then SIP-SRST is going to grant it if it can.=20 It's not the job of SIP-SRST to attempt to evaluate the "in-service" state or availability of the phone's primary Registrar/Proxy - often SIP-SRST does not even know who the primary is. Note that there is no requirement that the SIP-SRST router is in the physical network path between the phone and its primary Registrar/Proxy. Mike Tasker Cisco CallManager Express, Survivable Remote Site Telephony, SIP-SRST =20 -----Original Message----- From: Dave Oran (oran)=20 Sent: Tuesday, October 04, 2005 10:02 AM To: Michael Tasker (mtasker) Subject: Fwd: [Sip] No dual concurrent registration Begin forwarded message: > From: "Richard Logan" > Date: September 30, 2005 10:23:34 PM EDT > To: > Subject: [Sip] No dual concurrent registration > > > Hello, > We recently implemented a SIP phone system and are using the SIP SRST=20 > fall back on our phones. The phones do not support dual concurrent=20 > registration. We were able to get the phones to fail over to the=20 > server which works great. What were NOT able to do was to get the to=20 > fail back over to the SIP server. In other words once the phones fail > over to the router and since the service never stops the phones never > fail back over to the phone system. It doesn't sound like a big=20 > problem but any time we reboot our SIP phone system the phones fail=20 > over. We have been performing a reload on the switches which kills=20 > the power over Ethernet on the phones to get them operating again. > > Since the phones don't support dual registration Cisco won't help. =20 > Anyone got any ideas? Do I have something configured incorrectly on=20 > my routers? > > Thanks, > Richard Logan > > _______________________________________________ > 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 sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 05 11:39:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBMj-0006tD-91; Wed, 05 Oct 2005 11:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMwCz-0003ND-L5 for sip@megatron.ietf.org; Tue, 04 Oct 2005 19:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16132 for ; Tue, 4 Oct 2005 19:28:25 -0400 (EDT) Received: from adsl-66-138-117-27.dsl.wchtks.swbell.net ([66.138.117.27] helo=CUA-MAIL.CUOFAMERICA.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMwLl-0007z1-46 for sip@ietf.org; Tue, 04 Oct 2005 19:37:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] No dual concurrent registration Date: Tue, 4 Oct 2005 18:28:12 -0500 Message-ID: Thread-Topic: [Sip] No dual concurrent registration Thread-Index: AcXJBU3Qx/F3aUziQZyQDoPg5ljHYQAJflcAAAMMhJA= From: "Richard Logan" To: "Michael Tasker \(mtasker\)" , "Dave Oran \(oran\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 05 Oct 2005 10:12:11 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just so you know we are using Polycom IP500 phones and Cisco 2801 = routers. On the first point about the expire times I agree. I have considered = something similar to that. The problem that I have experienced has been = that any time I lower the registration time on my router in my sip.cfg = file the phones won't register to it. In fact if I modify almost any = setting with regards to the router registration they won't register to = it. I think I'm going to try and re-evaluate this though it's been some = time and I've learned alot since then. I can lower the registration time on the phones with regards to the = phone system. That has actually been nice. My phones will essentially = fail over to the router after only 10 or 20 seconds. That makes SIP = SRST more functional. With regards to disabling SRST: Unfortunately even if you stop the SRST = service and remove all the code from the Cisco routers the phones stay = registered to it. If the phone is rebooted from that point it won't = register to the router. Obviously that doesn't help with this problem = though. Anyways thanks for the email that is good information. Thanks, Richard Logan IS Manager Credit Union of America -----Original Message----- From: Michael Tasker (mtasker) [mailto:mtasker@cisco.com] Sent: Tuesday, October 04, 2005 4:44 PM To: Dave Oran (oran); Richard Logan Cc: sip@ietf.org Subject: RE: [Sip] No dual concurrent registration Hi Richard It really is up to the algorithm that's implemented in the phone to control the re-home to primary behavior. Possibly you could set the expires time on the SIP-SRST registrar to a short value - and maybe this would trigger the phones to do a periodic re-evaluate? Possibly you could go kill the SIP-SRST service itself as an alternative to power cycling the ethernet power? Note that the effect of power cycling the phone is simply to force the phone to re-evaluate which Proxy/Registrar it wants to register to. So what you really need is some less brute-force way to trigger the phone to do the re-evaluate - which has to be phone vendor specific I think. But the intent of SIP-SRST is to be a safe haven for any phone that has been stranded by it's primary Registrar/Proxy (for whatever reason) - so if the phone requests service - then SIP-SRST is going to grant it if it can.=20 It's not the job of SIP-SRST to attempt to evaluate the "in-service" state or availability of the phone's primary Registrar/Proxy - often SIP-SRST does not even know who the primary is. Note that there is no requirement that the SIP-SRST router is in the physical network path between the phone and its primary Registrar/Proxy. Mike Tasker Cisco CallManager Express, Survivable Remote Site Telephony, SIP-SRST =20 -----Original Message----- From: Dave Oran (oran)=20 Sent: Tuesday, October 04, 2005 10:02 AM To: Michael Tasker (mtasker) Subject: Fwd: [Sip] No dual concurrent registration Begin forwarded message: > From: "Richard Logan" > Date: September 30, 2005 10:23:34 PM EDT > To: > Subject: [Sip] No dual concurrent registration > > > Hello, > We recently implemented a SIP phone system and are using the SIP SRST=20 > fall back on our phones. The phones do not support dual concurrent=20 > registration. We were able to get the phones to fail over to the=20 > server which works great. What were NOT able to do was to get the to=20 > fail back over to the SIP server. In other words once the phones fail > over to the router and since the service never stops the phones never > fail back over to the phone system. It doesn't sound like a big=20 > problem but any time we reboot our SIP phone system the phones fail=20 > over. We have been performing a reload on the switches which kills=20 > the power over Ethernet on the phones to get them operating again. > > Since the phones don't support dual registration Cisco won't help. =20 > Anyone got any ideas? Do I have something configured incorrectly on=20 > my routers? > > Thanks, > Richard Logan > > _______________________________________________ > 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 sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 05 15:03:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEYO-0006Nj-21; Wed, 05 Oct 2005 15:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENBLE-0006VK-P3 for sip@megatron.ietf.org; Wed, 05 Oct 2005 11:38:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00625 for ; Wed, 5 Oct 2005 11:37:58 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler6.mail.eds.com ([192.85.154.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENBU9-0007K1-0Y for sip@ietf.org; Wed, 05 Oct 2005 11:47:13 -0400 Received: from ahmlir2.mail.eds.com (ahmlir2-2.mail.eds.com [192.85.154.132]) by ahmler6.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95FZ6u4015918; Wed, 5 Oct 2005 11:35:06 -0400 Received: from ahmlir2.mail.eds.com (localhost [127.0.0.1]) by ahmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95FY9Um023244; Wed, 5 Oct 2005 11:34:09 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95FY9iU023232; Wed, 5 Oct 2005 11:34:09 -0400 To: Paul Kyzivat Subject: [Sip] Re:Hold SDP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 5 Oct 2005 11:40:53 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/05/2005 08:34:09 AM, Serialize complete at 10/05/2005 08:34:09 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: SIP IETF , Whitaker , gledgard@iperia.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1922679386==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1922679386== Content-Type: multipart/alternative; boundary="=_alternative 0055603785257091_=" This is a multipart message in MIME format. --=_alternative 0055603785257091_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 LS0tLS0gRm9yd2FyZGVkIGJ5IFVkaXQgR295YWwvQy9VUy8zQ29tIG9uIDEwLzA1LzIwMDUgMTE6 MzAgQU0gLS0tLS0NCg0KVWRpdCBHb3lhbC9DL1VTLzNDb20NCjEwLzA1LzIwMDUgMTE6MzIgQU0N Cg0KVG8NClBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPg0KY2MNCmdsZWRnYXJkQGlw ZXJpYS5jb20sIHNpcEBpZXRmLm9yZywgc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUs IENocmlzIA0KV2hpdGFrZXIgPHdoaXRha2VyY2RAaG90bWFpbC5jb20+DQpTdWJqZWN0DQpSZTog W1NpcF0gUmU6IFtTaXAtaW1wbGVtZW50b3JzXSBIb2xkIFNEUA0KDQoNCg0KDQoNCkFzIHBlciBS RkMgMzI2NA0KDQo4LjQgUHV0dGluZyBhIFVuaWNhc3QgTWVkaWEgU3RyZWFtIG9uIEhvbGQNCklm IGEgcGFydHkgaW4gYSBjYWxsIHdhbnRzIHRvIHB1dCB0aGUgb3RoZXIgcGFydHkg4oCcb24gaG9s ZOKAnSwgaS5lLiwgcmVxdWVzdCANCnRoYXQgaXQgdGVtcG9yYXJpbHkgc3RvcHMgc2VuZGluZyBv bmUNCm9yIG1vcmUgdW5pY2FzdCBtZWRpYSBzdHJlYW1zLCBhIHBhcnR5IG9mZmVycyB0aGUgb3Ro ZXIgYW4gdXBkYXRlZCBTRFAuDQoNCltVZGl0XSBJIGFncmVlLg0KDQpJZiB0aGUgc3RyZWFtIHRv IGJlIHBsYWNlZCBvbiBob2xkIHdhcyBwcmV2aW91c2x5IGEgc2VuZHJlY3YgbWVkaWEgc3RyZWFt LCANCml0IGlzIHBsYWNlZCBvbiBob2xkIGJ5IG1hcmtpbmcNCml0IGFzIHNlbmRvbmx5LiBJZiB0 aGUgc3RyZWFtIHRvIGJlIHBsYWNlZCBvbiBob2xkIHdhcyBwcmV2aW91c2x5IGEgDQpyZWN2b25s eSBtZWRpYSBzdHJlYW0sIGl0IGlzIHBsYWNlZCBvbg0KaG9sZCBieSBtYXJraW5nIGl0IGluYWN0 aXZlLg0KDQo+PltVZGl0XSBBcyBwb2ludGVkIG91dCBieSBDaHJpcywgaXQgc2hvdWxkIHNwZWFr IHRoZSB0cnV0aC4uIElmIHVzZXIgDQphZ2VudCAgd2FudHMgdG8gcGxheSBtZWRpYSBmb3IgaG9s ZCwgaXQgY2FuIG1hcmsgaXQgYXMNCj4+c2VuZG9ubHkgb3RoZXJ3aXNlIGl0IGNhbiBtYXJrIGl0 IGFuIGluYWN0aXZlLg0KDQoNClR5cGljYWxseSwgd2hlbiBhIHVzZXIg4oCccHJlc3Nlc+KAnSBo b2xkLCB0aGUgYWdlbnQgd2lsbCBnZW5lcmF0ZSBhbiBvZmZlciANCndpdGggYWxsIHN0cmVhbXMg aW4gdGhlIFNEUCBpbmRpY2F0aW5nDQphIGRpcmVjdGlvbiBvZiBzZW5kb25seSwgYW5kIGl0IHdp bGwgYWxzbyBsb2NhbGx5IG11dGUsIHNvIHRoYXQgbm8gbWVkaWEgDQppcyBzZW50IHRvIHRoZSBm YXIgZW5kLCBhbmQgbm8gbWVkaWEgaXMNCnBsYXllZCBvdXQuDQoNCltVZGl0XSBJZiB1c2VyIGFn ZW50IGlzIGRvaW5nIGxvY2FsbHkgbXV0ZSBhbmQgbm8gbWVkaWEgaXMgc2VudCB0byBmYXJlbmQs IA0KdGhlbiB3aHkgaXQgc2hvdWxkIHNlbmQgaXQgYXMgc2VuZG9ubHkuIEl0IHNob3VsZCBzZW5k IGFzIGluYWN0aXZlLg0KQWx0aG91Z2ggdGhleSBhcmUgbm9uLW5vcm1hdGl2ZSBzdGF0bWVudHMs IGJ1dCBzdGlsbCBpdCBjYW4gYmUgcmVwaHJhc2VkIA0KYmVjYXVzZSBhZ2VudCBzaG91bGQgbm90 IG1hcmsgaXQgc2VuZG9ubHkgd2hlbiBpdCBzcGVjaWZpYWxseSBzYXlzIHRoYXQgbm8gDQptZWRp YSBuZWVkcyB0byBiZSBwbGF5ZWQgb3V0Lg0KDQpJdCBjYW4gcmF0aGVyIHNwZWNpZmllZCBhcyB1 c2VyIGFnZW50IGJlaGF2aW91ciBpZiBpdCB3YW50cyBtZWRpYSB0IG9iZSANCnBsYXllZCAsIGl0 IGNhbiBtYXJrIGl0IGEgc2VuZG5seSwgb3IgaWYgaXQgd2FudHMgdG8gc3RvcCBzZW5kaW5nIG1l ZGluZyANCm1lZGlhIHN0cmVhbXMsIGl0IGNhbiBtYXJrIGl0IGFzIGluYWN0aXZlLg0KDQoNCg== --=_alternative 0055603785257091_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM4MDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0g Rm9yd2FyZGVkIGJ5IFVkaXQNCkdveWFsL0MvVVMvM0NvbSBvbiAxMC8wNS8yMDA1IDExOjMwIEFN IC0tLS0tPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlVkaXQgR295 YWwvQy9VUy8zQ29tPC9iPjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4xMC8wNS8yMDA1IDExOjMyIEFNPC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7 PC9mb250Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Y2M8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Z2xlZGdhcmRAaXBlcmlhLmNvbSwgc2lwQGlldGYub3JnLA0Kc2lw LWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUsIENocmlzIFdoaXRha2VyICZsdDt3aGl0YWtl cmNkQGhvdG1haWwuY29tJmd0OzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQg dmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtTaXBdIFJlOiBb U2lwLWltcGxlbWVudG9yc10NCkhvbGQgU0RQPC9mb250PjxhIGhyZWY9Tm90ZXM6Ly8vODUyNTZG MjcwMDU0MEY4Ri8zMjU0N0Q3RjU5RjlFN0UzODUyNTYxMzIwMDU1NkU3Ny8yRDIyRTE1RjI1Mjg3 MTYzODgyNTcwOTEwMDRCRTZFQT5MaW5rPC9hPjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIHBlciBSRkMgMzI2NDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+OC40IFB1dHRpbmcgYSBVbmlj YXN0IE1lZGlhIFN0cmVhbSBvbg0KSG9sZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+SWYgYSBwYXJ0eSBpbiBhIGNhbGwgd2FudHMgdG8gcHV0IHRoZQ0Kb3RoZXIg cGFydHkg4oCcb24gaG9sZOKAnSwgaS5lLiwgcmVxdWVzdCB0aGF0IGl0IHRlbXBvcmFyaWx5IHN0 b3BzIHNlbmRpbmcNCm9uZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+b3IgbW9yZSB1bmljYXN0IG1lZGlhIHN0cmVhbXMsIGEgcGFydHkNCm9mZmVycyB0aGUgb3Ro ZXIgYW4gdXBkYXRlZCBTRFAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5bVWRpdF0gSSBhZ3JlZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBzdHJlYW0gdG8gYmUgcGxhY2VkIG9uIGhvbGQgd2Fz DQpwcmV2aW91c2x5IGEgc2VuZHJlY3YgbWVkaWEgc3RyZWFtLCBpdCBpcyBwbGFjZWQgb24gaG9s ZCBieSBtYXJraW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5p dCBhcyBzZW5kb25seS4gSWYgdGhlIHN0cmVhbSB0byBiZQ0KcGxhY2VkIG9uIGhvbGQgd2FzIHBy ZXZpb3VzbHkgYSByZWN2b25seSBtZWRpYSBzdHJlYW0sIGl0IGlzIHBsYWNlZCBvbjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aG9sZCBieSBtYXJraW5nIGl0IGlu YWN0aXZlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jmd0OyZndDtbVWRpdF0gQXMgcG9pbnRlZCBvdXQgYnkgQ2hyaXMsDQppdCBzaG91bGQgc3BlYWsg dGhlIHRydXRoLi4gSWYgdXNlciBhZ2VudCAmbmJzcDt3YW50cyB0byBwbGF5IG1lZGlhIGZvcg0K aG9sZCwgaXQgY2FuIG1hcmsgaXQgYXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZndDsmZ3Q7c2VuZG9ubHkgb3RoZXJ3aXNlIGl0IGNhbiBtYXJrDQppdCBhbiBp bmFjdGl2ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlR5cGljYWxseSwgd2hlbiBhIHVzZXIg4oCccHJlc3Nlc+KAnSBob2xkLA0KdGhlIGFn ZW50IHdpbGwgZ2VuZXJhdGUgYW4gb2ZmZXIgd2l0aCBhbGwgc3RyZWFtcyBpbiB0aGUgU0RQIGlu ZGljYXRpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmEgZGly ZWN0aW9uIG9mIHNlbmRvbmx5LCBhbmQgaXQgd2lsbA0KYWxzbyBsb2NhbGx5IG11dGUsIHNvIHRo YXQgbm8gbWVkaWEgaXMgc2VudCB0byB0aGUgZmFyIGVuZCwgYW5kIG5vIG1lZGlhDQppczwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cGxheWVkIG91dC48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPltVZGl0XSBJZiB1c2Vy IGFnZW50IGlzIGRvaW5nIGxvY2FsbHkNCm11dGUgYW5kIG5vIG1lZGlhIGlzIHNlbnQgdG8gZmFy ZW5kLCB0aGVuIHdoeSBpdCBzaG91bGQgc2VuZCBpdCBhcyBzZW5kb25seS4NCkl0IHNob3VsZCBz ZW5kIGFzIGluYWN0aXZlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QWx0aG91Z2ggdGhleSBhcmUgbm9uLW5vcm1hdGl2ZSBzdGF0bWVudHMsDQpidXQgc3RpbGwg aXQgY2FuIGJlIHJlcGhyYXNlZCBiZWNhdXNlIGFnZW50IHNob3VsZCBub3QgbWFyayBpdCBzZW5k b25seQ0Kd2hlbiBpdCBzcGVjaWZpYWxseSBzYXlzIHRoYXQgbm8gbWVkaWEgbmVlZHMgdG8gYmUg cGxheWVkIG91dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkl0IGNhbiByYXRoZXIgc3BlY2lmaWVkIGFzIHVzZXIgYWdlbnQNCmJlaGF2aW91ciBpZiBp dCB3YW50cyBtZWRpYSB0IG9iZSBwbGF5ZWQgLCBpdCBjYW4gbWFyayBpdCBhIHNlbmRubHksIG9y DQppZiBpdCB3YW50cyB0byBzdG9wIHNlbmRpbmcgbWVkaW5nIG1lZGlhIHN0cmVhbXMsIGl0IGNh biBtYXJrIGl0IGFzIGluYWN0aXZlLjwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 0055603785257091_=-- --===============1922679386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1922679386==-- From sip-bounces@ietf.org Wed Oct 05 18:06:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENHPD-0005Uu-2X; Wed, 05 Oct 2005 18:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENHPB-0005Ul-95 for sip@megatron.ietf.org; Wed, 05 Oct 2005 18:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04392 for ; Wed, 5 Oct 2005 18:06:26 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler8.mail.eds.com ([192.85.154.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENHY4-0006nX-Lv for sip@ietf.org; Wed, 05 Oct 2005 18:15:45 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler8.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95M6Ans016766; Wed, 5 Oct 2005 18:06:11 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95M5xW8024259; Wed, 5 Oct 2005 18:05:59 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j95M5xCq024248; Wed, 5 Oct 2005 18:05:59 -0400 In-Reply-To: To: Roman Shpount MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 5 Oct 2005 18:12:41 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/05/2005 03:06:00 PM, Serialize complete at 10/05/2005 03:06:00 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, pkyzivat@cisco.com, john.elwell@siemens.com, gledgard@iperia.com Subject: [Sip] Re: [Sip-implementors] Re: Sip-implementors Digest, Vol 31, Issue 14 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1301244223==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1301244223== Content-Type: multipart/alternative; boundary="=_alternative 00793F2285257091_=" This is a multipart message in MIME format. --=_alternative 00793F2285257091_= Content-Type: text/plain; charset="US-ASCII" Agreed! Roman Shpount Sent by: sip-implementors-bounces@cs.columbia.edu 10/05/2005 04:41 PM To cc gledgard@iperia.com, sip@ietf.org, pkyzivat@cisco.com, john.elwell@siemens.com, Udit Goyal/C/US/3Com@3Com Subject [Sip-implementors] Re: Sip-implementors Digest, Vol 31, Issue 14 John, You wrote: > RFC 3264 does indeed tell you to do that. In section 5.1 it states: > "If the offerer wishes to communicate, but wishes to neither send nor > receive media at this time, it MUST mark the stream with an "a=inactive" > attribute." > The problem is, this appears to be contradicted elsewhere. The problem is in RFC 3264 section 8.4. It states: "If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly." This sentence is more often false then true and should not be considered normative. I think the original intent of this text was to say that that SDP with c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such SDP was normally called putting on hold. Hence the confusion. In generall, it would be a good idea to remove mentioning of term hold from RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP should be spelled out. This should not change anything in the meaning of the RFC, but hopefully will end the hold confusion. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. -- www.atelo.com _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --=_alternative 00793F2285257091_= Content-Type: text/html; charset="US-ASCII"
Agreed!


Roman Shpount <roman@atelo.com>
Sent by: sip-implementors-bounces@cs.columbia.edu

10/05/2005 04:41 PM

To
<sip-implementors@cs.columbia.edu>
cc
gledgard@iperia.com, sip@ietf.org, pkyzivat@cisco.com, john.elwell@siemens.com, Udit Goyal/C/US/3Com@3Com
Subject
[Sip-implementors] Re: Sip-implementors Digest, Vol 31, Issue 14





John,
You wrote:
> RFC 3264 does indeed tell you to do that. In section 5.1 it states:
> "If the offerer wishes to communicate, but wishes to neither send nor
> receive media at this time, it MUST mark the stream with an "a=inactive"
> attribute."
> The problem is, this appears to be contradicted elsewhere.
The problem is in RFC 3264 section 8.4. It states:
"If the stream to be placed on hold was previously a sendrecv media
stream, it is placed on hold by marking it as sendonly." This sentence
is more often false then true and should not be considered normative.
I think the original intent of this text was to say that that SDP with
c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since
SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such
SDP was normally called putting on hold. Hence the confusion.
In generall, it would be a good idea to remove mentioning of term hold from
RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP
should be spelled out. This should not change anything in the meaning
of the RFC, but hopefully will end the hold confusion.
___________________________________
Roman Shpount, VP of Technology
aTelo, Inc. -- www.atelo.com






_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--=_alternative 00793F2285257091_=-- --===============1301244223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1301244223==-- From sip-bounces@ietf.org Thu Oct 06 04:05:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQkW-0004HV-Pc; Thu, 06 Oct 2005 04:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQkU-0004HK-KT for sip@megatron.ietf.org; Thu, 06 Oct 2005 04:05:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16003 for ; Thu, 6 Oct 2005 04:05:04 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENQtW-0002wo-Jn for sip@ietf.org; Thu, 06 Oct 2005 04:14:28 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84BD2AB3 for ; Thu, 6 Oct 2005 10:04:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:03:55 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:03:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 10:03:55 +0200 Message-ID: Thread-Topic: SIP session without SDP Thread-Index: AcXKTH8y8talim3VRF6y6KXbGvsyNQ== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 06 Oct 2005 08:03:55.0531 (UTC) FILETIME=[7F7F6DB0:01C5CA4C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Sip] SIP session without SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an = session description offer, the response (reliable) MUST contain an = session description answer. First, it is not said that the session description must be a SDP body, = so I assume something else could be used too? Second, assume that I want to set up a session without SDP (or, another = type of session description)? If I include an empty Accept header (or an = Accept header where application/sdp is not listed) I don't think the UAS = should be mandated to include an SDP offer in the response. So, I think the rules in 13.2.1 shall be applicable IF I am using a = session description, but I should NOT be mandated to use session = description. Regards, Christer Ericsson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 04:05:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQlD-0004Xt-8y; Thu, 06 Oct 2005 04:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENQlB-0004Xl-JW for sip@megatron.ietf.org; Thu, 06 Oct 2005 04:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16033 for ; Thu, 6 Oct 2005 04:05:47 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENQu9-0002y7-JF for sip@ietf.org; Thu, 06 Oct 2005 04:15:11 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8BAC0EBF for ; Thu, 6 Oct 2005 10:05:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:03:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:03:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2005 10:03:44 +0200 Message-ID: Thread-Topic: How long is a Contact valid Thread-Index: AcXKTHksqA1KPnmbT62G9qvTRgVO9A== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 06 Oct 2005 08:03:45.0266 (UTC) FILETIME=[79611D20:01C5CA4C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [Sip] How long is a Contact valid X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, RFC3261 says (also said in the GRUU draft) that a Contact URI shall be = valid for requests outside of the dialog for which the Contact URI was = created. Currently, however, it is not possible for the creator of the Contact = URI to indicate to the other user for how long the URI is valid, since = the "expires" parameter is only allowed in REGISTER requests, and 3xx = responses. So, the remote user of course assume that the URI is valid = for the duration of the current dialog (or until a target refresh is = recieved), but it does now know for how long the URI can be used for = requests outside of the dialog. The GRUU draft DOES say that the URI = ideally should be valid as long as the AOR it's associated to, but that = may not always be the case. My first question is: is there a reason why the "expires" parameter = couldn't be allowed for INVITE requests and 200 responses, to indicate = for how long the value is valid for out-of-current-dialog usage? My second question is (assuming the "expirese" parameter could be used = in INVITE/200): I may want the Contact URI to be valid for the duration = of the dialog for which it was created. However, in most cases it is = impossible to know for how long a dialog will last, in order to generate = an "expires" value, so I wonder if it would be possible to define some = kind of a "session" value, which means that the Contact value is valid = only for the duration of the session for which it was generated? Maybe a = zero value could be used to indicate this? Regards, Christer Ericsson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 05:16:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENRrI-0006hZ-Dg; Thu, 06 Oct 2005 05:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENRrG-0006hM-O4 for sip@megatron.ietf.org; Thu, 06 Oct 2005 05:16:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19789 for ; Thu, 6 Oct 2005 05:16:08 -0400 (EDT) Received: from mailgate2.nl.thalesgroup.com ([193.67.31.101] helo=mailgate2.signaal.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENS0D-0005xo-Gy for sip@ietf.org; Thu, 06 Oct 2005 05:25:32 -0400 Received: from mta1.nl.thales (mta1.signaal.local [193.67.31.130]) by mailgate2.signaal.nl (4.8.1.149) with ESMTP id for ; Thu, 6 Oct 2005 11:14:37 +0200 (MEST) Received: from suna900.sc.signaal.nl (suna900.sc.signaal.nl [192.7.99.164]) by mta1.nl.thales (4.9.7.3) with ESMTP id Dd38bAAw for ; Thu, 6 Oct 2005 11:14:13 +0200 (MEST) Received: from scms1.sc.signaal.nl ([192.7.99.212]) by suna900.sc.signaal.nl (Netscape Messaging Server 3.6) with ESMTP id AAA724F for ; Thu, 6 Oct 2005 11:14:07 +0200 Received: from scd01-MTA by scms1.sc.signaal.nl with Novell_GroupWise; Thu, 06 Oct 2005 11:13:30 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Thu, 06 Oct 2005 11:13:28 +0200 From: "Ettore Benedetti" To: Subject: Re: [Sip] Offer-answer model MIME-Version: 1.0 (Generated by Clearswift ES version 4.8.1.149) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Udit, the exchange is mostly correct: line order matters in SDP so you should swap the c=3D and a=3D lines in the first media item. Ettore Benedetti THALES COMMUNICATIONS B.V. Bestevaer 46, 1271 ZA Huizen The Netherlands Unclassified >>> 10/5/05 7:16:23 AM >>> Hi, I just want to check if following offer-answer model is valid: Offer: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4 host.anywhere.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 m=3Dvideo 51372 RTP/AVP 31 a=3Drtpmap:31 H261/90000 m=3Dvideo 53000 RTP/AVP 32 a=3Drtpmap:32 MPV/90000 Answer: v=3D0 o=3Dbob 2890844730 2890844730 IN IP4 host.example.com s=3D c=3DIN IP4 host.example.com t=3D0 0 m=3Daudio 49920 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 c=3DIN IP4 host.example.com // can it send its own "c" value=20 m=3Dvideo 0 RTP/AVP 31 m=3Dvideo 53000 RTP/AVP 32 a=3Drtpmap:32 MPV/90000 Thanks, Udit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 05:47:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENSL8-0007BF-Ug; Thu, 06 Oct 2005 05:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGDP-0006r2-4T for sip@megatron.ietf.org; Wed, 05 Oct 2005 16:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18597 for ; Wed, 5 Oct 2005 16:50:11 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENGMK-0000Hn-8G for sip@ietf.org; Wed, 05 Oct 2005 16:59:29 -0400 Received: from atelo.com ([68.33.192.37]) by comcast.net (sccrmhc13) with SMTP id <2005100520494901300b8vf7e>; Wed, 5 Oct 2005 20:49:49 +0000 DATE: 05 Oct 2005 20:41:41 GMT RECEIVED: from WebUser4 by Dispatcher; 5 Oct 2005 20:41:41 GMT Message-ID: X-Mailer: atelo.com POP3 Server v.1c MIME-Version: 1.0 From: Roman Shpount To: Content-type: TEXT/PLAIN Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 06 Oct 2005 05:47:00 -0400 Cc: Chris Whitaker , john.elwell@siemens.com, gledgard@iperia.com, sip@ietf.org, pkyzivat@cisco.com Subject: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org John,=0D=0A=0D=0AYou wrote:=0D=0A=0D=0A> RFC 3264 does indeed tell you t= o do that. In section 5.1 it states:=0D=0A> "If the offerer wishes to co= mmunicate, but wishes to neither send nor =0D=0A> receive media at this = time, it MUST mark the stream with an "a=3Dinactive" =0D=0A> attribute."= =0D=0A=0D=0A> The problem is, this appears to be contradicted elsewhere= . =0D=0A=0D=0AThe problem is in RFC 3264 section 8.4. It states:=0D=0A"I= f the stream to be placed on hold was previously a sendrecv media=0D=0As= tream, it is placed on hold by marking it as sendonly." This sentence=0D= =0Ais more often false then true and should not be considered normative.= =0D=0A=0D=0AI think the original intent of this text was to say that tha= t SDP with =0D=0Ac=3D0.0.0.0 corresponds to sendonly SDP and not inactiv= e SDP. Since=0D=0ASDP with c=3D0.0.0.0 used to be called hold SDP, sendi= ng an offer with such =0D=0ASDP was normally called putting on hold. Hen= ce the confusion.=0D=0A=0D=0AIn generall, it would be a good idea to rem= ove mentioning of term hold from=0D=0ARFC 3264. Also, correspondence bet= ween SDP with c=3D0.0.0.0 and sendonly SDP=0D=0Ashould be spelled out. T= his should not change anything in the meaning=0D=0Aof the RFC, but hopef= ully will end the hold confusion.=0D=0A_________________________________= __=0D=0ARoman Shpount, VP of Technology=0D=0AaTelo, Inc. -- www.atelo.co= m=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 08:52:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVED-000662-Oj; Thu, 06 Oct 2005 08:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVEC-00065x-1H for sip@megatron.ietf.org; Thu, 06 Oct 2005 08:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00319 for ; Thu, 6 Oct 2005 08:52:02 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVNG-0006CQ-Lv for sip@ietf.org; Thu, 06 Oct 2005 09:01:28 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2005 05:51:54 -0700 X-IronPort-AV: i="3.97,182,1125903600"; d="scan'208"; a="217539595:sNHT25640584" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j96CpiVv018706; Thu, 6 Oct 2005 05:51:47 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 08:51:48 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 08:51:47 -0400 Message-ID: <43451DE3.6050305@cisco.com> Date: Thu, 06 Oct 2005 08:51:47 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roman Shpount Subject: Re: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 12:51:47.0761 (UTC) FILETIME=[B68C9210:01C5CA74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Chris Whitaker , sip-implementors@cs.columbia.edu, gledgard@iperia.com, john.elwell@siemens.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Roman, While I agree that 3264 could do with some cleanup, I doubt it will happen any time soon. Paul Roman Shpount wrote: > John, > > You wrote: > > >>RFC 3264 does indeed tell you to do that. In section 5.1 it states: >>"If the offerer wishes to communicate, but wishes to neither send nor >>receive media at this time, it MUST mark the stream with an "a=inactive" >>attribute." > > >>The problem is, this appears to be contradicted elsewhere. > > > The problem is in RFC 3264 section 8.4. It states: > "If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly." This sentence > is more often false then true and should not be considered normative. > > I think the original intent of this text was to say that that SDP with > c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since > SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such > SDP was normally called putting on hold. Hence the confusion. > > In generall, it would be a good idea to remove mentioning of term hold from > RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP > should be spelled out. This should not change anything in the meaning > of the RFC, but hopefully will end the hold confusion. > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. -- www.atelo.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 sip-bounces@ietf.org Thu Oct 06 09:10:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVW9-0002Vi-TY; Thu, 06 Oct 2005 09:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVW8-0002Va-5c; Thu, 06 Oct 2005 09:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01485; Thu, 6 Oct 2005 09:10:34 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler7.mail.eds.com ([199.228.142.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVfD-00072s-Ni; Thu, 06 Oct 2005 09:20:00 -0400 Received: from plmlir2.mail.eds.com (plmlir2-2.mail.eds.com [199.228.142.132]) by plmler7.mail.eds.com (8.13.4/8.12.10) with ESMTP id j96D722k008304; Thu, 6 Oct 2005 08:07:08 -0500 Received: from plmlir2.mail.eds.com (localhost [127.0.0.1]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j96D6IbE026591; Thu, 6 Oct 2005 08:06:19 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j96D6IKY026580; Thu, 6 Oct 2005 08:06:18 -0500 In-Reply-To: <43451DE3.6050305@cisco.com> To: Paul Kyzivat Subject: Re: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Thu, 6 Oct 2005 09:13:02 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/06/2005 06:06:18 AM, Serialize complete at 10/06/2005 06:06:18 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: Chris Whitaker , john.elwell@siemens.com, gledgard@iperia.com, sip@ietf.org, sip-implementors@cs.columbia.edu, Roman Shpount , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1297560775==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1297560775== Content-Type: multipart/alternative; boundary="=_alternative 0047D71685257092_=" This is a multipart message in MIME format. --=_alternative 0047D71685257092_= Content-Type: text/plain; charset="US-ASCII" Even if it does not happen soon for RFC3264, we can make sure that SIPForum can include this as a part of requirements document for SIP user agent...because anyway it is specfying hold behaviour for user agents. Regards, Udit Paul Kyzivat Sent by: sip-bounces@ietf.org 10/06/2005 08:51 AM To Roman Shpount cc sip@ietf.org, Chris Whitaker , sip-implementors@cs.columbia.edu, gledgard@iperia.com, john.elwell@siemens.com Subject Re: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14 Roman, While I agree that 3264 could do with some cleanup, I doubt it will happen any time soon. Paul Roman Shpount wrote: > John, > > You wrote: > > >>RFC 3264 does indeed tell you to do that. In section 5.1 it states: >>"If the offerer wishes to communicate, but wishes to neither send nor >>receive media at this time, it MUST mark the stream with an "a=inactive" >>attribute." > > >>The problem is, this appears to be contradicted elsewhere. > > > The problem is in RFC 3264 section 8.4. It states: > "If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly." This sentence > is more often false then true and should not be considered normative. > > I think the original intent of this text was to say that that SDP with > c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since > SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such > SDP was normally called putting on hold. Hence the confusion. > > In generall, it would be a good idea to remove mentioning of term hold from > RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP > should be spelled out. This should not change anything in the meaning > of the RFC, but hopefully will end the hold confusion. > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. -- www.atelo.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 --=_alternative 0047D71685257092_= Content-Type: text/html; charset="US-ASCII"
Even if it does not happen soon for RFC3264, we can make sure that SIPForum can include this as a part of requirements document for SIP user agent...because anyway it is specfying hold behaviour for user agents.

Regards,
Udit



Paul Kyzivat <pkyzivat@cisco.com>
Sent by: sip-bounces@ietf.org

10/06/2005 08:51 AM

To
Roman Shpount <roman@atelo.com>
cc
sip@ietf.org, Chris Whitaker <whitakercd@hotmail.com>, sip-implementors@cs.columbia.edu, gledgard@iperia.com, john.elwell@siemens.com
Subject
Re: [Sip] Re: Sip-implementors Digest, Vol 31, Issue 14





Roman,
While I agree that 3264 could do with some cleanup, I doubt it will
happen any time soon.
Paul
Roman Shpount wrote:
> John,
>
> You wrote:
>
>
>>RFC 3264 does indeed tell you to do that. In section 5.1 it states:
>>"If the offerer wishes to communicate, but wishes to neither send nor
>>receive media at this time, it MUST mark the stream with an "a=inactive"
>>attribute."
>
>
>>The problem is, this appears to be contradicted elsewhere.
>
>
> The problem is in RFC 3264 section 8.4. It states:
> "If the stream to be placed on hold was previously a sendrecv media
> stream, it is placed on hold by marking it as sendonly." This sentence
> is more often false then true and should not be considered normative.
>
> I think the original intent of this text was to say that that SDP with
> c=0.0.0.0 corresponds to sendonly SDP and not inactive SDP. Since
> SDP with c=0.0.0.0 used to be called hold SDP, sending an offer with such
> SDP was normally called putting on hold. Hence the confusion.
>
> In generall, it would be a good idea to remove mentioning of term hold from
> RFC 3264. Also, correspondence between SDP with c=0.0.0.0 and sendonly SDP
> should be spelled out. This should not change anything in the meaning
> of the RFC, but hopefully will end the hold confusion.
> ___________________________________
> Roman Shpount, VP of Technology
> aTelo, Inc. -- www.atelo.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
--=_alternative 0047D71685257092_=-- --===============1297560775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1297560775==-- From sip-bounces@ietf.org Thu Oct 06 09:26:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVlN-0000FO-3e; Thu, 06 Oct 2005 09:26:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVlM-0000FI-0K for sip@megatron.ietf.org; Thu, 06 Oct 2005 09:26:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02451 for ; Thu, 6 Oct 2005 09:26:17 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVuQ-0007oN-RK for sip@ietf.org; Thu, 06 Oct 2005 09:35:44 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2005 06:25:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,182,1125903600"; d="scan'208"; a="12647890:sNHT22661230" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96DOfR7005613; Thu, 6 Oct 2005 09:25:07 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 09:25:01 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 09:25:01 -0400 Message-ID: <434525AC.9070103@cisco.com> Date: Thu, 06 Oct 2005 09:25:00 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] How long is a Contact valid References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 13:25:01.0120 (UTC) FILETIME=[5AAF0400:01C5CA79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > > Hi, > > RFC3261 says (also said in the GRUU draft) that a Contact URI shall be valid for requests outside of the dialog for which the Contact URI was created. > > Currently, however, it is not possible for the creator of the Contact URI to indicate to the other user for how long the URI is valid, since the "expires" parameter is only allowed in REGISTER requests, and 3xx responses. So, the remote user of course assume that the URI is valid for the duration of the current dialog (or until a target refresh is recieved), but it does now know for how long the URI can be used for requests outside of the dialog. The GRUU draft DOES say that the URI ideally should be valid as long as the AOR it's associated to, but that may not always be the case. > > My first question is: is there a reason why the "expires" parameter couldn't be allowed for INVITE requests and 200 responses, to indicate for how long the value is valid for out-of-current-dialog usage? I can think of a pragmatic reason why this might be a bad thing to do: The "expires=" parameter contains a duration, not an absolute time. This means that any recipient would have to timestamp it when received, and then recompute the expiration time any time it passed it elsewhere. For instance, when receiving it in an INVITE, it would be timestamped. Then when sending a REFER, the expiration time would have to be updated in the Refer-To header. And then the recipient of the refer would also have to timestamp it, and recompute the expiration time to decide if it is ok to send an INVITE to it. Of course, registrars do this, but this change would extend the pain. > My second question is (assuming the "expirese" parameter could be used in INVITE/200): I may want the Contact URI to be valid for the duration of the dialog for which it was created. However, in most cases it is impossible to know for how long a dialog will last, in order to generate an "expires" value, so I wonder if it would be possible to define some kind of a "session" value, which means that the Contact value is valid only for the duration of the session for which it was generated? Maybe a zero value could be used to indicate this? IMO this is a solution looking for a problem. Do we have a problem where we need to know when Contacts expire? Paul > Regards, > > Christer > Ericsson > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 09:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVp0-0000d5-OM; Thu, 06 Oct 2005 09:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVoz-0000cz-8g for sip@megatron.ietf.org; Thu, 06 Oct 2005 09:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02622 for ; Thu, 6 Oct 2005 09:30:03 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENVy4-0007xe-92 for sip@ietf.org; Thu, 06 Oct 2005 09:39:29 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2005 06:29:55 -0700 X-IronPort-AV: i="3.97,182,1125903600"; d="scan'208"; a="217554047:sNHT24993528" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96DTIKe002956; Thu, 6 Oct 2005 06:29:53 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 09:29:51 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 09:29:51 -0400 Message-ID: <434526CE.3080003@cisco.com> Date: Thu, 06 Oct 2005 09:29:50 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] SIP session without SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 13:29:51.0198 (UTC) FILETIME=[079567E0:01C5CA7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an session description offer, the response (reliable) MUST contain an session description answer. > > First, it is not said that the session description must be a SDP body, so I assume something else could be used too? > > Second, assume that I want to set up a session without SDP (or, another type of session description)? If I include an empty Accept header (or an Accept header where application/sdp is not listed) I don't think the UAS should be mandated to include an SDP offer in the response. > > So, I think the rules in 13.2.1 shall be applicable IF I am using a session description, but I should NOT be mandated to use session description. So you want to set up a session that has no description? Why would you want to do that? That seems *so* wrong! The whole point of INVITE is to negotiate the details of the session. Yes, you could use something else besides SDP - the obvious candidate is SDPng. But using none doesn't seem to fit the intent of INVITE. You can get much the effect you seem to be seeking simply by using SDP that has no m= lines. 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 sip-bounces@ietf.org Thu Oct 06 09:36:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVul-0001QV-48; Thu, 06 Oct 2005 09:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVui-0001Pr-Qk for sip@megatron.ietf.org; Thu, 06 Oct 2005 09:36:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03030 for ; Thu, 6 Oct 2005 09:35:58 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENW3n-0008Dm-QN for sip@ietf.org; Thu, 06 Oct 2005 09:45:25 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 6B55B6C017 for ; Thu, 6 Oct 2005 09:35:50 -0400 (EDT) Subject: Re: [Sip] SIP session without SDP From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Thu, 06 Oct 2005 09:35:50 -0400 Message-Id: <1128605750.15737.26.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote: > Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an > session description offer, the response (reliable) MUST contain an > session description answer. > > First, it is not said that the session description must be a SDP body, > so I assume something else could be used too? Yes. But I do not believe that any other form of session description has been standardized. > Second, assume that I want to set up a session without SDP (or, > another type of session description)? Why would you want to have a dialog with no session description? Though with the advent of MESSAGE, it is possible that one could establish a SIP dialog entirely to be able to pass MESSAGE requests, and thus need no "media" at all. > If I include an empty Accept header (or an Accept header where > application/sdp is not listed) I don't think the UAS should be > mandated to include an SDP offer in the response. Section 20.1 makes it clear that an empty Accept header means that no body formats are acceptable, whereas a missing Accept header is equivalent to "application/sdp". > So, I think the rules in 13.2.1 shall be applicable IF I am using a > session description, but I should NOT be mandated to use session > description. The last paragraphs of section 13.2.1 make it clear that a session description is mandatory only if there is an explicit or implicit "Content-Disposition: session" header. Checking section 20.11 and the IANA registrations (http://www.iana.org/assignments/mail-cont-disp), it does not appear that there is a Content-Disposition that means "no content", but the values "alert", "icon", and "render" would seem safe to use with an empty body. Perhaps a new value "none" is needed? Do you have an application where all this is a serious consideration? If so, you might want to lobby for standardizing "Content-Disposition: none". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 09:40:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVz1-0003ky-EL; Thu, 06 Oct 2005 09:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVz0-0003iz-E7 for sip@megatron.ietf.org; Thu, 06 Oct 2005 09:40:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03527 for ; Thu, 6 Oct 2005 09:40:24 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENW86-0008RL-A7 for sip@ietf.org; Thu, 06 Oct 2005 09:49:50 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id E0A996C017 for ; Thu, 6 Oct 2005 09:40:24 -0400 (EDT) Subject: Re: [Sip] How long is a Contact valid From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Thu, 06 Oct 2005 09:40:24 -0400 Message-Id: <1128606024.15737.28.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote: > My second question is (assuming the "expirese" parameter could be used > in INVITE/200): I may want the Contact URI to be valid for the > duration of the dialog for which it was created. However, in most > cases it is impossible to know for how long a dialog will last, in > order to generate an "expires" value, so I wonder if it would be > possible to define some kind of a "session" value, which means that > the Contact value is valid only for the duration of the session for > which it was generated? Maybe a zero value could be used to indicate > this? These seem to be valid concerns, but I don't see any good way to satisfy them -- in most cases, when a URI ceases to be valid can't be predicted until very close to the moment in question. You might want to look at the TRUU work, which addresses some of these questions. You can start with http://www.ietf.org/mail- archive/web/sip/current/msg12083.html Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 10:09:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWRH-0005a1-Kq; Thu, 06 Oct 2005 10:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWRF-0005Zw-9C for sip@megatron.ietf.org; Thu, 06 Oct 2005 10:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05452 for ; Thu, 6 Oct 2005 10:09:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWaI-0001Eo-Du for sip@ietf.org; Thu, 06 Oct 2005 10:19:01 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2005 10:09:01 -0400 X-IronPort-AV: i="3.97,182,1125892800"; d="scan'208"; a="73193722:sNHT2347774682" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96E8rQp016357; Thu, 6 Oct 2005 10:08:58 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:08:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] How long is a Contact valid Date: Thu, 6 Oct 2005 10:08:56 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3A2E4BD@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] How long is a Contact valid Thread-Index: AcXKerY9MFBULjByQVGKzIFsjxN+GAABC0mA From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" , "Christer Holmberg \(JO/LMF\)" X-OriginalArrivalTime: 06 Oct 2005 14:08:57.0131 (UTC) FILETIME=[7DDE5FB0:01C5CA7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Can't a Contact be "de-Registered" at any time? (Register with Expires=3D0) If so, then any assertion prior to that becomes false. Then it doesn't really matter what you try to tell a remote node, there is a chance it is false. So, why bother? Or, put another way, why is this needed? Mike =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Thursday, October 06, 2005 9:25 AM > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: [Sip] How long is a Contact valid >=20 >=20 >=20 > Christer Holmberg (JO/LMF) wrote: > >=20 > > Hi, > >=20 > > RFC3261 says (also said in the GRUU draft) that a Contact=20 > URI shall be valid for requests outside of the dialog for=20 > which the Contact URI was created. > >=20 > > Currently, however, it is not possible for the creator of=20 > the Contact URI to indicate to the other user for how long=20 > the URI is valid, since the "expires" parameter is only=20 > allowed in REGISTER requests, and 3xx responses. So, the=20 > remote user of course assume that the URI is valid for the=20 > duration of the current dialog (or until a target refresh is=20 > recieved), but it does now know for how long the URI can be=20 > used for requests outside of the dialog. The GRUU draft DOES=20 > say that the URI ideally should be valid as long as the AOR=20 > it's associated to, but that may not always be the case. > >=20 > > My first question is: is there a reason why the "expires"=20 > parameter couldn't be allowed for INVITE requests and 200=20 > responses, to indicate for how long the value is valid for=20 > out-of-current-dialog usage? >=20 > I can think of a pragmatic reason why this might be a bad thing to do: >=20 > The "expires=3D" parameter contains a duration, not an absolute=20 > time. This means that any recipient would have to timestamp=20 > it when received, and then recompute the expiration time any=20 > time it passed it elsewhere. >=20 > For instance, when receiving it in an INVITE, it would be=20 > timestamped.=20 > Then when sending a REFER, the expiration time would have to=20 > be updated in the Refer-To header. And then the recipient of=20 > the refer would also have to timestamp it, and recompute the=20 > expiration time to decide if it is ok to send an INVITE to it. >=20 > Of course, registrars do this, but this change would extend the pain. >=20 > > My second question is (assuming the "expirese" parameter=20 > could be used in INVITE/200): I may want the Contact URI to=20 > be valid for the duration of the dialog for which it was=20 > created. However, in most cases it is impossible to know for=20 > how long a dialog will last, in order to generate an=20 > "expires" value, so I wonder if it would be possible to=20 > define some kind of a "session" value, which means that the=20 > Contact value is valid only for the duration of the session=20 > for which it was generated? Maybe a zero value could be used=20 > to indicate this? >=20 > IMO this is a solution looking for a problem. Do we have a=20 > problem where we need to know when Contacts expire? >=20 > Paul >=20 > > Regards, > >=20 > > Christer > > Ericsson > >=20 > > _______________________________________________ > > 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 > >=20 >=20 > _______________________________________________ > 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=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 13:23:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZT7-0003fy-7D; Thu, 06 Oct 2005 13:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZT5-0003d1-6f for sip@megatron.ietf.org; Thu, 06 Oct 2005 13:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16369 for ; Thu, 6 Oct 2005 13:23:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZcD-0001AE-8R for sip@ietf.org; Thu, 06 Oct 2005 13:33:09 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Oct 2005 13:23:34 -0400 X-IronPort-AV: i="3.97,182,1125892800"; d="scan'208"; a="73225901:sNHT23055584" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96HNTQn009180; Thu, 6 Oct 2005 13:23:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:23:30 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 13:23:30 -0400 Message-ID: <43455D91.7000509@cisco.com> Date: Thu, 06 Oct 2005 13:23:29 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] SIP session without SDP References: <1128605750.15737.26.camel@cdhcp139.pingtel.com> In-Reply-To: <1128605750.15737.26.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 17:23:30.0231 (UTC) FILETIME=[AB941470:01C5CA9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > Why would you want to have a dialog with no session description? > > Though with the advent of MESSAGE, it is possible that one could > establish a SIP dialog entirely to be able to pass MESSAGE requests, and > thus need no "media" at all. This would be an abuse of INVITE. INVITE creates an *invite dialog usage* and as a side effect also may create a dialog. If all you want is a dialog within which to send MESSAGE, then you don't need the invite dialog usage. There are currently two kinds of dialog usage: invite & subscribe. Neither of these is right if all you want is to send MESSAGEs. That is a hint that you are doing something wrong. If you wanted to do that, then the right thing to do would be to come up with a new message-dialog-usage and a way to establish it. But there would be resistance to that - there is resistance to the whole concept of using MESSAGEs within a dialog as a message session. It was considered and rejected in favor of MSRP. 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 sip-bounces@ietf.org Thu Oct 06 14:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENatr-00079L-EA; Thu, 06 Oct 2005 14:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENato-00078e-RS for sip@megatron.ietf.org; Thu, 06 Oct 2005 14:55:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22450 for ; Thu, 6 Oct 2005 14:55:22 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENb2u-0005cZ-PN for sip@ietf.org; Thu, 06 Oct 2005 15:04:52 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id C02106C01D for ; Thu, 6 Oct 2005 14:55:17 -0400 (EDT) Subject: Re: [Sip] SIP session without SDP From: "Dale R. Worley" To: Sip In-Reply-To: <43455D91.7000509@cisco.com> References: <1128605750.15737.26.camel@cdhcp139.pingtel.com> <43455D91.7000509@cisco.com> Content-Type: text/plain Date: Thu, 06 Oct 2005 14:55:17 -0400 Message-Id: <1128624917.15737.62.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-06 at 13:23 -0400, Paul Kyzivat wrote: > This would be an abuse of INVITE. INVITE creates an *invite dialog > usage* and as a side effect also may create a dialog. If all you want is > a dialog within which to send MESSAGE, then you don't need the invite > dialog usage. What is an "invite dialog usage"? I haven't seen that term. Presumably it means more than "a dialog started by an INVITE". > But there would be > resistance to that - there is resistance to the whole concept of using > MESSAGEs within a dialog as a message session. It was considered and > rejected in favor of MSRP. Hmmm, but I see that MSRP is set up using SDP, so it doesn't give an example of a different body-content for INVITE. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 14:59:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaxU-0008AJ-Dl; Thu, 06 Oct 2005 14:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaxS-0008A4-6i for sip@megatron.ietf.org; Thu, 06 Oct 2005 14:59:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22691 for ; Thu, 6 Oct 2005 14:59:08 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENb6b-0005nm-0b for sip@ietf.org; Thu, 06 Oct 2005 15:08:37 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2005 11:59:00 -0700 X-IronPort-AV: i="3.97,183,1125903600"; d="scan'208"; a="349021464:sNHT26416020" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j96IwN5O018139; Thu, 6 Oct 2005 11:58:58 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 14:58:57 -0400 Received: from [161.44.55.132] ([161.44.55.132]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 14:58:57 -0400 Message-ID: <434573F1.8090609@cisco.com> Date: Thu, 06 Oct 2005 14:58:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] SIP session without SDP References: <1128605750.15737.26.camel@cdhcp139.pingtel.com> In-Reply-To: <1128605750.15737.26.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 18:58:57.0559 (UTC) FILETIME=[0154FA70:01C5CAA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dale R. Worley wrote: > On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote: > >>Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an >>session description offer, the response (reliable) MUST contain an >>session description answer. >> >>First, it is not said that the session description must be a SDP body, >>so I assume something else could be used too? > > > Yes. But I do not believe that any other form of session description > has been standardized. > > >>Second, assume that I want to set up a session without SDP (or, >>another type of session description)? > > > Why would you want to have a dialog with no session description? > > Though with the advent of MESSAGE, it is possible that one could > establish a SIP dialog entirely to be able to pass MESSAGE requests, and > thus need no "media" at all. > > >>If I include an empty Accept header (or an Accept header where >>application/sdp is not listed) I don't think the UAS should be >>mandated to include an SDP offer in the response. > > > Section 20.1 makes it clear that an empty Accept header means that no > body formats are acceptable, whereas a missing Accept header is > equivalent to "application/sdp". > > >>So, I think the rules in 13.2.1 shall be applicable IF I am using a >>session description, but I should NOT be mandated to use session >>description. > > > The last paragraphs of section 13.2.1 make it clear that a session > description is mandatory only if there is an explicit or implicit > "Content-Disposition: session" header. Checking section 20.11 and the > IANA registrations (http://www.iana.org/assignments/mail-cont-disp), it > does not appear that there is a Content-Disposition that means "no > content", but the values "alert", "icon", and "render" would seem safe > to use with an empty body. Perhaps a new value "none" is needed? I don't think so. The intent of the paragraphs at the end of 13.2.1 was to say that presence of a jpg in an INVITE does NOT mean that the jpg is the offer. This doesnt mean that its ok to do a SIP INVITE exchange without exchanging session descriptions. Indeed, I think the current text would forbid it (certainly, that was the intent). Note the following: The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13]. This means that the Accept header field has to be either absent (implying support only for SDP), or present and include SDP. It cannot be present and list nothing. As a consqeuence, lack of an offer in the INVITE will trigger an offer in the first reliable response. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Oct 06 15:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbMI-0008Tw-Ho; Thu, 06 Oct 2005 15:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbMH-0008T3-DU for sip@megatron.ietf.org; Thu, 06 Oct 2005 15:24:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25274 for ; Thu, 6 Oct 2005 15:24:47 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENbVP-0006pZ-9i for sip@ietf.org; Thu, 06 Oct 2005 15:34:16 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 254AF6C017 for ; Thu, 6 Oct 2005 15:24:43 -0400 (EDT) Subject: Re: [Sip] SIP session without SDP From: "Dale R. Worley" To: Sip In-Reply-To: <434573F1.8090609@cisco.com> References: <1128605750.15737.26.camel@cdhcp139.pingtel.com> <434573F1.8090609@cisco.com> Content-Type: text/plain Date: Thu, 06 Oct 2005 15:24:42 -0400 Message-Id: <1128626683.15737.84.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-06 at 14:58 -0400, Jonathan Rosenberg wrote: > I don't think so. The intent of the paragraphs at the end of 13.2.1 was > to say that presence of a jpg in an INVITE does NOT mean that the jpg is > the offer. This doesnt mean that its ok to do a SIP INVITE exchange > without exchanging session descriptions. Indeed, I think the current > text would forbid it (certainly, that was the intent). Note the following: > > The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be > supported by all user agents as a means to describe sessions, and its > usage for constructing offers and answers MUST follow the procedures > defined in [13]. > > This means that the Accept header field has to be either absent > (implying support only for SDP), or present and include SDP. It cannot > be present and list nothing. As a consqeuence, lack of an offer in the > INVITE will trigger an offer in the first reliable response. I'm new here, and I can't say what the intent was, but if you read that sentence closely, it does not say that setting up a session with SDP is mandatory in all INVITEs. All it says is that the UA must be able to do so with SDP, and if it does use SDP, it must do so according to [13]. In regard to the Accept header, section 20.1 says (in part): 20.1 Accept An empty Accept header field means that no formats are acceptable. Perhaps an empty Accept header is forbidden elsewhere, but I haven't seen such a statement. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 16:33:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcQy-0001Oi-43; Thu, 06 Oct 2005 16:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENcQw-0001No-5r for sip@megatron.ietf.org; Thu, 06 Oct 2005 16:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13285 for ; Thu, 6 Oct 2005 16:33:39 -0400 (EDT) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENcZx-0006Uh-VU for sip@ietf.org; Thu, 06 Oct 2005 16:43:10 -0400 Received: (qmail 21670 invoked by uid 0); 6 Oct 2005 20:33:17 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Oct 2005 20:33:17 -0000 Message-ID: <009201c5cab5$2cacca60$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "Christer Holmberg \(JO/LMF\)" References: <434525AC.9070103@cisco.com> Subject: Re: [Sip] How long is a Contact valid Date: Thu, 6 Oct 2005 22:33:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer, I can think of at least 2 reasons why an 'expires' parameter for a Contact header in INVITE would not be that useful: 1. The time period for which a Contact address is valid is (currently at least) not under control of the UA (i.e. not known). The UA may propose a desired limit on the period for which the Contact is ~used~ by another party, but it has no way of enforcing this. A possible way to remedy this is described here: http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-01.txt 2. What would the other party do with this information (i.e. when the Contact expires)? As it currently is (and as IMO it should be ) it is up to the UA inserting the Contact header to make sure it is valid at least for the lifetime of the dialog. If it becomes invalid, the UA must send a new Contact (e.g. through UPDATE or re-INVITE); a typical use case is a mobile terminal which changes its IP address. In other words, the responsibility is with the UA that provides the contact, not with the entity using that contact. This is similar to the UA's responsibility to re-register before the registration expires. Regarding a kind of flag to hint the other party that the Contact should not be used outside the dialog, like: Contact: ;use=dialog I think that this is what most UAs assume by default anyway (except perhaps newer ones that recognise 'Supported: gruu' ) Regards, Jeroen ----- Original Message ----- From: "Paul Kyzivat" To: "Christer Holmberg (JO/LMF)" Cc: Sent: Thursday, October 06, 2005 3:25 PM Subject: Re: [Sip] How long is a Contact valid > > > Christer Holmberg (JO/LMF) wrote: >> >> Hi, >> >> RFC3261 says (also said in the GRUU draft) that a Contact URI shall be >> valid for requests outside of the dialog for which the Contact URI was >> created. >> >> Currently, however, it is not possible for the creator of the Contact URI >> to indicate to the other user for how long the URI is valid, since the >> "expires" parameter is only allowed in REGISTER requests, and 3xx >> responses. So, the remote user of course assume that the URI is valid for >> the duration of the current dialog (or until a target refresh is >> recieved), but it does now know for how long the URI can be used for >> requests outside of the dialog. The GRUU draft DOES say that the URI >> ideally should be valid as long as the AOR it's associated to, but that >> may not always be the case. >> >> My first question is: is there a reason why the "expires" parameter >> couldn't be allowed for INVITE requests and 200 responses, to indicate >> for how long the value is valid for out-of-current-dialog usage? > > I can think of a pragmatic reason why this might be a bad thing to do: > > The "expires=" parameter contains a duration, not an absolute time. This > means that any recipient would have to timestamp it when received, and > then recompute the expiration time any time it passed it elsewhere. > > For instance, when receiving it in an INVITE, it would be timestamped. > Then when sending a REFER, the expiration time would have to be updated in > the Refer-To header. And then the recipient of the refer would also have > to timestamp it, and recompute the expiration time to decide if it is ok > to send an INVITE to it. > > Of course, registrars do this, but this change would extend the pain. > >> My second question is (assuming the "expirese" parameter could be used in >> INVITE/200): I may want the Contact URI to be valid for the duration of >> the dialog for which it was created. However, in most cases it is >> impossible to know for how long a dialog will last, in order to generate >> an "expires" value, so I wonder if it would be possible to define some >> kind of a "session" value, which means that the Contact value is valid >> only for the duration of the session for which it was generated? Maybe a >> zero value could be used to indicate this? > > IMO this is a solution looking for a problem. Do we have a problem where > we need to know when Contacts expire? > > Paul > >> Regards, >> >> Christer >> Ericsson >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 06 17:21:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdB6-0006vb-Fg; Thu, 06 Oct 2005 17:21:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdB4-0006vF-7o for sip@megatron.ietf.org; Thu, 06 Oct 2005 17:21:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17167 for ; Thu, 6 Oct 2005 17:21:19 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENdKC-0000q0-C0 for sip@ietf.org; Thu, 06 Oct 2005 17:30:50 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2005 14:21:11 -0700 X-IronPort-AV: i="3.97,184,1125903600"; d="scan'208"; a="349072240:sNHT23582724" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96LKuKM005329; Thu, 6 Oct 2005 14:21:08 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 17:21:08 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 17:21:07 -0400 Message-ID: <43459543.6020606@cisco.com> Date: Thu, 06 Oct 2005 17:21:07 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] SIP session without SDP References: <1128605750.15737.26.camel@cdhcp139.pingtel.com> <43455D91.7000509@cisco.com> <1128624917.15737.62.camel@cdhcp139.pingtel.com> In-Reply-To: <1128624917.15737.62.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 21:21:07.0700 (UTC) FILETIME=[DDB13340:01C5CABB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > On Thu, 2005-10-06 at 13:23 -0400, Paul Kyzivat wrote: > >>This would be an abuse of INVITE. INVITE creates an *invite dialog >>usage* and as a side effect also may create a dialog. If all you want is >>a dialog within which to send MESSAGE, then you don't need the invite >>dialog usage. > > > What is an "invite dialog usage"? I haven't seen that term. Presumably > it means more than "a dialog started by an INVITE". I thought dialog usage was discussed in either 3261 or 3265, but I can't find it right now. In any case it is a not widely understood. There are dialogs, and there are things that use dialogs: invites and subscriptions. The dialog itself has a certain amount of state associated with it. Then each usage has some added state. So, a dialog has: route set, target address, callid, local and remote CSeq, ... A subscribe dialog usage has: a direction (is this a subscriber or notifier), event type, event id, expiration time, ... An invite dialog usage has very little state of its own. I think you can probably consider offer/answer state to be part of this, maybe the most recent offered and answered sdp. >>But there would be >>resistance to that - there is resistance to the whole concept of using >>MESSAGEs within a dialog as a message session. It was considered and >>rejected in favor of MSRP. > > Hmmm, but I see that MSRP is set up using SDP, so it doesn't give an > example of a different body-content for INVITE. Right, because that is just a bad idea. Doing MSRP as a real media stream within a session made it fit into the overall model better. 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 sip-bounces@ietf.org Fri Oct 07 03:09:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmMF-0007Wz-9R; Fri, 07 Oct 2005 03:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmMD-0007WZ-I6 for sip@megatron.ietf.org; Fri, 07 Oct 2005 03:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29890 for ; Fri, 7 Oct 2005 03:09:27 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENmVN-0007Tz-4g for sip@ietf.org; Fri, 07 Oct 2005 03:19:03 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A69934FE; Fri, 7 Oct 2005 09:09:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:05:25 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:05:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] How long is a Contact valid Date: Fri, 7 Oct 2005 09:05:25 +0200 Message-ID: Thread-Topic: [Sip] How long is a Contact valid Thread-Index: AcXKtTBrz+d/NefPRLGneEK9YDbfnwAV9vuQ From: "Christer Holmberg (JO/LMF)" To: "Jeroen van Bemmel" , "Paul Kyzivat" X-OriginalArrivalTime: 07 Oct 2005 07:05:25.0606 (UTC) FILETIME=[7DD52060:01C5CB0D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >As it currently is (and as IMO it should be ) it is up to the=20 >UA inserting the Contact header to make sure it is valid at least for = the=20 >lifetime of the dialog. If it becomes invalid, the UA must send a new = Contact=20 >(e.g. through UPDATE or re-INVITE); a typical use case is a mobile = terminal=20 >which changes its IP address. In other words, the responsibility is = with=20 >the UA that provides the contact, not with the entity using that = contact. This is=20 >similar to the UA's responsibility to re-register before the = registration=20 >expires. [CHH] I don't think the issue is when the Contact is used within the = dialog. Also, in that case it is possible (as you also indicate) to = update it using an UPDATE/re-INVITe. The issue is when it's used outside = the dialog. =20 >Regarding a kind of flag to hint the other party that the=20 >Contact should not be used outside the dialog, like: >Contact: ;use=3Ddialog >=20 >I think that this is what most UAs assume by default anyway=20 >(except perhaps newer ones that recognise 'Supported: gruu' ) [CHH] GRUU is what I had in mind, eventhough I believe 3261 does not = forbid a "normal" Contact to also be use outside the dialog. Regards, Christer > ----- Original Message -----=20 > From: "Paul Kyzivat" > To: "Christer Holmberg (JO/LMF)" > Cc: > Sent: Thursday, October 06, 2005 3:25 PM > Subject: Re: [Sip] How long is a Contact valid >=20 >=20 > > > > > > Christer Holmberg (JO/LMF) wrote: > >> > >> Hi, > >> > >> RFC3261 says (also said in the GRUU draft) that a Contact=20 > URI shall be=20 > >> valid for requests outside of the dialog for which the=20 > Contact URI was=20 > >> created. > >> > >> Currently, however, it is not possible for the creator of=20 > the Contact URI=20 > >> to indicate to the other user for how long the URI is=20 > valid, since the=20 > >> "expires" parameter is only allowed in REGISTER requests, and 3xx=20 > >> responses. So, the remote user of course assume that the=20 > URI is valid for=20 > >> the duration of the current dialog (or until a target refresh is=20 > >> recieved), but it does now know for how long the URI can=20 > be used for=20 > >> requests outside of the dialog. The GRUU draft DOES say=20 > that the URI=20 > >> ideally should be valid as long as the AOR it's associated=20 > to, but that=20 > >> may not always be the case. > >> > >> My first question is: is there a reason why the "expires"=20 > parameter=20 > >> couldn't be allowed for INVITE requests and 200 responses,=20 > to indicate=20 > >> for how long the value is valid for out-of-current-dialog usage? > > > > I can think of a pragmatic reason why this might be a bad=20 > thing to do: > > > > The "expires=3D" parameter contains a duration, not an=20 > absolute time. This=20 > > means that any recipient would have to timestamp it when=20 > received, and=20 > > then recompute the expiration time any time it passed it elsewhere. > > > > For instance, when receiving it in an INVITE, it would be=20 > timestamped.=20 > > Then when sending a REFER, the expiration time would have=20 > to be updated in=20 > > the Refer-To header. And then the recipient of the refer=20 > would also have=20 > > to timestamp it, and recompute the expiration time to=20 > decide if it is ok=20 > > to send an INVITE to it. > > > > Of course, registrars do this, but this change would extend=20 > the pain. > > > >> My second question is (assuming the "expirese" parameter=20 > could be used in=20 > >> INVITE/200): I may want the Contact URI to be valid for=20 > the duration of=20 > >> the dialog for which it was created. However, in most cases it is=20 > >> impossible to know for how long a dialog will last, in=20 > order to generate=20 > >> an "expires" value, so I wonder if it would be possible to=20 > define some=20 > >> kind of a "session" value, which means that the Contact=20 > value is valid=20 > >> only for the duration of the session for which it was=20 > generated? Maybe a=20 > >> zero value could be used to indicate this? > > > > IMO this is a solution looking for a problem. Do we have a=20 > problem where=20 > > we need to know when Contacts expire? > > > > Paul > > > >> Regards, > >> > >> Christer > >> Ericsson > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 03:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmTQ-0002fp-DE; Fri, 07 Oct 2005 03:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmTO-0002eV-Iv for sip@megatron.ietf.org; Fri, 07 Oct 2005 03:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00374 for ; Fri, 7 Oct 2005 03:16:52 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENmcd-0007oj-2g for sip@ietf.org; Fri, 07 Oct 2005 03:26:28 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 45762D01; Fri, 7 Oct 2005 09:16:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:16:51 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:16:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP session without SDP Date: Fri, 7 Oct 2005 09:16:51 +0200 Message-ID: Thread-Topic: [Sip] SIP session without SDP Thread-Index: AcXKqDRndndr+/J2SvSpMJtC7//WBAAZg9aQ From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" , "Dale R. Worley" X-OriginalArrivalTime: 07 Oct 2005 07:16:51.0864 (UTC) FILETIME=[16DFC980:01C5CB0F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, The issus is not whether the UA entity supports SDP or not, but more if = it's mandatory to use for all sessions. Eventhough it's called session description, SIP usess SDP mainly for = MEDIA description (SIP headers and parameters are used to identity the = SIP session). So, the questions is whether an INVITE initiated dialog = MUST contain media. Yes, it is possible to send an SDP without m=3D lines, so if SDP really = is mandated I guess one would have to use that. I just think it would be = a little unecessary to include such SDP if the UA knows that there will = be no media during the dialog. Regards, Christer > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 6. lokakuuta 2005 21:59 > To: Dale R. Worley > Cc: Sip > Subject: Re: [Sip] SIP session without SDP >=20 >=20 > inline. >=20 > Dale R. Worley wrote: >=20 > > On Thu, 2005-10-06 at 10:03 +0200, Christer Holmberg (JO/LMF) wrote: > >=20 > >>Chapter 13.2.1 in RFC3261 says that, if the INVITE does not=20 > contain an > >>session description offer, the response (reliable) MUST contain an > >>session description answer. > >> > >>First, it is not said that the session description must be=20 > a SDP body, > >>so I assume something else could be used too? > >=20 > >=20 > > Yes. But I do not believe that any other form of session=20 > description > > has been standardized. > >=20 > >=20 > >>Second, assume that I want to set up a session without SDP (or, > >>another type of session description)? > >=20 > >=20 > > Why would you want to have a dialog with no session description? > >=20 > > Though with the advent of MESSAGE, it is possible that one could > > establish a SIP dialog entirely to be able to pass MESSAGE=20 > requests, and > > thus need no "media" at all. > >=20 > >=20 > >>If I include an empty Accept header (or an Accept header where > >>application/sdp is not listed) I don't think the UAS should be > >>mandated to include an SDP offer in the response. > >=20 > >=20 > > Section 20.1 makes it clear that an empty Accept header=20 > means that no > > body formats are acceptable, whereas a missing Accept header is > > equivalent to "application/sdp". > >=20 > >=20 > >>So, I think the rules in 13.2.1 shall be applicable IF I am using a > >>session description, but I should NOT be mandated to use session > >>description. > >=20 > >=20 > > The last paragraphs of section 13.2.1 make it clear that a session > > description is mandatory only if there is an explicit or implicit > > "Content-Disposition: session" header. Checking section=20 > 20.11 and the > > IANA registrations=20 > (http://www.iana.org/assignments/mail-cont-disp), it > > does not appear that there is a Content-Disposition that means "no > > content", but the values "alert", "icon", and "render"=20 > would seem safe > > to use with an empty body. Perhaps a new value "none" is needed? >=20 > I don't think so. The intent of the paragraphs at the end of=20 > 13.2.1 was=20 > to say that presence of a jpg in an INVITE does NOT mean that=20 > the jpg is=20 > the offer. This doesnt mean that its ok to do a SIP INVITE exchange=20 > without exchanging session descriptions. Indeed, I think the current=20 > text would forbid it (certainly, that was the intent). Note=20 > the following: >=20 >=20 > The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be > supported by all user agents as a means to describe=20 > sessions, and its > usage for constructing offers and answers MUST follow the=20 > procedures > defined in [13]. >=20 > This means that the Accept header field has to be either absent=20 > (implying support only for SDP), or present and include SDP.=20 > It cannot=20 > be present and list nothing. As a consqeuence, lack of an=20 > offer in the=20 > INVITE will trigger an offer in the first reliable response. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 03:20:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmXL-0003Pc-2D; Fri, 07 Oct 2005 03:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENmXJ-0003PX-Rj for sip@megatron.ietf.org; Fri, 07 Oct 2005 03:20:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00557 for ; Fri, 7 Oct 2005 03:20:56 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENmgZ-0007zi-8h for sip@ietf.org; Fri, 07 Oct 2005 03:30:31 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CEA6110F0; Fri, 7 Oct 2005 09:20:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:19:37 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:19:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP session without SDP Date: Fri, 7 Oct 2005 09:19:36 +0200 Message-ID: Thread-Topic: [Sip] SIP session without SDP Thread-Index: AcXKvBfIE5hRoEqfRNe4SufF0B/65AAUxYiQ From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" , "Dale R. Worley" X-OriginalArrivalTime: 07 Oct 2005 07:19:37.0210 (UTC) FILETIME=[796D95A0:01C5CB0F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >There are dialogs, and there are things that use dialogs: invites and=20 >subscriptions. The dialog itself has a certain amount of state=20 >associated with it. Then each usage has some added state. So,=20 >a dialog has: route set, target address, callid, local and remote CSeq, = ... True. But, all of this is "maintained" using SIP headers/parameters. You = don't need SDP for that. >An invite dialog usage has very little state of its own. I think you = can=20 >probably consider offer/answer state to be part of this, maybe the most = >recent offered and answered sdp. True. But, offer/answer state is needed only when you DO use SDP. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 09:10:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENs00-0002N8-T3; Fri, 07 Oct 2005 09:10:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrzy-0002Ms-FS for sip@megatron.ietf.org; Fri, 07 Oct 2005 09:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16941 for ; Fri, 7 Oct 2005 09:10:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENs9F-0005bE-Vz for sip@ietf.org; Fri, 07 Oct 2005 09:20:31 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 09:10:44 -0400 X-IronPort-AV: i="3.97,186,1125892800"; d="scan'208"; a="73304604:sNHT23502516" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j97DAXBi009007; Fri, 7 Oct 2005 09:10:42 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:10:27 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:10:27 -0400 Message-ID: <434673C2.1070102@cisco.com> Date: Fri, 07 Oct 2005 09:10:26 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] SIP session without SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 13:10:27.0163 (UTC) FILETIME=[7C2D82B0:01C5CB40] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > >>There are dialogs, and there are things that use dialogs: invites and >>subscriptions. The dialog itself has a certain amount of state >>associated with it. Then each usage has some added state. So, >>a dialog has: route set, target address, callid, local and remote CSeq, ... > > > True. But, all of this is "maintained" using SIP headers/parameters. You don't need SDP for that. > > >>An invite dialog usage has very little state of its own. I think you can >>probably consider offer/answer state to be part of this, maybe the most >>recent offered and answered sdp. > > True. But, offer/answer state is needed only when you DO use SDP. No. offer/answer state is needed when you exchange offers and answers, whether you use SDP, SDPng, or something else yet to be invented. The primary *purpose* of the INVITE is to initiate the exchange of offers and answers. I believe it is required to do so. If you don't need the state of the invite dialog usage, then you don't need the INVITE. That was my point in bringing up dialog usages. If all you want to do is exchange MESSAGEs within a dialog, then you should create some new way to establish a message-dialog-usage. 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 sip-bounces@ietf.org Fri Oct 07 09:22:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENsAw-0000wO-4N; Fri, 07 Oct 2005 09:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENsAt-0000wJ-Uy for sip@megatron.ietf.org; Fri, 07 Oct 2005 09:22:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17570 for ; Fri, 7 Oct 2005 09:22:10 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENsKC-0006Az-HR for sip@ietf.org; Fri, 07 Oct 2005 09:31:48 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2005 06:22:03 -0700 X-IronPort-AV: i="3.97,186,1125903600"; d="scan'208"; a="349347927:sNHT26235952" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j97DLuKE008312; Fri, 7 Oct 2005 06:22:00 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:21:59 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 09:21:59 -0400 Message-ID: <43467676.2050206@cisco.com> Date: Fri, 07 Oct 2005 09:21:58 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] SIP session without SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 13:21:59.0210 (UTC) FILETIME=[18AB80A0:01C5CB42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > The issus is not whether the UA entity supports SDP or not, but more if it's mandatory to use for all sessions. > > Eventhough it's called session description, SIP usess SDP mainly for MEDIA description (SIP headers and parameters are used to identity the SIP session). This is not remarkable. Look back at the history of MMUSIC. SDP predates SIP. SDP stands for Session Description Protocol, while SIP stands for Session Initiation Protocol. I don't think it is a coincidence that they both use *session* in their name, and for the most part we should assume that they intend to mean the same thing by it. So SIP initiates sessions by exchanging their descriptions. > So, the questions is whether an INVITE initiated dialog MUST contain media. > > Yes, it is possible to send an SDP without m= lines, so if SDP really is mandated I guess one would have to use that. I just think it would be a little unecessary to include such SDP if the UA knows that there will be no media during the dialog. Yes, I think that is the way it is. If you look back at 2543, it said that you distinguished whether a request contained an offer or not by whether the body contained an m= line. That got pretty ugly, and certainly wasn't easily extensible to other forms of session description. So it was changed to be based on a the presence of a body part with Content-Disposition of session. That change admitted the possibility of establishing a session with no media - via a session description that specifies no media. This is a degenerate case, but a potentially useful one - primarily as an intermediate state when it is known that communication is desired but the media to be used has not been decided. 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 sip-bounces@ietf.org Fri Oct 07 13:56:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwRz-0004uG-Mq; Fri, 07 Oct 2005 13:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwRy-0004uB-61 for sip@megatron.ietf.org; Fri, 07 Oct 2005 13:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02809 for ; Fri, 7 Oct 2005 13:56:04 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwbH-00017X-Om for sip@ietf.org; Fri, 07 Oct 2005 14:05:45 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 212934FC; Fri, 7 Oct 2005 19:56:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 19:56:01 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 19:56:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP session without SDP Date: Fri, 7 Oct 2005 19:56:00 +0200 Message-ID: Thread-Topic: [Sip] SIP session without SDP Thread-Index: AcXLQI0QnnDJDw5MQYeew1qqKKerGgAAsM7Q From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Oct 2005 17:56:00.0721 (UTC) FILETIME=[6092FC10:01C5CB68] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>>There are dialogs, and there are things that use dialogs:=20 >>>invites and subscriptions. The dialog itself has a certain amount of = state=20 >>>associated with it. Then each usage has some added state. So,=20 >>>a dialog has: route set, target address, callid, local and=20 >>>remote CSeq, ... >>True. But, all of this is "maintained" using SIP headers/parameters. = You don't need SDP for that. >>=20 >>=20 >>>An invite dialog usage has very little state of its own. I think you = can=20 >>>probably consider offer/answer state to be part of this, maybe the = most=20 >>>recent offered and answered sdp. >>=20 >>True. But, offer/answer state is needed only when you DO use SDP. >=20 >No. offer/answer state is needed when you exchange offers and=20 >answers, whether you use SDP, SDPng, or something else yet to be = invented. [CHH] True. But, that you do in order to "synchronize" the media. The = only SIP signalling specific related to offer/answer is that you can't = have two outstanding re-INVITEs, but even that you can achieve without = an offer/answer state machine (all you need to know is that you have an = ongoing re-INVITE transaction). >The primary *purpose* of the INVITE is to initiate the exchange of = offers and answers. I believe it is required to do so. [CHH] I think the primary purpose of the INVITE is to initiate the = session - which in most cases also includes initiating the exchange of = offers and answers. >If you don't need the state of the invite dialog usage, then you don't=20 >need the INVITE. That was my point in bringing up dialog usages. If all = >you want to do is exchange MESSAGEs within a dialog, then you should=20 >create some new way to establish a message-dialog-usage. [CHH] Of course that can be done, but I thought using INVITE would be an = easier solution... :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 14:22:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwr4-0004B6-IP; Fri, 07 Oct 2005 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwr2-0004AR-ON for sip@megatron.ietf.org; Fri, 07 Oct 2005 14:22:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04108 for ; Fri, 7 Oct 2005 14:21:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENx0L-0002F2-VZ for sip@ietf.org; Fri, 07 Oct 2005 14:31:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 14:21:50 -0400 X-IronPort-AV: i="3.97,188,1125892800"; d="scan'208"; a="73324792:sNHT24535556" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j97ILSBm027127; Fri, 7 Oct 2005 14:21:47 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 14:21:46 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 14:21:45 -0400 Message-ID: <4346BCB9.7050505@cisco.com> Date: Fri, 07 Oct 2005 14:21:45 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] SIP session without SDP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 18:21:45.0967 (UTC) FILETIME=[F99CCFF0:01C5CB6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > >>>>There are dialogs, and there are things that use dialogs: >>>>invites and subscriptions. The dialog itself has a certain amount of state >>>>associated with it. Then each usage has some added state. So, >>>>a dialog has: route set, target address, callid, local and >>>>remote CSeq, ... >>> >>>True. But, all of this is "maintained" using SIP headers/parameters. You don't need SDP for that. >>> >>>>An invite dialog usage has very little state of its own. I think you can >>>>probably consider offer/answer state to be part of this, maybe the most >>>>recent offered and answered sdp. >>> >>>True. But, offer/answer state is needed only when you DO use SDP. >> >>No. offer/answer state is needed when you exchange offers and >>answers, whether you use SDP, SDPng, or something else yet to be invented. > > [CHH] True. But, that you do in order to "synchronize" the media. The only SIP signalling specific related to offer/answer is that you can't have two outstanding re-INVITEs, but even that you can achieve without an offer/answer state machine (all you need to know is that you have an ongoing re-INVITE transaction). You also cannot have two outstanding offers. E.g. you cannot send an INVITE with an offer, and then follow it with an UPDATE containing another offer before receiving an answer. I don't think we need to get into the details of what state is required to implement the protocol correctly. It is sufficient to say that there is *some* state that is required because of INVITE and offer/answer. And this is specific to INVITE, over and above the state required for dialogs in general. >>The primary *purpose* of the INVITE is to initiate the exchange of offers and answers. I believe it is required to do so. > > [CHH] I think the primary purpose of the INVITE is to initiate the session - which in most cases also includes initiating the exchange of offers and answers. I discussed this further in an earlier message. >>If you don't need the state of the invite dialog usage, then you don't >>need the INVITE. That was my point in bringing up dialog usages. If all >>you want to do is exchange MESSAGEs within a dialog, then you should >>create some new way to establish a message-dialog-usage. > > [CHH] Of course that can be done, but I thought using INVITE would be an easier solution... :) I don't think it is "easier" to change the defintion of INVITE in a way that will probably break many/most UA implementations, in order to support doing something that probably shouldn't be done. 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 sip-bounces@ietf.org Fri Oct 07 15:00:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxSA-0006gs-G3; Fri, 07 Oct 2005 15:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENxS8-0006gi-2q for sip@megatron.ietf.org; Fri, 07 Oct 2005 15:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06204 for ; Fri, 7 Oct 2005 15:00:17 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENxbS-0003rH-Ck for sip@ietf.org; Fri, 07 Oct 2005 15:09:59 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 5F4DB6C01C for ; Fri, 7 Oct 2005 15:00:13 -0400 (EDT) Subject: Re: [Sip] How long is a Contact valid From: "Dale R. Worley" To: Sip In-Reply-To: <009201c5cab5$2cacca60$6402a8c0@BEMBUSTER> References: <434525AC.9070103@cisco.com> <009201c5cab5$2cacca60$6402a8c0@BEMBUSTER> Content-Type: text/plain Date: Fri, 07 Oct 2005 15:00:13 -0400 Message-Id: <1128711613.15737.103.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-06 at 22:33 +0200, Jeroen van Bemmel wrote: > Regarding a kind of flag to hint the other party that the Contact should not > be used outside the dialog, like: > Contact: ;use=dialog > > I think that this is what most UAs assume by default anyway (except perhaps > newer ones that recognise 'Supported: gruu' ) The whole situation is rather perverse. In theory, the Contact (a/k/a target) value was supposed to be globally routable and valid for a long time. Even within 3261, it was realized that the Contact might change during the dialog, and so re-INVITE was admitted. But as J. Rosenberg says in draft-ietf-sip-gruu-05: RFC 3261 mandates that a user agent populate the Contact header field in INVITE requests and responses with a URI that is global (meaning that it can be used from any element connected to the Internet), and that routes to the user agent which inserted it. RFC 3261 also mandates that this URI be valid for requests sent outside of the dialog in which the Contact URI was inserted. In practice, these requirements have proven very difficult to meet. Few endpoints have a hostname that is is present in DNS. Many endpoints have an IP address that is private because the client is behind a NAT. [...] Because of these difficulties, most clients have actually been inserting URIs into the Contact header field of requests and responses with the form sip:. These have the property of routing to the client, but they are generally only reachable from the proxy to which the user is directly connected. So in practice, Contact values may easily have a period of validity that is zero. Alternatively, if the Contact is a GRUU (indicated by "Supported: gruu" in the request/response), you know that it will be valid and for a long time. TRUUs have their own rules, and are valid for the duration of the dialog within which they are used. But in all of these cases, there isn't any particularly useful *additional* knowledge to be gained by the UA attempting to specify the time period for which the Contact will be valid. So I think this "expires" value is one of those ideas which is useful in a theoretical sense, but the vicissitudes of real SIP deployments prevent it from doing much useful in practice. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 18:45:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0yE-000619-FO; Fri, 07 Oct 2005 18:45:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0yD-000611-II for sip@megatron.ietf.org; Fri, 07 Oct 2005 18:45:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00833 for ; Fri, 7 Oct 2005 18:45:38 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO17Z-0008HJ-1g for sip@ietf.org; Fri, 07 Oct 2005 18:55:23 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 4D8EC6C017 for ; Fri, 7 Oct 2005 18:45:34 -0400 (EDT) Subject: Re: [Sip] SIP session without SDP From: "Dale R. Worley" To: Sip In-Reply-To: <4346BCB9.7050505@cisco.com> References: <4346BCB9.7050505@cisco.com> Content-Type: text/plain Date: Fri, 07 Oct 2005 18:45:34 -0400 Message-Id: <1128725134.15737.145.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hmmm... I get the feeling that there are a lot of loose ends in this discussion, and different people are grabbing different loose ends, which is confusing the discussion. Let me try to enumerate what seem to me to be the essential factors. It may be that when INVITE was defined, nobody envisioned that it might be used to establish a dialog that did not have a "media session" (described by SDP or something similar). But there seems to be nothing in the standards to prevent someone from doing so, nor any reason that proxies or other infrastructure agents would fail to process them correctly. There is no currently known purpose for which such a session-less dialog is better than other existing mechanisms. (In particular, applications should avoid sending streams of requests, to avoid overloading proxies.) Trying to establish such a dialog with a current UA will probably fail. (But that is of no consequence, as no current UA intends to use such dialogs.) There is the concept of "dialog usages", which doesn't seem to have been discussed much in recent times, or mentioned in the RFCs, but it is a useful concept for discussing particular subsets of the functioning of a dialog. Currently, there is "invite usage" (embracing media negotiation), and "subscribe usage" (embracing a subscription and its notices). A dialog can contain several usages simultaneously. E.g., a REFER in an INVITE-initiated dialog creates a subscribe usage, or a SUBSCRIBE-initiated dialog can have several further SUBSCRIBEs sent within it, so the dialog contains several subscribe usages. Some operations can affect multiple aspects of a dialog -- for instance, a re-INVITE can change the media session of the invite usage, but also change the target address, which affects all usages (as well as outside- of-usage within-dialog requests like OPTIONS). Nonetheless, there are ways that INVITE-initiated dialogs differ substantially from other dialogs that is not a consequence of usages -- INVITE operates in a way consonant with human attention, generating (with assistance from proxies) only one dialog (despite forking), and tolerating long dialog set-up times. Other requests that initiate dialogs are expected to complete quickly and proxies allow them to initiate multiple dialogs. These features may be orthogonal to the uses to which dialogs are put once they are established, which would suggest decoupling the usages within a dialog from the type of request (INVITE/non-INVITE) used to create it. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 07 19:14:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO1Pj-0008OD-JJ; Fri, 07 Oct 2005 19:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO1Pg-0008Nn-KS for sip@megatron.ietf.org; Fri, 07 Oct 2005 19:14:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02075 for ; Fri, 7 Oct 2005 19:14:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO1Z4-0000iQ-Ab for sip@ietf.org; Fri, 07 Oct 2005 19:23:46 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 19:13:55 -0400 X-IronPort-AV: i="3.97,189,1125892800"; d="scan'208"; a="73340132:sNHT26924388" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j97NDrQl001507; Fri, 7 Oct 2005 19:13:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 19:13:52 -0400 Received: from [161.44.79.143] ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 19:13:52 -0400 Message-ID: <43470130.3030003@cisco.com> Date: Fri, 07 Oct 2005 19:13:52 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> In-Reply-To: <1128725134.15737.145.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 23:13:52.0548 (UTC) FILETIME=[C844D640:01C5CB94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: Sip Subject: [Sip] Dialogs vs Dialog Usages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale, I was agreeing with your summary until the very end. See comment down there. I'm changing the subject line because we have gotten off the original subject. Paul Dale R. Worley wrote: > Hmmm... I get the feeling that there are a lot of loose ends in this > discussion, and different people are grabbing different loose ends, > which is confusing the discussion. Let me try to enumerate what seem to > me to be the essential factors. > > It may be that when INVITE was defined, nobody envisioned that it might > be used to establish a dialog that did not have a "media > session" (described by SDP or something similar). But there seems to be > nothing in the standards to prevent someone from doing so, nor any > reason that proxies or other infrastructure agents would fail to process > them correctly. > > There is no currently known purpose for which such a session-less > dialog is better than other existing mechanisms. (In particular, > applications should avoid sending streams of requests, to avoid > overloading proxies.) > > Trying to establish such a dialog with a current UA will probably fail. > (But that is of no consequence, as no current UA intends to use such > dialogs.) > > There is the concept of "dialog usages", which doesn't seem to have been > discussed much in recent times, or mentioned in the RFCs, but it is a > useful concept for discussing particular subsets of the functioning of a > dialog. Currently, there is "invite usage" (embracing media > negotiation), and "subscribe usage" (embracing a subscription and its > notices). A dialog can contain several usages simultaneously. E.g., a > REFER in an INVITE-initiated dialog creates a subscribe usage, or a > SUBSCRIBE-initiated dialog can have several further SUBSCRIBEs sent > within it, so the dialog contains several subscribe usages. Some > operations can affect multiple aspects of a dialog -- for instance, a > re-INVITE can change the media session of the invite usage, but also > change the target address, which affects all usages (as well as outside- > of-usage within-dialog requests like OPTIONS). > > Nonetheless, there are ways that INVITE-initiated dialogs differ > substantially from other dialogs that is not a consequence of usages -- This is not true. It is only the invite-dialog-usage that differs from other kinds of dialog-usages. It is the usage that has the alerting associated with it, not the dialog. > INVITE operates in a way consonant with human attention, generating > (with assistance from proxies) only one dialog (despite forking), and If there is forking, then one INVITE can generate multiple dialogs. Usually most of them are just early dialogs, but that needn't be the case. And forking of SUBSCRIBE can also result in multiple dialogs. > tolerating long dialog set-up times. Other requests that initiate > dialogs are expected to complete quickly and proxies allow them to > initiate multiple dialogs. These features may be orthogonal to the uses > to which dialogs are put once they are established, which would suggest > decoupling the usages within a dialog from the type of request > (INVITE/non-INVITE) used to create it. Most of the time, when speaking (loosely) about a dialog, people are really talking about a combination of a dialog-usage plus the corresponding dialog. There are a bunch of weird things that are possible, but that nobody ever tries, that would make all these distinctions clearer. E.g. - establish a dialog with SUBSCRIBE, then send an INVITE within it - establish a dialog with INVITE, then send a SUBSCRIBE within it. Then send BYE for the INVITE but keep the subscription active, hence keeping the dialog alive. Then, send another INVITE within the dialog. - send an INVITE that parallel forks. Receive 180 from both forks, and PRACK both of them. Then send a SUBSCRIBE (perhaps to the dialog event package) in each dialog. When one of them answers with a 200, the proxy will cancel the other INVITE. You will then have one dialog with an INVITE and a SUBSCRIBE, and another dialog with just a SUBSCRIBE. Most of these implications were apparently missed when 3261 was put together. The authors hate it, and there are efforts to deprecate the shared use of dialogs. Personally, I think it never should have been there, but the cat is out of the bag, and there is no way of getting it back in the bag. OTOH, if you try these corner cases, I will be surprised if you very often get success. It certainly isn't something people are likely to test for. But it is still useful to understand what the model is. I am aware of people who have established subscriptions to the same event package in both directions over the same dialog. (And it didn't work the first time they tried.) 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 sip-bounces@ietf.org Sat Oct 08 13:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOIvO-0002xa-Fx; Sat, 08 Oct 2005 13:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOIvM-0002tZ-7S for sip@megatron.ietf.org; Sat, 08 Oct 2005 13:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04390 for ; Sat, 8 Oct 2005 13:55:55 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOJ4s-0006Pf-St for sip@ietf.org; Sat, 08 Oct 2005 14:05:48 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j98HxfDn027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Oct 2005 12:59:42 -0500 Message-ID: <434807E7.8020607@softarmor.com> Date: Sat, 08 Oct 2005 12:54:47 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> In-Reply-To: <43470130.3030003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Sip Subject: [Sip] Crazy PaulK Dialog Usages andCrazier Pracical Idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > - establish a dialog with SUBSCRIBE, then send an INVITE within it Oddly enough, I never thought of this before. And I'm NOT recommending it now. But here's something to think about: In OMA's PoC architecture, some mobile UAs have long-lived relationships with network UAs called "Participating Functions", (PF). In the current spec, the mobile UA at start time sends an INVITE to its PF and establishes a dialog. This dialog is basically used like a conference call. When the mobile UA wants to talk to somebody else, the mobile UA sends a REFER within that dialog to the PF, with the Refer-To: pointing at the target, and the PF then generates an INVITE to the target. For calls in the other direction, the PF gets the INVITE and informs the mobile UA of the new call via a conference-package-like NOTIFY, generally accepting the INVITE after the mobile UA sends 200 for the NOTIFY (but sometimes not -- in the interest of performance tweaking, it can respond speculatively and send an "unconfirmed indication"). Why all the trickiness? This gives us an in-network high-bandwidth point that can manage (and serialize) concurrent flows to the mobile, so that the mobile's tiny-little-capillary bandwidth doesn't get logjammed. It also lets us fake-out some of the user-experience of latency that might otherwise occur. The PF acts as a signaling-and-media B2BUA to gain this control. It also keeps us from having to send media descriptions over-the-air for every call (ostensibly saving tons of bandwidth) -- the long-lived INVITE negotiates the offer-answer options for all later calls on that side. But I'm starting to speculate how this might look if the long-lived dialog were established via a SUBSCRIBE (perhaps to a new event package) and calls were set up by sending INVITE within that dialog, instead of REFER. Hmmm. -- 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 sip-bounces@ietf.org Sat Oct 08 15:22:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOKGl-0007Vm-Sw; Sat, 08 Oct 2005 15:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOKGj-0007Ve-KG for sip@megatron.ietf.org; Sat, 08 Oct 2005 15:22:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08904 for ; Sat, 8 Oct 2005 15:22:03 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOKQG-0008QP-08 for sip@ietf.org; Sat, 08 Oct 2005 15:31:58 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 261076C017 for ; Sat, 8 Oct 2005 15:21:56 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: <43470130.3030003@cisco.com> References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> Content-Type: text/plain Date: Sat, 08 Oct 2005 15:21:55 -0400 Message-Id: <1128799316.21489.4.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Dialogs vs Dialog Usages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Fri, 2005-10-07 at 19:13 -0400, Paul Kyzivat wrote: > > INVITE operates in a way consonant with human attention, generating > > (with assistance from proxies) only one dialog (despite forking), and > > If there is forking, then one INVITE can generate multiple dialogs. > Usually most of them are just early dialogs, but that needn't be the > case. And forking of SUBSCRIBE can also result in multiple dialogs. True, the difference is not absolute. But in an INVITE situation, the proxies attempt to prevent the establishment of more than one confirmed dialog, whereas in a SUBSCRIBE situation, they are forbidden from trying to prune the set of dialogs. In various cases, this makes various sorts of difference. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 08 19:17:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EONwU-00015w-NZ; Sat, 08 Oct 2005 19:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EONwS-00014o-FF for sip@megatron.ietf.org; Sat, 08 Oct 2005 19:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19343 for ; Sat, 8 Oct 2005 19:17:21 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOO60-00057Q-Tm for sip@ietf.org; Sat, 08 Oct 2005 19:27:19 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2005 16:17:13 -0700 X-IronPort-AV: i="3.97,190,1125903600"; d="scan'208"; a="349809270:sNHT23017196" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j98NHA4u002922; Sat, 8 Oct 2005 16:17:10 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 19:17:09 -0400 Received: from [10.86.242.114] ([10.86.242.114]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Oct 2005 19:17:09 -0400 Message-ID: <43485374.2070608@cisco.com> Date: Sat, 08 Oct 2005 19:17:08 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] Re: Dialogs vs Dialog Usages References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> <1128799316.21489.4.camel@cdhcp139.pingtel.com> In-Reply-To: <1128799316.21489.4.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2005 23:17:09.0479 (UTC) FILETIME=[680FDF70:01C5CC5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > On Fri, 2005-10-07 at 19:13 -0400, Paul Kyzivat wrote: > >>>INVITE operates in a way consonant with human attention, generating >>>(with assistance from proxies) only one dialog (despite forking), and >> >>If there is forking, then one INVITE can generate multiple dialogs. >>Usually most of them are just early dialogs, but that needn't be the >>case. And forking of SUBSCRIBE can also result in multiple dialogs. > > > True, the difference is not absolute. But in an INVITE situation, the > proxies attempt to prevent the establishment of more than one confirmed > dialog, whereas in a SUBSCRIBE situation, they are forbidden from trying > to prune the set of dialogs. They are? That is news to me. Where is that specified? > In various cases, this makes various sorts > of difference. I think there is less difference than people think. 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 sip-bounces@ietf.org Mon Oct 10 02:19:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOr0a-0000fG-Dt; Mon, 10 Oct 2005 02:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOr0W-0000ek-Ew for sip@megatron.ietf.org; Mon, 10 Oct 2005 02:19:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17593 for ; Mon, 10 Oct 2005 02:19:30 -0400 (EDT) From: Udit_Goyal@3com.com Received: from ahmler4.mail.eds.com ([192.85.154.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOrAJ-00026b-Fr for sip@ietf.org; Mon, 10 Oct 2005 02:29:42 -0400 Received: from ahmlir3.mail.eds.com (ahmlir3-2.mail.eds.com [192.85.154.133]) by ahmler4.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9A6J2Z0002163; Mon, 10 Oct 2005 02:19:02 -0400 Received: from ahmlir3.mail.eds.com (localhost [127.0.0.1]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9A6IIJ4004044; Mon, 10 Oct 2005 02:18:18 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir3.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9A6II0c004039; Mon, 10 Oct 2005 02:18:18 -0400 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Mon, 10 Oct 2005 02:25:02 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/09/2005 11:18:18 PM, Serialize complete at 10/09/2005 11:18:18 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF Subject: [Sip] Changing contact address X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897228696==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0897228696== Content-Type: multipart/alternative; boundary="=_alternative 00227B5385257096_=" This is a multipart message in MIME format. --=_alternative 00227B5385257096_= Content-Type: text/plain; charset="US-ASCII" Hi, If UAC wants to change its contact address i.e. target set, as per RFC 3261, UAC ca nsedn REINVITE for that. Is it possible to send Re-INVITE without any sdp, as it does not want to change any media or renegotiate any media, because if send without SDP, then UAS can consider it as asking for offer. Thanks, Udit --=_alternative 00227B5385257096_= Content-Type: text/html; charset="US-ASCII"
Hi,

If UAC wants to change its contact address i.e. target set, as per RFC 3261, UAC ca nsedn REINVITE for that.

Is it possible to send Re-INVITE without any sdp, as it does not want to change any media or renegotiate any media,

because if send without SDP, then UAS can consider it as asking for offer.

Thanks,
Udit
--=_alternative 00227B5385257096_=-- --===============0897228696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0897228696==-- From sip-bounces@ietf.org Mon Oct 10 02:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrdN-0006q6-7f; Mon, 10 Oct 2005 02:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOrdL-0006q1-4g for sip@megatron.ietf.org; Mon, 10 Oct 2005 02:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20743 for ; Mon, 10 Oct 2005 02:59:37 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOrn7-0003I8-2g for sip@ietf.org; Mon, 10 Oct 2005 03:09:50 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 41318C55; Mon, 10 Oct 2005 08:59:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 08:58:50 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 08:58:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Changing contact address Date: Mon, 10 Oct 2005 08:58:49 +0200 Message-ID: Thread-Topic: [Sip] Changing contact address Thread-Index: AcXNYzX/plgTuLCOSo67rm7VvINMuAABGjiw From: "Christer Holmberg (JO/LMF)" To: , "SIP Implementors" X-OriginalArrivalTime: 10 Oct 2005 06:58:50.0307 (UTC) FILETIME=[11748930:01C5CD68] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >If UAC wants to change its contact address i.e. target set, as per RFC = 3261, UAC ca nsedn REINVITE for that.=20 > >Is it possible to send Re-INVITE without any sdp, as it does not want = to change any media or renegotiate any media,=20 > >because if send without SDP, then UAS can consider it as asking for = offer.=20 It is possible to send a re-INVITE without SDP, but in that case the UAS = is mandated to send an SDP offer to you. There are different = understandings on how that offer shall be contstructed, though. But, another way is to include SDP in the re-INVITE, and to keep the = version part of the SDP origin parameter unchanged, which indicates that = the session description is unchanged. Regards, Christer Ericsson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 10 07:10:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvXu-0002oy-JS; Mon, 10 Oct 2005 07:10:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvXs-0002os-Mp for sip@megatron.ietf.org; Mon, 10 Oct 2005 07:10:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01553 for ; Mon, 10 Oct 2005 07:10:13 -0400 (EDT) Received: from mail.batmbg.com ([212.91.166.210]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EOvhi-00017B-QE for sip@ietf.org; Mon, 10 Oct 2005 07:20:30 -0400 Received: (qmail 14418 invoked from network); 10 Oct 2005 11:16:50 -0000 Received: from dune.batmbg.com (HELO ?192.168.0.15?) (192.168.0.15) by mars.batmbg.com with SMTP; 10 Oct 2005 11:16:50 -0000 Message-ID: <434A4AE0.7060509@batmbg.com> Date: Mon, 10 Oct 2005 14:05:04 +0300 From: George Petrov Georgiev Rusiichev Organization: BATM User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Sip] 491 Request Pending X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi all, I have a question about "491 Request Pending" RFC 3261 says: 21.4.27 491 Request Pending The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such "glare" situations are resolved. so, my question is: Is is acceptable for UAS to get "491 Request Pending" for for some other than INVITE and UPDATE requests? If not, I suppose if UAS receives 491 for non-INVITE (or outside a dialog)- it should be treated as general 4xx. Thanks in advance. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 10 14:40:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2Zj-0004tA-9W; Mon, 10 Oct 2005 14:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2Zi-0004t5-5f for sip@megatron.ietf.org; Mon, 10 Oct 2005 14:40:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11772 for ; Mon, 10 Oct 2005 14:40:36 -0400 (EDT) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2jd-0004dD-9Z for sip@ietf.org; Mon, 10 Oct 2005 14:50:55 -0400 Received: from jh by harjus.tutpro.com with local (Exim 4.50) id 1EP2ZV-0000tI-Jn for sip@ietf.org; Mon, 10 Oct 2005 21:40:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17226.46489.590660.450803@harjus.tutpro.com> Date: Mon, 10 Oct 2005 21:40:25 +0300 To: sip@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Sip] impractical keying requirement in sip identity draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org in my opinion, it is no practical to require that a company would supply private keying material regarding its domain to whoever party that happens to host its sip proxy service. that simply does not happen. if sip srv record of, say, cisco.com, points to sip.provider.com, then it must suffice that sip.provider.com uses its own keying material to sign the identity of cisco.com users. and even if sip.provider.com proxy would posses keying material of domain cisco.com, i don't understand how it could know which server certificate it should present to a sip ua when it establishes tls connection with the proxy, because that happens before the sip ua has sent any sip requests and because it is impractical to require that each domain would have its own ip address or port at the proxy. it may be that i'm missing something, but if not, it makes no sense for ietf to write specifications that cannot have real world implementations. -- 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 sip-bounces@ietf.org Tue Oct 11 01:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCbH-0004g7-TL; Tue, 11 Oct 2005 01:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCbF-0004fv-RM for sip@megatron.ietf.org; Tue, 11 Oct 2005 01:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15890 for ; Tue, 11 Oct 2005 01:22:52 -0400 (EDT) Received: from [203.145.183.217] (helo=203.145.183.217) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPClH-0004UZ-WE for sip@ietf.org; Tue, 11 Oct 2005 01:33:17 -0400 Received: from [192.168.10.74] ([192.168.10.74]) by 203.145.183.217 (8.12.11/8.12.11) with ESMTP id j9B5I0cc010793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2005 10:48:01 +0530 From: Suganya To: sip@ietf.org Content-Type: text/plain Message-Id: <1129008161.6628.1.camel@suganya> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 11 Oct 2005 10:52:42 +0530 Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-MailScanner-From: suganya@dgbmicro.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] 181 Call is being forwarded X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi all, I need to know if a UA can send 181 response. In RFC 3261, it is given that this response will be sent by a server and no mention about UAs. Regards, B.Suganya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 11 02:18:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDTD-0006lx-Ex; Tue, 11 Oct 2005 02:18:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDTB-0006ls-IP for sip@megatron.ietf.org; Tue, 11 Oct 2005 02:18:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01095 for ; Tue, 11 Oct 2005 02:18:33 -0400 (EDT) Received: from p04.nexlink.net ([80.86.195.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPDdB-0005eo-Ks for sip@ietf.org; Tue, 11 Oct 2005 02:28:59 -0400 Received: (qmail 7362 invoked from network); 11 Oct 2005 06:13:31 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 11 Oct 2005 06:13:31 -0000 Received: from d83-177-209-129.cust.tele2.fr (d83-177-209-129.cust.tele2.fr [83.177.209.129]) by webmail.tech-invite.com (IMP) with HTTP for ; Tue, 11 Oct 2005 08:13:31 +0200 Message-ID: <1129011211.434b580b3fa2a@webmail.tech-invite.com> Date: Tue, 11 Oct 2005 08:13:31 +0200 From: =?iso-8859-1?b?Sm/rbA==?= Repiquet To: Sipping MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 83.177.209.129 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Subject: [Sip] ABNF for Content-Disposition X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org RFC 3959 defines 'early-session' as a new disposition type value for the Content-Disposition header field and registers it at the IANA: http://www.iana.org/assignments/mail-cont-disp Why the 'disp-type' ABNF rule, defined in RFC3261: disp-type = "render" / "session" / "icon" / "alert" / disp-extension-token is not modified accordingly in this RFC? Note that the same occurs with RFC3893 that defines the 'aib' value... Is it correct to define the current disp-type rule as: disp-type = "render" / "session" / "icon" / "alert" / "early-session" / "aib" / disp-extension-token Thanks ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 11 04:17:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPFJm-00067W-4i; Tue, 11 Oct 2005 04:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPFJj-00067E-Fq for sip@megatron.ietf.org; Tue, 11 Oct 2005 04:16:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07179 for ; Tue, 11 Oct 2005 04:16:57 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPFTm-0000PK-Sy for sip@ietf.org; Tue, 11 Oct 2005 04:27:24 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9B8Gjw3011552 for ; Tue, 11 Oct 2005 03:16:46 -0500 (CDT) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Oct 2005 16:17:36 +0800 Received: from [135.252.136.79] ([135.252.136.79]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Oct 2005 16:17:36 +0800 Message-ID: <434B751F.7050908@lucent.com> Date: Tue, 11 Oct 2005 16:17:35 +0800 From: "Bourne Li" User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: "Suganya" Subject: Re: [Sip] 181 Call is being forwarded References: <1129008161.6628.1.camel@suganya> In-Reply-To: <1129008161.6628.1.camel@suganya> X-OriginalArrivalTime: 11 Oct 2005 08:17:36.0634 (UTC) FILETIME=[3CFA8DA0:01C5CE3C] X-Spam-Score: 0.5 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bbli@lucent.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769262782==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1769262782== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="------------070708050300080007070807" This is a multi-part message in MIME format. --------------070708050300080007070807 Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Suganya, RFC 3261 section 6 defines the server, UA and UAS: Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, *user agent servers*, redirect servers, and registrars. User Agent (UA): A logical entity that can act as both a user agent client and *user agent server*. User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. So, if UA can provide the call forwarding like service, which can generate the 181 response. Then, this UA is taking the UAS role and is one type of server. Regards, Bourne Suganya wrote: > Hi all, > > I need to know if a UA can send 181 response. In RFC 3261, it is given > that this response will be sent by a server and no mention about UAs. > > Regards, > B.Suganya > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > --------------070708050300080007070807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Suganya,

RFC 3261 section 6 defines the server, UA and UAS:

Server: A server is a network element that receives requests in
         order to service them and sends back responses to those
         requests.  Examples of servers are proxies, user agent servers,
         redirect servers, and registrars.

User Agent (UA): A logical entity that can act as both a user
         agent client and user agent server.

User Agent Server (UAS): A user agent server is a logical entity
         that generates a response to a SIP request.  The response
         accepts, rejects, or redirects the request.  This role lasts
         only for the duration of that transaction.  In other words, if
         a piece of software responds to a request, it acts as a UAS for
         the duration of that transaction.  If it generates a request
         later, it assumes the role of a user agent client for the
         processing of that transaction.

So, if UA can provide the call forwarding like service, which can generate the 181 response. Then, this UA is taking the UAS role and is one type of server.

Regards,
Bourne

Suganya wrote: 
Hi all,

I need to know if a UA can send 181 response. In RFC 3261, it is given
that this response will be sent by a server and no mention about UAs.

Regards,
B.Suganya


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--------------070708050300080007070807-- --===============1769262782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1769262782==-- From sip-bounces@ietf.org Tue Oct 11 17:25:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRcj-00066m-Pz; Tue, 11 Oct 2005 17:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRci-00066I-Er for sip@megatron.ietf.org; Tue, 11 Oct 2005 17:25:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05264 for ; Tue, 11 Oct 2005 17:25:21 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPRmr-0002Fz-Rz for sip@ietf.org; Tue, 11 Oct 2005 17:35:56 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9BLUBmK004947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Oct 2005 16:30:12 -0500 In-Reply-To: <1129011211.434b580b3fa2a@webmail.tech-invite.com> References: <1129011211.434b580b3fa2a@webmail.tech-invite.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] ABNF for Content-Disposition Date: Tue, 11 Oct 2005 16:25:15 -0500 To: =?ISO-8859-1?Q?Jo=EBl_Repiquet?= X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Sipping X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 11, 2005, at 1:13 AM, Jo=EBl Repiquet wrote: > RFC 3959 defines 'early-session' as a new disposition type value =20 > for the > Content-Disposition header field and registers it at the IANA: > http://www.iana.org/assignments/mail-cont-disp > > Why the 'disp-type' ABNF rule, defined in RFC3261: > disp-type =3D "render" / "session" / "icon" / "alert" / > disp-extension-token > > is not modified accordingly in this RFC? > > Note that the same occurs with RFC3893 that defines the 'aib' value... > > > Is it correct to define the current disp-type rule as: > disp-type =3D "render" / "session" / "icon" / "alert" / > "early-session" / "aib" / disp-extension-token My take is that since disp-extension-token effectively includes the =20 set of disposition-type values registered with IANA that your more =20 detailed grammar is syntactically equivalent. That's why not every SIP extension requires us to replace the grammar =20= used in RFC 3261. -- 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 sip-bounces@ietf.org Thu Oct 13 11:36:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ583-00014O-Nm; Thu, 13 Oct 2005 11:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ581-000143-Ln for sip@megatron.ietf.org; Thu, 13 Oct 2005 11:36:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24280 for ; Thu, 13 Oct 2005 11:36:17 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ5IW-0006zk-Uj for sip@ietf.org; Thu, 13 Oct 2005 11:47:15 -0400 Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 40902194472 for ; Thu, 13 Oct 2005 17:36:00 +0200 (CEST) Received: from [192.168.1.35] ([192.168.1.35]) by office-srv-04.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Oct 2005 17:38:11 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] How long is a Contact valid Date: Thu, 13 Oct 2005 17:35:59 +0200 To: "Christer Holmberg (JO/LMF)" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 13 Oct 2005 15:38:11.0255 (UTC) FILETIME=[1E111C70:01C5D00C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 6, 2005, at 10:03 AM, Christer Holmberg (JO/LMF) wrote: > > > Hi, > > RFC3261 says (also said in the GRUU draft) that a Contact URI shall be > valid for requests outside of the dialog for which the Contact URI was > created. I would say the contact is valid as long as the dialog that it was created for is valid. Hisham > > Currently, however, it is not possible for the creator of the Contact > URI to indicate to the other user for how long the URI is valid, since > the "expires" parameter is only allowed in REGISTER requests, and 3xx > responses. So, the remote user of course assume that the URI is valid > for the duration of the current dialog (or until a target refresh is > recieved), but it does now know for how long the URI can be used for > requests outside of the dialog. The GRUU draft DOES say that the URI > ideally should be valid as long as the AOR it's associated to, but > that may not always be the case. > > My first question is: is there a reason why the "expires" parameter > couldn't be allowed for INVITE requests and 200 responses, to indicate > for how long the value is valid for out-of-current-dialog usage? > > My second question is (assuming the "expirese" parameter could be used > in INVITE/200): I may want the Contact URI to be valid for the > duration of the dialog for which it was created. However, in most > cases it is impossible to know for how long a dialog will last, in > order to generate an "expires" value, so I wonder if it would be > possible to define some kind of a "session" value, which means that > the Contact value is valid only for the duration of the session for > which it was generated? Maybe a zero value could be used to indicate > this? > > Regards, > > Christer > Ericsson > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 13 12:18:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5lb-0005TU-Fn; Thu, 13 Oct 2005 12:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5lY-0005TI-PS for sip@megatron.ietf.org; Thu, 13 Oct 2005 12:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26614 for ; Thu, 13 Oct 2005 12:17:08 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ5w1-0008Bi-5q for sip@ietf.org; Thu, 13 Oct 2005 12:28:06 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EB2054F0003; Thu, 13 Oct 2005 17:46:54 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 17:45:55 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Oct 2005 17:45:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] How long is a Contact valid Date: Thu, 13 Oct 2005 17:45:55 +0200 Message-ID: Thread-Topic: [Sip] How long is a Contact valid Thread-Index: AcXQC9HSVgapeEdVSgKa5yO7rC3tFQAASbsw From: "Christer Holmberg (JO/LMF)" To: "Hisham Khartabil" X-OriginalArrivalTime: 13 Oct 2005 15:45:55.0640 (UTC) FILETIME=[32DCA380:01C5D00D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, >>RFC3261 says (also said in the GRUU draft) that a Contact=20 >>URI shall be valid for requests outside of the dialog for which the=20 >>Contact URI was created. >=20 >I would say the contact is valid as long as the dialog that it was=20 >created for is valid. The issue behind this discussion is that a contact may be valid also = after the dialog has been terminated. Regards, Christer > > > > Currently, however, it is not possible for the creator of=20 > the Contact=20 > > URI to indicate to the other user for how long the URI is=20 > valid, since=20 > > the "expires" parameter is only allowed in REGISTER=20 > requests, and 3xx=20 > > responses. So, the remote user of course assume that the=20 > URI is valid=20 > > for the duration of the current dialog (or until a target=20 > refresh is=20 > > recieved), but it does now know for how long the URI can be=20 > used for=20 > > requests outside of the dialog. The GRUU draft DOES say=20 > that the URI=20 > > ideally should be valid as long as the AOR it's associated to, but=20 > > that may not always be the case. > > > > My first question is: is there a reason why the "expires" parameter=20 > > couldn't be allowed for INVITE requests and 200 responses,=20 > to indicate=20 > > for how long the value is valid for out-of-current-dialog usage? > > > > My second question is (assuming the "expirese" parameter=20 > could be used=20 > > in INVITE/200): I may want the Contact URI to be valid for the=20 > > duration of the dialog for which it was created. However, in most=20 > > cases it is impossible to know for how long a dialog will last, in=20 > > order to generate an "expires" value, so I wonder if it would be=20 > > possible to define some kind of a "session" value, which means that=20 > > the Contact value is valid only for the duration of the session for=20 > > which it was generated? Maybe a zero value could be used to=20 > indicate=20 > > this? > > > > Regards, > > > > Christer > > Ericsson > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 13 19:28:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCV0-0004Er-Mf; Thu, 13 Oct 2005 19:28:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCUz-0004Em-BU for sip@megatron.ietf.org; Thu, 13 Oct 2005 19:28:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03454 for ; Thu, 13 Oct 2005 19:28:28 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQCfa-0007ZR-Qz for sip@ietf.org; Thu, 13 Oct 2005 19:39:31 -0400 Received: from [192.168.2.103] ([12.5.186.28]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9DNXMxE018404 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Oct 2005 18:33:23 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <321D79D4-71D6-4959-8E25-4D7E2766342B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 13 Oct 2005 18:28:22 -0500 To: Sipping List , Gonzalo Camarillo X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Allison Mankin Subject: [Sip] Expert review of draft-camarillo-sipping-user-database-01.txt: Revision required X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIPPING Working Group: Please consider the following "P-header expert review" and let us know if you have any issues with it or further suggestions to make. ---------- Publication of draft-camarillo-sipping-user-database-01.txt as an informational document defining P-headers has been requested. Under the terms of RFC 3427, this requires addressing the following 7 requirements: 1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance to these guidelines. The Expert Reviewer will send email to the Transport Area Directors on this determination. The expert reviewer can cite one or more of the guidelines that haven't been followed in his/her opinion. Dean Willis was selected as the designated expert for this review. As per the current practice, the resulting review will have been discussed in the SIP community via the SIPPING working group's mailing list and evaluated for rough technical consensus before reporting a conclusive positive review to the Area Directors. 2. The proposed extension MUST NOT define SIP option tags, response codes, or methods. The reviewed document defines one "P-header" without an option tag, response code, or method, and therefore satisfies this requirement. 3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions. The proposed header provides for the communication of locally-valid state information between two proxies in the IMS environment as defined by 3GPP. It does not appear to relate in any significant way to any ongoing, planned, proposed, or even whimsically discussed work of the IETF known to the reviewer, and therefore satisfies this requirement. 4. The proposed header MUST be of a purely informational nature, and MUST NOT significantly change the behavior of SIP entities which support it. Headers which merely provide additional information pertinent to a request or a response are acceptable. If the headers redefine or contradict normative behavior defined in standards track SIP specifications, that is what is meant by significantly different behavior. The proposed header conveys information about the back-end database used by the originating proxy to a receiving proxy in the same IMS operator domain. This prevents the receiving proxy from having to repeat the resolution process used by the first proxy. In the absence of this extension, the resulting call flow would be identical, but would require one additional database operation. Consequently, the proposed extension appears to be consistent with the intent of this requirement. 5. The proposed header MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new header MUST address security issues in detail as if it were a Standards Track document. Note that, if the intended application scenario makes certain assumptions regarding security, the security considerations only need to meet the intended application scenario rather than the general Internet case. In any case, security issues need to be discussed for arbitrary usage scenarios (including the general Internet case). The proposed extension header, "P-User-Database" applies only in IMS environments where the originating proxy (The P-CSCF) and the terminating proxy (the S-CSCF) exist in a protected environment sharing a mutual frame of reference to the database in question. The security relationship between these elements is defined by the IMS sprcifications. The text given as the "Security Consideration" section of the reviewed document follows: "The P-User-Database defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physically protecting the network. In any case, the environment where the P-User-Database header field will be used ensures the integrity and the confidentiality of the contents of this header field." While the above text is believed correct, this reviewer finds these considerations to provide inadequate guidance to future readers of this specification who may not be conversant with the characteristics of IMS. No explicit reference to IMS is made by the reviewed document, and the characteristics of IMS that make the proposed extension viable are not elucidated by the reviewed document. This could be corrected by an explicit reference to IMS specifications, and by the inclusion in the revisions to the reviewed document of a summary elucidation of the relevant characteristics of IMS: * The "P-User-Database" header field is inserted by a proxy element referred to as P-CSCF. * The "P-User-Database" header field is consumed and removed by a proxy element referred to as S-CSCF. * Both P-CSCF and S-CSCF are under the administrative control of a single operator, and share a common frame of reference to the database indicated by the P-User-Database header field. The preceding elucidations or equivalent material should be contained in the "Applicability Statement" section of the final RFC. * There is a slight security risk if the the P-User-Database header field is allowed is allowed to propagate out of the domain bounded by the administrative control of that operator. No user-sensitive information would be revealed by such a breach, but this could result in disclosure of information about the topology of the operator network that goes beyond the level of disclosure explicit in SIP messages without this extension. Consequently, operators my wish to be diligent about removal of the P-User-Database header field before sending a request containing it to other network operators or to user equipment. The preceding elucidation or equivalent material should be contained in the "Security Considerations" section of the final RFC. 6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with IANA. The reviewed document is intended to become the informational RFC required by this consideration. Acceptance of this document for publication as an informational RFC will address this requirement. 7. An applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet. The reviewed document contains an applicability statement. This reviewer finds he current applicability statement inadequate, and has discussed additional material earlier in this review that if added should make the applicability statement adequate to address this consideration. Note: It has been suggested to this reviewer that the proposed extension header field would benefit from the inclusion of extension parameter syntax, which has become the common practice for SIP extensions. Therefore it is suggested that the syntax be amended as follows: OLD: P-User-Database = "P-User-Database" HCOLON database NEW: P-User-Database = "P-User-Database" HCOLON database *( SEMI generic-param ) Further note: The document makes explicit reference to RFC 2119, but does not invoke any of the language of that RFC. For consistency with the current practices relating to informational-track documents, reference to RFC 2119 and the associated language definition section should be removed from revisions to the reviewed document. Conclusion: While the proposed extension header is consistent with the requirements of RFC 3427, the document as reviewed fails to satisfactorily address the "Applicability Statement" and "Security Considerations" requirements of that RFC, requires two additional content modifications (syntax change and removal of RFC 2119 references) and is therefore remanded to the author for revision. -- Dean Willis designated reviewer for draft-camarillo-sipping-user-database-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 13 19:39:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCfB-0008Fa-BZ; Thu, 13 Oct 2005 19:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQCf9-0008Eo-CC for sip@megatron.ietf.org; Thu, 13 Oct 2005 19:39:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04168 for ; Thu, 13 Oct 2005 19:38:58 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQCpk-0007uf-8C for sip@ietf.org; Thu, 13 Oct 2005 19:50:01 -0400 Received: from [192.168.2.103] ([12.5.186.28]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9DNhx1P018467 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 13 Oct 2005 18:43:59 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sipping List From: Dean Willis Date: Thu, 13 Oct 2005 18:39:00 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] Offer of meeting space from Pulver for VOIP-related ad-hoc and supplemental WG meetings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Pulver.com has offered to provide reasonable accomodations for ad-hoc or supplemental working group meetings in conjunction with their VON and IP.4.IT shows. The next IP.4.IT is scheduled for the week after IETF 64, and will be located in Las Vegas, Nevada at the Rio Hotel and Casino. Does anyone have a need for a supplemental WG or ad-hoc meeting that week and want to meet in Las Vegas? -- 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 sip-bounces@ietf.org Sat Oct 15 04:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQhm3-0006i1-ST; Sat, 15 Oct 2005 04:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQhm1-0006hw-QB for sip@megatron.ietf.org; Sat, 15 Oct 2005 04:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29124 for ; Sat, 15 Oct 2005 04:52:07 -0400 (EDT) Received: from web31803.mail.mud.yahoo.com ([68.142.207.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQhwp-0006Sq-1n for sip@ietf.org; Sat, 15 Oct 2005 05:03:29 -0400 Received: (qmail 57833 invoked by uid 60001); 15 Oct 2005 08:51:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sxf5EJQs5TcWnOrlhzqVO+PURfDT0lgiNb6YXXV9fafosZyuFgg6uUhbEa8ZE+FvDNznX3w5rBOHXrBo6kuHJz8a56ifXAobGV3YTIuP/VBP372G/qgRveyD9yQmRZVLfR91aX0JkxrInKz+1ILgHqoV2NGLi5qJO9owt7yc0As= ; Message-ID: <20051015085154.57831.qmail@web31803.mail.mud.yahoo.com> Received: from [210.5.196.6] by web31803.mail.mud.yahoo.com via HTTP; Sat, 15 Oct 2005 01:51:54 PDT Date: Sat, 15 Oct 2005 01:51:54 -0700 (PDT) From: Behrad To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] Authentication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008837447==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2008837447== Content-Type: multipart/alternative; boundary="0-1585420271-1129366314=:57827" Content-Transfer-Encoding: 8bit --0-1585420271-1129366314=:57827 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Howdy all, I'm using Windows Messanger 5.1 SIP Client to register to my TCP Registrar Server but i'm unable to authenticate with DIGEST-MD5 to the MS Directory Server. Has anybody experienced such a case? I've read that Windows Messanger is not RFC3261 based. ( I think it's generated digest-response is not compatible with ldap server. ) I'm reading this SIP digest-response from messanger and send the RFC2831 MD5 response to the ldap server in my Registrar Server. Helps Appriciated, --Behrad Give joy, Not request it. --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1585420271-1129366314=:57827 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Howdy all,
I'm using Windows Messanger 5.1 SIP Client to register to my TCP Registrar Server but i'm unable to authenticate with DIGEST-MD5 to the MS Directory Server.
Has anybody experienced such a case?
I've read that Windows Messanger is not RFC3261 based. ( I think it's generated digest-response is not compatible with ldap server.  )
I'm reading this SIP digest-response from messanger and send the RFC2831 MD5 response to the ldap server in my Registrar Server.
 
Helps Appriciated,


--Behrad  
Give joy, Not request it.

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-1585420271-1129366314=:57827-- --===============2008837447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2008837447==-- From sip-bounces@ietf.org Mon Oct 17 03:02:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERP0o-00041n-PB; Mon, 17 Oct 2005 03:02:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERP0m-00041D-Pn for sip@megatron.ietf.org; Mon, 17 Oct 2005 03:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20846 for ; Mon, 17 Oct 2005 03:02:14 -0400 (EDT) Received: from web40424.mail.yahoo.com ([66.218.92.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERPC4-0002pS-Ae for sip@ietf.org; Mon, 17 Oct 2005 03:14:00 -0400 Received: (qmail 8430 invoked by uid 60001); 17 Oct 2005 07:02:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oTVw/2XhrxfEvjJigoQmMwQpzdgl/sUzfrbjfovogy5fPr/Csw4tJTLJJmYqo6O8qNla3qqODYOWdIIMbzbsbyJztb/+tQehMfW2CRgtTEwS7va2/dKwtlUPyiwQfO1JNiBPSmAy5ysFbbuGqc8UpZ6Z1x6jvgscb46ODUPW1GY= ; Message-ID: <20051017070211.8428.qmail@web40424.mail.yahoo.com> Received: from [202.54.11.72] by web40424.mail.yahoo.com via HTTP; Mon, 17 Oct 2005 00:02:11 PDT Date: Mon, 17 Oct 2005 00:02:11 -0700 (PDT) From: rajesh kumar To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] help: how to create RTP stream X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325301344==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1325301344== Content-Type: multipart/alternative; boundary="0-52617909-1129532531=:8218" Content-Transfer-Encoding: 8bit --0-52617909-1129532531=:8218 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am connecting to the server through clinet socket program written in C. I am sending INVITE request and I am getting 100 trying and 200 OK then I am sending ACK in return to 200 Ok. Now I am trying to listen at the port which the server had sent along with 200 OK SDP. but I am only getting UDP packets(when displayed non human readable characters are displayed) where I was expecting RTP packets. Can anyone tell me hopw to interpret these UDP packets. I wish to create RTP stream..can any one help in knowing How to create RTP stream? With Regards, Rajesh --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-52617909-1129532531=:8218 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I am connecting to the server through clinet socket program written in C.
I am sending INVITE request and I am getting 100 trying and 200 OK  then I am sending ACK in return to 200 Ok.
Now I am trying to listen at the port which the server had sent along with 200 OK SDP. but I am only getting UDP packets(when displayed non human readable characters are displayed) where I was expecting RTP packets. Can anyone tell me hopw to interpret these UDP packets.
 
I wish to create RTP stream..can any one help in knowing How to create RTP stream?
 
With Regards,
Rajesh
 
 

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. --0-52617909-1129532531=:8218-- --===============1325301344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1325301344==-- From sip-bounces@ietf.org Tue Oct 18 04:22:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmfi-0006UZ-0f; Tue, 18 Oct 2005 04:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmfd-0006TO-Sg for sip@megatron.ietf.org; Tue, 18 Oct 2005 04:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12255 for ; Tue, 18 Oct 2005 04:17:58 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmr7-00053i-Q0 for sip@ietf.org; Tue, 18 Oct 2005 04:29:59 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9I8Ti3m015552 for ; Tue, 18 Oct 2005 01:29:44 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j9I8PkOr027089 for ; Tue, 18 Oct 2005 03:25:47 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] MESSAGE method Date: Tue, 18 Oct 2005 16:17:38 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B1B6590@ZMY16EXM66.ds.mot.com> Thread-Topic: [Sip] MESSAGE method Thread-Index: AcXTvCxWJp4z8ELBRxKorVfJqdQj9gAABkQg From: "Avasarala Ranjit-A20990" To: "Suganya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi If u use MESSAGE method, then there is no need to establish session with INVITE. But if u use MSRP which is session based IM, then u need to establish session with INVITE prior to using MSRP.=20 Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Suganya Sent: Tuesday, October 18, 2005 1:43 PM To: sip@ietf.org Subject: [Sip] MESSAGE method Hi all, I am extending the SIP stack I have implemented in accordance with RFC 3261. I need to add support for Instant Messaging. I am following RFC 3428 Do I need to establish a session with INVITE for sending Instant Messages? RFC 3428 does not talk about it. draft-rosenberg-simple-im-transport-00.txt has an example of sending MESSAGE method. It first sends an INVITE with an sdp body containing m=3Dmessage 987654321(session id) IMTP/TCP text/plain. After receiving 200 OK, it sends MESSAGE method. The call-id in INVITE and MESSAGE method is not matching in this example. What I interpret is, in order to know that the target supports Instant Messaging, INVITE is sent. Otherwise INVITE is not necessary and MESSAGE can be sent directly. Am I correct? Regards, B.Suganya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 18 04:22:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmc6-0004yw-Gq; Tue, 18 Oct 2005 04:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmc4-0004yJ-NQ for sip@megatron.ietf.org; Tue, 18 Oct 2005 04:14:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12016 for ; Tue, 18 Oct 2005 04:14:16 -0400 (EDT) Received: from dsl-kk-static-217.183.145.203.touchtelindia.net ([203.145.183.217] helo=203.145.183.217) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmnW-0004ul-Gs for sip@ietf.org; Tue, 18 Oct 2005 04:26:17 -0400 Received: from [192.168.10.74] ([192.168.10.74]) by 203.145.183.217 (8.12.11/8.12.11) with ESMTP id j9I88IDv030361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2005 13:38:29 +0530 From: Suganya To: sip@ietf.org Content-Type: text/plain Message-Id: <1129623189.4399.17.camel@suganya> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 18 Oct 2005 13:43:10 +0530 Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-MailScanner-From: suganya@dgbmicro.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Sip] MESSAGE method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi all, I am extending the SIP stack I have implemented in accordance with RFC 3261. I need to add support for Instant Messaging. I am following RFC 3428 Do I need to establish a session with INVITE for sending Instant Messages? RFC 3428 does not talk about it. draft-rosenberg-simple-im-transport-00.txt has an example of sending MESSAGE method. It first sends an INVITE with an sdp body containing m=message 987654321(session id) IMTP/TCP text/plain. After receiving 200 OK, it sends MESSAGE method. The call-id in INVITE and MESSAGE method is not matching in this example. What I interpret is, in order to know that the target supports Instant Messaging, INVITE is sent. Otherwise INVITE is not necessary and MESSAGE can be sent directly. Am I correct? Regards, B.Suganya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 18 05:36:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERntt-0007yV-Uc; Tue, 18 Oct 2005 05:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERntq-0007xi-Uf for sip@megatron.ietf.org; Tue, 18 Oct 2005 05:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16970 for ; Tue, 18 Oct 2005 05:36:43 -0400 (EDT) Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERo5M-0007Lr-DA for sip@ietf.org; Tue, 18 Oct 2005 05:48:44 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp13.clb.oleane.net with ESMTP id j9I9afWF005851 for ; Tue, 18 Oct 2005 11:36:41 +0200 Message-Id: <200510180936.j9I9afWF005851@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Oct 2005 11:36:35 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXTx24X43/kD1jtRBKkvRgunOfLAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Sip] International SIP Conference /Exhibition 2006 - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0775859519==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0775859519== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C5D3D8.32497A00" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C5D3D8.32497A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference /exhibition will be held in Paris next February 21-24, 2006. The SIP 2006 program is mainly dedicated to Peer-to-Peer communications, IMS architectures, SIP mobility and deployment examples. Get all details on the following link: http://www.upperside.fr/sip2006/sip2006program.htm ------=_NextPart_000_003C_01C5D3D8.32497A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The International SIP conference /exhibition = will be held in Paris next February 21-24, 2006.

The SIP 2006 = program is mainly dedicated to Peer-to-Peer communications, = IMS = architectures, SIP = mobility and deployment examples.

 

Get all details on the following = link:

http://www.upperside.fr/sip2006/sip2006program.htm

 

 

------=_NextPart_000_003C_01C5D3D8.32497A00-- --===============0775859519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0775859519==-- From sip-bounces@ietf.org Tue Oct 18 06:27:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERogS-00005T-Er; Tue, 18 Oct 2005 06:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERogP-00005G-Ui for sip@megatron.ietf.org; Tue, 18 Oct 2005 06:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19785 for ; Tue, 18 Oct 2005 06:26:53 -0400 (EDT) Received: from liszt-04.ednet.co.uk ([212.20.226.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERoru-0000IM-LR for sip@ietf.org; Tue, 18 Oct 2005 06:38:56 -0400 Received: from liszt-04.ednet.co.uk (mail.ednet.co.uk [212.20.226.52]) by liszt-04.ednet.co.uk (Postfix) with ESMTP id 684CC13F05 for ; Tue, 18 Oct 2005 11:26:31 +0100 (BST) Received: from sullivan.ednet.co.uk (sullivan.lumison.net [212.20.231.233]) by liszt-04.ednet.co.uk (postfixfilterd/14247) id VPRMQTZBEN for ; Tue, 18 Oct 2005 11:26:30 +0100 (BST) Received: from Azopardi (azopardi.ednet.co.uk [212.20.231.227]) by sullivan.ednet.co.uk (Postfix) with ESMTP id 5213316402B for ; Tue, 18 Oct 2005 11:26:30 +0100 (BST) From: "Suha Cubukcuoglu" To: Date: Tue, 18 Oct 2005 11:26:39 +0100 Organization: edNET Message-ID: <000d01c5d3ce$6d22d450$e3e714d4@Azopardi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Comment: Virus scanned by edNET X-Spam-Score: 0.4 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Sip] Hot Desking in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suhac@nplusone.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, We are interested in implementing 'hot desking' feature in our SIP proxy server. I'd like to ask if there is any RFC or similar document which I can refer to get an idea of how we can go about doing this. Apologies if this is not the right list to post to. Could anyone possibly give us some pointers to the subject? Thanks for your help. Regards, Suha Cubukcuoglu nplusone t: +44 131 514 2000 d: +44 131 514 4037 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison, nplusone or lightershade ltd. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison, nplusone and lightershade ltd accepts no liability for any damage caused by any virus transmitted by this email. -- -- Virus scanned by Lumison. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 18 17:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzFa-0003Gj-GD; Tue, 18 Oct 2005 17:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERzFY-0003Fi-3U for sip@megatron.ietf.org; Tue, 18 Oct 2005 17:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00836 for ; Tue, 18 Oct 2005 17:43:51 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERzR7-0005WF-1Q for sip@ietf.org; Tue, 18 Oct 2005 17:56:00 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9ILmvvC005618 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 18 Oct 2005 16:48:58 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <86A271D6-FC9F-45A9-8D98-ECA98CDB83C7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP List From: Dean Willis Date: Tue, 18 Oct 2005 16:43:51 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda prep for IETF 64 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org OK kids, as usual I'm looking forward to pulling together the agenda for our upcoming meeting in Vancouver. As usual, I'd like to dedicate a significant chunk of time to the various chartered deliverables that, as usual, we're behind on. So, what else do you want to talk about? Please send me suggestions, which I'll post onto the SIP supplemental web site in the usual place. I'll send a link once I start posting them. Gonzalo's HTML format works pretty well, so please fill in the following for each request (replace the CAPSTRINGS): YOUR NAME YOUR TOPIC THENAMEOFTHEDRAFT TIMEYOUTHINKYOUNEEDINMINUTES like maybe: Dean Willis Answer mode extensions draft-willis-sip-answeralert-01 15 Thanks, all. If we're still doing this for 65 (instead of using IETF Tools), I think I'll put up a web form. -- 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 sip-bounces@ietf.org Tue Oct 18 23:39:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES4nk-0003GH-Fr; Tue, 18 Oct 2005 23:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES4ni-0003E7-17 for sip@megatron.ietf.org; Tue, 18 Oct 2005 23:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16993 for ; Tue, 18 Oct 2005 23:39:29 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES4zM-0004nC-3G for sip@ietf.org; Tue, 18 Oct 2005 23:51:41 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id BDD416C017 for ; Tue, 18 Oct 2005 23:39:27 -0400 (EDT) Subject: Re: [Sip] Hot Desking in SIP From: "Dale R. Worley" To: Sip In-Reply-To: <000d01c5d3ce$6d22d450$e3e714d4@Azopardi> References: <000d01c5d3ce$6d22d450$e3e714d4@Azopardi> Content-Type: text/plain Date: Tue, 18 Oct 2005 23:39:27 -0400 Message-Id: <1129693167.23856.6.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, 2005-10-18 at 11:26 +0100, Suha Cubukcuoglu wrote: > We are interested in implementing 'hot desking' feature in our SIP proxy > server. I'd like to ask if there is any RFC or similar document which I > can refer to get an idea of how we can go about doing this. Could you describe what "hot desking" is? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 19 00:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5nJ-0006U2-Ja; Wed, 19 Oct 2005 00:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5nF-0006TA-J1 for sip@megatron.ietf.org; Wed, 19 Oct 2005 00:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19866 for ; Wed, 19 Oct 2005 00:43:04 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES5yr-0006Px-V1 for sip@ietf.org; Wed, 19 Oct 2005 00:55:17 -0400 Received: from rcdn-vpn-cluster-2-23.cisco.com ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9J4m2lu006500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Oct 2005 23:48:07 -0500 Subject: Re: [Sip] Agenda prep for IETF 64 From: Dean Willis To: sip@ietf.org, "Vijay K. Gurbani" In-Reply-To: <43556F0D.1070308@lucent.com> References: <86A271D6-FC9F-45A9-8D98-ECA98CDB83C7@softarmor.com> <43556F0D.1070308@lucent.com> Content-Type: text/plain Date: Tue, 18 Oct 2005 23:40:35 -0500 Message-Id: <1129696835.22137.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Good question. SIP only. I believe Gonzalo will be trolling for SIPPING. -- dean On Tue, 2005-10-18 at 16:54 -0500, Vijay K. Gurbani wrote: > Dean Willis wrote: > > > > OK kids, as usual I'm looking forward to pulling together the agenda > > for our upcoming meeting in Vancouver. > [...] > > Dean: > > Is this for SIP or SIPPING or both? > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 19 09:01:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDZ1-00068Y-55; Wed, 19 Oct 2005 09:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESBJr-0002aZ-N4 for sip@megatron.ietf.org; Wed, 19 Oct 2005 06:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05929 for ; Wed, 19 Oct 2005 06:37:06 -0400 (EDT) Received: from web32607.mail.mud.yahoo.com ([68.142.207.234]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESBVU-0006u8-2j for sip@ietf.org; Wed, 19 Oct 2005 06:49:22 -0400 Received: (qmail 82684 invoked by uid 60001); 19 Oct 2005 10:36:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uuAD5a508RDCLcEnTvs9xlcoPoa7jhdPqOH1JWim97a4T2bH3fxBmEm4mS8Exl7insijnPB3ibYVme6Tfug9ll4RtDJpllpg+yFeQT52eBiYcs6cCm0KXqyP817UN4f3xFkYkWbsmCsXKdnkdfHW+3pWEH+PaSFsHq9vblIklzw= ; Message-ID: <20051019103659.82682.qmail@web32607.mail.mud.yahoo.com> Received: from [150.140.140.176] by web32607.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2005 03:36:59 PDT Date: Wed, 19 Oct 2005 03:36:59 -0700 (PDT) From: angelos ntankos To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 19 Oct 2005 09:01:01 -0400 Subject: [Sip] New features in SIP protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dear Mr,Miss I would like to tell where could I find the new features that are proposed for the SIP protocol.If you could send them to me it will be more usefull.Thank you a lot. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.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 sip-bounces@ietf.org Wed Oct 19 15:49:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJwX-0002R1-Ah; Wed, 19 Oct 2005 15:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJwW-0002PP-7x for sip@megatron.ietf.org; Wed, 19 Oct 2005 15:49:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09474 for ; Wed, 19 Oct 2005 15:49:34 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESK8G-0006jn-Rg for sip@ietf.org; Wed, 19 Oct 2005 16:01:56 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9JJsctD014142 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 14:54:39 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <8706854C-D14F-4D50-A68A-D7A110B871D7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP List From: Dean Willis Date: Wed, 19 Oct 2005 14:49:34 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Ready for IETF LC on draft-ietf-sip-refer-with-norefersub-03? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My notes show that with we should be ready to request IETF Last Call for draft-ietf-sip-refer-with-norefersub-03. Anybody have a problem with that? -- 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 sip-bounces@ietf.org Wed Oct 19 16:25:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKJr-0005T5-09; Wed, 19 Oct 2005 16:13:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESKJo-0005SW-Fy for sip@megatron.ietf.org; Wed, 19 Oct 2005 16:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16368 for ; Wed, 19 Oct 2005 16:13:38 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESKVb-000105-2O for sip@ietf.org; Wed, 19 Oct 2005 16:26:00 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9JKIj98014290 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 15:18:47 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP List From: Dean Willis Date: Wed, 19 Oct 2005 15:13:40 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Ready for IETF LC on draft-ietf-sip-connect-reuse-04.txt? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My notes show we should be ready for IETF last call of draft-ietf-sip- connect-reuse-04.txt. Anybody got a problem with that? -- 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 sip-bounces@ietf.org Wed Oct 19 17:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESL7y-0000jl-5E; Wed, 19 Oct 2005 17:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESL7w-0000hr-3K for sip@megatron.ietf.org; Wed, 19 Oct 2005 17:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03619 for ; Wed, 19 Oct 2005 17:05:27 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESLJj-0007bk-8b for sip@ietf.org; Wed, 19 Oct 2005 17:17:48 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9JL5NEk014530; Wed, 19 Oct 2005 16:05:24 -0500 (CDT) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9JL5N519587; Wed, 19 Oct 2005 16:05:23 -0500 (CDT) Message-ID: <4356B513.8080604@lucent.com> Date: Wed, 19 Oct 2005 16:05:23 -0500 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Ready for IETF LC on draft-ietf-sip-connect-reuse-04.txt? References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0547544113==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0547544113== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010600000107000401000201" This is a cryptographically signed message in MIME format. --------------ms010600000107000401000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean Willis wrote: > My notes show we should be ready for IETF last call of draft-ietf-sip- > connect-reuse-04.txt. I presume you mean WGLC...? > Anybody got a problem with that? No ... as it happened, I did read -04 yesterday and I do have some comments on it but they can be addressed during WGLC. I will post them early next week. Ciao. - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms010600000107000401000201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMTkyMTA1MjNaMCMGCSqGSIb3DQEJ BDEWBBR6WYzsA+DrGtORWB9jo5pXxMJhhTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGALxXt2d9tllRnIh0tLCoGLXux4Jb/cMmVGJpcjLjYYscikGcb3VrU C+s0EH8mcEjggKRZ4oCiaeNk4V5VFLKfQ6uiaqLcD266sflSd0kjxpfhaSorZKDSut9bYxqU fY6CUoehYRO6/chViArxCnJaQM5jn0FMRmWjeTmiVMxTnfAAAAAAAAA= --------------ms010600000107000401000201-- --===============0547544113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0547544113==-- From sip-bounces@ietf.org Wed Oct 19 18:30:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMRm-0004Cz-R5; Wed, 19 Oct 2005 18:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESMRk-0004A4-NR for sip@megatron.ietf.org; Wed, 19 Oct 2005 18:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09182 for ; Wed, 19 Oct 2005 18:29:59 -0400 (EDT) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESMdY-0001vA-MD for sip@ietf.org; Wed, 19 Oct 2005 18:42:21 -0400 Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id j9JMTiQb003011; Wed, 19 Oct 2005 18:29:48 -0400 (EDT) From: "Brett Tate" To: "'Dean Willis'" , "'SIP List'" Subject: RE: [Sip] Ready for IETF LC on draft-ietf-sip-connect-reuse-04.txt? Date: Wed, 19 Oct 2005 18:30:06 -0400 Message-ID: <001301c5d4fc$a82a51c0$2c28a8c0@brett1> 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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > My notes show we should be ready for IETF last > call of draft-ietf-sip-connect-reuse-04.txt. > > Anybody got a problem with that? I posted the following questions and comments; however I have not received a reply. Hopefully Rohan or someone can reply to my questions and concerns prior to initiating WGLC. :) http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 19 19:12:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESN6u-0000GP-C8; Wed, 19 Oct 2005 19:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESN6s-0000Fm-IN for sip@megatron.ietf.org; Wed, 19 Oct 2005 19:12:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17101 for ; Wed, 19 Oct 2005 19:12:28 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESNIe-000598-0E for sip@ietf.org; Wed, 19 Oct 2005 19:24:49 -0400 Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com [64.101.149.214] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9JNHVJ7015200 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 19 Oct 2005 18:17:32 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: SIP List From: Dean Willis Date: Wed, 19 Oct 2005 18:12:26 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Sip] IETF 64 materials and agenda requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've started accumulating IETF 64 materials like agenda requests at: http://www.softarmor.com/sipwg/meets/ietf64/index.html If you make an agenda request and it fails to show up, please bug me. -- 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 sip-bounces@ietf.org Wed Oct 19 23:16:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESQuT-0004kc-RK; Wed, 19 Oct 2005 23:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESQuP-0004jP-Na for sip@megatron.ietf.org; Wed, 19 Oct 2005 23:16:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06793 for ; Wed, 19 Oct 2005 23:15:52 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESR6F-0005sV-Nm for sip@ietf.org; Wed, 19 Oct 2005 23:28:17 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id EF7E76C017 for ; Wed, 19 Oct 2005 23:15:54 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: <434807E7.8020607@softarmor.com> References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> <434807E7.8020607@softarmor.com> Content-Type: text/plain Date: Wed, 19 Oct 2005 23:15:54 -0400 Message-Id: <1129778154.6380.31.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Crazy PaulK Dialog Usages andCrazier Pracical Idea X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Sat, 2005-10-08 at 12:54 -0500, Dean Willis wrote: > But I'm starting to speculate how this might look if the long-lived > dialog were established via a SUBSCRIBE (perhaps to a new event package) > and calls were set up by sending INVITE within that dialog, instead of > REFER. Hmmm. I can see the attraction, but I'm not sure you'd save much. By the offer-answer model and all the machinery, you could still have only one INVITE dialog-usage within the dialog at a time. Using INVITEs would allow you to periodically re-negotiate the media, but they would also *require* you to re-negotiate the media every time you made a call. (And you've noted that your lords and masters think that's a Bad Idea.) How about ox and ass in double harness? Continue to use REFER to redirect the ultimate endpoint of the call, but use re-INVITE (in the future) when the phone and/or its base station decides it needs to re- negotiate the media. That would actually make sense for a phone that transitions between 3G and WiFi usage, and even more so once WiMax becomes popular. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 20 01:54:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTNd-0001yt-68; Thu, 20 Oct 2005 01:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTNa-0001tS-9R for sip@megatron.ietf.org; Thu, 20 Oct 2005 01:54:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13174 for ; Thu, 20 Oct 2005 01:54:08 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESTZS-0001Oi-27 for sip@ietf.org; Thu, 20 Oct 2005 02:06:35 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9K5xDQ6016396 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Oct 2005 00:59:13 -0500 In-Reply-To: <4356B513.8080604@lucent.com> References: <4356B513.8080604@lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ready for IETF LC on draft-ietf-sip-connect-reuse-04.txt? Date: Thu, 20 Oct 2005 00:54:06 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: SIP List , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 19, 2005, at 4:05 PM, Vijay K. Gurbani wrote: > Dean Willis wrote: > >> My notes show we should be ready for IETF last call of draft-ietf- >> sip- connect-reuse-04.txt. >> > > I presume you mean WGLC...? > > Actually, I really meant IETF LC, because Rohan dropped a note on me saying he thought it was ready to send to Allison, and I had a vague recollection of WGLCing it like 3 revs back . . . Rohan, are you playing games with my head again, darn you! So it looks like we need to do WGLC instead. That's why I try to ask before I do something completely stupid -- safety in numbers. Thanks, Vijay! -- 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 sip-bounces@ietf.org Thu Oct 20 01:55:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTOM-0002Kn-Ss; Thu, 20 Oct 2005 01:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTOK-0002H3-7B for sip@megatron.ietf.org; Thu, 20 Oct 2005 01:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13210 for ; Thu, 20 Oct 2005 01:54:54 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESTaB-0001Pn-TS for sip@ietf.org; Thu, 20 Oct 2005 02:07:21 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9K5xDQ7016396 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Oct 2005 01:00:05 -0500 In-Reply-To: <1129778154.6380.31.camel@cdhcp139.pingtel.com> References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> <434807E7.8020607@softarmor.com> <1129778154.6380.31.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C91FE94-3A87-4753-9FEF-D22BEAD2795C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: Crazy PaulK Dialog Usages andCrazier Pracical Idea Date: Thu, 20 Oct 2005 00:55:00 -0500 To: "Dale R. Worley" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 19, 2005, at 10:15 PM, Dale R. Worley wrote: > On Sat, 2005-10-08 at 12:54 -0500, Dean Willis wrote: > >> But I'm starting to speculate how this might look if the long-lived >> dialog were established via a SUBSCRIBE (perhaps to a new event >> package) >> and calls were set up by sending INVITE within that dialog, >> instead of >> REFER. Hmmm. >> > > I can see the attraction, but I'm not sure you'd save much. By the > offer-answer model and all the machinery, you could still have only > one > INVITE dialog-usage within the dialog at a time. Using INVITEs would > allow you to periodically re-negotiate the media, but they would also > *require* you to re-negotiate the media every time you made a call. > (And you've noted that your lords and masters think that's a Bad > Idea.) > > How about ox and ass in double harness? Continue to use REFER to > redirect the ultimate endpoint of the call, but use re-INVITE (in the > future) when the phone and/or its base station decides it needs to re- > negotiate the media. That would actually make sense for a phone that > transitions between 3G and WiFi usage, and even more so once WiMax > becomes popular. Makes sense to me. More sense than my crazy idea, anyhow. Thanks, Dale. -- 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 sip-bounces@ietf.org Thu Oct 20 06:02:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXGF-0002U3-8Y; Thu, 20 Oct 2005 06:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXGC-0002Rc-SR for sip@megatron.ietf.org; Thu, 20 Oct 2005 06:02:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28666 for ; Thu, 20 Oct 2005 06:02:47 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESXS6-0001tQ-FL for sip@ietf.org; Thu, 20 Oct 2005 06:15:15 -0400 Received: by wproxy.gmail.com with SMTP id 55so235838wri for ; Thu, 20 Oct 2005 03:02:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CMsQJYjRjDtD5kIhYsIlOrFFqd0Q1u8v8ntI6E0Phsci3B/pSCb/G+8RoDEi+JCH+z6Oje9YSXhb7UlbZ1NdlZOqHry+KTHEttrAwrqyHilznBfEdyk2MJZjD+yzDh7oZ5Roc4qDcfVchb4A+9gmEbJSYwdheWT2qnAVc3Z3O8I= Received: by 10.54.137.20 with SMTP id k20mr984261wrd; Thu, 20 Oct 2005 03:02:51 -0700 (PDT) Received: by 10.54.104.1 with HTTP; Thu, 20 Oct 2005 03:02:51 -0700 (PDT) Message-ID: <52db68bc0510200302k5b8df56cp5995ee851cd9415e@mail.gmail.com> Date: Thu, 20 Oct 2005 15:32:51 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Sip] SUBSCRIBE / 202 Accepted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1753162351==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1753162351== Content-Type: multipart/alternative; boundary="----=_Part_805_32910239.1129802571071" ------=_Part_805_32910239.1129802571071 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I'm sending the SUBSCRIBE request its giving 202 and responding with NOTIFY with no body. I would like to know the SUBSCRIBE request should contain authorization header. (Note: Im sending the authorization in SUBSCRIBE) If not, What is the meaning of these in RFC 3856 (Chapter 4 OverView of Operation) If authorization could not be obtained at this time, the subscription is considered "pending", and a 202 response is returned. In both cases, the PA sends an immediate NOTIFY message containing the state of the presentity and of the subscription. If i want to get 200 OK what should i send with SUSCRIBE and subsequently, to get NOTIFY with BODY. thanks in advance Looking forward for supportive response Any feedback is appericated. -- Sudhir Kumar Reddy Software Engineer, QualPhone communications pvt. ltd. Bangalore +91-9845052651 ------=_Part_805_32910239.1129802571071 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi All,

I'm sending the SUBSCRIBE request its giving 202 and responding with NOT= IFY with no body.

I would like to know the SUBSCRIBE request should contain authorization = header.
(Note: Im sending the authorization in SUBSCRIBE)

If not,
What is the meaning of these in RFC 3856 (Chapter 4 OverView = of Operation)

If authorization could not be obtained at this time, the subscription = is considered "pending", and a 202
response is returned. In bo= th cases, the PA sends an immediate NOTIFY message containing the state of = the presentity and of the subscription.
 
 

If i want to get 200 OK what should i send with SUSCRIBE and subsequentl= y, to get NOTIFY with BODY.

thanks in advance

Looking forward for supportive response

Any feedback is appericated.



--
Sudhir Kuma= r Reddy
Software Engineer,
QualPhone communications pvt. ltd.
Ban= galore
+91-9845052651=20 ------=_Part_805_32910239.1129802571071-- --===============1753162351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1753162351==-- From sip-bounces@ietf.org Thu Oct 20 06:47:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXx5-0005Vv-HE; Thu, 20 Oct 2005 06:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXx3-0005Qo-JT; Thu, 20 Oct 2005 06:47:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01416; Thu, 20 Oct 2005 06:47:02 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESY8t-0003Iw-TX; Thu, 20 Oct 2005 06:59:31 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j9KAeP6K022448; Thu, 20 Oct 2005 16:10:46 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id j9KAkpC28353; Thu, 20 Oct 2005 16:16:56 +0530 (IST) In-Reply-To: <52db68bc0510200302k5b8df56cp5995ee851cd9415e@mail.gmail.com> Subject: Re: [Sip] SUBSCRIBE / 202 Accepted To: Sudhir Kumar Reddy X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Retesh Chadha Date: Thu, 20 Oct 2005 16:16:42 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 20/10/2005 04:15:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 3.1 (+++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Sudhir I have not read RFC 3856, but according to subscribe-notify RFC, i think the UA getting 202 can't do anything to get back 200... It shouldn't send another SUBSCRIBE. It should just wait for another NOTIFY with state as active/terminated. By 202, the UAS means that subscription is validated, but going further notifier may/may not reject the subscription. Regds Retesh Sudhir Kumar Reddy sip@ietf.org Sent by: cc sip-bounces@ietf. org Subject [Sip] SUBSCRIBE / 202 Accepted 10/20/2005 03:32 PM Hi All, I'm sending the SUBSCRIBE request its giving 202 and responding with NOTIFY with no body. I would like to know the SUBSCRIBE request should contain authorization header. (Note: Im sending the authorization in SUBSCRIBE) If not, What is the meaning of these in RFC 3856 (Chapter 4 OverView of Operation) If authorization could not be obtained at this time, the subscription is considered "pending", and a 202 response is returned. In both cases, the PA sends an immediate NOTIFY message containing the state of the presentity and of the subscription. If i want to get 200 OK what should i send with SUSCRIBE and subsequently, to get NOTIFY with BODY. thanks in advance Looking forward for supportive response Any feedback is appericated. -- Sudhir Kumar Reddy Software Engineer, QualPhone communications pvt. ltd. Bangalore +91-9845052651 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 20 06:51:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESY1J-0006Ee-IJ; Thu, 20 Oct 2005 06:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESY1H-0006EW-WC; Thu, 20 Oct 2005 06:51:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01626; Thu, 20 Oct 2005 06:51:26 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYDB-0003Ra-Cq; Thu, 20 Oct 2005 07:03:55 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j9KApLV9003269; Thu, 20 Oct 2005 03:51:21 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9KB3OFX011371; Thu, 20 Oct 2005 06:03:25 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SUBSCRIBE / 202 Accepted Date: Thu, 20 Oct 2005 18:51:17 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B1B6C1F@ZMY16EXM66.ds.mot.com> Thread-Topic: [Sip] SUBSCRIBE / 202 Accepted Thread-Index: AcXVY9m/5DnhhDwURXiPFFOcDkzSIAAABlzQ From: "Avasarala Ranjit-A20990" To: "Retesh Chadha" , "Sudhir Kumar Reddy" X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi getting 202 does not mean subscription is validated. It means subscription is accepted. But only upon receiving NOTIFY, it is confirmed that subscription is active.=20 U cannot get 200 OK for SUBSCRIBE. =20 Regards Ranjit -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Retesh Chadha Sent: Thursday, October 20, 2005 4:17 PM To: Sudhir Kumar Reddy Cc: sip@ietf.org; sip-bounces@ietf.org Subject: Re: [Sip] SUBSCRIBE / 202 Accepted Hi Sudhir I have not read RFC 3856, but according to subscribe-notify RFC, i think the UA getting 202 can't do anything to get back 200... It shouldn't send another SUBSCRIBE. It should just wait for another NOTIFY with state as active/terminated. By 202, the UAS means that subscription is validated, but going further notifier may/may not reject the subscription. Regds Retesh =20 Sudhir Kumar Reddy sip@ietf.org Sent by: cc=20 sip-bounces@ietf. org Subject=20 [Sip] SUBSCRIBE / 202 Accepted =20 10/20/2005 03:32 PM =20 =20 =20 Hi All, I'm sending the SUBSCRIBE request its giving 202 and responding with NOTIFY with no body. I would like to know the SUBSCRIBE request should contain authorization header. (Note: Im sending the authorization in SUBSCRIBE) If not, What is the meaning of these in RFC 3856 (Chapter 4 OverView of Operation) If authorization could not be obtained at this time, the subscription is considered "pending", and a 202 response is returned. In both cases, the PA sends an immediate NOTIFY message containing the state of the presentity and of the subscription. If i want to get 200 OK what should i send with SUSCRIBE and subsequently, to get NOTIFY with BODY. thanks in advance Looking forward for supportive response Any feedback is appericated. -- Sudhir Kumar Reddy Software Engineer, QualPhone communications pvt. ltd. Bangalore +91-9845052651 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 20 09:57:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESavK-0006k8-ML; Thu, 20 Oct 2005 09:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESavI-0006jy-Sq for sip@megatron.ietf.org; Thu, 20 Oct 2005 09:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13138 for ; Thu, 20 Oct 2005 09:57:26 -0400 (EDT) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESb7E-000157-Sr for sip@ietf.org; Thu, 20 Oct 2005 10:09:58 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 06DEE6C01C for ; Thu, 20 Oct 2005 09:57:34 -0400 (EDT) Subject: RE: [Sip] SUBSCRIBE / 202 Accepted From: "Dale R. Worley" To: Sip In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B1B6C1F@ZMY16EXM66.ds.mot.com> References: <750BBC72E178114F9DC4872EBFF29A5B1B6C1F@ZMY16EXM66.ds.mot.com> Content-Type: text/plain Date: Thu, 20 Oct 2005 09:57:33 -0400 Message-Id: <1129816653.18747.17.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-10-20 at 18:51 +0800, Avasarala Ranjit-A20990 wrote: > getting 202 does not mean subscription is validated. It means > subscription is accepted. But only upon receiving NOTIFY, it is > confirmed that subscription is active. > U cannot get 200 OK for SUBSCRIBE. You may get a 200 response (which means that the subscription has been authorized and you will eventually receive a NOTIFY with contents), but the subscriber cannot force the notifier to produce 200. See section 3.1.4.1 of RFC 3265: This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately. A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 20 11:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScUn-0004NS-NB; Thu, 20 Oct 2005 11:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScUm-0004N2-5A for sip@megatron.ietf.org; Thu, 20 Oct 2005 11:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24098 for ; Thu, 20 Oct 2005 11:38:11 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScgk-0006Au-30 for sip@ietf.org; Thu, 20 Oct 2005 11:50:42 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2005 08:38:11 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KFbcFC015825; Thu, 20 Oct 2005 11:38:08 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:38:05 -0400 Received: from [161.44.55.175] ([161.44.55.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:38:04 -0400 Message-ID: <4357B9DC.4060105@cisco.com> Date: Thu, 20 Oct 2005 11:38:04 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] updated GRUU spec References: <433A566B.8040308@cisco.com> <009701c5c41c$214a1a00$6402a8c0@BEMBUSTER> In-Reply-To: <009701c5c41c$214a1a00$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2005 15:38:04.0710 (UTC) FILETIME=[430EAC60:01C5D58C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org sorry for the delay. More inline. Jeroen van Bemmel wrote: > Jonathan, > > Not sure if this has been discussed already, but currently the draft > states that in order to determine if the remote target is a GRUU, the UA > must look for a 'Supported: gruu' header. Right. > > Wouldn't it make sense to make this property explicit in the URI itself, > e.g. by requiring that a GRUU MUST contain a 'gruu' parameter flag? > This would address the requirement that "A server in the domain can > determine that the URI is a GRUU" (section 6), in fact it would allow > any entity to determine that the URI is a GRUU. We have in fact discussed this a few times. As a general rule, its preferable to not include information in the URI itself which describes the properties of the resource to which the URI points. > > This would help a UA in all use cases (4.1 (REFER) for the Refer-To > URI, 4.2 for the conference URI, and 4.3 for the Contact information in > PIDF) to determine that the URI is in fact a GRUU. I think putting it as > a URI parameter may also have benefits in authentication scenario's (it > would be included in the digest calculation). In all of these cases, I don't think the recipient of the URI would do anything differently if it knew it was a gruu, as opposed to if it didnt. A GRUU is just a URI that has the property that URIs in Refer-To, contact and PIDF need to have in order to work right anyway. To date, we havent had a way to produce those URI reliably. Now we do. > > Putting it as a question: is REQ 8 broad enough to cover all use cases? > Wouldn't "to know that the URI represents a GRUU" also be required > outside of a dialog, e.g. when obtaining the URI from a PIDF document? Actually, if anything, I'd argue that it really ought not be necesary to know its a gruu to use it, and thus the requirement is more than we need. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Oct 20 11:44:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScaO-0005B4-VU; Thu, 20 Oct 2005 11:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScaM-0005Az-UX for sip@megatron.ietf.org; Thu, 20 Oct 2005 11:44:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24378 for ; Thu, 20 Oct 2005 11:43:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScmK-0006Kl-Un for sip@ietf.org; Thu, 20 Oct 2005 11:56:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2005 08:43:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KFgGFK016681; Thu, 20 Oct 2005 11:43:55 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:43:45 -0400 Received: from [161.44.55.175] ([161.44.55.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 11:43:44 -0400 Message-ID: <4357BB30.4070308@cisco.com> Date: Thu, 20 Oct 2005 11:43:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jin, Haipeng" Subject: Re: [Sip] updated GRUU spec References: <4A599554B0051B4897DFDD6DF1EAED79691F4A@NAEX07.na.qualcomm.com> In-Reply-To: <4A599554B0051B4897DFDD6DF1EAED79691F4A@NAEX07.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2005 15:43:44.0522 (UTC) FILETIME=[0D99DEA0:01C5D58D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Jin, Haipeng wrote: > Hi, > > I have a question regarding record-routing treatment in paragraph 2 on > page 24, quoted as follows. > > Similarly, if a request arrives from the client towards the home > proxy, the edge proxy would look at the identity of the sender of the > request. If the proxy knows that it is placing itself on the Path > for registrations from that AOR, and the request contains a Supported > header field with the value "gruu", the edge proxy would insert a > Record-Route into the request, and then remove it in the response. > Similarly, if the identity of the sender of the request is one for > which the client has not put itself on the Path, the edge proxy would > keep its Record-Route in the response. > > I guess you really mean: > Similarly, if a request arrives from the client towards the home > proxy, the edge proxy would look at the the identity of the sender of > the request. If the proxy knows that it is placing itself on the Path > for registrations from that AOR, and the request contains a Supported > header field with the value "gruu", the edge proxy would NOT insert a > Record-Route into the request but WOULD INSERT it in the response. > Similarly, if the identity of the sender of the request is one for which > the PROXY has not put itself on the Path, the edge proxy would INSERT > Record-Route IN THE REQUEST and keep it in the response. > > The changes are marked in capital letter. I think this is the proxy > behavior to make sure that the client will have a route set entry for > its edge proxy, but the remote client will not. I think its right as written. The idea is that, if the proxy had put itself into the Path, then it will already be in the signaling chain for mid-dialog requests towards the client. Thus, it shouldn't be in the record-route set that is used to reach the client. That is the record-route set used by the other side. Thus, the record-route needs to be removed from the response. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Oct 20 17:24:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShtR-0004Lm-Aq; Thu, 20 Oct 2005 17:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShtP-0004L1-Vz for sip@megatron.ietf.org; Thu, 20 Oct 2005 17:24:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12225 for ; Thu, 20 Oct 2005 17:23:54 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShQ1-0006ur-KG for sip@ietf.org; Thu, 20 Oct 2005 16:53:47 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j9KKf8Fg017934; Thu, 20 Oct 2005 20:41:08 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 16:40:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] impractical keying requirement in sip identity draft Date: Thu, 20 Oct 2005 16:40:29 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> Thread-Topic: [Sip] impractical keying requirement in sip identity draft Thread-Index: AcXNypcmILzkEtXOSQGxgu8V6hO1eAH597UQ From: "Peterson, Jon" To: "Juha Heinanen" , X-OriginalArrivalTime: 20 Oct 2005 20:40:30.0334 (UTC) FILETIME=[82B129E0:01C5D5B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Juha, As has been pointed out on this mailing list before, this constraint = already exists in the core SIP standard. Specifically, in RFC3263. (From = 4.1) For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange.=20 If you send a request to a URI of the form sips:user@sip.example.com, = then the certificate of the responding server (which is delivered via = TLS in the backwards domain) must be for valid the domain = 'sip.example.com'. This goes even for the sorts of hosting cases where = the DNS NAPTR/SRV records for sip.example.com point you to = siphosting.com, and siphosting.com is the server that actually replies. = In that instance, siphosting.com must hold a certificate valid for = 'sip.example.com'. For us to deviate from this principle for the sip-identity draft really = doesn't make sense, because the constraint already exists in RFC3263. = We've gone to some trouble to make sure that the authority for a given = domain from an identity perspective mirrors the authority over the = domain for inbound requests to the domain. Regarding your concern about how the hosting service would know what = hosted domain the user agent is requesting, since as you rightly point = out a TLS connection is formed before any SIP requests are sent, the = same problem exists of course for HTTP. Thus, the caretakers of TLS = wisely added a server name indication to the extended client hello, = which defined in RFC3546 Section 3.1. So, this problem is addressed at = the TLS layer. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Juha Heinanen > Sent: Monday, October 10, 2005 11:40 AM > To: sip@ietf.org > Subject: [Sip] impractical keying requirement in sip identity draft >=20 >=20 > in my opinion, it is no practical to require that a company would = supply > private keying material regarding its domain to whoever party that > happens to host its sip proxy service. that simply does not happen. >=20 > if sip srv record of, say, cisco.com, points to sip.provider.com, then > it must suffice that sip.provider.com uses its own keying material to > sign the identity of cisco.com users. >=20 > and even if sip.provider.com proxy would posses keying material of > domain cisco.com, i don't understand how it could know which server > certificate it should present to a sip ua when it establishes tls > connection with the proxy, because that happens before the sip ua has > sent any sip requests and because it is impractical to require that = each > domain would have its own ip address or port at the proxy. >=20 > it may be that i'm missing something, but if not, it makes no sense = for > ietf to write specifications that cannot have real = worldimplementations. >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 20 23:27:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnYc-0008Uf-7w; Thu, 20 Oct 2005 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESnYa-0008US-Qp for sip@megatron.ietf.org; Thu, 20 Oct 2005 23:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20344 for ; Thu, 20 Oct 2005 23:26:49 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESnke-0005xp-2i for sip@ietf.org; Thu, 20 Oct 2005 23:39:29 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2005 20:26:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9L3QmUw001725 for ; Thu, 20 Oct 2005 20:26:48 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 23:26:47 -0400 Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 23:26:47 -0400 Message-ID: <43585FF7.4030606@cisco.com> Date: Thu, 20 Oct 2005 23:26:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2005 03:26:47.0676 (UTC) FILETIME=[44B85BC0:01C5D5EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've just submitted a revision of the GRUU spec. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-06.txt There is no technical change, just editorial changes made by rfc-ed. GRUU is currently going through an rfc editor early copy editor experiment. In this experiment, the rfc-editor does its copy-editing of a draft PRIOR to the final WGLC. Once the changes are made, they are reviewed by the editor, and the revised draft is reposted for last call. That is what I am now doing. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Fri Oct 21 18:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5iw-0007de-Af; Fri, 21 Oct 2005 18:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5iA-0007N7-AV; Fri, 21 Oct 2005 18:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23247; Fri, 21 Oct 2005 18:49:53 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET5uL-0001Dd-Cr; Fri, 21 Oct 2005 19:02:42 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET5i6-0004vv-4X; Fri, 21 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@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 : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-06.txt Pages : 41 Date : 2005-10-21 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-gruu-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21162355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21162355.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Sat Oct 22 01:54:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCKc-0003v5-Rh; Sat, 22 Oct 2005 01:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETCKX-0003pm-4L for sip@megatron.ietf.org; Sat, 22 Oct 2005 01:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19653 for ; Sat, 22 Oct 2005 01:53:58 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETCWp-0000cA-5p for sip@ietf.org; Sat, 22 Oct 2005 02:06:51 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2005 22:53:59 -0700 X-IronPort-AV: i="3.97,240,1125903600"; d="scan'208"; a="222731466:sNHT27358572" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9M5ri8u022461; Fri, 21 Oct 2005 22:53:54 -0700 (PDT) Received: from 10.21.120.51 ([10.21.120.51]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 22 Oct 2005 05:54:01 +0000 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Fri, 21 Oct 2005 22:52:50 -0700 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: Response Identity Thread-Index: AcXWzNXiFFDL3kLAEdqhrAARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings Subject: [Sip] Response Identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is the follow-up on the collected feedback about SIP Response Identity= . Feng and I put together what seem to be some of the key questions that have been on the list about response identity then Feng put together the start o= f some analysis. I thought this looked like some interesting work that might spark some discussion on how we should solve this problem. We would appreciate any feedback folks care to give. Thanks, Cullen 1. Q1 and Q1.1 is about the response identity. Q1: Which approach is chosen to indicate the responder's identity? A: the responder's identity is embedded into the response message directly B: Instead of any change on response message, the responder must send one additional request back to the originator AND embed the responder's identity into the request message, RIGHT after the responder sends its response. Analysis:=20 For A, pros: * no additional request or response is needed * works when the responder is either proxy or UA * relatively simple, without changing any per-dialog state Cons: * need to answer Q1.1 (see below) * need new development after Q1.1 (and Q3) is answered For B, pros: * no need to face Q1.1 Cons: * additional trip delay for each SIP request * additional request and response are needed * when the responder is a proxy, this is unnecessary overhead for a proxy. * need the state modification for the originator and the responder. Q1.1: If A is chosen in Q1, how to embed the responder's identity into the response message? A: allow the responder's identity to be clearly specified in the response header AND the digest is inserted into the header by leveraging "Identity" defined before. B: allow the responder's identity to be clearly specified in the response header AND use AIB for carrying the responder identity and related digest. =20 Analysis: For A, pros: * simple, quite straightforward * easy for proxies to check the responders identity Cons: * anonymity is impossible * adds yet another header that has conflicting data about identity For B, pros: * anonymity is possible Cons: * need to insert AIB into the message * anonymity may need end-to-middle support for some proxies. Note: Anonymity is described here with respect to A and B. For A, any node involved in the SIP dialog can reveal the responder identity by looking into the response header. For B, the responder identity can be hidden into the encrypted AIB into the message body. Only the desired node(s) with the corresponding key(s) can reveal the responder identity. 2. Q2.1 and Q2.2 are about the response authentication. Q2.1: Will TLS be deployed in EVERY single hop for each SIP dialog? A: Yes B: No Analysis: B is apparently the answer. Q2.2: If B is chosen in Q2.1, can TLS be expected to be deployed in EVERY single hop for each SIP dialog soon? How soon? =20 A: Yes. Regardless of how soon, the community can wait and hope for the best. B: No. Response authentication needs to be enhanced inside SIP itself, which can be complementary to TLS when some hops don't have TLS. Analysis: For A, pros: * uniform approach through TLS * keep the burden from SIP Cons: * as long as one hop doesn't have TLS, the chain of trust is broken * big risk of expecting TLS be deployed in EVERY single hop soon (there are always exceptions). * the progress of moving to TLS in the past has been slow =20 For B, pros: * if it can be done faster, well it would be done faster Cons: * enhancement work for SIP * not uniform approach anymore (even though they are complementary to each other) * as long as one hop doesn't use the new per-hop response authentication, that hop should use TLS. If not, the chain of trust is broken again. * not clear it can be done faster than TLS at every hop =20 =20 3. Q3 is relatively trivial, but it needs the clarification. Q3: If its related policy doesn't forbid it to reveal its identity for that dialog, how should the responder decide when it should reveal its identity back to the originator? A: the responder should reveal its identity as the default behavior. B: the responder must reveal its identity IF AND ONLY IF the request message has the new option tag in =ECRequire:=EE inside its header? For example, =ECRequire: responder-id=EE. =20 Analysis: For A, pros: * responder identity will be available as the default cons: * may provide unnecessary responder identity in some scenarios =20 For B, pros: * reduce the unnecessary disclosure of responder identity cons: * need to add new option tag into =ECRequire=EE in request header =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 22 13:09:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMsU-0003eb-CD; Sat, 22 Oct 2005 13:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMsR-0003co-Sf for sip@megatron.ietf.org; Sat, 22 Oct 2005 13:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21322 for ; Sat, 22 Oct 2005 13:09:39 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETN4o-0006Is-RW for sip@ietf.org; Sat, 22 Oct 2005 13:22:40 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9MH9kP5023831; Sat, 22 Oct 2005 20:09:46 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Oct 2005 20:09:39 +0300 Received: from [10.162.253.85] ([10.162.253.85]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 22 Oct 2005 20:09:39 +0300 Message-ID: <435A7252.50502@nokia.com> Date: Sat, 22 Oct 2005 20:09:38 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ayan Subject: Re: [Sip] aka querry References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2005 17:09:39.0591 (UTC) FILETIME=[63167970:01C5D72B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Ayan, Inline. ext ayan wrote: > hi all, > > for registration using akav1algorithm, the nonce value of the > WWW-Authenticate header of 401 response for REGISTER contains the > base 64 encoded RAND, AUTN and Server Specific Data. > > how do we parse the RAND, AUTN and Server Specific Data from the > nonce value? You first need to base64 decode the content of the field, which will reveal those parameters in binary format. > according to rfc 3310 example in section 3.2 : > > __________________________________________________________________________________ > > > Example: > > nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK=" > > 0 1 2 3 0 1 2 3 > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | RAND | | > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | AUTN | | > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Server Data... +-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: Generating the nonce value. > > ________________________________________________________________________________________ > > > here a 32 bit value is given for RAND and AUTN. each base 64 digit > will be 6 bit long. so how do we fit it into 32 bits? The base64 decoded nonce field can be of any lenght upwards from 64 bits. That is because the RAND and AUTN params can be appended with additional server generated data, basically serving as the "real" nonce of the authentication challenge. Never mind the fact that the example nonces are, well, nonsense; this is a known bug in the spec. It was a copy-paste error on my part at the late stages of editing the draft, and I didn't bother to double-check the examples by actually decoding the fields again -- they're not legal base64 encoding. I regret that now, since it seems that many times examples are to implementors much more important than actual text, syntax definitions or figures of bit fields... :( Cheers, Aki > i'm a little confused on this one? kindly help me out. > > > Thnx n Rgds. /ayan > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 22 14:21:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNzw-0005CB-9S; Sat, 22 Oct 2005 14:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNzs-0005AK-7U for sip@megatron.ietf.org; Sat, 22 Oct 2005 14:21:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24391 for ; Sat, 22 Oct 2005 14:21:23 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETOCG-0000DS-9S for sip@ietf.org; Sat, 22 Oct 2005 14:34:24 -0400 Received: by wproxy.gmail.com with SMTP id i23so384812wra for ; Sat, 22 Oct 2005 11:21:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=H/r8P0X5FthO2mZnFMd0jAMuDqcKRKOPzaaczE2pWdw1TvIzpT/UPtcd2tfj/JE8+3vUxbp6XUjaDVL5WpIf8Y7af0er5LiCNin70MEuma2qi9PrCloMJUlNZRBlpR6pfDtY6Lg6xgZRMcBR5LDtIl8aSgnSgLmRF1vwFGDtTb4= Received: by 10.54.153.1 with SMTP id a1mr2205795wre; Sat, 22 Oct 2005 11:21:30 -0700 (PDT) Received: by 10.54.92.3 with HTTP; Sat, 22 Oct 2005 11:21:30 -0700 (PDT) Message-ID: <953beacc0510221121p39a401f0w37d6f52a45719eed@mail.gmail.com> Date: Sat, 22 Oct 2005 11:21:30 -0700 From: Rohan Mahy To: "Peterson, Jon" Subject: Re: [Sip] impractical keying requirement in sip identity draft In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> MIME-Version: 1.0 References: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1932404721==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1932404721== Content-Type: multipart/alternative; boundary="----=_Part_19087_26973753.1130005290199" ------=_Part_19087_26973753.1130005290199 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, To try to further answer Juha's questions, the way that provider.netdecides what credentials to send is exactly the same way this works in HTTP. Provider.net today determines what domain it is serving based on the port number (set via SRV). Provider.netis hosting several TLS domains and for good providers, each hosted domain can have separate certs and private keys. Example-A.com does not have acces= s to Example-B.com's private key and vice versa. Another standardized but not yet deployed way to solve this problem is to use the TLS extended client hello extension to provide the name of the server. When implemented, this allows the server to provide the certificate of the expected domain on a single port. This is documented in RFC 3546. thanks, -rohan On 10/20/05, Peterson, Jon wrote: > > > Juha, > > As has been pointed out on this mailing list before, this constraint > already exists in the core SIP standard. Specifically, in RFC3263. (From > 4.1) > > For NAPTR records with SIPS protocol fields, (if the server is using > a site certificate), the domain name in the query and the domain name > in the replacement field MUST both be valid based on the site > certificate handed out by the server in the TLS exchange. > > If you send a request to a URI of the form sips:user@sip.example.com, the= n > the certificate of the responding server (which is delivered via TLS in t= he > backwards domain) must be for valid the domain 'sip.example.com'. > This goes even for the sorts of hosting cases where the DNS NAPTR/SRV > records for sip.example.com point you to > siphosting.com , and siphosting.comis the server that actually replies. In that instance, > siphosting.com must hold a certificate valid for = ' > sip.example.com '. > > For us to deviate from this principle for the sip-identity draft really > doesn't make sense, because the constraint already exists in RFC3263. We'= ve > gone to some trouble to make sure that the authority for a given domain f= rom > an identity perspective mirrors the authority over the domain for inbound > requests to the domain. > > Regarding your concern about how the hosting service would know what > hosted domain the user agent is requesting, since as you rightly point ou= t a > TLS connection is formed before any SIP requests are sent, the same probl= em > exists of course for HTTP. Thus, the caretakers of TLS wisely added a ser= ver > name indication to the extended client hello, which defined in RFC3546 > Section 3.1. So, this problem is addressed at the TLS layer. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > Juha Heinanen > > Sent: Monday, October 10, 2005 11:40 AM > > To: sip@ietf.org > > Subject: [Sip] impractical keying requirement in sip identity draft > > > > > > in my opinion, it is no practical to require that a company would suppl= y > > private keying material regarding its domain to whoever party that > > happens to host its sip proxy service. that simply does not happen. > > > > if sip srv record of, say, cisco.com , points to > sip.provider.com , then > > it must suffice that sip.provider.com uses it= s > own keying material to > > sign the identity of cisco.com users. > > > > and even if sip.provider.com proxy would > posses keying material of > > domain cisco.com , i don't understand how it could > know which server > > certificate it should present to a sip ua when it establishes tls > > connection with the proxy, because that happens before the sip ua has > > sent any sip requests and because it is impractical to require that eac= h > > domain would have its own ip address or port at the proxy. > > > > it may be that i'm missing something, but if not, it makes no sense for > > ietf to write specifications that cannot have real worldimplementations= . > > > > -- 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 > ------=_Part_19087_26973753.1130005290199 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,

To try to further answer Juha's questions, the way that provider.net decides what credentials to send is exactly the same way this works in HTTP.  Provider.net today determin= es what domain it is serving based on the port number (set via SRV).  Provider.net is hosting several TLS domains and for good providers, each hosted domain can have separate certs and private keys. Example-A.com does not have access to Example-B.com's private key and vice versa.

Another standardized but not yet deployed way to solve this problem is to use the TLS extended client hello extension to provide the name of the server.  When implemented, this allows the server to provide the certificate of the expected domain on a single port.  This is documented in RFC 3546.

thanks,
-rohan

On 10/20/05, Peterson, Jon <jon.peterson@neustar.biz> wrote:

Juha,

As has been pointed out on this mailing list before, this constraint already exists in the core SIP standard. Specifically, in RFC3263. (From 4.1)

   For NAPTR records with SIPS protocol fields,= (if the server is using
   a site certificate), the domain na= me in the query and the domain name
   in the replacement fiel= d MUST both be valid based on the site
   certificate handed out by the server in the TLS exchange.<= br>
If you send a request to a URI of the form sips:user@sip.example.com, then the certificate of the responding server (which is delivered via TLS in the backwards domain) must be for valid the domain 'sip.example.com'. This goes even for the sorts of hosting cases where the DNS NAPTR/SRV records for sip.example.com point yo= u to siphosting.com, and siphosting.com is the server that act= ually replies. In that instance, siphosting.com must hold a certificat= e valid for 'sip.example.com'.
For us to deviate from this principle for the sip-identity draft really doesn't make sense, because the constraint already exists in RFC3263. We've gone to some trouble to make sure that the authority for a given domain from an identity perspective mirrors the authority over the domain for inbound requests to the domain.

Regarding your concern about how the hosting service would know what hosted domain the user agent is requesting, since as you rightly point out a TLS connection is formed before any SIP requests are sent, the same problem exists of course for HTTP. Thus, the caretakers of TLS wisely added a server name indication to the extended client hello, which defined in RFC3546 Section 3.1. So, this problem is addressed at the TLS layer.
Jon Peterson
NeuStar, Inc.

> -----Original Message-----
&g= t; From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]O= n Behalf Of
> Juha Heinanen
> Sent: Monday, October 10, 2005 11= :40 AM
> To: sip@ietf.org
>= Subject: [Sip] impractical keying requirement in sip identity draft
>
>
> in my opinion, it is no practical to require that = a company would supply
> private keying material regarding its domain= to whoever party that
> happens to host its sip proxy service. =  that simply does not happen.
>
> if sip srv record of, say, ci= sco.com, points to sip.provider.com= , then
> it must suffice that sip.provider.com uses its own keying material to
> sign the identity of cisco.com users.
>
> and even if sip.provider.com proxy would posses key= ing material of
> domain cisco.com, i don't underst= and how it could know which server
> certificate it should present to= a sip ua when it establishes tls
> connection with the proxy, becaus= e that happens before the sip ua has
> sent any sip requests and because it is impractical to require tha= t each
> domain would have its own ip address or port at the proxy.>
> it may be that i'm missing something, but if not, it makes n= o sense for
> ietf to write specifications that cannot have real worldimplementa= tions.
>
> -- 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 questio= ns on current sip
> Use sipping@ietf.org for n= ew developments on the application of sip
>

__________________= _____________________________
Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW deve= lopment of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on curr= ent sip
Use sipping@ietf.org for new de= velopments on the application of sip

------=_Part_19087_26973753.1130005290199-- --===============1932404721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1932404721==-- From sip-bounces@ietf.org Sun Oct 23 00:55:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETXsu-0005EH-Kz; Sun, 23 Oct 2005 00:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETXso-0005BB-QH for sip@megatron.ietf.org; Sun, 23 Oct 2005 00:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13941 for ; Sun, 23 Oct 2005 00:54:46 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETY5I-0008Hj-20 for sip@ietf.org; Sun, 23 Oct 2005 01:07:53 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 21:54:48 -0700 X-IronPort-AV: i="3.97,241,1125903600"; d="scan'208"; a="355564373:sNHT24983196" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9N4sjub022167; Sat, 22 Oct 2005 21:54:46 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 00:54:45 -0400 Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 00:54:44 -0400 Message-ID: <435B1794.2090202@cisco.com> Date: Sun, 23 Oct 2005 00:54:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fridy Sharon-Fridman References: <8E5AB0A04458904BB9B079055261033CDD5F8D@mail.followap.com> In-Reply-To: <8E5AB0A04458904BB9B079055261033CDD5F8D@mail.followap.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 23 Oct 2005 04:54:44.0848 (UTC) FILETIME=[E2FC6700:01C5D78D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA13941 Cc: sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-target-dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the comments. I've incorporated them into the next revision. Details inline. Fridy Sharon-Fridman wrote: > Hi, >=20 > =20 >=20 > Few questions on this: >=20 > 1) Why NOTIFY is mentioned in paragraph 1 as a dialog creation=20 > transaction? (perhaps alongside SUBSCRIBE but it may be confusing).=20 > Indeed NOTIFY is not marked in section 7. Removed notify. >=20 > 2) Relating to below: >=20 > Instead, a better approach is for user agent A to send the >=20 > REFER request to user agent C outside of the dialog using its >=20 > Globally Routable User Agent URI (GRUU) [9]. In that case, a means >=20 > is needed for user agent B to authorize the REFER >=20 > As A transfers B to C, A send OOB REFER to C as said above in the first= =20 > sentence. The 2^nd one may be confusing as B is not part of that REFER.= =20 > B needs to authorize C. Good catch. This is a bug; it should say user aget B not C. >=20 > 3) Chapter 2 seems to be overview ONLY of the app interaction use= =20 > case outline in 1 (and not others, e.g. not a general overview=85). Fixed. >=20 > 4) 3.2 indicates a use case of SUBSCRIBE to conference EP. This=20 > can be highlighted in 1, or just generalized in 1 use case talking abou= t=20 > SUBSCRIBE, referring to both dialog and conference EP or being general=20 > without mentioning either. All of the use cases don't need to appear in section 1. I liked the fact=20 that there was a new one in this scetion - otherwise, it seems like the=20 use cases are finite and all listed up front. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Sun Oct 23 01:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETY3M-00012F-D9; Sun, 23 Oct 2005 01:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETY3K-000120-3L for sip@megatron.ietf.org; Sun, 23 Oct 2005 01:05:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14350 for ; Sun, 23 Oct 2005 01:05:37 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETYFo-00008A-G1 for sip@ietf.org; Sun, 23 Oct 2005 01:18:44 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2005 22:05:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,241,1125903600"; d="scan'208"; a="13705123:sNHT22796992" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9N55c23015454; Sun, 23 Oct 2005 01:05:39 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 01:05:38 -0400 Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 01:05:38 -0400 Message-ID: <435B1A21.4020601@cisco.com> Date: Sun, 23 Oct 2005 01:05:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Sip] WGLC for draft-ietf-sip-target-dialog-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2005 05:05:38.0332 (UTC) FILETIME=[687E25C0:01C5D78F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the comments, Jean-Francois. I've incorporated them into the new revision. Details below: Jean-Francois Mule wrote: > Jonathan, > > I have not followed this work closely so sorry if my comments are off-track, but here are 2 comments. > > --- 1. > The first comment is to consider aligning the aBNF grammar more strictly with the UAC/UAS behaviors on the remote-param and local-param. > > Sections 3 & 4 state that target-dialog should be authorized if both the remote-param and local-param are present (pending various conditions met). On the UAS, you even indicate the request for authorization MUST be ignored if both param are not provided (strong MUST). > Yet the grammar is much looser: > Target-Dialog = "Target-Dialog" HCOLON call-id *(SEMI > td-param) > td-param = remote-param / local-param / generic-param > remote-param = "remote-tag" EQUAL token > local-param = "local-tag" EQUAL token > > Is there a reason for not making the grammar stricter to mandate both remote and local params? Or turning the question around, what would be examples when an authorization would be granted without both? > I understand the potential issues of msgs being rejected due to bad grammar vs. msgs being accepted while only the header could be ignored but it seems that an implementation using this new header should be strict when sending the header. As a general rule, we have not tried to use the BNF to enforce these kinds of rules. For example, look at Via header field - branch ID is reqired but not if you just read the BNF. The reason is that we have always allowed the header parameters to appear in in order. It is difficult to write a BNF that indicates that a header field has to appear at least once, but the ordering amongst other parameters (new or existing) is not specified. > > --- 2. IANA section and Header Field Parameters Sub-Registry > Per RFC3968, would it make sense to register the Target-Dialog header field parameters? Done. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Sun Oct 23 01:28:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETYPF-0004qT-3q; Sun, 23 Oct 2005 01:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETYPC-0004qG-ON for sip@megatron.ietf.org; Sun, 23 Oct 2005 01:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15244 for ; Sun, 23 Oct 2005 01:28:14 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETYbg-0000jI-At for sip@ietf.org; Sun, 23 Oct 2005 01:41:21 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 22:28:17 -0700 X-IronPort-AV: i="3.97,241,1125903600"; d="scan'208"; a="355567471:sNHT23697752" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9N5SE94012010 for ; Sat, 22 Oct 2005 22:28:14 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 01:28:13 -0400 Received: from [192.168.1.100] ([10.86.242.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 01:28:13 -0400 Message-ID: <435B1F6D.1020800@cisco.com> Date: Sun, 23 Oct 2005 01:28:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2005 05:28:13.0723 (UTC) FILETIME=[905E66B0:01C5D792] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Sip] update to target-dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just submitted a revision to the target-dialog spec. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-02.txt The changes are: * More text on the importance of cryptographic identifiers for dialog IDs in order to prevent attacks * removed NOTIFY as an example dialog-forming request; while it is one, its confusing to be listed here since target-dialog isn't used in NOTIFY * fixed bug in example where 'user agent C' needed to be 'user agent B' * generalized the overview; it was written explicitly with REFER, but target-dialog is more general purpose * added IANA registry of header field parameters There are no open issues. I believe this document is ready to go. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Sun Oct 23 15:46:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETlnZ-0007jz-7A; Sun, 23 Oct 2005 15:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETlnX-0007ju-Rc for sip@megatron.ietf.org; Sun, 23 Oct 2005 15:46:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22078 for ; Sun, 23 Oct 2005 15:46:14 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETm07-0004Ze-DA for sip@ietf.org; Sun, 23 Oct 2005 15:59:29 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IOT00G01W4K25@siemenscomms.co.uk> for sip@ietf.org; Sun, 23 Oct 2005 20:43:33 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IOT0077XW4KEI@siemenscomms.co.uk>; Sun, 23 Oct 2005 20:43:32 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sun, 23 Oct 2005 20:46:03 +0100 Content-return: allowed Date: Sun, 23 Oct 2005 20:46:02 +0100 From: "Elwell, John" Subject: RE: [Sip] Response Identity To: Cullen Jennings , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266706C54688@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen, In-line John =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 22 October 2005 06:53 > To: sip@ietf.org > Cc: Cullen Jennings > Subject: [Sip] Response Identity >=20 >=20 > This is the follow-up on the collected feedback about SIP=20 > Response Identity. >=20 > Feng and I put together what seem to be some of the key=20 > questions that have > been on the list about response identity then Feng put=20 > together the start of > some analysis. I thought this looked like some interesting=20 > work that might > spark some discussion on how we should solve this problem. We would > appreciate any feedback folks care to give. >=20 > Thanks, Cullen >=20 >=20 > 1. Q1 and Q1.1 is about the response identity. >=20 > Q1: Which approach is chosen to indicate the responder's identit= y? >=20 > A: the responder's identity is embedded into the response > message directly >=20 > B: Instead of any change on response message, the=20 > responder must > send one additional request back to the originator=20 > AND embed > the responder's identity into the request message,=20 > RIGHT after > the responder sends its response. >=20 > Analysis:=20 >=20 > For A, pros: > * no additional request or response is needed > * works when the responder is either proxy or UA > * relatively simple, without changing any per-dialog st= ate >=20 > Cons: > * need to answer Q1.1 (see below) > * need new development after Q1.1 (and Q3) is answered >=20 > For B, pros: > * no need to face Q1.1 [JRE] There is an additional advantage that the same mechanism can be= used to indicate a change of identity during a dialog, as might happen if = a gateway becomes aware of changes in the other network. > Cons: > * additional trip delay for each SIP request [JRE] There needn't been an additional round trip delay for the origi= nal SIP request. The original SIP request can still receive a final (2xx) res= ponse and is then complete - response identity will occur a short time late= r (or earlier, if it is sent after a 1xx response but before the 2xx respon= se). > * additional request and response are needed > * when the responder is a proxy, this is=20 > unnecessary overhead > for a proxy. [JRE] It is questionable whether response identity is needed for a re= quest receiving a non-2xx final response, and hence whether response identi= ty needs to be generated by a proxy. In draft-elwell-sip-connected-ident= ity I suggest that response identity (or connected identity) is important o= nly when a dialog is established. Thus it would never come from a proxy. > * need the state modification for the originator and th= e > responder. >=20 >=20 > Q1.1: If A is chosen in Q1, how to embed the responder's identit= y > into the response message? >=20 > A: allow the responder's identity to be clearly specified in = the > response header AND the digest is inserted into=20 > the header by > leveraging "Identity" defined before. [JRE] The question is how to include the responder's identity in the response header in a way that will be signed by the Identity header. = It may need a different header to sign it. >=20 > B: allow the responder's identity to be clearly specified in = the > response header AND use AIB for carrying the responder > identity and related digest. > =20 >=20 > Analysis: > For A, pros: > * simple, quite straightforward > * easy for proxies to check the responders identity > Cons: > * anonymity is impossible [JRE] An equivalent level of anonymity to that provided by the Identi= ty header should be possible. > * adds yet another header that has conflicting data > about identity [JRE] Why would it be conflicting? The To header field is known not t= o reflect reality in many cases. >=20 > For B, pros: > * anonymity is possible > Cons: > * need to insert AIB into the message > * anonymity may need end-to-middle support for=20 > some proxies. >=20 > Note: Anonymity is described here with respect to A and B. > For A, any node involved in the SIP dialog can revea= l > the responder identity by looking into the response > header. >=20 > For B, the responder identity can be hidden into the > encrypted AIB into the message body. Only the desire= d > node(s) with the corresponding key(s) can reveal the > responder identity. >=20 > 2. Q2.1 and Q2.2 are about the response authentication. >=20 > Q2.1: Will TLS be deployed in EVERY single hop for each SIP > dialog? >=20 > A: Yes > B: No >=20 > Analysis: >=20 > B is apparently the answer. >=20 >=20 >=20 > Q2.2: If B is chosen in Q2.1, can TLS be expected to be=20 > deployed in > EVERY single hop for each SIP dialog soon? How soon? >=20 > =20 > A: Yes. Regardless of how soon, the community can wait and h= ope > for the best. >=20 > B: No. Response authentication needs to be enhanced inside S= IP > itself, which can be complementary to TLS when some hop= s > don't have TLS. >=20 > Analysis: > For A, pros: > * uniform approach through TLS > * keep the burden from SIP >=20 > Cons: > * as long as one hop doesn't have TLS, the chain of tr= ust > is broken > * big risk of expecting TLS be deployed in EVERY=20 > single hop > soon (there are always exceptions). > * the progress of moving to TLS in the past has been s= low >=20 > =20 > For B, pros: > * if it can be done faster, well it would be done fas= ter >=20 > Cons: >=20 > * enhancement work for SIP > * not uniform approach anymore (even though they are > complementary to each other) > * as long as one hop doesn't use the new=20 > per-hop response > authentication, that hop should use TLS. If not, > the chain of trust is broken again. > * not clear it can be done faster than TLS at every h= op > =20 > =20 > 3. Q3 is relatively trivial, but it needs the clarification. >=20 > Q3: If its related policy doesn't forbid it to reveal its identi= ty > for that dialog, how should the responder decide when it sho= uld > reveal its identity back to the originator? >=20 >=20 > A: the responder should reveal its identity as the default > behavior. >=20 > B: the responder must reveal its identity IF AND ONLY IF > the request message has the new option tag in =ECRequire= :=EE > inside its header? For example, =ECRequire: responder-id= =EE. > =20 > Analysis: > For A, pros: > * responder identity will be available as the default > cons: > * may provide unnecessary responder identity in some > scenarios > =20 > For B, pros: > * reduce the unnecessary disclosure of responder identi= ty > cons: > * need to add new option tag into =ECRequire=EE in=20 > request header >=20 > =20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Oct 23 17:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETnkT-0003LJ-Ai; Sun, 23 Oct 2005 17:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETnkR-0003LE-HI for sip@megatron.ietf.org; Sun, 23 Oct 2005 17:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26595 for ; Sun, 23 Oct 2005 17:51:11 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETnx3-0008Dk-IA for sip@ietf.org; Sun, 23 Oct 2005 18:04:27 -0400 Received: (qmail 25001 invoked by uid 0); 23 Oct 2005 21:50:52 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 Oct 2005 21:50:52 -0000 Message-ID: <001801c5d81b$d65294a0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <435B1F6D.1020800@cisco.com> Subject: Re: [Sip] update to target-dialog Date: Sun, 23 Oct 2005 23:50:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, It seems to me that In-Reply-To (RFC3261) is very similar to the new Target-Dialog header proposed in the draft. Perhaps this would merit some discussion (on this list and/or in the draft), in particular: - syntax is very similar, except that In-Reply-To does not allow parameters - For In-Reply-To, RFC3261 explicitly states that "This field is not a substitute for request authentication" - Is Target-Dialog to be used also for the use case for In-Reply-To mentioned in RFC3261 (return calls)? In that case there is no existing dialog, but there are similarities Regards, Jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "IETF SIP List" Sent: Sunday, October 23, 2005 7:28 AM Subject: [Sip] update to target-dialog >I just submitted a revision to the target-dialog spec. Until it appears, >you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-02.txt > > The changes are: > > * More text on the importance of cryptographic identifiers for dialog IDs > in order to prevent attacks > > * removed NOTIFY as an example dialog-forming request; while it is > one, its confusing to be listed here since target-dialog isn't used in > NOTIFY > > * fixed bug in example where 'user agent C' needed to be 'user agent > B' > > * generalized the overview; it was written explicitly with REFER, but > target-dialog is more general purpose > > * added IANA registry of header field parameters > > > There are no open issues. I believe this document is ready to go. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 sip-bounces@ietf.org Sun Oct 23 21:37:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETrGr-0002Yf-Mb; Sun, 23 Oct 2005 21:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETrGp-0002YT-AX for sip@megatron.ietf.org; Sun, 23 Oct 2005 21:37:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05567 for ; Sun, 23 Oct 2005 21:36:49 -0400 (EDT) Received: from [210.4.139.136] (helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETrTP-00067b-7h for sip@ietf.org; Sun, 23 Oct 2005 21:50:08 -0400 Received: from rautu.tutpro.com (smmsp@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9O1ZcgF004571; Mon, 24 Oct 2005 04:36:06 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j9O1J1A6004290; Mon, 24 Oct 2005 04:19:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17244.13957.272462.885349@rautu.tutpro.com> Date: Mon, 24 Oct 2005 04:19:01 +0300 From: Juha Heinanen To: Rohan Mahy Subject: Re: [Sip] impractical keying requirement in sip identity draft In-Reply-To: <953beacc0510221121p39a401f0w37d6f52a45719eed@mail.gmail.com> References: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> <953beacc0510221121p39a401f0w37d6f52a45719eed@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Peterson, Jon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Rohan Mahy writes: > Provider.net today determines what domain it is > serving based on the port number (set via SRV). are you saying that each time a provider adds a new domain to its proxy, the proxy would need to start listening on a new port? in all proxies that i know, this would mean restarting the proxy, which is very bad. looks like the extended client hello that jon pointed to, might be a better solution. but as far as i know, it is not yet supported by openssl library, for example. > Provider.netis hosting several TLS domains and > for good providers, each hosted domain > can have separate certs and private keys. Example-A.com does not have access > to Example-B.com's private key and vice versa. but provider needs access to both, which is my original concern. > Another standardized but not yet deployed way to solve this problem is to > use the TLS extended client hello extension to provide the name of the > server. When implemented, this allows the server to provide the certificate > of the expected domain on a single port. This is documented in RFC > 3546. yes. all this hassle seems to result from not being able to trust dns. why not simply sign the dns records pointing to the proxy after which the proxy would only need to sign itself? -- 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 sip-bounces@ietf.org Mon Oct 24 10:39:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3UK-000628-Ck; Mon, 24 Oct 2005 10:39:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3UI-000623-It for sip@megatron.ietf.org; Mon, 24 Oct 2005 10:39:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13047 for ; Mon, 24 Oct 2005 10:39:32 -0400 (EDT) Received: from [207.47.106.194] (helo=ixca-ex1.ixiacom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU3h4-0005uE-9V for sip@ietf.org; Mon, 24 Oct 2005 10:52:58 -0400 Received: from [10.205.17.132] (ixprasenjit [10.205.17.132]) by ixca-ex1.ixiacom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TPDT3Q8W; Mon, 24 Oct 2005 07:39:28 -0700 Message-ID: <435D1504.30406@gmail.com> Date: Mon, 24 Oct 2005 22:38:20 +0530 X-Sybari-Trust: d5873c76 453feeff 95896e57 0000010c From: Rohan Sen User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [Sip] Few SIP Issues from rfc3261 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1119559532==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1119559532== Content-Type: multipart/alternative; boundary="------------030202030409040606030502" This is a multi-part message in MIME format. --------------030202030409040606030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue # 1 ------------------------------------------------------------------------------------------------ In rfc3261, Section 10.3 Page 65 'Processing REGISTER Requests', "The registrar checks whether the request contains the Contact header field..." here, what I understood gives the following pseudo-code segment : if (contact header field is present) { if (contact == '*') { if ((expires == '0') || (additional contact header field is present)) { Send 400 response } else { if (Call-Id != bound-call-id) { Remove binding } else if (Cseq < bound-cseq) { ERROR } else { Remove binding } } } else { /* General processing of contact field and update of binding */ } } else { /* Fetching of binding */ } Please let me know if my understanding is incorrect. Issue # 2 ------------------------------------------------------------------------------------------------ In rfc3261, Section 16.12 Page 117 'Summary of Proxy Route Processing' "2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy,..." My understanding of the purpose of route header field is to specify a next proxy server (can be a loose router) for the SIP Message to the proxy server. I am unable to visualize any scenario where the 1st entry of Router field can point to that of the receiving proxy, because at every step it gets removed and the next value becomes the top most value (next poxy for the next proxy server). Issue # 3 ------------------------------------------------------------------------------------------------ In rfc3261, Section 10.3 Page 62 'Processing REGISTER Requests' "Each REGISTER message MUST be processed independently of any other registration or binding changes." Does this imply that the registrar must not buffer register requests in attempt to answer with 1 OK for several REGISTER messages for the same AOR ? Ex: If a Registrar receives 2 consecutive REGISTER messages with same AOR but different contact fields, then should it send a single 200 containing 2 bindings or 2 distinct OKs for each of the REGISTER messages ? What exactly are the implications if REGISTER requests are not processed independently ? Issue # 4 ------------------------------------------------------------------------------------------------ In rfc3261, Section 10.3 Page 63 'Processing REGISTER Requests' "If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps." What will be the response status code when a REGISTRAR responsible for domain abc.def.com receives a REGISTER message with : i. To field set to user1@abc.xyz.com but Request-URI set to abc.def.com ii. To field set to user1@abc.xyz.com and Request-URI set to abc.xyz.com Any help with these issues will be very much appreciated. thanks, Rohan Sen --------------030202030409040606030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Issue # 1
------------------------------------------------------------------------------------------------
In rfc3261, Section 10.3 Page 65 'Processing REGISTER Requests',

"The registrar checks whether the request contains the Contact
header field..."

here, what I understood gives the following pseudo-code segment :

if (contact header field is present) {
  if (contact == '*') {
    if ((expires == '0') || (additional contact header field is present)) {
      Send 400 response
    }
    else {
      if (Call-Id != bound-call-id) {
        Remove binding
      }
      else if (Cseq < bound-cseq) {
        ERROR
      }
      else {
        Remove binding
      }
    }
  }
  else {
    /* General processing of contact field and update of binding */
  }
}
else {
  /* Fetching of binding */
}

Please let me know if my understanding is incorrect.

Issue # 2
------------------------------------------------------------------------------------------------
In rfc3261, Section 16.12 Page 117 'Summary of Proxy Route Processing'
"2.  The proxy will inspect the URI in the topmost Route header
       field value.  If it indicates this proxy,..."

My understanding of the purpose of route header field is to specify a next proxy server (can be a loose router)
for the SIP Message to the proxy server. I am unable to visualize any scenario where the 1st entry
of Router field can point to that of the receiving proxy, because at every step it gets removed and the
next value becomes the top most value (next poxy for the next proxy server).

Issue # 3
------------------------------------------------------------------------------------------------
In rfc3261, Section 10.3 Page 62 'Processing REGISTER Requests'
"Each REGISTER message MUST be processed independently of any
other registration or binding changes."

Does this imply that the registrar must not buffer register requests in attempt to answer
with 1 OK for several REGISTER messages for the same AOR ?
Ex: If a Registrar receives 2 consecutive REGISTER messages with same AOR but different contact fields,
       then should it send a single 200 containing 2 bindings or 2 distinct OKs for each of the REGISTER messages ?
What exactly are the implications if REGISTER requests are not processed independently ?

Issue # 4
------------------------------------------------------------------------------------------------
In rfc3261, Section 10.3 Page 63 'Processing REGISTER Requests'
"If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps."

What will be the response status code when a REGISTRAR responsible for domain
abc.def.com receives a REGISTER message
with :
i.    To field set to user1@abc.xyz.com but Request-URI set to abc.def.com
ii.   To field set to user1@abc.xyz.com and Request-URI set to abc.xyz.com

Any help with these issues will be very much appreciated.

thanks,
Rohan Sen

--------------030202030409040606030502-- --===============1119559532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1119559532==-- From sip-bounces@ietf.org Tue Oct 25 02:09:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHzz-00009M-E0; Tue, 25 Oct 2005 02:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHzv-00008o-Jr for sip@megatron.ietf.org; Tue, 25 Oct 2005 02:09:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22678 for ; Tue, 25 Oct 2005 02:09:08 -0400 (EDT) Received: from c243-111.rim.net ([216.9.243.111] helo=MHS01YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUICo-0007DR-I8 for sip@ietf.org; Tue, 25 Oct 2005 02:22:43 -0400 Received: from ngw01ykf.rim.net ([10.102.108.30]) by MHS01YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 02:09:07 -0400 Importance: normal Priority: normal Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw01ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2005102502090715824 for ; Tue, 25 Oct 2005 02:09:07 -0400 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 02:09:07 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Date: Tue, 25 Oct 2005 02:09:08 -0400 Message-ID: Thread-Topic: Issue with draft-ietf-sip-refer-with-norefersub-03 thread-index: AcXZKpySA+6eWkBfRMG2H8iV6sABrg== From: "Andrew Allen" To: X-OriginalArrivalTime: 25 Oct 2005 06:09:07.0382 (UTC) FILETIME=[9BB08D60:01C5D92A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: Subject: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0033063248==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0033063248== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D92A.9AC75D6B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D92A.9AC75D6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Orit =20 Orit I have an issue with the last paragraph in section 4 of the current draft. =20 The "norefersub" tag, when included in the Require header field (always in conjunction with the "Refer-Sub" header field set to "false"), specifies that the REFER-Recipient MUST process a REFER transaction without establishing an implicit subscription. In this case, if the REFER-Recipient either doesn't support the extension or is not willing to grant the request, the REFER request MUST be rejected by sending "420 Bad Extension" response back to the REFER- Issuer. =20 I have not been following discussions on the draft closely but I assume that the reason why the Refer-sub header was added to the draft was because the semantics for the use of Require header are not to require a particular behavior other than to require that the UAS support the extension(s) identified by the option tags in order to accept the request containing the Require header. The above text from section 4 conflicts with my understanding of the text in RFC 3261 regarding the use of the Require header and also seems to conflict with the definition of the Refer-sub header in the draft since it would be quite valid to send a Refer request with Require norefersub and Refer-sub True. A UAC may require that the UAS support the extension for later requests on that dialog without requesting Refer-sub False for that specific Refer (possibly it may need to use Refer-sub True) for a later Refer request. =20 I would propose that the text is either deleted or modified to: =20 The "norefersub" tag, when included in the Require header field,=20 specifies that the REFER-Recipient MUST support the extension or the REFER request MUST be rejected by sending "420 Bad Extension"=20 response back to the REFER-Issuer. =20 =20 Andrew =20 =20 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. ------_=_NextPart_001_01C5D92A.9AC75D6B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Orit

 

Orit I have an issue with the last paragraph in = section 4 of the current draft.

 

   The "norefersub" tag, when included in = the Require header field

   (always in conjunction with the = "Refer-Sub" header field set to

   "false"), specifies that the = REFER-Recipient MUST process a REFER

   transaction without establishing an implicit subscription.  In this

   case, if the REFER-Recipient either doesn't support = the extension or

   is not willing to grant the request, the REFER = request MUST be

   rejected by sending "420 Bad Extension" = response back to the REFER-

   Issuer.

 

I have not been following discussions on the draft = closely but I assume that the reason why the Refer-sub header was added to the = draft was because the semantics for the use of Require header are not to = require a particular behavior other than to require that the UAS support the = extension(s) identified by the option tags in order to accept the request containing = the Require header.  The above text from section 4 conflicts with my understanding of the text in RFC 3261 regarding the use of the Require = header and also seems to conflict with the definition of the Refer-sub header = in the draft since it would be quite valid to send a Refer request with Require norefersub and Refer-sub True. A UAC may require that the UAS support = the extension for later requests on that dialog without requesting Refer-sub = False for that specific Refer (possibly it may need to use Refer-sub True) for = a later Refer request.

 

I would propose that the text is either deleted or = modified to:

 

   The "norefersub" tag, when included in = the Require header field,

   specifies that the REFER-Recipient MUST support the extension or

   the REFER request MUST be rejected by sending = "420 Bad Extension"

   response back to the = REFER-Issuer.

 

 

Andrew

 

 

This transmission (including any attachments) may contain = confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or = constitute non-public information. Any use of this information by anyone = other than the intended recipient is prohibited. If you have received = this transmission in error, please immediately reply to the sender and = delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. ------_=_NextPart_001_01C5D92A.9AC75D6B-- --===============0033063248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0033063248==-- From sip-bounces@ietf.org Tue Oct 25 15:52:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUq8-0007F2-Lj; Tue, 25 Oct 2005 15:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUoD-0006oM-Mw; Tue, 25 Oct 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15718; Tue, 25 Oct 2005 15:49:54 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUV18-0007sK-Ff; Tue, 25 Oct 2005 16:03:33 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo6-0007kj-6Z; Tue, 25 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-e2m-sec-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@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 : End-to-middle Security in the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sip-e2m-sec-01.txt Pages : 26 Date : 2005-10-25 Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-e2m-sec-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-e2m-sec-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: <2005-10-25141313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-e2m-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-e2m-sec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25141313.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Tue Oct 25 15:52:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUqW-0007Jr-0v; Tue, 25 Oct 2005 15:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUoF-0006oJ-2k; Tue, 25 Oct 2005 15:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15713; Tue, 25 Oct 2005 15:49:54 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUV18-0007sG-6Y; Tue, 25 Oct 2005 16:03:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUUo6-0007kO-2a; Tue, 25 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 25 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-target-dialog-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@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 : Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-target-dialog-02.txt Pages : 16 Date : 2005-10-25 This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-target-dialog-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-target-dialog-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-25140337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-target-dialog-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-target-dialog-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-25140337.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Tue Oct 25 16:25:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUV8q-0001F1-PM; Tue, 25 Oct 2005 16:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUV8o-0001E8-2g for sip@megatron.ietf.org; Tue, 25 Oct 2005 16:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22971 for ; Tue, 25 Oct 2005 16:11:11 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVLo-0002CY-2b for sip@ietf.org; Tue, 25 Oct 2005 16:24:53 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j9PKB8Fg010252; Tue, 25 Oct 2005 20:11:08 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:10:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] impractical keying requirement in sip identity draft Date: Tue, 25 Oct 2005 16:10:26 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597015030B6@stntexch03.cis.neustar.com> Thread-Topic: [Sip] impractical keying requirement in sip identity draft Thread-Index: AcXYO2O9kH2KYDnAQwqyvhk6LLKRogBZBH2A From: "Peterson, Jon" To: "Juha Heinanen" , "Rohan Mahy" X-OriginalArrivalTime: 25 Oct 2005 20:10:26.0952 (UTC) FILETIME=[23DBA880:01C5D9A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, Juha, I think DNSSEC is a very promising direction for = discovering keys associated with domains, including the keys used by = sip-identity. For the moment, however, it remains a direction. The = operational issues associated with deploying DNSSEC are well known, and = while the situation has certainly gotten a lot better of late, it will = still be some time before DNSSEC signatures could really become a part = of the security story for applications like SIP. I don't think it would = be a worthwhile exercise to try to build DNSSEC-like solutions for = signing/providing keys for SIP as a work-around. So, while I think it would be worth revisiting the use of DNSSEC for = sip-identity when it becomes widely deployable, for the moment I think = we would be best served to stay our current course. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Sunday, October 23, 2005 6:19 PM > To: Rohan Mahy > Cc: Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] impractical keying requirement in sip=20 > identity draft >=20 >=20 > Rohan Mahy writes: >=20 > > Provider.net today determines what=20 > domain it is > > serving based on the port number (set via SRV). >=20 > are you saying that each time a provider adds a new domain to=20 > its proxy, > the proxy would need to start listening on a new port? in all proxies > that i know, this would mean restarting the proxy, which is very bad. >=20 > looks like the extended client hello that jon pointed to, might be a > better solution. but as far as i know, it is not yet supported by > openssl library, for example. >=20 > > Provider.netis hosting several TLS domains and > > for good providers, each hosted domain > > can have separate certs and private keys. Example-A.com=20 > does not have access > > to Example-B.com's private key and vice versa. >=20 > but provider needs access to both, which is my original concern. >=20 > > Another standardized but not yet deployed way to solve=20 > this problem is to > > use the TLS extended client hello extension to provide the=20 > name of the > > server. When implemented, this allows the server to=20 > provide the certificate > > of the expected domain on a single port. This is documented in RFC > > 3546. >=20 > yes. >=20 > all this hassle seems to result from not being able to trust dns. why > not simply sign the dns records pointing to the proxy after which the > proxy would only need to sign itself? >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 25 19:26:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUYBZ-0007Bq-0n; Tue, 25 Oct 2005 19:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUYBW-00076S-FY for sip@megatron.ietf.org; Tue, 25 Oct 2005 19:26:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04686 for ; Tue, 25 Oct 2005 19:26:12 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUYOY-00023M-Ls for sip@ietf.org; Tue, 25 Oct 2005 19:39:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 25 Oct 2005 16:26:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:26:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 Date: Tue, 25 Oct 2005 16:26:15 -0700 Message-ID: Thread-Topic: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 thread-index: AcXZKpySA+6eWkBfRMG2H8iV6sABrgAkKPFw From: "Orit Levin" To: "Andrew Allen" , X-OriginalArrivalTime: 25 Oct 2005 23:26:15.0677 (UTC) FILETIME=[7EA4D2D0:01C5D9BB] X-Spam-Score: 0.6 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482450113==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0482450113== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D9BB.7E3645D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D9BB.7E3645D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, I agree with your point and suggest to fix this statement in the 48 editor's hours, unless the chairs think differently. =20 Orit. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Andrew Allen Sent: Monday, October 24, 2005 11:09 PM To: sip@ietf.org Subject: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 =09 =09 Orit =20 Orit I have an issue with the last paragraph in section 4 of the current draft. =20 The "norefersub" tag, when included in the Require header field (always in conjunction with the "Refer-Sub" header field set to "false"), specifies that the REFER-Recipient MUST process a REFER transaction without establishing an implicit subscription. In this case, if the REFER-Recipient either doesn't support the extension or is not willing to grant the request, the REFER request MUST be rejected by sending "420 Bad Extension" response back to the REFER- Issuer. =20 I have not been following discussions on the draft closely but I assume that the reason why the Refer-sub header was added to the draft was because the semantics for the use of Require header are not to require a particular behavior other than to require that the UAS support the extension(s) identified by the option tags in order to accept the request containing the Require header. The above text from section 4 conflicts with my understanding of the text in RFC 3261 regarding the use of the Require header and also seems to conflict with the definition of the Refer-sub header in the draft since it would be quite valid to send a Refer request with Require norefersub and Refer-sub True. A UAC may require that the UAS support the extension for later requests on that dialog without requesting Refer-sub False for that specific Refer (possibly it may need to use Refer-sub True) for a later Refer request. =20 I would propose that the text is either deleted or modified to: =20 The "norefersub" tag, when included in the Require header field,=20 specifies that the REFER-Recipient MUST support the extension or the REFER request MUST be rejected by sending "420 Bad Extension"=20 response back to the REFER-Issuer. =20 =20 Andrew =20 =20 =09 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=20 ------_=_NextPart_001_01C5D9BB.7E3645D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andrew,
I agree with your point and suggest to fix this = statement=20 in the 48 editor's hours, unless the chairs think=20 differently.
 
Orit.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Andrew = Allen
Sent:=20 Monday, October 24, 2005 11:09 PM
To:=20 sip@ietf.org
Subject: [Sip] Issue with=20 draft-ietf-sip-refer-with-norefersub-03

Orit

 

Orit I have an issue = with the last=20 paragraph in section 4 of the current = draft.

 

   The "norefersub" tag, when = included in=20 the Require header field

   (always in conjunction with the = "Refer-Sub" header field set to

   "false"), specifies that the=20 REFER-Recipient MUST process a REFER

   transaction without = establishing an=20 implicit subscription.  In this

   case, if the REFER-Recipient = either=20 doesn't support the extension or

   is not willing to grant the = request, the=20 REFER request MUST be

   rejected by sending "420 Bad = Extension"=20 response back to the REFER-

   = Issuer.

 

I have not been = following=20 discussions on the draft closely but I assume that the reason why the=20 Refer-sub header was added to the draft was because the semantics for = the use=20 of Require header are not to require a particular behavior other than = to=20 require that the UAS support the extension(s) identified by the option = tags in=20 order to accept the request containing the Require header.  The = above=20 text from section 4 conflicts with my understanding of the text in RFC = 3261=20 regarding the use of the Require header and also seems to conflict = with the=20 definition of the Refer-sub header in the draft since it would be = quite valid=20 to send a Refer request with Require norefersub and Refer-sub True. A = UAC may=20 require that the UAS support the extension for later requests on that = dialog=20 without requesting Refer-sub False for that specific Refer (possibly = it may=20 need to use Refer-sub True) for a later Refer=20 request.

 

I would propose that the = text is=20 either deleted or modified to:

 

   The "norefersub" tag, when = included in=20 the Require header field,

   specifies that the = REFER-Recipient MUST=20 support the extension or

   the REFER request MUST be = rejected by=20 sending "420 Bad Extension"

   response back to the=20 REFER-Issuer.

 

 

Andrew

 

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the=20 solicitor-client or other applicable privileges), or constitute = non-public=20 information. Any use of this information by anyone other than the = intended=20 recipient is prohibited. If you have received this transmission in = error,=20 please immediately reply to the sender and delete this information = from your=20 system. Use, dissemination, distribution, or reproduction of this = transmission=20 by unintended recipients is not authorized and may be unlawful.=20 ------_=_NextPart_001_01C5D9BB.7E3645D6-- --===============0482450113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0482450113==-- From sip-bounces@ietf.org Wed Oct 26 00:35:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUd0p-0007ae-Ex; Wed, 26 Oct 2005 00:35:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUd0n-0007aX-4d for sip@megatron.ietf.org; Wed, 26 Oct 2005 00:35:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21129 for ; Wed, 26 Oct 2005 00:35:25 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUdDq-0001xa-Uf for sip@ietf.org; Wed, 26 Oct 2005 00:49:13 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2005 00:35:31 -0400 X-IronPort-AV: i="3.97,251,1125892800"; d="scan'208"; a="74443365:sNHT26860908" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9Q4ZREi006336; Wed, 26 Oct 2005 00:35:28 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 00:35:27 -0400 Received: from [192.168.1.100] ([10.86.241.0]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 00:35:27 -0400 Message-ID: <435F078E.8030006@cisco.com> Date: Wed, 26 Oct 2005 00:35:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] update to target-dialog References: <435B1F6D.1020800@cisco.com> <001801c5d81b$d65294a0$6402a8c0@BEMBUSTER> In-Reply-To: <001801c5d81b$d65294a0$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2005 04:35:27.0109 (UTC) FILETIME=[B028B350:01C5D9E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I hadnt considered any relationship with In-Reply-To, this is an interesting question. In-Reply-To has seen little to no usage to date, AFAIK. Its original intent was quite literally for calling someone back later. So, if A calls B, B will have a call log that records it. When B calls A back, A will know that this is a call back. Presumably the UA would alert the user that this was a callback from a specific call made earlier, so the user could decide to accept or reject. As such, I do not think that the In-Reply-To is a substitiute or appropriate vehicle for what we want to do with target-dialog. THe reasons are: 1. In-Reply-To references a past call originated by the recipient of In-Reply-To. Target-Dialog references a current dialog, and the direction of initiation is not relevant 2. In-Reply-To has just a call-id. We need an entire dialog ID. 3. In-Reply-To is meant for human consumption, Target-Dialog, for an automata. 4. In-Reply-To implies cause and effect; i.e., this new request is BECAUSE of the request you sent me with this call-id. There is no cause and effect here, merely a reference for authorization purposes So, though close, they're not the same. I'm not sure how important this is in the draft, since its more of a question of design choice and/or relationship with other similar headers. Nice FYI, but won't impact interop. Thanks, Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > It seems to me that In-Reply-To (RFC3261) is very similar to the new > Target-Dialog header proposed in the draft. Perhaps this would merit > some discussion (on this list and/or in the draft), in particular: > > - syntax is very similar, except that In-Reply-To does not allow parameters > - For In-Reply-To, RFC3261 explicitly states that "This field is not a > substitute for request authentication" > - Is Target-Dialog to be used also for the use case for In-Reply-To > mentioned in RFC3261 (return calls)? In that case there is no existing > dialog, but there are similarities > > Regards, > > Jeroen > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "IETF SIP List" > Sent: Sunday, October 23, 2005 7:28 AM > Subject: [Sip] update to target-dialog > > >> I just submitted a revision to the target-dialog spec. Until it >> appears, you can pick it up at: >> >> http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-02.txt >> >> The changes are: >> >> * More text on the importance of cryptographic identifiers for dialog IDs >> in order to prevent attacks >> >> * removed NOTIFY as an example dialog-forming request; while it is >> one, its confusing to be listed here since target-dialog isn't used in >> NOTIFY >> >> * fixed bug in example where 'user agent C' needed to be 'user agent >> B' >> >> * generalized the overview; it was written explicitly with REFER, but >> target-dialog is more general purpose >> >> * added IANA registry of header field parameters >> >> >> There are no open issues. I believe this document is ready to go. >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.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. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Wed Oct 26 03:17:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfX3-0007Jy-M4; Wed, 26 Oct 2005 03:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfX1-0007FC-Nf for sip@megatron.ietf.org; Wed, 26 Oct 2005 03:17:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28391 for ; Wed, 26 Oct 2005 03:16:53 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUfk8-0006cX-MH for sip@ietf.org; Wed, 26 Oct 2005 03:30:41 -0400 Received: (qmail 3441 invoked by uid 0); 26 Oct 2005 07:16:38 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Oct 2005 07:16:38 -0000 Message-ID: <002d01c5d9fd$328a60d0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <435B1F6D.1020800@cisco.com> <001801c5d81b$d65294a0$6402a8c0@BEMBUSTER> <435F078E.8030006@cisco.com> Subject: Re: [Sip] update to target-dialog Date: Wed, 26 Oct 2005 09:16:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, I agree with your assesment. Syntax-wise Target-Dialog is a superset of In-Reply-To, so I was thinking more in terms of Target-Dialog making In-Reply-To obsolete (and not in terms of substituting TD with IRT). In particular because I think the In-Reply-To use case (call back) could use the authorization which TD provides (and matching on the entire dialog-id instead of only the call-id IRT provides). Issue is then that there is no 'current' dialog in that case. However, your answer does clarify (for me at least) the design intentions of TD, perhaps including some of this information in the draft helps understandability More responses inline Thanks, Jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "Jeroen van Bemmel" Cc: "IETF SIP List" Sent: Wednesday, October 26, 2005 6:35 AM Subject: Re: [Sip] update to target-dialog >I hadnt considered any relationship with In-Reply-To, this is an >interesting question. In-Reply-To has seen little to no usage to date, >AFAIK. Its original intent was quite literally for calling someone back >later. So, if A calls B, B will have a call log that records it. When B >calls A back, A will know that this is a call back. Presumably the UA would >alert the user that this was a callback from a specific call made earlier, >so the user could decide to accept or reject. > > As such, I do not think that the In-Reply-To is a substitiute or > appropriate vehicle for what we want to do with target-dialog. THe reasons > are: > > 1. In-Reply-To references a past call originated by the recipient of > In-Reply-To. Target-Dialog references a current dialog, and the direction > of initiation is not relevant > How strong is this "current dialog" requirement? Section 4 currently states that when no match is found (i.e. no current dialog), the header MUST be ignored. For both example use-cases mentioned (application interaction and dialog tracking), it seems that in case of no match the purpose of the request is lost. I can see value in specifying that either: 1) When no match is found, the request containing the TD header MUST be replied to with an error response (e.g. 481 Dialog does not exist) 2) OR the sender can include a parameter / flag indicating its preference in case of no-match (to allow for valid use cases with no current dialog) I think in particular for the application interaction example this would improve the user experience (e.g. when a URL to an interface is sent, and that interface is no longer relevant when the call has ended). This is related to the TD header but does go beyond the intended purpose of authorization > 2. In-Reply-To has just a call-id. We need an entire dialog ID. > > 3. In-Reply-To is meant for human consumption, Target-Dialog, for an > automata. > I would think that both are for automata, a user agent could use the IRT call-id as index into its call-log and bring up more details on the call (e.g. "You called this party on this and that date/time, there was no answer") > 4. In-Reply-To implies cause and effect; i.e., this new request is BECAUSE > of the request you sent me with this call-id. There is no cause and effect > here, merely a reference for authorization purposes > 5. There can be multiple In-Reply-To headers in a request (although that has probably seen even less usage than the single header case) > > So, though close, they're not the same. I'm not sure how important this is > in the draft, since its more of a question of design choice and/or > relationship with other similar headers. Nice FYI, but won't impact > interop. > I was triggered by the syntactic similarity, and then started wondering about functional overlap. Based on this information I now believe that they are disjunct in purpose; the only point left is whether there are use cases (like call back) where authorization is desirable too, although there is no "current" dialog. Is the "current" aspect nescessary or perhaps too restrictive, and should TD applicability be extended to work for non-current dialogs too? > Thanks, > Jonathan R. > > > > Jeroen van Bemmel wrote: > >> Jonathan, >> >> It seems to me that In-Reply-To (RFC3261) is very similar to the new >> Target-Dialog header proposed in the draft. Perhaps this would merit some >> discussion (on this list and/or in the draft), in particular: >> >> - syntax is very similar, except that In-Reply-To does not allow >> parameters >> - For In-Reply-To, RFC3261 explicitly states that "This field is not a >> substitute for request authentication" >> - Is Target-Dialog to be used also for the use case for In-Reply-To >> mentioned in RFC3261 (return calls)? In that case there is no existing >> dialog, but there are similarities >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- From: "Jonathan Rosenberg" >> >> To: "IETF SIP List" >> Sent: Sunday, October 23, 2005 7:28 AM >> Subject: [Sip] update to target-dialog >> >> >>> I just submitted a revision to the target-dialog spec. Until it appears, >>> you can pick it up at: >>> >>> http://www.jdrosen.net/papers/draft-ietf-sip-target-dialog-02.txt >>> >>> The changes are: >>> >>> * More text on the importance of cryptographic identifiers for dialog >>> IDs >>> in order to prevent attacks >>> >>> * removed NOTIFY as an example dialog-forming request; while it is >>> one, its confusing to be listed here since target-dialog isn't used in >>> NOTIFY >>> >>> * fixed bug in example where 'user agent C' needed to be 'user agent >>> B' >>> >>> * generalized the overview; it was written explicitly with REFER, but >>> target-dialog is more general purpose >>> >>> * added IANA registry of header field parameters >>> >>> >>> There are no open issues. I believe this document is ready to go. >>> >>> Thanks, >>> Jonathan R. >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.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. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 sip-bounces@ietf.org Wed Oct 26 07:28:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjSh-00018m-HH; Wed, 26 Oct 2005 07:28:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjSf-00018X-Ad for sip@megatron.ietf.org; Wed, 26 Oct 2005 07:28:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12561 for ; Wed, 26 Oct 2005 07:28:37 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUjfn-0006Ad-S7 for sip@ietf.org; Wed, 26 Oct 2005 07:42:29 -0400 Received: by wproxy.gmail.com with SMTP id i11so51315wra for ; Wed, 26 Oct 2005 04:28:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=e+YR0Tz2vwoOG02Gi40c0df4cRAnKfikBDYnnn96C+1a62XukE3FtG1ynnPk0K2m63P4jkcgHU7EAz85VULhV99vekFeU53p7B6BZBoj+sOQcWt36DKUyZmlNVib8trCLewAWLJROCm5poRJkziKLiB5HZf+2ue7HvE9uhInLDk= Received: by 10.54.134.18 with SMTP id h18mr351733wrd; Wed, 26 Oct 2005 04:28:50 -0700 (PDT) Received: by 10.54.104.1 with HTTP; Wed, 26 Oct 2005 04:28:50 -0700 (PDT) Message-ID: <52db68bc0510260428u29a7fb2bm92795cbfbc3efc12@mail.gmail.com> Date: Wed, 26 Oct 2005 16:58:50 +0530 From: Sudhir Kumar Reddy To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] Watcher info in Subscribe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0191285890==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0191285890== Content-Type: multipart/alternative; boundary="----=_Part_4316_25466149.1130326130442" ------=_Part_4316_25466149.1130326130442 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I would like to know the significance if the watcher info in Event Header o= f Subscribe. what would be the difference between Normal Subscribe with Event: Presence and with Event:Presence.winfo I have gone thru RFC 3857 it was some what clear. could anyone give more feedback on this.. Any Comments is appericated. regards -- Sudhir Kumar Reddy Software Engineer, QualPhone communications pvt. ltd. Bangalore +91-9845052651 ------=_Part_4316_25466149.1130326130442 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi All,

I would like to know the significance if the watcher info in Event Heade= r of Subscribe.

what would be the difference between Normal Subscribe with Event: Presen= ce and with Event:Presence.winfo

I have gone thru RFC 3857 it was some what clear.

could anyone give more feedback on this..

Any Comments is appericated.


regards



--
Sudhir Kumar Reddy
S= oftware Engineer,
QualPhone communications pvt. ltd.
Bangalore
+91= -9845052651=20 ------=_Part_4316_25466149.1130326130442-- --===============0191285890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0191285890==-- From sip-bounces@ietf.org Wed Oct 26 08:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkiZ-0003lR-VH; Wed, 26 Oct 2005 08:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkiY-0003lM-MO for sip@megatron.ietf.org; Wed, 26 Oct 2005 08:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17094 for ; Wed, 26 Oct 2005 08:49:07 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler1.mail.eds.com ([199.228.142.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkvf-0000Kc-2D for sip@ietf.org; Wed, 26 Oct 2005 09:02:58 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9QCn46E032760; Wed, 26 Oct 2005 12:49:06 GMT Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9QCmfZE021499; Wed, 26 Oct 2005 07:48:41 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9QCmflu021477; Wed, 26 Oct 2005 07:48:41 -0500 To: "SIP Implementors" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 26 Oct 2005 08:49:23 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/26/2005 05:48:40 AM, Serialize complete at 10/26/2005 05:48:40 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP IETF Subject: [Sip] IN VITE with different from tag X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2094937382==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============2094937382== Content-Type: multipart/alternative; boundary="=_alternative 00463507852570A6_=" This is a multipart message in MIME format. --=_alternative 00463507852570A6_= Content-Type: text/plain; charset="US-ASCII" Hi, What should be the UA behaviour on receiving two INVITE with different from tags, all other headers are same, should it treat it as different call since it will create a different dialog? -Udit --=_alternative 00463507852570A6_= Content-Type: text/html; charset="US-ASCII"
Hi,

What should be the UA behaviour on receiving two INVITE with different from tags, all other headers are same,
should it treat it as different call since it will create a different dialog?

-Udit --=_alternative 00463507852570A6_=-- --===============2094937382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2094937382==-- From sip-bounces@ietf.org Wed Oct 26 12:21:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnum-0002Nv-Fp; Wed, 26 Oct 2005 12:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnuk-0002Mh-6v for sip@megatron.ietf.org; Wed, 26 Oct 2005 12:14:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04448 for ; Wed, 26 Oct 2005 12:13:54 -0400 (EDT) Received: from mail2.hutchison.com.au ([203.18.188.195] helo=mailsweeper2.orange.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUo7v-0000Eh-Sr for sip@ietf.org; Wed, 26 Oct 2005 12:27:48 -0400 Received: from mail.hutch.com.au (unverified [203.31.24.24]) by mailsweeper2.orange.net.au (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Thu, 27 Oct 2005 02:10:28 +1000 Received: from GWACCESS-MTA by mail.hutch.com.au with Novell_GroupWise; Thu, 27 Oct 2005 02:13:59 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Thu, 27 Oct 2005 02:13:40 +1000 From: "Philip Walls" To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Sip] Re: Sip Digest, Vol 18, Issue 28 (Out of office) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for your email. Sorry, but I'll be out of the office on Thurs 27/10 & Fri 28/10. I'll be b= ack on Mon 31/10. I will not be contactable on Thursday, but may be able to respond to voicem= ails on Friday. Cheers Phil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 12:22:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUo2w-0003VH-L3; Wed, 26 Oct 2005 12:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUo2v-0003Qe-0o for sip@megatron.ietf.org; Wed, 26 Oct 2005 12:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05374 for ; Wed, 26 Oct 2005 12:22:21 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoG3-0000fx-9c for sip@ietf.org; Wed, 26 Oct 2005 12:36:15 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ00CLP75K8W@szxga01-in.huawei.com> for sip@ietf.org; Thu, 27 Oct 2005 00:29:44 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ009M875K2H@szxga01-in.huawei.com> for sip@ietf.org; Thu, 27 Oct 2005 00:29:44 +0800 (CST) Received: from mspt9ukf7x4jg7 ([218.18.248.254]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOZ005P478BO7@szxml02-in.huawei.com>; Thu, 27 Oct 2005 00:31:23 +0800 (CST) Date: Thu, 27 Oct 2005 00:22:20 +0800 From: Peili Xu To: gupta gaurav , SIP Implementors Message-id: <006f01c5da49$716d6670$9878fea9@mspt9ukf7x4jg7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20051026133730.5857.qmail@web30505.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7BIT Cc: SIP IETF Subject: [Sip] Re: [Sip-implementors] IN VITE with different from tag X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, It is OK from the protocol`s point of view, but I don`t see the application meaning for such INVITEs. ----- Original Message ----- From: "gupta gaurav" To: "SIP Implementors" Cc: "SIP IETF" Sent: Wednesday, October 26, 2005 9:37 PM Subject: Re: [Sip-implementors] IN VITE with different from tag > Yes the calls should be treated as different .Since > dialog ID consists of to tag, from tag & call ID. > if one of them is different, new dialog is created > > --- Udit_Goyal@3com.com wrote: > > > Hi, > > > > What should be the UA behaviour on receiving two > > INVITE with different > > from tags, all other headers are same, > > should it treat it as different call since it will > > create a different > > dialog? > > > > -Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 16:29:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUru9-0006DI-7F; Wed, 26 Oct 2005 16:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUru6-0006CH-KT for sip@megatron.ietf.org; Wed, 26 Oct 2005 16:29:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05167 for ; Wed, 26 Oct 2005 16:29:31 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUs7J-0005XJ-Gb for sip@ietf.org; Wed, 26 Oct 2005 16:43:27 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9QKYj9p015587 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 15:34:46 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <001CD7EB-0799-4732-BDD4-6CF805CE4AA9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 26 Oct 2005 15:29:33 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] Another WGLC for draft-ietf-sip-gruu-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You old-timers might remember that we originally working-group last called GRUU during the summer of 2004. It's changed since then, just a bit. But I think we're getting pretty close to "done", so I'd like to have a final round of review here before we ship this puppy off to the IESG. Please re-read the draft and post any comments here and to the author (jdrosen@cisco.com). I plan to conclude this review during the week of November 6, 2005, so make sure you get your comments on the list BEFORE November 6. Now, here's a tidbit of news: The GRUU draft is our first to participate in the RFC Editor's "early copy" experiment. The RFC editor has already had a crack at the document and suggested some changes to the author. Hopefully this will lead to faster passage through the RFC Editor queue once the draft has passed IETF Last Call and IESG Review. -- Dean Willis SIP Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 16:35:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrzn-0002CG-Ap; Wed, 26 Oct 2005 16:35:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrzk-00028g-IL for sip@megatron.ietf.org; Wed, 26 Oct 2005 16:35:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08128 for ; Wed, 26 Oct 2005 16:35:20 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUsCy-0006hE-6v for sip@ietf.org; Wed, 26 Oct 2005 16:49:16 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9QKed31015659 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 15:40:42 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BC30AFE-9036-4FAE-8999-DD8520F8F26C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 Date: Wed, 26 Oct 2005 15:35:27 -0500 To: Orit Levin X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Orit and I discussed this, and we agree some clarification is in- order. I've asked orit to propose some text in RFC-ED before-after format, which we'll propose to include with the request for last call. -- Dean On Oct 25, 2005, at 6:26 PM, Orit Levin wrote: > Andrew, > I agree with your point and suggest to fix this statement in the 48 > editor's hours, unless the chairs think differently. > > Orit. > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf > Of Andrew Allen > Sent: Monday, October 24, 2005 11:09 PM > To: sip@ietf.org > Subject: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03 > > Orit > > > > Orit I have an issue with the last paragraph in section 4 of the > current draft. > > > > The "norefersub" tag, when included in the Require header field > > (always in conjunction with the "Refer-Sub" header field set to > > "false"), specifies that the REFER-Recipient MUST process a REFER > > transaction without establishing an implicit subscription. In this > > case, if the REFER-Recipient either doesn't support the > extension or > > is not willing to grant the request, the REFER request MUST be > > rejected by sending "420 Bad Extension" response back to the REFER- > > Issuer. > > > > I have not been following discussions on the draft closely but I > assume that the reason why the Refer-sub header was added to the > draft was because the semantics for the use of Require header are > not to require a particular behavior other than to require that the > UAS support the extension(s) identified by the option tags in order > to accept the request containing the Require header. The above > text from section 4 conflicts with my understanding of the text in > RFC 3261 regarding the use of the Require header and also seems to > conflict with the definition of the Refer-sub header in the draft > since it would be quite valid to send a Refer request with Require > norefersub and Refer-sub True. A UAC may require that the UAS > support the extension for later requests on that dialog without > requesting Refer-sub False for that specific Refer (possibly it may > need to use Refer-sub True) for a later Refer request. > > > > I would propose that the text is either deleted or modified to: > > > > The "norefersub" tag, when included in the Require header field, > > specifies that the REFER-Recipient MUST support the extension or > > the REFER request MUST be rejected by sending "420 Bad Extension" > > response back to the REFER-Issuer. > > > > > > Andrew > > > > > > > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), > or constitute non-public information. Any use of this information > by anyone other than the intended recipient is prohibited. If you > have received this transmission in error, please immediately reply > to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 17:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUshs-0000u4-H9; Wed, 26 Oct 2005 17:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUshr-0000sl-1I for sip@megatron.ietf.org; Wed, 26 Oct 2005 17:21:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27467 for ; Wed, 26 Oct 2005 17:20:55 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUsv4-0005kK-OO for sip@ietf.org; Wed, 26 Oct 2005 17:34:52 -0400 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9QLQD4a015970 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 16:26:14 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <312FA63B-E9F0-453D-8DF5-853CB7056A42@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 26 Oct 2005 16:21:01 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'd like to go ahead and start WGLC for the connection reuse draft. This is on the proposed SIP re-charter with a November deliverable, so we need to get moving on it. Let's start by putting Brett's three questions "on the plate" and noting that WGLC isn't over until they're resolved. See: http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html I'd like to conclude this WGLC no later than November 18, 2005. As always, please copy your comments to the list and to the author, rohan@ekabal.com -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 18:50:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu6Z-0000hv-KE; Wed, 26 Oct 2005 18:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu5u-0000Tf-18; Wed, 26 Oct 2005 18:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02307; Wed, 26 Oct 2005 18:49:49 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ6-0008Gz-AQ; Wed, 26 Oct 2005 19:03:45 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5p-0005aY-Vx; Wed, 26 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@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 : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-01.txt Pages : 28 Date : 2005-10-26 Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and NATs, prevent servers from connecting to User Agents in this way. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS server. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections for high availability systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-outbound-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-outbound-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: <2005-10-26170858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26170858.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Wed Oct 26 18:53:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu9I-0001mt-N8; Wed, 26 Oct 2005 18:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu67-0000ar-93; Wed, 26 Oct 2005 18:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02470; Wed, 26 Oct 2005 18:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ7-0008HM-0z; Wed, 26 Oct 2005 19:03:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5q-0005cJ-JD; Wed, 26 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@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 : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson, C. Jennings Filename : draft-ietf-sip-identity-06.txt Pages : 42 Date : 2005-10-26 The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-identity-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-identity-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26180516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26180516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Wed Oct 26 20:56:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUw46-0000Ox-0K; Wed, 26 Oct 2005 20:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUw43-0000Lh-DD for sip@megatron.ietf.org; Wed, 26 Oct 2005 20:56:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11111 for ; Wed, 26 Oct 2005 20:56:04 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwHJ-0000lz-0V for sip@ietf.org; Wed, 26 Oct 2005 21:10:02 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9R11Koa016875 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 20:01:20 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A81D7E7-2E2A-450D-805E-226C0FBC7DAC@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 26 Oct 2005 19:56:09 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] Draft agenda, SIP WG at IETF 64 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ok, here's my first pass at an agenda for SIP. If you have suggestions, please make them. There's a pretty HTML version at: http://www.softarmor.com/sipwg/meets/ietf64/agenda.html ---------- Agenda, SIP at IETF 64 Note: For this agenda, the proposed scheduling is NOT strongly in order of priority to the working group or milestone dates. Rather, topics that require security advisor participation are grouped into the first session, as the second session conflicts with the Security general area meeting. Session 1: Tuesday, November 8, 1300-1500 1305 Chairs Status, Charter and Schedule 1320 Kumiko Ono End-to-Middle Security draft-ietf-sip-e2m-sec-01 1335 John Elwell Connected identity draft-elwell-sip-connected-identity-00 1350 Feng Cao Cullen Jennings Response Identity draft-cao-sip-response-auth-00 1405 Cullen Jennings Certs draft-ietf-sipping-certs-02 1420 Hannes Tschofenig SAML draft-tschofenig-sip-saml-04 1435 Dean Willis Andrew Allen Answer and Alert Modes draft-willis-sip-answeralert-01 Session 2: Thursday, September 10, 1300-1500 (Note: conflicts with SAAG) 1305 Jonathan Rosenberg GRUU draft-ietf-sip-gruu-06 1320 Jonathan Rosenberg Target Dialog draft-ietf-sip-target-dialog-02 1335 Rohan Mahy Connection Reuse draft-ietf-sip-connect-reuse-04 1355 Cullen Jennings Outbound draft-ietf-sip-outbound-01 1415 Orit Levin Refer Feature Parameters draft-ietf-sip-refer-feature-param-00 1430 James Polk Brian Rosen Location Conveyance draft-ietf-sip-location-conveyance-01 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 26 23:21:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyKX-0002kS-WF; Wed, 26 Oct 2005 23:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyKV-0002i2-Tf for sip@megatron.ietf.org; Wed, 26 Oct 2005 23:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18767 for ; Wed, 26 Oct 2005 23:21:12 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUyXm-0004xv-Np for sip@ietf.org; Wed, 26 Oct 2005 23:35:12 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9R3Q748017519 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 22:26:08 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 26 Oct 2005 22:20:57 -0500 To: MARJOU Xavier RD-MAPS-LAN X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, leo@cisco.com Subject: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > Hi, > > When reading Req-5 with "some sorts of emergency session", I > understand > that an "emergency mass alert" is a candidate use-case. > > Thus, in section 6, I suggest a new value for the Alert-Mode header > field: "Amplified" so that as many people as possible are alerted > (e.g. > an amplified ring tone). In this case, a UAS could also decide to > increase the volume of audio. > I've been thinking about this, and working on some client specs, and I'm beginning to think that maybe the Alert-Info header might offer a better way to do this, as well as do a number of other things (including possibly the alert-mode function of the draft in question). Maybe somebody already suggested this, and it just now percolated through my brain, so I apologize if I'm failing to credit this idea correctly. The problem with Alert-Info is that it's almost completely unspecified. As I read it, 3261 says it takes a URL as a value, without providing any way to negotiate (or confirm) the range of URLs that might be meaningful to the UAS. Not good. Some implementations (aka Cisco) use totally bogus integers or cadence-maps or other stuff in the Alert-Info header. Also not good. What if we were to define a series of URNs that refer to standardized alert-behaviors? We could have registered URNS for: 1) Normal alert 2) Distinctive alert (possibly indexed by an integer, for different distinctive alerts) 3) Null alert (which provides for the alert-mode behavior from this draft) 4) One or more types of request-encoded alerts, like the Cisco integers, where the encoded value is carried as a URN parameter set 5) Emergency alert We could lump these into one URN set (namespace?) and associate a SIP OPTION tag with support for the entire set of alerting behaviors. I think of this as "basic alerting options", and we could bound up the whole set in one I-D. Thus, an INVITE request might carry something like: Alert-Info: urn:org.ietf.sip.alert.basic//emergency Require: alert.basic or maybe: Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 or Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 Then for "downloaded" alert sets (aka HTTP or other URLS) we could potentially have additional URN sets, perhaps by URL type, or by payload type, or some other combination. This could provide subject material for additional IDs. -- 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 sip-bounces@ietf.org Wed Oct 26 23:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyi6-0003eD-9d; Wed, 26 Oct 2005 23:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUyi4-0003au-4W for sip@megatron.ietf.org; Wed, 26 Oct 2005 23:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19967 for ; Wed, 26 Oct 2005 23:45:32 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUyvL-0005dc-8f for sip@ietf.org; Wed, 26 Oct 2005 23:59:32 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9R3orwR017632 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 26 Oct 2005 22:50:54 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18417572-8A9E-4DE4-AB15-52EA84C4DC21@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 26 Oct 2005 22:45:42 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] Are we ready to WGLC draft-ietf-sip-e2m-sec-01? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At IETF 63 we said we expected to be able to WGLC the next draft (which has been published). Kumiko tells me that there are currently no open issues to discuss at IETF 64. The current draft passes idnits and looks superficially good to me. Are we ready to WGLC this draft? What do we think about requesting some security-area review in conjunction with WGLC? -- 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 sip-bounces@ietf.org Thu Oct 27 04:02:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV2i3-0004KH-Uu; Thu, 27 Oct 2005 04:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlTO-0004Ro-Om for sip@megatron.ietf.org; Wed, 26 Oct 2005 09:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19891 for ; Wed, 26 Oct 2005 09:37:31 -0400 (EDT) Received: from web30505.mail.mud.yahoo.com ([68.142.200.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EUlgT-0001pQ-0q for sip@ietf.org; Wed, 26 Oct 2005 09:51:23 -0400 Received: (qmail 5859 invoked by uid 60001); 26 Oct 2005 13:37:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UJSDzBgD0W6AL9aHxw8HP9o77h3rCh4s7fRRnTF0+Rzwk9Hs3nTnRqcMls9k4Lb6OTp68ihBTa/+AMaAs1V2qiPpefHIBg6Gdk2NsJ7R90HsG8Lxjdbiu9WfrAOwDRZ4T2xNuQjlsWwc9eWlPyFZhOjqVQbaoK+Kj9nysOEUAB0= ; Message-ID: <20051026133730.5857.qmail@web30505.mail.mud.yahoo.com> Received: from [217.45.197.113] by web30505.mail.mud.yahoo.com via HTTP; Wed, 26 Oct 2005 06:37:30 PDT Date: Wed, 26 Oct 2005 06:37:30 -0700 (PDT) From: gupta gaurav To: SIP Implementors In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 27 Oct 2005 04:02:01 -0400 Cc: SIP IETF Subject: [Sip] Re: [Sip-implementors] IN VITE with different from tag X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes the calls should be treated as different .Since dialog ID consists of to tag, from tag & call ID. if one of them is different, new dialog is created --- Udit_Goyal@3com.com wrote: > Hi, > > What should be the UA behaviour on receiving two > INVITE with different > from tags, all other headers are same, > should it treat it as different call since it will > create a different > dialog? > > -Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.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 sip-bounces@ietf.org Thu Oct 27 08:17:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6gV-0005sk-93; Thu, 27 Oct 2005 08:16:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6gT-0005sS-FH; Thu, 27 Oct 2005 08:16:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25275; Thu, 27 Oct 2005 08:16:24 -0400 (EDT) From: dave.robbins@verizon.com Received: from ftwmail2.verizon.com ([192.76.86.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV6tn-0008Uw-OQ; Thu, 27 Oct 2005 08:30:30 -0400 Received: from smtpirv.verizon.com (smtpirv.verizon.com [138.83.34.67]) by ftwmail2.verizon.com (8.13.3/8.13.3) with ESMTP id j9RCGJHP004734; Thu, 27 Oct 2005 07:16:19 -0500 (EST) Received: from ustxirvhqwmms01.ent.verizon.com (IRVMMS01B.interwan.gte.com [138.83.34.107]) by smtpirv.verizon.com (8.13.3/8.13.3) with ESMTP id j9RCGGYf013118; Thu, 27 Oct 2005 07:16:18 -0500 (CDT) Received: from 138.83.34.48 by ustxirvhqwmms01.ent.verizon.com with ESMTP (SMTP Relay); Thu, 27 Oct 2005 07:16:06 -0500 X-Server-Uuid: E1A60121-6F68-4E45-9692-B480AF34C963 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id j9RCG4Pe018005; Thu, 27 Oct 2005 07:16:06 -0500 (CDT) In-Reply-To: Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) To: "Dean Willis" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Thu, 27 Oct 2005 08:16:03 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 10/27/2005 07:16:05 MIME-Version: 1.0 X-WSS-ID: 6F7E1A8C2IS973687-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , sip-bounces@ietf.org, leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I agree wholeheartedly with Dean. A URL is a nice, generic way to specify an alert signal, but unless you know what sort of URLs your client understands, it's not very useful. Some clients might understand a URL that returns an audio file, but for other clients that might be totally useless. A set of standardized URNs that includes the various alerting patterns typically used in traditional telephony applications would be of great interest to me and my work. This would include the standard North American alerting patterns generically identified by the integers one through five, perhaps expressed more generically in some manner. And I imagine that there are other forms of alerting that could be accepted as standard. In my current work, we have had to invent a notation for this, and I've been suggesting that we think about promoting a standard of some sort. Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 781 466 4188 "Dean Willis" To Sent by: "MARJOU Xavier RD-MAPS-LAN" sip-bounces@ietf. org cc sip@ietf.org, leo@cisco.com Subject 10/26/2005 11:20 [Sip] Alert-Info Idea (was Re: PM Comment on draft-willis-sip-answeralert-01) On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > Hi, > > When reading Req-5 with "some sorts of emergency session", I > understand > that an "emergency mass alert" is a candidate use-case. > > Thus, in section 6, I suggest a new value for the Alert-Mode header > field: "Amplified" so that as many people as possible are alerted > (e.g. > an amplified ring tone). In this case, a UAS could also decide to > increase the volume of audio. > I've been thinking about this, and working on some client specs, and I'm beginning to think that maybe the Alert-Info header might offer a better way to do this, as well as do a number of other things (including possibly the alert-mode function of the draft in question). Maybe somebody already suggested this, and it just now percolated through my brain, so I apologize if I'm failing to credit this idea correctly. The problem with Alert-Info is that it's almost completely unspecified. As I read it, 3261 says it takes a URL as a value, without providing any way to negotiate (or confirm) the range of URLs that might be meaningful to the UAS. Not good. Some implementations (aka Cisco) use totally bogus integers or cadence-maps or other stuff in the Alert-Info header. Also not good. What if we were to define a series of URNs that refer to standardized alert-behaviors? We could have registered URNS for: 1) Normal alert 2) Distinctive alert (possibly indexed by an integer, for different distinctive alerts) 3) Null alert (which provides for the alert-mode behavior from this draft) 4) One or more types of request-encoded alerts, like the Cisco integers, where the encoded value is carried as a URN parameter set 5) Emergency alert We could lump these into one URN set (namespace?) and associate a SIP OPTION tag with support for the entire set of alerting behaviors. I think of this as "basic alerting options", and we could bound up the whole set in one I-D. Thus, an INVITE request might carry something like: Alert-Info: urn:org.ietf.sip.alert.basic//emergency Require: alert.basic or maybe: Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 or Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 Then for "downloaded" alert sets (aka HTTP or other URLS) we could potentially have additional URN sets, perhaps by URL type, or by payload type, or some other combination. This could provide subject material for additional IDs. -- 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 sip-bounces@ietf.org Thu Oct 27 09:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7oX-0004UC-DW; Thu, 27 Oct 2005 09:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7oV-0004QC-Nr for sip@megatron.ietf.org; Thu, 27 Oct 2005 09:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28991 for ; Thu, 27 Oct 2005 09:28:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV81s-0001yG-OO for sip@ietf.org; Thu, 27 Oct 2005 09:42:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2005 06:28:53 -0700 X-IronPort-AV: i="3.97,258,1125903600"; d="scan'208"; a="357462784:sNHT1622462890" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9RDSB9a009182; Thu, 27 Oct 2005 06:28:51 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:28:29 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:28:29 -0400 Message-ID: <4360D5FC.2020408@cisco.com> Date: Thu, 27 Oct 2005 09:28:28 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 13:28:29.0240 (UTC) FILETIME=[51685B80:01C5DAFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean - Inline. Dean Willis wrote: > > On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > >> Hi, >> >> When reading Req-5 with "some sorts of emergency session", I understand >> that an "emergency mass alert" is a candidate use-case. >> >> Thus, in section 6, I suggest a new value for the Alert-Mode header >> field: "Amplified" so that as many people as possible are alerted (e.g. >> an amplified ring tone). In this case, a UAS could also decide to >> increase the volume of audio. >> > > I've been thinking about this, and working on some client specs, and > I'm beginning to think that maybe the Alert-Info header might offer a > better way to do this, as well as do a number of other things > (including possibly the alert-mode function of the draft in question). > Maybe somebody already suggested this, and it just now percolated > through my brain, so I apologize if I'm failing to credit this idea > correctly. I think I may have mentioned this somewhere, sometime. At least I have also been thinking about it, and talking about it in fora where you weren't present. > The problem with Alert-Info is that it's almost completely unspecified. > As I read it, 3261 says it takes a URL as a value, without providing > any way to negotiate (or confirm) the range of URLs that might be > meaningful to the UAS. Not good. The lack of negotiation capability is somewhat of a problem, though the ability to negotiate any behavior of the callee at this stage of the call is dubious. (Potentially a UAS could return an error for an unrecognized Alert-Info, but that would then yield a HERFP problem.) > Some implementations (aka Cisco) use totally bogus integers or > cadence-maps or other stuff in the Alert-Info header. Also not good. > > What if we were to define a series of URNs that refer to standardized > alert-behaviors? We could have registered URNS for: > > 1) Normal alert > 2) Distinctive alert (possibly indexed by an integer, for different > distinctive alerts) > 3) Null alert (which provides for the alert-mode behavior from this draft) > 4) One or more types of request-encoded alerts, like the Cisco > integers, where the encoded value is carried as a URN parameter set > 5) Emergency alert I think URNs have a place here. > We could lump these into one URN set (namespace?) and associate a SIP > OPTION tag with support for the entire set of alerting behaviors. I > think of this as "basic alerting options", and we could bound up the > whole set in one I-D. In general, alerting is normally considered to ultimately be up to the one doing the alerting. In most cases I would expect any indication by the caller to be advisory. E.g. the callee may not trust the caller, and/or may want to use some kind of distinctive alerting it chooses to indicate who is calling. Ultimately, both the caller and the callee may want to choose, and somebody has to win. The question then is: if the OPTION tag is there, should the request be rejected if the Alert-Info value isn't understood, or if it won't be honored? This is further complicated because I think there will be many cases where intermediaries may want to insert an Alert-Info. For instance, I know of one proposal for a proxy acting on behalf of the callee to implement distinctive alerting by inserting an Alert-Info header with a value chosen according to who the caller is. Then the UAS only has to honor the Alert-Info, not figure out the circumstances when distinctive alerting should apply. I guess the usage for PoC would be simiar to this. In some sense things are simpler if the Alert-Info is inserted by an agent operating on behalf of the UAS, because it can perhaps be assumed to know what the UAS is capable of processing. > Thus, an INVITE request might carry something like: > > Alert-Info: urn:org.ietf.sip.alert.basic//emergency > Require: alert.basic > > or maybe: > > Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 > > or > > Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 > > > Then for "downloaded" alert sets (aka HTTP or other URLS) we could > potentially have additional URN sets, perhaps by URL type, or by > payload type, or some other combination. This could provide subject > material for additional IDs. I could pick at the details above, but now is not the time. Lets get the basic concepts worked out first. I'm worried about conflicts between the desires of the caller and callee, and also about the HERFP problem if we use Require. I think these can be sidestepped IF we assume the caller never inserts mandatory Alert-Info headers, and that A-I is generally only inserted by an agent of the callee that can have been provisioned to be aware of the UAS capabilities. 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 sip-bounces@ietf.org Thu Oct 27 09:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Df-0003Jy-62; Thu, 27 Oct 2005 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Dc-0003JE-Hi; Thu, 27 Oct 2005 09:55:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00817; Thu, 27 Oct 2005 09:54:45 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8Qy-0002oY-9k; Thu, 27 Oct 2005 10:08:50 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2005 06:54:49 -0700 X-IronPort-AV: i="3.97,258,1125903600"; d="scan'208"; a="357474570:sNHT62126824" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9RDsfuh025521; Thu, 27 Oct 2005 06:54:46 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:54:09 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:54:08 -0400 Message-ID: <4360DC00.80303@cisco.com> Date: Thu, 27 Oct 2005 09:54:08 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dave.robbins@verizon.com Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 13:54:08.0763 (UTC) FILETIME=[E708ECB0:01C5DAFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , sip-bounces@ietf.org, leo@cisco.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it would be good if there was a set of URNs that are defined *semantically* rather than defining precisely what should be rendered. These would be of much broader applicability than those that specify particular audio waveforms, etc., because they could be rendered in a variety of ways: audio, video, tactile, in different languages, etc. However there is probably value in having ones that have specific renderings as well. There could also be scenarios where one entity (e.g. representing the caller) inserts a URN that is semantic in nature, and another entity (e.g. representing the callee) replaces that with a different URN (or URI) that identifies a specific rendering that is consistent with the intended semantic, the capabilities of the UAS, and the desires of the UAS in terms of culturally specific values. Paul dave.robbins@verizon.com wrote: > I agree wholeheartedly with Dean. A URL is a nice, generic way to specify > an alert signal, but unless you know what sort of URLs your client > understands, it's not very useful. Some clients might understand a URL that > returns an audio file, but for other clients that might be totally useless. > A set of standardized URNs that includes the various alerting patterns > typically used in traditional telephony applications would be of great > interest to me and my work. This would include the standard North American > alerting patterns generically identified by the integers one through five, > perhaps expressed more generically in some manner. And I imagine that there > are other forms of alerting that could be accepted as standard. In my > current work, we have had to invent a notation for this, and I've been > suggesting that we think about promoting a standard of some sort. > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > 781 466 4188 > > > > "Dean Willis" > armor.com> To > Sent by: "MARJOU Xavier RD-MAPS-LAN" > sip-bounces@ietf. > org cc > sip@ietf.org, leo@cisco.com > Subject > 10/26/2005 11:20 [Sip] Alert-Info Idea (was Re: > PM Comment on > draft-willis-sip-answeralert-01) > > > > > > > > > > > > On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > > >>Hi, >> >>When reading Req-5 with "some sorts of emergency session", I >>understand >>that an "emergency mass alert" is a candidate use-case. >> >>Thus, in section 6, I suggest a new value for the Alert-Mode header >>field: "Amplified" so that as many people as possible are alerted >>(e.g. >>an amplified ring tone). In this case, a UAS could also decide to >>increase the volume of audio. >> > > > I've been thinking about this, and working on some client specs, and > I'm beginning to think that maybe the Alert-Info header might offer a > better way to do this, as well as do a number of other things > (including possibly the alert-mode function of the draft in > question). Maybe somebody already suggested this, and it just now > percolated through my brain, so I apologize if I'm failing to credit > this idea correctly. > > The problem with Alert-Info is that it's almost completely > unspecified. As I read it, 3261 says it takes a URL as a value, > without providing any way to negotiate (or confirm) the range of URLs > that might be meaningful to the UAS. Not good. > > Some implementations (aka Cisco) use totally bogus integers or > cadence-maps or other stuff in the Alert-Info header. Also not good. > > What if we were to define a series of URNs that refer to standardized > alert-behaviors? We could have registered URNS for: > > 1) Normal alert > 2) Distinctive alert (possibly indexed by an integer, for different > distinctive alerts) > 3) Null alert (which provides for the alert-mode behavior from this > draft) > 4) One or more types of request-encoded alerts, like the Cisco > integers, where the encoded value is carried as a URN parameter set > 5) Emergency alert > > We could lump these into one URN set (namespace?) and associate a SIP > OPTION tag with support for the entire set of alerting behaviors. I > think of this as "basic alerting options", and we could bound up the > whole set in one I-D. > > Thus, an INVITE request might carry something like: > > Alert-Info: urn:org.ietf.sip.alert.basic//emergency > Require: alert.basic > > or maybe: > > Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 > > or > > Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 > > > Then for "downloaded" alert sets (aka HTTP or other URLS) we could > potentially have additional URN sets, perhaps by URL type, or by > payload type, or some other combination. This could provide subject > material for additional IDs. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 27 10:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Qx-00073S-Lw; Thu, 27 Oct 2005 10:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Qw-000738-58; Thu, 27 Oct 2005 10:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01732; Thu, 27 Oct 2005 10:08:30 -0400 (EDT) From: dave.robbins@verizon.com Received: from tpamail2.verizon.com ([192.76.82.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8eI-0003Hc-Aa; Thu, 27 Oct 2005 10:22:35 -0400 Received: from smtpirv.verizon.com (smtpirv.verizon.com [138.83.34.67]) by tpamail2.verizon.com (8.13.3/8.13.3) with ESMTP id j9RE8Ujp029434; Thu, 27 Oct 2005 10:08:30 -0400 (EDT) Received: from ustxirvhqwmms01.ent.verizon.com (IRVMMS01B.interwan.gte.com [138.83.34.107]) by smtpirv.verizon.com (8.13.3/8.13.3) with ESMTP id j9RE8Hnu013320; Thu, 27 Oct 2005 09:08:23 -0500 (CDT) Received: from 138.83.34.48 by ustxirvhqwmms01.ent.verizon.com with ESMTP (SMTP Relay); Thu, 27 Oct 2005 09:07:54 -0500 X-Server-Uuid: E1A60121-6F68-4E45-9692-B480AF34C963 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id j9RE7rjP025082; Thu, 27 Oct 2005 09:07:53 -0500 (CDT) In-Reply-To: <4360DC00.80303@cisco.com> Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) To: "Paul Kyzivat" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Thu, 27 Oct 2005 10:07:51 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 10/27/2005 09:07:53 MIME-Version: 1.0 X-WSS-ID: 6F7E00B02IS1004155-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , sip-bounces@ietf.org, leo@cisco.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Agreed. Defining URNs "semantically" is what I had in mind. In an application carried over from the PSTN, distinctive alerting takes one of two different forms, depending upon whether it is rendered as power ringing or as a call-waiting alert tone. I would want to use a single URN, which the UAS would render in whatever way is appropriate for the current state of the device. Other semantic forms are surely useful as well. I can also see the potential value in having a URN that carries a specific rendering. Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 781 466 4188 "Paul Kyzivat" To Dave C. 10/27/2005 09:54 Robbins/EMPL/MA/Verizon@VZNotes AM cc "Dean Willis" , sip@ietf.org, "MARJOU Xavier RD-MAPS-LAN" , sip-bounces@ietf.org, leo@cisco.com Subject Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) I think it would be good if there was a set of URNs that are defined *semantically* rather than defining precisely what should be rendered. These would be of much broader applicability than those that specify particular audio waveforms, etc., because they could be rendered in a variety of ways: audio, video, tactile, in different languages, etc. However there is probably value in having ones that have specific renderings as well. There could also be scenarios where one entity (e.g. representing the caller) inserts a URN that is semantic in nature, and another entity (e.g. representing the callee) replaces that with a different URN (or URI) that identifies a specific rendering that is consistent with the intended semantic, the capabilities of the UAS, and the desires of the UAS in terms of culturally specific values. Paul dave.robbins@verizon.com wrote: > I agree wholeheartedly with Dean. A URL is a nice, generic way to specify > an alert signal, but unless you know what sort of URLs your client > understands, it's not very useful. Some clients might understand a URL that > returns an audio file, but for other clients that might be totally useless. > A set of standardized URNs that includes the various alerting patterns > typically used in traditional telephony applications would be of great > interest to me and my work. This would include the standard North American > alerting patterns generically identified by the integers one through five, > perhaps expressed more generically in some manner. And I imagine that there > are other forms of alerting that could be accepted as standard. In my > current work, we have had to invent a notation for this, and I've been > suggesting that we think about promoting a standard of some sort. > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > 781 466 4188 > > > > "Dean Willis" > armor.com> To > Sent by: "MARJOU Xavier RD-MAPS-LAN" > sip-bounces@ietf. > org cc > sip@ietf.org, leo@cisco.com > Subject > 10/26/2005 11:20 [Sip] Alert-Info Idea (was Re: > PM Comment on > draft-willis-sip-answeralert-01) > > > > > > > > > > > > On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > > >>Hi, >> >>When reading Req-5 with "some sorts of emergency session", I >>understand >>that an "emergency mass alert" is a candidate use-case. >> >>Thus, in section 6, I suggest a new value for the Alert-Mode header >>field: "Amplified" so that as many people as possible are alerted >>(e.g. >>an amplified ring tone). In this case, a UAS could also decide to >>increase the volume of audio. >> > > > I've been thinking about this, and working on some client specs, and > I'm beginning to think that maybe the Alert-Info header might offer a > better way to do this, as well as do a number of other things > (including possibly the alert-mode function of the draft in > question). Maybe somebody already suggested this, and it just now > percolated through my brain, so I apologize if I'm failing to credit > this idea correctly. > > The problem with Alert-Info is that it's almost completely > unspecified. As I read it, 3261 says it takes a URL as a value, > without providing any way to negotiate (or confirm) the range of URLs > that might be meaningful to the UAS. Not good. > > Some implementations (aka Cisco) use totally bogus integers or > cadence-maps or other stuff in the Alert-Info header. Also not good. > > What if we were to define a series of URNs that refer to standardized > alert-behaviors? We could have registered URNS for: > > 1) Normal alert > 2) Distinctive alert (possibly indexed by an integer, for different > distinctive alerts) > 3) Null alert (which provides for the alert-mode behavior from this > draft) > 4) One or more types of request-encoded alerts, like the Cisco > integers, where the encoded value is carried as a URN parameter set > 5) Emergency alert > > We could lump these into one URN set (namespace?) and associate a SIP > OPTION tag with support for the entire set of alerting behaviors. I > think of this as "basic alerting options", and we could bound up the > whole set in one I-D. > > Thus, an INVITE request might carry something like: > > Alert-Info: urn:org.ietf.sip.alert.basic//emergency > Require: alert.basic > > or maybe: > > Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 > > or > > Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 > > > Then for "downloaded" alert sets (aka HTTP or other URLS) we could > potentially have additional URN sets, perhaps by URL type, or by > payload type, or some other combination. This could provide subject > material for additional IDs. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 27 11:24:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9bt-0002b3-JD; Thu, 27 Oct 2005 11:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9br-0002aE-Dd for sip@megatron.ietf.org; Thu, 27 Oct 2005 11:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14878 for ; Thu, 27 Oct 2005 11:23:50 -0400 (EDT) Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9p9-0000Fl-Vr for sip@ietf.org; Thu, 27 Oct 2005 11:37:55 -0400 Received: from fdns2.rolm.com (imail2.icn.siemens.com [165.218.1.59]) by mail.siemenscom.com (8.13.4/8.13.4) with ESMTP id j9RFOCpX019322 for ; Thu, 27 Oct 2005 08:24:12 -0700 (PDT) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id j9RFNIwC004747 for ; Thu, 27 Oct 2005 08:23:18 -0700 (PDT) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Oct 2005 08:23:18 -0700 Message-ID: <4B8DD52AB570D311BEDE0008C7E619880D076723@BOCA212A> From: "Vaidya, Maulik" To: sip@ietf.org Subject: RE: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-an sweralert-01) Date: Thu, 27 Oct 2005 08:21:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Gents, pardon my ignorance if I say something really stupid Shouldn't 'semantic URNs' in some manner, shape or form include the format of alert (i.e. wav, mp3 etc), and the preferred medium of download (i.e. HTTP, WAP etc)? (because not all UACs will have the capability to support all forms of alert tones and download mechanisms. -Maulik -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of dave.robbins@verizon.com Sent: Thursday, October 27, 2005 10:08 AM To: Paul Kyzivat Cc: sip@ietf.org; MARJOU Xavier RD-MAPS-LAN; sip-bounces@ietf.org; leo@cisco.com; Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-answeralert-01) Agreed. Defining URNs "semantically" is what I had in mind. In an application carried over from the PSTN, distinctive alerting takes one of two different forms, depending upon whether it is rendered as power ringing or as a call-waiting alert tone. I would want to use a single URN, which the UAS would render in whatever way is appropriate for the current state of the device. Other semantic forms are surely useful as well. I can also see the potential value in having a URN that carries a specific rendering. Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 781 466 4188 "Paul Kyzivat" To Dave C. 10/27/2005 09:54 Robbins/EMPL/MA/Verizon@VZNotes AM cc "Dean Willis" , sip@ietf.org, "MARJOU Xavier RD-MAPS-LAN" , sip-bounces@ietf.org, leo@cisco.com Subject Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) I think it would be good if there was a set of URNs that are defined *semantically* rather than defining precisely what should be rendered. These would be of much broader applicability than those that specify particular audio waveforms, etc., because they could be rendered in a variety of ways: audio, video, tactile, in different languages, etc. However there is probably value in having ones that have specific renderings as well. There could also be scenarios where one entity (e.g. representing the caller) inserts a URN that is semantic in nature, and another entity (e.g. representing the callee) replaces that with a different URN (or URI) that identifies a specific rendering that is consistent with the intended semantic, the capabilities of the UAS, and the desires of the UAS in terms of culturally specific values. Paul dave.robbins@verizon.com wrote: > I agree wholeheartedly with Dean. A URL is a nice, generic way to > specify an alert signal, but unless you know what sort of URLs your > client understands, it's not very useful. Some clients might > understand a URL that > returns an audio file, but for other clients that might be totally useless. > A set of standardized URNs that includes the various alerting patterns > typically used in traditional telephony applications would be of great > interest to me and my work. This would include the standard North American > alerting patterns generically identified by the integers one through five, > perhaps expressed more generically in some manner. And I imagine that there > are other forms of alerting that could be accepted as standard. In my > current work, we have had to invent a notation for this, and I've been > suggesting that we think about promoting a standard of some sort. > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > 781 466 4188 > > > > "Dean Willis" > armor.com> To > Sent by: "MARJOU Xavier RD-MAPS-LAN" > sip-bounces@ietf. > org cc > sip@ietf.org, leo@cisco.com > Subject > 10/26/2005 11:20 [Sip] Alert-Info Idea (was Re: > PM Comment on > > draft-willis-sip-answeralert-01) > > > > > > > > > > > > On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: > > >>Hi, >> >>When reading Req-5 with "some sorts of emergency session", I >>understand that an "emergency mass alert" is a candidate use-case. >> >>Thus, in section 6, I suggest a new value for the Alert-Mode header >>field: "Amplified" so that as many people as possible are alerted >>(e.g. >>an amplified ring tone). In this case, a UAS could also decide to >>increase the volume of audio. >> > > > I've been thinking about this, and working on some client specs, and > I'm beginning to think that maybe the Alert-Info header might offer a > better way to do this, as well as do a number of other things > (including possibly the alert-mode function of the draft in question). > Maybe somebody already suggested this, and it just now percolated > through my brain, so I apologize if I'm failing to credit this idea > correctly. > > The problem with Alert-Info is that it's almost completely > unspecified. As I read it, 3261 says it takes a URL as a value, > without providing any way to negotiate (or confirm) the range of URLs > that might be meaningful to the UAS. Not good. > > Some implementations (aka Cisco) use totally bogus integers or > cadence-maps or other stuff in the Alert-Info header. Also not good. > > What if we were to define a series of URNs that refer to standardized > alert-behaviors? We could have registered URNS for: > > 1) Normal alert > 2) Distinctive alert (possibly indexed by an integer, for different > distinctive alerts) > 3) Null alert (which provides for the alert-mode behavior from this > draft) > 4) One or more types of request-encoded alerts, like the Cisco > integers, where the encoded value is carried as a URN parameter set > 5) Emergency alert > > We could lump these into one URN set (namespace?) and associate a SIP > OPTION tag with support for the entire set of alerting behaviors. I > think of this as "basic alerting options", and we could bound up the > whole set in one I-D. > > Thus, an INVITE request might carry something like: > > Alert-Info: urn:org.ietf.sip.alert.basic//emergency > Require: alert.basic > > or maybe: > > Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 > > or > > Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 > > > Then for "downloaded" alert sets (aka HTTP or other URLS) we could > potentially have additional URN sets, perhaps by URL type, or by > payload type, or some other combination. This could provide subject > material for additional IDs. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 27 11:59:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVA9m-0002Td-Iq; Thu, 27 Oct 2005 11:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVA9i-0002Sj-JP for sip@megatron.ietf.org; Thu, 27 Oct 2005 11:59:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01967 for ; Thu, 27 Oct 2005 11:58:49 -0400 (EDT) Received: from philipp.labs.nic.at ([83.136.32.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAN5-0006fw-5W for sip@ietf.org; Thu, 27 Oct 2005 12:12:56 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.50]) by philipp.labs.nic.at with esmtp (Exim 3.36 #1 (Debian)) id 1EVA8R-00060t-00; Thu, 27 Oct 2005 17:57:47 +0200 Message-ID: <4360F8FB.8010304@pernau.at> Date: Thu, 27 Oct 2005 17:57:47 +0200 From: Klaus Darilion User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] impractical keying requirement in sip identity draft References: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597015030A8@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Peterson, Jon wrote: > Juha, > > As has been pointed out on this mailing list before, this constraint > already exists in the core SIP standard. Specifically, in RFC3263. > (From 4.1) > > For NAPTR records with SIPS protocol fields, (if the server is using > a site certificate), the domain name in the query and the domain name > in the replacement field MUST both be valid based on the site > certificate handed out by the server in the TLS exchange. Hi Jon! And what is the practical solution for in-dialog requests and reponses which establish a new TLS connection (e.g. the initial TLS connection was terminated)? All SIP proxies I know put IP addresses into the Via and Record-Route headers. Thus, the proxy would also need a certificate with its IP address? regards Klaus > If you send a request to a URI of the form sips:user@sip.example.com, > then the certificate of the responding server (which is delivered via > TLS in the backwards domain) must be for valid the domain > 'sip.example.com'. This goes even for the sorts of hosting cases > where the DNS NAPTR/SRV records for sip.example.com point you to > siphosting.com, and siphosting.com is the server that actually > replies. In that instance, siphosting.com must hold a certificate > valid for 'sip.example.com'. > > For us to deviate from this principle for the sip-identity draft > really doesn't make sense, because the constraint already exists in > RFC3263. We've gone to some trouble to make sure that the authority > for a given domain from an identity perspective mirrors the authority > over the domain for inbound requests to the domain. > > Regarding your concern about how the hosting service would know what > hosted domain the user agent is requesting, since as you rightly > point out a TLS connection is formed before any SIP requests are > sent, the same problem exists of course for HTTP. Thus, the > caretakers of TLS wisely added a server name indication to the > extended client hello, which defined in RFC3546 Section 3.1. So, this > problem is addressed at the TLS layer. > > Jon Peterson NeuStar, Inc. > > >> -----Original Message----- From: sip-bounces@ietf.org >> [mailto:sip-bounces@ietf.org]On Behalf Of Juha Heinanen Sent: >> Monday, October 10, 2005 11:40 AM To: sip@ietf.org Subject: [Sip] >> impractical keying requirement in sip identity draft >> >> >> in my opinion, it is no practical to require that a company would >> supply private keying material regarding its domain to whoever >> party that happens to host its sip proxy service. that simply does >> not happen. >> >> if sip srv record of, say, cisco.com, points to sip.provider.com, >> then it must suffice that sip.provider.com uses its own keying >> material to sign the identity of cisco.com users. >> >> and even if sip.provider.com proxy would posses keying material of >> domain cisco.com, i don't understand how it could know which server >> certificate it should present to a sip ua when it establishes tls >> connection with the proxy, because that happens before the sip ua >> has sent any sip requests and because it is impractical to require >> that each domain would have its own ip address or port at the >> proxy. >> >> it may be that i'm missing something, but if not, it makes no sense >> for ietf to write specifications that cannot have real >> worldimplementations. >> >> -- 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 sip-bounces@ietf.org Thu Oct 27 12:29:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAdG-0002pr-Ry; Thu, 27 Oct 2005 12:29:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAdE-0002nS-FT for sip@megatron.ietf.org; Thu, 27 Oct 2005 12:29:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11975 for ; Thu, 27 Oct 2005 12:29:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAqc-0002Cg-Dk for sip@ietf.org; Thu, 27 Oct 2005 12:43:27 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2005 09:29:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9RGSdvB003504; Thu, 27 Oct 2005 09:29:22 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 12:29:11 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 12:29:11 -0400 Message-ID: <43610057.7000501@cisco.com> Date: Thu, 27 Oct 2005 12:29:11 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vaidya, Maulik" Subject: Re: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-an sweralert-01) References: <4B8DD52AB570D311BEDE0008C7E619880D076723@BOCA212A> In-Reply-To: <4B8DD52AB570D311BEDE0008C7E619880D076723@BOCA212A> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 16:29:11.0419 (UTC) FILETIME=[8FD994B0:01C5DB13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Vaidya, Maulik wrote: > Gents, pardon my ignorance if I say something really stupid > > Shouldn't 'semantic URNs' in some manner, shape or form include the format > of alert (i.e. wav, mp3 etc), and the preferred medium of download (i.e. > HTTP, WAP etc)? (because not all UACs will have the capability to support > all forms of alert tones and download mechanisms. In my mind, a *semantic* URN representing an alert would be something like: - normal alert - emergency alert - distintive alert N Then the receiving device would have complete freedom to render whatever it thinks is suitable to achieve that semantic. Most likely devices would be provisionable with a suitable value. There is no implication that the alert would be audio. It might be rendered using a "ringer" on a phone with traditional form factor, by playing a tune on a device with a speaker, by a flashing light on a device for a deaf user, and by a popup window on the screen of a PC running a softphone with audio disabled. Or it could be a combination of things. What you are describing isn't a URN at all, it is a URL that can be used to locate some representation to be rendered. That is ok too, but it isn't the same thing. Paul > -Maulik > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > dave.robbins@verizon.com > Sent: Thursday, October 27, 2005 10:08 AM > To: Paul Kyzivat > Cc: sip@ietf.org; MARJOU Xavier RD-MAPS-LAN; sip-bounces@ietf.org; > leo@cisco.com; Dean Willis > Subject: Re: [Sip] Alert-Info Idea (was Re: Commenton > draft-willis-sip-answeralert-01) > > Agreed. > > Defining URNs "semantically" is what I had in mind. In an application > carried over from the PSTN, distinctive alerting takes one of two different > forms, depending upon whether it is rendered as power ringing or as a > call-waiting alert tone. I would want to use a single URN, which the UAS > would render in whatever way is appropriate for the current state of the > device. Other semantic forms are surely useful as well. > > I can also see the potential value in having a URN that carries a specific > rendering. > > Dave Robbins > Verizon Laboratories > 40 Sylvan Rd. > Waltham, MA 02451-1128 > 781 466 4188 > > > > "Paul Kyzivat" > om> To > Dave C. > 10/27/2005 09:54 Robbins/EMPL/MA/Verizon@VZNotes > AM cc > "Dean Willis" > , > sip@ietf.org, "MARJOU Xavier > RD-MAPS-LAN" > , > sip-bounces@ietf.org, leo@cisco.com > Subject > Re: [Sip] Alert-Info Idea (was Re: > Comment on > draft-willis-sip-answeralert-01) > > > > > > > > > > > I think it would be good if there was a set of URNs that are defined > *semantically* rather than defining precisely what should be rendered. > These would be of much broader applicability than those that specify > particular audio waveforms, etc., because they could be rendered in a > variety of ways: audio, video, tactile, in different languages, etc. > > However there is probably value in having ones that have specific renderings > as well. > > There could also be scenarios where one entity (e.g. representing the > caller) inserts a URN that is semantic in nature, and another entity (e.g. > representing the callee) replaces that with a different URN (or > URI) that identifies a specific rendering that is consistent with the > intended semantic, the capabilities of the UAS, and the desires of the UAS > in terms of culturally specific values. > > Paul > > dave.robbins@verizon.com wrote: > >>I agree wholeheartedly with Dean. A URL is a nice, generic way to >>specify an alert signal, but unless you know what sort of URLs your >>client understands, it's not very useful. Some clients might >>understand a URL > > that > >>returns an audio file, but for other clients that might be totally > > useless. > >>A set of standardized URNs that includes the various alerting patterns >>typically used in traditional telephony applications would be of great >>interest to me and my work. This would include the standard North > > American > >>alerting patterns generically identified by the integers one through > > five, > >>perhaps expressed more generically in some manner. And I imagine that > > there > >>are other forms of alerting that could be accepted as standard. In my >>current work, we have had to invent a notation for this, and I've been >>suggesting that we think about promoting a standard of some sort. >> >>Dave Robbins >>Verizon Laboratories >>40 Sylvan Rd. >>Waltham, MA 02451-1128 >>781 466 4188 >> >> >> > > >> "Dean Willis" > > >> > >> armor.com> > > To > >> Sent by: "MARJOU Xavier RD-MAPS-LAN" > > >> sip-bounces@ietf. > > >> org > > cc > >> sip@ietf.org, leo@cisco.com > > > Subject > >> 10/26/2005 11:20 [Sip] Alert-Info Idea (was Re: > > >> PM Comment on > > >> >>draft-willis-sip-answeralert-01) > > > > > > > > >> >> >> >> >>On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote: >> >> >> >>>Hi, >>> >>>When reading Req-5 with "some sorts of emergency session", I >>>understand that an "emergency mass alert" is a candidate use-case. >>> >>>Thus, in section 6, I suggest a new value for the Alert-Mode header >>>field: "Amplified" so that as many people as possible are alerted >>>(e.g. >>>an amplified ring tone). In this case, a UAS could also decide to >>>increase the volume of audio. >>> >> >> >>I've been thinking about this, and working on some client specs, and >>I'm beginning to think that maybe the Alert-Info header might offer a >>better way to do this, as well as do a number of other things >>(including possibly the alert-mode function of the draft in question). >>Maybe somebody already suggested this, and it just now percolated >>through my brain, so I apologize if I'm failing to credit this idea >>correctly. >> >>The problem with Alert-Info is that it's almost completely >>unspecified. As I read it, 3261 says it takes a URL as a value, >>without providing any way to negotiate (or confirm) the range of URLs >>that might be meaningful to the UAS. Not good. >> >>Some implementations (aka Cisco) use totally bogus integers or >>cadence-maps or other stuff in the Alert-Info header. Also not good. >> >>What if we were to define a series of URNs that refer to standardized >>alert-behaviors? We could have registered URNS for: >> >>1) Normal alert >>2) Distinctive alert (possibly indexed by an integer, for different >>distinctive alerts) >>3) Null alert (which provides for the alert-mode behavior from this >>draft) >>4) One or more types of request-encoded alerts, like the Cisco >>integers, where the encoded value is carried as a URN parameter set >>5) Emergency alert >> >>We could lump these into one URN set (namespace?) and associate a SIP >>OPTION tag with support for the entire set of alerting behaviors. I >>think of this as "basic alerting options", and we could bound up the >>whole set in one I-D. >> >>Thus, an INVITE request might carry something like: >> >>Alert-Info: urn:org.ietf.sip.alert.basic//emergency >>Require: alert.basic >> >>or maybe: >> >>Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 >> >>or >> >>Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 >> >> >>Then for "downloaded" alert sets (aka HTTP or other URLS) we could >>potentially have additional URN sets, perhaps by URL type, or by >>payload type, or some other combination. This could provide subject >>material for additional IDs. >> >>-- >>Dean >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip >> >> >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip >> > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 27 23:05:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKYg-0000Nl-PF; Thu, 27 Oct 2005 23:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKYd-0000K6-DS; Thu, 27 Oct 2005 23:05:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14511; Thu, 27 Oct 2005 23:05:14 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVKm4-000550-6S; Thu, 27 Oct 2005 23:19:27 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9S3AUBU022513 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Oct 2005 22:10:32 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <26D463B9-2A8D-406B-8487-7C50ABEDC263@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org, sipping WG From: Dean Willis Date: Thu, 27 Oct 2005 22:05:18 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] Change to ABNF reference RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In case you didn't notice, the ABNF spec has been revised. We should now reference RFC 4234 instead of 2234. So if I try to send anything to the IESG that still references RFC 2234, somebody please stop me. -- 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 sip-bounces@ietf.org Thu Oct 27 23:37:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVL3F-0002ZX-0v; Thu, 27 Oct 2005 23:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVL3C-0002ZN-IH for sip@megatron.ietf.org; Thu, 27 Oct 2005 23:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16257 for ; Thu, 27 Oct 2005 23:36:50 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVLGh-0005zD-29 for sip@ietf.org; Thu, 27 Oct 2005 23:51:03 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9S3g9pc022648 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 27 Oct 2005 22:42:12 -0500 In-Reply-To: <4360D5FC.2020408@cisco.com> References: <4360D5FC.2020408@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) Date: Thu, 27 Oct 2005 22:36:56 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 27, 2005, at 8:28 AM, Paul Kyzivat wrote: > > >> We could lump these into one URN set (namespace?) and associate a >> SIP OPTION tag with support for the entire set of alerting >> behaviors. I think of this as "basic alerting options", and we >> could bound up the whole set in one I-D. >> > > In general, alerting is normally considered to ultimately be up to > the one doing the alerting. In most cases I would expect any > indication by the caller to be advisory. E.g. the callee may not > trust the caller, and/or may want to use some kind of distinctive > alerting it chooses to indicate who is calling. Ultimately, both > the caller and the callee may want to choose, and somebody has to win. > > The question then is: if the OPTION tag is there, should the > request be rejected if the Alert-Info value isn't understood, or if > it won't be honored? > SIP is actually very clear here -- accepting the request with a Requires: option tag says only that you understand the extension, not that you are committing to doing what it says for this call. > This is further complicated because I think there will be many > cases where intermediaries may want to insert an Alert-Info. For > instance, I know of one proposal for a proxy acting on behalf of > the callee to implement distinctive alerting by inserting an Alert- > Info header with a value chosen according to who the caller is. > Then the UAS only has to honor the Alert-Info, not figure out the > circumstances when distinctive alerting should apply. I guess the > usage for PoC would be simiar to this. In some sense things are > simpler if the Alert-Info is inserted by an agent operating on > behalf of the UAS, because it can perhaps be assumed to know what > the UAS is capable of processing. > Actually, I think that makes it not more complicated, but less. You act on the Alert-Info only to the extent that you trust the sender and forwarding elements to use it correctly -- kind of like not retrieving HTML links inside an unauthenticated email. I think this can be wrapped up with some tight security considerations. In an IMS-type environment, it would be reasonable to require the S- CSCF to strip off any foreign Alert-Info that it doesn't have reason to include. We can't say that in IETF, however, as we might well not have an S-CSCF. > >> Thus, an INVITE request might carry something like: >> Alert-Info: urn:org.ietf.sip.alert.basic//emergency >> Require: alert.basic >> or maybe: >> Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 >> or >> Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 >> Then for "downloaded" alert sets (aka HTTP or other URLS) we >> could potentially have additional URN sets, perhaps by URL type, >> or by payload type, or some other combination. This could provide >> subject material for additional IDs. >> > > I could pick at the details above, but now is not the time. Lets > get the basic concepts worked out first. > > I'm worried about conflicts between the desires of the caller and > callee, and also about the HERFP problem if we use Require. I think > these can be sidestepped IF we assume the caller never inserts > mandatory Alert-Info headers, and that A-I is generally only > inserted by an agent of the callee that can have been provisioned > to be aware of the UAS capabilities. Well, there's no way to tell WHO inserted an Alert-Info, is there? So, what happens if we have an Alert-Info extension set, with a corresponding Require? If the proxy forks it (I LOATHE forking), there's a chance that the request might be delivered to a node that doesn't grok the extension, and the resulting 4xx response might be HERFP-eaten by the proxy if it gets a "better" response from some other branch. So what? Either a "better" response goes back to the UAC (perhaps from a branch that understands the require), or it doesn't. Big loss. All that happens is that we don't get an error response back from a node we didn't want to talk to anyhow. We could certainly insert caveats about Require and HERFP in the draft. Oddly enough, the answer-mode/alert-mode draft I did for OMA suffers from exactly the same quirk, but nobody complained there. -- 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 sip-bounces@ietf.org Fri Oct 28 01:07:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMT5-00056L-DP; Fri, 28 Oct 2005 01:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMT2-0004rm-AN for sip@megatron.ietf.org; Fri, 28 Oct 2005 01:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20315 for ; Fri, 28 Oct 2005 01:07:35 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVMgV-0008NM-Qh for sip@ietf.org; Fri, 28 Oct 2005 01:21:50 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9S5Ctxn022964 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 28 Oct 2005 00:12:55 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Dean Willis Date: Fri, 28 Oct 2005 00:07:42 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt and ready to request publication? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We started WGLC on this draft last July, and it's been revved since in response to the comments in WGLC. Everybody happy with it now? -- 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 sip-bounces@ietf.org Fri Oct 28 01:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMta-00044u-OH; Fri, 28 Oct 2005 01:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMtX-000444-HV for sip@megatron.ietf.org; Fri, 28 Oct 2005 01:35:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22097 for ; Fri, 28 Oct 2005 01:34:58 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVN73-0000l8-9f for sip@ietf.org; Fri, 28 Oct 2005 01:49:13 -0400 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9S5eOfL023059 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 28 Oct 2005 00:40:24 -0500 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Dean Willis Date: Fri, 28 Oct 2005 00:35:12 -0500 X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] Revised agenda for SIP et IETF 64 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've posted a revised agenda at: http://www.softarmor.com/sipwg/meets/ietf64/agenda.html It's basically what we started with, with the exception that Kumiko's topic changed (since e2m is "done", but we still have worries about SPIT) and Jonathan says there's no need to talk about GRUU or target- dialog. -- 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 sip-bounces@ietf.org Fri Oct 28 02:09:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNQj-0000AO-P3; Fri, 28 Oct 2005 02:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNQh-00008K-Kl; Fri, 28 Oct 2005 02:09:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24071; Fri, 28 Oct 2005 02:09:12 -0400 (EDT) Received: from kwisrv3.kyocera-wireless.com ([206.169.67.193] helo=kwisrv3.kwi.intra.kyocera-wireless.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVNeA-0002Cp-4u; Fri, 28 Oct 2005 02:23:27 -0400 Received: by kwisrv3.kwi.intra.kyocera-wireless.com with Internet Mail Service (5.5.2653.19) id <47XM522D>; Fri, 28 Oct 2005 11:39:19 +0530 Message-ID: From: Digambar Rasal To: sip@ietf.org, sipping WG Date: Fri, 28 Oct 2005 11:39:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Sip] unification of wireless technologies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is there any group working on unification of the wireless technologies? My concern is about having a device that supports CDMA GSM WIFI-VOIP and similar wireless technology those allow to have some standard that allows roaming between these technologies. Regards Digambar Rasal Kyocera Wireless _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 02:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNkb-0002e7-Fd; Fri, 28 Oct 2005 02:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNkZ-0002bP-KQ for sip@megatron.ietf.org; Fri, 28 Oct 2005 02:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25271 for ; Fri, 28 Oct 2005 02:29:45 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVNy0-0002oZ-6k for sip@ietf.org; Fri, 28 Oct 2005 02:44:01 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IP200G014KX4J@siemenscomms.co.uk> for sip@ietf.org; Fri, 28 Oct 2005 07:26:57 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IP200F1S4KX5T@siemenscomms.co.uk>; Fri, 28 Oct 2005 07:26:57 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Oct 2005 07:29:28 +0100 Content-return: allowed Date: Fri, 28 Oct 2005 07:29:27 +0100 From: "Elwell, John" Subject: RE: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-an sweralert-01) To: Paul Kyzivat , "Vaidya, Maulik" Message-id: <50B1CBA96870A34799A506B2313F266706D1A4D6@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, > In my mind, a *semantic* URN representing an alert would be > something like: > - normal alert > - emergency alert > - distintive alert N > > Then the receiving device would have complete freedom to > render whatever > it thinks is suitable to achieve that semantic. Most likely devices > would be provisionable with a suitable value. > > There is no implication that the alert would be audio. It might be > rendered using a "ringer" on a phone with traditional form factor, by > playing a tune on a device with a speaker, by a flashing light on a > device for a deaf user, and by a popup window on the screen of a PC > running a softphone with audio disabled. Or it could be a > combination of > things. I quite like the idea of a "semantic" URN, and certainly if provided by the caller anything more than a "semantic" indication would be inappropriate (you probably don't want UK alert patterns when I call you). I would be curious to know more about the sort of values that a "semantic" URN would take. From your list above I can see that "emergency alert" might be useful, and "normal alert" for all non-special cases. But "distinctive alert N" does not really convey any semantics. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 03:24:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVObd-0008Ec-VP; Fri, 28 Oct 2005 03:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVObb-0008EU-7S for sip@megatron.ietf.org; Fri, 28 Oct 2005 03:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27559 for ; Fri, 28 Oct 2005 03:24:33 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVOp6-0004FI-Us for sip@ietf.org; Fri, 28 Oct 2005 03:38:50 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IP20060174XXD@siemenscomms.co.uk> for sip@ietf.org; Fri, 28 Oct 2005 08:22:09 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IP2003C474XFZ@siemenscomms.co.uk>; Fri, 28 Oct 2005 08:22:09 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Oct 2005 08:24:40 +0100 Content-return: allowed Date: Fri, 28 Oct 2005 08:24:39 +0100 From: "Elwell, John" Subject: RE: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) To: Dean Willis , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F266706D1A50D@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, > > > > The question then is: if the OPTION tag is there, should the > > request be rejected if the Alert-Info value isn't > understood, or if > > it won't be honored? > > > > SIP is actually very clear here -- accepting the request with a > Requires: option tag says only that you understand the > extension, not > that you are committing to doing what it says for this call. [JRE] This is already broken with 100rel. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 03:27:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOdp-0000Bq-Ae; Fri, 28 Oct 2005 03:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOdn-0000BA-1m; Fri, 28 Oct 2005 03:27:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27701; Fri, 28 Oct 2005 03:26:49 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVOrD-0004J2-H2; Fri, 28 Oct 2005 03:41:05 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id BBA6A205E0; Fri, 28 Oct 2005 12:43:51 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9F4D0205DA; Fri, 28 Oct 2005 12:43:51 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 12:56:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] unification of wireless technologies Date: Fri, 28 Oct 2005 12:56:17 +0530 Message-ID: Thread-Topic: [Sip] unification of wireless technologies Thread-Index: AcXbhpsSTJiNNU4ITHy5WEFqpa+IbgAB2XqQ To: , , X-OriginalArrivalTime: 28 Oct 2005 07:26:18.0156 (UTC) FILETIME=[E315D6C0:01C5DB90] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Digambar Rasal, I am not aware of any standards for all CDMA, GSM,WIFI-VOIP. For roaming in GSM and CDMA Networks with out changing the Existing GSM/IS-41 standards, Please refer GSM ANSI-41 Interoperability Team (GAIT) Standards. HTH, Sreeram. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Digambar Rasal Sent: Friday, October 28, 2005 11:39 AM To: sip@ietf.org; sipping WG Subject: [Sip] unification of wireless technologies=20 Is there any group working on unification of the wireless technologies?=20 My concern is about having a device that supports CDMA GSM WIFI-VOIP and similar wireless technology those allow to have some standard that allows roaming between these technologies. Regards Digambar Rasal Kyocera Wireless=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 06:21:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRMC-00060z-EU; Fri, 28 Oct 2005 06:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRM9-00060n-MZ for sip@megatron.ietf.org; Fri, 28 Oct 2005 06:21:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05704 for ; Fri, 28 Oct 2005 06:20:48 -0400 (EDT) From: grvijay.kumar@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRZc-0000Z2-7Q for sip@ietf.org; Fri, 28 Oct 2005 06:35:06 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 957BA205F6 for ; Fri, 28 Oct 2005 15:38:17 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 7BEFE205DC for ; Fri, 28 Oct 2005 15:38:17 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 15:50:43 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 28 Oct 2005 15:50:38 +0530 Message-ID: <897DA809E857CD40A8419CF517948E21012A1020@blr-k1-msg.wipro.com> Thread-Topic: Recommended /mandatory tests Thread-Index: AcXbqT2orgJ8cH6DRE+clj//raJZkg== To: X-OriginalArrivalTime: 28 Oct 2005 10:20:43.0969 (UTC) FILETIME=[41322B10:01C5DBA9] X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Sip] Recommended /mandatory tests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316107480==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0316107480== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DBA9.40B673DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DBA9.40B673DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all I have a query .In RFC 3398 i.e. SIP-T=20 It is RECOMMENDED that gateways implement functional equivalence with the call flows detailed in Section 7.1 and Section 8.1. Deviations from these flows are permissible in support of national ISUP variants, or any of the conservative policies recommended in Section 15. =20 =20 i.e. the scenario of getting ACM for every IAM triggered by INVITE.I feel it is Mandatory. Can any one tell that why it is quoted as RECOMMENDED instead of MANDATORY. regards Vijay ------_=_NextPart_001_01C5DBA9.40B673DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = all
I have a  = query .In RFC=20 3398 i.e. SIP-T

It is RECOMMENDED that gateways implement = functional=20 equivalence with

the call flows detailed in Section 7.1 = and Section=20 8.1. Deviations

from these flows are permissible in = support of=20 national ISUP

variants, or any of the conservative = policies=20 recommended in Section

15.

 

 

i.e. the=20 scenario of getting ACM for every IAM triggered by INVITE.I feel it is=20 Mandatory.

Can any one=20 tell that why it is quoted as RECOMMENDED instead of=20 MANDATORY.

regards
Vijay

------_=_NextPart_001_01C5DBA9.40B673DA-- --===============0316107480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0316107480==-- From sip-bounces@ietf.org Fri Oct 28 08:52:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTiJ-0004mT-Cb; Fri, 28 Oct 2005 08:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTiF-0004lE-L4 for sip@megatron.ietf.org; Fri, 28 Oct 2005 08:52:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12289 for ; Fri, 28 Oct 2005 08:51:45 -0400 (EDT) Received: from smtp10.clb.oleane.net ([213.56.31.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVTvl-0004Q7-M5 for sip@ietf.org; Fri, 28 Oct 2005 09:06:04 -0400 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp10.clb.oleane.net with ESMTP id j9SCpXOt014656 for ; Fri, 28 Oct 2005 14:51:36 +0200 Message-Id: <200510281251.j9SCpXOt014656@smtp10.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 28 Oct 2005 14:51:25 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXbvk0COLTtA4oiTLKvyWcnl43HZQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Sip] WiMAX Summit 2006 - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1417620947==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1417620947== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0161_01C5DBCF.12275D10" This is a multi-part message in MIME format. ------=_NextPart_000_0161_01C5DBCF.12275D10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The third edition of the WiMAX Summit 2006, the most important European event, will be held on February 21 to 24 at the Sofitel Bercy Hotel in Paris. The conference will largely be devoted to case studies presented by both incumbent and new entrant operators who have set up WiMAX infrastructures. All details at: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0161_01C5DBCF.12275D10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The third edition of the WiMAX Summit = 2006, the most important European event, will be held on February 21 to = 24 at the Sofitel Bercy Hotel in Paris.

The conference will largely be devoted to case studies presented by both incumbent and new entrant operators who have = set up WiMAX infrastructures.

 

All details at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

------=_NextPart_000_0161_01C5DBCF.12275D10-- --===============1417620947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1417620947==-- From sip-bounces@ietf.org Fri Oct 28 09:05:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTvR-0003ds-Gq; Fri, 28 Oct 2005 09:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTvQ-0003dn-0b for sip@megatron.ietf.org; Fri, 28 Oct 2005 09:05:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13185 for ; Fri, 28 Oct 2005 09:05:22 -0400 (EDT) Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVU8y-0004qQ-IP for sip@ietf.org; Fri, 28 Oct 2005 09:19:42 -0400 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id j9SD5Bba030135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2005 15:05:11 +0200 Received: from eeek.ingate.se (IDENT:7gYTNQYpptWSzMK0bI351Nq9s0HjTALh@localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.12.11/8.12.11) with ESMTP id j9SD58xd006028; Fri, 28 Oct 2005 15:05:09 +0200 Received: (from hasse@localhost) by eeek.ingate.se (8.12.11/8.12.11/Submit) id j9SD58Y4006027; Fri, 28 Oct 2005 15:05:08 +0200 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f From: Hans Persson To: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Message-Id: <1130504708.30501.17.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 28 Oct 2005 15:05:08 +0200 X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 28 Oct 2005 15:05:11 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Sip] A few nits on draft-ietf-sip-identity-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org tor 2005-10-27 klockan 00.50 skrev Internet-Drafts@ietf.org: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt A couple of nits on the -06 version: [Section 4] > When Bob's domain receives the request, it verifies the signature > provided in the Identity header, and thus can validates that the > domain indicated by the host portion of the AoR in the From header > field authenticated the user, and permitted them to assert that From > header field value. This same validation operation may be performed > by Bob's UAS. "validates" on line 2 should be "validate". [Section 9] > This document specifies two new SIP headers: Identity and Identity- > Info. Each of these headers can appear only once in a SIP message. > The grammar for these two headers is (following the ABNF [6] in s): > (following the ABNF [6] in RFC3261 [1]): Remove the entire first parenthesis. [Section 13.3] > Without TLS, the various header field values and the body of the > request will not have integrity protection with the request > arrives at an authentication service. Accordingly, a prior > legitimate or illegitimate intermediary could modify the message > arbitrarily. "with" on line 2 should be "when" (as it actually was in -05). [Section 13.4] > A verifier MUST evaluate the correspondence between the user's > identity and the signing certificate by following the procedures > defined in RFC 2818 [11] Section 3.1. While RFC2818 deals with the > use of HTTP in TLS, the procedures described are applicable to > verifying identity if one subtitutes the "hostname of the server" in > HTTP for the domain portion of the user's identity in the From header > field of a SIP request with an Identity header. "subtitutes" should be "substitutes". [Appendix D] > Changes from draft-ietf-sip-identity-06: This *is* -06. Also, a general note. The draft is very inconsistent about whether references should be written "RFCxxxx" or "RFC xxxx". Please decide on one format. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 09:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTyt-0006CT-0m; Fri, 28 Oct 2005 09:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTyr-000692-FD for sip@megatron.ietf.org; Fri, 28 Oct 2005 09:09:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13331 for ; Fri, 28 Oct 2005 09:08:55 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUCO-0004vt-SE for sip@ietf.org; Fri, 28 Oct 2005 09:23:15 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Oct 2005 06:09:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9SD7q9O019223; Fri, 28 Oct 2005 06:08:54 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 09:08:58 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 09:08:57 -0400 Message-ID: <436222E9.4000701@cisco.com> Date: Fri, 28 Oct 2005 09:08:57 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) References: <4360D5FC.2020408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 13:08:57.0691 (UTC) FILETIME=[C185EAB0:01C5DBC0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline Dean Willis wrote: > > On Oct 27, 2005, at 8:28 AM, Paul Kyzivat wrote: > >> >> >>> We could lump these into one URN set (namespace?) and associate a >>> SIP OPTION tag with support for the entire set of alerting >>> behaviors. I think of this as "basic alerting options", and we >>> could bound up the whole set in one I-D. >>> >> >> In general, alerting is normally considered to ultimately be up to >> the one doing the alerting. In most cases I would expect any >> indication by the caller to be advisory. E.g. the callee may not >> trust the caller, and/or may want to use some kind of distinctive >> alerting it chooses to indicate who is calling. Ultimately, both the >> caller and the callee may want to choose, and somebody has to win. >> >> The question then is: if the OPTION tag is there, should the request >> be rejected if the Alert-Info value isn't understood, or if it won't >> be honored? > > SIP is actually very clear here -- accepting the request with a > Requires: option tag says only that you understand the extension, not > that you are committing to doing what it says for this call. Yes, that was what I was thinking too. Which means that the option isn't good enough to ensure your chosen alert is rendered. But maybe it is good enough to know "it could have done it if it wanted to". >> This is further complicated because I think there will be many cases >> where intermediaries may want to insert an Alert-Info. For instance, >> I know of one proposal for a proxy acting on behalf of the callee to >> implement distinctive alerting by inserting an Alert- Info header with >> a value chosen according to who the caller is. Then the UAS only has >> to honor the Alert-Info, not figure out the circumstances when >> distinctive alerting should apply. I guess the usage for PoC would be >> simiar to this. In some sense things are simpler if the Alert-Info is >> inserted by an agent operating on behalf of the UAS, because it can >> perhaps be assumed to know what the UAS is capable of processing. >> > > Actually, I think that makes it not more complicated, but less. You act > on the Alert-Info only to the extent that you trust the sender and > forwarding elements to use it correctly -- kind of like not retrieving > HTML links inside an unauthenticated email. I think this can be > wrapped up with some tight security considerations. > > In an IMS-type environment, it would be reasonable to require the S- > CSCF to strip off any foreign Alert-Info that it doesn't have reason to > include. We can't say that in IETF, however, as we might well not have > an S-CSCF. Yes, things are simpler if we imagine this is the kind of environment when this feature is typically used. >>> Thus, an INVITE request might carry something like: >>> Alert-Info: urn:org.ietf.sip.alert.basic//emergency >>> Require: alert.basic >>> or maybe: >>> Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1 >>> or >>> Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5 >>> Then for "downloaded" alert sets (aka HTTP or other URLS) we could >>> potentially have additional URN sets, perhaps by URL type, or by >>> payload type, or some other combination. This could provide subject >>> material for additional IDs. >>> >> >> I could pick at the details above, but now is not the time. Lets get >> the basic concepts worked out first. >> >> I'm worried about conflicts between the desires of the caller and >> callee, and also about the HERFP problem if we use Require. I think >> these can be sidestepped IF we assume the caller never inserts >> mandatory Alert-Info headers, and that A-I is generally only inserted >> by an agent of the callee that can have been provisioned to be aware >> of the UAS capabilities. > > Well, there's no way to tell WHO inserted an Alert-Info, is there? > > So, what happens if we have an Alert-Info extension set, with a > corresponding Require? If the proxy forks it (I LOATHE forking), I don't loathe it the way you do. It presents some problems, but that is why they pay us the big bucks - to cope with the problems. :-) > there's a chance that the request might be delivered to a node that > doesn't grok the extension, and the resulting 4xx response might be > HERFP-eaten by the proxy if it gets a "better" response from some other > branch. > > So what? > > Either a "better" response goes back to the UAC (perhaps from a branch > that understands the require), or it doesn't. Big loss. All that > happens is that we don't get an error response back from a node we > didn't want to talk to anyhow. The problem is that there could be two UAs, one of which understands the A-I and another that doesn't. The one that supports the A-I isn't going to answer, because nobody is manning it. The one that doesn't support the A-I is ready and willing to answer. The caller wants to use the A-I, but will fall back to not using it if necessary. So the call is tried, and the UA that supports the A-I alerts for awhile using the chosen alert, but never answers. Eventually the caller gives up, and tries without the A-I. Now both UAs alert and the call is answered. Of course the answer here is to not put the Required header if you don't really require the feature. That is a reasonable in this scenario. I wonder if there are any scenarios where the Require is helpful? > We could certainly insert caveats about Require and HERFP in the draft. > Oddly enough, the answer-mode/alert-mode draft I did for OMA suffers > from exactly the same quirk, but nobody complained there. Probably because it applies in a narrow context. But I would have to go back and look at it again. 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 sip-bounces@ietf.org Fri Oct 28 09:21:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUAl-0005h8-88; Fri, 28 Oct 2005 09:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUAi-0005aT-Tx for sip@megatron.ietf.org; Fri, 28 Oct 2005 09:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14049 for ; Fri, 28 Oct 2005 09:21:11 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUOI-0005Jy-JZ for sip@ietf.org; Fri, 28 Oct 2005 09:35:30 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2005 06:21:19 -0700 X-IronPort-AV: i="3.97,263,1125903600"; d="scan'208"; a="224922362:sNHT29881882" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9SDKeVO016932; Fri, 28 Oct 2005 06:21:15 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 09:21:14 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 09:21:13 -0400 Message-ID: <436225C9.2060805@cisco.com> Date: Fri, 28 Oct 2005 09:21:13 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-an sweralert-01) References: <50B1CBA96870A34799A506B2313F266706D1A4D6@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266706D1A4D6@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 13:21:13.0671 (UTC) FILETIME=[78338D70:01C5DBC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > >>In my mind, a *semantic* URN representing an alert would be >>something like: >>- normal alert >>- emergency alert >>- distintive alert N >> >>Then the receiving device would have complete freedom to >>render whatever >>it thinks is suitable to achieve that semantic. Most likely devices >>would be provisionable with a suitable value. >> >>There is no implication that the alert would be audio. It might be >>rendered using a "ringer" on a phone with traditional form factor, by >>playing a tune on a device with a speaker, by a flashing light on a >>device for a deaf user, and by a popup window on the screen of a PC >>running a softphone with audio disabled. Or it could be a >>combination of >>things. > > > I quite like the idea of a "semantic" URN, and certainly if provided by the > caller anything more than a "semantic" indication would be inappropriate > (you probably don't want UK alert patterns when I call you). I would be > curious to know more about the sort of values that a "semantic" URN would > take. From your list above I can see that "emergency alert" might be useful, > and "normal alert" for all non-special cases. But "distinctive alert N" does > not really convey any semantics. I didn't put a lot of thought into that list. It is worth discussion. What I had in mind are things that have semantics corresponding to "features", such as the Telcordia ones, or the similar ones being worked on for TISPAN. Any feature that causes alerting could have a corresponding "semantic URN". "distinctive alert N" could perhaps have a better name, but I had in mind alignment with the traditional distinctive alerting feature. The idea would be that some agent working for the callee classifies incoming calls into one of several buckets, where each bucket is intended to receive a different kind of alerting. But the particular alert corresponding to each is left up to independent device provisioning. This just gives some "extra" names for buckets that don't have widely understood semantic intent - where the semantics are determined by someone doing provisioning for an individual AOR, who is not in a position to define new URN values. In some environments this would not be needed. When configuring such an agent for the callee, one might instead assign to the bucket an A-I URN or URL that identifies a specific rendering. Which to do depends on the capabilities of the system and the UAs. 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 sip-bounces@ietf.org Fri Oct 28 09:29:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUId-0001VS-H1; Fri, 28 Oct 2005 09:29:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUIb-0001Tp-Ch; Fri, 28 Oct 2005 09:29:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14346; Fri, 28 Oct 2005 09:29:19 -0400 (EDT) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUWA-0005VX-1E; Fri, 28 Oct 2005 09:43:39 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta01.csc.com (8.12.11/Switch-3.1.6) with ESMTP id j9SDTNYP027261; Fri, 28 Oct 2005 09:29:27 -0400 (EDT) In-Reply-To: Subject: Re: [Sip] unification of wireless technologies To: Digambar Rasal X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Fri, 28 Oct 2005 09:29:11 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/28/2005 09:29:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, sipping WG , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Some unification of GSM and WIFI Voice is being addressed in 3GPP, in the GERAN working group, under the name GAN (Generic Access Network). It was formerly called UMA (Unlicensed Mobile Access). Janet Digambar Rasal To Sent by: sip@ietf.org, sipping WG sip-bounces@ietf. org cc Subject 10/28/2005 02:09 [Sip] unification of wireless AM technologies Is there any group working on unification of the wireless technologies? My concern is about having a device that supports CDMA GSM WIFI-VOIP and similar wireless technology those allow to have some standard that allows roaming between these technologies. Regards Digambar Rasal Kyocera Wireless _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 09:54:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUge-00068k-OH; Fri, 28 Oct 2005 09:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUgd-00068e-5D for sip@megatron.ietf.org; Fri, 28 Oct 2005 09:54:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17878 for ; Fri, 28 Oct 2005 09:54:08 -0400 (EDT) Message-Id: <200510281354.JAA17878@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUu9-0006Rh-FH for sip@ietf.org; Fri, 28 Oct 2005 10:08:29 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVUgX-0004xl-8U; Fri, 28 Oct 2005 13:54:21 +0000 To: Hans Persson Subject: Re: [Sip] A few nits on draft-ietf-sip-identity-06.txt Date: Fri, 28 Oct 2005 06:54:21 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for the notes. A note to everyone - this document has been revised ONLY to handle the final IESG review. It is not open for discussion because it will get one last re-review check and then go to the RFC Editor queue. Thanks Allison Your friendly neighborhood Area Director _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 11:26:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW7F-0006Nv-P3; Fri, 28 Oct 2005 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW7D-0006Nl-EZ for sip@megatron.ietf.org; Fri, 28 Oct 2005 11:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24327 for ; Fri, 28 Oct 2005 11:25:42 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWKn-0000s1-7l for sip@ietf.org; Fri, 28 Oct 2005 11:40:02 -0400 Received: by wproxy.gmail.com with SMTP id i23so270633wra for ; Fri, 28 Oct 2005 08:25:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Yzc4AxIvDEjCj3W8wlVFxJs0d79IERpBPv607v4WiyQfDPS6i3VQ0+NKzSc2t/3uWxbR4GRmiCiwgOPfgEpwtCAalpHv5PM+4uCMLxeEtlUGnSew+Az7HtNu1kAgDEf9fDmPnlxgKepXie7yhKXjMqKcDuns7bzA8Npr9Xld+A8= Received: by 10.54.115.3 with SMTP id n3mr231820wrc; Fri, 28 Oct 2005 08:25:57 -0700 (PDT) Received: by 10.54.121.20 with HTTP; Fri, 28 Oct 2005 08:25:57 -0700 (PDT) Message-ID: Date: Fri, 28 Oct 2005 12:25:57 -0300 From: Mariano Stokle To: SIP , SIPPING MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 28 16:24:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVamD-0001l8-Jq; Fri, 28 Oct 2005 16:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVam9-0001dQ-Hw for sip@megatron.ietf.org; Fri, 28 Oct 2005 16:24:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15991 for ; Fri, 28 Oct 2005 16:24:15 -0400 (EDT) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVazl-0003X1-Ra for sip@ietf.org; Fri, 28 Oct 2005 16:38:39 -0400 X-IronPort-AV: i="3.97,263,1125892800"; d="scan'208"; a="21975757:sNHT38963376" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP session without SDP Date: Fri, 28 Oct 2005 16:24:27 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647017303F8@ATLANTIS.Brooktrout.com> Thread-Topic: [Sip] SIP session without SDP Thread-Index: AcXKevWS5/hAQHD4QsOk4BTiQZG3cwRQITzw From: "Eric Burger" To: "Paul Kyzivat" , "Christer Holmberg \(JO/LMF\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I actually do know of a situation where you would setup a call with no media: KPML. Let's say you want to establish a signaling-only session for transporting digits only. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, October 06, 2005 9:30 AM To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: Re: [Sip] SIP session without SDP Christer Holmberg (JO/LMF) wrote: > Hi, >=20 > Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an session description offer, the response (reliable) MUST contain an session description answer. >=20 > First, it is not said that the session description must be a SDP body, so I assume something else could be used too? >=20 > Second, assume that I want to set up a session without SDP (or, another type of session description)? If I include an empty Accept header (or an Accept header where application/sdp is not listed) I don't think the UAS should be mandated to include an SDP offer in the response. >=20 > So, I think the rules in 13.2.1 shall be applicable IF I am using a session description, but I should NOT be mandated to use session description. So you want to set up a session that has no description? Why would you=20 want to do that? That seems *so* wrong! The whole point of INVITE is to negotiate the=20 details of the session. Yes, you could use something else besides SDP - the obvious candidate is SDPng. But using none doesn't seem to fit the intent of INVITE. You can get much the effect you seem to be seeking simply by using SDP=20 that has no m=3D lines. 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 sip-bounces@ietf.org Fri Oct 28 16:51:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbCR-0000nw-ND; Fri, 28 Oct 2005 16:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbCQ-0000nS-1D for sip@megatron.ietf.org; Fri, 28 Oct 2005 16:51:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18615 for ; Fri, 28 Oct 2005 16:51:25 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbQ2-0004g1-EX for sip@ietf.org; Fri, 28 Oct 2005 17:05:47 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9SKuk2d026328 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 15:56:47 -0500 In-Reply-To: <436222E9.4000701@cisco.com> References: <4360D5FC.2020408@cisco.com> <436222E9.4000701@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E395D1C-4CA7-4AF4-9AAC-0BF3627B19CD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01) Date: Fri, 28 Oct 2005 15:51:33 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 28, 2005, at 8:08 AM, Paul Kyzivat wrote: > > > >> there's a chance that the request might be delivered to a node >> that doesn't grok the extension, and the resulting 4xx response >> might be HERFP-eaten by the proxy if it gets a "better" response >> from some other branch. >> So what? >> Either a "better" response goes back to the UAC (perhaps from a >> branch that understands the require), or it doesn't. Big loss. >> All that happens is that we don't get an error response back from >> a node we didn't want to talk to anyhow. >> > > The problem is that there could be two UAs, one of which > understands the A-I and another that doesn't. The one that supports > the A-I isn't going to answer, because nobody is manning it. The > one that doesn't support the A-I is ready and willing to answer. > > The caller wants to use the A-I, but will fall back to not using it > if necessary. > > So the call is tried, and the UA that supports the A-I alerts for > awhile using the chosen alert, but never answers. Eventually the > caller gives up, and tries without the A-I. Now both UAs alert and > the call is answered. > > Of course the answer here is to not put the Required header if you > don't really require the feature. That is a reasonable in this > scenario. I wonder if there are any scenarios where the Require is > helpful? > Exactly. If you don't actually require that the end point support the extension, don't insert a Require header for it. You can still offer the feature, and if it gets used, that's nice. If we use an Alert-Info header for the "don't bother the user because this is just an administrative loopback test call" function allowed for in draft-willis-answeralert, we get some mileage out of having a Require. Because we REALLY DON'T want the phone to ring and get picked up, resulting in a very confused user. We WANT the call to fail if the client doesn't support the extension. There are probably other cases, but as with most SIP extensions, sending a Require is generally the exception, not the rule. > >> We could certainly insert caveats about Require and HERFP in the >> draft. Oddly enough, the answer-mode/alert-mode draft I did for >> OMA suffers from exactly the same quirk, but nobody complained >> there. >> > > Probably because it applies in a narrow context. But I would have > to go back and look at it again. > Well, please go have another look at that draft, because they're about to start gestating cattle over in OMA for the lack of a solution to this problem. -- 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 sip-bounces@ietf.org Fri Oct 28 17:12:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbWn-0003Nd-Fr; Fri, 28 Oct 2005 17:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVbWk-0003NV-Me for sip@megatron.ietf.org; Fri, 28 Oct 2005 17:12:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20189 for ; Fri, 28 Oct 2005 17:12:26 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVbkN-0005OF-Gj for sip@ietf.org; Fri, 28 Oct 2005 17:26:48 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9SLHlMv026374 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 16:17:49 -0500 In-Reply-To: <50B1CBA96870A34799A506B2313F266706D1A50D@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266706D1A50D@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92A35CE1-EF8F-4560-94AC-CE5FE62D5BAE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) Date: Fri, 28 Oct 2005 16:12:35 -0500 To: "Elwell, John" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Paul Kyzivat , MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 28, 2005, at 2:24 AM, Elwell, John wrote: > Dean, > > >>> >>> The question then is: if the OPTION tag is there, should the >>> request be rejected if the Alert-Info value isn't >>> >> understood, or if >> >>> it won't be honored? >>> >>> >> >> SIP is actually very clear here -- accepting the request with a >> Requires: option tag says only that you understand the >> extension, not >> that you are committing to doing what it says for this call. >> > [JRE] This is already broken with 100rel. > Not at all. You could always fail the transaction. There's a difference between rejecting a request because you don't understand a specific extension and rejecting a request because your policy disallows acting on that extension for this specific request -- in one case you return a "bad extension" response, and in the other a "forbidden" with reason text explaining why it was forbidden ("403 I ain't doing preconditions with you, sucker!") It's like the difference between not supporting digest authentication, and not allowing a specific user to place a call. I suppose it would be fair to say that it is up to the specific extension to say one of: 1) If you accept a request but can't/won't honor the extension, the transaction proceeds with a potentially diminished or altered user experience. 2) If you accept a request but can't/wont honor the extension, then an error condition results. This is one of the differentiators for P-class extensions: they have to be in class 1 above. There are other differentiators, such as that P-headers are not allowed to have option tags, and they aren't required to be standards-track. Alert-Info definitely falls into class 1. You might receive an Alert- Info with the semantic "distinctive ring associated with your primary line service", but have a user-interface that recognizes that the call is from your fiance's phone and instead plays Mendelsohn's "Wedding March". This doesn't break the protocol. So the same phone might receive an Alert-Info with the semantic "Emergency" and instead play your configured emergency tone. In both cases your phone understands the Alert-Info header and would accept the request even with a Require:. -- 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 sip-bounces@ietf.org Fri Oct 28 18:02:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcIv-0000tI-CK; Fri, 28 Oct 2005 18:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcIr-0000qX-HB for sip@megatron.ietf.org; Fri, 28 Oct 2005 18:02:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22308 for ; Fri, 28 Oct 2005 18:02:08 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVcWV-0006ah-L4 for sip@ietf.org; Fri, 28 Oct 2005 18:16:32 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2005 15:02:09 -0700 X-IronPort-AV: i="3.97,263,1125903600"; d="scan'208"; a="670285833:sNHT2930599844" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9SM1G9e014163; Fri, 28 Oct 2005 15:02:06 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:01:24 -0400 Received: from [192.168.1.100] ([10.86.242.243]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:01:24 -0400 Message-ID: <43629FB3.7050307@cisco.com> Date: Fri, 28 Oct 2005 18:01:23 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] update to target-dialog References: <435B1F6D.1020800@cisco.com> <001801c5d81b$d65294a0$6402a8c0@BEMBUSTER> <435F078E.8030006@cisco.com> <002d01c5d9fd$328a60d0$6402a8c0@BEMBUSTER> In-Reply-To: <002d01c5d9fd$328a60d0$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 22:01:24.0488 (UTC) FILETIME=[234C4880:01C5DC0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Jonathan, > > I agree with your assesment. Syntax-wise Target-Dialog is a superset of > In-Reply-To, so I was thinking more in terms of Target-Dialog making > In-Reply-To obsolete (and not in terms of substituting TD with IRT). I'd rather not. I think they really have different semantics. > In > particular because I think the In-Reply-To use case (call back) could > use the authorization which TD provides (and matching on the entire > dialog-id instead of only the call-id IRT provides). Issue is then that > there is no 'current' dialog in that case. But they are menat for different consumption. Target-Dialog is really meant for automata to authorize a request based on security properties. In-Reply-To is really for rendering to a human, so they can know that this call was a consequence of a previous call attempt (which may have never even resulted in a dialog). > > However, your answer does clarify (for me at least) the design > intentions of TD, perhaps including some of this information in the > draft helps understandability I could add some text to clarify; I'd really rather do that in a rev that comes out after IETF LC... >> As such, I do not think that the In-Reply-To is a substitiute or >> appropriate vehicle for what we want to do with target-dialog. THe >> reasons are: >> >> 1. In-Reply-To references a past call originated by the recipient of >> In-Reply-To. Target-Dialog references a current dialog, and the >> direction of initiation is not relevant >> > > How strong is this "current dialog" requirement? Section 4 currently > states that when no match is found (i.e. no current dialog), the header > MUST be ignored. Well, as you say, the MUST requirement makes it clear that it is about the current dialog. > > For both example use-cases mentioned (application interaction and dialog > tracking), it seems that in case of no match the purpose of the request > is lost. I can see value in specifying that either: > 1) When no match is found, the request containing the TD header MUST be > replied to with an error response (e.g. 481 Dialog does not exist) 481 is not appropriate since there isnt yet a dialog. The point of ignoring the target-dialog is that you'd proceed as if the originator didn't know about the dialog, and let authorization happen by other means. In most cases, my assumption is that the request would not be authorized, and result in a 403. > 2) OR the sender can include a parameter / flag indicating its > preference in case of no-match (to allow for valid use cases with no > current dialog) I think the UAS has to decide what happens, not be dictated by UAC. > > I think in particular for the application interaction example this would > improve the user experience (e.g. when a URL to an interface is sent, > and that interface is no longer relevant when the call has ended). This > is related to the TD header but does go beyond the intended purpose of > authorization In most cases, the thing that is requested the interaction with the UA will know that the dialog has gone away.. > >> 2. In-Reply-To has just a call-id. We need an entire dialog ID. >> >> 3. In-Reply-To is meant for human consumption, Target-Dialog, for an >> automata. >> > > I would think that both are for automata, a user agent could use the IRT > call-id as index into its call-log and bring up more details on the call > (e.g. "You called this party on this and that date/time, there was no > answer") True, but its still ultimately to render something. Its a UI hint, no more. > >> 4. In-Reply-To implies cause and effect; i.e., this new request is >> BECAUSE of the request you sent me with this call-id. There is no >> cause and effect here, merely a reference for authorization purposes >> > > 5. There can be multiple In-Reply-To headers in a request (although that > has probably seen even less usage than the single header case) Well, there is no non-negative integer less than zero, so its the same either way ;) > >> >> So, though close, they're not the same. I'm not sure how important >> this is in the draft, since its more of a question of design choice >> and/or relationship with other similar headers. Nice FYI, but won't >> impact interop. >> > > I was triggered by the syntactic similarity, and then started wondering > about functional overlap. Based on this information I now believe that > they are disjunct in purpose; the only point left is whether there are > use cases (like call back) where authorization is desirable too, > although there is no "current" dialog. Is the "current" aspect > nescessary or perhaps too restrictive, and should TD applicability be > extended to work for non-current dialogs too? I would rather not. Target-dialog has a pretty specific scope, and expanding it to include the functions of In-Reply-To is not something I see a need to do. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Fri Oct 28 18:03:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcJS-0000zI-FE; Fri, 28 Oct 2005 18:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcJQ-0000zD-QK for sip@megatron.ietf.org; Fri, 28 Oct 2005 18:03:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22329 for ; Fri, 28 Oct 2005 18:02:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVcX4-0006b8-7q for sip@ietf.org; Fri, 28 Oct 2005 18:17:07 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2005 15:02:51 -0700 X-IronPort-AV: i="3.97,263,1125903600"; d="scan'208"; a="670286302:sNHT25514868" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9SM1k7o028840; Fri, 28 Oct 2005 15:02:48 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:02:43 -0400 Received: from [192.168.1.100] ([10.86.242.243]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:02:43 -0400 Message-ID: <4362A002.5040807@cisco.com> Date: Fri, 28 Oct 2005 18:02:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt and ready to request publication? References: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> In-Reply-To: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 22:02:43.0503 (UTC) FILETIME=[526503F0:01C5DC0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Wellll, I had hoped we're done, but there is a thread running (so far, just me and Jeroen van Bemmel) that does raise an open issue. Unless we can resolve on the list, we'll need time on the agenda after all, and we can't send to IESG until its resolved. Thanks, Jonathan R. Dean Willis wrote: > > We started WGLC on this draft last July, and it's been revved since in > response to the comments in WGLC. > > Everybody happy with it now? > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Fri Oct 28 18:12:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcS8-0003Ur-IE; Fri, 28 Oct 2005 18:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcS6-0003Ug-7g for sip@megatron.ietf.org; Fri, 28 Oct 2005 18:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22894 for ; Fri, 28 Oct 2005 18:11:41 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVcfk-0006tT-Jd for sip@ietf.org; Fri, 28 Oct 2005 18:26:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2005 15:11:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,263,1125903600"; d="scan'208"; a="14122983:sNHT21633526" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9SMBbEo011478; Fri, 28 Oct 2005 18:11:44 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:11:43 -0400 Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 18:11:42 -0400 Message-ID: <4362A21E.60703@cisco.com> Date: Fri, 28 Oct 2005 18:11:42 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] SIP session without SDP References: <330A23D8336C0346B5C1A5BB19666647017303F8@ATLANTIS.Brooktrout.com> In-Reply-To: <330A23D8336C0346B5C1A5BB19666647017303F8@ATLANTIS.Brooktrout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 22:11:42.0905 (UTC) FILETIME=[93E73A90:01C5DC0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Eric Burger wrote: > I actually do know of a situation where you would setup a call with no > media: KPML. > > Let's say you want to establish a signaling-only session for > transporting digits only. Am I missing something? If that is all you want to do, then simply send a subscription for the KPML event package. You don't need a media-less INVITE to do that. Paul > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, October 06, 2005 9:30 AM > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: [Sip] SIP session without SDP > > > > Christer Holmberg (JO/LMF) wrote: > >>Hi, >> >>Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an > > session description offer, the response (reliable) MUST contain an > session description answer. > >>First, it is not said that the session description must be a SDP body, > > so I assume something else could be used too? > >>Second, assume that I want to set up a session without SDP (or, > > another type of session description)? If I include an empty Accept > header (or an Accept header where application/sdp is not listed) I don't > think the UAS should be mandated to include an SDP offer in the > response. > >>So, I think the rules in 13.2.1 shall be applicable IF I am using a > > session description, but I should NOT be mandated to use session > description. > > So you want to set up a session that has no description? Why would you > want to do that? > > That seems *so* wrong! The whole point of INVITE is to negotiate the > details of the session. > > Yes, you could use something else besides SDP - the obvious candidate is > > SDPng. But using none doesn't seem to fit the intent of INVITE. > > You can get much the effect you seem to be seeking simply by using SDP > that has no m= lines. > > 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 sip-bounces@ietf.org Fri Oct 28 18:29:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcjU-0005Vv-Kb; Fri, 28 Oct 2005 18:29:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcjS-0005Vq-Id for sip@megatron.ietf.org; Fri, 28 Oct 2005 18:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23981 for ; Fri, 28 Oct 2005 18:29:37 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVcx6-0007Qp-3i for sip@ietf.org; Fri, 28 Oct 2005 18:44:01 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9SMYsWv026561 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 17:34:55 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 28 Oct 2005 17:29:41 -0500 To: Dean Willis X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] Another Revised agenda for SIP et IETF 64 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've posted yet another slightly a revised agenda at: http://www.softarmor.com/sipwg/meets/ietf64/agenda.html This revision adds (if time permits) a discussion led by David Schwarz of SAML for SPIT control at the end of session 1, and a discussion of route construction led by Jonathan Rosenberg at the end of session 2. -- 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 sip-bounces@ietf.org Fri Oct 28 18:41:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcux-0002kS-PP; Fri, 28 Oct 2005 18:41:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcuw-0002je-8u for sip@megatron.ietf.org; Fri, 28 Oct 2005 18:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24480 for ; Fri, 28 Oct 2005 18:41:29 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVd8a-0007i4-1s for sip@ietf.org; Fri, 28 Oct 2005 18:55:53 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9SMkmgb026606 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Oct 2005 17:46:49 -0500 In-Reply-To: <4362A002.5040807@cisco.com> References: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> <4362A002.5040807@cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83156929-BAA5-416D-9BD3-E75A222F7467@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt and ready to request publication? Date: Fri, 28 Oct 2005 17:41:34 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Joy. I've put a placeholder back into the agenda. Keep us posted please. -- Dean On Oct 28, 2005, at 5:02 PM, Jonathan Rosenberg wrote: > Wellll, I had hoped we're done, but there is a thread running (so > far, just me and Jeroen van Bemmel) that does raise an open issue. > Unless we can resolve on the list, we'll need time on the agenda > after all, and we can't send to IESG until its resolved. > > Thanks, > Jonathan R. > > Dean Willis wrote: > > >> We started WGLC on this draft last July, and it's been revved >> since in response to the comments in WGLC. >> Everybody happy with it now? -- 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 sip-bounces@ietf.org Fri Oct 28 19:45:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVdug-0005ga-6V; Fri, 28 Oct 2005 19:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVduc-0005gE-D1 for sip@megatron.ietf.org; Fri, 28 Oct 2005 19:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27388 for ; Fri, 28 Oct 2005 19:45:12 -0400 (EDT) Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVe8H-0000sG-Ih for sip@ietf.org; Fri, 28 Oct 2005 19:59:38 -0400 X-IronPort-AV: i="3.97,265,1125892800"; d="scan'208,217"; a="21979951:sNHT111365280" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Sip] SIP session without SDP Date: Fri, 28 Oct 2005 19:45:23 -0400 Message-ID: <330A23D8336C0346B5C1A5BB1966664762109F@ATLANTIS.Brooktrout.com> Thread-Topic: [Sip] SIP session without SDP Thread-Index: AcXcDKLy7lnJbbveQt6FMSWtfe4lXAADQfND From: "Eric Burger" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685004428==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0685004428== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DC19.AA2A023D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DC19.AA2A023D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable KPML needs a dialog to reference. I suppose the SUBSCRIBE creates a = dialog, but that is a bit weird.=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Fri Oct 28 18:12:08 2005 To: Eric Burger Cc: Christer Holmberg (JO/LMF); sip@ietf.org Subject: Re: [Sip] SIP session without SDP Eric Burger wrote: > I actually do know of a situation where you would setup a call with no > media: KPML. >=20 > Let's say you want to establish a signaling-only session for > transporting digits only. Am I missing something? If that is all you want to do, then simply send=20 a subscription for the KPML event package. You don't need a media-less=20 INVITE to do that. Paul > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, October 06, 2005 9:30 AM > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: [Sip] SIP session without SDP >=20 >=20 >=20 > Christer Holmberg (JO/LMF) wrote: >=20 >>Hi, >> >>Chapter 13.2.1 in RFC3261 says that, if the INVITE does not contain an >=20 > session description offer, the response (reliable) MUST contain an > session description answer. >=20 >>First, it is not said that the session description must be a SDP body, >=20 > so I assume something else could be used too? >=20 >>Second, assume that I want to set up a session without SDP (or, >=20 > another type of session description)? If I include an empty Accept > header (or an Accept header where application/sdp is not listed) I = don't > think the UAS should be mandated to include an SDP offer in the > response. >=20 >>So, I think the rules in 13.2.1 shall be applicable IF I am using a >=20 > session description, but I should NOT be mandated to use session > description. >=20 > So you want to set up a session that has no description? Why would you = > want to do that? >=20 > That seems *so* wrong! The whole point of INVITE is to negotiate the=20 > details of the session. >=20 > Yes, you could use something else besides SDP - the obvious candidate = is >=20 > SDPng. But using none doesn't seem to fit the intent of INVITE. >=20 > You can get much the effect you seem to be seeking simply by using SDP = > that has no m=3D lines. >=20 > Paul >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 ------_=_NextPart_001_01C5DC19.AA2A023D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Sip] SIP session without SDP

KPML needs a dialog to reference.  I suppose the = SUBSCRIBE creates a dialog, but that is a bit weird.

 -----Original Message-----
From:   Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent:   Fri Oct 28 18:12:08 2005
To:     Eric Burger
Cc:     Christer Holmberg (JO/LMF); sip@ietf.org
Subject:        Re: [Sip] SIP session = without SDP



Eric Burger wrote:
> I actually do know of a situation where you would setup a call with = no
> media: KPML.
>
> Let's say you want to establish a signaling-only session for
> transporting digits only.

Am I missing something? If that is all you want to do, then simply = send
a subscription for the KPML event package. You don't need a = media-less
INVITE to do that.

        Paul

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of
> Paul Kyzivat
> Sent: Thursday, October 06, 2005 9:30 AM
> To: Christer Holmberg (JO/LMF)
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIP session without SDP
>
>
>
> Christer Holmberg (JO/LMF) wrote:
>
>>Hi,
>>
>>Chapter 13.2.1 in RFC3261 says that, if the INVITE does not = contain an
>
> session description offer, the response  (reliable) MUST = contain an
> session description answer.
>
>>First, it is not said that the session description must be a SDP = body,
>
> so I assume something else could be used too?
>
>>Second, assume that I want to set up a session without SDP = (or,
>
> another type of session description)? If I include an empty = Accept
> header (or an Accept header where application/sdp is not listed) I = don't
> think the UAS should be mandated to include an SDP offer in the
> response.
>
>>So, I think the rules in 13.2.1 shall be applicable IF I am = using a
>
> session description, but I should NOT be mandated to use = session
> description.
>
> So you want to set up a session that has no description? Why would = you
> want to do that?
>
> That seems *so* wrong! The whole point of INVITE is to negotiate = the
> details of the session.
>
> Yes, you could use something else besides SDP - the obvious = candidate is
>
> SDPng. But using none doesn't seem to fit the intent of INVITE.
>
> You can get much the effect you seem to be seeking simply by using = SDP
> that has no m=3D lines.
>
>       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
>

------_=_NextPart_001_01C5DC19.AA2A023D-- --===============0685004428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0685004428==-- From sip-bounces@ietf.org Fri Oct 28 20:08:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVeH7-0007m1-Gr; Fri, 28 Oct 2005 20:08:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVeH4-0007ls-Qx for sip@megatron.ietf.org; Fri, 28 Oct 2005 20:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28269 for ; Fri, 28 Oct 2005 20:08:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVeUj-0001Os-C6 for sip@ietf.org; Fri, 28 Oct 2005 20:22:50 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2005 17:08:21 -0700 X-IronPort-AV: i="3.97,265,1125903600"; d="scan'208"; a="225121593:sNHT29743676900" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9T08JUw025700; Fri, 28 Oct 2005 17:08:19 -0700 (PDT) Received: from 10.82.241.157 ([10.82.241.157]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Oct 2005 00:08:51 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 28 Oct 2005 17:08:17 -0700 From: Cullen Jennings To: Rohan Mahy , Dean Willis , "Oscar Novo (JO/LMF)" Message-ID: Thread-Topic: Agenda requests, IETF 64 - draft-ietf-sip-outbound-01 Thread-Index: AcXcHNy1G2A6DEgQEdqAzwARJEEJ/A== In-Reply-To: <42184922.7030809@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "gonzalo.camarillo@ericsson.com" Subject: [Sip] Agenda requests, IETF 64 - draft-ietf-sip-outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen Jennings Outbound
20
draft-ietf-sip-outbound-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 29 01:30:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVjIe-0007GZ-Q7; Sat, 29 Oct 2005 01:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVjIc-0007GO-E1 for sip@megatron.ietf.org; Sat, 29 Oct 2005 01:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12106 for ; Sat, 29 Oct 2005 01:30:20 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVjWJ-0000B9-Op for sip@ietf.org; Sat, 29 Oct 2005 01:44:49 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Oct 2005 22:30:28 -0700 X-IronPort-AV: i="3.97,265,1125903600"; d="scan'208"; a="358331741:sNHT25203048" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9T5UQ94024972; Fri, 28 Oct 2005 22:30:26 -0700 (PDT) Received: from 10.82.216.110 ([10.82.216.110]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Oct 2005 05:30:57 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 28 Oct 2005 22:30:24 -0700 Subject: Re: [Sip] Are we ready to WGLC draft-ietf-sip-e2m-sec-01? From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Are we ready to WGLC draft-ietf-sip-e2m-sec-01? Thread-Index: AcXcSdx/GuElMkg9EdqLEAARJEEJ/A== In-Reply-To: <18417572-8A9E-4DE4-AB15-52EA84C4DC21@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 10/26/05 8:45 PM, "Dean Willis" wrote: > > At IETF 63 we said we expected to be able to WGLC the next draft > (which has been published). > > Kumiko tells me that there are currently no open issues to discuss at > IETF 64. > > The current draft passes idnits and looks superficially good to me. > > > Are we ready to WGLC this draft? yes > > What do we think about requesting some security-area review in > conjunction with WGLC? definitely needed > > -- > 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 sip-bounces@ietf.org Sat Oct 29 01:35:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVjN5-0008Ls-G0; Sat, 29 Oct 2005 01:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVjN3-0008Lj-CX for sip@megatron.ietf.org; Sat, 29 Oct 2005 01:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12279 for ; Sat, 29 Oct 2005 01:34:52 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVjah-0000HM-Ms for sip@ietf.org; Sat, 29 Oct 2005 01:49:21 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 28 Oct 2005 22:35:01 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9T5YvUw012960; Fri, 28 Oct 2005 22:34:58 -0700 (PDT) Received: from 10.82.216.110 ([10.82.216.110]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Oct 2005 05:35:29 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 28 Oct 2005 22:34:56 -0700 Subject: Re: [Sip] Another WGLC for draft-ietf-sip-gruu-06 From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Another WGLC for draft-ietf-sip-gruu-06 Thread-Index: AcXcSn6fvTRhIEg9EdqLEAARJEEJ/A== In-Reply-To: <001CD7EB-0799-4732-BDD4-6CF805CE4AA9@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org My 2 cents is ... This is an cutting it a bit too short on the WGLC given the rest of stuff happening and the importance of this document. It's been how many years? Anyways, I will be very happy to get this document finished. On 10/26/05 1:29 PM, "Dean Willis" wrote: > > You old-timers might remember that we originally working-group last > called GRUU during the summer of 2004. > > It's changed since then, just a bit. But I think we're getting pretty > close to "done", so I'd like to have a final round of review here > before we ship this puppy off to the IESG. > > Please re-read the draft and post any comments here and to the author > (jdrosen@cisco.com). > > I plan to conclude this review during the week of November 6, 2005, > so make sure you get your comments on the list BEFORE November 6. > > > > Now, here's a tidbit of news: The GRUU draft is our first to > participate in the RFC Editor's "early copy" experiment. The RFC > editor has already had a crack at the document and suggested some > changes to the author. Hopefully this will lead to faster passage > through the RFC Editor queue once the draft has passed IETF Last Call > and IESG Review. > > > -- > Dean Willis > SIP Co-Chair > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 29 16:34:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxPY-0006MB-Pc; Sat, 29 Oct 2005 16:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxPV-0006Ls-T5 for sip@megatron.ietf.org; Sat, 29 Oct 2005 16:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23413 for ; Sat, 29 Oct 2005 16:34:23 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVxdL-0006or-6g for sip@ietf.org; Sat, 29 Oct 2005 16:49:00 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9TKdhvS031957 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 29 Oct 2005 15:39:45 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A735ECF-EF03-4492-8DC1-666E79070230@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Sat, 29 Oct 2005 15:34:30 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've posted yet another slightly a revised agenda at: http://www.softarmor.com/sipwg/meets/ietf64/agenda.html This revision deletes the time slot for Feng Cao's response identity draft (which is still a useful reference but hasn't been revised since the last meeting), and adds a mini-discussion for Rohan's remote call control draft (by popular demand). I don't believe I've ever revised the SIP agenda more than twice before a meeting, and this is, I think, the 22nd SIP meeting that I've done the agenda for. Not that I mind (having a good agenda is Really Important), but I'm kind of curious as to why the churn. Perhaps it is related to the rechartering effort. -- 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 sip-bounces@ietf.org Sun Oct 30 14:25:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIoY-0007A7-9A; Sun, 30 Oct 2005 14:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIoR-00077a-AU for sip@megatron.ietf.org; Sun, 30 Oct 2005 14:25:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09902 for ; Sun, 30 Oct 2005 14:25:30 -0500 (EST) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWEAh-00065J-U1 for sip@ietf.org; Sun, 30 Oct 2005 09:28:39 -0500 Received: (qmail 4292 invoked by uid 0); 30 Oct 2005 14:13:44 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 Oct 2005 14:13:44 -0000 Message-ID: <004201c5dd5c$1de14740$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Rohan Mahy" References: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> <4362A002.5040807@cisco.com> Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt andready to request publication? Date: Sun, 30 Oct 2005 15:13:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I just learned about the remote call control draft, which appears to be one of the first to be using Target-Dialog (its usage was introduced with the -02 version of the draft). Interestingly, the remote-cc-02 draft is not using it for authorization purposes (yet) as seems to be the main intention formulated in the target-dialog draft. Rather, it states that the Target-Dialog header MUST be used "to select the appropriate dialog from which to source the request". I would say that - based on the name of the header - this would be one of the most obvious usages of the header, but the target-dialog draft does not really discuss this aspect. This leads to some questions: 1) Is the way the remote cc draft is using the Target-Dialog header appropriate / desirable ? 2) If yes, should this be documented in the target-dialog draft? In particular, I think the target-dialog draft should then e.g. discuss which error response code is sent back when there is no match on the Target-Dialog. A '403 Unauthorised' would not seem appropriate in this case. Perhaps a new response code would need to be introduced Likewise, the remote cc draft could mention the authorization aspects of the Target-Dialog header as a security consideration (currently, it recommends Digest Authentication) Regards, jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "Dean Willis" Cc: Sent: Friday, October 28, 2005 11:02 PM Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt andready to request publication? > Wellll, I had hoped we're done, but there is a thread running (so far, > just me and Jeroen van Bemmel) that does raise an open issue. Unless we > can resolve on the list, we'll need time on the agenda after all, and we > can't send to IESG until its resolved. > > Thanks, > Jonathan R. > > Dean Willis wrote: > >> >> We started WGLC on this draft last July, and it's been revved since in >> response to the comments in WGLC. >> >> Everybody happy with it now? >> >> -- >> 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 >> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 sip-bounces@ietf.org Mon Oct 31 03:04:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUes-0007TL-Mg; Mon, 31 Oct 2005 03:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUeq-0007TA-0g; Mon, 31 Oct 2005 03:04:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18771; Mon, 31 Oct 2005 03:04:24 -0500 (EST) Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWUsx-00054y-QL; Mon, 31 Oct 2005 03:19:21 -0500 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 6A16F4970D; Mon, 31 Oct 2005 08:04:24 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 37BFF2EFBBD; Mon, 31 Oct 2005 08:04:24 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id 10451176FB; Mon, 31 Oct 2005 08:04:24 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id D4F7A578; Mon, 31 Oct 2005 08:04:23 +0000 (GMT) In-Reply-To: To: Mariano Stokle Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Mon, 31 Oct 2005 09:02:26 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 31/10/2005 09:02:35, Serialize complete at 31/10/2005 09:02:35 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: SIP , SIPPING , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't resist answering. If you are asking yourself whether SIP is appropriate for carrying another "signalling protocol" is like asking "can I use SIP to do something for me". Most, if not all, SIP implementations rely on the fact that some other protocol is being carried in a SIP body. SDP and the XML used for IM and presence are good examples of this. The SIP methods that could be used to convey these protocols, is obviously open for discussion, but I fear that it will be extremely difficult to come to real consensus on this. In the CSTA case, I would say that, depending on what you are doing, both methods could be appropriate. BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 31 03:08:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUi4-0008KO-DQ; Mon, 31 Oct 2005 03:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUi2-0008K4-IF for sip@megatron.ietf.org; Mon, 31 Oct 2005 03:08:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19242 for ; Mon, 31 Oct 2005 03:07:43 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWUw9-0005Hu-9V for sip@ietf.org; Mon, 31 Oct 2005 03:22:39 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IP700101SLYWF@siemenscomms.co.uk> for sip@ietf.org; Mon, 31 Oct 2005 07:54:01 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IP700M1OS52AO@siemenscomms.co.uk>; Mon, 31 Oct 2005 07:43:50 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Oct 2005 07:46:20 +0000 Content-return: allowed Date: Mon, 31 Oct 2005 07:46:17 +0000 From: "Elwell, John" Subject: RE: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) To: Dean Willis Message-id: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org, Paul Kyzivat , MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, While I accept this would be reasonable behaviour for alert-info case, I still disagree with your statement that "SIP is actually very clear here -- accepting the request with a Requires: option tag says only that you understand the extension, not that you are committing to doing what it says for this call." In section 3 of RFC 3262 it states: "The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel." So in this particular case you cannot accept the request but not honour the extension. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28 October 2005 22:13 > To: Elwell, John > Cc: Paul Kyzivat; sip@ietf.org; MARJOU Xavier RD-MAPS-LAN; > leo@cisco.com > Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on > draft-willis-sip-an sweralert-01) > > > On Oct 28, 2005, at 2:24 AM, Elwell, John wrote: > > > Dean, > > > > > >>> > >>> The question then is: if the OPTION tag is there, should the > >>> request be rejected if the Alert-Info value isn't > >>> > >> understood, or if > >> > >>> it won't be honored? > >>> > >>> > >> > >> SIP is actually very clear here -- accepting the request with a > >> Requires: option tag says only that you understand the > >> extension, not > >> that you are committing to doing what it says for this call. > >> > > [JRE] This is already broken with 100rel. > > > > Not at all. You could always fail the transaction. There's a > difference between rejecting a request because you don't > understand a > specific extension and rejecting a request because your policy > disallows acting on that extension for this specific request -- in > one case you return a "bad extension" response, and in the other a > "forbidden" with reason text explaining why it was forbidden ("403 I > ain't doing preconditions with you, sucker!") > > It's like the difference between not supporting digest > authentication, and not allowing a specific user to place a call. > > > I suppose it would be fair to say that it is up to the specific > extension to say one of: > > 1) If you accept a request but can't/won't honor the extension, the > transaction proceeds with a potentially diminished or altered user > experience. > 2) If you accept a request but can't/wont honor the extension, then > an error condition results. > > > This is one of the differentiators for P-class extensions: they have > to be in class 1 above. There are other differentiators, such as > that P-headers are not allowed to have option tags, and they aren't > required to be standards-track. > > > Alert-Info definitely falls into class 1. You might receive an Alert- > Info with the semantic "distinctive ring associated with your > primary > line service", but have a user-interface that recognizes that the > call is from your fiance's phone and instead plays Mendelsohn's > "Wedding March". This doesn't break the protocol. So the same phone > might receive an Alert-Info with the semantic "Emergency" and > instead > play your configured emergency tone. In both cases your phone > understands the Alert-Info header and would accept the request even > with a Require:. > > > -- > 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 sip-bounces@ietf.org Mon Oct 31 07:59:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZG8-0003iR-O1; Mon, 31 Oct 2005 07:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZG6-0003h2-C9; Mon, 31 Oct 2005 07:59:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05498; Mon, 31 Oct 2005 07:59:11 -0500 (EST) Received: from [210.4.139.137] (helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWZUF-0000yI-Ie; Mon, 31 Oct 2005 08:14:10 -0500 Received: from rautu.tutpro.com (smmsp@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9VCw9N5004286; Mon, 31 Oct 2005 14:59:11 +0200 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j9VBnQoK003443; Mon, 31 Oct 2005 13:49:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17254.1222.895384.777514@rautu.tutpro.com> Date: Mon, 31 Oct 2005 13:49:26 +0200 From: Juha Heinanen To: sip@ietf.org Subject: [Sipping] Re: [Sip] unification of wireless technologies In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: sipping WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Janet P Gunn writes: > Some unification of GSM and WIFI Voice is being addressed in 3GPP, in the > GERAN working group, under the name GAN (Generic Access Network). It was > formerly called UMA (Unlicensed Mobile Access). as far as i understand, gan/uma work is not based on ietf sip standards. it would be a good idea to show how roaming between different network technologies could be done using sip. i would assume that the gruu stuff together with replaces header, for example, would get us somewhere. perhaps where already exists call flow examples in some documents? -- 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 sip-bounces@ietf.org Mon Oct 31 08:35:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZoS-0006nX-Ub; Mon, 31 Oct 2005 08:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBNT-0008Qt-Tr for sip@megatron.ietf.org; Thu, 27 Oct 2005 13:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16619 for ; Thu, 27 Oct 2005 13:17:06 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBar-0004MB-QC for sip@ietf.org; Thu, 27 Oct 2005 13:31:15 -0400 Received: from [192.168.1.20] (bzq-219-232-31.pop.bezeqint.net [62.219.232.31]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j9RHH9W07226; Thu, 27 Oct 2005 10:17:10 -0700 In-Reply-To: <18417572-8A9E-4DE4-AB15-52EA84C4DC21@softarmor.com> References: <18417572-8A9E-4DE4-AB15-52EA84C4DC21@softarmor.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5171ff40d5c6342b1ea6f24a647f9cf2@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Thu, 27 Oct 2005 19:17:12 +0200 To: Dean Willis X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Oct 2005 08:34:58 -0500 Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: Are we ready to WGLC draft-ietf-sip-e2m-sec-01? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org yes On Oct 27, 2005, at 5:45, Dean Willis wrote: > > At IETF 63 we said we expected to be able to WGLC the next draft > (which has been published). > > Kumiko tells me that there are currently no open issues to discuss at > IETF 64. > > The current draft passes idnits and looks superficially good to me. > > > Are we ready to WGLC this draft? > > What do we think about requesting some security-area review in > conjunction with WGLC? > > -- > 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 sip-bounces@ietf.org Mon Oct 31 08:35:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZoV-0006p3-JD; Mon, 31 Oct 2005 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOot-0000e3-O7; Fri, 28 Oct 2005 03:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28582; Fri, 28 Oct 2005 03:38:17 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVP2P-0004iZ-Aj; Fri, 28 Oct 2005 03:52:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9S7YkmO024963; Fri, 28 Oct 2005 10:34:46 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 10:38:31 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 10:38:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] RE: [Sip] unification of wireless technologies Date: Fri, 28 Oct 2005 10:38:28 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D013D4A7B@esebe100.NOE.Nokia.com> Thread-Topic: [Sipping] RE: [Sip] unification of wireless technologies Thread-Index: AcXbhpsSTJiNNU4ITHy5WEFqpa+IbgAB2XqQAAESibA= To: , , , X-OriginalArrivalTime: 28 Oct 2005 07:38:31.0220 (UTC) FILETIME=[98068740:01C5DB92] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 31 Oct 2005 08:34:58 -0500 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is far off-topic for this list, but both 3GPP and 3GPP2 are defining mechanisms for roaming between GSM/WCDMA & WiFi (3GPP) and between CDMA & WiFi (3GPP2). There are some proprietary mechanisms for GSM & CDMA roaming. My assumption is that this is something that needs to be discussed in 3GPP/3GPP2, SIP shouldn't have to worry about layer 2 roaming. John >-----Original Message----- >From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]=20 >Sent: 28 October, 2005 10:26 >To: digambar@kyocera-wireless.com; sip@ietf.org; sipping@ietf.org >Subject: [Sipping] RE: [Sip] unification of wireless technologies=20 > >Hi Digambar Rasal, > >I am not aware of any standards for all CDMA, GSM,WIFI-VOIP. > >For roaming in GSM and CDMA Networks with out changing the Existing >GSM/IS-41 standards, >Please refer GSM ANSI-41 Interoperability Team (GAIT) Standards. > >HTH, >Sreeram. > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 >Behalf Of Digambar Rasal >Sent: Friday, October 28, 2005 11:39 AM >To: sip@ietf.org; sipping WG >Subject: [Sip] unification of wireless technologies=20 > >Is there any group working on unification of the wireless=20 >technologies?=20 >My concern is about having a device that supports CDMA GSM=20 >WIFI-VOIP and similar wireless technology those allow to have=20 >some standard that allows roaming between these technologies. > >Regards >Digambar Rasal >Kyocera Wireless=20 > > >_______________________________________________ >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=20 >Use sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 31 08:35:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZoX-0006rd-OO; Mon, 31 Oct 2005 08:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZca-0003PM-Pw for sip@megatron.ietf.org; Mon, 31 Oct 2005 08:22:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07331 for ; Mon, 31 Oct 2005 08:22:25 -0500 (EST) From: henry@sinnreich.net Message-Id: <200510311322.IAA07331@ietf.org> Received: from xmail.bluehost.com ([70.98.111.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWZql-0002R2-8M for sip@ietf.org; Mon, 31 Oct 2005 08:37:24 -0500 Received: (qmail 22085 invoked by uid 0); 31 Oct 2005 13:22:37 -0000 Received: from unknown (HELO box6.bluehost.com) (70.98.111.61) by xmail.bluehost.com with SMTP; 31 Oct 2005 13:22:37 -0000 Received: from c-24-1-136-53.hsd1.tx.comcast.net ([24.1.136.53] helo=1AB764895C324D3) by box6.bluehost.com with esmtp (Exim 4.52) id 1EWZcO-0001R7-3D; Mon, 31 Oct 2005 06:22:32 -0700 To: "'Juha Heinanen'" , Subject: RE: [Sipping] Re: [Sip] unification of wireless technologies Date: Mon, 31 Oct 2005 07:22:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <17254.1222.895384.777514@rautu.tutpro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXeGyecOm0RCnn1SNyn5+sBZpMhHAAAjUtg X-PopBeforeSMTPSenders: henry@sinnreich.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box6.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - sinnreich.net X-Spam-Score: 2.9 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Oct 2005 08:34:59 -0500 Cc: 'sipping WG' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > it would be a good idea to show how roaming between > different network technologies could be done using sip. Fortunately this has already started. Please see: http://www.ieee802.org/21/july05_meeting_docs/P802-21-D00-01.pdf See also the recent related work in the IETF. Thanks, Henry -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Monday, October 31, 2005 5:49 AM To: sip@ietf.org Cc: sipping WG Subject: [Sipping] Re: [Sip] unification of wireless technologies Janet P Gunn writes: > Some unification of GSM and WIFI Voice is being addressed in 3GPP, in the > GERAN working group, under the name GAN (Generic Access Network). It was > formerly called UMA (Unlicensed Mobile Access). as far as i understand, gan/uma work is not based on ietf sip standards. it would be a good idea to show how roaming between different network technologies could be done using sip. i would assume that the gruu stuff together with replaces header, for example, would get us somewhere. perhaps where already exists call flow examples in some documents? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 31 11:19:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcNP-0003vp-Tn; Mon, 31 Oct 2005 11:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcNK-0003sm-6f; Mon, 31 Oct 2005 11:19:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18122; Mon, 31 Oct 2005 11:18:50 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcbX-0004u2-BK; Mon, 31 Oct 2005 11:33:51 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 31 Oct 2005 11:18:56 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005103111185515091 ; Mon, 31 Oct 2005 11:18:55 -0500 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Mon, 31 Oct 2005 11:18:56 -0500 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 11:22:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Date: Mon, 31 Oct 2005 11:22:31 -0500 Message-Id: <2FE23D25B7292B489A217D1965CDA866089900@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Thread-Index: AcXd8n1jyJ/u4ZptTuuFU3yzamCe2AAQ2k5w From: "Roy, Radhika \(AEAD\)" To: "Frank Derks" , "Mariano Stokle" X-OriginalArrivalTime: 31 Oct 2005 16:22:46.0108 (UTC) FILETIME=[53D6C9C0:01C5DE37] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: SIP , sip-bounces@ietf.org, SIPPING X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The use of other protocols like SDP and others in SIP must NOT need to be generalized by making a technically "wrong" interpretation such as "carrying of other protocols." Technically write interpretation of using SDP and others in SIP is this: 1. SDP and other protocols "complement" the session initiation in SIP. 2. SIP must NOT be used just another "transport" protocol for carrying other protocols. 3. SIP must NOT be used to carry another protocol suits of "session establishment" protocols that contradict the very fundamentals for which SIP has been created as a standard. If anyone violates the above items, definitely, they are abusing SIP standards, and it must be stopped immediately. Any comments? Best regards, Radhika R. Roy SAIC -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank Derks Sent: Monday, October 31, 2005 3:02 AM To: Mariano Stokle Cc: SIP; SIPPING; sip-bounces@ietf.org Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't=20 resist answering.=20 If you are asking yourself whether SIP is appropriate for carrying another=20 "signalling=20 protocol" is like asking "can I use SIP to do something for me". Most, if=20 not all,=20 SIP implementations rely on the fact that some other protocol is being=20 carried in a SIP body. SDP and the XML used for IM and presence are good examples of this.=20 The SIP methods that could be used to convey these protocols, is obviously open for=20 discussion, but I fear that it will be extremely difficult to come to real consensus on=20 this. In the CSTA case, I would say that, depending on what you are doing, both methods=20 could be appropriate.=20 BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a=20 complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of=20 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle =20 Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 31 12:56:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdtd-0003FR-AA; Mon, 31 Oct 2005 12:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdtb-0003FB-Cz for sip@megatron.ietf.org; Mon, 31 Oct 2005 12:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23955 for ; Mon, 31 Oct 2005 12:56:14 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWe7o-0004Jx-H7 for sip@ietf.org; Mon, 31 Oct 2005 13:11:17 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j9VI1ZDo028328 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Oct 2005 12:01:36 -0600 In-Reply-To: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63EE41BB-CAC1-4778-BA16-75E0CA8BFA83@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) Date: Mon, 31 Oct 2005 11:56:22 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Paul Kyzivat , MARJOU Xavier RD-MAPS-LAN , leo@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Oct 31, 2005, at 1:46 AM, Elwell, John wrote: > Dean, > > While I accept this would be reasonable behaviour for alert-info > case, I > still disagree with your statement that "SIP is actually very clear > here -- > accepting the request with a Requires: option tag says only that you > understand the extension, not that you are committing to doing what > it says > for this call." > > In section 3 of RFC 3262 it states: "The UAS MUST send any non-100 > provisional response reliably if the initial request contained a > Require > header field with the option tag 100rel. If the UAS is unwilling to > do so, > it MUST reject the initial request with a 420 (Bad Extension) and > include an > Unsupported header field containing the option tag 100rel." So in this > particular case you cannot accept the request but not honour the > extension. > Specific extensions can indicate that the request should be failed with an error response (and specify he response) although I question the wisdom of rejecting a request with a 420 after having indicated support for that extension in a Supported header. But I'm willing to concede that the documentation is unclear, given the wording in the example. 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 sip-bounces@ietf.org Mon Oct 31 16:55:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhcn-0004cN-V1; Mon, 31 Oct 2005 16:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhcl-0004bn-7J; Mon, 31 Oct 2005 16:55:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13190; Mon, 31 Oct 2005 16:55:07 -0500 (EST) From: Bjorn.Hjelm@alltel.com Received: from scarlitlx023.alltel.com ([198.133.100.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhr0-00024f-98; Mon, 31 Oct 2005 17:10:11 -0500 Received: from scarlitlx024.alltel.com (scarlitlx024.alltel.com [10.33.8.73]) by scarlitlx023.alltel.com (8.12.8/8.12.8) with ESMTP id j9VLtFUW009763; Mon, 31 Oct 2005 15:55:16 -0600 Received: from scarlitnt642.alltel.com (scarlitnt642.alltel.com [10.33.8.30]) by scarlitlx024.alltel.com (8.12.10/8.12.10) with ESMTP id j9VLtElo016339; Mon, 31 Oct 2005 15:55:14 -0600 (envelope-from Bjorn.Hjelm@alltel.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] unification of wireless technologies Date: Mon, 31 Oct 2005 15:55:14 -0600 Message-ID: <1270D164D92D2C43A52B99673149BAC9B6A327@scarlitnt642.alltel.com> Thread-Topic: [Sip] unification of wireless technologies Thread-Index: AcXbhrRLE+OvgQshRJaRQ1w8NsbLGgChqyPA To: , , X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ddunn@kyocera-wireless.com, ddunn@ktrc-na.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Digambar, When you are referring to "unification," is your question related to the ability of the core network to authenticate a user and deliver a VoIP service independent of access technology or the ability for a device access multiple air interface technologies to support VoIP? BR, Bjorn -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Digambar Rasal Sent: Friday, October 28, 2005 1:09 AM To: sip@ietf.org; sipping WG Subject: [Sip] unification of wireless technologies=20 Is there any group working on unification of the wireless technologies?=20 My concern is about having a device that supports CDMA GSM WIFI-VOIP and similar wireless technology those allow to have some standard that allows roaming between these technologies. Regards Digambar Rasal Kyocera Wireless=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ***************************************************************************= *************** The information contained in this message, including attachments, may conta= in=20 privileged or confidential information that is intended to be delivered onl= y to the=20 person identified above. If you are not the intended recipient, or the pers= on=20 responsible for delivering this message to the intended recipient, ALLTEL r= equests=20 that you immediately notify the sender and asks that you do not read the me= ssage or its=20 attachments, and that you delete them without copying or sending them to an= yone else.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip