From sip-bounces@ietf.org Mon Oct 01 04:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGDf-0003KU-7X; Mon, 01 Oct 2007 04:01:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcGDd-0003DM-U9 for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 04:01:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGDd-0003A6-HR for sip@ietf.org; Mon, 01 Oct 2007 04:01:33 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGDc-0002gl-SW for sip@ietf.org; Mon, 01 Oct 2007 04:01:33 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l917wjq25763; Mon, 1 Oct 2007 07:58:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 1 Oct 2007 03:01:11 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> In-Reply-To: <46FBD4C0.30601@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgBIQKSdFHccVs4T+CDC6BkaU94DAC1x7VQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> From: "Brian Stucker" To: "Adam Roach" , "Mary Barnes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Thursday, September 27, 2007 11:05 AM > To: Barnes, Mary (RICH2:AR00) > Cc: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > On 9/27/07 10:22 AM, Mary Barnes wrote: > > And, here's another very old one: > > > >=20 > http://quimby.gnus.org/internet-drafts/draft-choudhuri-sip-info-digit- > > 00 > > .txt > > =20 >=20 > Aha! Thanks. I conflated "using application/dtmf" with=20 > "transporting DTMF in info", which is a somewhat broader=20 > category. My read is that Hadriel and Brian were promoting a=20 > specific solution (application/dtmf), which may well not be the case. No. It is not the case. Sorry, I didn't realize you were thinking I was promoting a specific INFO solution. I'm trying to figure out where the harm is being done here (read on) by sending them. >=20 > So, plodding down that path (and going through the old=20 > arguments regarding DTMF in INFO), I am reminded that Jiri=20 > had a draft proposing DTMF in INFO using MGCP; and Bert=20 > Culpepper mentions this same approach in a later draft. Don't forget Rohan mentioned a similar approach in a draft some time ago http://www.softarmor.com/wgdb/docs/draft-mahy-sipping-signaled-digits-00 .txt >=20 > But, going back to the discussion at hand: Brian and Hadriel=20 > seem to be specifically promoting carrying "appliction/dtmf"=20 > in INFO. Since I can only guess at their motiviations, I'll=20 > leave it to them to indicate whether an=20 > "application/vnd.nortelnetworks.digits" or "message/mgcp"=20 > approach would make them happy. Well, now that you bring up application/vnd.nortelnetworks.digits, it really should have been application/com.nortelnetworks.digits (that's bugged me for years)... We do 2833 as well, so I'm not arguing for the sake of our own ancient MIME type (nor endorsing it either). Let me be the very first to say that the existance of a draft, no matter how old, does not make something a good idea. However, just because something isn't popular doesn't make it wrong or harmful either. If people wish to deprecate something purely for asthetic reasons, I simply do not support such an argument. I believe the deprecation of all uses of INFO OTHER than SIP-T is exactly for this reason. Why? Because we're allowing SIP-T. Ask yourself this question: if you are the terminator of a SIP-T call, what are your requirements as part of RFC-3372? Here they are for quick reference: "Terminator requirements: standard SIP processing, interpretation of encapsulated ISUP (for gateways only), support for multipart MIME, graceful handling of unknown MIME content (for non-gateways only)." Further (also from the RFC): "In case of an IP termination ..., the SIP UAS that receives SIP messages with encapsulated ISUP typically disregards the ISUP message. This does introduce a general requirement, however, that devices like SIP phones handle multipart MIME messages and unknown MIME types gracefully (this is a baseline SIP requirement, but also a place where vendors have been known to make shortcuts)." So if we're allowing SIP-T, which builds off of a baseline SIP requirement that if you get a MIME type or method (INFO) that you don't understand, that you gracefully handle this: send a 415/488 or send a 405, respectively, then why are we disallowing other uses of INFO that do not introduce ANY requirements beyond those of SIP-T which we are allowing? Here's another question for the readers: let's say Eric's draft becomes an RFC as written for sake of argument. What happens when a UA that does not support SIP-T gets a call from an ISUP gateway and gets an INFO with encapsulated ISUP in the message body? How does this processing differ from an endpoint getting encapsulated DTMF in a format it may not understand? It doesn't differ because it can't: the UA cannot differentiate between two different MIME types when it does not recognize either of them. I don't want a negotiation mechanism for INFO because I don't see a need for one. It's already there: 405, 415, and 488. If you don't support my MIME type, then my functionality is broken, not yours (unless you put my MIME type in your accept header). That's true of every MIME type in SIP other than SDP as part of an INVITE transaction as near as I can tell. If 405, 415, 488, allow, and accept are broken then let's fix that. Heck, the biggest usage (by volume) I see of INFO is for long-call audits where it carries absolutely no message body at all. How is this worse than sending an OPTIONS (which is allowed)? If someone can clearly address this argument and show how harm is being done and that RFC-3261 is not adequate to address this situation I'll shut up about deprecating INFO because then I think we'll have done three things: identified the real root cause of the problem, identified a problem in the baseline specification that needs to be fixed, and written a set of guidelines that others can clearly see why they shouldn't use INFO beyond the reason that sending something to someone else that they may not understand is bad, which would be a much shorter draft and not limited to INFO at all. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 01 04:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGYR-0005dw-Co; Mon, 01 Oct 2007 04:23:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcGYP-0005dY-BT for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 04:23:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGYP-0005dQ-0W for sip@ietf.org; Mon, 01 Oct 2007 04:23:01 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGYO-0003GY-FR for sip@ietf.org; Mon, 01 Oct 2007 04:23:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l918KPq04419; Mon, 1 Oct 2007 08:20:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 1 Oct 2007 03:22:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371170F0691@zrc2hxm2.corp.nortel.com> In-Reply-To: <03a701c80117$81c8df80$6901a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgBPCGecnNuVHIeQcab2a3KOjxu8QCxR/tA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <03a701c80117$81c8df80$6901a8c0@china.huawei.com> From: "Brian Stucker" To: "Spencer Dawkins" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Thursday, September 27, 2007 10:03 AM > To: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > >> Eric's document basically takes the second approach,=20 > grandfathering=20 > >> all uses of INFO that are currently published in an RFC or=20 > an active=20 > >> internet-draft, and forbidding any others. The list is not=20 > long; I'll=20 > >> replicate it here: > >> > >> 1. RFC 3372 > >> > >> You want more than that, you really need packages. > > > > Expand that list to include application/dtmf and I think you'll=20 > > largely end the debate. >=20 > It would be a lovely thing for this debate to end. Perhaps we=20 > could refocus with that aim in mind. Since I'm Eric's=20 > instigator, I'm asking that we remember how we got here. Spencer, I'm not debating the problem, I'm trying to figure out what the underlying problem realy *IS* so it's addressed properly. I could care less about application/dtmf or application/vnd.nortelnetworks.digits or any of the other myriad MIME types that may get sent in an INFO. I suggested adding the MIME types as a way to get agreement from others, but it's not what I'm worried about at all. [SNIP] =20 > If we could focus on Eric's draft, which does not deprecate=20 > existing standards-track uses of INFO, that might get us to=20 > publication of a draft that would discourage additional uses=20 > of INFO, and provide the explanation for this, so that random=20 > RAI-area drafts (which aren't even in the SIP working group)=20 > stop including text that explains Why We Aren't Using INFO -=20 > text that may or may not reflect SIP working group consensus. It's the explanation and allowance of SIP-T that (for me) is causing the problem because it makes the document really unclear as to what the actual harm being done here is. It's not clear to me at all why INFO should be deprecated based upon the arugment that sending stuff to someone that they might not understand, when gracefully handling such is a baseline requirement of 3261 and SIP-T itself and is not at all limited to INFO. If this is the real problem that we're trying to address, then write a draft that says that sending things that you're not sure the other side will understand is a bad idea, here's why, and don't make one SIP method the whipping boy for an entirely different problem that can arise in any SIP method. The biggest use of INFO that I see (by volume) contains no message body at all. I tried to point this out earlier so it could be included in the draft but the messenger got shot instead. INFO gets used to detect if the dialog, and therefore the call, is still alive. In this usage it does not differ from sending an OPTIONS as a mid-dialog request which is allowed by RFC-3261. The draft makes no mention of this usage and does not address why this is harmful (as opposed to OPTIONS) as a result. If this is harmful, then sending an OPTIONS in mid-dialog is harmful too, we should deprecate that as well. If sending MIME types that you're not sure the other side understands is harmful, then we should always start out a call by sending an OPTIONS prior to the INVITE so that we can be sure that the MIME types we may include in a multi-part offer are understood. Let's put that in there too if unknown MIME types is the real problem to be solved. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 01 15:00:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcQMw-0002kd-Os; Mon, 01 Oct 2007 14:51:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcQMv-0002jS-Pu for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 14:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcQMv-0002jK-G1 for sip@ietf.org; Mon, 01 Oct 2007 14:51:49 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcQMu-0000lx-5b for sip@ietf.org; Mon, 01 Oct 2007 14:51:49 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l91IpKve076097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2007 13:51:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46FCF307.30402@alcatel-lucent.fr> References: <46FCF307.30402@alcatel-lucent.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2396C577-3C8D-4CC6-A481-9EB7205F0B95@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] RR-fix: open issue on transport protocol parameter Date: Mon, 1 Oct 2007 13:51:14 -0500 To: Thomas Froment X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 03:32:46 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: sip-bounces@ietf.org Actually, I don't think either of these proposals is the solution for this particular issue. Jiri hit it on the head - the problem with the scenario you describe was at P2 - it _really_ needed to record-route. There's already some text in 3261 that pushes in this direction and probably what we want to do is just make that more clear in this document. The essence is that if you are a proxy and you change the transport characteristics as you forward a message, you need to record-route. RjS On Sep 28, 2007, at 7:26 AM, Thomas Froment wrote: > Before issuing a new version, draft http://www.ietf.org/internet- > drafts/draft-ietf-sip-record-route-fix-00.txt still contains (at > least) one open issue deserving the WG attention: > > It is located in section "6. Usage of transport parameter", and > question is marked as "[Note: these two suggestions have to be > discussed]" at the end of this section. > > I will still try to summarize the problem: > This is related to a common practice in proxy implementors to > support double Record-Route AND put the transport protocol > parameters. This practice is acceptable as long as all SIP elements > that MAY be in the path of subsequent requests support that > transport. This "restriction" needs an explanation: let's imagine > you have two proxies "P1" and "P2" on the path of an initial > request. P1 is record-route and changes the transport from UDP to > SCTP because P2 URI resolves to SCTP transport applying [RFC3263], > and consequently decides to put two Record-Route, one with > P1;transport=UDP, another one with P1;transport=SCTP. The problem > arises if P2 is not record-route, because the next SIP element > after P2 will be asked to reach P1 using SCTP transport for any > subsequent request from callee, and this SIP element MAY NOT > support that transport. > > Today, two propositions have been identified to handle this situation: > > - The first solution is to add to section 4.1 "Selecting a > transport protocol" of [RFC3263] which states that "If the URI > specifies a transport protocol in the transport parameter, that > transport protocol SHOULD be used.", the following statement: "if > this protocol is not supported the procedures described in this > document SHOULD be > followed as if the transport parameter was not set on URI". > > - Another solution is to RECOMMEND to NOT put any transport > parameter on Record-Route URI if the transport is a a transport > protocol not mandated by RFC3261 (i.e. a transport different from > UDP, TCP or > TLS). > > > Are any of these propositions considered as acceptable? > preferences? better suggestions? any help is very welcome, > > Thomas > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 01 16:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRqp-0007mz-BH; Mon, 01 Oct 2007 16:26:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcRqo-0007mq-0d for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 16:26:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRqn-0007XL-Lh for sip@ietf.org; Mon, 01 Oct 2007 16:26:45 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcRqV-0004kK-RY for sip@ietf.org; Mon, 01 Oct 2007 16:26:28 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l91KQHIS019166; Mon, 1 Oct 2007 14:26:18 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 1 Oct 2007 14:26:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Allowed SIP Header Fileds Date: Mon, 1 Oct 2007 14:26:13 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C66D51BD@srvxchg3.cablelabs.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CA13790@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Allowed SIP Header Fileds Thread-Index: AcfrrIXz/SJoApuNQn213dJZCM+jLwACIpMgBixIkpA= References: <454C097A8CB3F14BB73494D0CE053DBE22A4E3@MCHP7I7A.ww002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CA13790@sea02-mxc01.citel.com> From: "Steve Dotson" To: "Michael Procter" , "Fries, Steffen" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Errors-To: sip-bounces@ietf.org Michael, thank you for the background. Is there any reason mutual authentication would not be desired for UA to = Proxy authentication (or is it assumed that all clients support = TLS/IPsec to allow the UA to authenticate the Proxy)? The = Proxy-Authentication-Info header also delivers nextnonce, which as I = understand, allows the UA to provide its challenge-response = pre-emptively on subsequent messages, in environments where = authentication of non-REGISTERs is performed. Nonce-count is still an = option, but if I want to use a fresh nonce for each authentication I = have to complete another round trip. Does anyone remember these details being discussed? Thanks. =20 Steve. -----Original Message----- From: Michael Procter [mailto:michael.procter@citel.com]=20 Sent: Friday, August 31, 2007 4:15 AM To: Fries, Steffen; sip@ietf.org Subject: RE: [Sip] Allowed SIP Header Fileds Hi Steffen, Proxy authentication on the client side is performed using the headers = 'Proxy-Authenticate' and 'Proxy-Authorization' in the same way as user = to-user authentication uses the headers 'WWW-Authenticate' and = 'Authorization'. The extra header 'Authentication-Info' is allowed by RFC3261 Section = 22.4, last paragraph: RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. Authentication is posFrom sip-bounces@ietf.org Mon Oct 01 16:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRqp-0007mz-BH; Mon, 01 Oct 2007 16:26:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcRqo-0007mq-0d for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 16:26:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRqn-0007XL-Lh for sip@ietf.org; Mon, 01 Oct 2007 16:26:45 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcRqV-0004kK-RY for sip@ietf.org; Mon, 01 Oct 2007 16:26:28 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l91KQHIS019166; Mon, 1 Oct 2007 14:26:18 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 1 Oct 2007 14:26:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Allowed SIP Header Fileds Date: Mon, 1 Oct 2007 14:26:13 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C66D51BD@srvxchg3.cablelabs.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CA13790@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Allowed SIP Header Fileds Thread-Index: AcfrrIXz/SJoApuNQn213dJZCM+jLwACIpMgBixIkpA= References: <454C097A8CB3F14BB73494D0CE053DBE22A4E3@MCHP7I7A.ww002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CA13790@sea02-mxc01.citel.com> From: "Steve Dotson" To: "Michael Procter" , "Fries, Steffen" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Errors-To: sip-bounces@ietf.org Michael, thank you for the background. Is there any reason mutual authentication would not be desired for UA to = Proxy authentication (or is it assumed that all clients support = TLS/IPsec to allow the UA to authenticate the Proxy)? The = Proxy-Authentication-Info header also delivers nextnonce, which as I = understand, allows the UA to provide its challenge-response = pre-emptively on subsequent messages, in environments where = authentication of non-REGISTERs is performed. Nonce-count is still an = option, but if I want to use a fresh nonce for each authentication I = have to complete another round trip. Does anyone remember these details being discussed? Thanks. =20 Steve. -----Original Message----- From: Michael Procter [mailto:michael.procter@citel.com]=20 Sent: Friday, August 31, 2007 4:15 AM To: Fries, Steffen; sip@ietf.org Subject: RE: [Sip] Allowed SIP Header Fileds Hi Steffen, Proxy authentication on the client side is performed using the headers = 'Proxy-Authenticate' and 'Proxy-Authorization' in the same way as user = to-user authentication uses the headers 'WWW-Authenticate' and = 'Authorization'. The extra header 'Authentication-Info' is allowed by RFC3261 Section = 22.4, last paragraph: RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. Authentication is possible with just the normal 2 headers. But other = benefits occur when using the third header (Authentication-Info) in the = user-to-user case, sufficient to make RFC3261 permit it. Presumably the = advantages were not sufficient for the comparable user-to-proxy case. Regards, Michael > -----Original Message----- > From: Fries, Steffen [mailto:steffen.fries@siemens.com] > Sent: 31 August 2007 09:54 > To: sip@ietf.org > Subject: [Sip] Allowed SIP Header Fileds >=20 > Hi, >=20 > just a question regarding the allowed SIP header field in RFC 3261. > The Table 2 in section 20 states the corresponding headers for WWW-=20 > Authenticate and Authentication-Info but it does only state Proxy-=20 > Authenticate. While RFC2617 stated the Proxy-Authentication-Info=20 > header, RFC3261 does not. What is the reason for the removal and how=20 > is the Proxy Authentication on client side (via digest authentication) = > to be done in this case? >=20 > Ciao > Steffen >=20 >=20 > > ------------------------------------------- > > Steffen Fries > > Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, 81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > email: Steffen.Fries@siemens.com > > ------------------------------------------- > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard=20 > Cromme; > Vorstand: Peter L=F6scher, Vorsitzender; Johannes Feldmayer, Heinrich=20 > Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, J=FCrgen=20 > Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus = > Wucherer Sitz der Gesellschaft: Berlin und M=FCnchen, > Registergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684 = > WEEE-Reg.-Nr. DE 23691322 > > ___________________________________________ > > > > >=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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 01 16:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRrK-0008DK-SY; Mon, 01 Oct 2007 16:27:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcRrI-0008Bu-Dm for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 16:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRrH-00089V-VT for sip@ietf.org; Mon, 01 Oct 2007 16:27:15 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcRrG-0002m7-LN for sip@ietf.org; Mon, 01 Oct 2007 16:27:15 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l91KQo8H081507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Oct 2007 15:26:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparsible with just the normal 2 headers. But other = benefits occur when using the third header (Authentication-Info) in the = user-to-user case, sufficient to make RFC3261 permit it. Presumably the = advantages were not sufficient for the comparable user-to-proxy case. Regards, Michael > -----Original Message----- > From: Fries, Steffen [mailto:steffen.fries@siemens.com] > Sent: 31 August 2007 09:54 > To: sip@ietf.org > Subject: [Sip] Allowed SIP Header Fileds >=20 > Hi, >=20 > just a question regarding the allowed SIP header field in RFC 3261. > The Table 2 in section 20 states the corresponding headers for WWW-=20 > Authenticate and Authentication-Info but it does only state Proxy-=20 > Authenticate. While RFC2617 stated the Proxy-Authentication-Info=20 > header, RFC3261 does not. What is the reason for the removal and how=20 > is the Proxy Authentication on client side (via digest authentication) = > to be done in this case? >=20 > Ciao > Steffen >=20 >=20 > > ------------------------------------------- > > Steffen Fries > > Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, 81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > email: Steffen.Fries@siemens.com > > ------------------------------------------- > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard=20 > Cromme; > Vorstand: Peter L=F6scher, Vorsitzender; Johannes Feldmayer, Heinrich=20 > Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, J=FCrgen=20 > Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus = > Wucherer Sitz der Gesellschaft: Berlin und M=FCnchen, > Registergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684 = > WEEE-Reg.-Nr. DE 23691322 > > ___________________________________________ > > > > >=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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 01 16:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRrK-0008DK-SY; Mon, 01 Oct 2007 16:27:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcRrI-0008Bu-Dm for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 16:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRrH-00089V-VT for sip@ietf.org; Mon, 01 Oct 2007 16:27:15 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcRrG-0002m7-LN for sip@ietf.org; Mon, 01 Oct 2007 16:27:15 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l91KQo8H081507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Oct 2007 15:26:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Mon, 1 Oct 2007 15:26:51 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 03:32:46 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] SIPit 21 registration closes Oct 29 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: , Errors-To: sip-bounces@ietf.org SIPit 21 will take place November 5 through 9, 2007 in Beijing, China. Registration will close October 29 (four weeks from now). If you haven't already registered, please reserve your seat now before the event fills up. This SIPit will be hosted by the BII Group and the Beijing University of Posts and Telecommunications. The registration fee is $575 US Dollars per participant. See http://www.sipit.net for more information and to register. See you in Beijing! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ks Date: Mon, 1 Oct 2007 15:26:51 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 03:32:46 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] SIPit 21 registration closes Oct 29 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: , Errors-To: sip-bounces@ietf.org SIPit 21 will take place November 5 through 9, 2007 in Beijing, China. Registration will close October 29 (four weeks from now). If you haven't already registered, please reserve your seat now before the event fills up. This SIPit will be hosted by the BII Group and the Beijing University of Posts and Telecommunications. The registration fee is $575 US Dollars per participant. See http://www.sipit.net for more information and to register. See you in Beijing! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 02 10:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj81-0000Qe-Ab; Tue, 02 Oct 2007 10:53:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icj7z-0000QX-Pd for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 10:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj7z-0000QP-G1 for sip@ietf.org; Tue, 02 Oct 2007 10:53:39 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icj7t-0003xM-Ac for sip@ietf.org; Tue, 02 Oct 2007 10:53:39 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id l92ErMg7022630; Tue, 2 Oct 2007 10:53:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 10:53:22 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E71882E7@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-subnot-etags-01 Thread-Index: AcgFA/pU2vifrS1MTgmul3R397na7g== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org Subject: [Sip] Review of draft-ietf-sip-subnot-etags-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: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-subnot-etags-01 Reviewer: Tolga Asveren [tasveren@sonusnet.com] Review Date: 2 October 2007 Review Deadline: Status: post-WGLC Summary: This draft is on the right track for publication and requires a few additions/clarifications before publication Detailed Comments: * 1.2 Terminology , definition of representation The definition of "representation" does not provide a definition. There are just some statements about "representation". I am not sure whether such a definition is necessary either. I would suggest deleting "representation" from this section. * 3. Overview of Operations, remembering entity-tags for all versions Why is it necessary for the notifier to remember all versions of an entity? To check entity-tags in SUBSCRIBEs to determine whether an update has happened, it just needs to know the entity-tag for the last version. To generate unique entity-tags, it can just use a counter with some extra information to deal with restart situations, e.g. some information extracted from current time.=20 * 5.2 Generating SUBSCRIBE requests, presence of multiple conditional headers I assume simultaneous presence of both "Suppress-Body-If-Match" and "Suppress-Notify-If-Match" is allowed. This could be useful for polling/resuming a previous subscription scenarios, where the subscriber isn't sure about the capabilities of the notifier. Mentioning about this possibility could be useful IMHO: "It should be noted that subscribers MAY include both Suppress-Body-If-Match and Suppress-Notify-If-Match conditional header fields together in a SUBSCRIBE request. This type of usage could be utilized for the cases where the subscriber is not sure about the suppressing capabilities of the notifier." I guess, we would also need to define what a notifier should do upon receipt of both headers: "If a notifier receives both Suppress-Notify-If-Match and Suppress-Body-If-Match headers, it SHOULD suppress the notification if the condition evaluates to true if it has this capability. Otherwise it SHOULD suppress the body of the notification if it has this capability. If the notifier can't do either of these, it simply SHOULD ignore these headers." * 5.4 Polling or Fetching Resource State, meta-information query What is a real life use case for meta-information query? What value would learning current entity-tag value provide from subscriber perspective? * 6.1 Generating Entity-tags "For example, one possible method is to implement the entity-tag as a simple counter, incrementing it by one for each generated notification per resource" I have a few questions regarding this sentence: i- Multiple notifications to different subscribers could be generated for the same state. I don't think all these should cause a new e-tag value. AFAICS, the rule for a new entity-tag is as follows: "If a notification is generated for the current state and if the state changes, a new entity-tag MUST be assigned".=20 ii- What about notifier restarts? It may be helpful to indicate about some differentiator between cycles, e.g. some information based on current time. I guess the crucial point is to make sure that the same entity-tag is not reused for two different versions because that may suppress necessary state notifications. It is still tolerable if the notifier -for whatever reason- uses two different entity-tags for the same version at two distinct times. Maybe a sentence could be added about this : "Subscribers MUST not assume that a notifier will always use the same entity-tag for a specific version. Especially after notifier restarts, this MAY not be the case." * Forking RFC3265 4.4.9 has the following: " If such behavior is not allowed, the first potential dialog-establishing message will create a dialog. All subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To", "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE can arrive after a matching NOTIFY has been received; such responses might not correlate to the same dialog established by the NOTIFY. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored. " It could make sense to amend this behavior. Consider the case, where the SUBSCRIBE forks and the first 200/NOTIFY arrives from a notifier which does not support suppressing and after a short while subscriber receives the NOTIFY from another notifier with an entity-tag. It could be preferable for the subscriber to terminate the first dialog and continue the second one. * Implicit Subscriptions, REFER I think this mechanism is applicable for implicit subscriptions as well. It could be an idea to mention this somewhere (maybe in 2.3. Requirements) To say a sentence or two about REFER initiated subscriptions could be useful as well. I guess it doesn't make much sense to use suppressing capability in this case: "Although technically it is possible to use notification/body suppressing capability for REFER initiated subscriptions, this is not seen as desirable considering the REFER use case." Nits: * 3. Overview of Operation, middle of the second paragraph ", and attaches includes it in a SIP-ETag"=20 Just use either "attaches" or "includes" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 02 12:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icktp-000368-V7; Tue, 02 Oct 2007 12:47:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icktp-000363-1V for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:47:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickto-00035v-O0 for sip@ietf.org; Tue, 02 Oct 2007 12:47:08 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ickti-00076E-Hx for sip@ietf.org; Tue, 02 Oct 2007 12:47:08 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l92Gksag026256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Oct 2007 11:46:56 -0500 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 2 Oct 2007 11:46:46 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > So if we're allowing SIP-T, which builds off of a baseline SIP > requirement that if you get a MIME type or method (INFO) that you > don't > understand, that you gracefully handle this: send a 415/488 or send a > 405, respectively, then why are we disallowing other uses of INFO that > do not introduce ANY requirements beyond those of SIP-T which we are > allowing? > This raises the argument that SIP-T should be revisited to more clearly negotiate support for the material being tunneled, including the context in which it is being tunneled. My UA might, for example, know how to render an ISUP message using a pretty-printer. That doesn't mean it knows how to do SIP-T for gateways. So, SIP-T is broken and likely to give surprising results. That is not a hearty argument for endorsing the technique of SIP-T for other functions. > Here's another question for the readers: let's say Eric's draft > becomes > an RFC as written for sake of argument. What happens when a UA that > does > not support SIP-T gets a call from an ISUP gateway and gets an INFO > with > encapsulated ISUP in the message body? How does this processing differ > from an endpoint getting encapsulated DTMF in a format it may not > understand? It doesn't differ because it can't: the UA cannot > differentiate between two different MIME types when it does not > recognize either of them. But assume the UA DOES recognize the MIME type. How does it know what to do with it? Is content-disposition adequate? If it were, why would we have the higher-level negotiation of event contexts? -- 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 02 12:50:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickw3-0005s7-CC; Tue, 02 Oct 2007 12:49:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ickw1-0005s2-Pq for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:49:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ickw1-0005rq-E9 for sip@ietf.org; Tue, 02 Oct 2007 12:49:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ickw1-0001S0-41 for sip@ietf.org; Tue, 02 Oct 2007 12:49:25 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l92GnKE7026260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Oct 2007 11:49:21 -0500 In-Reply-To: <2396C577-3C8D-4CC6-A481-9EB7205F0B95@nostrum.com> References: <46FCF307.30402@alcatel-lucent.fr> <2396C577-3C8D-4CC6-A481-9EB7205F0B95@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31E44296-C279-4D4C-8FF1-1F101FD64255@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RR-fix: open issue on transport protocol parameter Date: Tue, 2 Oct 2007 11:49:12 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: sip-bounces@ietf.org On Oct 1, 2007, at 1:51 PM, Robert Sparks wrote: > Actually, I don't think either of these proposals is the solution > for this particular issue. > > Jiri hit it on the head - the problem with the scenario you > describe was at P2 - it _really_ > needed to record-route. > > There's already some text in 3261 that pushes in this direction and > probably what we want > to do is just make that more clear in this document. The essence is > that if you are a proxy > and you change the transport characteristics as you forward a > message, you need to record-route. And not only that, the proxy either needs to double-record or do a reverse patch-up on responses. -- 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 02 13:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclct-0002Np-D2; Tue, 02 Oct 2007 13:33:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iclcr-0002Nd-Ow for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 13:33:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iclcr-0002NU-Ep for sip@ietf.org; Tue, 02 Oct 2007 13:33:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclbc-0006nA-4X for sip@ietf.org; Tue, 02 Oct 2007 13:32:24 -0400 Received: from new.madein.hu ([195.56.146.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iclbb-00035j-Cv for sip@ietf.org; Tue, 02 Oct 2007 13:32:24 -0400 Received: from new.madein.hu (madein [127.0.0.1]) by new.madein.hu (Postfix) with ESMTP id 6461A2FDA for ; Tue, 2 Oct 2007 19:32:22 +0200 (CEST) Received: by new.madein.hu (Postfix, from userid 103) id E7BE83470; Tue, 2 Oct 2007 19:32:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on madein X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [10.177.177.1] (dsl5400B3F8.pool.t-online.hu [84.0.179.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by new.madein.hu (Postfix) with ESMTP id CA90B2FDA for ; Tue, 2 Oct 2007 19:32:17 +0200 (CEST) Message-ID: <470280C2.3040907@madein.hu> Date: Tue, 02 Oct 2007 19:32:50 +0200 From: Mihaly Zachar User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-TMDA-Confirmed: Tue, 02 Oct 2007 13:33:41 -0400 Subject: [Sip] 302 question 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: , Errors-To: sip-bounces@ietf.org Hi all, I'm writing an UAS. The UAS has a feature, that if the called number is matching with a pattern, it will send 183 Session in progress, than plays an RTP stream and then redirect the UAC with 302 Moved Temporarily.. There is an UAC, and it's developers says that I should not send 302 Redirect after the 183 Session in progress. This solution works well with CISCO media gateways. I could not find the exact paraghaph about it in the RFC 3261. Can sy help me in this ? So, the call flow is the following: UAC UAS --- INVITE ---> <--- 100 ------ <--- 183 ------ <-- RTP -- . . . <--- 302 ---- Is this correct ? Thanks, Misi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 02 13:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclvs-0003pZ-T0; Tue, 02 Oct 2007 13:53:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iclvr-0003if-Ai for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 13:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclvr-0003MQ-0q for sip@ietf.org; Tue, 02 Oct 2007 13:53:19 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iclve-00013K-FK for sip@ietf.org; Tue, 02 Oct 2007 13:53:13 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007100217523501300habe5e>; Tue, 2 Oct 2007 17:52:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l92HqZ29029920 for ; Tue, 2 Oct 2007 13:52:35 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l92HqZAI029916; Tue, 2 Oct 2007 13:52:35 -0400 Date: Tue, 2 Oct 2007 13:52:35 -0400 Message-Id: <200710021752.l92HqZAI029916@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <470280C2.3040907@madein.hu> (zmihaly@madein.hu) Subject: Re: [Sip] 302 question References: <470280C2.3040907@madein.hu> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: sip-bounces@ietf.org From: Mihaly Zachar The UAS has a feature, that if the called number is matching with a pattern, it will send 183 Session in progress, than plays an RTP stream and then redirect the UAC with 302 Moved Temporarily.. There is an UAC, and it's developers says that I should not send 302 Redirect after the 183 Session in progress. I believe the developers are incorrect. In RFC 3261, section 13.1, top of page 78, we see: After some time, those UASs can accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. This text implies that a provisional response may precede a non-2xx final response. 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 Tue Oct 02 15:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcmsT-0007RP-CC; Tue, 02 Oct 2007 14:53:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcmsR-0007KK-7Q for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 14:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcmsQ-0007JZ-QX for sip@ietf.org; Tue, 02 Oct 2007 14:53:50 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcmsJ-0002iI-Lg for sip@ietf.org; Tue, 02 Oct 2007 14:53:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l92IoYp15866; Tue, 2 Oct 2007 18:50:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 2 Oct 2007 13:53:00 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371171B82F3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgFE+HbCJnzyrxSS62OHvLnNjT8GQAEJ1JA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 02, 2007 11:47 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Adam Roach; Barnes, Mary (RICH2:AR00); sip@ietf.org > Subject: Re: [Sip] INFO >=20 >=20 > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: >=20 > > > > So if we're allowing SIP-T, which builds off of a baseline SIP=20 > > requirement that if you get a MIME type or method (INFO) that you=20 > > don't understand, that you gracefully handle this: send a=20 > 415/488 or=20 > > send a 405, respectively, then why are we disallowing other uses of=20 > > INFO that do not introduce ANY requirements beyond those of SIP-T=20 > > which we are allowing? > > >=20 > This raises the argument that SIP-T should be revisited to=20 > more clearly negotiate support for the material being=20 > tunneled, including the context in which it is being=20 > tunneled. My UA might, for example, know how to render an=20 > ISUP message using a pretty-printer. That doesn't mean it=20 > knows how to do SIP-T for gateways. >=20 > So, SIP-T is broken and likely to give surprising results.=20 > That is not a hearty argument for endorsing the technique of=20 > SIP-T for other functions. Nor is it a hearty argument for clarifying what's wrong with INFO by allowing it. >=20 >=20 > > Here's another question for the readers: let's say Eric's draft=20 > > becomes an RFC as written for sake of argument. What=20 > happens when a UA=20 > > that does not support SIP-T gets a call from an ISUP=20 > gateway and gets=20 > > an INFO with encapsulated ISUP in the message body? How does this=20 > > processing differ from an endpoint getting encapsulated DTMF in a=20 > > format it may not understand? It doesn't differ because it=20 > can't: the=20 > > UA cannot differentiate between two different MIME types=20 > when it does=20 > > not recognize either of them. >=20 > But assume the UA DOES recognize the MIME type. How does it=20 > know what to do with it? Is content-disposition adequate? Depends on how it recognizes it to my mind. I recognize you when I see you, and I recognize my 5-month old son when I see him, but I don't need a sticky on your foreheads to tell me how I should interact with you.=20 If we're saying that everything about how a UA handles a MIME type has to be meticulously stipulated in the signaling, then I think there's a lot more out there that's broken than INFO. Basically, you wouldn't be able to introduce any MIME type into your signaling assuming that the other end will gracefully deal with it if it doesn't know what to do with it. How many MIME types are out there and how many of them have been specifically specified as to how SIP works with them? >=20 > If it were, why would we have the higher-level negotiation of=20 > event contexts? There's a lot more to events than specifying a MIME type. Do they have to be signaled distinctly in order to be useful? Should the accept header be deprecated? >=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 Tue Oct 02 15:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icn8N-0001Uf-Gf; Tue, 02 Oct 2007 15:10:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icn8L-0001Sr-V0 for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 15:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icn8L-0001Qj-HO; Tue, 02 Oct 2007 15:10:17 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icn8K-0003EK-ES; Tue, 02 Oct 2007 15:10:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3CE6226E8C; Tue, 2 Oct 2007 19:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Icn86-0001D6-21; Tue, 02 Oct 2007 15:10: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, 02 Oct 2007 15:10:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-00.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: , 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 : Requirements and Analysis of Media Security Key Management Protocols Author(s) : D. Wing, et al. Filename : draft-ietf-sip-media-security-requirements-00.txt Pages : 42 Date : 2007-09-28 A number of proposals have been published to address the need of securing media traffic. A summary of the proposals available at that time is available in the appendix of this document. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements. A comparison of the requirements against the individual proposals is provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-00.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-media-security-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-media-security-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-02150009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-media-security-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-media-security-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-02150009.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 02 16:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icntc-0007Zg-70; Tue, 02 Oct 2007 15:59:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icnta-0007Js-4y for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 15:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcntY-00068o-V2 for sip@ietf.org; Tue, 02 Oct 2007 15:59:05 -0400 Received: from e23smtp05.au.ibm.com ([202.81.18.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icnt1-0007al-0N for sip@ietf.org; Tue, 02 Oct 2007 15:58:31 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.18.234]) by e23smtp05.au.ibm.com (8.13.1/8.13.1) with ESMTP id l92JwRQo017868 for ; Wed, 3 Oct 2007 05:58:27 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l92JwQAR4620374 for ; Wed, 3 Oct 2007 05:58:26 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l92JtYg1014358 for ; Wed, 3 Oct 2007 05:55:34 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l92JtXla014040 for ; Wed, 3 Oct 2007 05:55:34 +1000 From: Xin Sheng Mao To: sip@ietf.org Message-ID: Date: Wed, 3 Oct 2007 04:06:15 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 10/03/2007 04:06:34 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Xin Sheng Mao/China/IBM is out of the 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: , Content-Type: multipart/mixed; boundary="===============1237725711==" Errors-To: sip-bounces@ietf.org --===============1237725711== Content-type: multipart/alternative; Boundary="0__=C7BBF9FBDFFDE9408f9e8a93df938690918cC7BBF9FBDFFDE940" Content-Disposition: inline --0__=C7BBF9FBDFFDE9408f9e8a93df938690918cC7BBF9FBDFFDE940 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 2007-09-30 and will not return until 2007-10-08. I am out of office in this week for biz trip... I will try to access emails and get back to you --0__=C7BBF9FBDFFDE9408f9e8a93df938690918cC7BBF9FBDFFDE940 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 2007-09-30 and will not return until 2007-10-08.

I am out of office in this week for biz trip... I will try to access emails and get back to you --0__=C7BBF9FBDFFDE9408f9e8a93df938690918cC7BBF9FBDFFDE940-- --===============1237725711== 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 --===============1237725711==-- From sip-bounces@ietf.org Tue Oct 02 17:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icpd4-0008NM-Gt; Tue, 02 Oct 2007 17:50:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icpd2-0008Bc-Kg for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 17:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icpd2-00080M-4V for sip@ietf.org; Tue, 02 Oct 2007 17:50:08 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icpcu-0006xO-SE for sip@ietf.org; Tue, 02 Oct 2007 17:50:06 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l92LnfI13036; Tue, 2 Oct 2007 21:49:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 2 Oct 2007 16:49:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> From: "Francois Audet" To: "Dean Willis" , "Brian Stucker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org I'm still completely baffled by why are we having this thread. INFO is used by ISUP tunnelling. It's there, we can leave it alone. As far as I know, nobody is trying to improve it. Legacy stuff. No RFC required here.=20 DTMF transport is a null issue since the last remaining laggars that didn't support RFC 2833 now support it. So it is going away and I really can't imagine that anybody would bring a draft to resurect it. No RFC required here. IETF is certainly not going to come up with new INFO usages. Everytime somebody shows up with an INFO idea, he's promptly turned away. So, what is the "problem" that we are trying to solve? Why are we wasting time on this? Can't we just declare victory and move on? > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 02, 2007 09:47 > To: Stucker, Brian (RICH1:AR00) > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] INFO >=20 >=20 > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: >=20 > > > > So if we're allowing SIP-T, which builds off of a baseline SIP=20 > > requirement that if you get a MIME type or method (INFO) that you=20 > > don't understand, that you gracefully handle this: send a=20 > 415/488 or=20 > > send a 405, respectively, then why are we disallowing other uses of=20 > > INFO that do not introduce ANY requirements beyond those of SIP-T=20 > > which we are allowing? > > >=20 > This raises the argument that SIP-T should be revisited to=20 > more clearly negotiate support for the material being=20 > tunneled, including the context in which it is being=20 > tunneled. My UA might, for example, know how to render an=20 > ISUP message using a pretty-printer. That doesn't mean it=20 > knows how to do SIP-T for gateways. >=20 > So, SIP-T is broken and likely to give surprising results.=20 > That is not a hearty argument for endorsing the technique of=20 > SIP-T for other functions. >=20 >=20 > > Here's another question for the readers: let's say Eric's draft=20 > > becomes an RFC as written for sake of argument. What=20 > happens when a UA=20 > > that does not support SIP-T gets a call from an ISUP=20 > gateway and gets=20 > > an INFO with encapsulated ISUP in the message body? How does this=20 > > processing differ from an endpoint getting encapsulated DTMF in a=20 > > format it may not understand? It doesn't differ because it=20 > can't: the=20 > > UA cannot differentiate between two different MIME types=20 > when it does=20 > > not recognize either of them. >=20 > But assume the UA DOES recognize the MIME type. How does it=20 > know what to do with it? Is content-disposition adequate? >=20 > If it were, why would we have the higher-level negotiation of=20 > event contexts? >=20 > -- > Dean >=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=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 Tue Oct 02 17:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcphH-0005IE-6M; Tue, 02 Oct 2007 17:54:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcphG-0005I6-7L for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 17:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcphF-0005Hy-U2 for sip@ietf.org; Tue, 02 Oct 2007 17:54:29 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcphE-00073f-Nm for sip@ietf.org; Tue, 02 Oct 2007 17:54:29 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l92LsCI13771; Tue, 2 Oct 2007 21:54:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 2 Oct 2007 16:54:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371171B88D1@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQAABxDJA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel! .com> From: "Brian Stucker" To: "Francois Audet" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org Exactly.=20 > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Tuesday, October 02, 2007 4:50 PM > To: Dean Willis; Stucker, Brian (RICH1:AR00) > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > Subject: RE: [Sip] INFO >=20 > I'm still completely baffled by why are we having this thread. >=20 > INFO is used by ISUP tunnelling. It's there, we can leave it=20 > alone. As far as I know, nobody is trying to improve it.=20 > Legacy stuff. No RFC required here.=20 >=20 > DTMF transport is a null issue since the last remaining=20 > laggars that didn't support RFC 2833 now support it. So it is=20 > going away and I really can't imagine that anybody would=20 > bring a draft to resurect it. No RFC required here. >=20 > IETF is certainly not going to come up with new INFO usages.=20 > Everytime somebody shows up with an INFO idea, he's promptly=20 > turned away. >=20 > So, what is the "problem" that we are trying to solve? Why=20 > are we wasting time on this? >=20 > Can't we just declare victory and move on? >=20 >=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, October 02, 2007 09:47 > > To: Stucker, Brian (RICH1:AR00) > > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > > Subject: Re: [Sip] INFO > >=20 > >=20 > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > >=20 > > > > > > So if we're allowing SIP-T, which builds off of a baseline SIP=20 > > > requirement that if you get a MIME type or method (INFO) that you=20 > > > don't understand, that you gracefully handle this: send a > > 415/488 or > > > send a 405, respectively, then why are we disallowing=20 > other uses of=20 > > > INFO that do not introduce ANY requirements beyond those of SIP-T=20 > > > which we are allowing? > > > > >=20 > > This raises the argument that SIP-T should be revisited to more=20 > > clearly negotiate support for the material being tunneled,=20 > including=20 > > the context in which it is being tunneled. My UA might, for=20 > example,=20 > > know how to render an ISUP message using a pretty-printer. That=20 > > doesn't mean it knows how to do SIP-T for gateways. > >=20 > > So, SIP-T is broken and likely to give surprising results.=20 > > That is not a hearty argument for endorsing the technique=20 > of SIP-T for=20 > > other functions. > >=20 > >=20 > > > Here's another question for the readers: let's say Eric's draft=20 > > > becomes an RFC as written for sake of argument. What > > happens when a UA > > > that does not support SIP-T gets a call from an ISUP > > gateway and gets > > > an INFO with encapsulated ISUP in the message body? How does this=20 > > > processing differ from an endpoint getting encapsulated DTMF in a=20 > > > format it may not understand? It doesn't differ because it > > can't: the > > > UA cannot differentiate between two different MIME types > > when it does > > > not recognize either of them. > >=20 > > But assume the UA DOES recognize the MIME type. How does it=20 > know what=20 > > to do with it? Is content-disposition adequate? > >=20 > > If it were, why would we have the higher-level negotiation of event=20 > > contexts? > >=20 > > -- > > Dean > >=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=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 Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lK-0006uO-Gh; Wed, 03 Oct 2007 05:43:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004KF-RC for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004K7-Hu for sip@ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclht-00058Y-BH for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iclhs-0000iv-5A for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: by nz-out-0506.google.com with SMTP id n1so2854612nzf for ; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=tv6KrzK5Udb6qdc57snQl2XbhYfuZQgoWlQNsB+zRZ0=; b=eXxSh+2IBWoceEXSiDUAkT7zBs1niBdrzlOWRlBms6xmSJ43pSGm/UGd10fuDqOT1HbU5CO9gngTE22T1L/qnmVTRqVQXGpqpm6c1Oyc7ObgJXQlFxIXhSA587AU3hL1sYb1VWkA9oj3n1C3xxJMM/GkBbgFwMrc9l5QSsbnWDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ODwh1NvNjwVhF+AQCTgha2AyYTjUIaGX/bz0Yb6vK7FvMJiQUwSVaK3OWd4LY+zHYMVWCIPLZVWThUOF5GBKlz59LTyly8bW9bv7GKvCzeQQDnVUC0iGFP9N11x934b4Gw0sdGSWvDVdQxItPkpVemPBuqeIHr8H/JU/188/AN4= Received: by 10.114.13.1 with SMTP id 1mr6792679wam.1191346719022; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) Received: by 10.114.81.3 with HTTP; Tue, 2 Oct 2007 10:38:38 -0700 (PDT) Message-ID: <7770aa0f0710021038n552fb38ew9bf47fa6fbb3c4d9@mail.gmail.com> Date: Tue, 2 Oct 2007 23:08:38 +0530 From: "Ravi S" To: sip@ietf.org, rohc@ietf.org In-Reply-To: <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> MIME-Version: 1.0 References: <7770aa0f0709232352u15a722f8w89c42dc8582968aa@mail.gmail.com> <7770aa0f0709232354q4c48f5d2i3938c6283bb148aa@mail.gmail.com> <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-TMDA-Confirmed: Tue, 02 Oct 2007 13:48:38 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: Subject: [Sip] sigcomp-id parameter creation at proxy 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="===============0291195997==" Errors-To: sip-bounces@ietf.org --===============0291195997== Content-Type: multipart/alternative; boundary="----=_Part_19039_20908077.1191346719021" ------=_Part_19039_20908077.1191346719021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows (Ofcourse, I know its Standards Track draft) . So I was not able to understand when a UE or Proxy creates the remote application identifier and adds sigcomp-id to SIP URI or Via header. Can anyone explain if my understanding is correct with respect to the following call flow. Both Alice & Bob belong to same proxy example.com. But Alice is not compliant to draft-ietf-rohc-sigcomp-sip (It will not create remote application identifier). 1. Alice registers with example.com. Now remote application identifier will not be available at example.com, hence the proxy willFrom sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lK-0006uO-Gh; Wed, 03 Oct 2007 05:43:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004KF-RC for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004K7-Hu for sip@ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclht-00058Y-BH for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iclhs-0000iv-5A for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: by nz-out-0506.google.com with SMTP id n1so2854612nzf for ; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=tv6KrzK5Udb6qdc57snQl2XbhYfuZQgoWlQNsB+zRZ0=; b=eXxSh+2IBWoceEXSiDUAkT7zBs1niBdrzlOWRlBms6xmSJ43pSGm/UGd10fuDqOT1HbU5CO9gngTE22T1L/qnmVTRqVQXGpqpm6c1Oyc7ObgJXQlFxIXhSA587AU3hL1sYb1VWkA9oj3n1C3xxJMM/GkBbgFwMrc9l5QSsbnWDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ODwh1NvNjwVhF+AQCTgha2AyYTjUIaGX/bz0Yb6vK7FvMJiQUwSVaK3OWd4LY+zHYMVWCIPLZVWThUOF5GBKlz59LTyly8bW9bv7GKvCzeQQDnVUC0iGFP9N11x934b4Gw0sdGSWvDVdQxItPkpVemPBuqeIHr8H/JU/188/AN4= Received: by 10.114.13.1 with SMTP id 1mr6792679wam.1191346719022; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) Received: by 10.114.81.3 with HTTP; Tue, 2 Oct 2007 10:38:38 -0700 (PDT) Message-ID: <7770aa0f0710021038n552fb38ew9bf47fa6fbb3c4d9@mail.gmail.com> Date: Tue, 2 Oct 2007 23:08:38 +0530 From: "Ravi S" To: sip@ietf.org, rohc@ietf.org In-Reply-To: <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> MIME-Version: 1.0 References: <7770aa0f0709232352u15a722f8w89c42dc8582968aa@mail.gmail.com> <7770aa0f0709232354q4c48f5d2i3938c6283bb148aa@mail.gmail.com> <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-TMDA-Confirmed: Tue, 02 Oct 2007 13:48:38 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: Subject: [Sip] sigcomp-id parameter creation at proxy 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="===============0291195997==" Errors-To: sip-bounces@ietf.org --===============0291195997== Content-Type: multipart/alternative; boundary="----=_Part_19039_20908077.1191346719021" ------=_Part_19039_20908077.1191346719021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows (Ofcourse, I know its Standards Track draft) . So I was not able to understand when a UE or Proxy creates the remote application identifier and adds sigcomp-id to SIP URI or Via header. Can anyone explain if my understanding is correct with respect to the following call flow. Both Alice & Bob belong to same proxy example.com. But Alice is not compliant to draft-ietf-rohc-sigcomp-sip (It will not create remote application identifier). 1. Alice registers with example.com. Now remote application identifier will not be available at example.com, hence the proxy willFrom sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lK-0006uO-Gh; Wed, 03 Oct 2007 05:43:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004KF-RC for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IclrK-0004K7-Hu for sip@ietf.org; Tue, 02 Oct 2007 13:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iclht-00058Y-BH for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iclhs-0000iv-5A for sip@ietf.org; Tue, 02 Oct 2007 13:38:53 -0400 Received: by nz-out-0506.google.com with SMTP id n1so2854612nzf for ; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=tv6KrzK5Udb6qdc57snQl2XbhYfuZQgoWlQNsB+zRZ0=; b=eXxSh+2IBWoceEXSiDUAkT7zBs1niBdrzlOWRlBms6xmSJ43pSGm/UGd10fuDqOT1HbU5CO9gngTE22T1L/qnmVTRqVQXGpqpm6c1Oyc7ObgJXQlFxIXhSA587AU3hL1sYb1VWkA9oj3n1C3xxJMM/GkBbgFwMrc9l5QSsbnWDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ODwh1NvNjwVhF+AQCTgha2AyYTjUIaGX/bz0Yb6vK7FvMJiQUwSVaK3OWd4LY+zHYMVWCIPLZVWThUOF5GBKlz59LTyly8bW9bv7GKvCzeQQDnVUC0iGFP9N11x934b4Gw0sdGSWvDVdQxItPkpVemPBuqeIHr8H/JU/188/AN4= Received: by 10.114.13.1 with SMTP id 1mr6792679wam.1191346719022; Tue, 02 Oct 2007 10:38:39 -0700 (PDT) Received: by 10.114.81.3 with HTTP; Tue, 2 Oct 2007 10:38:38 -0700 (PDT) Message-ID: <7770aa0f0710021038n552fb38ew9bf47fa6fbb3c4d9@mail.gmail.com> Date: Tue, 2 Oct 2007 23:08:38 +0530 From: "Ravi S" To: sip@ietf.org, rohc@ietf.org In-Reply-To: <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> MIME-Version: 1.0 References: <7770aa0f0709232352u15a722f8w89c42dc8582968aa@mail.gmail.com> <7770aa0f0709232354q4c48f5d2i3938c6283bb148aa@mail.gmail.com> <7770aa0f0709250647h1cba7ca2m4e4aac4985d9bfef@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-TMDA-Confirmed: Tue, 02 Oct 2007 13:48:38 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: Subject: [Sip] sigcomp-id parameter creation at proxy 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="===============0291195997==" Errors-To: sip-bounces@ietf.org --===============0291195997== Content-Type: multipart/alternative; boundary="----=_Part_19039_20908077.1191346719021" ------=_Part_19039_20908077.1191346719021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows (Ofcourse, I know its Standards Track draft) . So I was not able to understand when a UE or Proxy creates the remote application identifier and adds sigcomp-id to SIP URI or Via header. Can anyone explain if my understanding is correct with respect to the following call flow. Both Alice & Bob belong to same proxy example.com. But Alice is not compliant to draft-ietf-rohc-sigcomp-sip (It will not create remote application identifier). 1. Alice registers with example.com. Now remote application identifier will not be available at example.com, hence the proxy will create one based on the source IP and Port. How does the proxy ensure that the same sigcomp-id will be used for the next message from Alice? Will it always use source IP and Port as a remote application identifier? 2. Bob registers with example.com. It will carry a valid remote application identifier in sigcomp-id parameter of Via header and SIP URI of Contact header (Created by Bob). The proxy will use the same identifier. Is this correct? --Ravi -- Coming Soon: Signature 2.0 (Beta) ------=_Part_19039_20908077.1191346719021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows
(Ofcourse, I know its Standards Track draft) . So I was not able to understand
when a UE or Proxy creates the remote application identifier and adds
sigcomp-id to SIP URI or Via header.

Can anyone explain if my understanding is correct with respect to the following
call flow.

Both Alice & Bob belong to same proxy example.com . But Alice is not compliant
to draft-ietf-rohc-sigcomp-sip (It will not create remote application
identifier).

1. Alice registers with example.com.  Now remote application identifier will
   not be available at example.com, hence the proxy will create one based on
   the source IP and Port.  How does the proxy ensure that the same sigcomp-id
   will be used for the next message from Alice?  Will it always use source IP
   and Port as a remote application identifier?

2. Bob registers with example.com. It will carry a valid remote application
   identifier in sigcomp-id parameter of Via header and SIP URI of Contact
   header (Created by Bob).  The proxy will use the same identifier. Is this
   correct?

          --Ravi

--
Coming Soon: Signature 2.0 (Beta)

------=_Part_19039_20908077.1191346719021-- --===============0291195997== 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 --===============0291195997==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lJ-0006uF-Me; Wed, 03 Oct 2007 05:43:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRF-0007i9-12 for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 10:40:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRE-0007hW-Ne for sip@ietf.org; Mon, 01 Oct 2007 10:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMMk-0007gs-Nq for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcMMe-000357-Gw for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 15:35:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 15:32:48 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E024090491A5C9@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlato create one based on the source IP and Port. How does the proxy ensure that the same sigcomp-id will be used for the next message from Alice? Will it always use source IP and Port as a remote application identifier? 2. Bob registers with example.com. It will carry a valid remote application identifier in sigcomp-id parameter of Via header and SIP URI of Contact header (Created by Bob). The proxy will use the same identifier. Is this correct? --Ravi -- Coming Soon: Signature 2.0 (Beta) ------=_Part_19039_20908077.1191346719021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows
(Ofcourse, I know its Standards Track draft) . So I was not able to understand
when a UE or Proxy creates the remote application identifier and adds
sigcomp-id to SIP URI or Via header.

Can anyone explain if my understanding is correct with respect to the following
call flow.

Both Alice & Bob belong to same proxy example.com . But Alice is not compliant
to draft-ietf-rohc-sigcomp-sip (It will not create remote application
identifier).

1. Alice registers with example.com.  Now remote application identifier will
   not be available at example.com, hence the proxy will create one based on
   the source IP and Port.  How does the proxy ensure that the same sigcomp-id
   will be used for the next message from Alice?  Will it always use source IP
   and Port as a remote application identifier?

2. Bob registers with example.com. It will carry a valid remote application
   identifier in sigcomp-id parameter of Via header and SIP URI of Contact
   header (Created by Bob).  The proxy will use the same identifier. Is this
   correct?

          --Ravi

--
Coming Soon: Signature 2.0 (Beta)

------=_Part_19039_20908077.1191346719021-- --===============0291195997== 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 --===============0291195997==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lJ-0006uF-Me; Wed, 03 Oct 2007 05:43:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRF-0007i9-12 for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 10:40:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRE-0007hW-Ne for sip@ietf.org; Mon, 01 Oct 2007 10:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMMk-0007gs-Nq for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcMMe-000357-Gw for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 15:35:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 15:32:48 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E024090491A5C9@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlato create one based on the source IP and Port. How does the proxy ensure that the same sigcomp-id will be used for the next message from Alice? Will it always use source IP and Port as a remote application identifier? 2. Bob registers with example.com. It will carry a valid remote application identifier in sigcomp-id parameter of Via header and SIP URI of Contact header (Created by Bob). The proxy will use the same identifier. Is this correct? --Ravi -- Coming Soon: Signature 2.0 (Beta) ------=_Part_19039_20908077.1191346719021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The draft, draft-ietf-rohc-sigcomp-sip-08.txt does not have call flows
(Ofcourse, I know its Standards Track draft) . So I was not able to understand
when a UE or Proxy creates the remote application identifier and adds
sigcomp-id to SIP URI or Via header.

Can anyone explain if my understanding is correct with respect to the following
call flow.

Both Alice & Bob belong to same proxy example.com . But Alice is not compliant
to draft-ietf-rohc-sigcomp-sip (It will not create remote application
identifier).

1. Alice registers with example.com.  Now remote application identifier will
   not be available at example.com, hence the proxy will create one based on
   the source IP and Port.  How does the proxy ensure that the same sigcomp-id
   will be used for the next message from Alice?  Will it always use source IP
   and Port as a remote application identifier?

2. Bob registers with example.com. It will carry a valid remote application
   identifier in sigcomp-id parameter of Via header and SIP URI of Contact
   header (Created by Bob).  The proxy will use the same identifier. Is this
   correct?

          --Ravi

--
Coming Soon: Signature 2.0 (Beta)

------=_Part_19039_20908077.1191346719021-- --===============0291195997== 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 --===============0291195997==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lJ-0006uF-Me; Wed, 03 Oct 2007 05:43:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRF-0007i9-12 for sip-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 10:40:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IcMRE-0007hW-Ne for sip@ietf.org; Mon, 01 Oct 2007 10:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcMMk-0007gs-Nq for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcMMe-000357-Gw for sip@ietf.org; Mon, 01 Oct 2007 10:35:22 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 15:35:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Oct 2007 15:32:48 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E024090491A5C9@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on section 3.4 of draft-ietf-sip-outbound-10 Thread-Index: AcgEN/AARdQEFnfsTqKfQlhuHAk4qQ== From: "Jonathan Cumming" To: , X-OriginalArrivalTime: 01 Oct 2007 14:35:05.0625 (UTC) FILETIME=[42405090:01C80438] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-TMDA-Confirmed: Mon, 01 Oct 2007 10:40:00 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: SIP WG Subject: [Sip] Question on section 3.4 of draft-ietf-sip-outbound-10 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="===============0465269911==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0465269911== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80438.13CDB103" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen, Rohan, I am concerned about the value and practicality of section 3.4 of draft-ietf-sip-outbound-10, and would like to understand the reasoning behind the text "(and not a subsequent flow with the same addresses)", as this is not discussed in the mandatory text and this characteristic is not provided by the example flow token generation algorithm in section 5.2. In detail, section 3.4 states the following: "When the Edge Proxy receives a registration, it needs to create an identifier value that is unique to this flow (and not a subsequent flow with the same addresses) and put this identifier in the Path header URI." I presume that reason that subsequent connections between identical addresses are treated as different flows is that the remote address and port may have been reallocated to a different device. Therefore, after a connection failure, a request to the UA routed using the flow identifier could go to a different device. Is this text trying to protect against this unusual situation (which would be rejected by the UA), or is there a rather more practical reason for blurring the layers? Why should a recovered connection be viewed differently from a previous one, as long as the UA is still contactable over that flow? Many thanks, Jonathan ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on section 3.4 of draft-ietf-sip-outbound-10

Cullen, Rohan,

I am concerned about the value and = practicality of section 3.4 of draft-ietf-sip-outbound-10, and would = like to understand the reasoning behind the text "(and not a subsequent flow with the same = addresses)", as this is not = discussed in the mandatory text and this characteristic is not = provided by the example flow token = generation algorithm in section 5.2.

In detail, section 3.4 states the = following:

  "When the Edge
  r: Thread-Topic: Question on section 3.4 of draft-ietf-sip-outbound-10 Thread-Index: AcgEN/AARdQEFnfsTqKfQlhuHAk4qQ== From: "Jonathan Cumming" To: , X-OriginalArrivalTime: 01 Oct 2007 14:35:05.0625 (UTC) FILETIME=[42405090:01C80438] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-TMDA-Confirmed: Mon, 01 Oct 2007 10:40:00 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: SIP WG Subject: [Sip] Question on section 3.4 of draft-ietf-sip-outbound-10 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="===============0465269911==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0465269911== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80438.13CDB103" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen, Rohan, I am concerned about the value and practicality of section 3.4 of draft-ietf-sip-outbound-10, and would like to understand the reasoning behind the text "(and not a subsequent flow with the same addresses)", as this is not discussed in the mandatory text and this characteristic is not provided by the example flow token generation algorithm in section 5.2. In detail, section 3.4 states the following: "When the Edge Proxy receives a registration, it needs to create an identifier value that is unique to this flow (and not a subsequent flow with the same addresses) and put this identifier in the Path header URI." I presume that reason that subsequent connections between identical addresses are treated as different flows is that the remote address and port may have been reallocated to a different device. Therefore, after a connection failure, a request to the UA routed using the flow identifier could go to a different device. Is this text trying to protect against this unusual situation (which would be rejected by the UA), or is there a rather more practical reason for blurring the layers? Why should a recovered connection be viewed differently from a previous one, as long as the UA is still contactable over that flow? Many thanks, Jonathan ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on section 3.4 of draft-ietf-sip-outbound-10

Cullen, Rohan,

I am concerned about the value and = practicality of section 3.4 of draft-ietf-sip-outbound-10, and would = like to understand the reasoning behind the text "(and not a subsequent flow with the same = addresses)", as this is not = discussed in the mandatory text and this characteristic is not = provided by the example flow token = generation algorithm in section 5.2.

In detail, section 3.4 states the = following:

  "When the Edge
  r: Thread-Topic: Question on section 3.4 of draft-ietf-sip-outbound-10 Thread-Index: AcgEN/AARdQEFnfsTqKfQlhuHAk4qQ== From: "Jonathan Cumming" To: , X-OriginalArrivalTime: 01 Oct 2007 14:35:05.0625 (UTC) FILETIME=[42405090:01C80438] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-TMDA-Confirmed: Mon, 01 Oct 2007 10:40:00 -0400 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: SIP WG Subject: [Sip] Question on section 3.4 of draft-ietf-sip-outbound-10 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="===============0465269911==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0465269911== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80438.13CDB103" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen, Rohan, I am concerned about the value and practicality of section 3.4 of draft-ietf-sip-outbound-10, and would like to understand the reasoning behind the text "(and not a subsequent flow with the same addresses)", as this is not discussed in the mandatory text and this characteristic is not provided by the example flow token generation algorithm in section 5.2. In detail, section 3.4 states the following: "When the Edge Proxy receives a registration, it needs to create an identifier value that is unique to this flow (and not a subsequent flow with the same addresses) and put this identifier in the Path header URI." I presume that reason that subsequent connections between identical addresses are treated as different flows is that the remote address and port may have been reallocated to a different device. Therefore, after a connection failure, a request to the UA routed using the flow identifier could go to a different device. Is this text trying to protect against this unusual situation (which would be rejected by the UA), or is there a rather more practical reason for blurring the layers? Why should a recovered connection be viewed differently from a previous one, as long as the UA is still contactable over that flow? Many thanks, Jonathan ------_=_NextPart_001_01C80438.13CDB103 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question on section 3.4 of draft-ietf-sip-outbound-10

Cullen, Rohan,

I am concerned about the value and = practicality of section 3.4 of draft-ietf-sip-outbound-10, and would = like to understand the reasoning behind the text "(and not a subsequent flow with the same = addresses)", as this is not = discussed in the mandatory text and this characteristic is not = provided by the example flow token = generation algorithm in section 5.2.

In detail, section 3.4 states the = following:

  "When the Edge
   Proxy receives a = registration, it needs to create an identifier value
   that is unique to = this flow (and not a subsequent flow with the same
   addresses) and put = this identifier in the Path header URI."

I presume that reason that subsequent = connections between identical addresses are treated as different flows = is that the remote address and port may have been reallocated to a = different device.  Therefore, after a connection failure, a request = to the UA routed using the flow identifier could go to a different = device.  Is this text trying to protect against this unusual = situation (which would be rejected by the UA), or is there a rather more = practical reason for blurring the layers?

Why should a recovered connection be = viewed differently from a previous one, as long as the UA is still = contactable over that flow?

Many thanks,
Jonathan

------_=_NextPart_001_01C80438.13CDB103-- --===============0465269911== 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 --===============0465269911==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lL-0006uu-7l; Wed, 03 Oct 2007 05:43:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icmz5-0003OS-At for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icmz5-0003OK-0I for sip@ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icmz4-0005ry-P4 for sip@ietf.org; Tue, 02 Oct 2007 15:00:42 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id ABBFF2AC64; Tue, 2 Oct 2007 19:00:12 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Icmya-0004gM-EJ; Tue, 02 Oct 2007 15:00:12 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: hannes.tschofenig@nsn.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 02 Oct 2007 15:00:12 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: sip@ietf.org, audet@nortel.com, Hannes.Tschofenig@nsn.com, steffen.fries@siemens.com, dwing@cisco.com Subject: [Sip] New Version Notification for draft-ietf-sip-media-security-requirements-00 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: , Errors-To: sip-bounces@ietf.org A new version of I-D, draft-ietf-sip-media-security-requirements-00.txt has been successfuly submitted by Hannes Tschofenig and posted to the IETF repository. Filename: draft-ietf-sip-media-security-requirements Revision: 00 Title: Requirements and Analysis of Media Security Key Management Protocols ; Proxy receives a = registration, it needs to create an identifier value
   that is unique to = this flow (and not a subsequent flow with the same
   addresses) and put = this identifier in the Path header URI."

I presume that reason that subsequent = connections between identical addresses are treated as different flows = is that the remote address and port may have been reallocated to a = different device.  Therefore, after a connection failure, a request = to the UA routed using the flow identifier could go to a different = device.  Is this text trying to protect against this unusual = situation (which would be rejected by the UA), or is there a rather more = practical reason for blurring the layers?

Why should a recovered connection be = viewed differently from a previous one, as long as the UA is still = contactable over that flow?

Many thanks,
Jonathan

------_=_NextPart_001_01C80438.13CDB103-- --===============0465269911== 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 --===============0465269911==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lL-0006uu-7l; Wed, 03 Oct 2007 05:43:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icmz5-0003OS-At for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icmz5-0003OK-0I for sip@ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icmz4-0005ry-P4 for sip@ietf.org; Tue, 02 Oct 2007 15:00:42 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id ABBFF2AC64; Tue, 2 Oct 2007 19:00:12 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Icmya-0004gM-EJ; Tue, 02 Oct 2007 15:00:12 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: hannes.tschofenig@nsn.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 02 Oct 2007 15:00:12 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: sip@ietf.org, audet@nortel.com, Hannes.Tschofenig@nsn.com, steffen.fries@siemens.com, dwing@cisco.com Subject: [Sip] New Version Notification for draft-ietf-sip-media-security-requirements-00 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: , Errors-To: sip-bounces@ietf.org A new version of I-D, draft-ietf-sip-media-security-requirements-00.txt has been successfuly submitted by Hannes Tschofenig and posted to the IETF repository. Filename: draft-ietf-sip-media-security-requirements Revision: 00 Title: Requirements and Analysis of Media Security Key Management Protocols ; Proxy receives a = registration, it needs to create an identifier value
   that is unique to = this flow (and not a subsequent flow with the same
   addresses) and put = this identifier in the Path header URI."

I presume that reason that subsequent = connections between identical addresses are treated as different flows = is that the remote address and port may have been reallocated to a = different device.  Therefore, after a connection failure, a request = to the UA routed using the flow identifier could go to a different = device.  Is this text trying to protect against this unusual = situation (which would be rejected by the UA), or is there a rather more = practical reason for blurring the layers?

Why should a recovered connection be = viewed differently from a previous one, as long as the UA is still = contactable over that flow?

Many thanks,
Jonathan

------_=_NextPart_001_01C80438.13CDB103-- --===============0465269911== 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 --===============0465269911==-- From sip-bounces@ietf.org Wed Oct 03 05:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0lL-0006uu-7l; Wed, 03 Oct 2007 05:43:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Icmz5-0003OS-At for sip-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icmz5-0003OK-0I for sip@ietf.org; Tue, 02 Oct 2007 15:00:43 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icmz4-0005ry-P4 for sip@ietf.org; Tue, 02 Oct 2007 15:00:42 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id ABBFF2AC64; Tue, 2 Oct 2007 19:00:12 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Icmya-0004gM-EJ; Tue, 02 Oct 2007 15:00:12 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: hannes.tschofenig@nsn.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 02 Oct 2007 15:00:12 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 03 Oct 2007 05:43:23 -0400 Cc: sip@ietf.org, audet@nortel.com, Hannes.Tschofenig@nsn.com, steffen.fries@siemens.com, dwing@cisco.com Subject: [Sip] New Version Notification for draft-ietf-sip-media-security-requirements-00 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: , Errors-To: sip-bounces@ietf.org A new version of I-D, draft-ietf-sip-media-security-requirements-00.txt has been successfuly submitted by Hannes Tschofenig and posted to the IETF repository. Filename: draft-ietf-sip-media-security-requirements Revision: 00 Title: Requirements and Analysis of Media Security Key Management Protocols Creation_date: 2007-09-28 WG ID: sip Number_of_pages: 42 Abstract: A number of proposals have been published to address the need of securing media traffic. A summary of the proposals available at that time is available in the appendix of this document. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements. A comparison of the requirements against the individual proposals is provided. The IETF Secretariat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip Creation_date: 2007-09-28 WG ID: sip Number_of_pages: 42 Abstract: A number of proposals have been published to address the need of securing media traffic. A summary of the proposals available at that time is available in the appendix of this document. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements. A comparison of the requirements against the individual proposals is provided. The IETF Secretariat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip Creation_date: 2007-09-28 WG ID: sip Number_of_pages: 42 Abstract: A number of proposals have been published to address the need of securing media traffic. A summary of the proposals available at that time is available in the appendix of this document. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements. A comparison of the requirements against the individual proposals is provided. The IETF Secretariat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 03 07:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1xg-0003is-It; Wed, 03 Oct 2007 07:00:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Id1xf-0003im-2i for sip-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 07:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1xe-0003ie-OW for sip@ietf.org; Wed, 03 Oct 2007 07:00:14 -0400 Received: from dhcp64-134-173-67.lrph.orl.wayport.net ([64.134.173.67] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id1xd-00008a-66 for sip@ietf.org; Wed, 03 Oct 2007 07:00:14 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8562A33C28; Wed, 3 Oct 2007 03:56:07 -0700 (PDT) Date: Wed, 03 Oct 2007 03:56:07 -0700 From: Eric Rescorla To: "DRAGE, Keith (Keith)" Subject: Re: [Sip] DTLS-SRTP - more work for the SIP group In-Reply-To: <5D1A7985295922448D5550C94DE29180016B8DDA@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180016B8DDA@DEEXC1U01.de.lucent.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071003105607.8562A33C28@delta.rtfm.com> X-Spam-Score: 2.2 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: , Errors-To: sip-bounces@ietf.org This seems like a sound plan to me. -Ekr At Tue, 18 Sep 2007 20:41:23 +0200, DRAGE, Keith (Keith) wrote: > > (As WG co-chair) > > You may remember that some time ago some work was identified that > crossed multiple working groups in the RAI area on the above subject. > Cullen took this ball away and played with it in a RAI BOF and there > came to some consensus on the way forward and what documentation was > required. > > However we now need to put that work through real working groups to get > it to IESG so we are reallocating it to working groups. > > I have requested milestones as follows: > > Sep 2007 Requirements for media keying to WGLC (Informational) > Nov 2007 Requirements for media keying to IESG (Informational) > > This will be WG milestones in support of progressing > http://www.ietf.org/internet-drafts/draft-wing-media-security-requiremen > ts-04.txt > And incorporating > draft-wing-rtpsec-keying-eval > > This charter item will essentially be a discussion of how we got where > we are now. It is therefore not the most earthshattering document, but > it has been considered valuable to retain some permanent record and an > informational RFC is the way to do this. > > Dec 2007 Establishment of secure media sessions using DTLS-SRTP > to WGLC (PS) > Feb 2008 Establishment of secure media sessions using DTLS-SRTP > to IESG (PS) > > This will be WG milestones in support of progressing > http://www.ietf.org/internet-drafts/draft-fischl-sipping-media-dtls-03.t > xt > > This charter item goes to SIP because it is security related, rather > than to SIPPING. This is one deliverable out of a package of 3, the > other two being: > > http://www.ietf.org/internet-drafts/draft-ietf-avt-dtls-srtp-00.txt > http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dtls-03.txt > > Which will be handled by AVT and MMUSIC respectively. > > What do you need to do as SIP WG members > ---------------------------------------- > > Provide consensus or not to move these drafts forward. > > Do you agree with the identified author drafts above forming the basis > of these charter items listed above? If not please express your > objections to the list, with appropriate technical considerations. > Indications of support are appropriate as well, particularly if you have > a technical point you wish to make (alternatively address the WG chairs > with just "Yes I support"). > > Responses please within a calendar week, i.e. by Tuesday 25th September > 2007, unless there is a feeling that more time and discussion are > needed. > > > Regards > > Keith > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 03 14:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9Hf-0007dW-Bz; Wed, 03 Oct 2007 14:49:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Id9Hd-0007d9-Tj for sip-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9Hd-0007Ru-Jm for sip@ietf.org; Wed, 03 Oct 2007 14:49:21 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id9HO-0007Iq-JY for sip@ietf.org; Wed, 03 Oct 2007 14:49:12 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l93Ili8A009446 for ; Wed, 3 Oct 2007 13:48:43 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 13:48:26 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 20:48:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] I-D Action:draft-ietf-sip-media-security-requirements-00.txt Date: Wed, 3 Oct 2007 20:48:23 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001771000@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-media-security-requirements-00.txt Thread-Index: AcgFKEr7UbqxStcvTpq7dKL+ZDotywAxXAMg References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 03 Oct 2007 18:48:24.0223 (UTC) FILETIME=[FA25D2F0:01C805ED] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: sip-bounces@ietf.org (As WG chair) This is work we have inherited from the RAI BOF on media security. We understand the work was pretty much finished here. Our intent is to put this into WGLC fairly shortly, so now would be a good time for you to look at it and tell us whether it is ready for that or not. Regards Keith=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, October 02, 2007 8:10 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D=20 > Action:draft-ietf-sip-media-security-requirements-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 >=20 > Title : Requirements and Analysis of Media=20 > Security Key Management Protocols > Author(s) : D. Wing, et al. > Filename :=20 > draft-ietf-sip-media-security-requirements-00.txt > Pages : 42 > Date : 2007-09-28 >=20 > A number of proposals have been published to address the need=20 > of securing media traffic. A summary of the proposals=20 > available at that time is available in the appendix of this=20 > document. Different assumptions, requirements, and usage=20 > environments justify every one of them. This document aims=20 > to summarize the discussed media security requirements. A=20 > comparison of the requirements against the individual=20 > proposals is provided. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-secur > ity-requirements-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-sip-media-security-requirements-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-sip-media-security-requirements-00.txt". >=20 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=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 Wed Oct 03 15:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9YF-0008DL-Me; Wed, 03 Oct 2007 15:06:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Id9YD-0008DG-Mf for sip-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 15:06:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id9YD-0008CW-Bq for sip@ietf.org; Wed, 03 Oct 2007 15:06:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id9Y8-0003mC-MI for sip@ietf.org; Wed, 03 Oct 2007 15:06:25 -0400 Received: from hkaplan [10.0.200.241] by acmepacket.com with ESMTP (SMTPD-9.10) id A82E0170; Wed, 03 Oct 2007 15:06:22 -0400 From: "Hadriel Kaplan" To: "'Francois Audet'" , "'Dean Willis'" , "'Brian Stucker'" References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> Subject: RE: [Sip] INFO Date: Wed, 3 Oct 2007 15:06:21 -0400 Message-ID: <009001c805f0$7c5fc440$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQACVQwvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: sip@ietf.org, 'Adam Roach' , 'Mary Barnes' 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: , Errors-To: sip-bounces@ietf.org The problem I think for DTMF is there are (1) applications that need DTMF that are not in the media path, and (2) there is equipment out there that only does INFO for dtmf. For (2), I'm cool with assuming 2833 will be the future. I don't work for those companies, but I assume they'll move that way and get their customers to upgrade. For (1), 2833 is not a solution. Currently KPML is the only IETF-standardized solution for that, yet INFO is the clear defacto standard most people use. My concern with assuming KPML will be adopted is there is little incentive for most devices to do so. The app server vendor who needs signaling-based dtmf has an incentive, but they need the UA's to support it, and I don't see that happening. Instead, INFO is simpler, and many already do it to support the legacy devices due to problem (2) above. But I was thinking someone else would say the same, but apparently not. So maybe I'm off base on this one. Nothing to see here. Move along. I don't actually care *that much*. I was more annoyed by the "info is bad" draft because it seemed flawed and biased to me, and if anyone wanted to propose Info for something in the future, the draft would be a needless block to that. -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, October 02, 2007 5:50 PM > To: Dean Willis; Brian Stucker > Cc: sip@ietf.org; Adam Roach; Mary Barnes > Subject: RE: [Sip] INFO > > I'm still completely baffled by why are we having this thread. > > INFO is used by ISUP tunnelling. It's there, we can leave it alone. As > far > as I know, nobody is trying to improve it. Legacy stuff. No RFC required > here. > > DTMF transport is a null issue since the last remaining laggars that > didn't > support RFC 2833 now support it. So it is going away and I really can't > imagine that > anybody would bring a draft to resurect it. No RFC required here. > > IETF is certainly not going to come up with new INFO usages. Everytime > somebody shows > up with an INFO idea, he's promptly turned away. > > So, what is the "problem" that we are trying to solve? Why are we > wasting > time on this? > > Can't we just declare victory and move on? > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, October 02, 2007 09:47 > > To: Stucker, Brian (RICH1:AR00) > > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > > Subject: Re: [Sip] INFO > > > > > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > > > > > > > So if we're allowing SIP-T, which builds off of a baseline SIP > > > requirement that if you get a MIME type or method (INFO) that you > > > don't understand, that you gracefully handle this: send a > > 415/488 or > > > send a 405, respectively, then why are we disallowing other uses of > > > INFO that do not introduce ANY requirements beyond those of SIP-T > > > which we are allowing? > > > > > > > This raises the argument that SIP-T should be revisited to > > more clearly negotiate support for the material being > > tunneled, including the context in which it is being > > tunneled. My UA might, for example, know how to render an > > ISUP message using a pretty-printer. That doesn't mean it > > knows how to do SIP-T for gateways. > > > > So, SIP-T is broken and likely to give surprising results. > > That is not a hearty argument for endorsing the technique of > > SIP-T for other functions. > > > > > > > Here's another question for the readers: let's say Eric's draft > > > becomes an RFC as written for sake of argument. What > > happens when a UA > > > that does not support SIP-T gets a call from an ISUP > > gateway and gets > > > an INFO with encapsulated ISUP in the message body? How does this > > > processing differ from an endpoint getting encapsulated DTMF in a > > > format it may not understand? It doesn't differ because it > > can't: the > > > UA cannot differentiate between two different MIME types > > when it does > > > not recognize either of them. > > > > But assume the UA DOES recognize the MIME type. How does it > > know what to do with it? Is content-disposition adequate? > > > > If it were, why would we have the higher-level negotiation of > > event contexts? > > > > -- > > 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 Wed Oct 03 16:42:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdB1N-0003tb-EA; Wed, 03 Oct 2007 16:40:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdB1L-0003tS-7J for sip-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 16:40:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdB1K-0003tJ-Q4 for sip@ietf.org; Wed, 03 Oct 2007 16:40:38 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdB1K-0006LF-07 for sip@ietf.org; Wed, 03 Oct 2007 16:40:38 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l93KbtS19330; Wed, 3 Oct 2007 20:37:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 3 Oct 2007 15:40:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1238C692@zrc2hxm0.corp.nortel.com> In-Reply-To: <009001c805f0$7c5fc440$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQACVQwvAACqkDQA== References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> <0! 09001c805 f0$7c5fc440$800101df@acmepacket.com> From: "Audet, Francois (SC100:3055)" To: "Hadriel Kaplan" , "Dean Willis" , "Brian Stucker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org If people did KPML without all the complexity (i.e., please report all digits one-by-one instead of complex pattern matching), then it would fix (1).=20 I do agree that the arguments against INFO are often biased and flawed. I'd much rather we just say: if you need out of band, use KPML because it's the standard, instead of dreaming up weird self-serving reasons why INFO is the root of all evils.=20 So again, the status quo is we have a standard for out-of-band (KPML) which is not broken (albeit a bit complicated). If somebody thinks it needs to be optimized for performance or whatever, let them propose it. I don't really have an opinion. Anyways, I'm not pulling out of this as I have nothing new to=20 contribute. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, October 03, 2007 12:06 > To: Audet, Francois (SC100:3055); 'Dean Willis'; Stucker,=20 > Brian (RICH1:AR00) > Cc: sip@ietf.org; 'Adam Roach'; Barnes, Mary (RICH2:AR00) > Subject: RE: [Sip] INFO >=20 > The problem I think for DTMF is there are (1) applications=20 > that need DTMF that are not in the media path, and (2) there=20 > is equipment out there that only does INFO for dtmf. For=20 > (2), I'm cool with assuming 2833 will be the future. I don't=20 > work for those companies, but I assume they'll move that way=20 > and get their customers to upgrade. >=20 > For (1), 2833 is not a solution. Currently KPML is the only=20 > IETF-standardized solution for that, yet INFO is the clear=20 > defacto standard most people use. My concern with assuming=20 > KPML will be adopted is there is little incentive for most=20 > devices to do so. The app server vendor who needs=20 > signaling-based dtmf has an incentive, but they need the UA's=20 > to support it, and I don't see that happening. Instead, INFO=20 > is simpler, and many already do it to support the legacy=20 > devices due to problem (2) above. But I was thinking someone=20 > else would say the same, but apparently not. So maybe I'm=20 > off base on this one. Nothing to see here. Move along. >=20 > I don't actually care *that much*. I was more annoyed by the=20 > "info is bad" > draft because it seemed flawed and biased to me, and if=20 > anyone wanted to propose Info for something in the future,=20 > the draft would be a needless block to that. >=20 > -hadriel >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, October 02, 2007 5:50 PM > > To: Dean Willis; Brian Stucker > > Cc: sip@ietf.org; Adam Roach; Mary Barnes > > Subject: RE: [Sip] INFO > >=20 > > I'm still completely baffled by why are we having this thread. > >=20 > > INFO is used by ISUP tunnelling. It's there, we can leave=20 > it alone. As=20 > > far as I know, nobody is trying to improve it. Legacy stuff. No RFC=20 > > required here. > >=20 > > DTMF transport is a null issue since the last remaining=20 > laggars that=20 > > didn't support RFC 2833 now support it. So it is going away and I=20 > > really can't imagine that anybody would bring a draft to=20 > resurect it.=20 > > No RFC required here. > >=20 > > IETF is certainly not going to come up with new INFO=20 > usages. Everytime=20 > > somebody shows up with an INFO idea, he's promptly turned away. > >=20 > > So, what is the "problem" that we are trying to solve? Why are we=20 > > wasting time on this? > >=20 > > Can't we just declare victory and move on? > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, October 02, 2007 09:47 > > > To: Stucker, Brian (RICH1:AR00) > > > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > > > Subject: Re: [Sip] INFO > > > > > > > > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > > > > > > > > > > So if we're allowing SIP-T, which builds off of a baseline SIP=20 > > > > requirement that if you get a MIME type or method=20 > (INFO) that you=20 > > > > don't understand, that you gracefully handle this: send a > > > 415/488 or > > > > send a 405, respectively, then why are we disallowing=20 > other uses=20 > > > > of INFO that do not introduce ANY requirements beyond those of=20 > > > > SIP-T which we are allowing? > > > > > > > > > > This raises the argument that SIP-T should be revisited to more=20 > > > clearly negotiate support for the material being=20 > tunneled, including=20 > > > the context in which it is being tunneled. My UA might,=20 > for example,=20 > > > know how to render an ISUP message using a pretty-printer. That=20 > > > doesn't mean it knows how to do SIP-T for gateways. > > > > > > So, SIP-T is broken and likely to give surprising results. > > > That is not a hearty argument for endorsing the technique=20 > of SIP-T=20 > > > for other functions. > > > > > > > > > > Here's another question for the readers: let's say Eric's draft=20 > > > > becomes an RFC as written for sake of argument. What > > > happens when a UA > > > > that does not support SIP-T gets a call from an ISUP > > > gateway and gets > > > > an INFO with encapsulated ISUP in the message body? How=20 > does this=20 > > > > processing differ from an endpoint getting encapsulated=20 > DTMF in a=20 > > > > format it may not understand? It doesn't differ because it > > > can't: the > > > > UA cannot differentiate between two different MIME types > > > when it does > > > > not recognize either of them. > > > > > > But assume the UA DOES recognize the MIME type. How does it know=20 > > > what to do with it? Is content-disposition adequate? > > > > > > If it were, why would we have the higher-level=20 > negotiation of event=20 > > > contexts? > > > > > > -- > > > Dean > > > > > > > > > > > > > > > _______________________________________________ > > > 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 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 Wed Oct 03 22:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGGn-0001S9-Vh; Wed, 03 Oct 2007 22:16:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdGGm-0001PI-JL for sip-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 22:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGGm-00015V-6V for sip@ietf.org; Wed, 03 Oct 2007 22:16:56 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdGGc-0002qF-1L for sip@ietf.org; Wed, 03 Oct 2007 22:16:52 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l942DTj23772; Thu, 4 Oct 2007 02:13:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] 302 question Date: Wed, 3 Oct 2007 21:15:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12424949@zrc2hxm0.corp.nortel.com> In-Reply-To: <200710021752.l92HqZAI029916@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] 302 question thread-index: AcgFHgGHD4HMOwakTlqHUdKxV0QcNQBDldsw References: <470280C2.3040907@madein.hu> <200710021752.l92HqZAI029916@dragon.ariadne.com> From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: sip-bounces@ietf.org The developers are definitely incorrect. The 302 might not even be originating from your UAS. It could have been a device further upstream that triggered the 302 (and/or yet another device that triggered the 183 for that matter). Regards, Brian=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Tuesday, October 02, 2007 12:53 PM > To: sip@ietf.org > Subject: Re: [Sip] 302 question >=20 > From: Mihaly Zachar >=20 > The UAS has a feature, that if the called number is=20 > matching with a=20 > pattern, it will send 183 Session in progress, than plays=20 > an RTP stream=20 > and then redirect the UAC with 302 Moved Temporarily.. >=20 > There is an UAC, and it's developers says that I should=20 > not send 302=20 > Redirect after the 183 Session in progress. >=20 > I believe the developers are incorrect. In RFC 3261, section=20 > 13.1, top of page 78, we see: >=20 > After some time, those UASs can accept the invitation (meaning the > session is to be established) by sending a 2xx response. If the > invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is > sent, depending on the reason for the rejection. Before sending a > final response, the UAS can also send provisional responses (1xx) > to advise the UAC of progress in contacting the called user. >=20 > After possibly receiving one or more provisional responses, the UAC > will get one or more 2xx responses or one non-2xx final response. >=20 > This text implies that a provisional response may precede a=20 > non-2xx final response. >=20 > Dale >=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 04 03:14:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdKnt-00063e-5x; Thu, 04 Oct 2007 03:07:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdKnp-00063P-Sh for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 03:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdKnp-00061O-C4 for sip@ietf.org; Thu, 04 Oct 2007 03:07:21 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdKni-0002ff-Vr for sip@ietf.org; Thu, 04 Oct 2007 03:07:21 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JPD00A2KL31EQ@siemenscomms.co.uk> for sip@ietf.org; Thu, 04 Oct 2007 08:06:37 +0100 (BST) Date: Thu, 04 Oct 2007 08:06:57 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: <009001c805f0$7c5fc440$800101df@acmepacket.com> To: Hadriel Kaplan , Francois Audet , Dean Willis , Brian Stucker Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03257E7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQACVQwvAAIIfYcA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <009001c805f0$7c5fc440$800101df@acmepacket.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sip@ietf.org, Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org Hadriel, Are those applications necessarily on the INFO path? KPML doesn't require the applications to be on the INFO path. I believe plenty of SIP devices only support RFC 2833, not INFO, and those that do support INFO are likely to do so in different ways, because it is not standardised. So how can the application provider be sure, even with INFO, that there will be devices to support it? John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 03 October 2007 20:06 > To: 'Francois Audet'; 'Dean Willis'; 'Brian Stucker' > Cc: sip@ietf.org; 'Adam Roach'; 'Mary Barnes' > Subject: RE: [Sip] INFO > > The problem I think for DTMF is there are (1) applications > that need DTMF > that are not in the media path, and (2) there is equipment > out there that > only does INFO for dtmf. For (2), I'm cool with assuming > 2833 will be the > future. I don't work for those companies, but I assume > they'll move that > way and get their customers to upgrade. > > For (1), 2833 is not a solution. Currently KPML is the only > IETF-standardized solution for that, yet INFO is the clear > defacto standard > most people use. My concern with assuming KPML will be > adopted is there is > little incentive for most devices to do so. The app server > vendor who needs > signaling-based dtmf has an incentive, but they need the UA's > to support it, > and I don't see that happening. Instead, INFO is simpler, > and many already > do it to support the legacy devices due to problem (2) above. > But I was > thinking someone else would say the same, but apparently not. > So maybe I'm > off base on this one. Nothing to see here. Move along. > > I don't actually care *that much*. I was more annoyed by the > "info is bad" > draft because it seemed flawed and biased to me, and if > anyone wanted to > propose Info for something in the future, the draft would be > a needless > block to that. > > -hadriel > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, October 02, 2007 5:50 PM > > To: Dean Willis; Brian Stucker > > Cc: sip@ietf.org; Adam Roach; Mary Barnes > > Subject: RE: [Sip] INFO > > > > I'm still completely baffled by why are we having this thread. > > > > INFO is used by ISUP tunnelling. It's there, we can leave > it alone. As > > far > > as I know, nobody is trying to improve it. Legacy stuff. No > RFC required > > here. > > > > DTMF transport is a null issue since the last remaining laggars that > > didn't > > support RFC 2833 now support it. So it is going away and I > really can't > > imagine that > > anybody would bring a draft to resurect it. No RFC required here. > > > > IETF is certainly not going to come up with new INFO > usages. Everytime > > somebody shows > > up with an INFO idea, he's promptly turned away. > > > > So, what is the "problem" that we are trying to solve? Why are we > > wasting > > time on this? > > > > Can't we just declare victory and move on? > > > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, October 02, 2007 09:47 > > > To: Stucker, Brian (RICH1:AR00) > > > Cc: sip@ietf.org; Adam Roach; Barnes, Mary (RICH2:AR00) > > > Subject: Re: [Sip] INFO > > > > > > > > > On Oct 1, 2007, at 3:01 AM, Brian Stucker wrote: > > > > > > > > > > > So if we're allowing SIP-T, which builds off of a baseline SIP > > > > requirement that if you get a MIME type or method > (INFO) that you > > > > don't understand, that you gracefully handle this: send a > > > 415/488 or > > > > send a 405, respectively, then why are we disallowing > other uses of > > > > INFO that do not introduce ANY requirements beyond > those of SIP-T > > > > which we are allowing? > > > > > > > > > > This raises the argument that SIP-T should be revisited to > > > more clearly negotiate support for the material being > > > tunneled, including the context in which it is being > > > tunneled. My UA might, for example, know how to render an > > > ISUP message using a pretty-printer. That doesn't mean it > > > knows how to do SIP-T for gateways. > > > > > > So, SIP-T is broken and likely to give surprising results. > > > That is not a hearty argument for endorsing the technique of > > > SIP-T for other functions. > > > > > > > > > > Here's another question for the readers: let's say Eric's draft > > > > becomes an RFC as written for sake of argument. What > > > happens when a UA > > > > that does not support SIP-T gets a call from an ISUP > > > gateway and gets > > > > an INFO with encapsulated ISUP in the message body? How > does this > > > > processing differ from an endpoint getting encapsulated > DTMF in a > > > > format it may not understand? It doesn't differ because it > > > can't: the > > > > UA cannot differentiate between two different MIME types > > > when it does > > > > not recognize either of them. > > > > > > But assume the UA DOES recognize the MIME type. How does it > > > know what to do with it? Is content-disposition adequate? > > > > > > If it were, why would we have the higher-level negotiation of > > > event contexts? > > > > > > -- > > > 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 04 05:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdNI0-0006EO-2D; Thu, 04 Oct 2007 05:46:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdNHz-0006EH-20 for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 05:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdNHy-0006E7-Og for sip@ietf.org; Thu, 04 Oct 2007 05:46:38 -0400 Received: from new.madein.hu ([195.56.146.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdNHs-00088R-Cg for sip@ietf.org; Thu, 04 Oct 2007 05:46:38 -0400 Received: from new.madein.hu (madein [127.0.0.1]) by new.madein.hu (Postfix) with ESMTP id 7B8E5347D for ; Thu, 4 Oct 2007 11:46:15 +0200 (CEST) Received: by new.madein.hu (Postfix, from userid 103) id 4D7D43484; Thu, 4 Oct 2007 11:46:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on madein X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [10.177.177.1] (dsl5400B454.pool.t-online.hu [84.0.180.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by new.madein.hu (Postfix) with ESMTP id 106FD347D for ; Thu, 4 Oct 2007 11:46:07 +0200 (CEST) Message-ID: <4704B65D.3060002@madein.hu> Date: Thu, 04 Oct 2007 11:46:05 +0200 From: Mihaly Zachar User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] 302 question References: <470280C2.3040907@madein.hu> <200710021752.l92HqZAI029916@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF12424949@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12424949@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: sip-bounces@ietf.org Thanks to Dale and Brian for these answers. The firmware developers have acknowledged my valid point, so we won the war. As I can see, this list is not for like these kind of questions, I very appreciate your answers here. Thanks, Misi Brian Stucker wrote: > The developers are definitely incorrect. The 302 might not even be > originating from your UAS. It could have been a device further upstream > that triggered the 302 (and/or yet another device that triggered the 183 > for that matter). > > Regards, > Brian > > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Tuesday, October 02, 2007 12:53 PM >> To: sip@ietf.org >> Subject: Re: [Sip] 302 question >> >> From: Mihaly Zachar >> >> The UAS has a feature, that if the called number is >> matching with a >> pattern, it will send 183 Session in progress, than plays >> an RTP stream >> and then redirect the UAC with 302 Moved Temporarily.. >> >> There is an UAC, and it's developers says that I should >> not send 302 >> Redirect after the 183 Session in progress. >> >> I believe the developers are incorrect. In RFC 3261, section >> 13.1, top of page 78, we see: >> >> After some time, those UASs can accept the invitation (meaning the >> session is to be established) by sending a 2xx response. If the >> invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is >> sent, depending on the reason for the rejection. Before sending a >> final response, the UAS can also send provisional responses (1xx) >> to advise the UAC of progress in contacting the called user. >> >> After possibly receiving one or more provisional responses, the UAC >> will get one or more 2xx responses or one non-2xx final response. >> >> This text implies that a provisional response may precede a >> non-2xx final response. >> >> 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 >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 04 08:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdPJZ-00074m-Fa; Thu, 04 Oct 2007 07:56:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdPJY-00074h-H8 for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 07:56:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdPJY-0006xY-4t for sip@ietf.org; Thu, 04 Oct 2007 07:56:24 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdPJI-0002IN-RN for sip@ietf.org; Thu, 04 Oct 2007 07:56:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20071004115607m1500ibeile>; Thu, 4 Oct 2007 11:56:07 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l94Bu629020169 for ; Thu, 4 Oct 2007 07:56:06 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l94Bu6MA020165; Thu, 4 Oct 2007 07:56:06 -0400 Date: Thu, 4 Oct 2007 07:56:06 -0400 Message-Id: <200710041156.l94Bu6MA020165@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4704B65D.3060002@madein.hu> (zmihaly@madein.hu) Subject: Re: [Sip] 302 question References: <470280C2.3040907@madein.hu> <200710021752.l92HqZAI029916@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF12424949@zrc2hxm0.corp.nortel.com> <4704B65D.3060002@madein.hu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Errors-To: sip-bounces@ietf.org From: Mihaly Zachar As I can see, this list is not for like these kind of questions, I very appreciate your answers here. You may want to subscribe to the SIP-Implementors mailing list, . 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 04 10:06:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRGg-00057i-2v; Thu, 04 Oct 2007 10:01:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdRGf-00056B-DB for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 10:01:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRGf-0004rt-2A for sip@ietf.org; Thu, 04 Oct 2007 10:01:33 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdRGZ-0008K2-N0 for sip@ietf.org; Thu, 04 Oct 2007 10:01:27 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 4 Oct 2007 10:01:27 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 4 Oct 2007 10:01:26 -0400 From: Hadriel Kaplan To: "Elwell, John" , Francois Audet , Dean Willis , Brian Stucker Date: Thu, 4 Oct 2007 10:01:23 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgFFMaU1QN8XmbXRC67YkHeZVzUnwAKDPVQACVQwvAAIIfYcAAOAjKw Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <009001c805f0$7c5fc440$800101df@acmepacket.com> <0D5F89FAC29E2C41B98A6A762007F5D03257E7@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D03257E7@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "sip@ietf.org" , Adam Roach , Mary Barnes 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, October 04, 2007 3:07 AM > To: Hadriel Kaplan; Francois Audet; Dean Willis; Brian Stucker > Cc: sip@ietf.org; Adam Roach; Mary Barnes > Subject: RE: [Sip] INFO > > Hadriel, > > Are those applications necessarily on the INFO path? KPML doesn't > require the applications to be on the INFO path. As far as I've ever seen yes the apps are in the signaling path, but it's n= ot my area. One would think, though, that for an app server to know whom t= o generate a KPML subscribe to, and for what dialog identifiers to put in t= he Event header, the app server would have to be in the signaling path rega= rdless. If one could KPML subscribe without that info, which is not clear = to me is or is not allowed by 4730, then sure one could just subscribe to U= As without being in call signaling. > I believe plenty of SIP devices only support RFC 2833, not INFO, and > those that do support INFO are likely to do so in different ways, > because it is not standardised. So how can the application provider be > sure, even with INFO, that there will be devices to support it? That's why I was thinking we could define a simple way to indicate such a t= hing. Usually I don't like to have more than one, mandatory way to do some= thing, but that ship has already sailed for DTMF, IMHO. So the next-best t= hing is at least negotiation/indication. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 04 10:08:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRMH-0008RY-Ay; Thu, 04 Oct 2007 10:07:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdRMF-0008Kf-EG for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 10:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRMF-0008KX-4a for sip@ietf.org; Thu, 04 Oct 2007 10:07:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdRM9-0001y3-MB for sip@ietf.org; Thu, 04 Oct 2007 10:07:19 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l94E6vvd009982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Oct 2007 09:07:02 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel! .com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F65DB27-41ED-42F3-97F5-D550C3E72902@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 4 Oct 2007 09:06:55 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Errors-To: sip-bounces@ietf.org On Oct 2, 2007, at 4:49 PM, Francois Audet wrote: > > IETF is certainly not going to come up with new INFO usages. Everytime > somebody shows > up with an INFO idea, he's promptly turned away. > > So, what is the "problem" that we are trying to solve? Why are we > wasting > time on this? > To paraphrase my friends at the 12-step program, the first step to fixing a problem is to admit that you have more than one problem and decide which one you're working on right now. I was happy with the status-quo. But here's the main problem as I understand it: People keep either showing up with INFO uses or just inventing them in the wild and propagating them until somebody ELSE shows up at IETF with a "de facto standard" usage of INFO that we have to turn away, thereby wasting our time and theirs, and hurting many people's delicate feelings in the process. If we had an RFC that said "New uses of INFO are not being accepted by the IETF for the following reasons, please use something else (like an event package) instead" then people might be less tempted to use INFO, or at least to bring it to the IETF. I think we have a consensus on this point. We have some debate on whether it's worth developing such an RFC, but I think everybody understands this path. However, there's a second problem, and people keep getting these two problems confused (or at least thinking we are discussing the first problem when we're really discussing the second) hence we go around in a circle. The second problem is "People are using INFO because it has certain advantages that make it more attractive than a new event package for some applications. If we fixed the problems with INFO negotiation without losing these advantages, the community would benefit greatly as a result." This is the problem whose threads contain things like "KPML is a much less efficient mechanism for driving telephone applications that use DTMF than DTMF over INFO". So, there are at least TWO PROBLEMS. Why don't we have at least two solutions? Perhaps we could document the flaws with INFO's design and explain, as a BCP, why we don't recommend using it and why IETF should not proceed with new usages of INFO as long as those flaws persist. This would not preclude a second standards-track effort (if we wish to pursue it) to fix INFO, or replace it with a new in-dialog contextually negotiated content transfer mechanism. It would also not preclude standards-track efforts to replace individual INFO usages with new SIP methods (if we wish to pursue them). For example, there's no reason why we couldn't replace ISUP- over-INFO with a new SIP method "ISUP", TSIG over INFO with a new SIP method "TSIG", DTMF-over-INFO with a new SIP method "DTMF", and so on. This gets back to my rant some months ago about the SIP community not having consensus on one extension methodology, thereby giving us multiple extension methodologies that compete (and possibly conflict) with each other. We don't agree whether SIP is an application protocol or a transport protocol, so we've made it into both at the same time. It's about time we grapple with this issue and establish a practice going forward. -- 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 04 10:32:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRje-00015D-Tl; Thu, 04 Oct 2007 10:31:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdRjd-00011v-IX for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 10:31:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRjd-00011n-8B for sip@ietf.org; Thu, 04 Oct 2007 10:31:29 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdRjc-0000qe-UM for sip@ietf.org; Thu, 04 Oct 2007 10:31:29 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPE001EY5OGXE@usaga01-in.huawei.com> for sip@ietf.org; Thu, 04 Oct 2007 07:31:28 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPE00AH85OD7R@usaga01-in.huawei.com> for sip@ietf.org; Thu, 04 Oct 2007 07:31:28 -0700 (PDT) Date: Thu, 04 Oct 2007 09:31:09 -0500 From: Spencer Dawkins Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) To: IETF SIP List Message-id: <00f601c80693$350490f0$6901a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8F65DB27-41ED-42F3-97F5-D550C3E72902@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: sip-bounces@ietf.org Hi, Dean, > I was happy with the status-quo. But here's the main problem as I > understand it: > > People keep either showing up with INFO uses or just inventing them in > the wild and propagating them until somebody ELSE shows up at IETF with a > "de facto standard" usage of INFO that we have to turn away, thereby > wasting our time and theirs, and hurting many people's delicate feelings > in the process. > > If we had an RFC that said "New uses of INFO are not being accepted by > the IETF for the following reasons, please use something else (like an > event package) instead" then people might be less tempted to use INFO, or > at least to bring it to the IETF. Speaking as co-chair of MEDIACTRL who's currently looking at text in one of the MEDIACTRL drafts about "why not INFO", that's exactly what I'm hoping for. Thanks for the excellent and short summary. Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 04 12:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT4C-0000Xb-IR; Thu, 04 Oct 2007 11:56:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdT4B-0000Wp-Eg for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 11:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT4B-0000We-4m for sip@ietf.org; Thu, 04 Oct 2007 11:56:47 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdT43-00067w-QH for sip@ietf.org; Thu, 04 Oct 2007 11:56:47 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l94Frrj18002; Thu, 4 Oct 2007 15:53:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 4 Oct 2007 10:56:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> In-Reply-To: <8F65DB27-41ED-42F3-97F5-D550C3E72902@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel! ! .com> < 8F65DB27-41ED-42F3-97F5-D550C3E72902@softarmor.com> From: "Audet, Francois (SC100:3055)" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: , Errors-To: sip-bounces@ietf.org There is a missing point in here. When you say "new uses of INFO are not being accepted by the IETF for the following reasons", the problem is that people are overstating their case when discussing the "reasons". This in turn is annoying people who find the "reasons" not technically accurate. I'd rather we try to avoid "inventing" reasons and getting into silly long arguments. We could say something very simple in that draft. Something like, INFO was created as a general transport mechanism in SIP. As SIP evolved, new=20 mechanisms for different usages were created (then we can list them,=20 and give KPML as an example for keypress). And then just say that new usages beyond the existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. And leave it to that. Any attempt at inventing complex reasons will just encourage people to find flaws in the arguments. But, again, I'm happy with the status quo. > If we had an RFC that said "New uses of INFO are not being accepted =20 > by the IETF for the following reasons, please use something else =20 > (like an event package) instead" then people might be less=20 > tempted to =20 > use INFO, or at least to bring it to the IETF. >=20 > I think we have a consensus on this point. We have some debate on =20 > whether it's worth developing such an RFC, but I think everybody =20 > understands this path. >=20 > However, there's a second problem, and people keep getting these two =20 > problems confused (or at least thinking we are discussing the first =20 > problem when we're really discussing the second) hence we go around =20 > in a circle. >=20 > The second problem is "People are using INFO because it has certain =20 > advantages that make it more attractive than a new event package for =20 > some applications. If we fixed the problems with INFO negotiation =20 > without losing these advantages, the community would benefit greatly =20 > as a result." >=20 > This is the problem whose threads contain things like "KPML=20 > is a much =20 > less efficient mechanism for driving telephone applications that use =20 > DTMF than DTMF over INFO". >=20 > So, there are at least TWO PROBLEMS. Why don't we have at least two =20 > solutions? >=20 > Perhaps we could document the flaws with INFO's design and explain, =20 > as a BCP, why we don't recommend using it and why IETF should not =20 > proceed with new usages of INFO as long as those flaws persist. >=20 > This would not preclude a second standards-track effort (if we wish =20 > to pursue it) to fix INFO, or replace it with a new in-dialog =20 > contextually negotiated content transfer mechanism. >=20 > It would also not preclude standards-track efforts to replace =20 > individual INFO usages with new SIP methods (if we wish to pursue =20 > them). For example, there's no reason why we couldn't replace ISUP-=20 > over-INFO with a new SIP method "ISUP", TSIG over INFO with a=20 > new SIP =20 > method "TSIG", DTMF-over-INFO with a new SIP method "DTMF", and so on. >=20 > This gets back to my rant some months ago about the SIP=20 > community not =20 > having consensus on one extension methodology, thereby giving us =20 > multiple extension methodologies that compete (and possibly=20 > conflict) =20 > with each other. We don't agree whether SIP is an application =20 > protocol or a transport protocol, so we've made it into both at the =20 > same time. It's about time we grapple with this issue and=20 > establish a =20 > practice going forward. >=20 > -- > Dean >=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 04 13:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdU8P-0006jC-Jf; Thu, 04 Oct 2007 13:05:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdU8O-0006hf-ID for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:05:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdU8O-0006hX-78 for sip@ietf.org; Thu, 04 Oct 2007 13:05:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdU8N-0006bl-Fc for sip@ietf.org; Thu, 04 Oct 2007 13:05:12 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F00C42107F; Thu, 4 Oct 2007 19:05:10 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-2d-47051d4655bc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CE02920FAF; Thu, 4 Oct 2007 19:05:10 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 19:05:10 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-urpalainen-sip-xcap-diff-event-02 Date: Thu, 4 Oct 2007 19:05:09 +0200 Message-ID: <6D34F0B7D5BCB246A42380744457CA3601A0FDF5@esealmw107.eemea.ericsson.se> In-Reply-To: <156FE001-F0E1-4C11-9B60-42E0912C83F8@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-urpalainen-sip-xcap-diff-event-02 Thread-Index: Acf/TSOzVjme1zdGSKWpQSGUJMWghAHVxyBA References: <46C948F1.7000503@nokia.com> <156FE001-F0E1-4C11-9B60-42E0912C83F8@softarmor.com> From: "Anders Lindgren C" To: "Dean Willis" , "IETF SIP List" X-OriginalArrivalTime: 04 Oct 2007 17:05:10.0423 (UTC) FILETIME=[B8C4B270:01C806A8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Ingemar Lindgren 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: , Errors-To: sip-bounces@ietf.org Hi all, This is my view given with an OMA touch. As I see it the i-d forms a good base to solve the requirements that I have seen in OMA so far. It is an important corner stone when implementing XCAP in a SIP environment as it make it possible to use SIP to solve e.g. the syncronisation issue between two XCAP client using existing SIP methods. I can not find that the content of the i-d needs to be changed in any major parts or that a different solution is needed than proposed. I'm also happy with initial sync issue as documented. It exists some issues related to how mapping between the content within the R-URI in the SIP Subscribe and the XCAP resources in the Subscribe body is done but I think that they better are handled in the OMA documents as they are related to the environment where the i-d is used more than being of basic nature. If these issues are found to be of general interest it is better to document it in it's one i-d later on when we got some experience from the usage of this i-d. The i-d has some similarity with http://tools.ietf.org/html/draft-ietf-sip-uri-list-subscribe-01 in that sense that both are using the resource-list format to transport the resources that you want information about. This opens up some questions if the i-d also shall define a exploder function for xcap document changes in that sense that I can subscribe for changes in a number of users XCAP documents in one Subscribe. Also here I my view is that this can be handled outside this i-d as it is not part of a base function and that we need some experience from this function before we start to make it more complex. As exploders often are related to attempts to reduce some resource usage it might be better to implement this type of function using this i-d and plus some more i-d/RFC and document it as a part of a document done by the organization that see a need for the function. The important thing is that the corner stones to use exist general available. Regards Anders -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: den 25 september 2007 10:18 To: IETF SIP List Cc: Jari Urpalainen; Anders Lindgren C; Ingemar Lindgren Subject: Re: [Sip] draft-urpalainen-sip-xcap-diff-event-02 On Aug 20, 2007, at 2:55 AM, Jari Urpalainen wrote: > Hi all! > > I've updated sip-xcap-diff-event-02.txt>. Element & attribute subscriptions were=20 > moved to i-d: simple-xcap-diff-06.txt>. Resource selections are done by a flat URI=20 > list with the XCAP resource list format instead of the "path" > header parameter, and some text nits have been done. The somewhat=20 > controversial initial sync problem still exists when patches are=20 > aggregated. It is however, proposed that we live with that now as it=20 > is a corner case which still can be handled with the proposed=20 > approach, any comments ? > br, Jari C'mon kids, OMA is quite reasonably busting my chops because the lack of an xcap-diff-event is mangling their schedule for XDM, and we're a bit late on our July milestone for WGLC here. Let's pick up the pace, ok? I'd like to ask the OMA to double-check that they are OK with the current draft. Anybody else got anything to say about this draft? Can we live with the initial sync issue as documented? I think I'm okay with it, but I've been reasonably happy for the last couple of revs, so it's other people that we need to hear from. If we're all happy, I'd like to get this renamed as a WG draft and on the working-group last-call schedule ASAP. -- 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 04 15:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVvd-0005en-UF; Thu, 04 Oct 2007 15:00:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdVvb-0005TL-Vw for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVvb-0005MR-4J for sip@ietf.org; Thu, 04 Oct 2007 15:00:07 -0400 Received: from ionians.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IdVvU-0003qQ-VP for sip@ietf.org; Thu, 04 Oct 2007 15:00:07 -0400 Received: from herzegovina.disanet.disa-u.mil ([164.117.144.227]) by ionians.disa.mil with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Oct 2007 14:59:47 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Oct 2007 14:59:46 -0400 Message-ID: <16BB45580B7F6A4D9CF65674DD7214F6024F1F6F@herzegovina.disanet.disa-u.mil> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Telephony Features RFCs (UNCLASSIFIED) Thread-Index: AcgGuLSyK4OBe68ZS+aUIlEXN01FsQ== From: "Nhan, Howard CIV DISA GES-E" To: "IETF SIP List" X-OriginalArrivalTime: 04 Oct 2007 18:59:47.0470 (UTC) FILETIME=[BBCECAE0:01C806B8] X-Spam-Score: -4.0 (----) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Sip] Telephony Features RFCs (UNCLASSIFIED) 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="===============0040674869==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0040674869== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0168_01C80697.336AE150"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0168_01C80697.336AE150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Hi, I'm trying to compile a list of all RFCs (proposed standards, draft standards, full standards, informational, ...) and I-Ds that pertain to telephony features (e.g. call hold, call forward, call transfer, call blocking, ...) Does anyone already have such a list? If not, could you suggest ways to compile this list quickly and painlessly? Thanks, Howard Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0168_01C80697.336AE150 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPNTCCAmcw ggHQoAMCAQICAQQwDQYJKoZIhvcNAQEFBQAwYTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHDAaBgNVBAMTE0RvRCBDTEFT UyAzIFJvb3QgQ0EwHhcNMDAwNTE5MTMxMzAwWhcNMjAwNTE0MTMxMzAwWjBhMQswCQYDVQQGEwJV UzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEc MBoGA1UEAxMTRG9EIENMQVNTIDMgUm9vdCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tTD+ZL7qzG3tgSz3f+kZug5paijhqanLlVgf8eaaaVPgiD+RxVG5Y5eo5iGME142PKhX+vhwLExq y78wp0wW5DJc+BKwUfgWV40vtE36LqiU6Cph1FcNR85uLC9+mGfMAAirtpYWNcKFkeVboArHZlJi 82F1lReuvCpWKaXgK1MCAwEAAaMvMC0wHQYDVR0OBBYEFGycpfBcj21BjcQXO5BXwg+jzW3+MAwG A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAr3FE+ZcjzGhpjEMHQbqIILMiAEHImKBVHM0/ brGTXK36GJq7HHNv/SRCj4efUc++hp/p14pITwjZaZSsP+YPLZcPKJN2T2Lf/6DNYfimhgwxNCDc fy+o+zm+le44WQJiwd5sFU/g35275HlzJP1jZJX3SqiZH0hllcd7v3gy53owggQbMIIDhKADAgEC AgErMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQDExNEb0QgQ0xBU1MgMyBSb290 IENBMB4XDTAzMDYxMDEwMjIyMVoXDTA5MDYwODEwMjIyMVowZDELMAkGA1UEBhMCVVMxGDAWBgNV BAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMT FkRPRCBDTEFTUyAzIEVNQUlMIENBLTkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJKB4YeX efs3SrZFpuQLlGRdA17Idtf2fMDbkddWoDIL+HnrBsUiiJO94uzU95UQMxpYNukSLZxu4bhsf4XT PtKJJGUhVf9Eb+iEAzFenCzORG2wx368eObjOdZp8wUQA8I/Z67JxxSojEilsrs28w6sNy8dYHXB So4qvb4Fv7GRAgMBAAGjggHeMIIB2jAdBgNVHQ4EFgQUqtJT7b8+4PQWtDLV3kQq2iVil78wDgYD VR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRs nKXwXI9tQY3EFzuQV8IPo81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1p bC9jbiUzZERvRCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0Ql MmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaB mWxkYXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOB gQCWGIMUVeEbVJ8R8kL8S1VXJcNPXTONJLaknzNLpDao5quyFH8xdX5ewi+k8A6ho8cIgBzs2BLq rX3jpcZINjgPQjpO9LeH7k6PAc4UVcdKrh4+dTKgXUxWh+p/FH91thlvX97bIn5sGmvwQIj8uqjZ cVs2xJ1+RFi2GKC8xDjH2TCCBCwwggOVoAMCAQICAxVUgjANBgkqhkiG9w0BAQUFADBkMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT A1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0EtOTAeFw0wNTAxMTgwMDAwMDBaFw0w ODAxMTcyMzU5NTlaMHMxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAK BgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQ0wCwYDVQQLEwRESVNBMR8wHQYDVQQDExZOSEFOLkhP V0FSRC4xMjMyMjEwNDA3MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8HLWkkqMlAIrWpWY3 IwhwmJ0WGQ6cEvQx9cQ/rYwDOjUXLcX5iC5LicVKenAD3rmFpRA+eUDhDFyR70svZNaTeK/WfFBx GWFKLDcphPIBNpxk649z5PcTyKEAqQJ2rV9ntbnRCjWxhbO+5X6bqV2HYrhsnDBmC4SWJucB9cqm hQIDAQABo4IB2zCCAdcwDgYDVR0PAQH/BAQDAgUgMB8GA1UdEQQYMBaBFGhvd2FyZC5uaGFuQGRp c2EubWlsMB8GA1UdIwQYMBaAFKrSU+2/PuD0FrQy1d5EKtolYpe/MB0GA1UdDgQWBBRoyPv5MuI9 WUy3JKJrc1lHATNVfjAWBgNVHSAEDzANMAsGCWCGSAFlAgELCTCBjwYDVR0SBIGHMIGEhoGBbGRh cDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMl MjBFTUFJTCUyMENBLTklMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5t ZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEwga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5j M3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtOSUy Y291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2Vy dGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEAOjJ833oleMDZ wm5l0LqYhNlZF26jKzCaR4mWp6NgOHB/YqIGyW7Bj1h9Wg4JAh4HHGeBudmO9t7RD4WkhjBo/mWX 1w+zC2Uff/sdq3OTYWvOmbmtTK/W7tNjNBEdsRaCYuBpiMtgxkrdxaUkJzC3o/WwewrTs4MURoBs XZKrdB0wggR3MIID4KADAgECAgMVVH0wDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAdBgNV BAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTkwHhcNMDUwMTE4MDAwMDAwWhcNMDgwMTE3MjM1OTU5 WjBzMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTENMAsGA1UECxMERElTQTEfMB0GA1UEAxMWTkhBTi5IT1dBUkQuMTIzMjIx MDQwNzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkUN1/UeN6wPDJMZEpAhGVNoNq7LbmYKG lS9dIB8Tffp5sTWcl8jZL5qLiBFN0Jgvz+U8kJRx/o/ioHu1JvyVvaDKMVJJBWzaaeI/LzVBDDZa uehjEzpFEnhs28EIUX8/TWXQpQGooAwAlS2nkNOcdmlGF8cRzB4XYqACt4HhU2ECAwEAAaOCAiYw ggIiMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBSq0lPtvz7g9Ba0MtXeRCraJWKXvzAdBgNV HQ4EFgQUDwscAe50/NsS4drhaFxmgmAoJBwwFgYDVR0gBA8wDTALBglghkgBZQIBCwkwgY8GA1Ud EgSBhzCBhIaBgWxkYXA6Ly9lbWFpbC1kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9E JTIwQ0xBU1MlMjAzJTIwRU1BSUwlMjBDQS05JTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RV LlMuJTIwR292ZXJubWVudCUyY2MlM2RVUzCBuQYDVR0fBIGxMIGuMIGroIGooIGlhoGibGRhcDov L2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlzYS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBF TUFJTCUyMENBLTklMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50 JTJjYyUzZFVTP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5MCkGA1UdJQQiMCAGCisG AQQBgjcUAgIGCCsGAQUFBwMEBggrBgEFBQcDAjA/BgNVHREEODA2gRRob3dhcmQubmhhbkBkaXNh Lm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyMzIyMTA0MDdAbWlsMA0GCSqGSIb3DQEBBQUAA4GBADQo IrZuThvnhzJ+KIahD6NRmxedzBGDVStnLU0HkKpuKkZfVDvhI4X+Alpw56mwQCgZfLb0Ow0qrO71 eYZAUPyAIa0UixNhaSJ0RnfBaVSblrnuF8JMTA5uxeipw+iyVESht0riwA6R8VSJ12XjQxHTYSeg kpVtfnSXsNPeWJxrMYICxjCCAsICAQEwazBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH b3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNT IDMgRU1BSUwgQ0EtOQIDFVR9MAkGBSsOAwIaBQCgggGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAwNDE4NTk0NVowIwYJKoZIhvcNAQkEMRYEFD6qku5KTsGk ZApsuhtNnCFeREyQMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHoGCSsGAQQBgjcQ BDFtMGswZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMD RG9EMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTkCAxVUgjB8 BgsqhkiG9w0BCRACCzFtoGswZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVu dDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlM IENBLTkCAxVUgjANBgkqhkiG9w0BAQEFAASBgBWSZqJDdPoIOI3jrBIAlOQ27PGMOw1JbKx1nhHR bNG1RIeVpp7Voj7MGMe6SGt9rKxKhdYp0i1VbY6UhR01ARmSQcaGZH2ZmxVVgvVLWlArJX/OmXeD P/RNjQSLu3PPI+pI+RKlUa1OjF5ZM/AT51aJfTwUl8ByjtgbzvMUKnrmAAAAAAAA ------=_NextPart_000_0168_01C80697.336AE150-- --===============0040674869== 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 --===============0040674869==-- From sip-bounces@ietf.org Thu Oct 04 15:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWAa-0006p6-LI; Thu, 04 Oct 2007 15:15:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdWAZ-0006jw-J1 for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWAZ-0006ib-7U for sip@ietf.org; Thu, 04 Oct 2007 15:15:35 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWAT-0004Rh-0K for sip@ietf.org; Thu, 04 Oct 2007 15:15:35 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l94JFLaR022671; Thu, 4 Oct 2007 14:15:21 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l94JFLj26721; Thu, 4 Oct 2007 14:15:21 -0500 (CDT) Message-ID: <47053BC9.5080404@alcatel-lucent.com> Date: Thu, 04 Oct 2007 14:15:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Nhan, Howard CIV DISA GES-E" Subject: Re: [Sip] Telephony Features RFCs (UNCLASSIFIED) References: <16BB45580B7F6A4D9CF65674DD7214F6024F1F6F@herzegovina.disanet.disa-u.mil> In-Reply-To: <16BB45580B7F6A4D9CF65674DD7214F6024F1F6F@herzegovina.disanet.disa-u.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: sip-bounces@ietf.org Nhan, Howard CIV DISA GES-E wrote: > Hi, > > I'm trying to compile a list of all RFCs (proposed standards, draft > standards, full standards, informational, ...) and I-Ds that pertain to > telephony features (e.g. call hold, call forward, call transfer, call > blocking, ...) > > Does anyone already have such a list? If not, could you suggest ways to > compile this list quickly and painlessly? As a start, I would suggest the following links: 1) The SIP Hitchhiker's guide (especially section 4 in it) http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-03 2) The BLISS working group http://www.ietf.org/html.charters/bliss-charter.html and some blissful drafts: http://tools.ietf.org/html/draft-elwell-bliss-dnd http://tools.ietf.org/html/draft-poetzl-bliss-call-completion http://tools.ietf.org/html/draft-procter-bliss-call-park-extension Regards, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 05 08:49:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdmWt-0004Nn-7r; Fri, 05 Oct 2007 08:43:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdmWr-0004KL-0b for sip-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 08:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdmWq-0004KD-Mr for sip@ietf.org; Fri, 05 Oct 2007 08:43:40 -0400 Received: from qb-out-0506.google.com ([72.14.204.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdmWk-00047p-A9 for sip@ietf.org; Fri, 05 Oct 2007 08:43:40 -0400 Received: by qb-out-0506.google.com with SMTP id o21so146718qba for ; Fri, 05 Oct 2007 05:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=6hZ0FkyoEvywKnP7DVkShQxgxDrt8A9dYMHLywzhlUs=; b=Mo1xfEdVhdFjqDqedUJgPNTr9DxJv6Rghqppv/xaUlidiXteidkiZNeCGGmRqHFeQPSZjS2ujNCjVU+xoZJ73YF6nOdxmleJcFMs5VCFT9Zg2niFRWc6FO4qhZ6Sna7NkgBHCmCGOAF7wUexyW29K4z9defUSmtQU7rmmXVcArM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TeohY1Spc3NhaU0EYkwXuq8sY3oqYhugPdFaoowKpDoqRqXXiyioDqawVikU5lWXZuShwG9K0cXEqXAur0pbV2dCHq1t0wxGKtsyyiLXzltHEs+PGsOckuqWburmQMlk8YZi5JvjiQU9JVNWGTFB1YzDW4nAJBn2SzmVnzrchTs= Received: by 10.142.72.21 with SMTP id u21mr3278134wfa.1191588195049; Fri, 05 Oct 2007 05:43:15 -0700 (PDT) Received: by 10.70.22.4 with HTTP; Fri, 5 Oct 2007 05:43:14 -0700 (PDT) Message-ID: <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> Date: Fri, 5 Oct 2007 14:43:14 +0200 From: "Pars Mutaf" To: "Dean Willis" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Content-Type: multipart/mixed; boundary="===============0824334157==" Errors-To: sip-bounces@ietf.org --===============0824334157== Content-Type: multipart/alternative; boundary="----=_Part_21662_13625387.1191588194935" ------=_Part_21662_13625387.1191588194935 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/28/07, Pars Mutaf wrote: > > Hello, > > Thanx for the message, I hope you and (other SIP experts) > subscribe to the ML: > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > Personally, I'm not sure if we need a store/forward > solution. We probably don't want to store a pairing > request message while the user is off-line. Because > the request message itself can be used for SPAM. > > Maybe a real-time solution is preferable. I.e., if > the target user is off-line we don't care. The querier > needs to try later to get the user's consent. > > Personally, I'm also against a SIP-based solution. > This is my personal opinion and of course open to > discussion. Hello, I'll feel more comfortable if I explain the above statement to SIP folks. I'm not defending any particular design, I'm trying to start some discussion and get more people to the list, and hoping to find the right choices together. For example there is also a serverless design possibility (for local use only) which also deserves attention IMHO, because of the obvious advantages of a serverless design: -I have a new phone, I want to pair it with that of a friend. -I type his name. -My phone issues a local multicast DNS query to his name over WiFi or WiMax. -Using multicast DNS my phone scans his name. -His phone returns an IP address (possibly a local/temporary one) and perhaps other info helping me deal with name collisions. -We use the proposed pairing protocol for exchanging our SIP URIs, fixed MIPv6 home addresses, create an IPsec SA etc. This is also another obvious design with pros and cons IMHO. Thanks, pars I really hope we can talk about these issues. > > Thanks, > pars > > On 9/28/07, Dean Willis wrote: > > > > > > On Sep 27, 2007, at 4:38 PM, Dale.Worley@comcast.net wrote: > > > > > From: "Pars Mutaf" > > > > > > The following is a new abstract solution, a third alternative, a > > > protocol > > > for "pairing" two cellular hosts: > > > > > > Model of operation > > > > > > 1. The querier user types the target user's "human name" (as if > > > he were > > > consulting a phonebook), or a pseudoynm. > > > 2. The pairing request is forwarded to the target phone. > > > 3. The query, along with the querier user's name, are displayed > > > on the > > > target phone's screen. > > > 4. The target user approves the request in real-time by pushing > > > on the YES > > > button of the phone. > > > 5. The two phones exchange their Mobile IPv6 home addresses, SIP > > > URIs, and > > > establish an IPsec security association (using IKEv2). > > > > > > How do you make this work? Step 2 seems to require that you have > > > already located the target phone, whereas the protocol's *purpose* is > > > to locate the target phone. > > > > > > > > > One possibility is that the directory service is operating on behalf > > of the target, not the searcher. As such, the directory service is > > trusted to know the display name to userID binding. When it receives > > a query, the directory service uses the target's SIP contact > > registration to send a consent request to the target user. If the > > target user response positively, then the directory service returns > > the directory's query result to the searcher. > > > > Basically, another layer of indirection (directory) in front of a > > watcher pattern. > > > > There are probably other embodiments, but that's the obvious one. > > > > -- > > 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 > > > > ------=_Part_21662_13625387.1191588194935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/28/07, Pars Mutaf <pars.mutaf@gmail.com> wrote:
Hello,

Thanx for the message, I hope you and (other SIP experts)
subscribe to the ML:

https://www1.ietf.org/mailman/listinfo/humanresolvers

Personally, I'm not sure if we need a store/forward
solution. We probably don't want to store a pairing
request message while the user is off-line. Because
the request message itself can be used for SPAM.

Maybe a real-time solution is preferable. I.e., if
the target user is off-line we don't care. The querier
needs to try later to get the user's consent.

Personally, I'm also against a SIP-based solution.
This is my personal opinion and of course open to
discussion.


Hello,
I'll feel more comfortable if I explain the above statement
to SIP folks. I'm not defending any particular design, I'm trying
to start some discussion and get more people to the list,
and hoping to find the right choices together.

For example there is also a serverless design possibility
(for local use only) which also deserves attention IMHO,
because of the obvious advantages of a serverless design:

-I have a new phone, I want to pair it with that of a friend.
-I type his name.
-My phone issues a local multicast DNS query to his name
over WiFi or WiMax.
-Using multicast DNS my phone scans his name.
-His phone returns an IP address (possibly a local/temporary one)
and perhaps other info helping me deal with name collisions.
-We use the proposed pairing protocol for exchanging our
SIP URIs, fixed MIPv6 home addresses, create an IPsec SA etc.

This is also another obvious design with pros and cons IMHO.

Thanks,
pars


I really hope we can talk about these issues.

Thanks,
pars


On 9/28/07, Dean Willis <dean.willis@softarmor.com> wrote:

On Sep 27, 2007, at 4:38 PM, Dale.Worley@comcast.net wrote:

>    From: "Pars Mutaf" < pars.mutaf@gmail.com>
>
>    The following is a new abstract solution, a third alternative, a
> protocol
>    for "pairing" two cellular hosts:
>
>    Model of operation
>
>    1. The querier user types the target user's "human name" (as if
> he were
>       consulting a phonebook), or a pseudoynm.
>    2. The pairing request is forwarded to the target phone.
>    3. The query, along with the querier user's name, are displayed
> on the
>       target phone's screen.
>    4. The target user approves the request in real-time by pushing
> on the YES
>       button of the phone.
>    5. The two phones exchange their Mobile IPv6 home addresses, SIP
> URIs, and
>       establish an IPsec security association (using IKEv2).
>
> How do you make this work?  Step 2 seems to require that you have
> already located the target phone, whereas the protocol's *purpose* is
> to locate the target phone.
>


One possibility is that the directory service is operating on behalf
of the target, not the searcher. As such, the directory service is
trusted to know the display name to userID binding. When it receives
a query, the directory service uses the target's SIP contact
registration to send a consent request to the target user. If the
target user response positively, then the directory service returns
the directory's query result to the searcher.

Basically, another layer of indirection (directory) in front of a
watcher pattern.

There are probably other embodiments, but that's the obvious one.

--
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


------=_Part_21662_13625387.1191588194935-- --===============0824334157== 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 --===============0824334157==-- From sip-bounces@ietf.org Fri Oct 05 13:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdrE4-00021E-0h; Fri, 05 Oct 2007 13:44:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdrE2-00020O-CT for sip-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdrE2-00020G-1u for sip@ietf.org; Fri, 05 Oct 2007 13:44:34 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdrDv-0006CC-TU for sip@ietf.org; Fri, 05 Oct 2007 13:44:34 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l95HiBW01963; Fri, 5 Oct 2007 17:44:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Telephony Features RFCs (UNCLASSIFIED) Date: Fri, 5 Oct 2007 12:44:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1251AEB7@zrc2hxm0.corp.nortel.com> In-Reply-To: <47053BC9.5080404@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Telephony Features RFCs (UNCLASSIFIED) thread-index: AcgGu/J4G2mQsBWiS0GJpkoQvkWbFQAuuURQ References: <16BB45580B7F6A4D9CF65674DD7214F6024F1F6F@herzegovina.disanet.disa-u.mil> <47053BC9.5080404@alcatel-lucent.com> From: "Francois Audet" To: "Vijay K. Gurbani" , "Nhan, Howard CIV DISA GES-E" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: sip-bounces@ietf.org Also: http://www.ietf.org/rfc/rfc3842.txt http://www.ietf.org/rfc/rfc4579.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-08.tx t http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples- 13.txt > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 > Sent: Thursday, October 04, 2007 12:15 > To: Nhan, Howard CIV DISA GES-E > Cc: IETF SIP List > Subject: Re: [Sip] Telephony Features RFCs (UNCLASSIFIED) >=20 > Nhan, Howard CIV DISA GES-E wrote: > > Hi, > >=20 > > I'm trying to compile a list of all RFCs (proposed standards, draft=20 > > standards, full standards, informational, ...) and I-Ds=20 > that pertain=20 > > to telephony features (e.g. call hold, call forward, call transfer,=20 > > call blocking, ...) > >=20 > > Does anyone already have such a list? If not, could you=20 > suggest ways=20 > > to compile this list quickly and painlessly? >=20 > As a start, I would suggest the following links: >=20 > 1) The SIP Hitchhiker's guide (especially section 4 in it) > http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-03 >=20 > 2) The BLISS working group > http://www.ietf.org/html.charters/bliss-charter.html > and some blissful drafts: > http://tools.ietf.org/html/draft-elwell-bliss-dnd > http://tools.ietf.org/html/draft-poetzl-bliss-call-completion > =20 > http://tools.ietf.org/html/draft-procter-bliss-call-park-extension >=20 > Regards, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >=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 07 23:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iej2Z-00016t-OD; Sun, 07 Oct 2007 23:12:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iej2Y-00016m-VQ for sip-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 23:12:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iej2Y-0000lu-Jw for sip@ietf.org; Sun, 07 Oct 2007 23:12:18 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iej2N-00076N-Pe for sip@ietf.org; Sun, 07 Oct 2007 23:12:08 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l983C4O17995; Mon, 8 Oct 2007 03:12:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Sun, 7 Oct 2007 22:11:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1256EA6D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAAK6PvNA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel! ! ! .com> < 8F65DB27- 41ED-42F3-97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Francois Audet" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Thursday, October 04, 2007 10:56 AM > To: Dean Willis > Cc: IETF SIP List > Subject: RE: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 > There is a missing point in here. >=20 > When you say "new uses of INFO are not being accepted by the=20 > IETF for the following reasons", the problem is that people=20 > are overstating their case when discussing the "reasons".=20 > This in turn is annoying people who find the "reasons" not=20 > technically accurate. >=20 > I'd rather we try to avoid "inventing" reasons and getting=20 > into silly long arguments. Yes, exactly. >=20 > We could say something very simple in that draft. Something=20 > like, INFO was created as a general transport mechanism in=20 > SIP. As SIP evolved, new mechanisms for different usages were=20 > created (then we can list them, and give KPML as an example=20 > for keypress). And then just say that new usages beyond the=20 > existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. >=20 > And leave it to that. I personally would support such a document. >=20 > Any attempt at inventing complex reasons will just encourage=20 > people to find flaws in the arguments. People like me. I'd rather there be no reason than a bad reason. Bad reasons tend to get exploited and extended to other support further bad ideas/reasons down the road. >=20 > But, again, I'm happy with the status quo. >=20 > > If we had an RFC that said "New uses of INFO are not being=20 > accepted by=20 > > the IETF for the following reasons, please use something=20 > else (like an=20 > > event package) instead" then people might be less tempted=20 > to use INFO,=20 > > or at least to bring it to the IETF. > >=20 > > I think we have a consensus on this point. We have some debate on=20 > > whether it's worth developing such an RFC, but I think everybody=20 > > understands this path. > >=20 > > However, there's a second problem, and people keep getting=20 > these two=20 > > problems confused (or at least thinking we are discussing the first=20 > > problem when we're really discussing the second) hence we=20 > go around in=20 > > a circle. > >=20 > > The second problem is "People are using INFO because it has certain=20 > > advantages that make it more attractive than a new event=20 > package for=20 > > some applications. If we fixed the problems with INFO negotiation=20 > > without losing these advantages, the community would=20 > benefit greatly=20 > > as a result." > >=20 > > This is the problem whose threads contain things like "KPML=20 > is a much=20 > > less efficient mechanism for driving telephone applications=20 > that use=20 > > DTMF than DTMF over INFO". > >=20 > > So, there are at least TWO PROBLEMS. Why don't we have at least two=20 > > solutions? > >=20 > > Perhaps we could document the flaws with INFO's design and=20 > explain, as=20 > > a BCP, why we don't recommend using it and why IETF should=20 > not proceed=20 > > with new usages of INFO as long as those flaws persist. > >=20 > > This would not preclude a second standards-track effort (if=20 > we wish to=20 > > pursue it) to fix INFO, or replace it with a new in-dialog=20 > > contextually negotiated content transfer mechanism. > >=20 > > It would also not preclude standards-track efforts to replace=20 > > individual INFO usages with new SIP methods (if we wish to pursue=20 > > them). For example, there's no reason why we couldn't replace ISUP-=20 > > over-INFO with a new SIP method "ISUP", TSIG over INFO with=20 > a new SIP=20 > > method "TSIG", DTMF-over-INFO with a new SIP method "DTMF",=20 > and so on. > >=20 > > This gets back to my rant some months ago about the SIP=20 > community not=20 > > having consensus on one extension methodology, thereby giving us=20 > > multiple extension methodologies that compete (and possibly > > conflict) > > with each other. We don't agree whether SIP is an=20 > application protocol=20 > > or a transport protocol, so we've made it into both at the=20 > same time.=20 > > It's about time we grapple with this issue and establish a practice=20 > > going forward. > >=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=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 Mon Oct 08 09:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesJe-0003t5-Mh; Mon, 08 Oct 2007 09:06:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IesJb-0003sd-TE for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 09:06:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IesJb-0003sP-I1 for sip@ietf.org; Mon, 08 Oct 2007 09:06:31 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IesJb-0005su-2B for sip@ietf.org; Mon, 08 Oct 2007 09:06:31 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IesJa-00030L-5d for sip@ietf.org; Mon, 08 Oct 2007 09:06:30 -0400 Received: from col-dhcp33-244-153.bbn.com ([128.33.244.153] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IesJa-0007jm-6v for sip@ietf.org; Mon, 08 Oct 2007 09:06:30 -0400 Message-ID: <470A2B54.6060905@bbn.com> Date: Mon, 08 Oct 2007 09:06:28 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-00 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: , Errors-To: sip-bounces@ietf.org ------------------------------------------------------- Document: draft-ietf-sip-media-security-requirements-00 Reviewer: Richard Barnes, BBN Review Date: 06 September 2007 ------------------------------------------------------- 1. As a document proposing requirements for a security protocol, this document needs more discussion of the system being protected and the level of protection that the desired protocol is to support. Section 5 is a good start on this, and it should be moved forward to be just after the Terminology section. 2. I think the fundamental security requirement that you're driving at is that the protocol should have a mode of operation in which an attacker must mount active attacks on BOTH the signaling and media path in order to gain access to the keys being negotiated by the protocol, and that even in this case, the attack should be detectable by the endpoints. This is essentially what's being encoded in requirements R1, R2, and R17, but this should be made clearer in these requirements, and in the security analysis section (i.e., Section 5). 3. Requirements R23, R24, R25 are inappropriate for this document, in that they conflict directly with the security requirements (R1, R2, R17). A well-designed key-exchange protocol *should* be able to detect a middle-man, authorized or not. Lawful intercept should be handled outside of the key management protocol, as in draft-wing-sipping-srtp-key. 4. This document needs several more terms defined in the Terminology. The three I spotted were: "media path", "signaling path", and "perfect forward secrecy". PFS is already defined in the requirements; this text should just be moved to the Terminology section. 5. If we intend this document to move quickly toward RFC status, it seems like the evaluation appendices will have to be deleted, or at least the parts of them that refer to protocols that are not RFCs or not on their way. 6. Section 3.1 and 3.3 do not appear to be directly related to the requirements as stated. They should be moved to sections B.2 and B.3, respectively (like the text on SSRCs and ROCs). 7. Sections C.1 and C.3 should be deleted. Section C.1. is predicated on the notion that protocols require a PKI to be used, when in reality (as was discussed extensively on rtpsec), any protocol that can be used with a PKI can be used with self-signed certificates if both endpoints are willing. Section C.3. tries to evaluate whether solutions can do best-effort security, while ignoring the work that has been done on SDP capability negotiation. *. (nit) Throughout, the word "keying" is used to mean the process of key negotiation/exchange or key management. It should be replaced by those terms as appropriate. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 08 11:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieu86-0006tj-Gz; Mon, 08 Oct 2007 11:02:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ieu84-0006t8-M3 for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 11:02:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieu84-0006sz-9s for sip@ietf.org; Mon, 08 Oct 2007 11:02:44 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ieu83-0003AY-7H for sip@ietf.org; Mon, 08 Oct 2007 11:02:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l98F2eXc102036 for ; Mon, 8 Oct 2007 15:02:40 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l98F2e4s1269794 for ; Mon, 8 Oct 2007 17:02:40 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l98F2ePi012818 for ; Mon, 8 Oct 2007 17:02:40 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l98F2dZQ012808; Mon, 8 Oct 2007 17:02:39 +0200 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Mon, 8 Oct 2007 17:02:38 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 08/10/2007 17:02:39, Serialize complete at 08/10/2007 17:02:39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: draft-ietf-sip-subnot-etags@tools.ietf.org Subject: [Sip] Review of draft-ietf-sip-subnot-etags-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: , Content-Type: multipart/mixed; boundary="===============0000209942==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0000209942== Content-Type: multipart/alternative; boundary="=_alternative 0052A4B3C225736E_=" This is a multipart message in MIME format. --=_alternative 0052A4B3C225736E_= Content-Type: text/plain; charset="US-ASCII" Several comments: ------------- A possible security issue with the following scenario: a) Subscriber subscribes with Suppress-Body-If-Match header with etag of e1. b) The document has changed but what was changed is suppressed from that subscriber due to privacy. c) The subscriber will get notify with new tag but with the same document. If the subscriber wants to it can compare to the previous value and understand that something is being suppressed from it. ------------- Section 5.2 - second paragraph "the first notification after the SUBSCRIBE" sounds as the first new notification due to state change after the SUBSCRIBE. Maybe it is better to write "the immediate notification following the SUBSCRIBE". Note that there are other occurrences of the usage of "first" if you decide to change. ------------- Section 5.2 - Last paragraph before the examples typo - "simply copies" should be "simply copied" ------------- Section 5.2 - last example Maybe there should be some explanation of why * is needed earlier in the document. Liveliness use case is described below but maybe better to explain earlier in the doc ------------- Figure 4 ... poll interval elapses Should probably be "... poll interval elapses immediately" Since it is zero initially. Section 5.6 Should not this be the first use case described? From bandwidth pov it is the most important. ------------- Section 6.1 " ...The notifier MUST remember the entity-tag of an entity as long as the version of the entity is current. The notifier MAY remember the entity-tag longer than this, e.g., for implementing journaled state differentials (Section 6.4). " I understood from the text that the etag can be deleted by the notifier when there is no current value to the entity. Consider the case when a subscriber subscribed and got entity e1. Meanwhile the resource has become stale (all previous publishes expired). After e.g. two days the subscriber tries to subscribe with e1 for the suppressing condition. What will the notifier selecting e1 as the current entity tag again? If it does so the subscriber will not get a notify (or body of notify) while it should have gotten one. I hope that this is only my misunderstanding. ------------- Comment from Ofira Tal (IBM) Should we consider the change of the entity tag as a reason to send a notify with the entity tag only even though there is no need to send an actual notify to the subscriber since the change affects filtered information due to privacy or just filtering. This will enable avoiding redundant NOTIFY in subsequent subscribes since the latest entity tag will be used. --Avshalom --=_alternative 0052A4B3C225736E_= Content-Type: text/html; charset="US-ASCII"
Several comments:

-------------
A possible security issue with the following scenario:
a) Subscriber subscribes with Suppress-Body-If-Match header with
etag of e1.
b) The document has changed but what was changed is suppressed from
that subscriber due to privacy.
c) The subscriber will get notify with new tag but with the same
document.

If the subscriber wants to it can compare to the previous value and
understand that something is being suppressed from it.

-------------
Section 5.2 - second paragraph
"the first notification after the SUBSCRIBE" sounds as the first new
notification due to state change after the SUBSCRIBE. Maybe it is better
to write "the immediate notification following the SUBSCRIBE".
Note that there are other occurrences of the usage of "first" if you
decide to change.

-------------
Section 5.2 - Last paragraph before the examples
typo - "simply copies"  should be  "simply copied"

-------------
Section 5.2 - last example

Maybe there should be some explanation of why * is needed earlier
in the document. Liveliness use case is described below but maybe
better to explain earlier in the doc

-------------
Figure 4
          ... poll interval elapses

Should probably be  "... poll interval elapses immediately"
Since it is zero initially.

Section 5.6
Should not this be the first use case described? From bandwidth pov
it is the most important.

-------------
Section 6.1

"
...The notifier MUST remember the entity-tag of an entity as long
   as the version of the entity is current.  The notifier MAY remember
   the entity-tag longer than this, e.g., for implementing journaled
   state differentials (Section 6.4).
"

I understood from the text that the etag can be deleted by the notifier
when there is no current value to the entity. Consider the case when
a subscriber subscribed and got entity e1. Meanwhile the resource has become
stale (all previous publishes expired).
After e.g. two days the subscriber tries to subscribe with e1 for
the suppressing condition. What will the notifier selecting e1 as the
current entity tag again? If it does so the subscriber will not get
a notify (or body of notify) while it should have gotten one.
I hope that this is only my misunderstanding.

-------------
Comment from Ofira Tal (IBM)

Should we consider the change of the entity tag as a reason to
send a notify with the entity tag only even though there is no
need to send an actual notify to the subscriber since the change
affects filtered information due to privacy or just filtering.
This will enable avoiding redundant NOTIFY in subsequent
subscribes since the latest entity tag will be used.

--Avshalom




 --=_alternative 0052A4B3C225736E_=-- --===============0000209942== 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 --===============0000209942==-- From sip-bounces@ietf.org Mon Oct 08 15:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iexn5-0007dN-U4; Mon, 08 Oct 2007 14:57:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iexn1-0007bP-Ul for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 14:57:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iexn0-0007ZH-1N; Mon, 08 Oct 2007 14:57:15 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iexmz-0003QL-NE; Mon, 08 Oct 2007 14:57:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 945AE2AC6F; Mon, 8 Oct 2007 18:57:13 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iexmz-0007si-Ah; Mon, 08 Oct 2007 14:57:13 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 08 Oct 2007 14:57:13 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Rejecting Anonymous Requests in 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: , Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt Technical Summary This document defines an extension to the Session Initiation Protocol providing a new response code that may be used to reject an anonymous request so that the requesting party can understand that the request was rejected because it was made anonymously and could reasonably be expected to succeed if retried without anonymity. Working Group Summary The requirement addressed by this document was identified by ETSI TISPAN. The SIPPING working group discussed the requirement and determined that a SIP extension would be required to address that requirement. The technique specified by this document was originally introduced in an individual document submitted by Jonathan Rosenberg and discussed in the SIP working group. The SIP working group rapidly achieved consensus on the approach and recommended establishing a working group milestone for this work. There was no controversy within the SIP working group on the direction of this work. Document Quality This is a very simple extension to the SIP protocol. It is expected to be widely implemented in SIP systems interacting with the switched telephone networks of the world. Since it addresses requirements from ETSI TISPAN, participants from that organization were asked to review the specification and reported that it is suitable for their needs. Personnel The document shepherd is Dean Willis. The responsible area director is Cullen Jennings. No IANA expert, MIB doctor, or other specialized contributor is required. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 08 15:16:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iey3M-0001Z8-UW; Mon, 08 Oct 2007 15:14:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iey3L-0001VA-E7 for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 15:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iey3K-0001SR-Kg for sip@ietf.org; Mon, 08 Oct 2007 15:14:07 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iey3G-0001QU-KI for sip@ietf.org; Mon, 08 Oct 2007 15:14:06 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l98JDgrA031243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2007 14:13:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <470A816C.1040304@nostrum.com> Date: Mon, 08 Oct 2007 14:13:48 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel! ! ! .com> < 8F65DB27- 41ED-42F3-97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1256EA6D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1256EA6D@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4506/Mon Oct 8 11:43:33 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , Francois Audet , 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: , Errors-To: sip-bounces@ietf.org On 10/7/07 10:11 PM, Brian Stucker wrote: > >> From: Audet, Francois (SC100:3055) >> >> We could say something very simple in that draft. Something >> like, INFO was created as a general transport mechanism in >> SIP. As SIP evolved, new mechanisms for different usages were >> created (then we can list them, and give KPML as an example >> for keypress). And then just say that new usages beyond the >> existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. >> >> And leave it to that. >> > > I personally would support such a document. > As would I. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 08 17:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iezvz-0005Zg-7i; Mon, 08 Oct 2007 17:14:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iezvx-0005ZZ-Ik for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 17:14:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iezvx-0005ZR-80 for sip@ietf.org; Mon, 08 Oct 2007 17:14:37 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iezvw-0007XN-Jq for sip@ietf.org; Mon, 08 Oct 2007 17:14:37 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l98LEJVp022754; Mon, 8 Oct 2007 14:14:19 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l98LEGBN020513; Mon, 8 Oct 2007 14:14:17 -0700 Received: from 10.43.242.47 ([10.43.242.47]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Oct 2007 21:14:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 08 Oct 2007 17:14:12 -0400 Subject: Re: [Sip] Telephony Features RFCs (UNCLASSIFIED) From: Eric Burger To: "Nhan, Howard CIV DISA GES-E" Message-ID: Thread-Topic: [Sip] Telephony Features RFCs (UNCLASSIFIED) Thread-Index: AcgGu/J4G2mQsBWiS0GJpkoQvkWbFQAuuURQAJ5VMK8= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1251AEB7@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Errors-To: sip-bounces@ietf.org Just for grins, would you mind posting the results of your research? Some here think the preponderance of our time is being spent on recreating telephony features. Others think it is a small amount of time. Nothing like some hard data to settle a bet. Thanks. On 10/5/07 1:44 PM, "Francois Audet" wrote: > Also: > http://www.ietf.org/rfc/rfc3842.txt > http://www.ietf.org/rfc/rfc4579.txt > http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-08.tx > t > http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples- > 13.txt > >> -----Original Message----- >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >> Sent: Thursday, October 04, 2007 12:15 >> To: Nhan, Howard CIV DISA GES-E >> Cc: IETF SIP List >> Subject: Re: [Sip] Telephony Features RFCs (UNCLASSIFIED) >> >> Nhan, Howard CIV DISA GES-E wrote: >>> Hi, >>> >>> I'm trying to compile a list of all RFCs (proposed standards, draft >>> standards, full standards, informational, ...) and I-Ds >> that pertain >>> to telephony features (e.g. call hold, call forward, call transfer, >>> call blocking, ...) >>> >>> Does anyone already have such a list? If not, could you >> suggest ways >>> to compile this list quickly and painlessly? >> >> As a start, I would suggest the following links: >> >> 1) The SIP Hitchhiker's guide (especially section 4 in it) >> http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-03 >> >> 2) The BLISS working group >> http://www.ietf.org/html.charters/bliss-charter.html >> and some blissful drafts: >> http://tools.ietf.org/html/draft-elwell-bliss-dnd >> http://tools.ietf.org/html/draft-poetzl-bliss-call-completion >> >> http://tools.ietf.org/html/draft-procter-bliss-call-park-extension >> >> Regards, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 08 17:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IezuB-0003Vk-5W; Mon, 08 Oct 2007 17:12:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iezu9-0003TT-QX for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 17:12:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iezu9-0003TL-FG for sip@ietf.org; Mon, 08 Oct 2007 17:12:45 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iezu8-0007UO-O2 for sip@ietf.org; Mon, 08 Oct 2007 17:12:45 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l98LCfmH020104; Mon, 8 Oct 2007 14:12:41 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l98LCLeT019654; Mon, 8 Oct 2007 14:12:39 -0700 Received: from 10.43.242.47 ([10.43.242.47]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Oct 2007 21:12:32 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 08 Oct 2007 17:12:28 -0400 Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) From: Eric Burger To: Fran=?ISO-8859-1?B?5w==?=ois Audet Message-ID: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAANRquiY= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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: , Errors-To: sip-bounces@ietf.org So, what is missing, or what should be taken out, of draft-burger-sip-info? I think what you propose is what the document says. Help me out here! On 10/4/07 11:56 AM, "Audet, Francois (SC100:3055)" wrote: > There is a missing point in here. > > When you say "new uses of INFO are not being accepted by the IETF for > the > following reasons", the problem is that people are overstating their > case > when discussing the "reasons". This in turn is annoying people who find > the "reasons" not technically accurate. > > I'd rather we try to avoid "inventing" reasons and getting into silly > long arguments. > > We could say something very simple in that draft. Something like, INFO > was > created as a general transport mechanism in SIP. As SIP evolved, new > mechanisms for different usages were created (then we can list them, > and give KPML as an example for keypress). And then just say that new > usages beyond the existing ones, i.e., ISUP/QSIG tunnelling, are > therefore > deprecated. > > And leave it to that. > > Any attempt at inventing complex reasons will just encourage people to > find flaws in the arguments. > > But, again, I'm happy with the status quo. > >> If we had an RFC that said "New uses of INFO are not being accepted >> by the IETF for the following reasons, please use something else >> (like an event package) instead" then people might be less >> tempted to >> use INFO, or at least to bring it to the IETF. >> >> I think we have a consensus on this point. We have some debate on >> whether it's worth developing such an RFC, but I think everybody >> understands this path. >> >> However, there's a second problem, and people keep getting these two >> problems confused (or at least thinking we are discussing the first >> problem when we're really discussing the second) hence we go around >> in a circle. >> >> The second problem is "People are using INFO because it has certain >> advantages that make it more attractive than a new event package for >> some applications. If we fixed the problems with INFO negotiation >> without losing these advantages, the community would benefit greatly >> as a result." >> >> This is the problem whose threads contain things like "KPML >> is a much >> less efficient mechanism for driving telephone applications that use >> DTMF than DTMF over INFO". >> >> So, there are at least TWO PROBLEMS. Why don't we have at least two >> solutions? >> >> Perhaps we could document the flaws with INFO's design and explain, >> as a BCP, why we don't recommend using it and why IETF should not >> proceed with new usages of INFO as long as those flaws persist. >> >> This would not preclude a second standards-track effort (if we wish >> to pursue it) to fix INFO, or replace it with a new in-dialog >> contextually negotiated content transfer mechanism. >> >> It would also not preclude standards-track efforts to replace >> individual INFO usages with new SIP methods (if we wish to pursue >> them). For example, there's no reason why we couldn't replace ISUP- >> over-INFO with a new SIP method "ISUP", TSIG over INFO with a >> new SIP >> method "TSIG", DTMF-over-INFO with a new SIP method "DTMF", and so on. >> >> This gets back to my rant some months ago about the SIP >> community not >> having consensus on one extension methodology, thereby giving us >> multiple extension methodologies that compete (and possibly >> conflict) >> with each other. We don't agree whether SIP is an application >> protocol or a transport protocol, so we've made it into both at the >> same time. It's about time we grapple with this issue and >> establish a >> practice going forward. >> >> -- >> 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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 08 18:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1Hv-0001Yw-PD; Mon, 08 Oct 2007 18:41:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1If1Hu-0001Va-Oi for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 18:41:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1Hu-0001Tc-Ax for sip@ietf.org; Mon, 08 Oct 2007 18:41:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If1Ht-0001K7-Fb for sip@ietf.org; Mon, 08 Oct 2007 18:41:22 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l98MfIS16660; Mon, 8 Oct 2007 22:41:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Mon, 8 Oct 2007 17:41:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF125D62E5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAANRquiYAAQGRkA== References: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Eric Burger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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: , Errors-To: sip-bounces@ietf.org The Abstract should say something like: The purpose of the INFO request for the Session Initiation Protocol (SIP), as described by RFC 2976, is to provide mid-session SIP User Agent (UA)-to-SIP UA application data transport. In the years since the introduction of the INFO request, experience with the use of the INFO request indicates a number of problems. This document explains why there are INFO-based, proprietary protocols in the wild; the flaws of using INFO; and explains why it is not possible to create a framework to rescue INFO for general purpose use. Thus, this document restricts the use of INFO to call establishment signaling, as described in RFC 3372 (SIP-T).=20 The INFO method was created as a general transport mechanism in SIP.=20 As SIP has evolved since then, new mechanisms for different usages=20 were created. As these mechanisms are now available, this document formally deprecates the use of INFO for new usages beyond the existing standardized ones (i.e., ISUP and QSIG tunnelling). =20 In section 1, instead of having this rethorical description of why INFO is useful, just explain that originally INFO was defined for call associated signalling (ISUP and QSIG). Then explain that the mechanism was then used as a generic SIP transport because it was there, for DTMF, MSCML, etc. Then explain that standard mechanisms were defined for DTMF, etc.=20 I think we need to ditch section 2 altogether ("Flaws with INFO"). That's the part that people really have problems with. Then your current section 3 would describe the existing mechanisms. 3.2 should mention both RFC 2833 and KPML. I would remove 3.4. Also remove 3.5 (we don't need to be defensive: KPML would be used here). Section 4 is OK. I think we should add there IETF will not standardize any more usages of INFO. > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Monday, October 08, 2007 14:12 > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 > So, what is missing, or what should be taken out, of=20 > draft-burger-sip-info? > I think what you propose is what the document says. Help me out here! >=20 >=20 > On 10/4/07 11:56 AM, "Audet, Francois (SC100:3055)" > wrote: >=20 > > There is a missing point in here. > >=20 > > When you say "new uses of INFO are not being accepted by=20 > the IETF for=20 > > the following reasons", the problem is that people are overstating=20 > > their case when discussing the "reasons". This in turn is annoying=20 > > people who find the "reasons" not technically accurate. > >=20 > > I'd rather we try to avoid "inventing" reasons and getting=20 > into silly=20 > > long arguments. > >=20 > > We could say something very simple in that draft. Something=20 > like, INFO=20 > > was created as a general transport mechanism in SIP. As SIP=20 > evolved,=20 > > new mechanisms for different usages were created (then we can list=20 > > them, and give KPML as an example for keypress). And then just say=20 > > that new usages beyond the existing ones, i.e., ISUP/QSIG=20 > tunnelling,=20 > > are therefore deprecated. > >=20 > > And leave it to that. > >=20 > > Any attempt at inventing complex reasons will just=20 > encourage people to=20 > > find flaws in the arguments. > >=20 > > But, again, I'm happy with the status quo. > >=20 > >> If we had an RFC that said "New uses of INFO are not being=20 > accepted=20 > >> by the IETF for the following reasons, please use something else=20 > >> (like an event package) instead" then people might be less=20 > tempted to=20 > >> use INFO, or at least to bring it to the IETF. > >>=20 > >> I think we have a consensus on this point. We have some debate on=20 > >> whether it's worth developing such an RFC, but I think everybody=20 > >> understands this path. > >>=20 > >> However, there's a second problem, and people keep getting=20 > these two=20 > >> problems confused (or at least thinking we are discussing=20 > the first=20 > >> problem when we're really discussing the second) hence we=20 > go around=20 > >> in a circle. > >>=20 > >> The second problem is "People are using INFO because it=20 > has certain=20 > >> advantages that make it more attractive than a new event=20 > package for=20 > >> some applications. If we fixed the problems with INFO negotiation=20 > >> without losing these advantages, the community would=20 > benefit greatly=20 > >> as a result." > >>=20 > >> This is the problem whose threads contain things like=20 > "KPML is a much=20 > >> less efficient mechanism for driving telephone=20 > applications that use=20 > >> DTMF than DTMF over INFO". > >>=20 > >> So, there are at least TWO PROBLEMS. Why don't we have at=20 > least two=20 > >> solutions? > >>=20 > >> Perhaps we could document the flaws with INFO's design and=20 > explain,=20 > >> as a BCP, why we don't recommend using it and why IETF should not=20 > >> proceed with new usages of INFO as long as those flaws persist. > >>=20 > >> This would not preclude a second standards-track effort=20 > (if we wish=20 > >> to pursue it) to fix INFO, or replace it with a new in-dialog=20 > >> contextually negotiated content transfer mechanism. > >>=20 > >> It would also not preclude standards-track efforts to replace=20 > >> individual INFO usages with new SIP methods (if we wish to pursue=20 > >> them). For example, there's no reason why we couldn't=20 > replace ISUP-=20 > >> over-INFO with a new SIP method "ISUP", TSIG over INFO=20 > with a new SIP=20 > >> method "TSIG", DTMF-over-INFO with a new SIP method=20 > "DTMF", and so on. > >>=20 > >> This gets back to my rant some months ago about the SIP=20 > community not=20 > >> having consensus on one extension methodology, thereby giving us=20 > >> multiple extension methodologies that compete (and possibly > >> conflict) > >> with each other. We don't agree whether SIP is an application=20 > >> protocol or a transport protocol, so we've made it into=20 > both at the=20 > >> same time. It's about time we grapple with this issue and=20 > establish a=20 > >> practice going forward. > >>=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=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 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 08 19:10:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1gj-00070Y-PE; Mon, 08 Oct 2007 19:07:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1If1gh-0006y3-Vs for sip-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 19:06:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If1gh-0006Zm-LQ for sip@ietf.org; Mon, 08 Oct 2007 19:06:59 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If1gS-00029z-7M for sip@ietf.org; Mon, 08 Oct 2007 19:06:44 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20071008230639m1500ie59le>; Mon, 8 Oct 2007 23:06:43 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l98N6c29012628 for ; Mon, 8 Oct 2007 19:06:38 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l98N6c8T012624; Mon, 8 Oct 2007 19:06:38 -0400 Date: Mon, 8 Oct 2007 19:06:38 -0400 Message-Id: <200710082306.l98N6c8T012624@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> (pars.mutaf@gmail.com) Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Errors-To: sip-bounces@ietf.org From: "Pars Mutaf" I'll feel more comfortable if I explain the above statement to SIP folks. I'm not defending any particular design, I'm trying to start some discussion and get more people to the list, and hoping to find the right choices together. What is the problem you are trying to solve? 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 Tue Oct 09 04:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAHU-00081V-Si; Tue, 09 Oct 2007 04:17:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfAHS-0007z0-VG for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 04:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAHS-0007yn-JY for sip@ietf.org; Tue, 09 Oct 2007 04:17:30 -0400 Received: from ag-out-0708.google.com ([72.14.246.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfAHL-0005ns-Cs for sip@ietf.org; Tue, 09 Oct 2007 04:17:30 -0400 Received: by ag-out-0708.google.com with SMTP id 8so434300agc for ; Tue, 09 Oct 2007 01:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=vzsbpJ6/IvqHfhlhlv5lR02tLi67s5K2SgoDV9GC4EE=; b=ngl1pwQiS+A0023045xEG1X5FLULcplpySVFXcMAbqGsYBKH2r0uWtUxWqzuxXFeZ+aKlpCQITvQSyzpulRBXyxypGJj/JiPQIgIZjQTYXt7b6tl+LEhYsbXhWCp+Vx8+Pt6PluBjZbRmXPi7kl4YuOSv8ozGplvnSRtJ9vdGNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ajLO8Fhwe5AdM6XRi+2XtOMFUHS8eJdu18PAdSISWLlB+TSsMOGj3Q4oE9lXBpqwP2Kr3MZMcWelth3YGaKHJ3ua6STMHP3JPcH0qCs7EEi9qJgegCJkyLER1E8w4RbPqJizjs8qW5AGxoL4KoEop5T6tmu08T/X9TNVDXKTPUg= Received: by 10.70.72.1 with SMTP id u1mr5065937wxa.1191917822278; Tue, 09 Oct 2007 01:17:02 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 9 Oct 2007 01:17:02 -0700 (PDT) Message-ID: <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> Date: Tue, 9 Oct 2007 10:17:02 +0200 From: "Pars Mutaf" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <200710082306.l98N6c8T012624@dragon.ariadne.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Content-Type: multipart/mixed; boundary="===============0042388333==" Errors-To: sip-bounces@ietf.org --===============0042388333== Content-Type: multipart/alternative; boundary="----=_Part_53733_30040992.1191917822268" ------=_Part_53733_30040992.1191917822268 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Dale.Worley@comcast.net wrote: > > From: "Pars Mutaf" > > I'll feel more comfortable if I explain the above statement > to SIP folks. I'm not defending any particular design, I'm trying > to start some discussion and get more people to the list, > and hoping to find the right choices together. > > What is the problem you are trying to solve? Thanks. I tried to introduce the problem in my first mail which was perhaps too long: http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html Briefly: the problem is that users cannot publish their identifiers e.g. SIP URIs, for privacy reasons. They are obligated to exchange their contact information manually upon face-to-face contact. But face-to-face contact is not always available, and even if it is available manual exchange is difficult. Details are in the e-mail cited above :-) Please note that I invited IETF SIP researchers because they are expert in telephony (i.e. the general idea, not only SIP). Thanks, pars 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 > ------=_Part_53733_30040992.1191917822268 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Dale.Worley@comcast.net <Dale.Worley@comcast.net> wrote:
   From: "Pars Mutaf" <pars.mutaf@gmail.com >

   I'll feel more comfortable if I explain the above statement
   to SIP folks. I'm not defending any particular design, I'm trying
   to start some discussion and get more people to the list,
   and hoping to find the right choices together.

What is the problem you are trying to solve?

Thanks. I tried to introduce the problem in my first
mail which was perhaps too long:
http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html

Briefly: the problem is that users cannot publish their
identifiers e.g. SIP URIs, for privacy reasons. They are
obligated to exchange their contact information manually
upon face-to-face contact. But face-to-face contact is not
always available, and even if it is available manual
exchange is difficult.

Details are in the e-mail cited above :-)

Please note that I invited IETF SIP researchers because they
are expert in telephony (i.e. the general idea, not only SIP).

Thanks,
pars


 

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

------=_Part_53733_30040992.1191917822268-- --===============0042388333== 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 --===============0042388333==-- From sip-bounces@ietf.org Tue Oct 09 08:31:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfE9A-0006b5-T3; Tue, 09 Oct 2007 08:25:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfE99-0006ay-Gv for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 08:25:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfE99-0006Zk-4E for sip@ietf.org; Tue, 09 Oct 2007 08:25:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfE98-0000WQ-I9 for sip@ietf.org; Tue, 09 Oct 2007 08:25:10 -0400 X-IronPort-AV: E=Sophos;i="4.21,248,1188802800"; d="scan'208";a="233264342" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2007 05:25:08 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l99CP74B009675; Tue, 9 Oct 2007 05:25:07 -0700 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 l99COnd7001194; Tue, 9 Oct 2007 12:25:07 GMT 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.1830); Tue, 9 Oct 2007 08:24:32 -0400 Received: from [10.86.241.48] ([10.86.241.48]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 08:24:32 -0400 Message-ID: <470B72FF.3010000@cisco.com> Date: Tue, 09 Oct 2007 08:24:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> In-Reply-To: <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 12:24:32.0251 (UTC) FILETIME=[58804CB0:01C80A6F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--23.696500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2641; t=1191932707; x=1192796707; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20IETF=20solution=20for=20pairing=20cellular=20 hosts |Sender:=20; bh=jEgW3xEXMPmlxnq0MEaMuLk14zr4yYG3POr4Fv7zyPs=; b=sfVHvIzGWD/09Qi7vxEWGImwU5ap5borQwayC7GFQYFIh5SQrgcpB+PDhrivHEMLUjOpaq/f y67s6SFIcd/4Hgd5oQSP6Wav6t7UlftTEEnG1Zk0DRaTrJ13/MW5v/YtSy6yCY0oMvd0Yq1DKK CohRwg73lqyheUUQcRwhE1R8U=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > On 10/9/07, *Dale.Worley@comcast.net * > > wrote: > > From: "Pars Mutaf" > > > I'll feel more comfortable if I explain the above statement > to SIP folks. I'm not defending any particular design, I'm trying > to start some discussion and get more people to the list, > and hoping to find the right choices together. > > What is the problem you are trying to solve? > > > Thanks. I tried to introduce the problem in my first > mail which was perhaps too long: > http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html > > Briefly: the problem is that users cannot publish their > identifiers e.g. SIP URIs, for privacy reasons. They are > obligated to exchange their contact information manually > upon face-to-face contact. But face-to-face contact is not > always available, and even if it is available manual > exchange is difficult. Maybe I'm missing something, but it seems to me that what you are seeking is exactly the function provided by a sip registrar. Your requirements from the referenced mail are: > Model of operation > > 1. The querier user types the target user's "human name" (as if he were > consulting a phonebook), or a pseudoynm. An AOR: sip:name@domain. > 2. The pairing request is forwarded to the target phone. The request is forwarded to the home proxy associated with the registrar. Then it is forwarded to a registered target phone. The caller doesn't need to ever know the actual address of the target phone. > 3. The query, along with the querier user's name, are displayed on the > target phone's screen. The target phone rings. The callerid information is typically displayed by that phone. > 4. The target user approves the request in real-time by pushing on the YES > button of the phone. The target user approves the request by answering the phone. > 5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and > establish an IPsec security association (using IKEv2). The calling phone provided its contact address in the INVITE. The target phone returns its contact address in the response to the invite. They have also exchanged media addresses in SDP offer/answer. It will require some additional work if you want an IPsec security association between caller and callee. Establishing an e2e secure path for a call has been a topic of interest for some time. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 09 09:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEgA-0001Y3-14; Tue, 09 Oct 2007 08:59:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfEg5-0001OH-Bh for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 08:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfEg5-0001Nz-0c for sip@ietf.org; Tue, 09 Oct 2007 08:59:13 -0400 Received: from fk-out-0910.google.com ([209.85.128.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfEfy-0006fP-HK for sip@ietf.org; Tue, 09 Oct 2007 08:59:12 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1718747fkz for ; Tue, 09 Oct 2007 05:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=db6la84aURBLfuLI22ZM1OgsswYS5VagGlRayxKXcJM=; b=IxmlJ7JyJWTS/Pfpk605VZnMKmRWa/dXk4tPciQ8MUSkrlJm2lFBIx/dVIuYoGUc7nA0H1A0PHE9ozwSI4OgNpB7uj5wf0yLU/rWPKgjPlT6n+0OZvvYUNcRBTmAspkho3xivH5PBGW132woUV0XETYAsMlcIDw1tQXoG4wOnD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Wlmg5xNe6gvbMoO1hRbrBhAWgc3Vr4Px5llBdskVV1vgsb3/duaRr34j+V150/oRvQJVC/mIB/2DV9Wpumi6M6aV0aHg4klO5c7OJLhS/mtQgYanQAd0a0gF3Ke7+4i4qecyYl+igykdoM5VzaLZL569TgnxZqJDPlGc0bQAJws= Received: by 10.82.189.6 with SMTP id m6mr28118075buf.1191934740156; Tue, 09 Oct 2007 05:59:00 -0700 (PDT) Received: by 10.82.177.2 with HTTP; Tue, 9 Oct 2007 05:58:59 -0700 (PDT) Message-ID: <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> Date: Tue, 9 Oct 2007 14:58:59 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470B72FF.3010000@cisco.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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: , Content-Type: multipart/mixed; boundary="===============0940328720==" Errors-To: sip-bounces@ietf.org --===============0940328720== Content-Type: multipart/alternative; boundary="----=_Part_5241_4483874.1191934739960" ------=_Part_5241_4483874.1191934739960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Paul Kyzivat wrote: > > > > Pars Mutaf wrote: > > On 10/9/07, *Dale.Worley@comcast.net * > > < Dale.Worley@comcast.net > wrote: > > > > From: "Pars Mutaf" > > > > > > I'll feel more comfortable if I explain the above statement > > to SIP folks. I'm not defending any particular design, I'm trying > > > to start some discussion and get more people to the list, > > and hoping to find the right choices together. > > > > What is the problem you are trying to solve? > > > > > > Thanks. I tried to introduce the problem in my first > > mail which was perhaps too long: > > http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html > > > > Briefly: the problem is that users cannot publish their > > identifiers e.g. SIP URIs, for privacy reasons. They are > > obligated to exchange their contact information manually > > upon face-to-face contact. But face-to-face contact is not > > always available, and even if it is available manual > > exchange is difficult. > > Maybe I'm missing something, but it seems to me that what you are > seeking is exactly the function provided by a sip registrar. Your > requirements from the referenced mail are: > > > Model of operation > > > > 1. The querier user types the target user's "human name" (as if he were > > consulting a phonebook), or a pseudoynm. > > An AOR: sip:name@domain. Where did you get this information. It is private. (I'm not saying that this a problem of SIP. This is general problem.) Please note that the proposal is comparable to the 'phone book', not SIP. Thanks, pars > 2. The pairing request is forwarded to the target phone. > > The request is forwarded to the home proxy associated with the > registrar. Then it is forwarded to a registered target phone. The caller > doesn't need to ever know the actual address of the target phone. > > > 3. The query, along with the querier user's name, are displayed on the > > target phone's screen. > > The target phone rings. The callerid information is typically displayed > by that phone. > > > 4. The target user approves the request in real-time by pushing on the > YES > > button of the phone. > > The target user approves the request by answering the phone. > > > 5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, > and > > establish an IPsec security association (using IKEv2). > > The calling phone provided its contact address in the INVITE. The target > phone returns its contact address in the response to the invite. They > have also exchanged media addresses in SDP offer/answer. > > It will require some additional work if you want an IPsec security > association between caller and callee. Establishing an e2e secure path > for a call has been a topic of interest for some time. Paul > ------=_Part_5241_4483874.1191934739960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/9/07, Paul Kyzivat <pkyzivat@cisco.com > wrote:


Pars Mutaf wrote:
> On 10/9/07, *Dale.Worley@comcast.net <mailto: Dale.Worley@comcast.net>*
> < Dale.Worley@comcast.net <mailto:Dale.Worley@comcast.net>> wrote:
>
>        From: "Pars Mutaf" < pars.mutaf@gmail.com
>     <mailto:pars.mutaf@gmail.com>>
>
>        I'll feel more comfortable if I explain the above statement
>        to SIP folks. I'm not defending any particular design, I'm trying
>        to start some discussion and get more people to the list,
>        and hoping to find the right choices together.
>
>     What is the problem you are trying to solve?
>
>
> Thanks. I tried to introduce the problem in my first
> mail which was perhaps too long:
> http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html
>
> Briefly: the problem is that users cannot publish their
> identifiers e.g. SIP URIs, for privacy reasons. They are
> obligated to exchange their contact information manually
> upon face-to-face contact. But face-to-face contact is not
> always available, and even if it is available manual
> exchange is difficult.

Maybe I'm missing something, but it seems to me that what you are
seeking is exactly the function provided by a sip registrar. Your
requirements from the referenced mail are:

> Model of operation
>
> 1. The querier user types the target user's "human name" (as if he were
>    consulting a phonebook), or a pseudoynm.

An AOR: sip:name@domain.


Where did you get this information. It is private.

(I'm not saying that this a problem of SIP. This is general problem.)

Please note that the proposal is comparable to the 'phone book',
not SIP.

Thanks,
pars





> 2. The pairing request is forwarded to the target phone.

The request is forwarded to the home proxy associated with the
registrar. Then it is forwarded to a registered target phone. The caller
doesn't need to ever know the actual address of the target phone.

> 3. The query, along with the querier user's name, are displayed on the
>    target phone's screen.

The target phone rings. The callerid information is typically displayed
by that phone.

> 4. The target user approves the request in real-time by pushing on the YES
>    button of the phone.

The target user approves the request by answering the phone.

> 5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and
>    establish an IPsec security association (using IKEv2).

The calling phone provided its contact address in the INVITE. The target
phone returns its contact address in the response to the invite. They
have also exchanged media addresses in SDP offer/answer.

It will require some additional work if you want an IPsec security
association between caller and callee. Establishing an e2e secure path
for a call has been a topic of interest for some time.



 

        Paul

------=_Part_5241_4483874.1191934739960-- --===============0940328720== 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 --===============0940328720==-- From sip-bounces@ietf.org Tue Oct 09 09:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFHH-0004Cz-Iw; Tue, 09 Oct 2007 09:37:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfFHE-000464-UN for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFHE-00045w-Kj for sip@ietf.org; Tue, 09 Oct 2007 09:37:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFH7-0008Qs-ON for sip@ietf.org; Tue, 09 Oct 2007 09:37:36 -0400 X-IronPort-AV: E=Sophos;i="4.21,248,1188792000"; d="scan'208";a="73500529" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2007 09:37:14 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l99DbEtm019713; Tue, 9 Oct 2007 09:37:14 -0400 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 l99Db0d8012452; Tue, 9 Oct 2007 13:37:14 GMT 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.1830); Tue, 9 Oct 2007 09:37:05 -0400 Received: from [10.86.241.48] ([10.86.241.48]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 09:37:04 -0400 Message-ID: <470B8400.7080208@cisco.com> Date: Tue, 09 Oct 2007 09:37:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> In-Reply-To: <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 13:37:04.0635 (UTC) FILETIME=[7AB964B0:01C80A79] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--16.702300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3606; t=1191937034; x=1192801034; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20IETF=20solution=20for=20pairing=20cellular=20 hosts |Sender:=20 |To:=20Pars=20Mutaf=20; bh=RQbvYjNiu8rOTtbzmP2zfSkw9JBUzXasbVYFz4KWRHo=; b=kYXadInwlxcm+z5nPuOEr8jKiEDmKOJ3prZvLF3FYIYLg4pHtJWr4PDoejQvfwee2S3wpl5P QzPX+9hYFgZhyhEXAqirWoB431xTF4o1gMVEeMxeohyrTle3Ab9kYBQV; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > > > On 10/9/07, *Paul Kyzivat* > wrote: > > > > Pars Mutaf wrote: > > On 10/9/07, *Dale.Worley@comcast.net > >* > > < Dale.Worley@comcast.net > >> > wrote: > > > > From: "Pars Mutaf" < pars.mutaf@gmail.com > > > >> > > > > I'll feel more comfortable if I explain the above statement > > to SIP folks. I'm not defending any particular design, I'm > trying > > to start some discussion and get more people to the list, > > and hoping to find the right choices together. > > > > What is the problem you are trying to solve? > > > > > > Thanks. I tried to introduce the problem in my first > > mail which was perhaps too long: > > http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html > > > > > Briefly: the problem is that users cannot publish their > > identifiers e.g. SIP URIs, for privacy reasons. They are > > obligated to exchange their contact information manually > > upon face-to-face contact. But face-to-face contact is not > > always available, and even if it is available manual > > exchange is difficult. > > Maybe I'm missing something, but it seems to me that what you are > seeking is exactly the function provided by a sip registrar. Your > requirements from the referenced mail are: > > > Model of operation > > > > 1. The querier user types the target user's "human name" (as if > he were > > consulting a phonebook), or a pseudoynm. > > An AOR: sip:name@domain. > > > > Where did you get this information. It is private. > > (I'm not saying that this a problem of SIP. This is general problem.) > > Please note that the proposal is comparable to the 'phone book', > not SIP. In order to use a phone book, you must: - start with the name you know for the person - canonicalize it to a form that might be listed in a phone book - choose which phone book to look in. This is effectively a domain in which names should be unique. - look up the name to get an address. (This of course doesn't work if the target doesn't want to disclose the address - an unlisted number.) The above isn't much different from me guessing from your name (Pars Mutaf) that your user name might be pars.mutaf, and then guessing that you might be using domain gmail.com. In fact the scale of the problem is comparable if I don't know where in the world your phone might be registered. It is worse in that there isn't much consistency with how human names are mapped to user names. It sounds like you are looking for a global registry of mappings from human names to various sorts of addresses. That might be something like ENUM, but with the keys being human names rather than phone numbers. Given the difficulty there has been in getting a public enum established, I would anticipate it could be very hard to get agreement to establish a public registry keyed by human name - there are huge privacy issues. 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 Tue Oct 09 10:39:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGAm-0002nM-Kl; Tue, 09 Oct 2007 10:35:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfGAk-0002nF-Tq for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGAk-0002hg-KB for sip@ietf.org; Tue, 09 Oct 2007 10:34:58 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGAa-0001lO-9b for sip@ietf.org; Tue, 09 Oct 2007 10:34:54 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1517270wxc for ; Tue, 09 Oct 2007 07:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=u1QORuaOXeImLvCfKbWxKrlk0PvLoQmKCNX8A+0D4PE=; b=KyKNME+dxndiYuGKuxDvocuXpHyYl/Mgnr3124TwOyGCbUOCIGa3rKOEVhs5k5NMLdhpH/ZoIAIDvBu8iIQo35PR/VUZNR2+6zni2louaqoFb9toL8QtuFuSK6EjhuiRpYUBe+W4ywV9+4yOPJ5ZM7acX1A93eNkj9+ql9w/SlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=USTCB64CCP0xufzGPbJcW3pFSzKN7jMt6oAYF2/5/ncS1vZdiSgCI8CQeN+66aQpCKtRjy2VXgIwLEpVy9AxqUJvelGeMG++V81Mit/ThrKgQbBJImKZT1lKW5RFQ47IKrMYF/ymLOxG20dJUQx8eYN0x51ViOTH6DE8PsQJ3ZU= Received: by 10.70.117.3 with SMTP id p3mr13831992wxc.1191940434619; Tue, 09 Oct 2007 07:33:54 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 9 Oct 2007 07:33:54 -0700 (PDT) Message-ID: <18a603a60710090733t261d00eas9ba022b3af9f67d5@mail.gmail.com> Date: Tue, 9 Oct 2007 16:33:54 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470B8400.7080208@cisco.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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: , Content-Type: multipart/mixed; boundary="===============1652949741==" Errors-To: sip-bounces@ietf.org --===============1652949741== Content-Type: multipart/alternative; boundary="----=_Part_1434_6811958.1191940434617" ------=_Part_1434_6811958.1191940434617 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Paul Kyzivat wrote: > > > > Pars Mutaf wrote: > > > > > > On 10/9/07, *Paul Kyzivat* > > wrote: > > > > > > > > Pars Mutaf wrote: > > > On 10/9/07, *Dale.Worley@comcast.net > > > >* > > > < Dale.Worley@comcast.net > > >> > > wrote: > > > > > > From: "Pars Mutaf" < pars.mutaf@gmail.com > > > > > >> > > > > > > I'll feel more comfortable if I explain the above > statement > > > to SIP folks. I'm not defending any particular design, I'm > > trying > > > to start some discussion and get more people to the list, > > > and hoping to find the right choices together. > > > > > > What is the problem you are trying to solve? > > > > > > > > > Thanks. I tried to introduce the problem in my first > > > mail which was perhaps too long: > > > http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html > > > > > > > > Briefly: the problem is that users cannot publish their > > > identifiers e.g. SIP URIs, for privacy reasons. They are > > > obligated to exchange their contact information manually > > > upon face-to-face contact. But face-to-face contact is not > > > always available, and even if it is available manual > > > exchange is difficult. > > > > Maybe I'm missing something, but it seems to me that what you are > > seeking is exactly the function provided by a sip registrar. Your > > requirements from the referenced mail are: > > > > > Model of operation > > > > > > 1. The querier user types the target user's "human name" (as if > > he were > > > consulting a phonebook), or a pseudoynm. > > > > An AOR: sip:name@domain. > > > > > > > > Where did you get this information. It is private. > > > > (I'm not saying that this a problem of SIP. This is general problem.) > > > > Please note that the proposal is comparable to the 'phone book', > > not SIP. > > In order to use a phone book, you must: > - start with the name you know for the person > - canonicalize it to a form that might be listed in a phone book > - choose which phone book to look in. This is effectively a > domain in which names should be unique. > - look up the name to get an address. (This of course doesn't work > if the target doesn't want to disclose the address - an unlisted > number.) > > The above isn't much different from me guessing from your name (Pars > Mutaf) that your user name might be pars.mutaf, and then guessing that > you might be using domain gmail.com. In fact the scale of the problem is > comparable if I don't know where in the world your phone might be > registered. There is a general privacy requirement which says that SIP URIs shouldn't be predictable (i.e. based on human name). Otherwise you will receive spam, unwanted calls, etc. on your cell phone. I think everybody agrees with that. There is also the domain name problem as you noticed. These make the retrieval or manual exchange of phone numbers difficult. It is worse in that there isn't much consistency with how human names > are mapped to user names. > > It sounds like you are looking for a global registry of mappings from > human names to various sorts of addresses. No :-) (or, I misunderstood) Please see below. That might be something like > ENUM, but with the keys being human names rather than phone numbers. OK perhaps. But human name collisions must be handled. Another solution would be based on multicast DNS, but for local use only, as briefly described at: http://www1.ietf.org/mail-archive/web/sip/current/msg20672.html Given the difficulty there has been in getting a public enum > established, I would anticipate it could be very hard to get agreement > to establish a public registry keyed by human name - there are huge > privacy issues. This is exactly my point. But there is a general misunderstanding. The proposal wasn't clear I think (below is very simplified): 1. The querier types the target human name. 2. The request (e.g. for a phone number) is forwarded to the target user. 3. The target user approves it. 4. The target phone, returns its phone number. I think the 3rd point is being missed (except, I guess, by Dean Willis who made a comparison with consent framework. This is another discussion topic.) Thanks, pars Paul > ------=_Part_1434_6811958.1191940434617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 10/9/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Pars Mutaf wrote:
>
>
> On 10/9/07, *Paul Kyzivat* <pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>> wrote:
>
>
>
>     Pars Mutaf wrote:
>      > On 10/9/07, *Dale.Worley@comcast.net
>     <mailto:Dale.Worley@comcast.net > <mailto: Dale.Worley@comcast.net
>     <mailto:Dale.Worley@comcast.net>>*
>      > < Dale.Worley@comcast.net <mailto:Dale.Worley@comcast.net>
>     <mailto:Dale.Worley@comcast.net <mailto: Dale.Worley@comcast.net>>>
>     wrote:
>      >
>      >        From: "Pars Mutaf" < pars.mutaf@gmail.com
>     <mailto: pars.mutaf@gmail.com>
>      >     <mailto:pars.mutaf@gmail.com <mailto:pars.mutaf@gmail.com >>>
>      >
>      >        I'll feel more comfortable if I explain the above statement
>      >        to SIP folks. I'm not defending any particular design, I'm
>     trying
>      >        to start some discussion and get more people to the list,
>      >        and hoping to find the right choices together.
>      >
>      >     What is the problem you are trying to solve?
>      >
>      >
>      > Thanks. I tried to introduce the problem in my first
>      > mail which was perhaps too long:
>      > http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html
>     <http://www1.ietf.org/mail-archive/web/sip/current/msg20618.html >
>      >
>      > Briefly: the problem is that users cannot publish their
>      > identifiers e.g. SIP URIs, for privacy reasons. They are
>      > obligated to exchange their contact information manually
>      > upon face-to-face contact. But face-to-face contact is not
>      > always available, and even if it is available manual
>      > exchange is difficult.
>
>     Maybe I'm missing something, but it seems to me that what you are
>     seeking is exactly the function provided by a sip registrar. Your
>     requirements from the referenced mail are:
>
>      > Model of operation
>      >
>      > 1. The querier user types the target user's "human name" (as if
>     he were
>      >    consulting a phonebook), or a pseudoynm.
>
>     An AOR: sip:name@domain.
>
>
>
> Where did you get this information. It is private.
>
> (I'm not saying that this a problem of SIP. This is general problem.)
>
> Please note that the proposal is comparable to the 'phone book',
> not SIP.

In order to use a phone book, you must:
- start with the name you know for the person
- canonicalize it to a form that might be listed in a phone book
- choose which phone book to look in. This is effectively a
   domain in which names should be unique.
- look up the name to get an address. (This of course doesn't work
   if the target doesn't want to disclose the address - an unlisted
   number.)

The above isn't much different from me guessing from your name (Pars
Mutaf) that your user name might be pars.mutaf, and then guessing that
you might be using domain gmail.com. In fact the scale of the problem is
comparable if I don't know where in the world your phone might be
registered.


There is a general privacy requirement which says that SIP URIs shouldn't
be predictable (i.e. based on human name).
Otherwise you will receive spam, unwanted calls, etc.
on your cell phone. I think everybody agrees with that.

There is also the domain name problem as you noticed.

These make the retrieval or manual exchange of phone numbers
difficult.


It is worse in that there isn't much consistency with how human names
are mapped to user names.

It sounds like you are looking for a global registry of mappings from
human names to various sorts of addresses.


No :-)
(or, I misunderstood)
Please see below.
 

That might be something like
ENUM, but with the keys being human names rather than phone numbers.


OK perhaps. But human name collisions must be handled.
Another solution would be based on multicast DNS, but for local
use only, as briefly described at:

http://www1.ietf.org/mail-archive/web/sip/current/msg20672.html
 

Given the difficulty there has been in getting a public enum
established, I would anticipate it could be very hard to get agreement
to establish a public registry keyed by human name - there are huge
privacy issues.

This is exactly my point. But there is a general misunderstanding.
The proposal wasn't clear I think (below is very simplified):

1. The querier types the target human name.
2. The request ( e.g. for a phone number) is forwarded to the target user.
3. The target user approves it.
4. The target phone, returns its phone number.

I think the 3rd point is being missed (except, I guess, by Dean Willis who
made a comparison with consent framework. This is another discussion
topic.)

Thanks,
pars



        Paul

------=_Part_1434_6811958.1191940434617-- --===============1652949741== 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 --===============1652949741==-- From sip-bounces@ietf.org Tue Oct 09 10:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGKg-0005Pe-M4; Tue, 09 Oct 2007 10:45:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfGKe-0005OD-Eu for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGKd-0005Ny-TK for sip@ietf.org; Tue, 09 Oct 2007 10:45:12 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGKX-00020t-LH for sip@ietf.org; Tue, 09 Oct 2007 10:45:11 -0400 Received: from localhost.localdomain (ppp-70-244-166-252.dsl.rcsntx.swbell.net [70.244.166.252]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l99Ehf6K090745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 09:43:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <470B9398.2070706@nostrum.com> Date: Tue, 09 Oct 2007 09:43:36 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> In-Reply-To: <470B8400.7080208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.244.166.252 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4514/Tue Oct 9 09:03:20 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > It sounds like you are looking for a global registry of mappings from > human names to various sorts of addresses. That might be something > like ENUM, but with the keys being human names rather than phone numbers. Alternately, you can see it as an LDAP directory with interactive user permissions (similar to the winfo/XCAP setup we have for presence). It would be a fairly straightforward effort to engineer a system fitting that description, but I think we'd need better defined requirements than we have so far. For example: how does one locate the proper directory server for a given user? I doubt a unified global system to hold 2 billion to 3 billion [1] user records would be technically feasible; and, even it if is, I don't understand how it could be humanly useful. A search for "John Smith" or "Wen Zhang" in a directory containing half the world's population would turn up hundreds of thousands, and possibly millions, of records. In fact, I don't have a particularly common name, and disambiguating *me* from the several dozen other Adam Roaches you get when you search on Google is something of a tricky task. And google gives a lot more context than any directory could ever hope to. Just looking at the top five hits on Google right now: you can probably guess that I'm not the tattoo artist or the wardrobe assistant -- but do you know enough about me to be certain I'm not the Adam Roach from Missouri listed on myspace? In other words: I think there needs to be more scope around the problem before we start contemplating solutions; because the problem, as stated, has no workable solution. The hurdle isn't technological -- it's human. /a [1] http://www.news.com/2100-1039_3-6159491.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 Tue Oct 09 11:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGhl-0004d8-K3; Tue, 09 Oct 2007 11:09:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfGhk-0004d3-0m for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 11:09:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGhj-0004Zz-NQ for sip@ietf.org; Tue, 09 Oct 2007 11:09:03 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGhT-0002Ur-NH for sip@ietf.org; Tue, 09 Oct 2007 11:08:53 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1527293wxc for ; Tue, 09 Oct 2007 08:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=dA39i5VIV8VIWoea3kPnJigWyQcTJ2EpXH0Q72SeWx8=; b=miZ4oS9E9MpsrSH3f65Slf9Gl+VBnnX1LtbO4hV1AtA5EX1ba9+dz+CP8eIluSZkvJamtItigUfhttRiihfJvXTjwr38xGSMEYz65m3TgrcUQbxICX1lNLxmWKVY8DnBKDcPSyklIjtjYAAv4fDhkEvN6TJ05hnOy/0qDIkzYS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hBB7TKdspUygOvxpBX7fGlXtQYX7cVQoh/clnZaoQ9F4dDt7OkJiUAQeb3dd55PoLqzesNFRQyH1GL3OMB1GtwDrX+I83cjvSF1AdNegIcVMyFiLRDjGnYAlknyI4L7xtR8a+jl3muRHsFr3RVoAYDF8HYW7xN/5Qq7/5Uyqsx4= Received: by 10.70.23.1 with SMTP id 1mr10639281wxw.1191942495058; Tue, 09 Oct 2007 08:08:15 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 9 Oct 2007 08:08:14 -0700 (PDT) Message-ID: <18a603a60710090808p3c8a70co8992e1d7bb1711ae@mail.gmail.com> Date: Tue, 9 Oct 2007 17:08:14 +0200 From: "Pars Mutaf" To: "Adam Roach" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470B9398.2070706@nostrum.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> <470B9398.2070706@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, Paul Kyzivat 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="===============0142028411==" Errors-To: sip-bounces@ietf.org --===============0142028411== Content-Type: multipart/alternative; boundary="----=_Part_1797_25888636.1191942495050" ------=_Part_1797_25888636.1191942495050 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Adam Roach wrote: > > Paul Kyzivat wrote: > > It sounds like you are looking for a global registry of mappings from > > human names to various sorts of addresses. That might be something > > like ENUM, but with the keys being human names rather than phone > numbers. > > Alternately, you can see it as an LDAP directory with interactive user > permissions (similar to the winfo/XCAP setup we have for presence). It > would be a fairly straightforward effort to engineer a system fitting > that description, but I think we'd need better defined requirements than > we have so far. Thanks! But there is another question first. Will you subscribe: https://www1.ietf.org/mailman/listinfo/humanresolvers For example: how does one locate the proper directory server for a given > user? Right. > I doubt a unified global system to hold 2 billion to 3 billion [1] > user records would be technically feasible; and, even it if is, I don't > understand how it could be humanly useful. A search for "John Smith" or > "Wen Zhang" in a directory containing half the world's population would > turn up hundreds of thousands, and possibly millions, of records. I would think that a world-wide solution is overly ambitious (and difficult) and not so useful for the average case (which covers a very large number of users). BTW, some folks mentioned location-based solutions. Thanks, pars > In fact, I don't have a particularly common name, and disambiguating > *me* from the several dozen other Adam Roaches you get when you search > on Google is something of a tricky task. And google gives a lot more > context than any directory could ever hope to. Just looking at the top > five hits on Google right now: you can probably guess that I'm not the > tattoo artist or the wardrobe assistant -- but do you know enough about > me to be certain I'm not the Adam Roach from Missouri listed on myspace? > > In other words: I think there needs to be more scope around the problem > before we start contemplating solutions; because the problem, as stated, > has no workable solution. The hurdle isn't technological -- it's human. > > /a > > [1] http://www.news.com/2100-1039_3-6159491.html > ------=_Part_1797_25888636.1191942495050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/9/07, Adam Roach <adam@nostrum.com> wrote:
Paul Kyzivat wrote:
> It sounds like you are looking for a global registry of mappings from
> human names to various sorts of addresses. That might be something
> like ENUM, but with the keys being human names rather than phone numbers.

Alternately, you can see it as an LDAP directory with interactive user
permissions (similar to the winfo/XCAP setup we have for presence). It
would be a fairly straightforward effort to engineer a system fitting
that description, but I think we'd need better defined requirements than
we have so far.


Thanks! But there is another question first. Will you subscribe:

https://www1.ietf.org/mailman/listinfo/humanresolvers

 

For example: how does one locate the proper directory server for a given
user?

Right.
 
I doubt a unified global system to hold 2 billion to 3 billion [1]
user records would be technically feasible; and, even it if is, I don't
understand how it could be humanly useful. A search for "John Smith" or
"Wen Zhang" in a directory containing half the world's population would
turn up hundreds of thousands, and possibly millions, of records.

I would think that a world-wide solution is overly ambitious (and difficult)
and not so useful for the average case (which covers a very large number
of users).

BTW, some folks mentioned location-based solutions.

Thanks,
pars


 
In fact, I don't have a particularly common name, and disambiguating
*me* from the several dozen other Adam Roaches you get when you search
on Google is something of a tricky task. And google gives a lot more
context than any directory could ever hope to. Just looking at the top
five hits on Google right now: you can probably guess that I'm not the
tattoo artist or the wardrobe assistant --  but do you know enough about
me to be certain I'm not the Adam Roach from Missouri listed on myspace?

In other words: I think there needs to be more scope around the problem
before we start contemplating solutions; because the problem, as stated,
has no workable solution. The hurdle isn't technological -- it's human.

/a

[1] http://www.news.com/2100-1039_3-6159491.html

------=_Part_1797_25888636.1191942495050-- --===============0142028411== 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 --===============0142028411==-- From sip-bounces@ietf.org Tue Oct 09 11:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHOl-0004js-5g; Tue, 09 Oct 2007 11:53:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfHOj-0004hS-5q for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 11:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHOi-0004fy-S8 for sip@ietf.org; Tue, 09 Oct 2007 11:53:28 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfHOc-0003Op-ME for sip@ietf.org; Tue, 09 Oct 2007 11:53:28 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1542162wxc for ; Tue, 09 Oct 2007 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=usOYsJI6eXh9kIjoQcE2mbxG7HaYAmJNu3ATUJVA9f8=; b=kJ7OMASBU2nG6MZfLY0eQCNl91Br+ZZL4nIuD8C9nt71tBSvflrcHYojsvTiRLNn1wloqFQ/PCxd3QjPXJgou+OcbDS75aErcH055oGiLWCmpssSVrBsp0zYHT4tlpeJI3CwxzFCrp2Xs50nkdTI+EdKUmkVnp632udjMHC5irQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=SJEy6Toke1fu15mA10wxxLmAgchypffpW89RVufFWkZPfyQ+th9gHFZHXf5PjwosSh078ugM7K2SC4FTFYQHYVDQWuwamHIJCOS1PHkGFfGG3+iUYiTM5RT0R7p/K9vdtOe/WtVFP7Y6fTPCpdBL6B2IDE4T12vuuXOACqvLhTs= Received: by 10.70.12.2 with SMTP id 2mr27211699wxl.1191945192247; Tue, 09 Oct 2007 08:53:12 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 9 Oct 2007 08:53:12 -0700 (PDT) Message-ID: <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> Date: Tue, 9 Oct 2007 17:53:12 +0200 From: "Pars Mutaf" To: "Joel M. Halpern" , sip@ietf.org Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <20071009135435.502B47DF3@bender.tigertech.net> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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="===============1869412409==" Errors-To: sip-bounces@ietf.org --===============1869412409== Content-Type: multipart/alternative; boundary="----=_Part_2336_29692923.1191945192235" ------=_Part_2336_29692923.1191945192235 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Joel M. Halpern wrote: > > At 08:58 AM 10/9/2007, you wrote: > >Where did you get this information. It is private. > > Presumably, the "this" refers to the SIP URI. > If you don't have the SIP URI, what string do you think you > have? Human names are utterly useless for this, due to collision, > misspelling, and many other problems. To my knowledge, phonebook users never complained about that. The real problem of the phonebook, today, is the privacy problem. An extension is needed for interactive user permissions as stated by Adam Roach. A note about name collisions: Similarly to a traditional phonebook user, if you are looking for a certain John Smith, hopefully you will have some additional information helping filter the results. (in the proposed extension, the target cell phone may return such information, e.g. company name, street address, etc.) Note also that if anyone can send you a resolution request, that is > roughly equivalent, in terms of intrusiveness, to anyone causing your > phone to ring. The proposal is rather as follows (abstract): You solve to a challenge (e.g. a CAPTCHA) to obtain the target phone number. Then, you can make a call, send a message etc. Thanks, pars Alternatively, if you want a challenge / response on the resolution > request, you can give a challenge / response on the SIP request. > > Yours, > Joel > > ------=_Part_2336_29692923.1191945192235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/9/07, Joel M. Halpern <jmh@joelhalpern.com> wrote:
At 08:58 AM 10/9/2007, you wrote:
>Where did you get this information. It is private.

Presumably, the "this" refers to the SIP URI.
If you don't have the SIP URI, what string do you think you
have?  Human names are utterly useless for this, due to collision,
misspelling, and many other problems.

To my knowledge, phonebook users never complained about that.

The real problem of the phonebook, today, is the privacy
problem. An extension is needed for interactive user
permissions as stated by Adam Roach.
 
A note about name collisions:

Similarly to a traditional phonebook user, if you are looking
for a certain John Smith, hopefully you will have some
additional information helping filter the results.

(in the proposed extension, the target cell phone may return
such information, e.g. company name, street address, etc.)


Note also that if anyone can send you a resolution request, that is
roughly equivalent, in terms of intrusiveness, to anyone causing your
phone to ring.

The proposal is rather as follows (abstract):

You solve to a challenge (e.g. a CAPTCHA) to obtain the target
phone number.
Then, you can make a call, send a message etc.

Thanks,
pars
 

Alternatively, if you want a challenge / response on the resolution
request, you can give a challenge / response on the SIP request.

Yours,
Joel


------=_Part_2336_29692923.1191945192235-- --===============1869412409== 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 --===============1869412409==-- From sip-bounces@ietf.org Tue Oct 09 12:25:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHrN-00019D-HQ; Tue, 09 Oct 2007 12:23:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfHrM-000191-CQ for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 12:23:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHrM-00018i-0m for sip@ietf.org; Tue, 09 Oct 2007 12:23:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfHrL-00075U-G8 for sip@ietf.org; Tue, 09 Oct 2007 12:23:03 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188792000"; d="scan'208";a="134399058" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Oct 2007 12:23:03 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l99GN3ZV008978; Tue, 9 Oct 2007 12:23:03 -0400 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 l99GMst0014630; Tue, 9 Oct 2007 16:23:02 GMT 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.1830); Tue, 9 Oct 2007 12:22:45 -0400 Received: from [10.86.241.48] ([10.86.241.48]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 12:22:44 -0400 Message-ID: <470BAAD4.8030003@cisco.com> Date: Tue, 09 Oct 2007 12:22:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> In-Reply-To: <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 16:22:44.0728 (UTC) FILETIME=[9F7B3780:01C80A90] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--18.900100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3634; t=1191946983; x=1192810983; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20IETF=20solution=20for=20pairing=20cellular=20 hosts |Sender:=20 |To:=20Pars=20Mutaf=20; bh=yuQo3Jl5+zsdih1TR0XQnJZokZ1jjACm4U35XCYw9H4=; b=eYAFqGw/A/aGLXyWjCxLyu3f3cTqE7agypIP5QrM+gT75NZeonJYoPr4oZhhxBWwUN/sRT5W M7sEcGAtYkYE0PG/ehapCMAlfYVhYgIK7jhGRDqRwyXOQ3lTTX+A8GNs; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, "Joel M. Halpern" 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > > > On 10/9/07, *Joel M. Halpern* > wrote: > > At 08:58 AM 10/9/2007, you wrote: > >Where did you get this information. It is private. > > Presumably, the "this" refers to the SIP URI. > If you don't have the SIP URI, what string do you think you > have? Human names are utterly useless for this, due to collision, > misspelling, and many other problems. > > > To my knowledge, phonebook users never complained about that. Phone books worked reasonably well in a different age. And they depended on people being willing to advertise certain context information to the public at large: their phone number and an address. I think today that people are not so willing to disclose that information publicly. Today we often want to talk to people whose addresses we often don't know. Instead we may know their email address, or an IM address, etc. And those things are at least unique. So there are two problems here: - trying to find a unique address for someone given only some human name you have for them, and to disambiguate them from all the other people with similar names based on whatever information they might be willing to disclose to a random stranger. - given some unique address that is known to be associated with a given individual, find a different address for the same individual that is usable for some desired form of communication. The latter is probably a much more solvable problem. > The real problem of the phonebook, today, is the privacy > problem. An extension is needed for interactive user > permissions as stated by Adam Roach. > > A note about name collisions: > > Similarly to a traditional phonebook user, if you are looking > for a certain John Smith, hopefully you will have some > additional information helping filter the results. > > (in the proposed extension, the target cell phone may return > such information, e.g. company name, street address, etc.) I'm not likely to have my phone return that sort of information to unknown requestors. I don't know who would. > Note also that if anyone can send you a resolution request, that is > roughly equivalent, in terms of intrusiveness, to anyone causing your > phone to ring. > > > The proposal is rather as follows (abstract): > > You solve to a challenge (e.g. a CAPTCHA) to obtain the target > phone number. > Then, you can make a call, send a message etc. Really! Maybe you are willing to give your information out to anyone who can solve a CAPTCHA, but I'm not. Note that in Adam's example you might be sending this request to dozens, hundreds, or more of targets that you are not interested in, and who are presumably not interested in you either. Then you are going to solve a capcha from each one enroute to finding the right one? And they are going to go along with this? Paul > Thanks, > pars > > > Alternatively, if you want a challenge / response on the resolution > request, you can give a challenge / response on the SIP request. > > Yours, > Joel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 09 13:24:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIkn-0002Ue-D8; Tue, 09 Oct 2007 13:20:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfIkl-0002UT-27 for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 13:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfIkk-0002UF-Nd for sip@ietf.org; Tue, 09 Oct 2007 13:20:18 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfIke-0005PB-Dn for sip@ietf.org; Tue, 09 Oct 2007 13:20:18 -0400 Received: by nz-out-0506.google.com with SMTP id n1so947720nzf for ; Tue, 09 Oct 2007 10:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=ub8hrRga7VcUQJgF9xejLryNjCO6i7wQeYmGFQhC8Mw=; b=aYPlcQNfnNnjtEuHCZLU+1lLmvwnYZqd011b8UAI4MJ7RT50tfWD9+KbWLSP3ngrni0K6xb9bgKyFotk36qJD6H11qcRStQhk1ouE0oyjBR7ITQMnU5Y9NYCeSqUhNZ4t6d+7MvmRDMbkRHUh/XLrwamgTjfJ5TIAVDW3fDXDPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=VZZLcg5pVCDGgNflqpRVyfT9Z8wPuI7JWtA8gvyIDxEEIMoxaPxcuec3RvoETAi8zQYgYlTQ5XXy9bsspb2ofws+r8YMTkfHyHVbxS/nBScZrBriisMXvVTabAqb8ZFDvIZMjVScXUNuafXY9yO1xlVUVrl0Pdpm+eVoPQVtiao= Received: by 10.142.141.5 with SMTP id o5mr253232wfd.1191950401141; Tue, 09 Oct 2007 10:20:01 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 9 Oct 2007 10:20:00 -0700 (PDT) Message-ID: <18a603a60710091020y6c3b44a6la4f2bf7bb4580aa4@mail.gmail.com> Date: Tue, 9 Oct 2007 19:20:00 +0200 From: "Pars Mutaf" To: "Joel M. Halpern" , sip@ietf.org Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <20071009161749.EF6207E02@bender.tigertech.net> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <20071009161749.EF6207E02@bender.tigertech.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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="===============0565451731==" Errors-To: sip-bounces@ietf.org --===============0565451731== Content-Type: multipart/alternative; boundary="----=_Part_3031_11947346.1191950401033" ------=_Part_3031_11947346.1191950401033 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Joel M. Halpern wrote: > > What you are describing seems to be a directory (LDAP or White Pages > or ...) with tools to prevent automated usage. > It has almost nothing to do with SIP or with Mobile devices, Cell phones make the solution attractive, and the solution is most needed by cell phone users. You need someone's phone number (and Mobile IPv6 home address). You get all you need from the target phone *when needed*, if authorized by the target user. Or, when you meet someone and want get your phones paired, you just type the target name because you have your cell phone in your hand. The phones get paired. You don't need to type a long SIP URI and Mobile IPv6 home address. as the > information sought could easily be any sort of communications > establishment information. This is a possible discussion topic. Such directories have been tried, and generally fail on large scale. > The internet tends to not have the kind of matching information that > people are used to using. I'm not sure what you mean by large scale. I suspect that it is an unnecessarily ambitious requirement. A local solution is already very much needed IMHO. If you really want to build it, I suggest you uncouple it from SIP, I don't know about solution space, currently. Discussion needed to start somewhere, SIP WG was an obvious place. Thanks, pars and make the argument to the apps area for a person resolution > application. I believe you have pointed to mailing lists that are > already discussing this as a general problem. > > Yours, > Joel > > PS: Phone books only work if you know the address you need. Try > using telephone information (411 in the US) without knowing what town > your target is in. > > At 11:53 AM 10/9/2007, you wrote: > > > >On 10/9/07, Joel M. Halpern > ><jmh@joelhalpern.com> wrote: > >At 08:58 AM 10/9/2007, you wrote: > > >Where did you get this information. It is private. > > > >Presumably, the "this" refers to the SIP URI. > >If you don't have the SIP URI, what string do you think you > >have? Human names are utterly useless for this, due to collision, > >misspelling, and many other problems. > > > > > >To my knowledge, phonebook users never complained about that. > > > >The real problem of the phonebook, today, is the privacy > >problem. An extension is needed for interactive user > >permissions as stated by Adam Roach. > > > >A note about name collisions: > > > >Similarly to a traditional phonebook user, if you are looking > >for a certain John Smith, hopefully you will have some > >additional information helping filter the results. > > > >(in the proposed extension, the target cell phone may return > >such information, e.g. company name, street address, etc.) > > > > > >Note also that if anyone can send you a resolution request, that is > >roughly equivalent, in terms of intrusiveness, to anyone causing your > >phone to ring. > > > > > >The proposal is rather as follows (abstract): > > > >You solve to a challenge (e.g. a CAPTCHA) to obtain the target > >phone number. > >Then, you can make a call, send a message etc. > > > >Thanks, > >pars > > > > > >Alternatively, if you want a challenge / response on the resolution > >request, you can give a challenge / response on the SIP request. > > > >Yours, > >Joel > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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_3031_11947346.1191950401033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Joel M. Halpern <jmh@joelhalpern.com> wrote:
What you are describing seems to be a directory (LDAP or White Pages
or ...) with tools to prevent automated usage.
It has almost nothing to do with SIP or with Mobile devices,

Cell phones make the solution attractive,
and the solution is most needed by cell phone users.

You need someone's phone number (and Mobile IPv6 home address).
You get all you need from the target phone *when needed*, if authorized
by the target user.

Or, when you meet someone and want get your phones paired, you
just type the target name because you have your cell phone in your hand.
The phones get paired. You don't need to type a long SIP URI and
Mobile IPv6 home address.


as the
information sought could easily be any sort of communications
establishment information.

This is a possible discussion topic. 

Such directories have been tried, and generally fail on large scale.
The internet tends to not have the kind of matching information that
people are used to using.

I'm not sure what you mean by large scale. I suspect that it is an
unnecessarily ambitious requirement.

A local solution is already very much needed IMHO.


If you really want to build it, I suggest you uncouple it from SIP,

I don't know about solution space, currently. Discussion needed
to start somewhere, SIP WG was an obvious place.

Thanks,
pars


and make the argument to the apps area for a person resolution
application.  I believe you have pointed to mailing lists that are
already discussing this as a general problem.

Yours,
Joel

PS: Phone books only work if you know the address you need.  Try
using telephone information (411 in the US) without knowing what town
your target is in.

At 11:53 AM 10/9/2007, you wrote:


>On 10/9/07, Joel M. Halpern
><<mailto:jmh@joelhalpern.com> jmh@joelhalpern.com> wrote:
>At 08:58 AM 10/9/2007, you wrote:
> >Where did you get this information. It is private.
>
>Presumably, the "this" refers to the SIP URI.
>If you don't have the SIP URI, what string do you think you
>have?  Human names are utterly useless for this, due to collision,
>misspelling, and many other problems.
>
>
>To my knowledge, phonebook users never complained about that.
>
>The real problem of the phonebook, today, is the privacy
>problem. An extension is needed for interactive user
>permissions as stated by Adam Roach.
>
>A note about name collisions:
>
>Similarly to a traditional phonebook user, if you are looking
>for a certain John Smith, hopefully you will have some
>additional information helping filter the results.
>
>(in the proposed extension, the target cell phone may return
>such information, e.g. company name, street address, etc.)
>
>
>Note also that if anyone can send you a resolution request, that is
>roughly equivalent, in terms of intrusiveness, to anyone causing your
>phone to ring.
>
>
>The proposal is rather as follows (abstract):
>
>You solve to a challenge (e.g. a CAPTCHA) to obtain the target
>phone number.
>Then, you can make a call, send a message etc.
>
>Thanks,
>pars
>
>
>Alternatively, if you want a challenge / response on the resolution
>request, you can give a challenge / response on the SIP request.
>
>Yours,
>Joel
>
>
>_______________________________________________
>Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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_3031_11947346.1191950401033-- --===============0565451731== 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 --===============0565451731==-- From sip-bounces@ietf.org Tue Oct 09 14:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJO7-00069i-Fb; Tue, 09 Oct 2007 14:00:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfJO5-00069c-Hi for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 14:00:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJO5-0005wd-5z for sip@ietf.org; Tue, 09 Oct 2007 14:00:57 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfJO0-000129-SU for sip@ietf.org; Tue, 09 Oct 2007 14:00:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2007100918005201200eh021e>; Tue, 9 Oct 2007 18:00:52 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l99I0p29030728 for ; Tue, 9 Oct 2007 14:00:51 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l99I0pXk030724; Tue, 9 Oct 2007 14:00:51 -0400 Date: Tue, 9 Oct 2007 14:00:51 -0400 Message-Id: <200710091800.l99I0pXk030724@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <18a603a60710091020y6c3b44a6la4f2bf7bb4580aa4@mail.gmail.com> (pars.mutaf@gmail.com) Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <20071009161749.EF6207E02@bender.tigertech.net> <18a603a60710091020y6c3b44a6la4f2bf7bb4580aa4@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: sip-bounces@ietf.org I find the whole problem statement mysterious. The stated problem is, "How do I find a person's SIP URI without having them present to ask?" and "How do I prevent unauthorized people from obtaining this information?" The first part is a general phone book problem. But by hypothesis, it requires relatively little authentication of me to obtain the SIP URI. Yes, you can propose a step where the inquiry is passed to the target for approval, but that means that anyone who attempts a lookup can annoy the target person -- a direct failure of the privacy goal, since the inquirer has just contacted the target! If you want people to be interested in this, you're going to have to assemble a much better problem statement and at least one plausible solution, I think. My suspicion is that treating the SIP URI itself has having strong privacy requirements, but not treating the information needed to look up the SIP URI as not having strong privacy requirements, is not going to make any difference unless the process that maps between the two has strong authentication of the inquirer. 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 Tue Oct 09 14:36:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJv1-0005Md-Jt; Tue, 09 Oct 2007 14:34:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfJv0-0005M2-HY for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 14:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfJv0-0005LB-7j for sip@ietf.org; Tue, 09 Oct 2007 14:34:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfJut-0007bT-MT for sip@ietf.org; Tue, 09 Oct 2007 14:34:58 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188802800"; d="scan'208";a="179932435" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2007 11:34:51 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l99IYpYl018624; Tue, 9 Oct 2007 11:34:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l99IYla3007767; Tue, 9 Oct 2007 18:34:51 GMT 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.1830); Tue, 9 Oct 2007 14:34:44 -0400 Received: from [10.86.241.48] ([10.86.241.48]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 14:34:44 -0400 Message-ID: <470BC9C4.8080606@cisco.com> Date: Tue, 09 Oct 2007 14:34:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> <470B9398.2070706@nostrum.com> <18a603a60710090808p3c8a70co8992e1d7bb1711ae@mail.gmail.com> In-Reply-To: <18a603a60710090808p3c8a70co8992e1d7bb1711ae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 18:34:44.0115 (UTC) FILETIME=[0FCDC630:01C80AA3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--14.932700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=628; t=1191954891; x=1192818891; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20IETF=20solution=20for=20pairing=20cellular=20 hosts |Sender:=20; bh=e16vvjYVabWgnZ2bBHVoG0xUFj62BiS/ERs8AYfBZ1g=; b=EbkEOK0HrRg9Rw9NYyUDoKmlWFhx7ORUcP/fDwZ3lzLuaLZtJGDexp+vgmVJOjkYEoQzaLZI 0QSn8lf/Z3YHuuv1uEX+POOVCHKvfyG2TkbARl/9d79/Cmqgg9O8QPcw; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > > Thanks! But there is another question first. Will you subscribe: > > https://www1.ietf.org/mailman/listinfo/humanresolvers I subscribe to a lot of lists. I need some motivation before subscribing to another one. I expect a lot of people on *this* list are in the same boat. You have gotten some people to respond to you here, though there is clearly a lot of skepticism. You will probably have better luck getting people to discuss here than at a new list. At least maybe you can try here to make a case for why people want to participate in your humanresolvers list. 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 Tue Oct 09 17:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMBh-0004EB-HA; Tue, 09 Oct 2007 17:00:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfMBg-0004E6-KE for sip-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 17:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMBg-0004Dy-AU for sip@ietf.org; Tue, 09 Oct 2007 17:00:20 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfMBa-0003UL-4A for sip@ietf.org; Tue, 09 Oct 2007 17:00:20 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l99L05sU021497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Oct 2007 16:00:06 -0500 In-Reply-To: <470BC9C4.8080606@cisco.com> References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> <470B9398.2070706@nostrum.com> <18a603a60710090808p3c8a70co8992e1d7bb1711ae@mail.gmail.com> <470BC9C4.8080606@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90AEC7BF-3B11-45CE-BCDF-37496D7BCA52@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] IETF solution for pairing cellular hosts Date: Tue, 9 Oct 2007 15:59:48 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: sip-bounces@ietf.org On Oct 9, 2007, at 1:34 PM, Paul Kyzivat wrote: > > > Pars Mutaf wrote: >> Thanks! But there is another question first. Will you subscribe: >> https://www1.ietf.org/mailman/listinfo/humanresolvers > > I subscribe to a lot of lists. I need some motivation before > subscribing to another one. I expect a lot of people on *this* list > are in the same boat. > > You have gotten some people to respond to you here, though there is > clearly a lot of skepticism. You will probably have better luck > getting people to discuss here than at a new list. At least maybe > you can try here to make a case for why people want to participate > in your humanresolvers list. Arguably, this would be more of a candidate for the SIPPING list than the SIP list. But as I said, it sounds like using an LDAP front-end. I'd image one could accomplish this by sending a SIP CONSENT request to a server in the domain of the target, where the SIP request has as its request URI and LDAP URL (RFC 2255, I think), with the user's name encoded in the LDAP URL. Assuming the consent phase hasn't previously occurred, said server would then look up the user name, translate it thru the usual SIP mechanisms, and send the CONSENT request onward. If the user grants consent, then the server would store this, and in the future either return a 302 with the user's SIP URI. That's for the particular combination of requirements previously given. Many alternative approaches, such as proxying the request to the target rather than returning a 302 and gleaning "consent" based on the user's response to an initial INVITE request address slight variations in those requirements. But I don't really think we need to be talking about this too much on the SIP list. Perhaps we should wait until the humanresolvers people better understand their requirements. -- 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 10 01:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTtc-0003Ny-Hl; Wed, 10 Oct 2007 01:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfTta-0003JT-5t for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 01:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTtZ-0003JL-Qn for sip@ietf.org; Wed, 10 Oct 2007 01:14:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfTtU-000217-17 for sip@ietf.org; Wed, 10 Oct 2007 01:14:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AEA9620492; Wed, 10 Oct 2007 07:13:32 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-95-470c5f7c1f0f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C5F92005E; Wed, 10 Oct 2007 07:13:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 07:13:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 07:13:31 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF125D62E5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAANRquiYAAQGRkABA3ymw References: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF125D62E5@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Eric Burger" X-OriginalArrivalTime: 10 Oct 2007 05:13:32.0453 (UTC) FILETIME=[4D460550:01C80AFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: sip-bounces@ietf.org >The Abstract should say something like: >=20 >The purpose of the INFO request for the Session Initiation Protocol >(SIP), as described by RFC 2976, is to provide mid-session SIP User >Agent (UA)-to-SIP UA application data transport. In the=20 >years since the introduction of the INFO request, experience with the=20 >use of the INFO request indicates a number of problems. Experience has also shown the opposite. And, one reason why the problems have occured is because it has not been possible to standardize the usage. >This document explains why there are INFO-based, proprietary protocols in the wild; And there we would describe the issues which have been raised with the alternative solutions. >the flaws of using INFO; and explains why it is not possible to create a >framework to rescue INFO for general purpose use. And, why is it not possible? >The INFO method was created as a general transport mechanism in SIP.=20 >As SIP has evolved since then, new mechanisms for different usages=20 >were created. As these mechanisms are now available, this document >formally deprecates the use oFrom sip-bounces@ietf.org Wed Oct 10 01:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTtc-0003Ny-Hl; Wed, 10 Oct 2007 01:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfTta-0003JT-5t for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 01:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTtZ-0003JL-Qn for sip@ietf.org; Wed, 10 Oct 2007 01:14:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfTtU-000217-17 for sip@ietf.org; Wed, 10 Oct 2007 01:14:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AEA9620492; Wed, 10 Oct 2007 07:13:32 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-95-470c5f7c1f0f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C5F92005E; Wed, 10 Oct 2007 07:13:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 07:13:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 07:13:31 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF125D62E5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAANRquiYAAQGRkABA3ymw References: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF125D62E5@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Eric Burger" X-OriginalArrivalTime: 10 Oct 2007 05:13:32.0453 (UTC) FILETIME=[4D460550:01C80AFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: sip-bounces@ietf.org >The Abstract should say something like: >=20 >The purpose of the INFO request for the Session Initiation Protocol >(SIP), as described by RFC 2976, is to provide mid-session SIP User >Agent (UA)-to-SIP UA application data transport. In the=20 >years since the introduction of the INFO request, experience with the=20 >use of the INFO request indicates a number of problems. Experience has also shown the opposite. And, one reason why the problems have occured is because it has not been possible to standardize the usage. >This document explains why there are INFO-based, proprietary protocols in the wild; And there we would describe the issues which have been raised with the alternative solutions. >the flaws of using INFO; and explains why it is not possible to create a >framework to rescue INFO for general purpose use. And, why is it not possible? >The INFO method was created as a general transport mechanism in SIP.=20 >As SIP has evolved since then, new mechanisms for different usages=20 >were created. As these mechanisms are now available, this document >formally deprecates the use of INFO for new usages beyond=20 >the existing standardized ones (i.e., ISUP and QSIG tunnelling). I disagree to that. We are still discussing the advantages/disadvantages/issues with INFO vs other mechanisms. 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 Wed Oct 10 01:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTt3-0002oo-6f; Wed, 10 Oct 2007 01:13:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfTt1-0002nz-Bo for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 01:13:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTt0-0002kB-UL for sip@ietf.org; Wed, 10 Oct 2007 01:13:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfTsx-0005us-Af for sip@ietf.org; Wed, 10 Oct 2007 01:13:31 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FA0420251; Wed, 10 Oct 2007 07:13:30 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-0f-470c5f7a73af Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D7B4201CC; Wed, 10 Oct 2007 07:13:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 07:13:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 07:13:29 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> < 8F65DB2 7-41ED-42F3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Audet, Francois (SC100:3055)" , "Dean Willis" X-OriginalArrivalTime: 10 Oct 2007 05:13:30.0339 (UTC) FILETIME=[4C037330:01C80AFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: f INFO for new usages beyond=20 >the existing standardized ones (i.e., ISUP and QSIG tunnelling). I disagree to that. We are still discussing the advantages/disadvantages/issues with INFO vs other mechanisms. 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 Wed Oct 10 01:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTt3-0002oo-6f; Wed, 10 Oct 2007 01:13:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfTt1-0002nz-Bo for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 01:13:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfTt0-0002kB-UL for sip@ietf.org; Wed, 10 Oct 2007 01:13:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfTsx-0005us-Af for sip@ietf.org; Wed, 10 Oct 2007 01:13:31 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FA0420251; Wed, 10 Oct 2007 07:13:30 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-0f-470c5f7a73af Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D7B4201CC; Wed, 10 Oct 2007 07:13:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 07:13:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 07:13:29 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> < 8F65DB2 7-41ED-42F3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Audet, Francois (SC100:3055)" , "Dean Willis" X-OriginalArrivalTime: 10 Oct 2007 05:13:30.0339 (UTC) FILETIME=[4C037330:01C80AFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: sip-bounces@ietf.org =20 >There is a missing point in here. >=20 >When you say "new uses of INFO are not being accepted by the=20 >IETF for the following reasons", the problem is that people=20 >are overstating their case when discussing the "reasons".=20 >This in turn is annoying people who find the "reasons" not=20 >technically accurate. >=20 >I'd rather we try to avoid "inventing" reasons and getting=20 >into silly long arguments. >=20 >We could say something very simple in that draft. Something=20 >like, INFO was created as a general transport mechanism in=20 >SIP. As SIP evolved, new mechanisms for different usages were=20 >created (then we can list them, and give KPML as an example=20 >for keypress). And then just say that new usages beyond the=20 >existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. >=20 >And leave it to that. >=20 >Any attempt at inventing complex reasons will just encourage=20 >people to find flaws in the arguments. Ignorning the reason why people are using INFO is not going to make things better either... I think most people are aware of KPML etc - we don't need to tell them that. 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 Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >There is a missing point in here. >=20 >When you say "new uses of INFO are not being accepted by the=20 >IETF for the following reasons", the problem is that people=20 >are overstating their case when discussing the "reasons".=20 >This in turn is annoying people who find the "reasons" not=20 >technically accurate. >=20 >I'd rather we try to avoid "inventing" reasons and getting=20 >into silly long arguments. >=20 >We could say something very simple in that draft. Something=20 >like, INFO was created as a general transport mechanism in=20 >SIP. As SIP evolved, new mechanisms for different usages were=20 >created (then we can list them, and give KPML as an example=20 >for keypress). And then just say that new usages beyond the=20 >existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. >=20 >And leave it to that. >=20 >Any attempt at inventing complex reasons will just encourage=20 >people to find flaws in the arguments. Ignorning the reason why people are using INFO is not going to make things better either... I think most people are aware of KPML etc - we don't need to tell them that. 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 Wed Oct 10 03:53:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWI4-0004Ym-Ns; Wed, 10 Oct 2007 03:47:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfWI2-0004VK-JL for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 03:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWI1-0004QN-VW for sip@ietf.org; Wed, 10 Oct 2007 03:47:33 -0400 Received: from vsnlnycsym01.vsnlxchange.com ([59.163.238.2] helo=mail.vsnlxchange.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfWHr-0006Ks-Pt for sip@ietf.org; Wed, 10 Oct 2007 03:47:29 -0400 Received: from mail.vsnlxchange.com (unknown [127.0.0.1]) by mail.vsnlxchange.com (Symantec Mail Security) with ESMTP id 24D0B50E31; Wed, 10 Oct 2007 03:46:51 -0400 (EDT) X-AuditID: 0a481007-ad734bb000002a10-14-470c836b9167 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 10 Oct 2007 13:16:47 +0530 Message-ID: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URI for Emergency call? Thread-Index: AcgLEbYr8FAX/AY/SH6T6/5pTQxokA== X-Priority: 1 Priority: Urgent Importance: high From: "Rathod Subhashchandra" To: X-OriginalArrivalTime: 10 Oct 2007 07:46:50.0941 (UTC) FILETIME=[B7FFE6D0:01C80B11] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.8 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Sip-implementors@lists.cs.columbia.edu Subject: [Sip] URI for Emergency call? 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="===============0775231194==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0775231194== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B11.B62BC22D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B11.B62BC22D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, This is regarding the URI for emergency call. draft-ietf-ecrit-service-urn-02 says URI should be urn:service:sos But 3GPP 23.003 says sip:user@sos.domain Which is the format we need to follow? Appreciate and thanks for your quick replay to this. Thanks ! Rathod. This message (including any attachment) is confidential and may be legally p= rivileged. Access to this message by anyone other than the intended recipie= nt(s) listed above is unauthorized. If you are not the intended recipient y= ou are hereby notified that any disclosure, copying, or distribution of the= message, or any action taken or omission of action by you in reliance upon= it, is prohibited and may be unlawful. Please immediately notify the sende= r by reply e-mail and permanently delete all copies of the message if you ha= ve received this message in error. ------_=_NextPart_001_01C80B11.B62BC22D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= = =0A= =0A= =0A=
Hi All,
=0A=
 
=0A=
This is regarding the URI for emergency call= .
=0A=
 
=0A=
draft-ietf-ecrit-service-urn-02 says URI sho= uld be =0A=

urn:service:sos

=0A=

But 3GPP 23.003 says sip:user@sos.domain=

=0A=

Which is the format we need to follow?

=0A=

Appreciate and thanks for your quick replay to this.

=0A=

Thanks !

=0A=

Rathod.

=0A=

 

This message (including any attachment) is confidential and may be= legally privileged. Access to this message by anyone other than the intend= ed recipient(s) listed above is unauthorized. If you are not the intended r= ecipient you are hereby notified that any disclosure, copying, or distributi= on of the message, or any action taken or omission of action by you in relia= nce upon it, is prohibited and may be unlawful. Please immediately notify t= he sender by reply e-mail and permanently delete all copies of the message i= f you have received this message in error.

------_=_NextPart_001_01C80B11.B62BC22D-- --===============0775231194== 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 --===============0775231194==-- From sip-bounces@ietf.org Wed Oct 10 04:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWX1-00070u-P4; Wed, 10 Oct 2007 04:03:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfWX0-0006z6-3I for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 04:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfWWz-0006yx-F4 for sip@ietf.org; Wed, 10 Oct 2007 04:03:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfWWy-0002nk-HP for sip@ietf.org; Wed, 10 Oct 2007 04:03:01 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CA0E520FBA; Wed, 10 Oct 2007 10:02:59 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-a2-470c87333f73 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEF3B2124B; Wed, 10 Oct 2007 10:02:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:02:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] URI for Emergency call? Date: Wed, 10 Oct 2007 10:02:56 +0200 Message-ID: In-Reply-To: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] URI for Emergency call? Thread-Index: AcgLEbYr8FAX/AY/SH6T6/5pTQxokAAAivSw References: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> From: "Christer Holmberg" To: "Rathod Subhashchandra" , X-OriginalArrivalTime: 10 Oct 2007 08:02:59.0110 (UTC) FILETIME=[F912C460:01C80B13] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Sip-implementors@lists.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: , Content-Type: multipart/mixed; boundary="===============0465694733==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0465694733== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B13.F800FA87" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B13.F800FA87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Look at 24.229, version 7.9.0. =20 Regards, =20 Christer ________________________________ From: Rathod Subhashchandra [mailto:rathod@tataelxsi.co.in]=20 Sent: 10. lokakuuta 2007 10:47 To: sip@ietf.org Cc: Sip-implementors@lists.cs.columbia.edu Subject: [Sip] URI for Emergency call? Importance: High =09 =09 Hi All, =20 This is regarding the URI for emergency call. =20 draft-ietf-ecrit-service-urn-02 says URI should be=20 urn:service:sos But 3GPP 23.003 says sip:user@sos.domain Which is the format we need to follow? Appreciate and thanks for your quick replay to this. Thanks ! Rathod. =20 This message (including any attachment) is confidential and may be legally privileged. Access to this message by anyone other than the intended recipient(s) listed above is unauthorized. If you are not the intended recipient you are hereby notified that any disclosure, copying, or distribution of the message, or any action taken or omission of action by you in reliance upon it, is prohibited and may be unlawful. Please immediately notify the sender by reply e-mail and permanently delete all copies of the message if you have received this message in error. ------_=_NextPart_001_01C80B13.F800FA87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Look=20 at 24.229, version 7.9.0.
 
Regards,
 
Christer

From: Rathod Subhashchandra=20 [mailto:rathod@tataelxsi.co.in]
Sent: 10. lokakuuta 2007=20 10:47
To: sip@ietf.org
Cc:=20 Sip-implementors@lists.cs.columbia.edu
Subject: [Sip] URI = for=20 Emergency call?
Importance: High

Hi All,
 
This is regarding the URI for = emergency=20 call.
 
draft-ietf-ecrit-service-urn-02 says = URI should=20 be

urn:service:sos

But 3GPP 23.003 says = sip:user@sos.domain

Which is the format we need to=20 follow?

Appreciate and thanks for your quick = replay to=20 this.

Thanks !

Rathod.

 

This message (including any attachment) is confidential and may be = legally=20 privileged. Access to this message by anyone other than the intended=20 recipient(s) listed above is unauthorized. If you are not the intended = recipient you are hereby notified that any disclosure, copying, or=20 distribution of the message, or any action taken or omission of action = by you=20 in reliance upon it, is prohibited and may be unlawful. Please = immediately=20 notify the sender by reply e-mail and permanently delete all copies of = the=20 message if you have received this message in=20 error.

------_=_NextPart_001_01C80B13.F800FA87-- --===============0465694733== 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 --===============0465694733==-- From sip-bounces@ietf.org Wed Oct 10 05:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfXeU-0001ij-9P; Wed, 10 Oct 2007 05:14:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfXeS-0001ib-9N for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 05:14:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfXeR-0001iR-Ts for sip@ietf.org; Wed, 10 Oct 2007 05:14:47 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfXeR-0004fY-DC for sip@ietf.org; Wed, 10 Oct 2007 05:14:47 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO00E09UNO2P@usaga01-in.huawei.com> for sip@ietf.org; Wed, 10 Oct 2007 02:07:00 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPO00KTFUNMIP@usaga01-in.huawei.com> for sip@ietf.org; Wed, 10 Oct 2007 02:07:00 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [60.42.80.93]) by szxmc03-in.huawei.com (mshttpd); Wed, 10 Oct 2007 18:06:54 +0900 Date: Wed, 10 Oct 2007 18:06:54 +0900 From: yanglili 60087 Subject: =?gb2312?B?u9i4tA==?=:[Sip] URI for Emergency call? In-reply-to: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> To: Rathod Subhashchandra Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> X-Spam-Score: 1.3 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org, Sip-implementors@lists.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: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi The Service URN is used for the request-URI. And the 'sip:user@sos.domain' is the IMPU of the originated user. Hope this helps. Cheers Lili Yang Huawei Technologies --Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA) Content-type: multipart/alternative; boundary="Boundary_(ID_3PMF0Esa03WMTBIzmVWGgA)" Content-class: urn:content-classes:message --Boundary_(ID_3PMF0Esa03WMTBIzmVWGgA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, This is regarding the URI for emergency call. draft-ietf-ecrit-service-urn-02 says URI should be urn:service:sos But 3GPP 23.003 says sip:user@sos.domain Which is the format we need to follow? Appreciate and thanks for your quick replay to this. Thanks ! Rathod. This message (including any attachment) is confidential and may be legally privileged. Access to this message by anyone other than the intended recipient(s) listed above is unauthorized. If you are not the intended recipient you are hereby notified that any disclosure, copying, or distribution of the message, or any action taken or omission of action by you in reliance upon it, is prohibited and may be unlawful. Please immediately notify the sender by reply e-mail and permanently delete all copies of the message if you have received this message in error. --Boundary_(ID_3PMF0Esa03WMTBIzmVWGgA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi All,
 
This is regarding the URI for emergency call.
 
draft-ietf-ecrit-service-urn-02 says URI should be

urn:service:sos

But 3GPP 23.003 says sip:user@sos.domain

Which is the format we need to follow?

Appreciate and thanks for your quick replay to this.

Thanks !

Rathod.

 

This message (including any attachment) is confidential and may be legally privileged. Access to this message by anyone other than the intended recipient(s) listed above is unauthorized. If you are not the intended recipient you are hereby notified that any disclosure, copying, or distribution of the message, or any action taken or omission of action by you in reliance upon it, is prohibited and may be unlawful. Please immediately notify the sender by reply e-mail and permanently delete all copies of the message if you have received this message in error.

--Boundary_(ID_3PMF0Esa03WMTBIzmVWGgA)-- --Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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 --Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA) 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 --Boundary_(ID_PTyJOqQs95ZQMbfI6CJ/cA)-- From sip-bounces@ietf.org Wed Oct 10 05:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfXn8-0008Sp-7A; Wed, 10 Oct 2007 05:23:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfXn6-0008I1-P2 for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 05:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfXn6-0008HQ-Ee for sip@ietf.org; Wed, 10 Oct 2007 05:23:44 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfXn0-0001IR-60 for sip@ietf.org; Wed, 10 Oct 2007 05:23:44 -0400 Received: by wx-out-0506.google.com with SMTP id s8so137152wxc for ; Wed, 10 Oct 2007 02:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=/UVUj1rI2q62SP718Gf/EDakjnNaOIT50pNoO5hMf44=; b=Gt4d5PZb9uw/Zsv6I/yd5IEV104tAgmoXXNx+JZ/zwdnciuEj3scHSDdu2+C8J+58UuJmkOOpm58wkuribA4ae1hCMP3mnJZYqbItxSqZ1hUdOQSZV7i3QgclJNqRiWQQ2rdxKq5gdB5u+8+xcsFiZFqIRu0tKWeRT6u7QcU6og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=m8lCuI+H9rYa/o4JuJWh1hqTuSPAy7vlSjWZQMC7p0ZrxcACR2+DCFtbsNb3IMPHTGFqjyKM38lAIvauvMXfRVk8zOz2Wp0gM9i0XRzoaoHZaTnvCVQT/VB7Lvo1/gFbQ0J5ya2I6lXITkN6yWa4z5KNYWq66cFieF73/83lzsg= Received: by 10.70.45.10 with SMTP id s10mr893381wxs.1192008202713; Wed, 10 Oct 2007 02:23:22 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Wed, 10 Oct 2007 02:23:22 -0700 (PDT) Message-ID: <18a603a60710100223x8c84b4dm99f670cd89437fc3@mail.gmail.com> Date: Wed, 10 Oct 2007 11:23:22 +0200 From: "Pars Mutaf" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <200710091800.l99I0pXk030724@dragon.ariadne.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <20071009161749.EF6207E02@bender.tigertech.net> <18a603a60710091020y6c3b44a6la4f2bf7bb4580aa4@mail.gmail.com> <200710091800.l99I0pXk030724@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Content-Type: multipart/mixed; boundary="===============0169300623==" Errors-To: sip-bounces@ietf.org --===============0169300623== Content-Type: multipart/alternative; boundary="----=_Part_6967_22459739.1192008202709" ------=_Part_6967_22459739.1192008202709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Dale.Worley@comcast.net wrote: > > I find the whole problem statement mysterious. The stated problem is, > "How do I find a person's SIP URI without having them present to ask?" 1) How do I find a person's SIP URI without having them present to ask. 2) When the person is present, how do we exchange our SIP URIs and possibly other information easily. I.e., simply by typing a name we get the phones paired. Note that the protocol can be used for requesting any combination of various identifiers from the target phone. For example, you will probably need a Mobile IPv6 home address too. In this case, you will request a SIP URI and a Mobile IPv6 home address (concurrently) from the target phone. and "How do I prevent unauthorized people from obtaining this > information?" Obviously, a message with the querier user's name will be displayed on the target phone: Pairing request from Michael Jordan. Accept? [YES/NO] Of course, authentication needed between cell phone operators. If a cerfiticate is unknown, the target user should be warned. The first part is a general phone book problem. But by hypothesis, it > requires relatively little authentication of me to obtain the SIP URI. > Yes, you can propose a step where the inquiry is passed to the target > for approval, but that means that anyone who attempts a lookup can > annoy the target person -- a direct failure of the privacy goal, since > the inquirer has just contacted the target! This is a very good question. Here is an abstract solution: Before the pairing request can be displayed on the target screen, the querier "user" will need to solve a challenge. For example a CAPTCHA. The attack that you mention above is similar to knocking at the door of someone and running away. This could happen (I myself did that, I confess :-/ ). In our case the attack is even more stupid because the attacker has to solve a difficult problem before disturbing someone! If you want people to be interested in this, you're going to have to > assemble a much better problem statement and at least one plausible > solution, I think. One plausible solution to me (a serverless one) can be based on mDNS, but for wireless local use only. Dean Willis is suggesting a solution based on SIP consent framework. Others see it as extension to LDAP. DNS based solutions are also being mentioned. My suspicion is that treating the SIP URI itself has having strong > privacy requirements, but not treating the information needed to look > up the SIP URI as not having strong privacy requirements, is not going > to make any difference unless the process that maps between the two > has strong authentication of the inquirer. I hope that I could answer this above. Thanks, pars 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 > ------=_Part_6967_22459739.1192008202709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 10/9/07, Dale.Worley@comcast.net <Dale.Worley@comcast.net> wrote:
I find the whole problem statement mysterious.  The stated problem is,
"How do I find a person's SIP URI without having them present to ask?"

1) How do I find a person's SIP URI without having them present to ask.
2) When the person is present, how do we exchange our SIP URIs and
possibly other information easily. I.e., simply by typing a name we get the
phones paired.

Note that the protocol can be used for requesting any combination of
various identifiers from the target phone. For example, you will probably
need a Mobile IPv6 home address too. In this case, you will request
a SIP URI and a Mobile IPv6 home address (concurrently) from the
target phone.


and "How do I prevent unauthorized people from obtaining this
information?"

Obviously, a message with the querier user's name will be
displayed on the target phone:

               Pairing request from
               Michael Jordan. Accept? [YES/NO]

Of course, authentication needed between cell phone operators.
If a cerfiticate is unknown, the target user should be warned.
 

The first part is a general phone book problem.  But by hypothesis, it
requires relatively little authentication of me to obtain the SIP URI.
Yes, you can propose a step where the inquiry is passed to the target
for approval, but that means that anyone who attempts a lookup can
annoy the target person -- a direct failure of the privacy goal, since
the inquirer has just contacted the target!

This is a very good question. Here is an abstract solution:

Before the pairing request can be displayed on the target screen,
the querier "user" will need to solve a challenge. For example a CAPTCHA.
The attack that you mention above is similar to knocking at the door
of someone and running away. This could happen (I myself did that, I confess :-/  ).
In our case the attack is even more stupid because the attacker
has to solve a difficult problem before disturbing someone!
 

If you want people to be interested in this, you're going to have to
assemble a much better problem statement and at least one plausible
solution, I think.

One plausible solution to me (a serverless one) can be based on mDNS, but for wireless local use only.
Dean Willis is suggesting a solution based on SIP consent framework.
Others see it as extension to LDAP.
DNS based solutions are also being mentioned.


My suspicion is that treating the SIP URI itself has having strong
privacy requirements, but not treating the information needed to look
up the SIP URI as not having strong privacy requirements, is not going
to make any difference unless the process that maps between the two
has strong authentication of the inquirer.

I hope that I could answer this above.

Thanks,
pars


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

------=_Part_6967_22459739.1192008202709-- --===============0169300623== 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 --===============0169300623==-- From sip-bounces@ietf.org Wed Oct 10 06:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYTp-00040J-V5; Wed, 10 Oct 2007 06:07:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfYTo-000404-4z for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 06:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYTn-0003tE-Qz for sip@ietf.org; Wed, 10 Oct 2007 06:07:51 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound8-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfYTc-00033p-Mx for sip@ietf.org; Wed, 10 Oct 2007 06:07:46 -0400 Received: from outbound8-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-blu-R.bigfish.com (Postfix) with ESMTP id 504919DE6B4; Wed, 10 Oct 2007 10:07:29 +0000 (UTC) Received: from mail46-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound8-blu.bigfish.com (Postfix) with ESMTP id 42BA8600052; Wed, 10 Oct 2007 10:07:29 +0000 (UTC) Received: from mail46-blu (localhost.localdomain [127.0.0.1]) by mail46-blu-R.bigfish.com (Postfix) with ESMTP id 14B1F1A000CF; Wed, 10 Oct 2007 10:07:29 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail46-blu (MessageSwitch) id 119201084968542_18868; Wed, 10 Oct 2007 10:07:29 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail46-blu.bigfish.com (Postfix) with ESMTP id 37CA83F805B; Wed, 10 Oct 2007 10:07:28 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] URI for Emergency call? Date: Wed, 10 Oct 2007 11:06:22 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] URI for Emergency call? Thread-Index: AcgLH012932eRG+YTemxRuljJwhOyAABa4zA From: "Dan Warren" To: "yanglili 60087" , "Rathod Subhashchandra" X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, Sip-implementors@lists.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: , Content-Type: multipart/mixed; boundary="===============1073540092==" Errors-To: sip-bounces@ietf.org --===============1073540092== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IERvZXMgdGhpcyBpbXBseSB0aGVuIHRoYXQgYWxsIElNUyBzdWJzY3JpYmVyIHByb2ZpbGVzIGhh dmUgdG8gaW5jbHVkZSB0aGlzIElNUFU/ICBPciBpcyBpdCBleHBlY3RlZCB0aGF0IHRoZSBJTVBV IGlzIGNvbmZpZ3VyZWQgb24gYWxsIGRldmljZXMgYW5kIGlzIHJvdXRlZCBieSByb3RlIGluIHRo ZSBuZXR3b3JrPw0KDQpEYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiB5YW5nbGlsaSA2MDA4NyBbbWFpbHRvOmthZHl5YW5nQGh1YXdlaS5jb21dIA0KPiBTZW50OiAx MCBPY3RvYmVyIDIwMDcgMTA6MDcNCj4gVG86IFJhdGhvZCBTdWJoYXNoY2hhbmRyYQ0KPiBDYzog c2lwQGlldGYub3JnOyBTaXAtaW1wbGVtZW50b3JzQGxpc3RzLmNzLmNvbHVtYmlhLmVkdQ0KPiBT dWJqZWN0OiDlm57lpI06W1NpcF0gVVJJIGZvciBFbWVyZ2VuY3kgY2FsbD8NCj4gDQo+IA0KPiAN Cj4gSGkNCj4gDQo+IFRoZSBTZXJ2aWNlIFVSTiBpcyB1c2VkIGZvciB0aGUgcmVxdWVzdC1VUkku DQo+IA0KPiBBbmQgdGhlICdzaXA6dXNlckBzb3MuZG9tYWluJyBpcyB0aGUgSU1QVSBvZiB0aGUg b3JpZ2luYXRlZCB1c2VyLg0KPiANCj4gSG9wZSB0aGlzIGhlbHBzLg0KPiANCj4gQ2hlZXJzDQo+ IExpbGkgWWFuZw0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIA0KPiANCj4gIA0KPiANCj4gDQoKRm9y dGhjb21pbmcgR1NNQSBFdmVudHM6CiAKR1NNQSBNb2JpbGUgQXNpYSBDb25ncmVzcwpNYWNhdQox MiAtIDE1IE5vdmVtYmVyIDIwMDcKd3d3Lm1vYmlsZWFzaWFjb25ncmVzcy5jb20KIApHU01BIE1v YmlsZSBXb3JsZCBDb25ncmVzcwpCYXJjZWxvbmEKMTEgLSAxNCBGZWJydWFyeSAyMDA4Cnd3dy5t b2JpbGV3b3JsZGNvbmdyZXNzLmNvbQoKClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBh cmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50 aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBh Y3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFu eW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDc1OSAyMzAw IGFuZCBoaWdobGlnaHQgdGhlIGVycm9yCg== --===============1073540092== 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 --===============1073540092==-- From sip-bounces@ietf.org Wed Oct 10 09:16:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbKp-0005t2-GC; Wed, 10 Oct 2007 09:10:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfbKo-0005sk-KX for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 09:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbKn-0005sV-Ur for sip@ietf.org; Wed, 10 Oct 2007 09:10:45 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfbKh-0000Uv-P1 for sip@ietf.org; Wed, 10 Oct 2007 09:10:45 -0400 Received: by an-out-0708.google.com with SMTP id c17so4724anc for ; Wed, 10 Oct 2007 06:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=jf7uJf46TaZ3q2AeX2HDKCjwn7+c+OB8Lz1MjlKiJhQ=; b=EsKZnCnWrhSbwo9y6xsqc0UuFkrWE5GB56jSToDJef3/npvf3nwaD/20dTdT2B5TGi/0QGQv0LF9TWZES8RArd/pnfbAHjYz85L0IyfWc6Kjb5q+pSY3TOLoPpCnpFBckJ2WE+PFBzcgJwZTXpfIHIsNiS+OuUdy9WfJOy7yTzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=I3Eybee6h+21Cqbklwm0XYV/KBYHCxTVB8DcA2N3eh3AYE1B8DzOJ0CYcg3neiCnk9uItCJqlPxopxl7cE+Hp9FAPEh5zhFSssQc5bsh7Wnw1wXzUjXU+phPQ/AlASGm1c7vRqgksd5lokvXWVVzV2QzbfydXtAF8EGrljj33aw= Received: by 10.142.100.1 with SMTP id x1mr63425wfb.1192021796264; Wed, 10 Oct 2007 06:09:56 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Wed, 10 Oct 2007 06:09:56 -0700 (PDT) Message-ID: <18a603a60710100609u46f901d2o2abfce95294280b3@mail.gmail.com> Date: Wed, 10 Oct 2007 15:09:56 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470BC9C4.8080606@cisco.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <470B8400.7080208@cisco.com> <470B9398.2070706@nostrum.com> <18a603a60710090808p3c8a70co8992e1d7bb1711ae@mail.gmail.com> <470BC9C4.8080606@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Content-Type: multipart/mixed; boundary="===============0204838613==" Errors-To: sip-bounces@ietf.org --===============0204838613== Content-Type: multipart/alternative; boundary="----=_Part_8054_23883743.1192021796220" ------=_Part_8054_23883743.1192021796220 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/9/07, Paul Kyzivat wrote: > > > > Pars Mutaf wrote: > > > > Thanks! But there is another question first. Will you subscribe: > > > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > I subscribe to a lot of lists. I need some motivation before subscribing > to another one. One more doesn't hurt? :-) Thanks a lot for your suggestions below, I'm trying to make a case for telephony people in general. I would like to thank the SIP WG for their comments. An area director suggested me to ask SIP WG feedback. I'll send a mail to humanresolvers pointing to this discussion. I hope to see you there for in-depth discussions on the problem statement, requirements and solution space. Regards, pars mutaf I expect a lot of people on *this* list are in the same > boat. > > You have gotten some people to respond to you here, though there is > clearly a lot of skepticism. You will probably have better luck getting > people to discuss here than at a new list. At least maybe you can try > here to make a case for why people want to participate in your > humanresolvers list. > > Paul > ------=_Part_8054_23883743.1192021796220 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/9/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Pars Mutaf wrote:
>
> Thanks! But there is another question first. Will you subscribe:
>
> https://www1.ietf.org/mailman/listinfo/humanresolvers

I subscribe to a lot of lists. I need some motivation before subscribing
to another one.

One more doesn't hurt? :-)

Thanks a lot for your suggestions below, I'm trying to make
a case for telephony people in general. I would like to thank
the SIP WG for their comments. An area director suggested
me to ask SIP WG feedback.

I'll send a mail to humanresolvers pointing to this discussion.

I hope to see you there for in-depth discussions on the
problem statement, requirements and solution space.

Regards,

pars mutaf


 




 

I expect a lot of people on *this* list are in the same
boat.

You have gotten some people to respond to you here, though there is
clearly a lot of skepticism. You will probably have better luck getting
people to discuss here than at a new list. At least maybe you can try
here to make a case for why people want to participate in your
humanresolvers list.

        Paul

------=_Part_8054_23883743.1192021796220-- --===============0204838613== 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 --===============0204838613==-- From sip-bounces@ietf.org Wed Oct 10 11:41:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfddA-0006CX-D1; Wed, 10 Oct 2007 11:37:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifdd9-0006CB-QF for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 11:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdd9-0006C3-GO for sip@ietf.org; Wed, 10 Oct 2007 11:37:51 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifdd0-0005vb-A7 for sip@ietf.org; Wed, 10 Oct 2007 11:37:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9AFbOt01743; Wed, 10 Oct 2007 15:37:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 10:37:07 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoA== References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! < 8F65DB 2 7-41ED-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: sip-bounces@ietf.org =20 > Ignorning the reason why people are using INFO is not going=20 > to make things better either... >=20 > I think most people are aware of KPML etc - we don't need to=20 > tell them that. I seriously don't think people are using INFO because they think it's=20 better than KPML. I think peopled use to use INFO because (a) they implemented it before RFC 2833, and (b) because it was difficult for them to implement RFC 2833 when it got implemented and (c) KPML didn't exist at that time. I believe at this point, this is an imaginary issue. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 10 12:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeIb-00079I-M6; Wed, 10 Oct 2007 12:20:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfeIZ-000763-Qo for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:20:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeIZ-00075v-Ft for sip@ietf.org; Wed, 10 Oct 2007 12:20:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfeIY-0001V0-US for sip@ietf.org; Wed, 10 Oct 2007 12:20:39 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4C2C120482; Wed, 10 Oct 2007 18:20:38 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-ce-470cfbd69ae4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27BBB20051; Wed, 10 Oct 2007 18:20:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:20:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 18:20:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoAAA8Q80 References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! < 8F65 DB 2 7-41ED-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Dean Willis" X-OriginalArrivalTime: 10 Oct 2007 16:20:37.0890 (UTC) FILETIME=[7E4B0620:01C80B59] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: , Errors-To: sip-bounces@ietf.org Hi, >> Ignorning the reason why people are using INFO is not going >> to make things better either... >> >> I think most people are aware of KPML etc - we don't need to >> tell them that. >I seriously don't think people are using INFO because they think it's >better than KPML. >I think peopled use to use INFO because (a) they implemented it before >RFC 2833, and (b) because it was difficult for them to implement >RFC 2833 when it got implemented and (c) KPML didn't exist at that = time. (d) they think it's a waste of resources to establish multiple = additional subscription dialogs (there may be other type of data than = DTMF they are willing to receive) which in many cases may not even be = used during the call (it can not be assumed that the one sending the = subscription always knows exactly when it will receive events). Maybe = DTMF is not the best example in the world (my fault - I should have been = more generic), but I am sure there could be events which would not be = used in a very high percentage of all calls, but still the additional = subscription dialog(s) would have to be established - just in case. =20 I still strongly think it would be much better to describe the = issues/advantages/disadvantages with BOTH INFO and events, and study = what possible needs to defined related to negotiation etc, instead of = just ignoring the real world and providing flexibility to people using = SIP for their applications... =20 Regards, =20 Christer =20 =20 =20 =20 I believe at this point, this is an imaginary issue. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 10 13:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffdq-0000lR-Tg; Wed, 10 Oct 2007 13:46:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iffdp-0000kJ-FJ for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 13:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffdo-0000jo-QR; Wed, 10 Oct 2007 13:46:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iffdn-0002FX-IY; Wed, 10 Oct 2007 13:46:40 -0400 X-IronPort-AV: E=Sophos;i="4.21,255,1188802800"; d="scan'208";a="11732472" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2007 10:46:39 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9AHkcuY006477; Wed, 10 Oct 2007 10:46:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9AHkZpH008689; Wed, 10 Oct 2007 17:46:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:46:32 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.70.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:46:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Oct 2007 12:46:29 -0500 To: "Dan Warren" , "yanglili 60087" , "Rathod Subhashchandra" From: "James M. Polk" Subject: RE: [Sip] URI for Emergency call? In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TL D> References: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TLD> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 10 Oct 2007 17:46:31.0649 (UTC) FILETIME=[7E2C3D10:01C80B65] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2035; t=1192038398; x=1192902398; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20URI=20for=20Emergency=20call? |Sender:=20; bh=5YQFobhlu+MgHIanu+kmtPYE+lDT03PKVIT8DDsjsf4=; b=jqp2C70F8WPR7YIfy+WNMWEMIri5JYYcqWYWrB4EvWPnOA6rnJRyVl19xgx/thoNj9tSZLXJ dTGxFhu/2FHR7NU1Mswfj+cSc1RIX4Vnxgngv6yJlB5bZMKe1IvxU3gUMziDAIPQAROZrZE74I RqeYwflRFCbixfHPhWHtLkYr8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, "'ecrit@ietf.org'" , Sip-implementors@lists.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: , Errors-To: sip-bounces@ietf.org This discussion belongs on the ECRIT list, since=20 you're asking questions about an ECRIT document http://www.ietf.org/html.charters/ecrit-charter.html [I've added ecrit added here, but kept sip on=20 this message to make sure all who read this=20 message on the sip list know this thread should move lists] At 05:06 AM 10/10/2007, Dan Warren wrote: >Content-class: urn:content-classes:message >Content-Type: text/plain; > charset=3D"UTF-8" > > Does this imply then that all IMS subscriber=20 > profiles have to include this IMPU? Or is it=20 > expected that the IMPU is configured on all=20 > devices and is routed by rote in the network? > >Dan > > > -----Original Message----- > > From: yanglili 60087 [mailto:kadyyang@huawei.com] > > Sent: 10 October 2007 10:07 > > To: Rathod Subhashchandra > > Cc: sip@ietf.org; Sip-implementors@lists.cs.columbia.edu > > Subject: =E5=9B=9E=E5=A4=8D:[Sip] URI for Emergency call? > > > > Hi > > > > The Service URN is used for the request-URI. > > > > And the 'sip:user@sos.domain' is the IMPU of the originated user. > > > > Hope this helps. > > > > Cheers > > Lili Yang > > Huawei Technologies > > >Forthcoming GSMA Events: GSMA Mobile Asia=20 >Congress Macau 12 - 15 November 2007=20 >www.mobileasiacongress.com GSMA Mobile World=20 >Congress Barcelona 11 - 14 February 2008=20 >www.mobileworldcongress.com This email and its=20 >attachments are intended for the above named=20 >only and may be confidential. If they have come=20 >to you in error you must take no action based on=20 >them, nor must you copy or show them to anyone;=20 >please reply to this email or call +44 207 759=20 >2300 and highlight the error= _______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 10 18:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjVy-0008IL-3I; Wed, 10 Oct 2007 17:54:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfjVx-0008Hv-3E for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 17:54:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfjVw-00082H-OM for sip@ietf.org; Wed, 10 Oct 2007 17:54:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfjVm-0003rK-6h for sip@ietf.org; Wed, 10 Oct 2007 17:54:38 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9ALsVon018695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Oct 2007 16:54:33 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F65DB 2 7-41ED-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76AA5CC3-0307-4614-8C14-7684DE9C83C2@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 16:54:10 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 10, 2007, at 10:37 AM, Francois Audet wrote: > > >> Ignorning the reason why people are using INFO is not going >> to make things better either... >> >> I think most people are aware of KPML etc - we don't need to >> tell them that. > > I seriously don't think people are using INFO because they think it's > better than KPML. > > I think peopled use to use INFO because (a) they implemented it before > RFC 2833, and (b) because it was difficult for them to implement > RFC 2833 when it got implemented and (c) KPML didn't exist at that > time. > > I believe at this point, this is an imaginary issue. Well, let's imagine we aren't talking about DTMF. If I were cobbling together a SIP app that needed to exchange blobs alongside an extant dialog, I'd have to say I'd be tempted to use INFO despite all the caveats. It's a heck of a lot easier than implementing a new event package, and much less overhead too. Now, wouldn't it be just as easy to invent a new SIP method to transport my blob? It might be. That depends on my stack and on any confounded SBCs in the loop. In both cases, it's probably easier to just slap a new media type into an INFO. This gets back to my question of "What is the proper SIP extension model?" Do we do new methods or new payloads for existing methods? Or something else? Classic SIP says "new method, same dialog". INFO says "new payload, INFO method, same dialog". SUB/NOT says "new payload, new SUBSCRIBE dialog, method". Purist SIP says "Make the blob into media, reinvite for the new media". SIMPLE says "Carry the blob in an MSRP session, reinvite for MSRP". We've got too many potato peelers and a lot of nervous cats here, folks. How do we choose our tool? -- 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 10 18:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifjdx-0001K1-8n; Wed, 10 Oct 2007 18:03:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifjdv-0001Jr-Pf for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 18:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifjdv-0001JP-Fp for sip@ietf.org; Wed, 10 Oct 2007 18:03:03 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifjdq-0002QQ-Uy for sip@ietf.org; Wed, 10 Oct 2007 18:03:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9AM2g800123; Wed, 10 Oct 2007 22:02:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 17:02:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF126BCF4A@zrc2hxm0.corp.nortel.com> In-Reply-To: <76AA5CC3-0307-4614-8C14-7684DE9C83C2@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgLiCmgfV31IyqCTGu8cyTX8JYtUAAAELvw References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! < 8F 65DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <76AA5CC3-0307-4614-8C14-7684DE9C83C2@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > Well, let's imagine we aren't talking about DTMF. Good. > If I were cobbling together a SIP app that needed to exchange=20 > blobs alongside an extant dialog, I'd have to say I'd be=20 > tempted to use INFO despite all the caveats. It's a heck of a=20 > lot easier than implementing a new event package, and much=20 > less overhead too. >=20 > Now, wouldn't it be just as easy to invent a new SIP method=20 > to transport my blob? It might be. That depends on my stack=20 > and on any confounded SBCs in the loop. In both cases, it's=20 > probably easier to just slap a new media type into an INFO. >=20 > This gets back to my question of "What is the proper SIP=20 > extension model?" Do we do new methods or new payloads for=20 > existing methods? Or something else? >=20 > Classic SIP says "new method, same dialog". INFO says "new=20 > payload, INFO method, same dialog". SUB/NOT says "new=20 > payload, new SUBSCRIBE dialog, method". Purist SIP says "Make=20 > the blob into media, reinvite for the new media". SIMPLE says=20 > "Carry the blob in an MSRP session, reinvite for MSRP". >=20 > We've got too many potato peelers and a lot of nervous cats=20 > here, folks. How do we choose our tool? Maybe what is needed is a description of which of these mechanism is appropriate for what class of extension? And is there a case where one of the non-INFO is not appropriate? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 10 18:19:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifjqt-0002V4-3E; Wed, 10 Oct 2007 18:16:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifjqq-0002Tr-Tn for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 18:16:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifjqp-0002QG-8W for sip@ietf.org; Wed, 10 Oct 2007 18:16:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifjqp-0004OY-0p for sip@ietf.org; Wed, 10 Oct 2007 18:16:23 -0400 X-IronPort-AV: E=Sophos;i="4.21,256,1188792000"; d="scan'208";a="73712307" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2007 18:16:22 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9AMGM19024181; Wed, 10 Oct 2007 18:16:22 -0400 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 l9AMG5rl001373; Wed, 10 Oct 2007 22:16:14 GMT 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.1830); Wed, 10 Oct 2007 18:16:09 -0400 Received: from [10.86.241.48] ([10.86.241.48]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:16:08 -0400 Message-ID: <470D4F27.6070509@cisco.com> Date: Wed, 10 Oct 2007 18:16:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F65DB 2 7-41ED-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <76AA5CC3-0307-4614-8C14-7684DE9C83C2@softarmor.com> In-Reply-To: <76AA5CC3-0307-4614-8C14-7684DE9C83C2@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2007 22:16:08.0902 (UTC) FILETIME=[28912660:01C80B8B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15474.002 X-TM-AS-Result: No--10.553500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=145; t=1192054582; x=1192918582; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20What=20are=20we=20arguing=20about=20when=20we=20say=2 0INFO?=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20 |To:=20Dean=20Willis=20; bh=1VuO93VaCFvj1vMxWF60ilC+DxJCax7J90mFWIT5Wp4=; b=jn1ixOZh2cxOlUv+4dhIb24j6rlD/7rYPOZuPhx5HWu+YbPdScZUL0g61HfRYhamHrHjmWXt X3xOPsTkDWBDVQBcuCyTfMvTgBSG3ya+1Im4ItT5FKU+nHnU6QzTqcdP; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > We've got too many potato peelers and a lot of nervous cats here, folks. Spoken like a true dog owner! 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 10 19:20:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifkld-0000X7-Rk; Wed, 10 Oct 2007 19:15:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifklc-0000NF-6e for sip-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 19:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifklb-0000Kd-Rf for sip@ietf.org; Wed, 10 Oct 2007 19:15:03 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfklW-0004c6-GA for sip@ietf.org; Wed, 10 Oct 2007 19:15:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9ANEjt25032; Wed, 10 Oct 2007 23:14:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 18:14:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoAAA8Q80AA7KEfA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org =20 > (d) they think it's a waste of resources to establish=20 > multiple additional subscription dialogs (there may be other=20 > type of data than DTMF they are willing to receive) which in=20 > many cases may not even be used during the call (it can not=20 > be assumed that the one sending the subscription always knows=20 > exactly when it will receive events). Maybe DTMF is not the=20 > best example in the world (my fault - I should have been more=20 > generic), but I am sure there could be events which would not=20 > be used in a very high percentage of all calls, but still the=20 > additional subscription dialog(s) would have to be=20 > established - just in case. Maybe a way to subscribe to packages within an INVITE dialog would be suitable. You then would get the NOTIFYs withind the dialog, and they wouldn't be out-of-the-blue because you would have subscribed to those events explicitly with some Allow-Event in the INVITE.=20 I know many people will hate this idea but, I do agree with Christer that subscribing to an event package "just in case" when it normally is not used is quite a huge overhead and explain why people just use INFO instead. > I still strongly think it would be much better to describe=20 > the issues/advantages/disadvantages with BOTH INFO and=20 > events, and study what possible needs to defined related to=20 > negotiation etc, instead of just ignoring the real world and=20 > providing flexibility to people using SIP for their applications... I think the idea above would address this and avoid the INFO pitfalls. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 11 00:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpWz-0007yg-Gz; Thu, 11 Oct 2007 00:20:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IfpWy-0007yS-5V for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 00:20:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpWx-0007yK-QS for sip@ietf.org; Thu, 11 Oct 2007 00:20:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfpWx-00005A-0i for sip@ietf.org; Thu, 11 Oct 2007 00:20:15 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9B4K85P020850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Oct 2007 23:20:10 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 10 Oct 2007 23:19:47 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 10, 2007, at 6:14 PM, Francois Audet wrote: > >> (d) they think it's a waste of resources to establish >> multiple additional subscription dialogs (there may be other >> type of data than DTMF they are willing to receive) which in >> many cases may not even be used during the call (it can not >> be assumed that the one sending the subscription always knows >> exactly when it will receive events). Maybe DTMF is not the >> best example in the world (my fault - I should have been more >> generic), but I am sure there could be events which would not >> be used in a very high percentage of all calls, but still the >> additional subscription dialog(s) would have to be >> established - just in case. > > Maybe a way to subscribe to packages within an INVITE dialog would > be suitable. You then would get the NOTIFYs withind the dialog, and > they wouldn't be out-of-the-blue because you would have subscribed > to those events explicitly with some Allow-Event in the INVITE. > Hmm. In-dialog event notification using INVITE as an explicit subscription trigger. That works, mostly. Other people would argue that the semantics are better preserved with a a new SIP method that is defined to carry whatever sort of blob we're talking about in the specific context of the application usage. We'd then add that method name to the list of supported methods given in the Allow header field. Of course, this will eventually give us "Really Big" Allow header fields, which means the negotiation mechanism is broken. We need an easier way for one end to ask "Hey, do you understand this?". Others would say that the we're better off defining a session protocol designed to transport the blobs in question, along with SDP extensions to negotiate this protocol, NAT-traversal hooks to allow us to talk about the connectivity of the blob-transferral protocol, then do a reINVITE exchange to add the new blob-session to the existing session. Yet others would say that we already have a blob-transferral protocol (MSRP), along with the nat traversal hooks and SDP extensions needed to negotiate it, and should therefore push the problem out one layer of protocol and make it an MSRP problem. This begs the question of how MSRP negotiates as to whether the context and content are agreed on both ends, which AFAIK it does little better at than INFO. So what's the difference? All (assuming we figure out the MSRP context negotiation problem) explicitly declare the understanding of and the desire to receive messages within this dialog/session that contain the data we've defined and assure that the application context (the "what do I do with this stuff" problem) is mutually understood. The differences are that one approach is the extension of an application protocol to support a new application, while two others are extensions of existing transport protocols (SIP, MSRP) to carry new payloads in contexts determined by the applications. The last one implies the development of an all-new transport protocol (or perhaps the modification of some other protocol like RTP) as well as extension to our descriptive protocol (SDP). These are very different things, and part of the reason that SIP has gotten more complex than I would like is that we haven't been operating with a clear understanding of these differences. Personally, I think that we've got a lot of complexity there that we didn't really need. If SIP had been designed from the ground-up as a transport protocol for arbitrary messages and the application were a function of the message content, we'd have a much clearer model of what to do. But it wasn't built that way, so now we need some guiding principles on when each sort of approach is appropriate. Without it, we're just going to go around in circles on the "Is INFO harmful, and if so why?" carousel. Since I can't leave it hanging there, I'd like to propose some rules of thumb: 1) If INFO had context negotiation, we'd have a complete protocol and would quite possibly only need new SIP method types if there was a need for a fundamental change to the SIP state machine. Even without INFO, we have the same functionality available, albeit at the overhead of an additional dialog. So, I suggest we only introduce new SIP methods if there's a need to change the underlying machine. If we're just moving new data in application contexts, we can do that without changing SIP itself. I really don't want to keep the SIP WG around just so we can specify a new SIP method for each application somebody dreams up. 2) Since SIP can provide for the transport of arbitrary data and application context, we should only use "session" transport of the data when that dataflow itself has fundamentally different characteristics -- essentially, when it is a long-lived and relatively continues flow, aka a "stream". Quite possibly, this should extend to only dataflows that have the properties of RTP -- time sensitive, relatively loss insensitive, and so bulky we need them to be as end-to-end as we can even if it means building more infrastructure to make that happen. And yes, I think MSRP is a misguided effort -- by the time we've built MSRP relays and all the extra cruft, we've duplicated SIP's message proxy operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm not even sure that this level of separation is a good idea. Coaxial signaling and media have great advantages for firewall traversal. But we have what we have. In short, use RTP/MSRP for "sessions", and SIP event payloads (or contextually-adapted INFO) for everything else. 3) There is no rule 3. -- 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 11 00:47:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifpu8-0004QH-HF; Thu, 11 Oct 2007 00:44:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifpu7-0004P6-7q for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 00:44:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifpu6-0004Ow-PL for sip@ietf.org; Thu, 11 Oct 2007 00:44:10 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifpu6-0000fZ-7Y for sip@ietf.org; Thu, 11 Oct 2007 00:44:10 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9B4h8a2001954; Wed, 10 Oct 2007 23:44:09 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 23:43:20 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 06:43:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] URI for Emergency call? Date: Thu, 11 Oct 2007 06:43:15 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180017A9066@DEEXC1U01.de.lucent.com> In-Reply-To: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] URI for Emergency call? Thread-Index: AcgLEbYr8FAX/AY/SH6T6/5pTQxokAAr1Peg References: <9D5E1752379A43408015F7FE984661155CDC26@CHNEXVS01.VSNLXCHANGE.COM> From: "DRAGE, Keith \(Keith\)" To: "Rathod Subhashchandra" , X-OriginalArrivalTime: 11 Oct 2007 04:43:17.0779 (UTC) FILETIME=[3E0E7E30:01C80BC1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Sip-implementors@lists.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: , Content-Type: multipart/mixed; boundary="===============0235516503==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0235516503== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80BC1.3DDB0F8F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80BC1.3DDB0F8F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are comparing apples and oranges. =20 The first of these is the URI to which an emergency call is addressed =20 The second is the public user identity of the caller when making an = emergency call. =20 regards =20 Keith ________________________________ From: Rathod Subhashchandra [mailto:rathod@tataelxsi.co.in]=20 Sent: Wednesday, October 10, 2007 8:47 AM To: sip@ietf.org Cc: Sip-implementors@lists.cs.columbia.edu Subject: [Sip] URI for Emergency call? Importance: High =09 =09 Hi All, =20 This is regarding the URI for emergency call. =20 draft-ietf-ecrit-service-urn-02 says URI should be=20 urn:service:sos But 3GPP 23.003 says sip:user@sos.domain Which is the format we need to follow? Appreciate and thanks for your quick replay to this. Thanks ! Rathod. =20 This message (including any attachment) is confidential and may be = legally privileged. Access to this message by anyone other than the = intended recipient(s) listed above is unauthorized. If you are not the = intended recipient you are hereby notified that any disclosure, copying, = or distribution of the message, or any action taken or omission of = action by you in reliance upon it, is prohibited and may be unlawful. = Please immediately notify the sender by reply e-mail and permanently = delete all copies of the message if you have received this message in = error. ------_=_NextPart_001_01C80BC1.3DDB0F8F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You are comparing apples and = oranges.
 
The first of these is the URI to which an = emergency call is=20 addressed
 
The second is the public user identity of the = caller when=20 making an emergency call.
 
regards
 
Keith

From: Rathod Subhashchandra=20 [mailto:rathod@tataelxsi.co.in]
Sent: Wednesday, October = 10, 2007=20 8:47 AM
To: sip@ietf.org
Cc:=20 Sip-implementors@lists.cs.columbia.edu
Subject: [Sip] URI = for=20 Emergency call?
Importance: High

Hi All,
 
This is regarding the URI for = emergency=20 call.
 
draft-ietf-ecrit-service-urn-02 says = URI should=20 be

urn:service:sos

But 3GPP 23.003 says = sip:user@sos.domain

Which is the format we need to=20 follow?

Appreciate and thanks for your quick = replay to=20 this.

Thanks !

Rathod.

 

This message (including any attachment) is confidential and may be = legally=20 privileged. Access to this message by anyone other than the intended=20 recipient(s) listed above is unauthorized. If you are not the intended = recipient you are hereby notified that any disclosure, copying, or=20 distribution of the message, or any action taken or omission of action = by you=20 in reliance upon it, is prohibited and may be unlawful. Please = immediately=20 notify the sender by reply e-mail and permanently delete all copies of = the=20 message if you have received this message in=20 error.

------_=_NextPart_001_01C80BC1.3DDB0F8F-- --===============0235516503== 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 --===============0235516503==-- From sip-bounces@ietf.org Thu Oct 11 02:42:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrfr-0000Uy-1M; Thu, 11 Oct 2007 02:37:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifrfp-0000UY-BH for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 02:37:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrfo-0000UP-Nb for sip@ietf.org; Thu, 11 Oct 2007 02:37:32 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifrfo-00053v-0r for sip@ietf.org; Thu, 11 Oct 2007 02:37:32 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l9B6bF9r016152; Thu, 11 Oct 2007 08:37:16 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l9B6bDwK020193; Thu, 11 Oct 2007 08:37:15 +0200 Received: from MCHP7I7A.ww002.siemens.net ([139.25.131.138]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 08:37:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Review of draft-ietf-sip-media-security-requirements-00 Date: Thu, 11 Oct 2007 08:37:10 +0200 Message-ID: <454C097A8CB3F14BB73494D0CE053DBE2C339D@MCHP7I7A.ww002.siemens.net> In-Reply-To: <470A2B54.6060905@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-ietf-sip-media-security-requirements-00 Thread-Index: AcgJrgnGV/ZnTCBgQfCUbr+PjzEF+wCIetQg References: <470A2B54.6060905@bbn.com> From: "Fries, Steffen" To: "Richard Barnes" , "IETF SIP List" X-OriginalArrivalTime: 11 Oct 2007 06:37:12.0897 (UTC) FILETIME=[281ABB10:01C80BD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: sip-bounces@ietf.org Hi Richard, thank you for the detailed review of the draft. We already incorporated suggestions and enhancements you proposed and are preparing an updated version, which will be submitted soon.=20 Ciao Steffen > 1. As a document proposing requirements for a security=20 > protocol, this document needs more discussion of the system=20 > being protected and the level of protection that the desired=20 > protocol is to support. Section 5 is a good start on this,=20 > and it should be moved forward to be just after the=20 > Terminology section. > 2. I think the fundamental security requirement that you're=20 > driving at is that the protocol should have a mode of=20 > operation in which an attacker must mount active attacks on=20 > BOTH the signaling and media path in order to gain access to=20 > the keys being negotiated by the protocol, and that even in=20 > this case, the attack should be detectable by the endpoints. =20 > This is essentially what's being encoded in requirements R1,=20 > R2, and R17, but this should be made clearer in these=20 > requirements, and in the security analysis section (i.e., Section 5). >=20 > 3. Requirements R23, R24, R25 are inappropriate for this=20 > document, in that they conflict directly with the security=20 > requirements (R1, R2, R17). A well-designed key-exchange=20 > protocol *should* be able to detect a middle-man, authorized=20 > or not. Lawful intercept should be handled outside of the=20 > key management protocol, as in draft-wing-sipping-srtp-key. >=20 > 4. This document needs several more terms defined in the Terminology.=20 > The three I spotted were: "media path", "signaling path", and=20 > "perfect forward secrecy". PFS is already defined in the=20 > requirements; this text should just be moved to the=20 > Terminology section. >=20 > 5. If we intend this document to move quickly toward RFC=20 > status, it seems like the evaluation appendices will have to=20 > be deleted, or at least the parts of them that refer to=20 > protocols that are not RFCs or not on their way. >=20 > 6. Section 3.1 and 3.3 do not appear to be directly related=20 > to the requirements as stated. They should be moved to=20 > sections B.2 and B.3, respectively (like the text on SSRCs and ROCs). >=20 > 7. Sections C.1 and C.3 should be deleted. Section C.1. is=20 > predicated on the notion that protocols require a PKI to be=20 > used, when in reality (as was discussed extensively on=20 > rtpsec), any protocol that can be used with a PKI can be used=20 > with self-signed certificates if both endpoints are willing. =20 > Section C.3. tries to evaluate whether solutions can do=20 > best-effort security, while ignoring the work that has been=20 > done on SDP capability negotiation. >=20 > *. (nit) Throughout, the word "keying" is used to mean the=20 > process of key negotiation/exchange or key management. It=20 > should be replaced by those terms as appropriate. >=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=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 11 10:29:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifyyh-0002aC-6A; Thu, 11 Oct 2007 10:25:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifyyf-0002Sm-Hk for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifyyf-0002Pv-6U for sip@ietf.org; Thu, 11 Oct 2007 10:25:29 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifyyd-0003ew-S1 for sip@ietf.org; Thu, 11 Oct 2007 10:25:29 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9BEPBov072961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Oct 2007 09:25:11 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <917DDE53-CCBF-44F5-A77A-D3EE702CF083@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Thu, 11 Oct 2007 09:25:01 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] SIPit 21 is 3 weeks away 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: , Errors-To: sip-bounces@ietf.org SIPit 21 starts 3 weeks from Monday (on November 5). Registration closes in just over two weeks (October 29). If you're planning to attend, but have not yet registered, please take a moment to do so now. Be sure to acquire the visa you will need to enter China and take care of any shipping you need to do for the event immediately. More information about the event is available at www.sipit.net. Instructions for shipping can be found at http://www.sipit21.org/ inform.html RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 11 10:29:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz1z-0001H8-10; Thu, 11 Oct 2007 10:28:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ifz1y-0001Go-0D for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:28:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz1x-0001GU-Jo for sip@ietf.org; Thu, 11 Oct 2007 10:28:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifz1w-0006Jn-Hp for sip@ietf.org; Thu, 11 Oct 2007 10:28:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,260,1188802800"; d="scan'208";a="234796920" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2007 07:28:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9BESq3j004421; Thu, 11 Oct 2007 07:28:52 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9BESOlT013667; Thu, 11 Oct 2007 14:28:51 GMT 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.1830); Thu, 11 Oct 2007 10:28:37 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 10:28:37 -0400 Message-ID: <470E3318.20309@cisco.com> Date: Thu, 11 Oct 2007 10:28:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] IETF solution for pairing cellular hosts References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <200709272138.l8RLcBLC028711@dragon.ariadne.com> <18a603a60709280417x75a7e937y55254def4491496a@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <470BAAD4.8030003@cisco.com> In-Reply-To: <470BAAD4.8030003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2007 14:28:37.0152 (UTC) FILETIME=[02D58A00:01C80C13] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15476.002 X-TM-AS-Result: No--18.242400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7415; t=1192112932; x=1192976932; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20IETF=20solution=20for=20pairing=20cellular=20 hosts |Sender:=20; bh=YvLfPjucwhxyVMfKkRgPDHPqNcljqGQdB42986tNvTo=; b=koam7gtQX8gs8PfyyvoXdHYa6CPl5LQBx8JNjJ/XQys+ORjrDRY5p97idwtAa0ZoK9t/I1lO xViDowCDIsXu4Wm6eco6hDCxNMDaAaewBMLiKRQ1k4lPeN2JJ9CBJkb7kP+BPO5sCWd+1IS57o EJLuROVITla/xI056CuAmS0vA=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: sip@ietf.org, "Joel M. Halpern" 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: , Errors-To: sip-bounces@ietf.org Elaborating on my earlier reply... I question whether what you are trying to achieve even makes sense to attempt, at least in the form you have framed the problem. And I sense the same feeling from some of the other people, though that is only my impression. Increasingly, people have multiple identifier (pseudonyms?) that they are known by in various contexts. Some of these are unique, in that there is a well defined relationship between the identifier and a specific human being. In other cases the relationship between the identifier and a human is non-unique, and other information must be used to resolve the ambiguity. Person names are of the non-unique form. URIs used for various forms of communication, including SIP and TEL, are often unique. Just as it is increasingly common for people to use multiple identities, it is often the case that they don't desire the association between one of these identities and their person or other identities to be known. However this isn't always the case. Sometimes the distinct identifiers are simply an artifact of technology, and associations between them are willingly exposed. (E.g. on some online forums I use a pseudonym. The operator of the list knows the mapping to my email address and name, but this kept private. I may choose to include my name, email address, or phone number in a message on this forum - exposing the relationship - or I may carefully refrain from doing so.) I think you have two problems to solve here, and they probably need different solutions: 1) mapping from an ambiguous identifier for a person to an unambiguous identifier. 2) given one unambiguous identifier, obtain a different unambiguous identifier which enables a particular form of communication. For (1) I think the best you can expect to do is have some kind of voluntary registry (roughly akin to the phone book) that lists the names of people and whatever information they choose to make public that might help disambiguate them from other people, and then a corresponding unambiguous identifier. There doesn't have to be just one such registry. Google does an admirable job of federating many sources of such information. For (2) the solution is straightforward if the association between the identify you have and the one you want is public. If it is not public, then you must make a request and have it granted. If the identifier you have enables a communication path where you can make a query then the solution is straightforward - you just ask. If the identifier you have (say a Social Security number) doesn't enable communication, then you must delegate your request to some entity that knows the mapping you desire, and the policy for determining whether to grant it to you. (This could involve communicating with the target.) What seem like a bad idea to me is trying to combine (1) and (2) when you don't have enough information to disambiguate. And IIUC that is what you are proposing - to have an agent that knows the mapping from names to phone numbers make queries to all people with matching names. IMO there will be widespread objection to that, even if requests are restricted to those requesters who have solved a CAPCHA. Paul Paul Kyzivat wrote: > > > Pars Mutaf wrote: >> >> >> On 10/9/07, *Joel M. Halpern* > > wrote: >> >> At 08:58 AM 10/9/2007, you wrote: >> >Where did you get this information. It is private. >> >> Presumably, the "this" refers to the SIP URI. >> If you don't have the SIP URI, what string do you think you >> have? Human names are utterly useless for this, due to collision, >> misspelling, and many other problems. >> >> >> To my knowledge, phonebook users never complained about that. > > Phone books worked reasonably well in a different age. And they depended > on people being willing to advertise certain context information to the > public at large: their phone number and an address. I think today that > people are not so willing to disclose that information publicly. > > Today we often want to talk to people whose addresses we often don't > know. Instead we may know their email address, or an IM address, etc. > And those things are at least unique. > > So there are two problems here: > - trying to find a unique address for someone given only > some human name you have for them, and to disambiguate > them from all the other people with similar names based > on whatever information they might be willing to disclose > to a random stranger. > > - given some unique address that is known to be associated > with a given individual, find a different address for the > same individual that is usable for some desired form of > communication. > > The latter is probably a much more solvable problem. > >> The real problem of the phonebook, today, is the privacy >> problem. An extension is needed for interactive user >> permissions as stated by Adam Roach. >> >> A note about name collisions: >> >> Similarly to a traditional phonebook user, if you are looking >> for a certain John Smith, hopefully you will have some >> additional information helping filter the results. >> >> (in the proposed extension, the target cell phone may return >> such information, e.g. company name, street address, etc.) > > I'm not likely to have my phone return that sort of information to > unknown requestors. I don't know who would. > >> Note also that if anyone can send you a resolution request, that is >> roughly equivalent, in terms of intrusiveness, to anyone causing your >> phone to ring. >> >> >> The proposal is rather as follows (abstract): >> >> You solve to a challenge (e.g. a CAPTCHA) to obtain the target >> phone number. >> Then, you can make a call, send a message etc. > > Really! Maybe you are willing to give your information out to anyone who > can solve a CAPTCHA, but I'm not. > > Note that in Adam's example you might be sending this request to dozens, > hundreds, or more of targets that you are not interested in, and who are > presumably not interested in you either. Then you are going to solve a > capcha from each one enroute to finding the right one? And they are > going to go along with this? > > Paul > >> Thanks, >> pars >> >> >> Alternatively, if you want a challenge / response on the resolution >> request, you can give a challenge / response on the SIP request. >> >> Yours, >> Joel >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 11 13:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Kg-0007xf-E9; Thu, 11 Oct 2007 12:56:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig1Kf-0007xY-Im for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 12:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Kf-0007sh-8e for sip@ietf.org; Thu, 11 Oct 2007 12:56:21 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig1KT-0002rE-2y for sip@ietf.org; Thu, 11 Oct 2007 12:56:15 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9BGtPd25828; Thu, 11 Oct 2007 16:55:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 11 Oct 2007 11:55:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> In-Reply-To: <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgLvgjMC66ej2saQpWIz0LomUP4iQAaQKHQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Hi Dean, Can you tell me what is the difference between "contextually-adapted INFO", and a "subscription embedded in the INVITE, with the NOTIFY using the same dialog"? I don't see any advantage to the INFO approach. It seems to me we already have a mechanism for asking for asynchroous information with subscriptions. Why not use that? > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, October 10, 2007 21:20 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > On Oct 10, 2007, at 6:14 PM, Francois Audet wrote: >=20 > > > >> (d) they think it's a waste of resources to establish multiple=20 > >> additional subscription dialogs (there may be other type=20 > of data than=20 > >> DTMF they are willing to receive) which in many cases may=20 > not even be=20 > >> used during the call (it can not be assumed that the one=20 > sending the=20 > >> subscription always knows exactly when it will receive=20 > events). Maybe=20 > >> DTMF is not the best example in the world (my fault - I=20 > should have=20 > >> been more generic), but I am sure there could be events=20 > which would=20 > >> not be used in a very high percentage of all calls, but still the=20 > >> additional subscription dialog(s) would have to be=20 > established - just=20 > >> in case. > > > > Maybe a way to subscribe to packages within an INVITE=20 > dialog would be=20 > > suitable. You then would get the NOTIFYs withind the=20 > dialog, and they=20 > > wouldn't be out-of-the-blue because you would have=20 > subscribed to those=20 > > events explicitly with some Allow-Event in the INVITE. > > >=20 > Hmm. In-dialog event notification using INVITE as an explicit=20 > subscription trigger. That works, mostly. >=20 > Other people would argue that the semantics are better=20 > preserved with a a new SIP method that is defined to carry=20 > whatever sort of blob we're talking about in the specific=20 > context of the application usage. =20 > We'd then add that method name to the list of supported=20 > methods given in the Allow header field. Of course, this will=20 > eventually give us "Really Big" Allow header fields, which=20 > means the negotiation mechanism is broken. We need an easier=20 > way for one end to ask "Hey, do you understand this?". >=20 > Others would say that the we're better off defining a session=20 > protocol designed to transport the blobs in question, along=20 > with SDP extensions to negotiate this protocol, NAT-traversal=20 > hooks to allow us to talk about the connectivity of the=20 > blob-transferral protocol, then do a reINVITE exchange to add=20 > the new blob-session to the existing session. >=20 > Yet others would say that we already have a blob-transferral=20 > protocol (MSRP), along with the nat traversal hooks and SDP=20 > extensions needed to negotiate it, and should therefore push=20 > the problem out one layer of protocol and make it an MSRP=20 > problem. This begs the question of how MSRP negotiates as to=20 > whether the context and content are agreed on both ends,=20 > which AFAIK it does little better at than INFO. >=20 >=20 > So what's the difference? >=20 > All (assuming we figure out the MSRP context negotiation=20 > problem) explicitly declare the understanding of and the=20 > desire to receive messages within this dialog/session that=20 > contain the data we've defined and assure that the=20 > application context (the "what do I do with this stuff"=20 > problem) is mutually understood. >=20 > The differences are that one approach is the extension of an=20 > application protocol to support a new application, while two=20 > others are extensions of existing transport protocols (SIP,=20 > MSRP) to carry new payloads in contexts determined by the=20 > applications. The last one implies the development of an=20 > all-new transport protocol (or perhaps the modification of=20 > some other protocol like RTP) as well as extension to our=20 > descriptive protocol (SDP). These are very different things,=20 > and part of the reason that SIP has gotten more complex than=20 > I would like is that we haven't been operating with a clear=20 > understanding of these differences. >=20 > Personally, I think that we've got a lot of complexity there=20 > that we didn't really need. If SIP had been designed from the=20 > ground-up as a transport protocol for arbitrary messages and=20 > the application were a function of the message content, we'd=20 > have a much clearer model of what to do. But it wasn't built=20 > that way, so now we need some guiding principles on when each=20 > sort of approach is appropriate. Without it, we're just going=20 > to go around in circles on the "Is INFO harmful, and if so=20 > why?" carousel. >=20 > Since I can't leave it hanging there, I'd like to propose=20 > some rules of thumb: >=20 > 1) If INFO had context negotiation, we'd have a complete=20 > protocol and would quite possibly only need new SIP method=20 > types if there was a need for a fundamental change to the SIP=20 > state machine. Even without INFO, we have the same=20 > functionality available, albeit at the overhead of an=20 > additional dialog. So, I suggest we only introduce new SIP=20 > methods if there's a need to change the underlying machine.=20 > If we're just moving new data in application contexts, we can=20 > do that without changing SIP itself. I really don't want to=20 > keep the SIP WG around just so we can specify a new SIP=20 > method for each application somebody dreams up. >=20 > 2) Since SIP can provide for the transport of arbitrary data=20 > and application context, we should only use "session"=20 > transport of the data when that dataflow itself has=20 > fundamentally different characteristics -- essentially, when=20 > it is a long-lived and relatively continues flow, aka a=20 > "stream". Quite possibly, this should extend to only=20 > dataflows that have the properties of RTP -- time sensitive,=20 > relatively loss insensitive, and so bulky we need them to be=20 > as end-to-end as we can even if it means building more=20 > infrastructure to make that happen. And yes, I think MSRP is=20 > a misguided effort -- by the time we've built MSRP relays and=20 > all the extra cruft, we've duplicated SIP's message proxy=20 > operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm=20 > not even sure that this level of separation is a good idea.=20 > Coaxial signaling and media have great advantages for=20 > firewall traversal. But we have what we have. In short, use=20 > RTP/MSRP for "sessions", and SIP event payloads (or=20 > contextually-adapted INFO) for everything else. >=20 > 3) There is no rule 3. >=20 > -- > Dean >=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 11 13:07:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1UG-0005WK-Gz; Thu, 11 Oct 2007 13:06:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig1UE-0005W1-OY for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1UE-0005Vt-Dg for sip@ietf.org; Thu, 11 Oct 2007 13:06:14 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig1U8-0003MV-09 for sip@ietf.org; Thu, 11 Oct 2007 13:06:14 -0400 Received: by wx-out-0506.google.com with SMTP id s8so578789wxc for ; Thu, 11 Oct 2007 10:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=I28PIfUebgFuToZe+Z43us2+09iACKAyxzVJoOXgvIY=; b=qNxcW6CwjXOhko5e9BuybpDWsMGCxCWOzB5248yiqSDCjhPxNhoyGTS6f4ZynoRSBHQoFO/uQmX5swaT5hRccqsNBEZU5k86eoeiC/WALU7cvyB0rlS5BNstl1w/QsH67XEYwJmHOVv2xpza40UjCPrz61qfYRK1REqb9aCQLc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dRu684Om+P106aTYM1+VgM1wOBX1WOYI/7yYqokAk5OQJ+o/38Sym4QhTwX31na5ueThinFABLuh3f3Ih7LZnr23Kkhwp3ROPwSW5G5FyQlej3xNchSQV55WjeRwhYY5OremTA87A6BNW8nMi1bCzLO3nHzbmjOYoleRjZ3IH3g= Received: by 10.70.32.2 with SMTP id f2mr3532298wxf.1192122352456; Thu, 11 Oct 2007 10:05:52 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Thu, 11 Oct 2007 10:05:52 -0700 (PDT) Message-ID: <18a603a60710111005q4faa56fuc6191e70fe8296eb@mail.gmail.com> Date: Thu, 11 Oct 2007 19:05:52 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470E3318.20309@cisco.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <470BAAD4.8030003@cisco.com> <470E3318.20309@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 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: , Content-Type: multipart/mixed; boundary="===============0412234525==" Errors-To: sip-bounces@ietf.org --===============0412234525== Content-Type: multipart/alternative; boundary="----=_Part_17345_19801763.1192122352447" ------=_Part_17345_19801763.1192122352447 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/11/07, Paul Kyzivat wrote: > > Elaborating on my earlier reply... > > I question whether what you are trying to achieve even makes sense to > attempt, at least in the form you have framed the problem. And I sense > the same feeling from some of the other people, though that is only my > impression. > > Increasingly, people have multiple identifier (pseudonyms?) that they > are known by in various contexts. Some of these are unique, in that > there is a well defined relationship between the identifier and a > specific human being. In other cases the relationship between the > identifier and a human is non-unique, and other information must be used > to resolve the ambiguity. Person names are of the non-unique form. URIs > used for various forms of communication, including SIP and TEL, are > often unique. > > Just as it is increasingly common for people to use multiple identities, > it is often the case that they don't desire the association between one > of these identities and their person or other identities to be known. > However this isn't always the case. Sometimes the distinct identifiers > are simply an artifact of technology, and associations between them are > willingly exposed. > > (E.g. on some online forums I use a pseudonym. The operator of the list > knows the mapping to my email address and name, but this kept private. I > may choose to include my name, email address, or phone number in a > message on this forum - exposing the relationship - or I may carefully > refrain from doing so.) > > I think you have two problems to solve here, and they probably need > different solutions: > > 1) mapping from an ambiguous identifier for a person to an unambiguous > identifier. > > 2) given one unambiguous identifier, obtain a different unambiguous > identifier which enables a particular form of communication. > > For (1) I think the best you can expect to do is have some kind of > voluntary registry (roughly akin to the phone book) that lists the names > of people and whatever information they choose to make public that might > help disambiguate them from other people, and then a corresponding > unambiguous identifier. There doesn't have to be just one such registry. > Google does an admirable job of federating many sources of such > information. > > For (2) the solution is straightforward if the association between the > identify you have and the one you want is public. If it is not public, > then you must make a request and have it granted. If the identifier you > have enables a communication path where you can make a query then the > solution is straightforward - you just ask. If the identifier you have > (say a Social Security number) doesn't enable communication, then you > must delegate your request to some entity that knows the mapping you > desire, and the policy for determining whether to grant it to you. (This > could involve communicating with the target.) Thanks for your input. I respect your requirements. I still hope we can talk more in detail. Can we add more levels to these privacy requirements? We can assume that young users (living mostly in a cyberspace :-) know each other's pseudonyms for example? Or, I can tell you my pseudonym when we meet (and use this info for easily pairing our phones). If later you lose contact(*) you can re-initiate pairing if you remember the pseudonym. *: your phone has lost state, or you have new phone, or I changed my phone number etc. I mean the association between human name and pseudonym may not be necessarily made public. What seem like a bad idea to me is trying to combine (1) and (2) when > you don't have enough information to disambiguate. And IIUC that is what > you are proposing - to have an agent that knows the mapping from names > to phone numbers make queries to all people with matching names. IMO > there will be widespread objection to that, even if requests are > restricted to those requesters who have solved a CAPCHA. I respect your objections, but this is also an approach for another type of user IMHO. If I desperately need to talk and I have 10 candidate target users (with the same name), then I can call all of them one by one, until I find the person. Note also that, when we talk about name collisions, we should talk about a "double name collision". The querier's name appears on the target phone's screen. So, if the target user doesn't know me they will probably reject my request. Hoping that my friend didn't reject my query I can try the next one. If there are 100 candidate users, this is bad luck. But the service still works for millions of others. Thanks, pars PS: Without comment, hoping that this would give some ideas: http://www.intelius.com/phone-search-name.html Paul > > Paul Kyzivat wrote: > > > > > > Pars Mutaf wrote: > >> > >> > >> On 10/9/07, *Joel M. Halpern* >> > wrote: > >> > >> At 08:58 AM 10/9/2007, you wrote: > >> >Where did you get this information. It is private. > >> > >> Presumably, the "this" refers to the SIP URI. > >> If you don't have the SIP URI, what string do you think you > >> have? Human names are utterly useless for this, due to collision, > >> misspelling, and many other problems. > >> > >> > >> To my knowledge, phonebook users never complained about that. > > > > Phone books worked reasonably well in a different age. And they depended > > > on people being willing to advertise certain context information to the > > public at large: their phone number and an address. I think today that > > people are not so willing to disclose that information publicly. > > > > Today we often want to talk to people whose addresses we often don't > > know. Instead we may know their email address, or an IM address, etc. > > And those things are at least unique. > > > > So there are two problems here: > > - trying to find a unique address for someone given only > > some human name you have for them, and to disambiguate > > them from all the other people with similar names based > > on whatever information they might be willing to disclose > > to a random stranger. > > > > - given some unique address that is known to be associated > > with a given individual, find a different address for the > > same individual that is usable for some desired form of > > communication. > > > > The latter is probably a much more solvable problem. > > > >> The real problem of the phonebook, today, is the privacy > >> problem. An extension is needed for interactive user > >> permissions as stated by Adam Roach. > >> > >> A note about name collisions: > >> > >> Similarly to a traditional phonebook user, if you are looking > >> for a certain John Smith, hopefully you will have some > >> additional information helping filter the results. > >> > >> (in the proposed extension, the target cell phone may return > >> such information, e.g. company name, street address, etc.) > > > > I'm not likely to have my phone return that sort of information to > > unknown requestors. I don't know who would. > > > >> Note also that if anyone can send you a resolution request, that is > > >> roughly equivalent, in terms of intrusiveness, to anyone causing > your > >> phone to ring. > >> > >> > >> The proposal is rather as follows (abstract): > >> > >> You solve to a challenge ( e.g. a CAPTCHA) to obtain the target > >> phone number. > >> Then, you can make a call, send a message etc. > > > > Really! Maybe you are willing to give your information out to anyone who > > can solve a CAPTCHA, but I'm not. > > > > Note that in Adam's example you might be sending this request to dozens, > > hundreds, or more of targets that you are not interested in, and who are > > presumably not interested in you either. Then you are going to solve a > > capcha from each one enroute to finding the right one? And they are > > going to go along with this? > > > > Paul > > > >> Thanks, > >> pars > >> > >> > >> Alternatively, if you want a challenge / response on the resolution > > >> request, you can give a challenge / response on the SIP request. > >> > >> Yours, > >> Joel > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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_17345_19801763.1192122352447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/11/07, Paul Kyzivat <pkyzivat@cisco.com > wrote:
Elaborating on my earlier reply...

I question whether what you are trying to achieve even makes sense to
attempt, at least in the form you have framed the problem. And I sense
the same feeling from some of the other people, though that is only my
impression.

Increasingly, people have multiple identifier (pseudonyms?) that they
are known by in various contexts. Some of these are unique, in that
there is a well defined relationship between the identifier and a
specific human being. In other cases the relationship between the
identifier and a human is non-unique, and other information must be used
to resolve the ambiguity. Person names are of the non-unique form. URIs
used for various forms of communication, including SIP and TEL, are
often unique.

Just as it is increasingly common for people to use multiple identities,
it is often the case that they don't desire the association between one
of these identities and their person or other identities to be known.
However this isn't always the case. Sometimes the distinct identifiers
are simply an artifact of technology, and associations between them are
willingly exposed.

(E.g. on some online forums I use a pseudonym. The operator of the list
knows the mapping to my email address and name, but this kept private. I
may choose to include my name, email address, or phone number in a
message on this forum - exposing the relationship - or I may carefully
refrain from doing so.)

I think you have two problems to solve here, and they probably need
different solutions:

1) mapping from an ambiguous identifier for a person to an unambiguous
identifier.

2) given one unambiguous identifier, obtain a different unambiguous
identifier which enables a particular form of communication.

For (1) I think the best you can expect to do is have some kind of
voluntary registry (roughly akin to the phone book) that lists the names
of people and whatever information they choose to make public that might
help disambiguate them from other people, and then a corresponding
unambiguous identifier. There doesn't have to be just one such registry.
Google does an admirable job of federating many sources of such information.

For (2) the solution is straightforward if the association between the
identify you have and the one you want is public. If it is not public,
then you must make a request and have it granted. If the identifier you
have enables a communication path where you can make a query then the
solution is straightforward - you just ask. If the identifier you have
(say a Social Security number) doesn't enable communication, then you
must delegate your request to some entity that knows the mapping you
desire, and the policy for determining whether to grant it to you. (This
could involve communicating with the target.)


Thanks for your input. I respect your requirements.
I still hope we can talk more in detail.

Can we add more levels to these privacy requirements?

We can assume that young users (living mostly in a cyberspace :-)
know each other's pseudonyms for example?

Or, I can tell you my pseudonym when we meet (and use this
info for easily pairing our phones). If later you lose contact(*)
you can re-initiate pairing if you remember the pseudonym.

*: your phone has lost state, or you have new phone,
   or I changed my phone number etc.


I mean the association between human name and pseudonym
may not be necessarily made public.



What seem like a bad idea to me is trying to combine (1) and (2) when
you don't have enough information to disambiguate. And IIUC that is what
you are proposing - to have an agent that knows the mapping from names
to phone numbers make queries to all people with matching names.

IMO
there will be widespread objection to that, even if requests are
restricted to those requesters who have solved a CAPCHA.

I respect your objections, but this is also an approach
for another type of user IMHO.

If I desperately need to talk and I have 10 candidate target users
(with the same name), then I can call all of them one by one, until
I find the person. Note also that, when we talk about name collisions,
we should talk about a "double name collision". The querier's name
appears on the target phone's screen. So, if the target user doesn't
know me they will probably reject my request. Hoping that my
friend didn't reject my query I can try the next one.

If there are 100 candidate users, this is bad luck. But the service
still works for millions of others.

Thanks,
pars

PS: Without comment, hoping that this would give some ideas:
http://www.intelius.com/phone-search-name.html



        Paul

Paul Kyzivat wrote:
>
>
> Pars Mutaf wrote:
>>
>>
>> On 10/9/07, *Joel M. Halpern* <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>> wrote:
>>
>>     At 08:58 AM 10/9/2007, you wrote:
>>      >Where did you get this information. It is private.
>>
>>     Presumably, the "this" refers to the SIP URI.
>>     If you don't have the SIP URI, what string do you think you
>>     have?  Human names are utterly useless for this, due to collision,
>>     misspelling, and many other problems.
>>
>>
>> To my knowledge, phonebook users never complained about that.
>
> Phone books worked reasonably well in a different age. And they depended
> on people being willing to advertise certain context information to the
> public at large: their phone number and an address. I think today that
> people are not so willing to disclose that information publicly.
>
> Today we often want to talk to people whose addresses we often don't
> know. Instead we may know their email address, or an IM address, etc.
> And those things are at least unique.
>
> So there are two problems here:
> - trying to find a unique address for someone given only
>   some human name you have for them, and to disambiguate
>   them from all the other people with similar names based
>   on whatever information they might be willing to disclose
>   to a random stranger.
>
> - given some unique address that is known to be associated
>   with a given individual, find a different address for the
>   same individual that is usable for some desired form of
>   communication.
>
> The latter is probably a much more solvable problem.
>
>> The real problem of the phonebook, today, is the privacy
>> problem. An extension is needed for interactive user
>> permissions as stated by Adam Roach.
>>
>> A note about name collisions:
>>
>> Similarly to a traditional phonebook user, if you are looking
>> for a certain John Smith, hopefully you will have some
>> additional information helping filter the results.
>>
>> (in the proposed extension, the target cell phone may return
>> such information, e.g. company name, street address, etc.)
>
> I'm not likely to have my phone return that sort of information to
> unknown requestors. I don't know who would.
>
>>     Note also that if anyone can send you a resolution request, that is
>>     roughly equivalent, in terms of intrusiveness, to anyone causing your
>>     phone to ring.
>>
>>
>> The proposal is rather as follows (abstract):
>>
>> You solve to a challenge ( e.g. a CAPTCHA) to obtain the target
>> phone number.
>> Then, you can make a call, send a message etc.
>
> Really! Maybe you are willing to give your information out to anyone who
> can solve a CAPTCHA, but I'm not.
>
> Note that in Adam's example you might be sending this request to dozens,
> hundreds, or more of targets that you are not interested in, and who are
> presumably not interested in you either. Then you are going to solve a
> capcha from each one enroute to finding the right one? And they are
> going to go along with this?
>
>     Paul
>
>> Thanks,
>> pars
>>
>>
>>     Alternatively, if you want a challenge / response on the resolution
>>     request, you can give a challenge / response on the SIP request.
>>
>>     Yours,
>>     Joel
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_17345_19801763.1192122352447-- --===============0412234525== 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 --===============0412234525==-- From sip-bounces@ietf.org Thu Oct 11 15:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3lo-0004dx-K8; Thu, 11 Oct 2007 15:32:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig3ln-0004YD-3x for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 15:32:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3lm-0004BN-Fn for sip@ietf.org; Thu, 11 Oct 2007 15:32:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig3lZ-0006Wv-RK for sip@ietf.org; Thu, 11 Oct 2007 15:32:18 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9BJW5R4027092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Oct 2007 14:32:07 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 11 Oct 2007 14:31:59 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List , Christer Holmberg Subject: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) 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: , Errors-To: sip-bounces@ietf.org On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: > Hi Dean, > > Can you tell me what is the difference between "contextually-adapted > INFO", and a "subscription embedded in the INVITE, with the NOTIFY > using the same dialog"? I don't see any advantage to the INFO > approach. > One might argue that the second is a means of implementing the first. INFO, as written, lacks contextual negotiation. You're proposing to replace the method name with NOTIFY and use the event-package framework for content and context expression, using a header-field in the INVITE request to engage context negotiation. It seems to me like that would work. There's nothing "implicit" about it, and it is no worse for overhead than using Supported or Allow. It also has the advantage of letting us reuse an existing registration framework, IANA process, and specification review process under RFC 3427. Very tidy, I think I like it. I would argue that it would be nice to have an extension mechanism that allows a UA to be asked "Do you support this specific extension?" without the UA having to encode every extension it supports in every request it sends, but that's a different issue. > It seems to me we already have a mechanism for asking for asynchroous > information with subscriptions. Why not use that? > As you pointed out, the current mechanism adds a dialog overhead. It also raises issues with event-stream correlation that can be a bit of a challenge depending on the application's API and threading model. Your suggested workaround for in-dialog notification relieves these issues, so it may be better than the existing mechanism for a number of use cases. More importantly, it is no worse than NOTIFY for those use cases (barring the small increase in request size for context negotiation). -- 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 11 15:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig44Q-0005Qg-QS; Thu, 11 Oct 2007 15:51:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig44Q-0005QV-0A for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 15:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig44P-0005QN-Mn for sip@ietf.org; Thu, 11 Oct 2007 15:51:45 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig44K-0002Ez-H8 for sip@ietf.org; Thu, 11 Oct 2007 15:51:45 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9BJpPU15119; Thu, 11 Oct 2007 19:51:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 14:51:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12700BA3@zrc2hxm0.corp.nortel.com> In-Reply-To: <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) thread-index: AcgMPXF0+T3qB/6PSpGj+tw0+TvT4gAAnhsA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! ! ! < 8F6 5 D B 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF SIP List , Christer Holmberg Subject: [Sip] RE: Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) 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: , Errors-To: sip-bounces@ietf.org Looks like we are in agreement. Your paraphrasing of my proposal is accurate. Let's wait for other opinions.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, October 11, 2007 12:32 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; IETF SIP List > Subject: Francois' counter to INFO (was Re: What are we=20 > arguing about when we say INFO?) >=20 >=20 > On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: >=20 > > Hi Dean, > > > > Can you tell me what is the difference between=20 > "contextually-adapted=20 > > INFO", and a "subscription embedded in the INVITE, with the NOTIFY=20 > > using the same dialog"? I don't see any advantage to the INFO=20 > > approach. > > >=20 > One might argue that the second is a means of implementing the first. >=20 > INFO, as written, lacks contextual negotiation. You're=20 > proposing to replace the method name with NOTIFY and use the=20 > event-package framework for content and context expression,=20 > using a header-field in the INVITE request to engage context=20 > negotiation. It seems to me like that would work. There's=20 > nothing "implicit" about it, and it is no worse for overhead=20 > than using Supported or Allow. It also has the advantage of=20 > letting us reuse an existing registration framework, IANA=20 > process, and specification review process under RFC 3427.=20 > Very tidy, I think I like it. >=20 > I would argue that it would be nice to have an extension=20 > mechanism that allows a UA to be asked "Do you support this=20 > specific extension?" without the UA having to encode every=20 > extension it supports in every request it sends, but that's a=20 > different issue. >=20 >=20 > > It seems to me we already have a mechanism for asking for=20 > asynchroous=20 > > information with subscriptions. Why not use that? > > >=20 > As you pointed out, the current mechanism adds a dialog=20 > overhead. It also raises issues with event-stream correlation=20 > that can be a bit of a challenge depending on the=20 > application's API and threading model. =20 > Your suggested workaround for in-dialog notification relieves=20 > these issues, so it may be better than the existing mechanism=20 > for a number of use cases. More importantly, it is no worse=20 > than NOTIFY for those use cases (barring the small increase=20 > in request size for context negotiation). >=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 Thu Oct 11 18:24:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6ME-0004aD-Ax; Thu, 11 Oct 2007 18:18:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig6MC-0004a5-VP for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 18:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6MC-0004Zu-Ki for sip@ietf.org; Thu, 11 Oct 2007 18:18:16 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig6M4-00087y-4k for sip@ietf.org; Thu, 11 Oct 2007 18:18:14 -0400 Received: (qmail 26205 invoked by uid 0); 11 Oct 2007 22:18:57 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Oct 2007 22:18:57 -0000 Message-ID: <470EA105.3030202@zonnet.nl> Date: Fri, 12 Oct 2007 00:17:41 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Audet Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: IETF SIP List , Christer Holmberg , 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: , Errors-To: sip-bounces@ietf.org Francois, "Why not use that?" is the wrong question. It should be "Why do THEY (the people out there) use or don't use { KPML, INFO, RFC2833, , ... }" It is not up to us - the people participating in these IETF mailinglists - to decide what gets used. We simply don't have any say in that. In my limited perception of the world, people use INFO because it's better known by them, supported by some devices, simpler to use, and low overhead - you don't pay a performance penalty unless a key press (for example) actually happens, which in some cases is rare (like for certain telephony applications). People tend to think along the lines of "it's defined in an RFC, therefore standard, seems supported by others (at least by the list of devices on my mandatory interop list) -> ok to use" and then add an item to their "supported standards" list on the product data sheet "We" can argue that it's wrong to use INFO, that it's lacking contextually-adapted negotiations mechanisms, etc. but the reaction will simply be: "What are you talking about, contextual bla-bla, it's working fine for US and our purposes". Pandorra's box that is INFO has been opened. It's out there, and there's no stopping it. Let's go solve some real issues now Regards, Jeroen Francois Audet wrote: > Hi Dean, > > Can you tell me what is the difference between "contextually-adapted > INFO", and a "subscription embedded in the INVITE, with the NOTIFY > using the same dialog"? I don't see any advantage to the INFO approach. > > It seems to me we already have a mechanism for asking for asynchroous > information with subscriptions. Why not use that? > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, October 10, 2007 21:20 >> To: Audet, Francois (SC100:3055) >> Cc: Christer Holmberg; IETF SIP List >> Subject: Re: What are we arguing about when we say INFO? (was >> Re: [Sip] INFO) >> >> >> On Oct 10, 2007, at 6:14 PM, Francois Audet wrote: >> >> >>>> (d) they think it's a waste of resources to establish multiple >>>> additional subscription dialogs (there may be other type >>>> >> of data than >> >>>> DTMF they are willing to receive) which in many cases may >>>> >> not even be >> >>>> used during the call (it can not be assumed that the one >>>> >> sending the >> >>>> subscription always knows exactly when it will receive >>>> >> events). Maybe >> >>>> DTMF is not the best example in the world (my fault - I >>>> >> should have >> >>>> been more generic), but I am sure there could be events >>>> >> which would >> >>>> not be used in a very high percentage of all calls, but still the >>>> additional subscription dialog(s) would have to be >>>> >> established - just >> >>>> in case. >>>> >>> Maybe a way to subscribe to packages within an INVITE >>> >> dialog would be >> >>> suitable. You then would get the NOTIFYs withind the >>> >> dialog, and they >> >>> wouldn't be out-of-the-blue because you would have >>> >> subscribed to those >> >>> events explicitly with some Allow-Event in the INVITE. >>> >>> >> Hmm. In-dialog event notification using INVITE as an explicit >> subscription trigger. That works, mostly. >> >> Other people would argue that the semantics are better >> preserved with a a new SIP method that is defined to carry >> whatever sort of blob we're talking about in the specific >> context of the application usage. >> We'd then add that method name to the list of supported >> methods given in the Allow header field. Of course, this will >> eventually give us "Really Big" Allow header fields, which >> means the negotiation mechanism is broken. We need an easier >> way for one end to ask "Hey, do you understand this?". >> >> Others would say that the we're better off defining a session >> protocol designed to transport the blobs in question, along >> with SDP extensions to negotiate this protocol, NAT-traversal >> hooks to allow us to talk about the connectivity of the >> blob-transferral protocol, then do a reINVITE exchange to add >> the new blob-session to the existing session. >> >> Yet others would say that we already have a blob-transferral >> protocol (MSRP), along with the nat traversal hooks and SDP >> extensions needed to negotiate it, and should therefore push >> the problem out one layer of protocol and make it an MSRP >> problem. This begs the question of how MSRP negotiates as to >> whether the context and content are agreed on both ends, >> which AFAIK it does little better at than INFO. >> >> >> So what's the difference? >> >> All (assuming we figure out the MSRP context negotiation >> problem) explicitly declare the understanding of and the >> desire to receive messages within this dialog/session that >> contain the data we've defined and assure that the >> application context (the "what do I do with this stuff" >> problem) is mutually understood. >> >> The differences are that one approach is the extension of an >> application protocol to support a new application, while two >> others are extensions of existing transport protocols (SIP, >> MSRP) to carry new payloads in contexts determined by the >> applications. The last one implies the development of an >> all-new transport protocol (or perhaps the modification of >> some other protocol like RTP) as well as extension to our >> descriptive protocol (SDP). These are very different things, >> and part of the reason that SIP has gotten more complex than >> I would like is that we haven't been operating with a clear >> understanding of these differences. >> >> Personally, I think that we've got a lot of complexity there >> that we didn't really need. If SIP had been designed from the >> ground-up as a transport protocol for arbitrary messages and >> the application were a function of the message content, we'd >> have a much clearer model of what to do. But it wasn't built >> that way, so now we need some guiding principles on when each >> sort of approach is appropriate. Without it, we're just going >> to go around in circles on the "Is INFO harmful, and if so >> why?" carousel. >> >> Since I can't leave it hanging there, I'd like to propose >> some rules of thumb: >> >> 1) If INFO had context negotiation, we'd have a complete >> protocol and would quite possibly only need new SIP method >> types if there was a need for a fundamental change to the SIP >> state machine. Even without INFO, we have the same >> functionality available, albeit at the overhead of an >> additional dialog. So, I suggest we only introduce new SIP >> methods if there's a need to change the underlying machine. >> If we're just moving new data in application contexts, we can >> do that without changing SIP itself. I really don't want to >> keep the SIP WG around just so we can specify a new SIP >> method for each application somebody dreams up. >> >> 2) Since SIP can provide for the transport of arbitrary data >> and application context, we should only use "session" >> transport of the data when that dataflow itself has >> fundamentally different characteristics -- essentially, when >> it is a long-lived and relatively continues flow, aka a >> "stream". Quite possibly, this should extend to only >> dataflows that have the properties of RTP -- time sensitive, >> relatively loss insensitive, and so bulky we need them to be >> as end-to-end as we can even if it means building more >> infrastructure to make that happen. And yes, I think MSRP is >> a misguided effort -- by the time we've built MSRP relays and >> all the extra cruft, we've duplicated SIP's message proxy >> operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm >> not even sure that this level of separation is a good idea. >> Coaxial signaling and media have great advantages for >> firewall traversal. But we have what we have. In short, use >> RTP/MSRP for "sessions", and SIP event payloads (or >> contextually-adapted INFO) for everything else. >> >> 3) There is no rule 3. >> >> -- >> 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 11 20:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7rY-00062B-FA; Thu, 11 Oct 2007 19:54:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig7rW-0005tc-G3 for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 19:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig7rW-0005Z2-3J for sip@ietf.org; Thu, 11 Oct 2007 19:54:42 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig7rM-00033D-O8 for sip@ietf.org; Thu, 11 Oct 2007 19:54:33 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9BNsDDU027138; Thu, 11 Oct 2007 18:54:13 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 18:54:13 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 01:54:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Fri, 12 Oct 2007 01:54:10 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> In-Reply-To: <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgLv0SYQ12Cvi4BRyKsCkDtxYyWqgAR48QA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 11 Oct 2007 23:54:11.0123 (UTC) FILETIME=[050E9830:01C80C62] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org There is one major downside to this. If we are sending stuff in the dialog, it really ought to have some relation to the dialog, not just be included there because the dialog happened to exist.....then you end up with people wanting to route the dialog to a centralised point where you can extract this piggy-backed information ... Then you end up with a stimulus protocol between this UE and this centralised server where the dialog contains absolutely no knowledge of the state of the session. Providing an in dialog mechanism makes it much harder to to stop this happening.=20 Regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, October 11, 2007 5:20 AM > To: Francois Audet > Cc: IETF SIP List; Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > On Oct 10, 2007, at 6:14 PM, Francois Audet wrote: >=20 > > > >> (d) they think it's a waste of resources to establish multiple=20 > >> additional subscription dialogs (there may be other type=20 > of data than=20 > >> DTMF they are willing to receive) which in many cases may=20 > not even be=20 > >> used during the call (it can not be assumed that the one=20 > sending the=20 > >> subscription always knows exactly when it will receive=20 > events). Maybe=20 > >> DTMF is not the best example in the world (my fault - I=20 > should have=20 > >> been more generic), but I am sure there could be events=20 > which would=20 > >> not be used in a very high percentage of all calls, but still the=20 > >> additional subscription dialog(s) would have to be=20 > established - just=20 > >> in case. > > > > Maybe a way to subscribe to packages within an INVITE=20 > dialog would be=20 > > suitable. You then would get the NOTIFYs withind the=20 > dialog, and they=20 > > wouldn't be out-of-the-blue because you would have=20 > subscribed to those=20 > > events explicitly with some Allow-Event in the INVITE. > > >=20 > Hmm. In-dialog event notification using INVITE as an explicit=20 > subscription trigger. That works, mostly. >=20 > Other people would argue that the semantics are better=20 > preserved with a a new SIP method that is defined to carry=20 > whatever sort of blob we're talking about in the specific=20 > context of the application usage. =20 > We'd then add that method name to the list of supported=20 > methods given in the Allow header field. Of course, this will=20 > eventually give us "Really Big" Allow header fields, which=20 > means the negotiation mechanism is broken. We need an easier=20 > way for one end to ask "Hey, do you understand this?". >=20 > Others would say that the we're better off defining a session=20 > protocol designed to transport the blobs in question, along=20 > with SDP extensions to negotiate this protocol, NAT-traversal=20 > hooks to allow us to talk about the connectivity of the=20 > blob-transferral protocol, then do a reINVITE exchange to add=20 > the new blob-session to the existing session. >=20 > Yet others would say that we already have a blob-transferral=20 > protocol (MSRP), along with the nat traversal hooks and SDP=20 > extensions needed to negotiate it, and should therefore push=20 > the problem out one layer of protocol and make it an MSRP=20 > problem. This begs the question of how MSRP negotiates as to=20 > whether the context and content are agreed on both ends,=20 > which AFAIK it does little better at than INFO. >=20 >=20 > So what's the difference? >=20 > All (assuming we figure out the MSRP context negotiation=20 > problem) explicitly declare the understanding of and the=20 > desire to receive messages within this dialog/session that=20 > contain the data we've defined and assure that the=20 > application context (the "what do I do with this stuff"=20 > problem) is mutually understood. >=20 > The differences are that one approach is the extension of an=20 > application protocol to support a new application, while two=20 > others are extensions of existing transport protocols (SIP,=20 > MSRP) to carry new payloads in contexts determined by the=20 > applications. The last one implies the development of an=20 > all-new transport protocol (or perhaps the modification of=20 > some other protocol like RTP) as well as extension to our=20 > descriptive protocol (SDP). These are very different things,=20 > and part of the reason that SIP has gotten more complex than=20 > I would like is that we haven't been operating with a clear=20 > understanding of these differences. >=20 > Personally, I think that we've got a lot of complexity there=20 > that we didn't really need. If SIP had been designed from the=20 > ground-up as a transport protocol for arbitrary messages and=20 > the application were a function of the message content, we'd=20 > have a much clearer model of what to do. But it wasn't built=20 > that way, so now we need some guiding principles on when each=20 > sort of approach is appropriate. Without it, we're just going=20 > to go around in circles on the "Is INFO harmful, and if so=20 > why?" carousel. >=20 > Since I can't leave it hanging there, I'd like to propose=20 > some rules of thumb: >=20 > 1) If INFO had context negotiation, we'd have a complete=20 > protocol and would quite possibly only need new SIP method=20 > types if there was a need for a fundamental change to the SIP=20 > state machine. Even without INFO, we have the same=20 > functionality available, albeit at the overhead of an=20 > additional dialog. So, I suggest we only introduce new SIP=20 > methods if there's a need to change the underlying machine.=20 > If we're just moving new data in application contexts, we can=20 > do that without changing SIP itself. I really don't want to=20 > keep the SIP WG around just so we can specify a new SIP=20 > method for each application somebody dreams up. >=20 > 2) Since SIP can provide for the transport of arbitrary data=20 > and application context, we should only use "session"=20 > transport of the data when that dataflow itself has=20 > fundamentally different characteristics -- essentially, when=20 > it is a long-lived and relatively continues flow, aka a=20 > "stream". Quite possibly, this should extend to only=20 > dataflows that have the properties of RTP -- time sensitive,=20 > relatively loss insensitive, and so bulky we need them to be=20 > as end-to-end as we can even if it means building more=20 > infrastructure to make that happen. And yes, I think MSRP is=20 > a misguided effort -- by the time we've built MSRP relays and=20 > all the extra cruft, we've duplicated SIP's message proxy=20 > operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm=20 > not even sure that this level of separation is a good idea.=20 > Coaxial signaling and media have great advantages for=20 > firewall traversal. But we have what we have. In short, use=20 > RTP/MSRP for "sessions", and SIP event payloads (or=20 > contextually-adapted INFO) for everything else. >=20 > 3) There is no rule 3. >=20 > -- > Dean >=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 11 20:10:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85U-0006S2-7N; Thu, 11 Oct 2007 20:09:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig85S-0006QF-5A for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85R-0006Q6-Qx; Thu, 11 Oct 2007 20:09:05 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig85R-0003fz-Bq; Thu, 11 Oct 2007 20:09:05 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08xuD007921; Thu, 11 Oct 2007 17:08:59 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uUm030757; Thu, 11 Oct 2007 17:08:57 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:08:56 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 17:32:14 -0400 Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt From: Eric Burger To: Dean Willis , Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: AcgMTjB0bshoHnhBEdymOwAWy4mm/w== In-Reply-To: <50E0593E-BCE3-4725-A85B-49A6F5F37900@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List , ECRIT 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: , Errors-To: sip-bounces@ietf.org Except... You have NO way of knowing you are the terminating proxy. On 9/4/07 12:13 PM, "Dean Willis" wrote: > > On Sep 3, 2007, at 2:59 PM, Hannes Tschofenig wrote: [snip] > In the broader IETF case, I suspect it means "NEVER retarget a > request URI that contains a service URN unless you're the terminating > PSAP's proxy, and then do so very carefully." Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 11 20:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85i-0006dH-Js; Thu, 11 Oct 2007 20:09:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig85h-0006cR-6n for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85g-0006cJ-Tc for sip@ietf.org; Thu, 11 Oct 2007 20:09:20 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig85Z-0003YC-E7 for sip@ietf.org; Thu, 11 Oct 2007 20:09:20 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C090e5007928; Thu, 11 Oct 2007 17:09:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C08uUo030757; Thu, 11 Oct 2007 17:08:59 -0700 Received: from 172.24.28.199 ([172.24.28.199]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Oct 2007 00:08:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 11 Oct 2007 17:34:53 -0400 Subject: Re: [Sip] INFO From: Eric Burger To: "Christer Holmberg (JO/LMF)" , Hadriel Kaplan Message-ID: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsTh In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Errors-To: sip-bounces@ietf.org Right: "DTMF may not be the only information users want to send to each other during a session." This is why one MUST establish multiple subscription dialogs. How else would one keep track of the different elements / local routing decisions? If you are proposing application routing a'la P-Asserted-Service... On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" wrote: > > > Hi, > > Let's also keep in mind that DTMF may not be the only information users > want to send to each other during a session. So, you will need to > establish subscription dialogs for every type of event that the users > may want to send during the session... > > Regards, > > Christer > >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) >> [mailto:christer.holmberg@ericsson.com] >> Sent: 11. syyskuuta 2007 12:27 >> To: Hadriel Kaplan; Eric Burger >> Cc: sip >> Subject: RE: [Sip] INFO >> >> >> Hi, >> >>>> Consider a PSTN call. The call goes from the gateway to >> softswitch / >>>> Proxy. Proxy routes to VM App Server. INFO has to pass through >>>> softswitch / Proxy. >>>> In KPML-land, VM App Server *directly* subscribes to UAC key press >> state, bypassing the softswitch. >> >> [Christer] As I've said before, there are environments where some >> proxies must (for whatever reason) be passed through. I guess an >> outbound proxy is a good example. >> >>>> KPML and INFO have the same number of messages for a SINGLE digit; >> KPML wins >>>> hands-down for multiple digits or reports. >>> >>> Not exactly - for a single digit, KPML would generate a >>> Subscribe/200/Notify/200 before the single DTMF was even >>> pressed - before the actual Notify with the digits in it. >>> And of course there is now also a subscribe dialog involved. >>> Assuming a one-shot single digit type, then, we're talking 6 >>> SIP messages for KPML vs. 2 for Info. >> >> [Christer] And, in cases where you need to send DTMFs (or whatever >> information) in both directions you actually need 2 >> subscription dialogs >> - one in each direction, and maintaining dialog state also consumes >> resources. And, in some cases you may not even know whether you will >> ever have to use the dialog. >> >> >>>> More importantly, let's take a Call Management (CM) >> application that >>>> calls a VM application when they cannot find the >> subscriber. INFO has >> >>>> to pass through the softswitch / Proxy to the CM >> application. Cool - >>>> it is a proxy, so it knows to relay. But OOPS! The CM application >>>> has to proxy the INFOs to the VM application. Yes - you could be a >>>> good programmer and remember to do that EVERYWHERE you place an >>>> outbound call, but it is really easy to get wrong. >>> >>> I'm not sure I understand the scenario. The VM learned about >>> this call how? >>> By being in the signaling path, no? So why wouldn't the CM >>> forward INFO along the path? (I mean it is in the same >>> dialog, after all) Now I don't doubt it could screw that up, >>> and eat the info thinking it was for itself, but lots of >>> things can get screwed up - my guess is KPML will not be >>> impervious to screw ups. >> >> [Christer] I also have problems understanding the scenario. INFO is >> routed to wherever the INVITE that initiated the dialog was routed... >> >> 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 >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 11 20:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85P-0006Kd-A0; Thu, 11 Oct 2007 20:09:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ig85N-0006B4-UE for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 20:09:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig85N-0006At-3V for sip@ietf.org; Thu, 11 Oct 2007 20:09:01 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig85M-0003fs-8F for sip@ietf.org; Thu, 11 Oct 2007 20:09:01 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9C08vc08343; Fri, 12 Oct 2007 00:08:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 11 Oct 2007 19:08:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12746DFC@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgLv0SYQ12Cvi4BRyKsCkDtxYyWqgAR48QAABc7cGA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8 F6 5 DB 2 7- 41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Yes, I agree. > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Thursday, October 11, 2007 16:54 > To: Dean Willis; Audet, Francois (SC100:3055) > Cc: IETF SIP List; Christer Holmberg > Subject: RE: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 > There is one major downside to this. >=20 > If we are sending stuff in the dialog, it really ought to=20 > have some relation to the dialog, not just be included there=20 > because the dialog happened to exist.....then you end up with=20 > people wanting to route the dialog to a centralised point=20 > where you can extract this piggy-backed information ... Then=20 > you end up with a stimulus protocol between this UE and this=20 > centralised server where the dialog contains absolutely no=20 > knowledge of the state of the session. >=20 > Providing an in dialog mechanism makes it much harder to to=20 > stop this happening.=20 >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, October 11, 2007 5:20 AM > > To: Francois Audet > > Cc: IETF SIP List; Christer Holmberg > > Subject: Re: What are we arguing about when we say INFO? (was > > Re: [Sip] INFO) > >=20 > >=20 > > On Oct 10, 2007, at 6:14 PM, Francois Audet wrote: > >=20 > > > > > >> (d) they think it's a waste of resources to establish multiple=20 > > >> additional subscription dialogs (there may be other type > > of data than > > >> DTMF they are willing to receive) which in many cases may > > not even be > > >> used during the call (it can not be assumed that the one > > sending the > > >> subscription always knows exactly when it will receive > > events). Maybe > > >> DTMF is not the best example in the world (my fault - I > > should have > > >> been more generic), but I am sure there could be events > > which would > > >> not be used in a very high percentage of all calls, but=20 > still the=20 > > >> additional subscription dialog(s) would have to be > > established - just > > >> in case. > > > > > > Maybe a way to subscribe to packages within an INVITE > > dialog would be > > > suitable. You then would get the NOTIFYs withind the > > dialog, and they > > > wouldn't be out-of-the-blue because you would have > > subscribed to those > > > events explicitly with some Allow-Event in the INVITE. > > > > >=20 > > Hmm. In-dialog event notification using INVITE as an explicit=20 > > subscription trigger. That works, mostly. > >=20 > > Other people would argue that the semantics are better=20 > preserved with=20 > > a a new SIP method that is defined to carry whatever sort of blob=20 > > we're talking about in the specific context of the=20 > application usage. > > We'd then add that method name to the list of supported=20 > methods given=20 > > in the Allow header field. Of course, this will eventually give us=20 > > "Really Big" Allow header fields, which means the negotiation=20 > > mechanism is broken. We need an easier way for one end to=20 > ask "Hey, do=20 > > you understand this?". > >=20 > > Others would say that the we're better off defining a=20 > session protocol=20 > > designed to transport the blobs in question, along with SDP=20 > extensions=20 > > to negotiate this protocol, NAT-traversal hooks to allow us to talk=20 > > about the connectivity of the blob-transferral protocol, then do a=20 > > reINVITE exchange to add the new blob-session to the=20 > existing session. > >=20 > > Yet others would say that we already have a=20 > blob-transferral protocol=20 > > (MSRP), along with the nat traversal hooks and SDP=20 > extensions needed=20 > > to negotiate it, and should therefore push the problem out=20 > one layer=20 > > of protocol and make it an MSRP problem. This begs the=20 > question of how=20 > > MSRP negotiates as to whether the context and content are agreed on=20 > > both ends, which AFAIK it does little better at than INFO. > >=20 > >=20 > > So what's the difference? > >=20 > > All (assuming we figure out the MSRP context negotiation=20 > > problem) explicitly declare the understanding of and the=20 > > desire to receive messages within this dialog/session that=20 > > contain the data we've defined and assure that the=20 > > application context (the "what do I do with this stuff"=20 > > problem) is mutually understood. > >=20 > > The differences are that one approach is the extension of an=20 > > application protocol to support a new application, while two=20 > > others are extensions of existing transport protocols (SIP,=20 > > MSRP) to carry new payloads in contexts determined by the=20 > > applications. The last one implies the development of an=20 > > all-new transport protocol (or perhaps the modification of=20 > > some other protocol like RTP) as well as extension to our=20 > > descriptive protocol (SDP). These are very different things,=20 > > and part of the reason that SIP has gotten more complex than=20 > > I would like is that we haven't been operating with a clear=20 > > understanding of these differences. > >=20 > > Personally, I think that we've got a lot of complexity there=20 > > that we didn't really need. If SIP had been designed from the=20 > > ground-up as a transport protocol for arbitrary messages and=20 > > the application were a function of the message content, we'd=20 > > have a much clearer model of what to do. But it wasn't built=20 > > that way, so now we need some guiding principles on when each=20 > > sort of approach is appropriate. Without it, we're just going=20 > > to go around in circles on the "Is INFO harmful, and if so=20 > > why?" carousel. > >=20 > > Since I can't leave it hanging there, I'd like to propose=20 > > some rules of thumb: > >=20 > > 1) If INFO had context negotiation, we'd have a complete=20 > > protocol and would quite possibly only need new SIP method=20 > > types if there was a need for a fundamental change to the SIP=20 > > state machine. Even without INFO, we have the same=20 > > functionality available, albeit at the overhead of an=20 > > additional dialog. So, I suggest we only introduce new SIP=20 > > methods if there's a need to change the underlying machine.=20 > > If we're just moving new data in application contexts, we can=20 > > do that without changing SIP itself. I really don't want to=20 > > keep the SIP WG around just so we can specify a new SIP=20 > > method for each application somebody dreams up. > >=20 > > 2) Since SIP can provide for the transport of arbitrary data=20 > > and application context, we should only use "session"=20 > > transport of the data when that dataflow itself has=20 > > fundamentally different characteristics -- essentially, when=20 > > it is a long-lived and relatively continues flow, aka a=20 > > "stream". Quite possibly, this should extend to only=20 > > dataflows that have the properties of RTP -- time sensitive,=20 > > relatively loss insensitive, and so bulky we need them to be=20 > > as end-to-end as we can even if it means building more=20 > > infrastructure to make that happen. And yes, I think MSRP is=20 > > a misguided effort -- by the time we've built MSRP relays and=20 > > all the extra cruft, we've duplicated SIP's message proxy=20 > > operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm=20 > > not even sure that this level of separation is a good idea.=20 > > Coaxial signaling and media have great advantages for=20 > > firewall traversal. But we have what we have. In short, use=20 > > RTP/MSRP for "sessions", and SIP event payloads (or=20 > > contextually-adapted INFO) for everything else. > >=20 > > 3) There is no rule 3. > >=20 > > -- > > Dean > >=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 >=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 11 22:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAS8-0007PO-Tq; Thu, 11 Oct 2007 22:40:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgAS6-0007Aq-QB for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:40:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAS6-00075e-7E; Thu, 11 Oct 2007 22:40:38 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAS5-0008Pc-RC; Thu, 11 Oct 2007 22:40:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7D71A175AB; Fri, 12 Oct 2007 02:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IgARW-00072t-1X; Thu, 11 Oct 2007 22:40: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: Thu, 11 Oct 2007 22:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-gruu-15.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: , 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-15.txt Pages : 39 Date : 2007-10-11 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 registrar 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-15.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-15.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-15.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: <2007-10-11223239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-11223239.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 Thu Oct 11 22:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAPp-0002Sc-4U; Thu, 11 Oct 2007 22:38:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgAPn-0002SS-Ns for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:38:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAPn-0002RM-Cq for sip@ietf.org; Thu, 11 Oct 2007 22:38:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAPk-0008L1-Hf for sip@ietf.org; Thu, 11 Oct 2007 22:38:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6416720537; Fri, 12 Oct 2007 04:38:11 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-b9-470ede1339be Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 496C12052B; Fri, 12 Oct 2007 04:38:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 04:38:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 12 Oct 2007 04:38:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmA= References: From: "Christer Holmberg" To: "Eric Burger" , "Hadriel Kaplan" X-OriginalArrivalTime: 12 Oct 2007 02:38:10.0839 (UTC) FILETIME=[EDFC1A70:01C80C78] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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: , Errors-To: sip-bounces@ietf.org Hi Eric, I am not sure I understand what you mean, but INFOs are routed according to the route set of the invite dialog they are sent within. If you want to transport information using some other path you can of course not send the information within the invite dialog. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 0:35 > To: Christer Holmberg; Hadriel Kaplan > Cc: sip > Subject: Re: [Sip] INFO >=20 > Right: "DTMF may not be the only information users want to=20 > send to each other during a session." This is why one MUST=20 > establish multiple subscription dialogs. How else would one=20 > keep track of the different elements / local routing=20 > decisions? If you are proposing application routing a'la=20 > P-Asserted-Service... >=20 >=20 > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > wrote: >=20 > >=20 > >=20 > > Hi, > >=20 > > Let's also keep in mind that DTMF may not be the only information=20 > > users want to send to each other during a session. So, you=20 > will need=20 > > to establish subscription dialogs for every type of event that the=20 > > users may want to send during the session... > >=20 > > Regards, > >=20 > > Christer > >=20 > >> -----Original Message----- > >> From: Christer Holmberg (JO/LMF) > >> [mailto:christer.holmberg@ericsson.com] > >> Sent: 11. syyskuuta 2007 12:27 > >> To: Hadriel Kaplan; Eric Burger > >> Cc: sip > >> Subject: RE: [Sip] INFO > >>=20 > >>=20 > >> Hi, > >>=20 > >>>> Consider a PSTN call. The call goes from the gateway to > >> softswitch / > >>>> Proxy. Proxy routes to VM App Server. INFO has to pass through=20 > >>>> softswitch / Proxy. > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > key press > >> state, bypassing the softswitch. > >>=20 > >> [Christer] As I've said before, there are environments where some=20 > >> proxies must (for whatever reason) be passed through. I guess an=20 > >> outbound proxy is a good example. > >>=20 > >>>> KPML and INFO have the same number of messages for a=20 > SINGLE digit; > >> KPML wins > >>>> hands-down for multiple digits or reports. > >>>=20 > >>> Not exactly - for a single digit, KPML would generate a=20 > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > pressed -=20 > >>> before the actual Notify with the digits in it. > >>> And of course there is now also a subscribe dialog involved. > >>> Assuming a one-shot single digit type, then, we're talking 6 SIP=20 > >>> messages for KPML vs. 2 for Info. > >>=20 > >> [Christer] And, in cases where you need to send DTMFs (or whatever > >> information) in both directions you actually need 2 subscription=20 > >> dialogs > >> - one in each direction, and maintaining dialog state also=20 > consumes=20 > >> resources. And, in some cases you may not even know=20 > whether you will=20 > >> ever have to use the dialog. > >>=20 > >>=20 > >>>> More importantly, let's take a Call Management (CM) > >> application that > >>>> calls a VM application when they cannot find the > >> subscriber. INFO has > >>=20 > >>>> to pass through the softswitch / Proxy to the CM > >> application. Cool - > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > application=20 > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > could be a=20 > >>>> good programmer and remember to do that EVERYWHERE you place an=20 > >>>> outbound call, but it is really easy to get wrong. > >>>=20 > >>> I'm not sure I understand the scenario. The VM learned=20 > about this=20 > >>> call how? > >>> By being in the signaling path, no? So why wouldn't the=20 > CM forward=20 > >>> INFO along the path? (I mean it is in the same dialog,=20 > after all) =20 > >>> Now I don't doubt it could screw that up, and eat the=20 > info thinking=20 > >>> it was for itself, but lots of things can get screwed up=20 > - my guess=20 > >>> is KPML will not be impervious to screw ups. > >>=20 > >> [Christer] I also have problems understanding the=20 > scenario. INFO is=20 > >> routed to wherever the INVITE that initiated the dialog=20 > was routed... > >>=20 > >> Regards, > >>=20 > >> Christer > >>=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 Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 11 22:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAS8-0007PO-Tq; Thu, 11 Oct 2007 22:40:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgAS6-0007Aq-QB for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:40:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAS6-00075e-7E; Thu, 11 Oct 2007 22:40:38 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAS5-0008Pc-RC; Thu, 11 Oct 2007 22:40:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7D71A175AB; Fri, 12 Oct 2007 02:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IgARW-00072t-1X; Thu, 11 Oct 2007 22:40: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: Thu, 11 Oct 2007 22:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-gruu-15.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: , 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-15.txt Pages : 39 Date : 2007-10-11 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 registrar 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-15.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-15.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-15.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: <2007-10-11223239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-11223239.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 Thu Oct 11 22:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAPp-0002Sc-4U; Thu, 11 Oct 2007 22:38:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgAPn-0002SS-Ns for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:38:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAPn-0002RM-Cq for sip@ietf.org; Thu, 11 Oct 2007 22:38:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAPk-0008L1-Hf for sip@ietf.org; Thu, 11 Oct 2007 22:38:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6416720537; Fri, 12 Oct 2007 04:38:11 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-b9-470ede1339be Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 496C12052B; Fri, 12 Oct 2007 04:38:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 04:38:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 12 Oct 2007 04:38:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmA= References: From: "Christer Holmberg" To: "Eric Burger" , "Hadriel Kaplan" X-OriginalArrivalTime: 12 Oct 2007 02:38:10.0839 (UTC) FILETIME=[EDFC1A70:01C80C78] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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: , Errors-To: sip-bounces@ietf.org Hi Eric, I am not sure I understand what you mean, but INFOs are routed according to the route set of the invite dialog they are sent within. If you want to transport information using some other path you can of course not send the information within the invite dialog. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 0:35 > To: Christer Holmberg; Hadriel Kaplan > Cc: sip > Subject: Re: [Sip] INFO >=20 > Right: "DTMF may not be the only information users want to=20 > send to each other during a session." This is why one MUST=20 > establish multiple subscription dialogs. How else would one=20 > keep track of the different elements / local routing=20 > decisions? If you are proposing application routing a'la=20 > P-Asserted-Service... >=20 >=20 > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > wrote: >=20 > >=20 > >=20 > > Hi, > >=20 > > Let's also keep in mind that DTMF may not be the only information=20 > > users want to send to each other during a session. So, you=20 > will need=20 > > to establish subscription dialogs for every type of event that the=20 > > users may want to send during the session... > >=20 > > Regards, > >=20 > > Christer > >=20 > >> -----Original Message----- > >> From: Christer Holmberg (JO/LMF) > >> [mailto:christer.holmberg@ericsson.com] > >> Sent: 11. syyskuuta 2007 12:27 > >> To: Hadriel Kaplan; Eric Burger > >> Cc: sip > >> Subject: RE: [Sip] INFO > >>=20 > >>=20 > >> Hi, > >>=20 > >>>> Consider a PSTN call. The call goes from the gateway to > >> softswitch / > >>>> Proxy. Proxy routes to VM App Server. INFO has to pass through=20 > >>>> softswitch / Proxy. > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > key press > >> state, bypassing the softswitch. > >>=20 > >> [Christer] As I've said before, there are environments where some=20 > >> proxies must (for whatever reason) be passed through. I guess an=20 > >> outbound proxy is a good example. > >>=20 > >>>> KPML and INFO have the same number of messages for a=20 > SINGLE digit; > >> KPML wins > >>>> hands-down for multiple digits or reports. > >>>=20 > >>> Not exactly - for a single digit, KPML would generate a=20 > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > pressed -=20 > >>> before the actual Notify with the digits in it. > >>> And of course there is now also a subscribe dialog involved. > >>> Assuming a one-shot single digit type, then, we're talking 6 SIP=20 > >>> messages for KPML vs. 2 for Info. > >>=20 > >> [Christer] And, in cases where you need to send DTMFs (or whatever > >> information) in both directions you actually need 2 subscription=20 > >> dialogs > >> - one in each direction, and maintaining dialog state also=20 > consumes=20 > >> resources. And, in some cases you may not even know=20 > whether you will=20 > >> ever have to use the dialog. > >>=20 > >>=20 > >>>> More importantly, let's take a Call Management (CM) > >> application that > >>>> calls a VM application when they cannot find the > >> subscriber. INFO has > >>=20 > >>>> to pass through the softswitch / Proxy to the CM > >> application. Cool - > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > application=20 > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > could be a=20 > >>>> good programmer and remember to do that EVERYWHERE you place an=20 > >>>> outbound call, but it is really easy to get wrong. > >>>=20 > >>> I'm not sure I understand the scenario. The VM learned=20 > about this=20 > >>> call how? > >>> By being in the signaling path, no? So why wouldn't the=20 > CM forward=20 > >>> INFO along the path? (I mean it is in the same dialog,=20 > after all) =20 > >>> Now I don't doubt it could screw that up, and eat the=20 > info thinking=20 > >>> it was for itself, but lots of things can get screwed up=20 > - my guess=20 > >>> is KPML will not be impervious to screw ups. > >>=20 > >> [Christer] I also have problems understanding the=20 > scenario. INFO is=20 > >> routed to wherever the INVITE that initiated the dialog=20 > was routed... > >>=20 > >> Regards, > >>=20 > >> Christer > >>=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 Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 12 00:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBxi-0002DR-TJ; Fri, 12 Oct 2007 00:17:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgAKu-0004PX-Rp for sip-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:33:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAKu-0004PP-HR for sip@ietf.org; Thu, 11 Oct 2007 22:33:12 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgAKu-0008B1-9x for sip@ietf.org; Thu, 11 Oct 2007 22:33:12 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 30D732ACB9; Fri, 12 Oct 2007 02:32:42 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IgAKP-0006ri-Ti; Thu, 11 Oct 2007 22:32:41 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: jdrosen@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 11 Oct 2007 22:32:41 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Fri, 12 Oct 2007 00:17:21 -0400 Cc: sip@ietf.org Subject: [Sip] New Version Notification for draft-ietf-sip-gruu-15 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: , Errors-To: sip-bounces@ietf.org A new version of I-D, draft-ietf-sip-gruu-15.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository. Filename: draft-ietf-sip-gruu Revision: 15 Title: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Creation_date: 2007-10-11 WG ID: sip Number_of_pages: 39 Abstract: 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 registrar and for communicating a GRUU to a peer within a dialog. The IETF Secretariat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 12 03:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEbx-00025w-SV; Fri, 12 Oct 2007 03:07:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgEbx-00024C-47 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEbs-0001l2-BP for sip@ietf.org; Fri, 12 Oct 2007 03:07:00 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgEbl-0007VB-U1 for sip@ietf.org; Fri, 12 Oct 2007 03:06:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A35E20519; Fri, 12 Oct 2007 09:06:28 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-20-470f1cf4058f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29C882000C; Fri, 12 Oct 2007 09:06:28 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:06:27 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:06:27 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6F41E2465; Fri, 12 Oct 2007 10:06:27 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 959774DC26; Fri, 12 Oct 2007 10:06:26 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 263E84DB21; Fri, 12 Oct 2007 10:06:26 +0300 (EEST) Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) From: Salvatore Loreto To: Dean Willis In-Reply-To: <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> Content-Type: text/plain Date: Fri, 12 Oct 2007 10:06:26 +0300 Message-Id: <1192172786.17547.19.camel@n85.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 12 Oct 2007 07:06:27.0501 (UTC) FILETIME=[6857CDD0:01C80C9E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org see my comments in line Sal On Thu, 2007-10-11 at 14:31 -0500, Dean Willis wrote: > On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: > > > Hi Dean, > > > > Can you tell me what is the difference between "contextually-adapted > > INFO", and a "subscription embedded in the INVITE, with the NOTIFY > > using the same dialog"? I don't see any advantage to the INFO > > approach. > > > > One might argue that the second is a means of implementing the first. > > INFO, as written, lacks contextual negotiation. You're proposing to > replace the method name with NOTIFY and use the event-package > framework for content and context expression, using a header-field in > the INVITE request to engage context negotiation. It seems to me like > that would work. There's nothing "implicit" about it, and it is no > worse for overhead than using Supported or Allow. It also has the > advantage of letting us reuse an existing registration framework, > IANA process, and specification review process under RFC 3427. Very > tidy, I think I like it. the proposal is interesting. However there should be cases where you need to send whatever information in both directions, or cases where when you send an information via Notify you need to receive back some information (e.g. the fact that you receive a 200Ok as answer to the Notify it is not enough). How do you think your proposal should work in those cases ? perhaps with 2 subscription one in each direction? > > I would argue that it would be nice to have an extension mechanism > that allows a UA to be asked "Do you support this specific > extension?" without the UA having to encode every extension it > supports in every request it sends, but that's a different issue. that is also something nice. Are you thinking a mechanism like an OPTION that instead to be general just asks for a specific extension? > > > > It seems to me we already have a mechanism for asking for asynchroous > > information with subscriptions. Why not use that? > > > > As you pointed out, the current mechanism adds a dialog overhead. It > also raises issues with event-stream correlation that can be a bit of > a challenge depending on the application's API and threading model. > Your suggested workaround for in-dialog notification relieves these > issues, so it may be better than the existing mechanism for a number > of use cases. More importantly, it is no worse than NOTIFY for those > use cases (barring the small increase in request size for context > negotiation). > > -- > 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 Fri Oct 12 05:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgH4o-0006Sp-VQ; Fri, 12 Oct 2007 05:45:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgH4n-0006Rg-7i for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 05:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgH4m-0006RR-U8 for sip@ietf.org; Fri, 12 Oct 2007 05:45:00 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgH4f-0004gI-Hg for sip@ietf.org; Fri, 12 Oct 2007 05:45:00 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C9ibPR014725; Fri, 12 Oct 2007 02:44:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9C9iade016626; Fri, 12 Oct 2007 02:44:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Sip] INFO Date: Fri, 12 Oct 2007 02:44:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOw== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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: , Errors-To: sip-bounces@ietf.org Routing of the message once it gets to the device (application), not route to the device (transport). -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. ----- Original Message ----- From: Christer Holmberg To: Eric Burger; Hadriel Kaplan Cc: sip Sent: Thu Oct 11 19:38:06 2007 Subject: RE: [Sip] INFO Hi Eric, I am not sure I understand what you mean, but INFOs are routed according to the route set of the invite dialog they are sent within. If you want to transport information using some other path you can of course not send the information within the invite dialog. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: 12. lokakuuta 2007 0:35 > To: Christer Holmberg; Hadriel Kaplan > Cc: sip > Subject: Re: [Sip] INFO > > Right: "DTMF may not be the only information users want to > send to each other during a session." This is why one MUST > establish multiple subscription dialogs. How else would one > keep track of the different elements / local routing > decisions? If you are proposing application routing a'la > P-Asserted-Service... > > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > wrote: > > > > > > > Hi, > > > > Let's also keep in mind that DTMF may not be the only information > > users want to send to each other during a session. So, you > will need > > to establish subscription dialogs for every type of event that the > > users may want to send during the session... > > > > Regards, > > > > Christer > > > >> -----Original Message----- > >> From: Christer Holmberg (JO/LMF) > >> [mailto:christer.holmberg@ericsson.com] > >> Sent: 11. syyskuuta 2007 12:27 > >> To: Hadriel Kaplan; Eric Burger > >> Cc: sip > >> Subject: RE: [Sip] INFO > >> > >> > >> Hi, > >> > >>>> Consider a PSTN call. The call goes from the gateway to > >> softswitch / > >>>> Proxy. Proxy routes to VM App Server. INFO has to pass through > >>>> softswitch / Proxy. > >>>> In KPML-land, VM App Server *directly* subscribes to UAC > key press > >> state, bypassing the softswitch. > >> > >> [Christer] As I've said before, there are environments where some > >> proxies must (for whatever reason) be passed through. I guess an > >> outbound proxy is a good example. > >> > >>>> KPML and INFO have the same number of messages for a > SINGLE digit; > >> KPML wins > >>>> hands-down for multiple digits or reports. > >>> > >>> Not exactly - for a single digit, KPML would generate a > >>> Subscribe/200/Notify/200 before the single DTMF was even > pressed - > >>> before the actual Notify with the digits in it. > >>> And of course there is now also a subscribe dialog involved. > >>> Assuming a one-shot single digit type, then, we're talking 6 SIP > >>> messages for KPML vs. 2 for Info. > >> > >> [Christer] And, in cases where you need to send DTMFs (or whatever > >> information) in both directions you actually need 2 subscription > >> dialogs > >> - one in each direction, and maintaining dialog state also > consumes > >> resources. And, in some cases you may not even know > whether you will > >> ever have to use the dialog. > >> > >> > >>>> More importantly, let's take a Call Management (CM) > >> application that > >>>> calls a VM application when they cannot find the > >> subscriber. INFO has > >> > >>>> to pass through the softswitch / Proxy to the CM > >> application. Cool - > >>>> it is a proxy, so it knows to relay. But OOPS! The CM > application > >>>> has to proxy the INFOs to the VM application. Yes - you > could be a > >>>> good programmer and remember to do that EVERYWHERE you place an > >>>> outbound call, but it is really easy to get wrong. > >>> > >>> I'm not sure I understand the scenario. The VM learned > about this > >>> call how? > >>> By being in the signaling path, no? So why wouldn't the > CM forward > >>> INFO along the path? (I mean it is in the same dialog, > after all) > >>> Now I don't doubt it could screw that up, and eat the > info thinking > >>> it was for itself, but lots of things can get screwed up > - my guess > >>> is KPML will not be impervious to screw ups. > >> > >> [Christer] I also have problems understanding the > scenario. INFO is > >> routed to wherever the INVITE that initiated the dialog > was routed... > >> > >> 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 > >> > > > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 12 09:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKQQ-0000o1-NB; Fri, 12 Oct 2007 09:19:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgKQO-0000kd-Kt for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 09:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKQO-0000aJ-2H for sip@ietf.org; Fri, 12 Oct 2007 09:19:32 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgKQG-0003oM-Bb for sip@ietf.org; Fri, 12 Oct 2007 09:19:29 -0400 Received: by wr-out-0506.google.com with SMTP id 70so493878wra for ; Fri, 12 Oct 2007 06:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=L6z/vkyBizNyP2iy6g0yKS5S0R+EUhTRuSkmRIbL3wY=; b=n4vVzkMfSPeavRPp8HZPtNAGh+QBeRygvUGQNuZPswVINITOFDQxR/a9ZAFWVROlsDsW2o78vPBqcRT3iCbUM1+8txL6KJREQjpVnIAyu0YYdVbNjrBnY1UEho5puMMiFSRyim1UcslspaKOEuQOM91K2lmCPmUUUhmRxuDAqH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=DNS0mB8jLO/eFfgr40u70/oTf3koREZd5rEX8mXacXPikyCI5ruwnFFF2jTvycBrRisGBHY53/4LWFBM9QU4/d37rq1gMqxY2ql1mKCjW8Ts5VgQ0yf1OpadaKJhGSAaqBqiwflio41ZPeVDqmY6mt7Z+UY073KGqEh+HM48aoQ= Received: by 10.142.73.8 with SMTP id v8mr929251wfa.1192195140673; Fri, 12 Oct 2007 06:19:00 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Fri, 12 Oct 2007 06:19:00 -0700 (PDT) Message-ID: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> Date: Fri, 12 Oct 2007 15:19:00 +0200 From: "Pars Mutaf" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellular hosts) 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="===============0955155717==" Errors-To: sip-bounces@ietf.org --===============0955155717== Content-Type: multipart/alternative; boundary="----=_Part_21503_5576381.1192195140634" ------=_Part_21503_5576381.1192195140634 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Is the SIP trapezoid needed in cellular networks? This is a deployment question. The very simple logic of my question is as follows: For privacy reasons: - cellular users don't publish their SIP URIs in a phonebook. - unpredictable and long SIP URIs are recommended. Thus the SIP URI will be: n-random-characters@domainname which may be too long to read/type as we do today when two cell phone users meet each other? If so: Any solution is welcome (e.g. pairing) to help users exchange their SIP URIs easily. For example, user names are locally published, I choose the name of my friend in a wireless network, and get the SIP URI. If such solution exists: Why not use it also for exchanging a Mobile IPv6 home address. I.e., I get my friend's SIP URI and home address concurrently. [bonus result: we can establish IPsec since we already know our IP addresses]. Conclusion: By the basic SIP privacy requirement we also came to solving the routing problem. What I am missing? Thanks, pars ------=_Part_21503_5576381.1192195140634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

Is the SIP trapezoid needed in cellular networks?
This is a deployment question. The very simple logic
of my question is as follows:

For privacy reasons:
- cellular users don't publish their SIP URIs in a
  phonebook.
- unpredictable and long SIP URIs are recommended.

Thus the SIP URI will be:

       n-random-characters@domainname

which may be too long to read/type as we do
today when two cell phone users meet each other?

If so:
Any solution is welcome (e.g. pairing) to help
users exchange their SIP URIs easily. For example,
user names are locally published, I choose the name
of my friend in a wireless network, and get the SIP URI.

If such solution exists:
Why not use it also for exchanging a Mobile IPv6
home address. I.e., I get my friend's SIP URI and
home address concurrently. [bonus result: we can
establish IPsec since we already know our IP addresses].

Conclusion:
By the basic SIP privacy requirement we also came to
solving the routing problem.

What I am missing?

Thanks,
pars












------=_Part_21503_5576381.1192195140634-- --===============0955155717== 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 --===============0955155717==-- From sip-bounces@ietf.org Fri Oct 12 09:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKrR-0006dX-GR; Fri, 12 Oct 2007 09:47:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgKrO-0006dD-JA for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 09:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKrN-0006d2-Mo for sip@ietf.org; Fri, 12 Oct 2007 09:47:25 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgKrH-0005La-Eq for sip@ietf.org; Fri, 12 Oct 2007 09:47:25 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1IgKXk-0007cW-At; Fri, 12 Oct 2007 06:27:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Fri, 12 Oct 2007 06:27:12 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> In-Reply-To: <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgMPvxpYI9xWRQDQbmavNIVfix2kAAk1s8g References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> From: "Michael Procter" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > INFO, as written, lacks contextual negotiation. You're proposing to > replace the method name with NOTIFY and use the event-package > framework for content and context expression, using a header-field in > the INVITE request to engage context negotiation. It seems to me like > that would work. There's nothing "implicit" about it, and it is no > worse for overhead than using Supported or Allow. It also has the > advantage of letting us reuse an existing registration framework, > IANA process, and specification review process under RFC 3427. Very > tidy, I think I like it. One area that would need defining very carefully is the question of subscription usage lifetimes. Tying them to the lifetime of the invite usage that caused them sounds quite tidy, and would prevent a flurry of NOTIFY/state=3Dterminated messages straight after a BYE. No doubt there are scenarios when this is less than helpful though. Similarly, rules on if/when resubscription is necessary would need to be agreed, rather than leaving it to 'implementor's discretion'. Interestingly, I was thinking about a related problem recently and wondered if some sort of multi-event subscribe might help with the many-dialogs problem that some people are starting to see. Francois' approach gives a related solution in the scenario where there is a call dialog in existence between the relevant endpoints. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 11:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLxE-0007FK-2b; Fri, 12 Oct 2007 10:57:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgLxC-0007FF-27 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 10:57:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLxB-0007F6-Ne for sip@ietf.org; Fri, 12 Oct 2007 10:57:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLxB-0003oJ-Ah for sip@ietf.org; Fri, 12 Oct 2007 10:57:29 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188792000"; d="scan'208";a="134780796" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Oct 2007 10:57:28 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9CEvSNa001624; Fri, 12 Oct 2007 10:57:28 -0400 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 l9CEvFs5015714; Fri, 12 Oct 2007 14:57:28 GMT 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.1830); Fri, 12 Oct 2007 10:57:24 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 10:57:24 -0400 Message-ID: <470F8B54.1030506@cisco.com> Date: Fri, 12 Oct 2007 10:57:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellular hosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> In-Reply-To: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 14:57:24.0169 (UTC) FILETIME=[32A12B90:01C80CE0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--15.699700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2296; t=1192201048; x=1193065048; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SIP=20trapezoid=20(was=20Re=3A=20IETF=20solut ion=20for=20pairing=20cellular=0A=20hosts) |Sender:=20 |To:=20Pars=20Mutaf=20; bh=RJkD7sNGVMkYvmucRAwcjRut4tUD12jP2j+123SyG+I=; b=YDO9xx+TE1SQ+iLIboa7Jox3wuvMxnq/lPHS5S7HBlAXXBy6A68JVQUMDqVuGZ5vnNvG1UrK O72QDxdpbPP26snYA5uZ3swc9O3JCd09p/zrIv0XgeY00f5SBgUnm0Yz; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > Hello, > > Is the SIP trapezoid needed in cellular networks? > This is a deployment question. The very simple logic > of my question is as follows: > > For privacy reasons: > - cellular users don't publish their SIP URIs in a > phonebook. > - unpredictable and long SIP URIs are recommended. > > Thus the SIP URI will be: > > n-random-characters@domainname > > which may be too long to read/type as we do > today when two cell phone users meet each other? We may have a different usage model in mind. AFAIK cellular users are identified by their phone number, which is used for humman interchange of addresses all the time. When rendered as a URI, it can be a TEL URI, or a sip uri. When a sip URI it has a particular domain, which may not normally be known to the caller. But in that case they start with a TEL uri and it gets translated along the way - typically with ENUM. In any case it isn't the caller's concern. The mobile *device* has a different, contact, address. But callers are never expected to know that. It is the point of the sip trapezoid (actually just part of it - the home proxy) to do this translation. Paul > If so: > Any solution is welcome (e.g. pairing) to help > users exchange their SIP URIs easily. For example, > user names are locally published, I choose the name > of my friend in a wireless network, and get the SIP URI. > > If such solution exists: > Why not use it also for exchanging a Mobile IPv6 > home address. I.e., I get my friend's SIP URI and > home address concurrently. [bonus result: we can > establish IPsec since we already know our IP addresses]. > > Conclusion: > By the basic SIP privacy requirement we also came to > solving the routing problem. > > What I am missing? > > Thanks, > pars > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 11:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMCe-0005XA-Q6; Fri, 12 Oct 2007 11:13:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgMCd-0005Wg-Au for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 11:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMCc-0005WX-UN for sip@ietf.org; Fri, 12 Oct 2007 11:13:26 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgMCW-00016f-M9 for sip@ietf.org; Fri, 12 Oct 2007 11:13:26 -0400 Received: by wx-out-0506.google.com with SMTP id s8so850699wxc for ; Fri, 12 Oct 2007 08:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=2ZI32QIbvoUQxsenWGr66szM00OSwIp100a7K7Zhuwg=; b=sxOu6sTIei1UzNvhMBYnONHwEv4qTDXhAYDkFEoqhweIJZZ8KLOeorqoN8LVXkmFhJitww3wlltyCFkGZIP5xe83SJXi8HEu0gV91GJbNrKemfqFWDIEpIJGtyIr+X5NI4hJ/uzi3ke06HrSpjrlUP+WRE7E8D39alqTYfTBgHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JbVeY6D5sed/M1Eo9jJ6JEg+wuH4kpNMvnMsA4uLtNJtz8Sl2asbIbI81bmNmmWPt22phu/17+koAqvzSULOYQoI7rILNNs0y1xpLmlvG43f6MXL1GzKB+v7cmO1TvQ2yW+hk0AeTK6GDnu3GgjJnl7bfGV62TVVGp54Q5OD73c= Received: by 10.70.111.2 with SMTP id j2mr5314380wxc.1192201969239; Fri, 12 Oct 2007 08:12:49 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Fri, 12 Oct 2007 08:12:49 -0700 (PDT) Message-ID: <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> Date: Fri, 12 Oct 2007 17:12:49 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellular hosts) In-Reply-To: <470F8B54.1030506@cisco.com> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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: , Content-Type: multipart/mixed; boundary="===============0731361679==" Errors-To: sip-bounces@ietf.org --===============0731361679== Content-Type: multipart/alternative; boundary="----=_Part_22147_5495001.1192201969225" ------=_Part_22147_5495001.1192201969225 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, Paul Kyzivat wrote: > > > > Pars Mutaf wrote: > > Hello, > > > > Is the SIP trapezoid needed in cellular networks? > > This is a deployment question. The very simple logic > > of my question is as follows: > > > > For privacy reasons: > > - cellular users don't publish their SIP URIs in a > > phonebook. > > - unpredictable and long SIP URIs are recommended. > > > > Thus the SIP URI will be: > > > > n-random-characters@domainname > > > > which may be too long to read/type as we do > > today when two cell phone users meet each other? > > We may have a different usage model in mind. > > AFAIK cellular users are identified by their phone number, which is used > for humman interchange of addresses all the time. When rendered as a > URI, it can be a TEL URI, or a sip uri. When a sip URI it has a > particular domain, which may not normally be known to the caller. But in > that case they start with a TEL uri and it gets translated along the way > - typically with ENUM. In any case it isn't the caller's concern. > > The mobile *device* has a different, contact, address. But callers are > never expected to know that. It is the point of the sip trapezoid > (actually just part of it - the home proxy) to do this translation. In my simplistic view: I need my packets routed from my device to the other device. Mobile IPv6 home address does that (including location management, i.e. locating the target device when I make a call). I'm not saying that Mobile IPv6 home address corresponds to the telephone number. We still have a SIP URI for the SIP application. Thanks, pars Paul > > > If so: > > Any solution is welcome (e.g. pairing) to help > > users exchange their SIP URIs easily. For example, > > user names are locally published, I choose the name > > of my friend in a wireless network, and get the SIP URI. > > > > If such solution exists: > > Why not use it also for exchanging a Mobile IPv6 > > home address. I.e., I get my friend's SIP URI and > > home address concurrently. [bonus result: we can > > establish IPsec since we already know our IP addresses]. > > > > Conclusion: > > By the basic SIP privacy requirement we also came to > > solving the routing problem. > > > > What I am missing? > > > > Thanks, > > pars > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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_22147_5495001.1192201969225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/12/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Pars Mutaf wrote:
> Hello,
>
> Is the SIP trapezoid needed in cellular networks?
> This is a deployment question. The very simple logic
> of my question is as follows:
>
> For privacy reasons:
> - cellular users don't publish their SIP URIs in a
>   phonebook.
> - unpredictable and long SIP URIs are recommended.
>
> Thus the SIP URI will be:
>
>        n-random-characters@domainname
>
> which may be too long to read/type as we do
> today when two cell phone users meet each other?

We may have a different usage model in mind.

AFAIK cellular users are identified by their phone number, which is used
for humman interchange of addresses all the time. When rendered as a
URI, it can be a TEL URI, or a sip uri. When a sip URI it has a
particular domain, which may not normally be known to the caller. But in
that case they start with a TEL uri and it gets translated along the way
- typically with ENUM. In any case it isn't the caller's concern.

The mobile *device* has a different, contact, address. But callers are
never expected to know that. It is the point of the sip trapezoid
(actually just part of it - the home proxy) to do this translation.


In my simplistic view:
I need my packets routed from my device to the other device.
Mobile IPv6 home address does that (including location
management, i.e. locating the target device when I make a call).

I'm not saying that Mobile IPv6 home address corresponds to the
telephone number. We still have a SIP URI for the SIP application.

Thanks,
pars


 

        Paul

> If so:
> Any solution is welcome ( e.g. pairing) to help
> users exchange their SIP URIs easily. For example,
> user names are locally published, I choose the name
> of my friend in a wireless network, and get the SIP URI.
>
> If such solution exists:
> Why not use it also for exchanging a Mobile IPv6
> home address. I.e., I get my friend's SIP URI and
> home address concurrently. [bonus result: we can
> establish IPsec since we already know our IP addresses].
>
> Conclusion:
> By the basic SIP privacy requirement we also came to
> solving the routing problem.
>
> What I am missing?
>
> Thanks,
> pars
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_22147_5495001.1192201969225-- --===============0731361679== 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 --===============0731361679==-- From sip-bounces@ietf.org Fri Oct 12 11:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMnC-0001SG-OZ; Fri, 12 Oct 2007 11:51:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgMnA-0001QI-Jw for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 11:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMnA-0001Q8-AI for sip@ietf.org; Fri, 12 Oct 2007 11:51:12 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgMn5-0002dr-4X for sip@ietf.org; Fri, 12 Oct 2007 11:51:12 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l9CFmHe28708; Fri, 12 Oct 2007 15:48:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Date: Fri, 12 Oct 2007 09:50:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> In-Reply-To: <1192172786.17547.19.camel@n85.nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Index: AcgMnnBB28HK/WmUR+6VZU1wo+wntwAQKkaw References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> From: "Francois Audet" To: "Salvatore Loreto" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > the proposal is interesting.=20 > However there should be cases where you need to send whatever=20 > information in both directions, or cases where when you send=20 > an information via Notify you need to receive back some=20 > information (e.g. > the fact that you receive a 200Ok as answer to the Notify it=20 > is not enough). > How do you think your proposal should work in those cases ?=20 > perhaps with > 2 subscription one in each direction?=20 Yes. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 12:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgN5N-0000vt-24; Fri, 12 Oct 2007 12:10:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgN5L-0000sK-JH for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 12:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgN5L-0000s8-9X for sip@ietf.org; Fri, 12 Oct 2007 12:09:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgN5K-0003VV-2E for sip@ietf.org; Fri, 12 Oct 2007 12:09:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188792000"; d="scan'208";a="73917193" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2007 12:09:45 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CG9kIo020087; Fri, 12 Oct 2007 12:09:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9CG9hrS013728; Fri, 12 Oct 2007 16:09:45 GMT 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.1830); Fri, 12 Oct 2007 12:09:43 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:09:43 -0400 Message-ID: <470F9C47.4040702@cisco.com> Date: Fri, 12 Oct 2007 12:09:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellular hosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> In-Reply-To: <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 16:09:43.0422 (UTC) FILETIME=[4D06A1E0:01C80CEA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--18.815400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3793; t=1192205386; x=1193069386; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SIP=20trapezoid=20(was=20Re=3A=20IETF=20solut ion=20for=20pairing=20cellular=0A=20hosts) |Sender:=20 |To:=20Pars=20Mutaf=20; bh=PAuWaP7eFlM3tsq78e6pFL3bAmnhyQSjPmxA8xcsyN4=; b=lADMmN4kyhqde0Ds4ORGtwZJXiL+qof7lns8MMPfO8QaUZwX44qX5x0dZd7SZVDL0wQzZKDf 7gHuewqNmpPgAzPGRMINLJENbTUIjZEcmS1keZC8V5Vjb+KHy7VCv5go; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > > > On 10/12/07, *Paul Kyzivat* > wrote: > > > > Pars Mutaf wrote: > > Hello, > > > > Is the SIP trapezoid needed in cellular networks? > > This is a deployment question. The very simple logic > > of my question is as follows: > > > > For privacy reasons: > > - cellular users don't publish their SIP URIs in a > > phonebook. > > - unpredictable and long SIP URIs are recommended. > > > > Thus the SIP URI will be: > > > > n-random-characters@domainname > > > > which may be too long to read/type as we do > > today when two cell phone users meet each other? > > We may have a different usage model in mind. > > AFAIK cellular users are identified by their phone number, which is > used > for humman interchange of addresses all the time. When rendered as a > URI, it can be a TEL URI, or a sip uri. When a sip URI it has a > particular domain, which may not normally be known to the caller. But in > that case they start with a TEL uri and it gets translated along the > way > - typically with ENUM. In any case it isn't the caller's concern. > > The mobile *device* has a different, contact, address. But callers are > never expected to know that. It is the point of the sip trapezoid > (actually just part of it - the home proxy) to do this translation. > > > > In my simplistic view: > I need my packets routed from my device to the other device. > Mobile IPv6 home address does that (including location > management, i.e. locating the target device when I make a call). > > I'm not saying that Mobile IPv6 home address corresponds to the > telephone number. We still have a SIP URI for the SIP application. Then I don't understand what problem you are trying to solve. If you wish to communicate with me via SIP then you should be trying to discover my Address of Record (AoR - either a SIP or possibly a TEL URI). The sip infrastructure will take care of routing to the device. AoRs will typically be user friendly to the same extent that email addresses or phone numbers are. Paul > Thanks, > pars > > > > > Paul > > > If so: > > Any solution is welcome ( e.g. pairing) to help > > users exchange their SIP URIs easily. For example, > > user names are locally published, I choose the name > > of my friend in a wireless network, and get the SIP URI. > > > > If such solution exists: > > Why not use it also for exchanging a Mobile IPv6 > > home address. I.e., I get my friend's SIP URI and > > home address concurrently. [bonus result: we can > > establish IPsec since we already know our IP addresses]. > > > > Conclusion: > > By the basic SIP privacy requirement we also came to > > solving the routing problem. > > > > What I am missing? > > > > Thanks, > > pars > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu > for questions on current sip > > Use sipping@ietf.org for new > developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 12:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNc1-000830-3E; Fri, 12 Oct 2007 12:43:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgNbz-00082k-OR for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 12:43:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNbz-00082F-DV for sip@ietf.org; Fri, 12 Oct 2007 12:43:43 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgNby-0007vX-TG for sip@ietf.org; Fri, 12 Oct 2007 12:43:43 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9CGhdG10937; Fri, 12 Oct 2007 16:43:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Date: Fri, 12 Oct 2007 11:32:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1274760A@zrc2hxm0.corp.nortel.com> In-Reply-To: <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Index: AcgMPuauyoGg8vVeSIadbk1hzW264QAqpRFg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> From: "Brian Stucker" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, October 11, 2007 2:32 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List; Christer Holmberg > Subject: [Sip] Francois' counter to INFO (was Re: What are we=20 > arguing about when we say INFO?) >=20 >=20 > On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: >=20 > > Hi Dean, > > > > Can you tell me what is the difference between=20 > "contextually-adapted=20 > > INFO", and a "subscription embedded in the INVITE, with the NOTIFY=20 > > using the same dialog"? I don't see any advantage to the INFO=20 > > approach. > > >=20 > One might argue that the second is a means of implementing the first. >=20 > INFO, as written, lacks contextual negotiation. You're=20 > proposing to replace the method name with NOTIFY and use the=20 > event-package framework for content and context expression,=20 > using a header-field in the INVITE request to engage context=20 > negotiation. It seems to me like that would work. There's=20 > nothing "implicit" about it, and it is no worse for overhead=20 > than using Supported or Allow. It also has the advantage of=20 > letting us reuse an existing registration framework, IANA=20 > process, and specification review process under RFC 3427.=20 > Very tidy, I think I like it. I'm missing something here. When I send a SUBSCRIBE I'm saying the following, "For the resource identified by the request-URI, I'd like to synchronize with a particular state machine for X seconds with the state data encoded in format Y." The other end can accept or reject the request as a whole, there is no offer/answer negotiation going on. If we were to trigger a subscription based upon the INVITE that takes care of targeting the resource and the duration of interest and leaves out identifying the particular state machine you want to synchronize with and how you want to encode the state data. Can't I identify the state machine I want to synchronize with using a supported header and the encoding using the accept header, specifying the pair-values that are legal in an IETF document? Isn't this what RFC-3312 did, and although integrated differently into the protocol because the state machine being synchronized was SIP itself what RFC-3262 does? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 12 12:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNdd-000097-53; Fri, 12 Oct 2007 12:45:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgNdb-00008r-0G for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 12:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNda-00008h-N1 for sip@ietf.org; Fri, 12 Oct 2007 12:45:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgNdU-0004lB-Ge for sip@ietf.org; Fri, 12 Oct 2007 12:45:22 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9CGj67a013863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Oct 2007 11:45:07 -0500 In-Reply-To: <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Fri, 12 Oct 2007 11:45:00 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 11, 2007, at 6:54 PM, DRAGE, Keith ((Keith)) wrote: > There is one major downside to this. > > If we are sending stuff in the dialog, it really ought to have some > relation to the dialog, not just be included there because the dialog > happened to exist.....then you end up with people wanting to route the > dialog to a centralised point where you can extract this piggy-backed > information ... Then you end up with a stimulus protocol between > this UE > and this centralised server where the dialog contains absolutely no > knowledge of the state of the session. > > Providing an in dialog mechanism makes it much harder to to stop this > happening. That's back to the question of "Is SIP an application protocol or a transport protocol"? Should the SIP-layer software be aware of and coupled to the state of the application that's using SIP? If so, then the proper design model is to build a new SIP request method for every new piece of application functionality. So for example, DTMF: Using this model of SIP extension, we might define a new "DTMF" method. It would look just like DTMF-over-INFO, except the name of the method would be DTMF. It clearly resolves the INFO-context question, because now we KNOW we're getting dialog- related DTMF over it, and we know what to do with it. We know what we can transport in DTMF-requests, because the RFC that defines the DTMF extension method will also define exactly what payload format to use. This too is a clean solution to the problem, although it embodies a different design philosophy than the same-dialog NOTIFY. This leads back to my question: What is the right extension modality for SIP? Until we have an answer here, we're going to keep going back and forth on this. MAKE A DECISION, PEOPLE! Now for the bad news: People are still having this argument about HTTP (we had it during XCAP in the GET/PUT vs POST debate) even though the real world has proven dramatically by example that HTTP is a transport protocol and is protocol-wise completely decoupled from the state of the application (see AJAX as an example). -- 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 12 12:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNjy-00058a-Hq; Fri, 12 Oct 2007 12:51:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgNjx-00057L-5R for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 12:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNjw-00051f-S4 for sip@ietf.org; Fri, 12 Oct 2007 12:51:56 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgNjp-0004xZ-HP for sip@ietf.org; Fri, 12 Oct 2007 12:51:50 -0400 Received: by wx-out-0506.google.com with SMTP id s8so872899wxc for ; Fri, 12 Oct 2007 09:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=534v/p+dcb4lhnaD8pDUI2smm/wSUEKt2bjYIflTppo=; b=nepY3NSAiPOZSe2wrlwd3E1CLON8z3puWReOWM8HCbT65C9ULtdb9yvbTMPoFMfu/Rxf6MsOR0R6J8jHDXIXDV1IUWhTjiv5bnk99xiVrzU336pakUAGDel/1td5Q41GJajGCkxMT84IgGtF3yO/ZX/N1+8uDM5TXMDwSBT3lDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=SmdxhM8VdM072F/NHFNqifsRvUjACVn0TGLX2ZvP4uJEpqmlZdl9Xj5CCQNiEvswEMyowvcgHA5TnKQXz3YPP512CFD2Eo/sDiqOYSk4JQl/R7kfc1I0+c4K37wYkzqZB4Yp4tUUxkWJD/xpQGIoXsBmRnOB/ShiO4AtnS983pg= Received: by 10.70.7.4 with SMTP id 4mr5430787wxg.1192207861975; Fri, 12 Oct 2007 09:51:01 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Fri, 12 Oct 2007 09:51:01 -0700 (PDT) Message-ID: <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> Date: Fri, 12 Oct 2007 18:51:01 +0200 From: "Pars Mutaf" To: "Paul Kyzivat" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellular hosts) In-Reply-To: <470F9C47.4040702@cisco.com> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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: , Content-Type: multipart/mixed; boundary="===============1060279167==" Errors-To: sip-bounces@ietf.org --===============1060279167== Content-Type: multipart/alternative; boundary="----=_Part_23182_28204228.1192207861968" ------=_Part_23182_28204228.1192207861968 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, Paul Kyzivat wrote: > > > > Pars Mutaf wrote: > > > > > > On 10/12/07, *Paul Kyzivat* > > wrote: > > > > > > > > Pars Mutaf wrote: > > > Hello, > > > > > > Is the SIP trapezoid needed in cellular networks? > > > This is a deployment question. The very simple logic > > > of my question is as follows: > > > > > > For privacy reasons: > > > - cellular users don't publish their SIP URIs in a > > > phonebook. > > > - unpredictable and long SIP URIs are recommended. > > > > > > Thus the SIP URI will be: > > > > > > n-random-characters@domainname > > > > > > which may be too long to read/type as we do > > > today when two cell phone users meet each other? > > > > We may have a different usage model in mind. > > > > AFAIK cellular users are identified by their phone number, which is > > used > > for humman interchange of addresses all the time. When rendered as a > > URI, it can be a TEL URI, or a sip uri. When a sip URI it has a > > particular domain, which may not normally be known to the caller. > But in > > that case they start with a TEL uri and it gets translated along the > > way > > - typically with ENUM. In any case it isn't the caller's concern. > > > > The mobile *device* has a different, contact, address. But callers > are > > never expected to know that. It is the point of the sip trapezoid > > (actually just part of it - the home proxy) to do this translation. > > > > > > > > In my simplistic view: > > I need my packets routed from my device to the other device. > > Mobile IPv6 home address does that (including location > > management, i.e. locating the target device when I make a call). > > > > I'm not saying that Mobile IPv6 home address corresponds to the > > telephone number. We still have a SIP URI for the SIP application. > > Then I don't understand what problem you are trying to solve. > > If you wish to communicate with me via SIP then you should be trying to > discover my Address of Record (AoR - either a SIP or possibly a TEL > URI). The privacy problem: normally I shouldn't be able to discover your SIP URI. Then, we turn back to my initial question in this thread: (really sorry I couldn't make it shorter!) http://www1.ietf.org/mail-archive/web/sip/current/msg20730.html Thanks! pars The sip infrastructure will take care of routing to the device. > AoRs will typically be user friendly to the same extent that email > addresses or phone numbers are. > > Paul > > > Thanks, > > pars > > > > > > > > > > Paul > > > > > If so: > > > Any solution is welcome ( e.g. pairing) to help > > > users exchange their SIP URIs easily. For example, > > > user names are locally published, I choose the name > > > of my friend in a wireless network, and get the SIP URI. > > > > > > If such solution exists: > > > Why not use it also for exchanging a Mobile IPv6 > > > home address. I.e., I get my friend's SIP URI and > > > home address concurrently. [bonus result: we can > > > establish IPsec since we already know our IP addresses]. > > > > > > Conclusion: > > > By the basic SIP privacy requirement we also came to > > > solving the routing problem. > > > > > > What I am missing? > > > > > > Thanks, > > > pars > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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_23182_28204228.1192207861968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/12/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Pars Mutaf wrote:
>
>
> On 10/12/07, *Paul Kyzivat* <pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>> wrote:
>
>
>
>     Pars Mutaf wrote:
>      > Hello,
>      >
>      > Is the SIP trapezoid needed in cellular networks?
>      > This is a deployment question. The very simple logic
>      > of my question is as follows:
>      >
>      > For privacy reasons:
>      > - cellular users don't publish their SIP URIs in a
>      >   phonebook.
>      > - unpredictable and long SIP URIs are recommended.
>      >
>      > Thus the SIP URI will be:
>      >
>      >        n-random-characters@domainname
>      >
>      > which may be too long to read/type as we do
>      > today when two cell phone users meet each other?
>
>     We may have a different usage model in mind.
>
>     AFAIK cellular users are identified by their phone number, which is
>     used
>     for humman interchange of addresses all the time. When rendered as a
>     URI, it can be a TEL URI, or a sip uri. When a sip URI it has a
>     particular domain, which may not normally be known to the caller. But in
>     that case they start with a TEL uri and it gets translated along the
>     way
>     - typically with ENUM. In any case it isn't the caller's concern.
>
>     The mobile *device* has a different, contact, address. But callers are
>     never expected to know that. It is the point of the sip trapezoid
>     (actually just part of it - the home proxy) to do this translation.
>
>
>
> In my simplistic view:
> I need my packets routed from my device to the other device.
> Mobile IPv6 home address does that (including location
> management, i.e. locating the target device when I make a call).
>
> I'm not saying that Mobile IPv6 home address corresponds to the
> telephone number. We still have a SIP URI for the SIP application.

Then I don't understand what problem you are trying to solve.

If you wish to communicate with me via SIP then you should be trying to
discover my Address of Record (AoR - either a SIP or possibly a TEL
URI).

The privacy problem: normally I shouldn't be able to discover
your SIP URI.

Then, we turn back to my initial question in this thread:
(really sorry I couldn't make it shorter!)

http://www1.ietf.org/mail-archive/web/sip/current/msg20730.html
 

Thanks!
pars




The sip infrastructure will take care of routing to the device.
AoRs will typically be user friendly to the same extent that email
addresses or phone numbers are.

        Paul

> Thanks,
> pars
>
>
>
>
>             Paul
>
>      > If so:
>      > Any solution is welcome ( e.g. pairing) to help
>      > users exchange their SIP URIs easily. For example,
>      > user names are locally published, I choose the name
>      > of my friend in a wireless network, and get the SIP URI.
>      >
>      > If such solution exists:
>      > Why not use it also for exchanging a Mobile IPv6
>      > home address. I.e., I get my friend's SIP URI and
>      > home address concurrently. [bonus result: we can
>      > establish IPsec since we already know our IP addresses].
>      >
>      > Conclusion:
>      > By the basic SIP privacy requirement we also came to
>      > solving the routing problem.
>      >
>      > What I am missing?
>      >
>      > Thanks,
>      > pars
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>      > This list is for NEW development of the core SIP Protocol
>      > Use sip-implementors@cs.columbia.edu
>     <mailto:sip-implementors@cs.columbia.edu> for questions on current sip
>      > Use sipping@ietf.org <mailto:sipping@ietf.org> for new
>     developments on the application of sip
>
>

------=_Part_23182_28204228.1192207861968-- --===============1060279167== 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 --===============1060279167==-- From sip-bounces@ietf.org Fri Oct 12 13:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNvL-0006hW-Rm; Fri, 12 Oct 2007 13:03:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgNvK-0006hK-9b for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNvJ-0006dO-W3 for sip@ietf.org; Fri, 12 Oct 2007 13:03:41 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgNv4-0005Nv-WF for sip@ietf.org; Fri, 12 Oct 2007 13:03:33 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l9CH0Be27101; Fri, 12 Oct 2007 17:00:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Fri, 12 Oct 2007 12:02:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM7/gCjvEyEC/iQVeVRwn9WYcVPwAAQGXQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> From: "Brian Stucker" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, October 12, 2007 11:45 AM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List; Audet, Francois (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > On Oct 11, 2007, at 6:54 PM, DRAGE, Keith ((Keith)) wrote: >=20 > > There is one major downside to this. > > > > If we are sending stuff in the dialog, it really ought to have some=20 > > relation to the dialog, not just be included there because=20 > the dialog=20 > > happened to exist.....then you end up with people wanting=20 > to route the=20 > > dialog to a centralised point where you can extract this=20 > piggy-backed=20 > > information ... Then you end up with a stimulus protocol=20 > between this=20 > > UE and this centralised server where the dialog contains=20 > absolutely no=20 > > knowledge of the state of the session. > > > > Providing an in dialog mechanism makes it much harder to to=20 > stop this=20 > > happening. >=20 > That's back to the question of "Is SIP an application=20 > protocol or a transport protocol"? >=20 > Should the SIP-layer software be aware of and coupled to the=20 > state of the application that's using SIP? >=20 > If so, then the proper design model is to build a new SIP=20 > request method for every new piece of application functionality. You forgot about supported. >=20 > So for example, DTMF: Using this model of SIP extension, we=20 > might define a new "DTMF" method. It would look just like=20 > DTMF-over-INFO, except the name of the method would be DTMF.=20 > It clearly resolves the INFO-context question, because now we=20 > KNOW we're getting dialog- related DTMF over it, and we know=20 > what to do with it. We know what we can transport in=20 > DTMF-requests, because the RFC that defines the DTMF=20 > extension method will also define exactly what payload format to use. INVITE Supported: foo Allow: INFO Accept: application/foo 200 OK Supported: foo Allow: INFO Accept: application/foo ... INFO Content-Type: application/foo [DTMF] Where is this broken? >=20 > This too is a clean solution to the problem, although it=20 > embodies a different design philosophy than the same-dialog NOTIFY. >=20 > This leads back to my question: What is the right extension=20 > modality for SIP? Until we have an answer here, we're going=20 > to keep going back and forth on this. MAKE A DECISION, PEOPLE! You can't feasibly make a clean one. There will always be SDP vs. non-SDP extension modalities. >=20 > Now for the bad news: People are still having this argument=20 > about HTTP (we had it during XCAP in the GET/PUT vs POST=20 > debate) even though the real world has proven dramatically by=20 > example that HTTP is a transport protocol and is=20 > protocol-wise completely decoupled from the state of the=20 > application (see AJAX as an example). >=20 > -- > Dean >=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 Fri Oct 12 13:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgO69-0002yh-Vc; Fri, 12 Oct 2007 13:14:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgO68-0002ya-Af for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgO68-0002wu-1C for sip@ietf.org; Fri, 12 Oct 2007 13:14:52 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgO5y-0005of-NK for sip@ietf.org; Fri, 12 Oct 2007 13:14:48 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPT009S76JIGY@usaga01-in.huawei.com> for sip@ietf.org; Fri, 12 Oct 2007 10:14:06 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPT00C0E6JHY1@usaga01-in.huawei.com> for sip@ietf.org; Fri, 12 Oct 2007 10:14:06 -0700 (PDT) Date: Fri, 12 Oct 2007 12:13:29 -0500 From: Spencer Dawkins Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) To: sip@ietf.org Message-id: <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: sip-bounces@ietf.org > The privacy problem: normally I shouldn't be able to discover your SIP URI. I'm guessing that if you can't tell people your SIP AOR, then SIP is not for you. Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 13:48:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOZ4-0003A4-JG; Fri, 12 Oct 2007 13:44:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgOZ3-00037E-4u for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOZ2-0002z7-Ra for sip@ietf.org; Fri, 12 Oct 2007 13:44:44 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOYs-0006hh-L1 for sip@ietf.org; Fri, 12 Oct 2007 13:44:40 -0400 Received: by wx-out-0506.google.com with SMTP id s8so883975wxc for ; Fri, 12 Oct 2007 10:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=8dFgcqbb9CoiJfcom+bqHmDZGjfMhf03gf8nei0p6jI=; b=CQaXTVkDdMZTTa3Vj7Yx0mQ1gEZXJek/eJ0P54/Vc3aCoYQhqw/El7eRcDNQ4ToyL6Zp6PyTFYA3/InMm5DMomw7dgN0IzYV4OIq1kgny7Z2D6MnQID3D6gZeaYLQV1Ada9SOs2toCUcfi+/QuB9k447IpdtSE3Uk3d+JfnfvS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LEPwTM7bThrrGqXJDv9+x/+tsACoxQds5YJARRR+6JvzMYe7P8JTSPjc25MKOjb1eDeaxH24SPcd2sTcIn7FsgI/BLJmV/kvgfD+ntTgdKq+KHVQUoLbBpnlajDssYJZRYrFQyZnWKJqbQo2S91wW126O2VS4SlJ5JkbnGvVz0I= Received: by 10.70.30.7 with SMTP id d7mr5535259wxd.1192211033848; Fri, 12 Oct 2007 10:43:53 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Fri, 12 Oct 2007 10:43:53 -0700 (PDT) Message-ID: <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> Date: Fri, 12 Oct 2007 19:43:53 +0200 From: "Pars Mutaf" To: "Spencer Dawkins" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) In-Reply-To: <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Content-Type: multipart/mixed; boundary="===============0823229361==" Errors-To: sip-bounces@ietf.org --===============0823229361== Content-Type: multipart/alternative; boundary="----=_Part_23559_21825554.1192211033835" ------=_Part_23559_21825554.1192211033835 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, Spencer Dawkins wrote: > > > The privacy problem: normally I shouldn't be able to discover > your SIP URI. > > I'm guessing that if you can't tell people your SIP AOR, then SIP is not > for > you. Hello, I won't publish my SIP URI in a phone book allowing anyone to see it. We already agreed on that. I'll tell it to people that I know only. I'll tell it using a user friendly mechanism called "pairing" : We meet each other with our cell phones, and agree to exchange our contact information. So, the procedure is under our control. Pairing is good for us also because it allows us to exchange a secret key (note that this is already enough motivation for the pairing idea). The point is that, if I give you my SIP URI (using the pairing procedure) then I can also give you my Mobile IPv6 home address using the same pairing procedure. In other words, there is _no more resolution_ from SIP URI to home IP address. You get them **concurrently**. We have each other's SIP URIs and home addresses. ->SIP application is happy, it has the target SIP URI. ->Routing problem is solved by mobile IPv6. My question was: do we need the SIP trapezoid in this case. Thanks, pars Thanks, > > Spencer > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_23559_21825554.1192211033835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/12/07, Spencer Dawkins <spencer@mcsr-labs.org> wrote:
> The privacy problem: normally I shouldn't be able to discover
your SIP URI.

I'm guessing that if you can't tell people your SIP AOR, then SIP is not for
you.

Hello,

I won't publish my SIP URI in a phone book allowing anyone to see it.
We already agreed on that.

I'll tell it to people that I know only. I'll tell it using a user friendly
mechanism called "pairing" : We meet each other with our cell phones,
and agree to exchange our contact information. So, the procedure is
under our control. Pairing is good for us also because it allows us to
exchange a secret key (note that this is already enough motivation for
the pairing idea).

The point is that, if I give you my SIP URI (using the pairing procedure)
then I can also give you my Mobile IPv6 home address using the same
pairing procedure. In other words, there is _no more resolution_ from
SIP URI to home IP address. You get them **concurrently**.

We have each other's SIP URIs and home addresses.
->SIP application is happy, it has the target SIP URI.
->Routing problem is solved by mobile IPv6.

My question was: do we need the SIP trapezoid in this case.

Thanks,
pars




 

Thanks,

Spencer




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_23559_21825554.1192211033835-- --===============0823229361== 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 --===============0823229361==-- From sip-bounces@ietf.org Fri Oct 12 14:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOku-0002i4-29; Fri, 12 Oct 2007 13:57:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgOks-0002hy-Ec for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:56:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOks-0002hq-3s for sip@ietf.org; Fri, 12 Oct 2007 13:56:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgOkr-0001iZ-PM for sip@ietf.org; Fri, 12 Oct 2007 13:56:58 -0400 X-IronPort-AV: E=Sophos;i="4.21,267,1188792000"; d="scan'208";a="73928286" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2007 13:56:56 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9CHutcr005375; Fri, 12 Oct 2007 13:56:55 -0400 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 l9CHuYs9023405; Fri, 12 Oct 2007 17:56:50 GMT 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.1830); Fri, 12 Oct 2007 13:56:44 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 13:56:44 -0400 Message-ID: <470FB55E.2070909@cisco.com> Date: Fri, 12 Oct 2007 13:56:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 17:56:44.0427 (UTC) FILETIME=[403E3DB0:01C80CF9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--18.456600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1449; t=1192211815; x=1193075815; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20What=20are=20we=20arguing=20about=20when=20we=20say=2 0INFO?=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20 |To:=20Brian=20Stucker=20; bh=0qra693OOvVcD6Kx1M79iqnlAW1lEOjqdxDu9WOIEW8=; b=kXg+fD/2nOFrNpviIduf3w84he0MV1fadeRxcuDRTENQmepuUsE3bRsxkh0QRRt1ONex6IUC 5/Zoh1QZpPgY2bdljh4WuTgPQw1ETzRy6j4/xw9A28fgEUzSb1cCJUeP; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List , Francois Audet , Christer Holmberg , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > You forgot about supported. > >> So for example, DTMF: Using this model of SIP extension, we >> might define a new "DTMF" method. It would look just like >> DTMF-over-INFO, except the name of the method would be DTMF. >> It clearly resolves the INFO-context question, because now we >> KNOW we're getting dialog- related DTMF over it, and we know >> what to do with it. We know what we can transport in >> DTMF-requests, because the RFC that defines the DTMF >> extension method will also define exactly what payload format to use. > > INVITE > Supported: foo > Allow: INFO > Accept: application/foo > > 200 OK > Supported: foo > Allow: INFO > Accept: application/foo > > ... > > INFO > Content-Type: application/foo > [DTMF] > > > Where is this broken? This can work if there is an RFC defining the foo option that specifies that when both parties support foo then: - the UAC may use INFO to send information using Content-Type application/foo and Content-Disposition: (TBD) - the circumstances triggering the UAC to send are ... - the expected actions of the UAS upon receiving are ... Because this uses an option, and a new option can only be defined via an RFC, this technique is only available (legally) when an RFC will be approved. (Of course people have been known to invent new options without an RFC, but that is non-conforming 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 12 14:24:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP7F-0004p8-57; Fri, 12 Oct 2007 14:20:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgP7D-0004ni-6M for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:20:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP7C-0004fb-RD for sip@ietf.org; Fri, 12 Oct 2007 14:20:02 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgP78-0002Gw-3k for sip@ietf.org; Fri, 12 Oct 2007 14:19:58 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Oct 2007 14:19:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Fri, 12 Oct 2007 14:19:49 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F01816D0B@MAIL02.cedarpointcom.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM7/gCjvEyEC/iQVeVRwn9WYcVPwAAQGXQAAHYyBA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com>!! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3-97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> From: "Sumit Garg" To: "Brian Stucker" , "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 12 Oct 2007 18:19:50.0183 (UTC) FILETIME=[7A37D370:01C80CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Agreed. Basically there can be 3 scenario: 1. A---------------C (the signaling and media path ) --->2833 is best. 2. A---------------B (the signaling and media path )=20 C which is a proxy, and in neither path needs the DTMF (SUBSCRIBE/NOTIFY is best) 3. A---------------C------------B (signaling path) A--------------------B (media path) C needs the DTMF events, cannot use 2833 and SUBSCRIBE/NOTIFY is okay but not necessarily the best approach due to the overhead of additional dialogs (whose duration is tightly linked to the INVITE dialog). INFO definitely looks attractive here. Similarly, the recent draft on rtcp-summary defines a complex SUBCRIBE/NOTIFY mechanism, which again covers all scenarios gracefully. However, for scenario 1 and 3 some other mechanism would be better. I see the need for being able to implicitly SUBSCRIBE for certain events in the INVITE/200 OK itself. Whether we get those notifications in an INFO or a NOTIFY does not matter that much. I could even use the RTCP summary if it was in the BYE/200 (where it logically belongs). -Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Brian Stucker [mailto:bstucker@nortel.com]=20 Sent: Friday, October 12, 2007 1:03 PM To: Dean Willis; DRAGE, Keith (Keith) Cc: IETF SIP List; Francois Audet; Christer Holmberg Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 12, 2007 11:45 AM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List; Audet, Francois (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) >=20 >=20 > On Oct 11, 2007, at 6:54 PM, DRAGE, Keith ((Keith)) wrote: >=20 > > There is one major downside to this. > > > > If we are sending stuff in the dialog, it really ought to have some=20 > > relation to the dialog, not just be included there because > the dialog > > happened to exist.....then you end up with people wanting > to route the > > dialog to a centralised point where you can extract this > piggy-backed > > information ... Then you end up with a stimulus protocol > between this > > UE and this centralised server where the dialog contains > absolutely no > > knowledge of the state of the session. > > > > Providing an in dialog mechanism makes it much harder to to > stop this > > happening. >=20 > That's back to the question of "Is SIP an application protocol or a=20 > transport protocol"? >=20 > Should the SIP-layer software be aware of and coupled to the state of=20 > the application that's using SIP? >=20 > If so, then the proper design model is to build a new SIP request=20 > method for every new piece of application functionality. You forgot about supported. >=20 > So for example, DTMF: Using this model of SIP extension, we might=20 > define a new "DTMF" method. It would look just like DTMF-over-INFO,=20 > except the name of the method would be DTMF. > It clearly resolves the INFO-context question, because now we KNOW=20 > we're getting dialog- related DTMF over it, and we know what to do=20 > with it. We know what we can transport in DTMF-requests, because the=20 > RFC that defines the DTMF extension method will also define exactly=20 > what payload format to use. INVITE Supported: foo Allow: INFO Accept: application/foo 200 OK Supported: foo Allow: INFO Accept: application/foo ... INFO Content-Type: application/foo [DTMF] Where is this broken? >=20 > This too is a clean solution to the problem, although it embodies a=20 > different design philosophy than the same-dialog NOTIFY. >=20 > This leads back to my question: What is the right extension modality=20 > for SIP? Until we have an answer here, we're going to keep going back=20 > and forth on this. MAKE A DECISION, PEOPLE! You can't feasibly make a clean one. There will always be SDP vs. non-SDP extension modalities. >=20 > Now for the bad news: People are still having this argument about HTTP > (we had it during XCAP in the GET/PUT vs POST > debate) even though the real world has proven dramatically by example=20 > that HTTP is a transport protocol and is protocol-wise completely=20 > decoupled from the state of the application (see AJAX as an example). >=20 > -- > Dean >=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 Use=20 > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 14:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPJu-0007g6-8x; Fri, 12 Oct 2007 14:33:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgPJs-0007fz-C9 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:33:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPJr-0007JZ-Vs for sip@ietf.org; Fri, 12 Oct 2007 14:33:08 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgPJd-0002bM-IM for sip@ietf.org; Fri, 12 Oct 2007 14:32:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20071012183252m1200cmq65e>; Fri, 12 Oct 2007 18:32:52 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9CIWp29024443 for ; Fri, 12 Oct 2007 14:32:51 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9CIWp6Y024439; Fri, 12 Oct 2007 14:32:51 -0400 Date: Fri, 12 Oct 2007 14:32:51 -0400 Message-Id: <200710121832.l9CIWp6Y024439@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> (pars.mutaf@gmail.com) Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: sip-bounces@ietf.org From: "Pars Mutaf" I won't publish my SIP URI in a phone book allowing anyone to see it. We already agreed on that. I'll tell it to people that I know only. I'll tell it using a user friendly mechanism called "pairing" : We meet each other with our cell phones, and agree to exchange our contact information. So, the procedure is under our control. Pairing is good for us also because it allows us to exchange a secret key (note that this is already enough motivation for the pairing idea). So your usage model is that you will only want to communicate with people that you already know, and in most cases, have personally met. This means that you have no need of a directory, as your SIP device will be used to remember the URI of every person that you can call. Note that this is much like how many mobile phone users use their mobiles, but the opposite of the normal model of landline telephones, where it is expected that the public can discover and contact you. My question was: do we need the SIP trapezoid in this case. If you assume that each mobile has a fixed IPv6 address, then the address-based URI will always reach the mobile. And in that case, you don't need a home proxy that translates an AOR into a contact URI -- in effect, that translation process has been moved down into the network layer by the process of routing to that IPv6 address. But it seems unlikely that an individual will have a fixed IPv6 address over the long term. For one, it seems unlikely that *every* network will provide uniform IPv6 mobility. For another, what if the user replaces his mobile? 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 12 14:37:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPN5-0003UD-PR; Fri, 12 Oct 2007 14:36:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgPN4-0003U3-9D for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:36:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPN3-0003Ta-UX for sip@ietf.org; Fri, 12 Oct 2007 14:36:25 -0400 Received: from smtp-1.hut.fi ([130.233.228.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgPMy-0002ib-5w for sip@ietf.org; Fri, 12 Oct 2007 14:36:20 -0400 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l9CIaHD0015321; Fri, 12 Oct 2007 21:36:17 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 21749-33-3; Fri, 12 Oct 2007 21:36:17 +0300 (EEST) Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l9CIZqwe015124; Fri, 12 Oct 2007 21:35:52 +0300 Received: from localhost (localhost.tml.hut.fi [127.0.0.1]) by mail.tml.hut.fi (Postfix) with ESMTP id A8F1B3A2CF5; Fri, 12 Oct 2007 21:35:52 +0300 (EEST) Received: from mail.tml.hut.fi ([127.0.0.1]) by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06479-05; Fri, 12 Oct 2007 21:35:51 +0300 (EEST) Received: from localhost (newhorde.tml.hut.fi [130.233.45.225]) by mail.tml.hut.fi (Postfix) with ESMTP id 796003A2CF3; Fri, 12 Oct 2007 21:35:51 +0300 (EEST) Received: from tltpc77.hut.fi (tltpc77.hut.fi [130.233.158.137]) by horde.tml.hut.fi (Horde MIME library) with HTTP; Fri, 12 Oct 2007 21:30:57 +0300 Message-ID: <20071012213057.xekhg90hesks8kc8@horde-intra.tml.hut.fi> Date: Fri, 12 Oct 2007 21:30:57 +0300 From: sergiole@tml.hut.fi To: sip@ietf.org Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> In-Reply-To: <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Spam-Score: 1.8 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: , Errors-To: sip-bounces@ietf.org I understand that the problem you want to solve is the following : > Or, when you meet someone and want get your phones paired, you > just type the target name because you have your cell phone in your hand. > The phones get paired. You don't need to type a long SIP URI and > Mobile IPv6 home address. also mentioned in other email: > I'll tell it to people that I know only. I'll tell it using a user friendl= y > mechanism called "pairing" : We meet each other with our cell phones, > and agree to exchange our contact information. I guess that what you want to avoid is to input in your phone the =20 URI of the person you met, and instead automatically interchange URIs. In any case someone needs to enter something in their phone, either =20 a URI, search keyword, TEL, etc to pair a contact... SE Quoting Pars Mutaf : > On 10/12/07, Spencer Dawkins wrote: >> >> > The privacy problem: normally I shouldn't be able to discover >> your SIP URI. >> >> I'm guessing that if you can't tell people your SIP AOR, then SIP is not >> for >> you. > > > Hello, > > I won't publish my SIP URI in a phone book allowing anyone to see it. > We already agreed on that. > > I'll tell it to people that I know only. I'll tell it using a user friendl= y > mechanism called "pairing" : We meet each other with our cell phones, > and agree to exchange our contact information. So, the procedure is > under our control. Pairing is good for us also because it allows us to > exchange a secret key (note that this is already enough motivation for > the pairing idea). > > The point is that, if I give you my SIP URI (using the pairing procedure) > then I can also give you my Mobile IPv6 home address using the same > pairing procedure. In other words, there is _no more resolution_ from > SIP URI to home IP address. You get them **concurrently**. > > We have each other's SIP URIs and home addresses. > ->SIP application is happy, it has the target SIP URI. > ->Routing problem is solved by mobile IPv6. > > My question was: do we need the SIP trapezoid in this case. > > Thanks, > pars > > > > > > > Thanks, >> >> Spencer >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 14:48:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPUl-0003Xv-HX; Fri, 12 Oct 2007 14:44:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgPUk-0003UJ-03 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPUj-0003UB-Mi for sip@ietf.org; Fri, 12 Oct 2007 14:44:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPUe-0008Ra-Gq for sip@ietf.org; Fri, 12 Oct 2007 14:44:21 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9CIi4808165; Fri, 12 Oct 2007 18:44:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Fri, 12 Oct 2007 13:43:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF127A6F34@zrc2hxm0.corp.nortel.com> In-Reply-To: <470FB55E.2070909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM+UjDATCFiEk5RTuzcIBKyQM64gABQtqw References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <470FB55E.2070909@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: IETF SIP List , Francois Audet , Christer Holmberg , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 12, 2007 12:57 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; DRAGE, Keith (Keith); IETF SIP List; Audet,=20 > Francois (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 >=20 > Brian Stucker wrote: >=20 > > You forgot about supported. > >=20 > >> So for example, DTMF: Using this model of SIP extension, we might=20 > >> define a new "DTMF" method. It would look just like=20 > DTMF-over-INFO,=20 > >> except the name of the method would be DTMF. > >> It clearly resolves the INFO-context question, because now we KNOW=20 > >> we're getting dialog- related DTMF over it, and we know what to do=20 > >> with it. We know what we can transport in DTMF-requests,=20 > because the=20 > >> RFC that defines the DTMF extension method will also=20 > define exactly=20 > >> what payload format to use. > >=20 > > INVITE > > Supported: foo > > Allow: INFO > > Accept: application/foo > >=20 > > 200 OK > > Supported: foo > > Allow: INFO > > Accept: application/foo > >=20 > > ... > >=20 > > INFO > > Content-Type: application/foo > > [DTMF] > >=20 > >=20 > > Where is this broken? >=20 > This can work if there is an RFC defining the foo option that=20 > specifies that when both parties support foo then: > - the UAC may use INFO to send information using > Content-Type application/foo and Content-Disposition: (TBD) > - the circumstances triggering the UAC to send are ... > - the expected actions of the UAS upon receiving are ... >=20 > Because this uses an option, and a new option can only be=20 > defined via an RFC, this technique is only available=20 > (legally) when an RFC will be approved. (Of course people=20 > have been known to invent new options without an RFC, but=20 > that is non-conforming usage.) That seems like more of a legal loophole for defining event header values than anything else. There's only one currently IANA registered event header value that is not associated with an RFC and I doubt that one is going to live for very long in light of RTCP-XR. Are you advocating not having to have an RFC for an event header as a positive thing? If so, then isn't this equivalent to a vote for leaving INFO alone? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 12 15:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQJl-0002jW-Pw; Fri, 12 Oct 2007 15:37:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgQJj-0002gF-R8 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:37:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQJj-0002g7-Fg for sip@ietf.org; Fri, 12 Oct 2007 15:37:03 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgQJi-0004hN-S3 for sip@ietf.org; Fri, 12 Oct 2007 15:37:03 -0400 X-IronPort-AV: E=Sophos;i="4.21,268,1188802800"; d="scan'208";a="406037388" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2007 12:37:02 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9CJb2dQ002876; Fri, 12 Oct 2007 12:37:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9CJb0mD003063; Fri, 12 Oct 2007 19:37:01 GMT 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.1830); Fri, 12 Oct 2007 15:36:50 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 15:36:49 -0400 Message-ID: <470FCCD2.5090007@cisco.com> Date: Fri, 12 Oct 2007 15:36:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <470FB55E.2070909@cisco.com> <1ECE0EB50388174790F9694F77522CCF127A6F34@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF127A6F34@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 19:36:49.0460 (UTC) FILETIME=[3B858F40:01C80D07] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15478.002 X-TM-AS-Result: No--31.080900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3143; t=1192217822; x=1193081822; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20What=20are=20we=20arguing=20about=20when=20we=20say=2 0INFO?=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20; bh=t+KPveCkTpUk07Bdynm8ArZpKgl58POngQQXJW5E/QU=; b=nDZfHG6JwO/qhzA+wXQtdOy6irsGRYUQYDh2wlm/e2Y3w7I9ReI4mGEn60GH3qaZBevMLlcv imEtErSYVK871gv2yqj4FWx6h/rTlx90fZskKMgErT0S1ePP72fGHqJY; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: IETF SIP List , Francois Audet , Christer Holmberg , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 12, 2007 12:57 PM >> To: Stucker, Brian (RICH1:AR00) >> Cc: Dean Willis; DRAGE, Keith (Keith); IETF SIP List; Audet, >> Francois (SC100:3055); Christer Holmberg >> Subject: Re: What are we arguing about when we say INFO? (was >> Re: [Sip] INFO) >> >> >> >> Brian Stucker wrote: >> >>> You forgot about supported. >>> >>>> So for example, DTMF: Using this model of SIP extension, we might >>>> define a new "DTMF" method. It would look just like >> DTMF-over-INFO, >>>> except the name of the method would be DTMF. >>>> It clearly resolves the INFO-context question, because now we KNOW >>>> we're getting dialog- related DTMF over it, and we know what to do >>>> with it. We know what we can transport in DTMF-requests, >> because the >>>> RFC that defines the DTMF extension method will also >> define exactly >>>> what payload format to use. >>> INVITE >>> Supported: foo >>> Allow: INFO >>> Accept: application/foo >>> >>> 200 OK >>> Supported: foo >>> Allow: INFO >>> Accept: application/foo >>> >>> ... >>> >>> INFO >>> Content-Type: application/foo >>> [DTMF] >>> >>> >>> Where is this broken? >> This can work if there is an RFC defining the foo option that >> specifies that when both parties support foo then: >> - the UAC may use INFO to send information using >> Content-Type application/foo and Content-Disposition: (TBD) >> - the circumstances triggering the UAC to send are ... >> - the expected actions of the UAS upon receiving are ... >> >> Because this uses an option, and a new option can only be >> defined via an RFC, this technique is only available >> (legally) when an RFC will be approved. (Of course people >> have been known to invent new options without an RFC, but >> that is non-conforming usage.) > > That seems like more of a legal loophole for defining event header > values than anything else. Event types and sip option tags are separate namespaces with different registration ruies: - event types: Informational RFC approved by the IESG - option tags: Publication of standards track (section 27.1) So the bar is slightly lower for event types. > There's only one currently IANA registered > event header value that is not associated with an RFC and I doubt that > one is going to live for very long in light of RTCP-XR. > > Are you advocating not having to have an RFC for an event header as a > positive thing? If so, then isn't this equivalent to a vote for leaving > INFO alone? No, I'm not advocating it as a good thing. I am acknowledging that people will do it for proprietary reasons, but that if they later come forward and try to get the usage formally approved then there is a bar to get over. You can publish a informational rfc for your proprietary event type without any consensus of the wg, etc. But getting a standards track rfc approved for an option tag will require the wg to bless your approach. Paul > Regards, > Brian > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 12 15:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQR9-0006EW-9H; Fri, 12 Oct 2007 15:44:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgQR7-0006EI-N0 for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQR7-0006EA-DO for sip@ietf.org; Fri, 12 Oct 2007 15:44:41 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQR5-00020x-TO for sip@ietf.org; Fri, 12 Oct 2007 15:44:41 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E5BA2015A; Fri, 12 Oct 2007 21:44:39 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-61-470fcea7f71b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FC7E2008A; Fri, 12 Oct 2007 21:44:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 21:44:38 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 21:44:38 +0200 Received: from [131.160.126.165] (rvi2-126-165.lmf.ericsson.se [131.160.126.165]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3221B2465; Fri, 12 Oct 2007 22:44:38 +0300 (EEST) Message-ID: <470FCEA4.3060101@ericsson.com> Date: Fri, 12 Oct 2007 22:44:36 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt References: <46DDD081.9030900@cisco.com> <46DE8094.8060807@ericsson.com> In-Reply-To: <46DE8094.8060807@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 19:44:39.0028 (UTC) FILETIME=[5367F340:01C80D08] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: Eric Burger , Paul Kyzivat , Keith Drage , 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: , Errors-To: sip-bounces@ietf.org Folks, FYI: we have requested the apps folks to have a look at this draft in order to make sure we get all the MIME stuff right. We will make sure the review is posted to this list. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi, > > to be more concrete in our discussions, we need to make decisions on the > following two issues: > > 1) Where in a SIP message is it allowed to reference a body part? > > a) in header fields and body parts within the same multipart/related as > the referenced body part > b) in header fields and body parts that appear before the referenced > body part > c) in header fields and any body part > > We discussed that doing c) would require to parse SIP messages twice to > look for potential references. Therefore, we decided to do a) or b). The > current draft specifies a), we doing b) might make sense as well (it > would be less restrictive). > > > 2) If a receiver does not understand a reference to a body part: > > a) it should process (handle) it solely based on its disposition type > (as a fall-back mechanism). If the sender does not want this to happen, > it can use an option tag. > > b) the body part will have a disposition type of "only-by-reference". > This way, since the receiver did not understand the reference, it knows > it should not process the body. > > The current draft specifies a), but b) would be an interesting > optimization (no need to use option tags and reissue requests). However, > we would need to get the opinion of a MIME person on b). > > Cheers, > > Gonzalo > > > > Paul Kyzivat wrote: >> >> >> Eric Burger wrote: >>> I agree 100% with Paul. However, one thing I would like to hear >>> opinions on >>> is the following: >>> >>> Do we way body parts are always processed, no matter what? >>> >>> It would be convenient to say body parts get processed as needed. If >>> there >>> is a related part that never gets referenced, then a conforming >>> processor >>> might not process that part, as an optimization. >> >> This gets into semantics... >> >> For one thing, I guess we should talk about "handling" rather than >> "processing" - this is tied to the C-D "handling=" parameter. >> >> But the key thing is what does it *mean* to say you have handled >> something? Its one thing to understand the meaning of the type and >> disposition. What you actually *do* once that is understood is >> something else entirely. >> >> I would expect that somewhere there would be a normative specification >> for each C-D of what it means to *handle* body parts with that >> disposition. This is where we get into trouble with "render", where we >> need a different definition for SIP than is used for email. >> >> I presume that if we had such normative definitions, then that would >> determine what sort of optimizations, such as lazy processing, are >> allowed. >> >> For example, 3261 defines (barely) the C-D "alert". It says this >> "should" (lower case) be rendered. Together with some words elsewhere >> about Alert-Info that warn of security issues, its seems clear that >> the UA is given discretion about actually rendering this. (But it is >> not a stellar example of clarity.) I would interpret this to mean that >> you can consider the "alert" body part to have been "handled" if you >> have indeed understood it and then *either* rendered it or made an >> explicit not to render it. >> >>> However, one thing we need to be mindful of are side effects. MIME body >>> parts can make external references. Those external references (to >>> http/https URI's) may hit application servers. Those application >>> servers >>> may do something based on the receipt of the URI. It could be as >>> simple as >>> recording the fact the body part was read (like a web beacon), or it >>> could >>> be as complex as changing application state. >> >> We have similar issues with headers that contain URL references, that >> might or might not be resolved. E.g. Call-Info. >> >> Again, I don't see any general answer better than the specification of >> the particular header or C-D. >> >> Based on this discussion I am beginning to conclude that we might as >> well treat each body part almost as if it were a header whose name is >> its C-D. >> >>> What do people think of this? Do we say that SIP engines are >>> opportunistic, >>> and the side effect MUST happen if the body gets used, buy the side >>> effect >>> MAY happen if the body does not get used? That would be my vote, as the >>> alternative, that all side effects (external references get resolved) >>> happen >>> puts a pretty big burden on User Agents. >> >> This is further complicated by intermediate nodes. They are >> *permitted* to look at body parts. If, as a result, an intermediate >> node dereferences a reference within a body part, you will potentially >> have another side effect. >> >> I also agree that we should give the UA latitude in what processing it >> does. For example, even though a request has a geopriv header with a >> body part containing location data, and has specified >> "handling=required", the UAS may have no use for the location. If it >> doesn't intend to use it then why should it process it? >> >> Paul >> >>> On 8/29/07 8:57 AM, "Paul Kyzivat" wrote: >>> >>>> To clarify futher my last point below... >>>> >>>> What I am saying is that IMO body parts must always be processed >>>> according to their type and disposition, whether there are >>>> references to >>>> them or not. If there is a reference, and it is understood, then it can >>>> modify or supplement the processing, but if the reference is not >>>> recognized or understood then the other processing still occurs. >>>> >>>> If we want to support the possibility of a reference to a body part, >>>> where there is to be no processing of the body part when the reference >>>> is not understood, then we need a content-disposition that says "don't >>>> do anything with this unless you process a reference to it." >>>> >>>> An alternative is to simply assume there are no such cases, and warn >>>> people that use references to select a C-D for the referenced part that >>>> will have an appropriate result if the reference is not understood. >>>> >>>> For instance, we have both the Alert-Info header and the "alert" >>>> C-D. If >>>> you use an A-I with a CID reference, then you can use "alert" as the >>>> C-D >>>> of that part. In that case, the A-I header is redundant unless it >>>> contains something that modifies the processing. >>>> >>>> An example where the problem I am concerned about may exist is in >>>> draft-ietf-sip-location-conveyance-08. It has an example of a >>>> Geolocation header referencing a body part. There is no C-D header in >>>> the example, so by default it is "render;handling=required". And its >>>> C-T >>>> is application/pidf+xml. If a recipient of this message didn't >>>> understand the Geolocation header it would reach the conclusion that it >>>> should render the pidf. Its debatable whether that is the desired >>>> conclusion - I think not. IMO the intent is that if the Geolocation >>>> header isn't processed then the pidf should be ignored. So, IMO this >>>> body part ought to contain: >>>> Content-Disposition: by-reference;handling=optional >>>> >>>> (I don't care what name we use for the disposition, just that we >>>> have one.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo, >>>>> >>>>> Obviously we allow a "forward" reference from the sip message itself >>>>> (which from a mime perspective are just a bunch of mime headers.) >>>>> >>>>> I think that establishes a precedent that needs to be continued. An >>>>> example of why can be seen in sipfrag: >>>>> >>>>> If we had a valid sip response that had a reference into one of its >>>>> body >>>>> parts, then if that was turned into a sipfrag and stuffed into the >>>>> body >>>>> of a NOTIFY, then it must still be valid. >>>>> >>>>> I just did a quick scan of the new draft, so the following is a >>>>> tentative comment, until I can read it more carefully: >>>>> >>>>> I think the draft is now saying that the decision about whether to >>>>> process a body part according to a reference to it, or process >>>>> independently, is decided based on whether a reference is found. We >>>>> had >>>>> this discussion before, and I think we agreed that wouldn't work well, >>>>> and that instead we would have a special C-D type for body parts that >>>>> are disposed of based on a reference. >>>>> >>>>> I don't think the introduction of issues related to multipart/related >>>>> changes this. The obvious cases are when there is a single >>>>> multipart/mixed containing some body parts. Some of those may be >>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) may >>>>> stand >>>>> on their own. It is entirely possible that a body part might be >>>>> referenced from some extension header that the recipient doesn't >>>>> understand. In that case it may erroneously decide to process the body >>>>> part on its own, when it should instead have ignored it because the >>>>> header isn't being processed. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Gonzalo Camarillo wrote: >>>>>> Folks, >>>>>> >>>>>> I have just submitted a new revision of the body handling draft. >>>>>> Until >>>>>> it appears on the archives, you can fetch it from: >>>>>> >>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt >>>>>> >>>>>> >>>>>> Per our discussions in Chicago, the draft now states that only body >>>>>> parts within the same 'multipart/related' can reference each other >>>>>> using cid URIs. >>>>>> >>>>>> If this is too restrictive, we could also allow using forward >>>>>> references in any context (with no 'multipart/related' at all). >>>>>> >>>>>> Comments? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of sip >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> Notice: This email message, together with any attachments, may >>> contain information of BEA Systems, Inc., its subsidiaries and >>> affiliated entities, that may be confidential, proprietary, >>> copyrighted and/or legally privileged, and is intended solely for >>> the use of the individual or entity named in this message. If you are >>> not the intended recipient, and have received this message in error, >>> please immediately return this by email and then delete it. >>> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 18:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSSw-0001P9-PG; Fri, 12 Oct 2007 17:54:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgSSu-0001NC-OA for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSSu-0001Gq-EK for sip@ietf.org; Fri, 12 Oct 2007 17:54:40 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSSj-0006CF-9m for sip@ietf.org; Fri, 12 Oct 2007 17:54:35 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 12 Oct 2007 17:54:24 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 12 Oct 2007 17:54:23 -0400 From: Hadriel Kaplan To: Francois Audet , Adam Roach Date: Fri, 12 Oct 2007 17:54:08 -0400 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoAAA8Q80AA7KEfAAYf0aUA== Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Errors-To: sip-bounces@ietf.org Yeah, that's what I meant when I said in an earlier email: "But I think that is something that could be standardized away if we needed= to. One way could be to define an Event package type model for it. One c= ould argue Info is essentially a Notify, except in a subscription implicitl= y created by, and tied to the dialog from, an Invite." But Adam didn't seem to like it. Not sure why. Adam? -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, October 10, 2007 7:14 PM > To: Christer Holmberg; Dean Willis > Cc: IETF SIP List > Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > > > (d) they think it's a waste of resources to establish > > multiple additional subscription dialogs (there may be other > > type of data than DTMF they are willing to receive) which in > > many cases may not even be used during the call (it can not > > be assumed that the one sending the subscription always knows > > exactly when it will receive events). Maybe DTMF is not the > > best example in the world (my fault - I should have been more > > generic), but I am sure there could be events which would not > > be used in a very high percentage of all calls, but still the > > additional subscription dialog(s) would have to be > > established - just in case. > > Maybe a way to subscribe to packages within an INVITE dialog would > be suitable. You then would get the NOTIFYs withind the dialog, and > they wouldn't be out-of-the-blue because you would have subscribed > to those events explicitly with some Allow-Event in the INVITE. > > I know many people will hate this idea but, I do agree with Christer > that subscribing to an event package "just in case" when it normally > is not used is quite a huge overhead and explain why people just > use INFO instead. > > > > I still strongly think it would be much better to describe > > the issues/advantages/disadvantages with BOTH INFO and > > events, and study what possible needs to defined related to > > negotiation etc, instead of just ignoring the real world and > > providing flexibility to people using SIP for their applications... > > I think the idea above would address this and avoid the INFO pitfalls. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 12 19:27:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTq6-0000ho-0q; Fri, 12 Oct 2007 19:22:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgTq4-0000hO-Gq for sip-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:22:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTq4-0000dU-4q for sip@ietf.org; Fri, 12 Oct 2007 19:22:40 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgTpz-00031X-Ot for sip@ietf.org; Fri, 12 Oct 2007 19:22:36 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 12 Oct 2007 19:22:35 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 12 Oct 2007 19:22:34 -0400 From: Hadriel Kaplan To: Sumit Garg , Brian Stucker , Dean Willis , "DRAGE, Keith (Keith)" Date: Fri, 12 Oct 2007 19:22:31 -0400 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM7/gCjvEyEC/iQVeVRwn9WYcVPwAAQGXQAAHYyBAAC00lAA== Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com>!! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3-97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F01816D0B@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F01816D0B@MAIL02.cedarpointcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List , Francois Audet , Christer, Holmberg 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Sumit Garg [mailto:sgarg@cedarpointcom.com] > Sent: Friday, October 12, 2007 2:20 PM > To: Brian Stucker; Dean Willis; DRAGE, Keith (Keith) > Cc: IETF SIP List; Francois Audet; Christer Holmberg > Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > Agreed. > > Basically there can be 3 scenario: > > 1. A---------------C (the signaling and media path ) --->2833 is best. > > 2. A---------------B (the signaling and media path ) > C which is a proxy, and in neither path needs the DTMF > (SUBSCRIBE/NOTIFY is best) > > 3. A---------------C------------B (signaling path) > A--------------------B (media path) > C needs the DTMF events, cannot use 2833 and SUBSCRIBE/NOTIFY is okay > but not necessarily the best approach due to the overhead of additional > dialogs (whose duration is tightly linked to the INVITE dialog). INFO > definitely looks attractive here. > > Similarly, the recent draft on rtcp-summary defines a complex > SUBCRIBE/NOTIFY mechanism, which again covers all scenarios gracefully. > However, for scenario 1 and 3 some other mechanism would be better. Even for scenario 2. In scenario 2 such a proxy was in the path for at lea= st the Invite, in order to know about the session. So even if it wasn't re= cord-routing it may be better for proxy C to do subscribe/notify, but for A= and B it will be worse, as they now have an additional dialog... for each = proxy C in the Invite's path that wants the information. And if A or B are= gateways or servers handling lots of sessions, that's a difference. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 13 04:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igc3o-0007Pw-Tf; Sat, 13 Oct 2007 04:09:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Igc3n-0007Po-Ks for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 04:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igc3n-0007Pg-BO for sip@ietf.org; Sat, 13 Oct 2007 04:09:23 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igc3h-0002a6-U0 for sip@ietf.org; Sat, 13 Oct 2007 04:09:23 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2AEC8201AD; Sat, 13 Oct 2007 10:09:01 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-43-47107d1d8579 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00A6920144; Sat, 13 Oct 2007 10:09:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 10:09:00 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Oct 2007 10:09:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 590262462; Sat, 13 Oct 2007 11:09:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AFF014DC26; Sat, 13 Oct 2007 11:08:59 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3640A4DB21; Sat, 13 Oct 2007 11:08:59 +0300 (EEST) Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) From: Salvatore Loreto To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> <1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Sat, 13 Oct 2007 11:08:59 +0300 Message-Id: <1192262939.4329.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 13 Oct 2007 08:09:00.0405 (UTC) FILETIME=[4FA94250:01C80D70] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , Christer Holmberg , 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: , Errors-To: sip-bounces@ietf.org On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > the proposal is interesting. > > However there should be cases where you need to send whatever > > information in both directions, or cases where when you send > > an information via Notify you need to receive back some > > information (e.g. > > the fact that you receive a 200Ok as answer to the Notify it > > is not enough). > > How do you think your proposal should work in those cases ? > > perhaps with > > 2 subscription one in each direction? > > Yes. OK, I agree on this. But maybe should be interesting a mechanism to discriminate when you need 2 subscription one in each direction, when one it is enough and in the case of only one subscription the possibility to choose in which direction you want to start it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 13 11:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igiv4-000163-Bt; Sat, 13 Oct 2007 11:28:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Igiv2-00011o-Hn for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 11:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igiv2-0000ze-6m for sip@ietf.org; Sat, 13 Oct 2007 11:28:48 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igiv0-0007lU-Mh for sip@ietf.org; Sat, 13 Oct 2007 11:28:48 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9DFSQ1W083120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Oct 2007 10:28:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4710E415.3070602@nostrum.com> Date: Sat, 13 Oct 2007 10:28:21 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4539/Sat Oct 13 03:59:25 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Answering a little bit of your scenario and a little bit of Francois': 1. Support must be explicit. Everything described so far makes indication of the ability to receive an INVITE (or NOTIFY in Francois' case) implicit in circumstances where such an implication can be accidental. There are legitimate situations in which any of the proposed heuristics used to perform such an implication may legitimately exist and yet not mean that the recipient is requesting INFO (or NOTIFY) requests. 2. Dialog re-use causes problems. Having multiple usages within a dialog causes all kinds of confusing interactions between the usages. Even the ones that are well documented are seldom implemented correctly. (e.g., if I send a re-INVITE in a dialog that is shared with a SUBSCRIBE and get a 481, what is gone? The INVITE usage or the dialog? What it it's a 480? A 500? Even if _you_ know where to look it up, will implementors? Even if they do, are the rules sufficiently labyrinthine that the chances of misimplementation are high?) The "pushing my buttons" comment came from your implication that INFO was basically the same as NOTIFY in this context -- which is imperfect in myriad ways. For example: such a statement would mean that the INFO usage survives the termination of the INVITE dialog (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's probably not what you meant, but (except at the most superficial level) it's so far away from what you might actually want as to be a very poor starting point. Can this be salvaged? Yes -- and Dean's earlier proposal for INFO packages does so by making such things explicit. There's another question about whether it's worth salvaging, and I think that's a little less cut-and-dried (despite my strong opinion on the topic) -- but I'm boggled by the extreme pushback to making this negotiation explicit in the face of clear examples of how things break when we don't. /a (For the record: "Allow-Event" in an INVITE has very well defined semantics -- it means, "if you send me a SUBSCRIBE for this event package, I can send NOTIFYs". It is exactly backwards from the meaning "I can receive NOTIFYs of this type".) Hadriel Kaplan wrote: > Yeah, that's what I meant when I said in an earlier email: > "But I think that is something that could be standardized away if we needed to. One way could be to define an Event package type model for it. One could argue Info is essentially a Notify, except in a subscription implicitly created by, and tied to the dialog from, an Invite." > > But Adam didn't seem to like it. Not sure why. Adam? > > -hadriel > > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Wednesday, October 10, 2007 7:14 PM >> To: Christer Holmberg; Dean Willis >> Cc: IETF SIP List >> Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] >> INFO) >> >> >> >>> (d) they think it's a waste of resources to establish >>> multiple additional subscription dialogs (there may be other >>> type of data than DTMF they are willing to receive) which in >>> many cases may not even be used during the call (it can not >>> be assumed that the one sending the subscription always knows >>> exactly when it will receive events). Maybe DTMF is not the >>> best example in the world (my fault - I should have been more >>> generic), but I am sure there could be events which would not >>> be used in a very high percentage of all calls, but still the >>> additional subscription dialog(s) would have to be >>> established - just in case. >>> >> Maybe a way to subscribe to packages within an INVITE dialog would >> be suitable. You then would get the NOTIFYs withind the dialog, and >> they wouldn't be out-of-the-blue because you would have subscribed >> to those events explicitly with some Allow-Event in the INVITE. >> >> I know many people will hate this idea but, I do agree with Christer >> that subscribing to an event package "just in case" when it normally >> is not used is quite a huge overhead and explain why people just >> use INFO instead. >> >> >> >>> I still strongly think it would be much better to describe >>> the issues/advantages/disadvantages with BOTH INFO and >>> events, and study what possible needs to defined related to >>> negotiation etc, instead of just ignoring the real world and >>> providing flexibility to people using SIP for their applications... >>> >> I think the idea above would address this and avoid the INFO pitfalls. >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 13 22:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igt8x-0006nZ-H1; Sat, 13 Oct 2007 22:23:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Igt8v-0006nO-Kb for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 22:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igt8v-0006fg-B3 for sip@ietf.org; Sat, 13 Oct 2007 22:23:49 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igt8k-0000xp-6o for sip@ietf.org; Sat, 13 Oct 2007 22:23:44 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 13 Oct 2007 22:23:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 13 Oct 2007 22:23:17 -0400 From: Hadriel Kaplan To: Salvatore Loreto , Francois Audet Date: Sat, 13 Oct 2007 22:23:15 -0400 Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8Ww Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> <1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> In-Reply-To: <1192262939.4329.5.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF SIP List , Dean Willis , Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-From sip-bounces@ietf.org Sat Oct 13 22:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igt8x-0006nZ-H1; Sat, 13 Oct 2007 22:23:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Igt8v-0006nO-Kb for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 22:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igt8v-0006fg-B3 for sip@ietf.org; Sat, 13 Oct 2007 22:23:49 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igt8k-0000xp-6o for sip@ietf.org; Sat, 13 Oct 2007 22:23:44 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 13 Oct 2007 22:23:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 13 Oct 2007 22:23:17 -0400 From: Hadriel Kaplan To: Salvatore Loreto , Francois Audet Date: Sat, 13 Oct 2007 22:23:15 -0400 Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8Ww Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> <1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> In-Reply-To: <1192262939.4329.5.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF SIP List , Dean Willis , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org You make it sound like there is some extra signaling involved in the subscr= iptions. I thought we were talking about *implicit* subscriptions. The on= ly extra "signaling" would be event package negotiation exchange, presumabl= y in headers in the Invite and responses. Then a Notify for the events. O= r really instead of a NOTIFY, it could be a new method called "Invite-based= Notification Function Output" or "INFO" for short. :) Or do you just mean the negotiation needs to support both the concept of a = uni and bi-directional implicit subscription? -hadriel > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Saturday, October 13, 2007 4:09 AM > To: Francois Audet > Cc: IETF SIP List; Christer Holmberg; Dean Willis > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing > about when we say INFO?) > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > the proposal is interesting. > > > However there should be cases where you need to send whatever > > > information in both directions, or cases where when you send > > > an information via Notify you need to receive back some > > > information (e.g. > > > the fact that you receive a 200Ok as answer to the Notify it > > > is not enough). > > > How do you think your proposal should work in those cases ? > > > perhaps with > > > 2 subscription one in each direction? > > > > Yes. > > OK, I agree on this. > But maybe should be interesting a mechanism to discriminate when you > need 2 subscription one in each direction, when one it is enough and in > the case of only one subscription the possibility to choose in which > direction you want to start it. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 13 22:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgszT-0004zA-Ah; Sat, 13 Oct 2007 22:14:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgszR-0004xr-Oc for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 22:14:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgszQ-0004vR-VV for sip@ietf.org; Sat, 13 Oct 2007 22:14:01 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgszL-00074R-Dc for sip@ietf.org; Sat, 13 Oct 2007 22:13:55 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 13 Oct 2007 22:13:54 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 13 Oct 2007 22:13:54 -0400 From: Hadriel Kaplan To: Adam Roach Date: Sat, 13 Oct 2007 22:13:52 -0400 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJA Message-ID: References: <6FC4416DDE56C44DA0AEE67Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You make it sound like there is some extra signaling involved in the subscr= iptions. I thought we were talking about *implicit* subscriptions. The on= ly extra "signaling" would be event package negotiation exchange, presumabl= y in headers in the Invite and responses. Then a Notify for the events. O= r really instead of a NOTIFY, it could be a new method called "Invite-based= Notification Function Output" or "INFO" for short. :) Or do you just mean the negotiation needs to support both the concept of a = uni and bi-directional implicit subscription? -hadriel > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Saturday, October 13, 2007 4:09 AM > To: Francois Audet > Cc: IETF SIP List; Christer Holmberg; Dean Willis > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing > about when we say INFO?) > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > the proposal is interesting. > > > However there should be cases where you need to send whatever > > > information in both directions, or cases where when you send > > > an information via Notify you need to receive back some > > > information (e.g. > > > the fact that you receive a 200Ok as answer to the Notify it > > > is not enough). > > > How do you think your proposal should work in those cases ? > > > perhaps with > > > 2 subscription one in each direction? > > > > Yes. > > OK, I agree on this. > But maybe should be interesting a mechanism to discriminate when you > need 2 subscription one in each direction, when one it is enough and in > the case of only one subscription the possibility to choose in which > direction you want to start it. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 13 22:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgszT-0004zA-Ah; Sat, 13 Oct 2007 22:14:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IgszR-0004xr-Oc for sip-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 22:14:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgszQ-0004vR-VV for sip@ietf.org; Sat, 13 Oct 2007 22:14:01 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgszL-00074R-Dc for sip@ietf.org; Sat, 13 Oct 2007 22:13:55 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 13 Oct 2007 22:13:54 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 13 Oct 2007 22:13:54 -0400 From: Hadriel Kaplan To: Adam Roach Date: Sat, 13 Oct 2007 22:13:52 -0400 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJA Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <4710E415.3070602@nostrum.com> In-Reply-To: <4710E415.3070602@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Howdy, Inline... > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Saturday, October 13, 2007 11:28 AM > To: Hadriel Kaplan > Cc: Francois Audet; IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > Answering a little bit of your scenario and a little bit of Francois': > > 1. Support must be explicit. Everything described so far makes > indication of the ability to receive an INVITE I assume you mean INFO, not INVITE? > (or NOTIFY in > Francois' case) implicit in circumstances where such an > implication can be accidental. There are legitimate situations in > which any of the proposed heuristics used to perform such an > implication may legitimately exist and yet not mean that the > recipient is requesting INFO (or NOTIFY) requests. I didn't mean to imply there wouldn't be explicit indication of INFO suppor= t for specific event packages. I was saying that's what's missing now and = would have to be standardized. > 2. Dialog re-use causes problems. Having multiple usages within a > dialog causes all kinds of confusing interactions between the > usages. Even the ones that are well documented are seldom > implemented correctly. (e.g., if I send a re-INVITE in a dialog > that is shared with a SUBSCRIBE and get a 481, what is gone? The > INVITE usage or the dialog? The dialog, as before, and also the subscription, since the subscription wo= uld be tied to the invite's dialog. They would share fate. > What it it's a 480? A 500? Even if > _you_ know where to look it up, will implementors? Even if they > do, are the rules sufficiently labyrinthine that the chances of > misimplementation are high?) The "pushing my buttons" comment came > from your implication that INFO was basically the same as NOTIFY > in this context -- which is imperfect in myriad ways. For example: > such a statement would mean that the INFO usage survives the > termination of the INVITE dialog > (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's > probably not what you meant, but (except at the most superficiBC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <4710E415.3070602@nostrum.com> In-Reply-To: <4710E415.3070602@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Howdy, Inline... > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Saturday, October 13, 2007 11:28 AM > To: Hadriel Kaplan > Cc: Francois Audet; IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > Answering a little bit of your scenario and a little bit of Francois': > > 1. Support must be explicit. Everything described so far makes > indication of the ability to receive an INVITE I assume you mean INFO, not INVITE? > (or NOTIFY in > Francois' case) implicit in circumstances where such an > implication can be accidental. There are legitimate situations in > which any of the proposed heuristics used to perform such an > implication may legitimately exist and yet not mean that the > recipient is requesting INFO (or NOTIFY) requests. I didn't mean to imply there wouldn't be explicit indication of INFO suppor= t for specific event packages. I was saying that's what's missing now and = would have to be standardized. > 2. Dialog re-use causes problems. Having multiple usages within a > dialog causes all kinds of confusing interactions between the > usages. Even the ones that are well documented are seldom > implemented correctly. (e.g., if I send a re-INVITE in a dialog > that is shared with a SUBSCRIBE and get a 481, what is gone? The > INVITE usage or the dialog? The dialog, as before, and also the subscription, since the subscription wo= uld be tied to the invite's dialog. They would share fate. > What it it's a 480? A 500? Even if > _you_ know where to look it up, will implementors? Even if they > do, are the rules sufficiently labyrinthine that the chances of > misimplementation are high?) The "pushing my buttons" comment came > from your implication that INFO was basically the same as NOTIFY > in this context -- which is imperfect in myriad ways. For example: > such a statement would mean that the INFO usage survives the > termination of the INVITE dialog > (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's > probably not what you meant, but (except at the most superficial > level) it's so far away from what you might actually want as to be > a very poor starting point. Right, it's not what I meant. :) > Can this be salvaged? Yes -- and Dean's earlier proposal for INFO > packages does so by making such things explicit. There's another > question about whether it's worth salvaging, and I think that's a little > less cut-and-dried (despite my strong opinion on the topic) -- but I'm > boggled by the extreme pushback to making this negotiation explicit in > the face of clear examples of how things break when we don't. I don't think anyone is pushing back against making negotiation explicit. > (For the record: "Allow-Event" in an INVITE has very well defined > semantics -- it means, "if you send me a SUBSCRIBE for this event > package, I can send NOTIFYs". It is exactly backwards from the meaning > "I can receive NOTIFYs of this type".) Yes I agree... didn't say otherwise. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip al > level) it's so far away from what you might actually want as to be > a very poor starting point. Right, it's not what I meant. :) > Can this be salvaged? Yes -- and Dean's earlier proposal for INFO > packages does so by making such things explicit. There's another > question about whether it's worth salvaging, and I think that's a little > less cut-and-dried (despite my strong opinion on the topic) -- but I'm > boggled by the extreme pushback to making this negotiation explicit in > the face of clear examples of how things break when we don't. I don't think anyone is pushing back against making negotiation explicit. > (For the record: "Allow-Event" in an INVITE has very well defined > semantics -- it means, "if you send me a SUBSCRIBE for this event > package, I can send NOTIFYs". It is exactly backwards from the meaning > "I can receive NOTIFYs of this type".) Yes I agree... didn't say otherwise. :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50S-00086U-3s; Sun, 14 Oct 2007 11:03:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih50Q-000869-B3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50Q-00081u-07 for sip@ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ih50K-00035I-8p for sip@ietf.org; Sun, 14 Oct 2007 11:03:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C31F204D3; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-d2-47122fcf5cdb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 731C520048; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Date: Sun, 14 Oct 2007 17:03:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8WwADLs1cA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com > ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com><80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com><1192172786.17547.19.camel@n85.nomadiclab.com><1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Salvatore Loreto" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:03:42.0959 (UTC) FILETIME=[693BFrom sip-bounces@ietf.org Sun Oct 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50S-00086U-3s; Sun, 14 Oct 2007 11:03:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih50Q-000869-B3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50Q-00081u-07 for sip@ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ih50K-00035I-8p for sip@ietf.org; Sun, 14 Oct 2007 11:03:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C31F204D3; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-d2-47122fcf5cdb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 731C520048; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Date: Sun, 14 Oct 2007 17:03:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8WwADLs1cA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com > ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com><80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com><1192172786.17547.19.camel@n85.nomadiclab.com><1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Salvatore Loreto" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:03:42.0959 (UTC) FILETIME=[693BFrom sip-bounces@ietf.org Sun Oct 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50S-00086U-3s; Sun, 14 Oct 2007 11:03:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih50Q-000869-B3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50Q-00081u-07 for sip@ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ih50K-00035I-8p for sip@ietf.org; Sun, 14 Oct 2007 11:03:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C31F204D3; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-d2-47122fcf5cdb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 731C520048; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Date: Sun, 14 Oct 2007 17:03:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8WwADLs1cA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com > ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com><80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com><1192172786.17547.19.camel@n85.nomadiclab.com><1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Salvatore Loreto" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:03:42.0959 (UTC) FILETIME=[693BFrom sip-bounces@ietf.org Sun Oct 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50S-00086U-3s; Sun, 14 Oct 2007 11:03:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih50Q-000869-B3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih50Q-00081u-07 for sip@ietf.org; Sun, 14 Oct 2007 11:03:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ih50K-00035I-8p for sip@ietf.org; Sun, 14 Oct 2007 11:03:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C31F204D3; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-d2-47122fcf5cdb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 731C520048; Sun, 14 Oct 2007 17:03:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:03:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Date: Sun, 14 Oct 2007 17:03:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguingabout when we say INFO?) Thread-Index: AcgNc2L2ePuLAOL7RsGdIBTlp5C8qgAND8WwADLs1cA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.norte l!! .com > ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com><80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com><1192172786.17547.19.camel@n85.nomadiclab.com><1ECE0EB50388174790F9694F77522CCF12747307@zrc2hxm0.corp.nortel.com> <1192262939.4329.5.camel@localhost.localdomain> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Salvatore Loreto" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:03:42.0959 (UTC) FILETIME=[693B6FF0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List , 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: , Errors-To: sip-bounces@ietf.org =20 >You make it sound like there is some extra signaling involved=20 >in the subscriptions. I thought we were talking about=20 >*implicit* subscriptions. The only extra "signaling" would=20 >be event package negotiation exchange, presumably in headers=20 >in the Invite and responses. Then a Notify for the events. =20 >Or really instead of a NOTIFY, it could be a new method=20 >called "Invite-based Notification Function Output" or "INFO"=20 >for short. :) YES! :) Regards, Christer > > -----Original Message----- > > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > > Sent: Saturday, October 13, 2007 4:09 AM > > To: Francois Audet > > Cc: IETF SIP List; Christer Holmberg; Dean Willis > > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we=20 > > arguing about when we say INFO?) > > > > > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > > > the proposal is interesting. > > > > However there should be cases where you need to send whatever=20 > > > > information in both directions, or cases where when you send an=20 > > > > information via Notify you need to receive back some=20 > information=20 > > > > (e.g. > > > > the fact that you receive a 200Ok as answer to the Notify it is=20 > > > > not enough). > > > > How do you think your proposal should work in those cases ? > > > > perhaps with > > > > 2 subscription one in each direction? > > > > > > Yes. > > > > OK, I agree on this. > > But maybe should be interesting a mechanism to discriminate=20 > when you=20 > > need 2 subscription one in each direction, when one it is=20 > enough and=20 > > in the case of only one subscription the possibility to choose in=20 > > which direction you want to start it. > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007BZ-VH; Sun, 14 Oct 2007 11:01:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yR-00077m-0w for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-00077e-NO for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-0005TF-2t for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00CD82017B; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-5d-47122f4b43bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mail6FF0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List , 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: , Errors-To: sip-bounces@ietf.org =20 >You make it sound like there is some extra signaling involved=20 >in the subscriptions. I thought we were talking about=20 >*implicit* subscriptions. The only extra "signaling" would=20 >be event package negotiation exchange, presumably in headers=20 >in the Invite and responses. Then a Notify for the events. =20 >Or really instead of a NOTIFY, it could be a new method=20 >called "Invite-based Notification Function Output" or "INFO"=20 >for short. :) YES! :) Regards, Christer > > -----Original Message----- > > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > > Sent: Saturday, October 13, 2007 4:09 AM > > To: Francois Audet > > Cc: IETF SIP List; Christer Holmberg; Dean Willis > > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we=20 > > arguing about when we say INFO?) > > > > > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > > > the proposal is interesting. > > > > However there should be cases where you need to send whatever=20 > > > > information in both directions, or cases where when you send an=20 > > > > information via Notify you need to receive back some=20 > information=20 > > > > (e.g. > > > > the fact that you receive a 200Ok as answer to the Notify it is=20 > > > > not enough). > > > > How do you think your proposal should work in those cases ? > > > > perhaps with > > > > 2 subscription one in each direction? > > > > > > Yes. > > > > OK, I agree on this. > > But maybe should be interesting a mechanism to discriminate=20 > when you=20 > > need 2 subscription one in each direction, when one it is=20 > enough and=20 > > in the case of only one subscription the possibility to choose in=20 > > which direction you want to start it. > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007BZ-VH; Sun, 14 Oct 2007 11:01:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yR-00077m-0w for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-00077e-NO for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-0005TF-2t for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00CD82017B; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-5d-47122f4b43bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mail6FF0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List , 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: , Errors-To: sip-bounces@ietf.org =20 >You make it sound like there is some extra signaling involved=20 >in the subscriptions. I thought we were talking about=20 >*implicit* subscriptions. The only extra "signaling" would=20 >be event package negotiation exchange, presumably in headers=20 >in the Invite and responses. Then a Notify for the events. =20 >Or really instead of a NOTIFY, it could be a new method=20 >called "Invite-based Notification Function Output" or "INFO"=20 >for short. :) YES! :) Regards, Christer > > -----Original Message----- > > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > > Sent: Saturday, October 13, 2007 4:09 AM > > To: Francois Audet > > Cc: IETF SIP List; Christer Holmberg; Dean Willis > > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we=20 > > arguing about when we say INFO?) > > > > > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > > > the proposal is interesting. > > > > However there should be cases where you need to send whatever=20 > > > > information in both directions, or cases where when you send an=20 > > > > information via Notify you need to receive back some=20 > information=20 > > > > (e.g. > > > > the fact that you receive a 200Ok as answer to the Notify it is=20 > > > > not enough). > > > > How do you think your proposal should work in those cases ? > > > > perhaps with > > > > 2 subscription one in each direction? > > > > > > Yes. > > > > OK, I agree on this. > > But maybe should be interesting a mechanism to discriminate=20 > when you=20 > > need 2 subscription one in each direction, when one it is=20 > enough and=20 > > in the case of only one subscription the possibility to choose in=20 > > which direction you want to start it. > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007BZ-VH; Sun, 14 Oct 2007 11:01:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yR-00077m-0w for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-00077e-NO for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-0005TF-2t for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00CD82017B; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-5d-47122f4b43bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mail6FF0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List , 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: , Errors-To: sip-bounces@ietf.org =20 >You make it sound like there is some extra signaling involved=20 >in the subscriptions. I thought we were talking about=20 >*implicit* subscriptions. The only extra "signaling" would=20 >be event package negotiation exchange, presumably in headers=20 >in the Invite and responses. Then a Notify for the events. =20 >Or really instead of a NOTIFY, it could be a new method=20 >called "Invite-based Notification Function Output" or "INFO"=20 >for short. :) YES! :) Regards, Christer > > -----Original Message----- > > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > > Sent: Saturday, October 13, 2007 4:09 AM > > To: Francois Audet > > Cc: IETF SIP List; Christer Holmberg; Dean Willis > > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we=20 > > arguing about when we say INFO?) > > > > > > > > On Fri, 2007-10-12 at 09:50 -0500, Francois Audet wrote: > > > > > > > the proposal is interesting. > > > > However there should be cases where you need to send whatever=20 > > > > information in both directions, or cases where when you send an=20 > > > > information via Notify you need to receive back some=20 > information=20 > > > > (e.g. > > > > the fact that you receive a 200Ok as answer to the Notify it is=20 > > > > not enough). > > > > How do you think your proposal should work in those cases ? > > > > perhaps with > > > > 2 subscription one in each direction? > > > > > > Yes. > > > > OK, I agree on this. > > But maybe should be interesting a mechanism to discriminate=20 > when you=20 > > need 2 subscription one in each direction, when one it is=20 > enough and=20 > > in the case of only one subscription the possibility to choose in=20 > > which direction you want to start it. > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007BZ-VH; Sun, 14 Oct 2007 11:01:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yR-00077m-0w for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-00077e-NO for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-0005TF-2t for sip@ietf.org; Sun, 14 Oct 2007 11:01:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00CD82017B; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-5d-47122f4b43bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sun, 14 Oct 2007 17:01:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8A References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 14 Oct 2007 15:01:31.0385 (UTC) FILETIME=[1ACED690:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Errors-To: sip-bounces@ietf.org Hi, As I have said before: you have similar problems with other mechanisms. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 12:45 > To: Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > Routing of the message once it gets to the device=20 > (application), not route to the device (transport). >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger; Hadriel Kaplan > Cc: sip > Sent: Thu Oct 11 19:38:06 2007 > Subject: RE: [Sip] INFO >=20 >=20 > Hi Eric, >=20 > I am not sure I understand what you mean, but INFOs are=20 > routed according to the route set of the invite dialog they=20 > are sent within. >=20 > If you want to transport information using some other path=20 > you can of course not send the information within the invite dialog. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 0:35 > > To: Christer Holmberg; Hadriel Kaplan > > Cc: sip > > Subject: Re: [Sip] INFO > >=20 > > Right: "DTMF may not be the only information users want to send to=20 > > each other during a session." This is why one MUST=20 > establish multiple=20 > > subscription dialogs. How else would one keep track of the=20 > different=20 > > elements / local routing decisions? If you are proposing=20 > application=20 > > routing a'la P-Asserted-Service... > >=20 > >=20 > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > wrote: > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > Let's also keep in mind that DTMF may not be the only information=20 > > > users want to send to each other during a session. So, you=20 > > will need=20 > > > to establish subscription dialogs for every type of event=20 > that the=20 > > > users may want to send during the session... > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> [mailto:christer.holmberg@ericsson.com] > > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sun, 14 Oct 2007 17:01:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8A References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 14 Oct 2007 15:01:31.0385 (UTC) FILETIME=[1ACED690:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Errors-To: sip-bounces@ietf.org Hi, As I have said before: you have similar problems with other mechanisms. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 12:45 > To: Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > Routing of the message once it gets to the device=20 > (application), not route to the device (transport). >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger; Hadriel Kaplan > Cc: sip > Sent: Thu Oct 11 19:38:06 2007 > Subject: RE: [Sip] INFO >=20 >=20 > Hi Eric, >=20 > I am not sure I understand what you mean, but INFOs are=20 > routed according to the route set of the invite dialog they=20 > are sent within. >=20 > If you want to transport information using some other path=20 > you can of course not send the information within the invite dialog. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 0:35 > > To: Christer Holmberg; Hadriel Kaplan > > Cc: sip > > Subject: Re: [Sip] INFO > >=20 > > Right: "DTMF may not be the only information users want to send to=20 > > each other during a session." This is why one MUST=20 > establish multiple=20 > > subscription dialogs. How else would one keep track of the=20 > different=20 > > elements / local routing decisions? If you are proposing=20 > application=20 > > routing a'la P-Asserted-Service... > >=20 > >=20 > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > wrote: > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > Let's also keep in mind that DTMF may not be the only information=20 > > > users want to send to each other during a session. So, you=20 > > will need=20 > > > to establish subscription dialogs for every type of event=20 > that the=20 > > > users may want to send during the session... > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> [mailto:christer.holmberg@ericsson.com] > > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sun, 14 Oct 2007 17:01:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8A References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 14 Oct 2007 15:01:31.0385 (UTC) FILETIME=[1ACED690:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Errors-To: sip-bounces@ietf.org Hi, As I have said before: you have similar problems with other mechanisms. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 12:45 > To: Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > Routing of the message once it gets to the device=20 > (application), not route to the device (transport). >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger; Hadriel Kaplan > Cc: sip > Sent: Thu Oct 11 19:38:06 2007 > Subject: RE: [Sip] INFO >=20 >=20 > Hi Eric, >=20 > I am not sure I understand what you mean, but INFOs are=20 > routed according to the route set of the invite dialog they=20 > are sent within. >=20 > If you want to transport information using some other path=20 > you can of course not send the information within the invite dialog. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 0:35 > > To: Christer Holmberg; Hadriel Kaplan > > Cc: sip > > Subject: Re: [Sip] INFO > >=20 > > Right: "DTMF may not be the only information users want to send to=20 > > each other during a session." This is why one MUST=20 > establish multiple=20 > > subscription dialogs. How else would one keep track of the=20 > different=20 > > elements / local routing decisions? If you are proposing=20 > application=20 > > routing a'la P-Asserted-Service... > >=20 > >=20 > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > wrote: > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > Let's also keep in mind that DTMF may not be the only information=20 > > > users want to send to each other during a session. So, you=20 > > will need=20 > > > to establish subscription dialogs for every type of event=20 > that the=20 > > > users may want to send during the session... > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> [mailto:christer.holmberg@ericsson.com] > > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sun, 14 Oct 2007 17:01:30 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8A References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 14 Oct 2007 15:01:31.0385 (UTC) FILETIME=[1ACED690:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Errors-To: sip-bounces@ietf.org Hi, As I have said before: you have similar problems with other mechanisms. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 12. lokakuuta 2007 12:45 > To: Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO >=20 > Routing of the message once it gets to the device=20 > (application), not route to the device (transport). >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger; Hadriel Kaplan > Cc: sip > Sent: Thu Oct 11 19:38:06 2007 > Subject: RE: [Sip] INFO >=20 >=20 > Hi Eric, >=20 > I am not sure I understand what you mean, but INFOs are=20 > routed according to the route set of the invite dialog they=20 > are sent within. >=20 > If you want to transport information using some other path=20 > you can of course not send the information within the invite dialog. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 0:35 > > To: Christer Holmberg; Hadriel Kaplan > > Cc: sip > > Subject: Re: [Sip] INFO > >=20 > > Right: "DTMF may not be the only information users want to send to=20 > > each other during a session." This is why one MUST=20 > establish multiple=20 > > subscription dialogs. How else would one keep track of the=20 > different=20 > > elements / local routing decisions? If you are proposing=20 > application=20 > > routing a'la P-Asserted-Service... > >=20 > >=20 > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > wrote: > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > Let's also keep in mind that DTMF may not be the only information=20 > > > users want to send to each other during a session. So, you=20 > > will need=20 > > > to establish subscription dialogs for every type of event=20 > that the=20 > > > users may want to send during the session... > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> [mailto:christer.holmberg@ericsson.com] > > >> Sent: 11. syyskuuta 2007 12:27 > > >> To: Hadriel Kaplan; Eric Burger > > >> Cc: sip > > >> Subject: RE: [Sip] INFO > > >>=20 > > >>=20 > > >> Hi, > > >>=20 > > >>>> Consider a PSTN call. The call goes from the gateway to > > >> softswitch / > > >>>> Proxy. Proxy routes to VM App Server. INFO has to=20 > pass through=20 > > >>>> softswitch / Proxy. > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > > key press > > >> state, bypassing the softswitch. > > >>=20 > > >> [Christer] As I've said before, there are environments=20 > where some=20 > > >> proxies must (for whatever reason) be passed through. I guess an=20 > > >> outbound proxy is a good example. > > >>=20 > > >>>> KPML and INFO have the same number of messages for a=20 > > SINGLE digit; > > >> KPML wins > > >>>> hands-down for multiple digits or reports. > > >>>=20 > > >>> Not exactly - for a single digit, KPML would generate a=20 > > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > > pressed -=20 > > >>> before the actual Notify with the digits in it. > > >>> And of course there is now also a subscribe dialog involved. > > >>> Assuming a one-shot single digit type, then, we're=20 > talking 6 SIP=20 > > >>> messages for KPML vs. 2 for Info. > > >>=20 > > >> [Christer] And, in cases where you need to send DTMFs=20 > (or whatever > > >> information) in both directions you actually need 2 subscription=20 > > >> dialogs > > >> - one in each direction, and maintaining dialog state also=20 > > consumes=20 > > >> resources. And, in some cases you may not even know=20 > > whether you will=20 > > >> ever have to use the dialog. > > >>=20 > > >>=20 > > >>>> More importantly, let's take a Call Management (CM) > > >> application that > > >>>> calls a VM application when they cannot find the > > >> subscriber. INFO has > > >>=20 > > >>>> to pass through the softswitch / Proxy to the CM > > >> application. Cool - > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > > application=20 > > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > > could be a=20 > > >>>> good programmer and remember to do that EVERYWHERE you=20 > place an=20 > > >>>> outbound call, but it is really easy to get wrong. > > >>>=20 > > >>> I'm not sure I understand the scenario. The VM learned=20 > > about this=20 > > >>> call how? > > >>> By being in the signaling path, no? So why wouldn't the=20 > > CM forward=20 > > >>> INFO along the path? (I mean it is in the same dialog,=20 > > after all) =20 > > >>> Now I don't doubt it could screw that up, and eat the=20 > > info thinking=20 > > >>> it was for itself, but lots of things can get screwed up=20 > > - my guess=20 > > >>> is KPML will not be impervious to screw ups. > > >>=20 > > >> [Christer] I also have problems understanding the=20 > > scenario. INFO is=20 > > >> routed to wherever the INVITE that initiated the dialog=20 > > was routed... > > >>=20 > > >> Regards, > > >>=20 > > >> Christer > > >>=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=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >>=20 > > >=20 > >=20 > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confideuta 2007 12:27 > > >> To: Hadriel Kaplan; Eric Burger > > >> Cc: sip > > >> Subject: RE: [Sip] INFO > > >>=20 > > >>=20 > > >> Hi, > > >>=20 > > >>>> Consider a PSTN call. The call goes from the gateway to > > >> softswitch / > > >>>> Proxy. Proxy routes to VM App Server. INFO has to=20 > pass through=20 > > >>>> softswitch / Proxy. > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > > key press > > >> state, bypassing the softswitch. > > >>=20 > > >> [Christer] As I've said before, there are environments=20 > where some=20 > > >> proxies must (for whatever reason) be passed through. I guess an=20 > > >> outbound proxy is a good example. > > >>=20 > > >>>> KPML and INFO have the same number of messages for a=20 > > SINGLE digit; > > >> KPML wins > > >>>> hands-down for multiple digits or reports. > > >>>=20 > > >>> Not exactly - for a single digit, KPML would generate a=20 > > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > > pressed -=20 > > >>> before the actual Notify with the digits in it. > > >>> And of course there is now also a subscribe dialog involved. > > >>> Assuming a one-shot single digit type, then, we're=20 > talking 6 SIP=20 > > >>> messages for KPML vs. 2 for Info. > > >>=20 > > >> [Christer] And, in cases where you need to send DTMFs=20 > (or whatever > > >> information) in both directions you actually need 2 subscription=20 > > >> dialogs > > >> - one in each direction, and maintaining dialog state also=20 > > consumes=20 > > >> resources. And, in some cases you may not even know=20 > > whether you will=20 > > >> ever have to use the dialog. > > >>=20 > > >>=20 > > >>>> More importantly, let's take a Call Management (CM) > > >> application that > > >>>> calls a VM application when they cannot find the > > >> subscriber. INFO has > > >>=20 > > >>>> to pass through the softswitch / Proxy to the CM > > >> application. Cool - > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > > application=20 > > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > > could be a=20 > > >>>> good programmer and remember to do that EVERYWHERE you=20 > place an=20 > > >>>> outbound call, but it is really easy to get wrong. > > >>>=20 > > >>> I'm not sure I understand the scenario. The VM learned=20 > > about this=20 > > >>> call how? > > >>> By being in the signaling path, no? So why wouldn't the=20 > > CM forward=20 > > >>> INFO along the path? (I mean it is in the same dialog,=20 > > after all) =20 > > >>> Now I don't doubt it could screw that up, and eat the=20 > > info thinking=20 > > >>> it was for itself, but lots of things can get screwed up=20 > > - my guess=20 > > >>> is KPML will not be impervious to screw ups. > > >>=20 > > >> [Christer] I also have problems understanding the=20 > > scenario. INFO is=20 > > >> routed to wherever the INVITE that initiated the dialog=20 > > was routed... > > >>=20 > > >> Regards, > > >>=20 > > >> Christer > > >>=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=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >>=20 > > >=20 > >=20 > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confideuta 2007 12:27 > > >> To: Hadriel Kaplan; Eric Burger > > >> Cc: sip > > >> Subject: RE: [Sip] INFO > > >>=20 > > >>=20 > > >> Hi, > > >>=20 > > >>>> Consider a PSTN call. The call goes from the gateway to > > >> softswitch / > > >>>> Proxy. Proxy routes to VM App Server. INFO has to=20 > pass through=20 > > >>>> softswitch / Proxy. > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > > key press > > >> state, bypassing the softswitch. > > >>=20 > > >> [Christer] As I've said before, there are environments=20 > where some=20 > > >> proxies must (for whatever reason) be passed through. I guess an=20 > > >> outbound proxy is a good example. > > >>=20 > > >>>> KPML and INFO have the same number of messages for a=20 > > SINGLE digit; > > >> KPML wins > > >>>> hands-down for multiple digits or reports. > > >>>=20 > > >>> Not exactly - for a single digit, KPML would generate a=20 > > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > > pressed -=20 > > >>> before the actual Notify with the digits in it. > > >>> And of course there is now also a subscribe dialog involved. > > >>> Assuming a one-shot single digit type, then, we're=20 > talking 6 SIP=20 > > >>> messages for KPML vs. 2 for Info. > > >>=20 > > >> [Christer] And, in cases where you need to send DTMFs=20 > (or whatever > > >> information) in both directions you actually need 2 subscription=20 > > >> dialogs > > >> - one in each direction, and maintaining dialog state also=20 > > consumes=20 > > >> resources. And, in some cases you may not even know=20 > > whether you will=20 > > >> ever have to use the dialog. > > >>=20 > > >>=20 > > >>>> More importantly, let's take a Call Management (CM) > > >> application that > > >>>> calls a VM application when they cannot find the > > >> subscriber. INFO has > > >>=20 > > >>>> to pass through the softswitch / Proxy to the CM > > >> application. Cool - > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > > application=20 > > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > > could be a=20 > > >>>> good programmer and remember to do that EVERYWHERE you=20 > place an=20 > > >>>> outbound call, but it is really easy to get wrong. > > >>>=20 > > >>> I'm not sure I understand the scenario. The VM learned=20 > > about this=20 > > >>> call how? > > >>> By being in the signaling path, no? So why wouldn't the=20 > > CM forward=20 > > >>> INFO along the path? (I mean it is in the same dialog,=20 > > after all) =20 > > >>> Now I don't doubt it could screw that up, and eat the=20 > > info thinking=20 > > >>> it was for itself, but lots of things can get screwed up=20 > > - my guess=20 > > >>> is KPML will not be impervious to screw ups. > > >>=20 > > >> [Christer] I also have problems understanding the=20 > > scenario. INFO is=20 > > >> routed to wherever the INVITE that initiated the dialog=20 > > was routed... > > >>=20 > > >> Regards, > > >>=20 > > >> Christer > > >>=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=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >>=20 > > >=20 > >=20 > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confideuta 2007 12:27 > > >> To: Hadriel Kaplan; Eric Burger > > >> Cc: sip > > >> Subject: RE: [Sip] INFO > > >>=20 > > >>=20 > > >> Hi, > > >>=20 > > >>>> Consider a PSTN call. The call goes from the gateway to > > >> softswitch / > > >>>> Proxy. Proxy routes to VM App Server. INFO has to=20 > pass through=20 > > >>>> softswitch / Proxy. > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC=20 > > key press > > >> state, bypassing the softswitch. > > >>=20 > > >> [Christer] As I've said before, there are environments=20 > where some=20 > > >> proxies must (for whatever reason) be passed through. I guess an=20 > > >> outbound proxy is a good example. > > >>=20 > > >>>> KPML and INFO have the same number of messages for a=20 > > SINGLE digit; > > >> KPML wins > > >>>> hands-down for multiple digits or reports. > > >>>=20 > > >>> Not exactly - for a single digit, KPML would generate a=20 > > >>> Subscribe/200/Notify/200 before the single DTMF was even=20 > > pressed -=20 > > >>> before the actual Notify with the digits in it. > > >>> And of course there is now also a subscribe dialog involved. > > >>> Assuming a one-shot single digit type, then, we're=20 > talking 6 SIP=20 > > >>> messages for KPML vs. 2 for Info. > > >>=20 > > >> [Christer] And, in cases where you need to send DTMFs=20 > (or whatever > > >> information) in both directions you actually need 2 subscription=20 > > >> dialogs > > >> - one in each direction, and maintaining dialog state also=20 > > consumes=20 > > >> resources. And, in some cases you may not even know=20 > > whether you will=20 > > >> ever have to use the dialog. > > >>=20 > > >>=20 > > >>>> More importantly, let's take a Call Management (CM) > > >> application that > > >>>> calls a VM application when they cannot find the > > >> subscriber. INFO has > > >>=20 > > >>>> to pass through the softswitch / Proxy to the CM > > >> application. Cool - > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM=20 > > application=20 > > >>>> has to proxy the INFOs to the VM application. Yes - you=20 > > could be a=20 > > >>>> good programmer and remember to do that EVERYWHERE you=20 > place an=20 > > >>>> outbound call, but it is really easy to get wrong. > > >>>=20 > > >>> I'm not sure I understand the scenario. The VM learned=20 > > about this=20 > > >>> call how? > > >>> By being in the signaling path, no? So why wouldn't the=20 > > CM forward=20 > > >>> INFO along the path? (I mean it is in the same dialog,=20 > > after all) =20 > > >>> Now I don't doubt it could screw that up, and eat the=20 > > info thinking=20 > > >>> it was for itself, but lots of things can get screwed up=20 > > - my guess=20 > > >>> is KPML will not be impervious to screw ups. > > >>=20 > > >> [Christer] I also have problems understanding the=20 > > scenario. INFO is=20 > > >> routed to wherever the INVITE that initiated the dialog=20 > > was routed... > > >>=20 > > >> Regards, > > >>=20 > > >> Christer > > >>=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=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >>=20 > > >=20 > >=20 > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yT-0007Bh-Rq; Sun, 14 Oct 2007 11:01:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yS-0007BU-L3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007Au-B9 for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-0005Ta-Up for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A38720221; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-64-47122f5a734c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 36DF820101; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Sun, 14 Oct 2007 17:01:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM70L092FzRUSXRt6sec0ZzBhyhAAfERwg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> ntial, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yT-0007Bh-Rq; Sun, 14 Oct 2007 11:01:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yS-0007BU-L3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007Au-B9 for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-0005Ta-Up for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A38720221; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-64-47122f5a734c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 36DF820101; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Sun, 14 Oct 2007 17:01:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM70L092FzRUSXRt6sec0ZzBhyhAAfERwg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> ntial, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yT-0007Bh-Rq; Sun, 14 Oct 2007 11:01:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yS-0007BU-L3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007Au-B9 for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-0005Ta-Up for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A38720221; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-64-47122f5a734c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 36DF820101; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Sun, 14 Oct 2007 17:01:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM70L092FzRUSXRt6sec0ZzBhyhAAfERwg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> ntial, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yT-0007Bh-Rq; Sun, 14 Oct 2007 11:01:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yS-0007BU-L3 for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yS-0007Au-B9 for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yQ-0005Ta-Up for sip@ietf.org; Sun, 14 Oct 2007 11:01:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A38720221; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-64-47122f5a734c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 36DF820101; Sun, 14 Oct 2007 17:01:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Sun, 14 Oct 2007 17:01:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgM70L092FzRUSXRt6sec0ZzBhyhAAfERwg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 14 Oct 2007 15:01:45.0958 (UTC) FILETIME=[237E8060:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 [Christer] The questions you ask in your e-mail I think we need to get an answer to in any case, no matter what/if we do with INFO. My opinions in-line. >>There is one major downside to this. >> >>If we are sending stuff in the dialog, it really ought to have some=20 >>relation to the dialog, not just be included there because the dialog=20 >>happened to exist.....then you end up with people wanting to route the >>dialog to a centralised point where you can extract this piggy-backed=20 >>information ... Then you end up with a stimulus protocol between this=20 >>UE and this centralised server where the dialog contains absolutely no >>knowledge of the state of the session. >> >>Providing an in dialog mechanism makes it much harder to to stop this=20 >>happening. >=20 >That's back to the question of "Is SIP an application protocol or a transport protocol"? >=20 >Should the SIP-layer software be aware of and coupled to the state of the application that's using SIP? [Christer] No. >If so, then the proper design model is to build a new SIP request method for every new piece of application=20 >functionality. [Christer] No. That is unflexible, doesn't help innovation and deployments of applications, and considering the time it takes to get stuff through the IETF process (there would be lots of discussions about the application itself, which has nothing to do with the SIP protocol and how it is used )it probably would mean that people would use non-standard mechanisms anyway. Our job is to provide tools for people doing applications. =20 >So for example, DTMF: Using this model of SIP extension, we=20 >might define a new "DTMF" method. It would look just like=20 >DTMF-over-INFO, except the name of the method would be DTMF.=20 >It clearly resolves the INFO-context question, because now we=20 >KNOW we're getting dialog- related DTMF over it, and we know=20 >what to do with it. We know what we can transport in=20 >DTMF-requests, because the RFC that defines the DTMF=20 >extension method will also define exactly what payload format to use. >=20 >This too is a clean solution to the problem, although it=20 >embodies a different design philosophy than the same-dialog NOTIFY. [Christer] I don't think we need a DTMF method. We may solve one issue, but tomorrow there may a new one... =20 >This leads back to my question: What is the right extension=20 >modality for SIP? Until we have an answer here, we're going=20 >to keep going back and forth on this. MAKE A DECISION, PEOPLE! [Christer] My question is: are we really talking about SIP extension here? Yes, in order to make INFO work (or if we would do something related to in-dialog notifications), we may have to do something. But, after that is done, we don't need to extend anything. People using INFO (or something else) may have to register whatever packages/content-types etc etc, but that is not an extension of the protocol. Regards, Christer =20 >Now for the bad news: People are still having this argument=20 >about HTTP (we had it during XCAP in the GET/PUT vs POST=20 >debate) even though the real world has proven dramatically by=20 >example that From: "Christer Holmberg" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 14 Oct 2007 15:01:45.0958 (UTC) FILETIME=[237E8060:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 [Christer] The questions you ask in your e-mail I think we need to get an answer to in any case, no matter what/if we do with INFO. My opinions in-line. >>There is one major downside to this. >> >>If we are sending stuff in the dialog, it really ought to have some=20 >>relation to the dialog, not just be included there because the dialog=20 >>happened to exist.....then you end up with people wanting to route the >>dialog to a centralised point where you can extract this piggy-backed=20 >>information ... Then you end up with a stimulus protocol between this=20 >>UE and this centralised server where the dialog contains absolutely no >>knowledge of the state of the session. >> >>Providing an in dialog mechanism makes it much harder to to stop this=20 >>happening. >=20 >That's back to the question of "Is SIP an application protocol or a transport protocol"? >=20 >Should the SIP-layer software be aware of and coupled to the state of the application that's using SIP? [Christer] No. >If so, then the proper design model is to build a new SIP request method for every new piece of application=20 >functionality. [Christer] No. That is unflexible, doesn't help innovation and deployments of applications, and considering the time it takes to get stuff through the IETF process (there would be lots of discussions about the application itself, which has nothing to do with the SIP protocol and how it is used )it probably would mean that people would use non-standard mechanisms anyway. Our job is to provide tools for people doing applications. =20 >So for example, DTMF: Using this model of SIP extension, we=20 >might define a new "DTMF" method. It would look just like=20 >DTMF-over-INFO, except the name of the method would be DTMF.=20 >It clearly resolves the INFO-context question, because now we=20 >KNOW we're getting dialog- related DTMF over it, and we know=20 >what to do with it. We know what we can transport in=20 >DTMF-requests, because the RFC that defines the DTMF=20 >extension method will also define exactly what payload format to use. >=20 >This too is a clean solution to the problem, although it=20 >embodies a different design philosophy than the same-dialog NOTIFY. [Christer] I don't think we need a DTMF method. We may solve one issue, but tomorrow there may a new one... =20 >This leads back to my question: What is the right extension=20 >modality for SIP? Until we have an answer here, we're going=20 >to keep going back and forth on this. MAKE A DECISION, PEOPLE! [Christer] My question is: are we really talking about SIP extension here? Yes, in order to make INFO work (or if we would do something related to in-dialog notifications), we may have to do something. But, after that is done, we don't need to extend anything. People using INFO (or something else) may have to register whatever packages/content-types etc etc, but that is not an extension of the protocol. Regards, Christer =20 >Now for the bad news: People are still having this argument=20 >about HTTP (we had it during XCAP in the GET/PUT vs POST=20 >debate) even though the real world has proven dramatically by=20 >example that From: "Christer Holmberg" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 14 Oct 2007 15:01:45.0958 (UTC) FILETIME=[237E8060:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 [Christer] The questions you ask in your e-mail I think we need to get an answer to in any case, no matter what/if we do with INFO. My opinions in-line. >>There is one major downside to this. >> >>If we are sending stuff in the dialog, it really ought to have some=20 >>relation to the dialog, not just be included there because the dialog=20 >>happened to exist.....then you end up with people wanting to route the >>dialog to a centralised point where you can extract this piggy-backed=20 >>information ... Then you end up with a stimulus protocol between this=20 >>UE and this centralised server where the dialog contains absolutely no >>knowledge of the state of the session. >> >>Providing an in dialog mechanism makes it much harder to to stop this=20 >>happening. >=20 >That's back to the question of "Is SIP an application protocol or a transport protocol"? >=20 >Should the SIP-layer software be aware of and coupled to the state of the application that's using SIP? [Christer] No. >If so, then the proper design model is to build a new SIP request method for every new piece of application=20 >functionality. [Christer] No. That is unflexible, doesn't help innovation and deployments of applications, and considering the time it takes to get stuff through the IETF process (there would be lots of discussions about the application itself, which has nothing to do with the SIP protocol and how it is used )it probably would mean that people would use non-standard mechanisms anyway. Our job is to provide tools for people doing applications. =20 >So for example, DTMF: Using this model of SIP extension, we=20 >might define a new "DTMF" method. It would look just like=20 >DTMF-over-INFO, except the name of the method would be DTMF.=20 >It clearly resolves the INFO-context question, because now we=20 >KNOW we're getting dialog- related DTMF over it, and we know=20 >what to do with it. We know what we can transport in=20 >DTMF-requests, because the RFC that defines the DTMF=20 >extension method will also define exactly what payload format to use. >=20 >This too is a clean solution to the problem, although it=20 >embodies a different design philosophy than the same-dialog NOTIFY. [Christer] I don't think we need a DTMF method. We may solve one issue, but tomorrow there may a new one... =20 >This leads back to my question: What is the right extension=20 >modality for SIP? Until we have an answer here, we're going=20 >to keep going back and forth on this. MAKE A DECISION, PEOPLE! [Christer] My question is: are we really talking about SIP extension here? Yes, in order to make INFO work (or if we would do something related to in-dialog notifications), we may have to do something. But, after that is done, we don't need to extend anything. People using INFO (or something else) may have to register whatever packages/content-types etc etc, but that is not an extension of the protocol. Regards, Christer =20 >Now for the bad news: People are still having this argument=20 >about HTTP (we had it during XCAP in the GET/PUT vs POST=20 >debate) even though the real world has proven dramatically by=20 >example that From: "Christer Holmberg" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 14 Oct 2007 15:01:45.0958 (UTC) FILETIME=[237E8060:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 [Christer] The questions you ask in your e-mail I think we need to get an answer to in any case, no matter what/if we do with INFO. My opinions in-line. >>There is one major downside to this. >> >>If we are sending stuff in the dialog, it really ought to have some=20 >>relation to the dialog, not just be included there because the dialog=20 >>happened to exist.....then you end up with people wanting to route the >>dialog to a centralised point where you can extract this piggy-backed=20 >>information ... Then you end up with a stimulus protocol between this=20 >>UE and this centralised server where the dialog contains absolutely no >>knowledge of the state of the session. >> >>Providing an in dialog mechanism makes it much harder to to stop this=20 >>happening. >=20 >That's back to the question of "Is SIP an application protocol or a transport protocol"? >=20 >Should the SIP-layer software be aware of and coupled to the state of the application that's using SIP? [Christer] No. >If so, then the proper design model is to build a new SIP request method for every new piece of application=20 >functionality. [Christer] No. That is unflexible, doesn't help innovation and deployments of applications, and considering the time it takes to get stuff through the IETF process (there would be lots of discussions about the application itself, which has nothing to do with the SIP protocol and how it is used )it probably would mean that people would use non-standard mechanisms anyway. Our job is to provide tools for people doing applications. =20 >So for example, DTMF: Using this model of SIP extension, we=20 >might define a new "DTMF" method. It would look just like=20 >DTMF-over-INFO, except the name of the method would be DTMF.=20 >It clearly resolves the INFO-context question, because now we=20 >KNOW we're getting dialog- related DTMF over it, and we know=20 >what to do with it. We know what we can transport in=20 >DTMF-requests, because the RFC that defines the DTMF=20 >extension method will also define exactly what payload format to use. >=20 >This too is a clean solution to the problem, although it=20 >embodies a different design philosophy than the same-dialog NOTIFY. [Christer] I don't think we need a DTMF method. We may solve one issue, but tomorrow there may a new one... =20 >This leads back to my question: What is the right extension=20 >modality for SIP? Until we have an answer here, we're going=20 >to keep going back and forth on this. MAKE A DECISION, PEOPLE! [Christer] My question is: are we really talking about SIP extension here? Yes, in order to make INFO work (or if we would do something related to in-dialog notifications), we may have to do something. But, after that is done, we don't need to extend anything. People using INFO (or something else) may have to register whatever packages/content-types etc etc, but that is not an extension of the protocol. Regards, Christer =20 >Now for the bad news: People are still having this argument=20 >about HTTP (we had it during XCAP in the GET/PUT vs POST=20 >debate) even though the real world has proven dramatically by=20 >example that HTTP is a transport protocol and is=20 >protocol-wise completely decoupled from the state of the=20 >application (see AJAX as an example). >=20 > -- > Dean >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yR-00078D-7m; Sun, 14 Oct 2007 11:01:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yP-00077Z-Oz for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-00077R-FG for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yO-0005TM-4G for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EFCA201B3; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-61-47122f52bc6d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7413F20101; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Sun, 14 Oct 2007 17:01:37 +0200 Message-ID: In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgMPvxpYI9xWRQDQbmavNIVfix2kAAk1s8gACby+aA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@seHTTP is a transport protocol and is=20 >protocol-wise completely decoupled from the state of the=20 >application (see AJAX as an example). >=20 > -- > Dean >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yR-00078D-7m; Sun, 14 Oct 2007 11:01:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yP-00077Z-Oz for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-00077R-FG for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yO-0005TM-4G for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EFCA201B3; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-61-47122f52bc6d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7413F20101; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Sun, 14 Oct 2007 17:01:37 +0200 Message-ID: In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgMPvxpYI9xWRQDQbmavNIVfix2kAAk1s8gACby+aA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@seHTTP is a transport protocol and is=20 >protocol-wise completely decoupled from the state of the=20 >application (see AJAX as an example). >=20 > -- > Dean >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yR-00078D-7m; Sun, 14 Oct 2007 11:01:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yP-00077Z-Oz for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-00077R-FG for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yO-0005TM-4G for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EFCA201B3; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-61-47122f52bc6d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7413F20101; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Sun, 14 Oct 2007 17:01:37 +0200 Message-ID: In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgMPvxpYI9xWRQDQbmavNIVfix2kAAk1s8gACby+aA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@seHTTP is a transport protocol and is=20 >protocol-wise completely decoupled from the state of the=20 >application (see AJAX as an example). >=20 > -- > Dean >=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 14 11:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yR-00078D-7m; Sun, 14 Oct 2007 11:01:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ih4yP-00077Z-Oz for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih4yP-00077R-FG for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih4yO-0005TM-4G for sip@ietf.org; Sun, 14 Oct 2007 11:01:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EFCA201B3; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-61-47122f52bc6d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7413F20101; Sun, 14 Oct 2007 17:01:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Sun, 14 Oct 2007 17:01:37 +0200 Message-ID: In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgMPvxpYI9xWRQDQbmavNIVfix2kAAk1s8gACby+aA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> From: "Christer Holmberg" To: "Michael Procter" , "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:01:37.0963 (UTC) FILETIME=[1EBA8FB0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>INFO, as written, lacks contextual negotiation. You're proposing to=20 >>replace the method name with NOTIFY and use the event-package=20 >>framework for content and context expression, using a header-field in=20 >>the INVITE request to engage context negotiation. It seems to me like=20 >>that would work. There's nothing "implicit" about it, and it is no=20 >>worse for overhead than using Supported or Allow. It also has the=20 >>advantage of letting us reuse an existing registration framework, IANA >>process, and specification review process under RFC 3427.=20 >>Very tidy, I think I like it. >=20 >One area that would need defining very carefully is the=20 >question of subscription usage lifetimes. Tying them to the=20 >lifetime of the invite usage that caused them sounds quite=20 >tidy, and would prevent a flurry of NOTIFY/state=3Dterminated=20 >messages straight after a BYE. [Christer] Maybe these notifications could be sent in the BYE? And/or, maybe we could define a "dialog" value for subscription usage lifetime? I haven't thought about this proposal in detail yet, but we would also need to take the the dialog-reuse spec (which proposes NOT to mix dialog usages) into consideration. But, if we somehow could bind the subscription lifetime to the dialog lifetime I think that at least some of the issues in that spec would be solved. 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 a02-mxc01.citel.com> From: "Christer Holmberg" To: "Michael Procter" , "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:01:37.0963 (UTC) FILETIME=[1EBA8FB0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>INFO, as written, lacks contextual negotiation. You're proposing to=20 >>replace the method name with NOTIFY and use the event-package=20 >>framework for content and context expression, using a header-field in=20 >>the INVITE request to engage context negotiation. It seems to me like=20 >>that would work. There's nothing "implicit" about it, and it is no=20 >>worse for overhead than using Supported or Allow. It also has the=20 >>advantage of letting us reuse an existing registration framework, IANA >>process, and specification review process under RFC 3427.=20 >>Very tidy, I think I like it. >=20 >One area that would need defining very carefully is the=20 >question of subscription usage lifetimes. Tying them to the=20 >lifetime of the invite usage that caused them sounds quite=20 >tidy, and would prevent a flurry of NOTIFY/state=3Dterminated=20 >messages straight after a BYE. [Christer] Maybe these notifications could be sent in the BYE? And/or, maybe we could define a "dialog" value for subscription usage lifetime? I haven't thought about this proposal in detail yet, but we would also need to take the the dialog-reuse spec (which proposes NOT to mix dialog usages) into consideration. But, if we somehow could bind the subscription lifetime to the dialog lifetime I think that at least some of the issues in that spec would be solved. 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 a02-mxc01.citel.com> From: "Christer Holmberg" To: "Michael Procter" , "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:01:37.0963 (UTC) FILETIME=[1EBA8FB0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>INFO, as written, lacks contextual negotiation. You're proposing to=20 >>replace the method name with NOTIFY and use the event-package=20 >>framework for content and context expression, using a header-field in=20 >>the INVITE request to engage context negotiation. It seems to me like=20 >>that would work. There's nothing "implicit" about it, and it is no=20 >>worse for overhead than using Supported or Allow. It also has the=20 >>advantage of letting us reuse an existing registration framework, IANA >>process, and specification review process under RFC 3427.=20 >>Very tidy, I think I like it. >=20 >One area that would need defining very carefully is the=20 >question of subscription usage lifetimes. Tying them to the=20 >lifetime of the invite usage that caused them sounds quite=20 >tidy, and would prevent a flurry of NOTIFY/state=3Dterminated=20 >messages straight after a BYE. [Christer] Maybe these notifications could be sent in the BYE? And/or, maybe we could define a "dialog" value for subscription usage lifetime? I haven't thought about this proposal in detail yet, but we would also need to take the the dialog-reuse spec (which proposes NOT to mix dialog usages) into consideration. But, if we somehow could bind the subscription lifetime to the dialog lifetime I think that at least some of the issues in that spec would be solved. 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 a02-mxc01.citel.com> From: "Christer Holmberg" To: "Michael Procter" , "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 14 Oct 2007 15:01:37.0963 (UTC) FILETIME=[1EBA8FB0:01C80E73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>INFO, as written, lacks contextual negotiation. You're proposing to=20 >>replace the method name with NOTIFY and use the event-package=20 >>framework for content and context expression, using a header-field in=20 >>the INVITE request to engage context negotiation. It seems to me like=20 >>that would work. There's nothing "implicit" about it, and it is no=20 >>worse for overhead than using Supported or Allow. It also has the=20 >>advantage of letting us reuse an existing registration framework, IANA >>process, and specification review process under RFC 3427.=20 >>Very tidy, I think I like it. >=20 >One area that would need defining very carefully is the=20 >question of subscription usage lifetimes. Tying them to the=20 >lifetime of the invite usage that caused them sounds quite=20 >tidy, and would prevent a flurry of NOTIFY/state=3Dterminated=20 >messages straight after a BYE. [Christer] Maybe these notifications could be sent in the BYE? And/or, maybe we could define a "dialog" value for subscription usage lifetime? I haven't thought about this proposal in detail yet, but we would also need to take the the dialog-reuse spec (which proposes NOT to mix dialog usages) into consideration. But, if we somehow could bind the subscription lifetime to the dialog lifetime I think that at least some of the issues in that spec would be solved. 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 Sun Oct 14 17:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhB7O-0001zT-IT; Sun, 14 Oct 2007 17:35:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhB7M-0001yv-6A for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 17:35:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhB7L-0001ww-4S for sip@ietf.org; Sun, 14 Oct 2007 17:35:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhB7K-0002Ow-QS for sip@ietf.org; Sun, 14 Oct 2007 17:35:23 -0400 X-IronPort-AV: E=Sophos;i="4.21,274,1188802800"; d="scan'208";a="236951997" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2007 14:35:21 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ELZLd1025459; Sun, 14 Oct 2007 17:35:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ELZ2k7008987; Sun, 14 Oct 2007 21:35:02 GMT 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.1830); Sun, 14 Oct 2007 17:35:02 -0400 Received: from [10.86.242.72] ([10.86.242.72]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Oct 2007 17:35:01 -0400 Message-ID: <47128B84.9030208@cisco.com> Date: Sun, 14 Oct 2007 17:35:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2007 21:35:01.0819 (UTC) FILETIME=[13B928B0:01C80EAA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--21.096300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=882; t=1192397721; x=1193261721; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Francois'=20counter=20to=20INFO=20(was=20Re=3 A=20What=20are=20we=20arguing=0A=20aboutwhen=20we=20say=20INFO?) |Sender:=20 |To:=20Christer=20Holmberg=20; bh=W3aG2AH+47GO/17ogKcxRaayhrDXwEgxPGs5gWmdKIg=; b=I3SrLKadCuM2o4lQpWtwnLr75m3cBMocrMzrBqHOCoMue2QfjbITaZSFjKQjRZBvKsHSVHZy KQIJ3fjSWG6Tv8UrbzAJeRarzgyBOkplACD5xbUN8dVvVuo2++dr1oCV; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , Francois Audet , Michael Procter , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > I haven't thought about this proposal in detail yet, but we would also > need to take the the dialog-reuse spec (which proposes NOT to mix dialog > usages) into consideration. But, if we somehow could bind the > subscription lifetime to the dialog lifetime I think that at least some > of the issues in that spec would be solved. The lifetime of a dialog isn't an independent variable - it ends when the last dialog usage ends. If you are really talking about implicit *subscriptions*, then you either must explicitly end them, or else define their *implicit* end in terms of something that has an explicit endpoint. I expect that you are talking about something that either shares the invite dialog usage, or else a distinct dialog usage that implicitly starts and stops concurrently with the invite 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 Sun Oct 14 20:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhDO1-0005Ee-Vw; Sun, 14 Oct 2007 20:00:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhDNz-0005Dg-TK for sip-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 20:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhDNz-0005DV-4K for sip@ietf.org; Sun, 14 Oct 2007 20:00:43 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhDNs-0008DK-Gw for sip@ietf.org; Sun, 14 Oct 2007 20:00:43 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9F00I1u027779; Sun, 14 Oct 2007 17:00:18 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9F00HIj026743; Sun, 14 Oct 2007 17:00:17 -0700 Received: from 172.24.28.205 ([172.24.28.205]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Oct 2007 00:00:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 14 Oct 2007 19:52:53 -0400 Subject: Re: [Sip] INFO From: Eric Burger To: Christer Holmberg Message-ID: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8AAFOVHYA= In-Reply-To: Mime-version: 1.0 x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c 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: , Content-Type: multipart/mixed; boundary="===============1006418847==" Errors-To: sip-bounces@ietf.org --===============1006418847== Content-type: multipart/alternative; boundary="B_3275236816_4129000" --B_3275236816_4129000 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit No. For subscribe/notify interaction, it is trivial: whomever issues the subscribe gets the notify. Easy for the stack to figure out. For INFO interaction, everything goes to call control. That works if your model is pure softswitch/feature server, but not many folks are doing that anymore. On 10/14/07 11:01 AM, "Christer Holmberg" wrote: > > > Hi, > > As I have said before: you have similar problems with other mechanisms. > > Regards, > > Christer > >> > -----Original Message----- >> > From: Eric Burger [mailto:eburger@bea.com] >> > Sent: 12. lokakuuta 2007 12:45 >> > To: Christer Holmberg >> > Cc: sip@ietf.org >> > Subject: Re: [Sip] INFO >> > >> > Routing of the message once it gets to the device >> > (application), not route to the device (transport). >> > >> > -- >> > Sent from my wireless e-mail device. Sorry if terse. We all >> > need lemonade: see >> > for what lemonade is. >> > >> > ----- Original Message ----- >> > From: Christer Holmberg >> > To: Eric Burger; Hadriel Kaplan >> > Cc: sip >> > Sent: Thu Oct 11 19:38:06 2007 >> > Subject: RE: [Sip] INFO >> > >> > >> > Hi Eric, >> > >> > I am not sure I understand what you mean, but INFOs are >> > routed according to the route set of the invite dialog they >> > are sent within. >> > >> > If you want to transport information using some other path >> > you can of course not send the information within the invite dialog. >> > >> > Regards, >> > >> > Christer >> > >> > >>> > > -----Original Message----- >>> > > From: Eric Burger [mailto:eburger@bea.com] >>> > > Sent: 12. lokakuuta 2007 0:35 >>> > > To: Christer Holmberg; Hadriel Kaplan >>> > > Cc: sip >>> > > Subject: Re: [Sip] INFO >>> > > >>> > > Right: "DTMF may not be the only information users want to send to >>> > > each other during a session." This is why one MUST >> > establish multiple >>> > > subscription dialogs. How else would one keep track of the >> > different >>> > > elements / local routing decisions? If you are proposing >> > application >>> > > routing a'la P-Asserted-Service... >>> > > >>> > > >>> > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" >>> > > wrote: >>> > > >>>> > > > >>>> > > > >>>> > > > Hi, >>>> > > > >>>> > > > Let's also keep in mind that DTMF may not be the only information >>>> > > > users want to send to each other during a session. So, you >>> > > will need >>>> > > > to establish subscription dialogs for every type of event >> > that the >>>> > > > users may want to send during the session... >>>> > > > >>>> > > > Regards, >>>> > > > >>>> > > > Christer >>>> > > > >>>>> > > >> -----Original Message----- >>>>> > > >> From: Christer Holmberg (JO/LMF) >>>>> > > >> [mailto:christer.holmberg@ericsson.com] >>>>> > > >> Sent: 11. syyskuuta 2007 12:27 >>>>> > > >> To: Hadriel Kaplan; Eric Burger >>>>> > > >> Cc: sip >>>>> > > >> Subject: RE: [Sip] INFO >>>>> > > >> >>>>> > > >> >>>>> > > >> Hi, >>>>> > > >> >>>>>>> > > >>>> Consider a PSTN call. The call goes from the gateway to >>>>> > > >> softswitch / >>>>>>> > > >>>> Proxy. Proxy routes to VM App Server. INFO has to >> > pass through >>>>>>> > > >>>> softswitch / Proxy. >>>>>>> > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC >>> > > key press >>>>> > > >> state, bypassing the softswitch. >>>>> > > >> >>>>> > > >> [Christer] As I've said before, there are environments >> > where some >>>>> > > >> proxies must (for whatever reason) be passed through. I guess an >>>>> > > >> outbound proxy is a good example. >>>>> > > >> >>>>>>> > > >>>> KPML and INFO have the same number of messages for a >>> > > SINGLE digit; >>>>> > > >> KPML wins >>>>>>> > > >>>> hands-down for multiple digits or reports. >>>>>> > > >>> >>>>>> > > >>> Not exactly - for a single digit, KPML would generate a >>>>>> > > >>> Subscribe/200/Notify/200 before the single DTMF was even >>> > > pressed - >>>>>> > > >>> before the actual Notify with the digits in it. >>>>>> > > >>> And of course there is now also a subscribe dialog involved. >>>>>> > > >>> Assuming a one-shot single digit type, then, we're >> > talking 6 SIP >>>>>> > > >>> messages for KPML vs. 2 for Info. >>>>> > > >> >>>>> > > >> [Christer] And, in cases where you need to send DTMFs >> > (or whatever >>>>> > > >> information) in both directions you actually need 2 subscription >>>>> > > >> dialogs >>>>> > > >> - one in each direction, and maintaining dialog state also >>> > > consumes >>>>> > > >> resources. And, in some cases you may not even know >>> > > whether you will >>>>> > > >> ever have to use the dialog. >>>>> > > >> >>>>> > > >> >>>>>>> > > >>>> More importantly, let's take a Call Management (CM) >>>>> > > >> application that >>>>>>> > > >>>> calls a VM application when they cannot find the >>>>> > > >> subscriber. INFO has >>>>> > > >> >>>>>>> > > >>>> to pass through the softswitch / Proxy to the CM >>>>> > > >> application. Cool - >>>>>>> > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM >>> > > application >>>>>>> > > >>>> has to proxy the INFOs to the VM application. Yes - you >>> > > could be a >>>>>>> > > >>>> good programmer and remember to do that EVERYWHERE you >> > place an >>>>>>> > > >>>> outbound call, but it is really easy to get wrong. >>>>>> > > >>> >>>>>> > > >>> I'm not sure I understand the scenario. The VM learned >>> > > about this >>>>>> > > >>> call how? >>>>>> > > >>> By being in the signaling path, no? So why wouldn't the >>> > > CM forward >>>>>> > > >>> INFO along the path? (I mean it is in the same dialog, >>> > > after all) >>>>>> > > >>> Now I don't doubt it could screw that up, and eat the >>> > > info thinking >>>>>> > > >>> it was for itself, but lots of things can get screwed up >>> > > - my guess >>>>>> > > >>> is KPML will not be impervious to screw ups. >>>>> > > >> >>>>> > > >> [Christer] I also have problems understanding the >>> > > scenario. INFO is >>>>> > > >> routed to wherever the INVITE that initiated the dialog >>> > > was routed... >>>>> > > >> >>>>> > > >> 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 >>>>> > > >> >>>> > > > >>> > > >>> > > >>> > > >>> > > Notice: This email message, together with any attachments, >>> > > may contain information of BEA Systems, Inc., its >>> > > subsidiaries and affiliated entities, that may be >>> > > confidential, proprietary, copyrighted and/or legally >>> > > privileged, and is intended solely for the use of the >>> > > individual or entity named in this message. If you are not >>> > > the intended recipient, and have received this message in >>> > > error, please immediately return this by email and then delete it. >>> > > >> > >> > Notice: This email message, together with any attachments, >> > may contain information of BEA Systems, Inc., its >> > subsidiaries and affiliated entities, that may be >> > confidential, proprietary, copyrighted and/or legally >> > privileged, and is intended solely for the use of the >> > individual or entity named in this message. If you are not >> > the intended recipient, and have received this message in >> > error, please immediately return this by email and then delete it. >> > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --B_3275236816_4129000 Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7bit Re: [Sip] INFO No.   For subscribe/notify interaction, it is trivial: whomever issues the subscribe gets the notify. Easy for the stack to figure out.  For INFO interaction, everything goes to call control. That works if your model is pure softswitch/feature server, but not many folks are doing that anymore.


On 10/14/07 11:01 AM, "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:



Hi,

As I have said before: you have similar problems with other mechanisms.

Regards,

Christer

> -----Original Message-----
> From: Eric Burger [mailto:eburger@bea.com]
> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: sip@ietf.org
> Subject: Re: [Sip] INFO
>
> Routing of the message once it gets to the device
> (application), not route to the device (transport).
>
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all
> need lemonade: see
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
>
> ----- Original Message -----
> From: Christer Holmberg <christer.holmberg@ericsson.com>
> To: Eric Burger; Hadriel Kaplan <HKaplan@acmepacket.com>
> Cc: sip <sip@ietf.org>
> Sent: Thu Oct 11 19:38:06 2007
> Subject: RE: [Sip] INFO
>
>
> Hi Eric,
>
> I am not sure I understand what you mean, but INFOs are
> routed according to the route set of the invite dialog they
> are sent within.
>
> If you want to transport information using some other path
> you can of course not send the information within the invite dialog.
>
> Regards,
>
> Christer
>
>
> > -----Original Message-----
> > From: Eric Burger [mailto:eburger@bea.com]
> > Sent: 12. lokakuuta 2007 0:35
> > To: Christer Holmberg; Hadriel Kaplan
> > Cc: sip
> > Subject: Re: [Sip] INFO
> >
> > Right: "DTMF may not be the only information users want to send to
> > each other during a session."  This is why one MUST
> establish multiple
> > subscription dialogs.  How else would one keep track of the
> different
> > elements / local routing decisions?  If you are proposing
> application
> > routing a'la P-Asserted-Service...
> >
> >
> > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)"
> > <christer.holmberg@ericsson.com> wrote:
> >
> > >
> > >
> > > Hi,
> > >
> > > Let's also keep in mind that DTMF may not be the only information
> > > users want to send to each other during a session. So, you
> > will need
> > > to establish subscription dialogs for every type of event
> that the
> > > users may want to send during the session...
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >> -----Original Message-----
> > >> From: Christer Holmberg (JO/LMF)
> > >> [mailto:christer.holmberg@ericsson.com]
> > >> Sent: 11. syyskuuta 2007 12:27
> > >> To: Hadriel Kaplan; Eric Burger
> > >> Cc: sip
> > >> Subject: RE: [Sip] INFO
> > >>
> > >>
> > >> Hi,
> > >>
> > >>>> Consider a PSTN call.  The call goes from the gateway to
> > >> softswitch /
> > >>>> Proxy.  Proxy routes to VM App Server.  INFO has to
> pass through
> > >>>> softswitch / Proxy.
> > >>>> In KPML-land, VM App Server *directly* subscribes to UAC
> > key press
> > >> state, bypassing the softswitch.
> > >>
> > >> [Christer] As I've said before, there are environments
> where some
> > >> proxies must (for whatever reason) be passed through. I guess an
> > >> outbound proxy is a good example.
> > >>
> > >>>> KPML and INFO have the same number of messages for a
> > SINGLE digit;
> > >> KPML wins
> > >>>> hands-down for multiple digits or reports.
> > >>>
> > >>> Not exactly - for a single digit, KPML would generate a
> > >>> Subscribe/200/Notify/200 before the single DTMF was even
> > pressed -
> > >>> before the actual Notify with the digits in it.
> > >>> And of course there is now also a subscribe dialog involved.
> > >>> Assuming a one-shot single digit type, then, we're
> talking 6 SIP
> > >>> messages for KPML vs. 2 for Info.
> > >>
> > >> [Christer] And, in cases where you need to send DTMFs
> (or whatever
> > >> information) in both directions you actually need 2 subscription
> > >> dialogs
> > >> - one in each direction, and maintaining dialog state also
> > consumes
> > >> resources. And, in some cases you may not even know
> > whether you will
> > >> ever have to use the dialog.
> > >>
> > >>
> > >>>> More importantly, let's take a Call Management (CM)
> > >> application that
> > >>>> calls a VM application when they cannot find the
> > >> subscriber.  INFO has
> > >>
> > >>>> to pass through the softswitch / Proxy to the CM
> > >> application.  Cool -
> > >>>> it is a proxy, so it knows to relay.  But OOPS!  The CM
> > application
> > >>>> has to proxy the INFOs to the VM application.  Yes - you
> > could be a
> > >>>> good programmer and remember to do that EVERYWHERE you
> place an
> > >>>> outbound call, but it is really easy to get wrong.
> > >>>
> > >>> I'm not sure I understand the scenario.  The VM learned
> > about this
> > >>> call how?
> > >>> By being in the signaling path, no?  So why wouldn't the
> > CM forward
> > >>> INFO along the path? (I mean it is in the same dialog,
> > after all)
> > >>> Now I don't doubt it could screw that up, and eat the
> > info thinking
> > >>> it was for itself, but lots of things can get screwed up
> > - my guess
> > >>> is KPML will not be impervious to screw ups.
> > >>
> > >> [Christer] I also have problems understanding the
> > scenario. INFO is
> > >> routed to wherever the INVITE that initiated the dialog
> > was routed...
> > >>
> > >> 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
> > >>
> > >
> >
> >
> >
> > Notice:  This email message, together with any attachments,
> > may contain information  of  BEA Systems,  Inc.,  its
> > subsidiaries  and  affiliated entities,  that may be
> > confidential,  proprietary,  copyrighted  and/or legally
> > privileged, and is intended solely for the use of the
> > individual or entity named in this message. If you are not
> > the intended recipient, and have received this message in
> > error, please immediately return this by email and then delete it.
> >
>
> Notice:  This email message, together with any attachments,
> may contain information  of  BEA Systems,  Inc.,  its
> subsidiaries  and  affiliated entities,  that may be
> confidential,  proprietary,  copyrighted  and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --B_3275236816_4129000-- --===============1006418847== 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 --===============1006418847==-- From sip-bounces@ietf.org Mon Oct 15 03:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhK3G-0001Mf-8e; Mon, 15 Oct 2007 03:07:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhK3E-0001MU-Jx for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 03:07:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhK3D-0001KK-KR for sip@ietf.org; Mon, 15 Oct 2007 03:07:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhK38-0004vF-2S for sip@ietf.org; Mon, 15 Oct 2007 03:07:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 77A7A20544; Mon, 15 Oct 2007 09:07:37 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-4b-471311b98b76 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F7FA204F7; Mon, 15 Oct 2007 09:07:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 09:07:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Mon, 15 Oct 2007 09:07:35 +0200 Message-ID: In-Reply-To: <47128B84.9030208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgOqiGWNnSl4sZzQdqii3mJ+NyY/wAT9YUA References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> <471 28B84.90 30208@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 15 Oct 2007 07:07:36.0838 (UTC) FILETIME=[10E90A60:01C80EFA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List , Francois Audet , Michael Procter , 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I haven't thought about this proposal in detail yet, but we would also >>need to take the the dialog-reuse spec (which proposes NOT to mix=20 >>dialog usages) into consideration. But, if we somehow could bind the=20 >>subscription lifetime to the dialog lifetime I think that at least=20 >>some of the issues in that spec would be solved. >=20 >The lifetime of a dialog isn't an independent variable - it=20 >ends when the last dialog usage ends. >=20 >If you are really talking about implicit *subscriptions*,=20 >then you either must explicitly end them, or else define=20 >their *implicit* end in terms of something that has an=20 >explicit endpoint. >=20 >I expect that you are talking about something that either=20 >shares the invite dialog usage, or else a distinct dialog=20 >usage that implicitly starts and stops concurrently with the=20 >invite dialog usage. Yes. I'd like to call it "invite dialog subscriptions", or something like that... 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 Mon Oct 15 03:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKJZ-00070W-Iv; Mon, 15 Oct 2007 03:24:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhKJX-0006sH-Ng for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 03:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKJW-0006jb-Fy for sip@ietf.org; Mon, 15 Oct 2007 03:24:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhKJT-0004j9-ON for sip@ietf.org; Mon, 15 Oct 2007 03:24:33 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6E1920532; Mon, 15 Oct 2007 09:24:13 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-10-4713159de609 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C889120571; Mon, 15 Oct 2007 09:24:13 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 09:24:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Mon, 15 Oct 2007 09:24:12 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJAADI363A= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><4710E415.3 070602@n ostrum.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Adam Roach" X-OriginalArrivalTime: 15 Oct 2007 07:24:13.0511 (UTC) FILETIME=[62F94570:01C80EFC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 Inline >> 2. Dialog re-use causes problems. Having multiple usages within a >> dialog causes all kinds of confusing interactions between the >> usages. Even the ones that are well documented are seldom >> implemented correctly. (e.g., if I send a re-INVITE in a dialog >> that is shared with a SUBSCRIBE and get a 481, what=20 >> is gone? The INVITE usage or the dialog? >=20 >The dialog, as before, and also the subscription, since the=20 >subscription would be tied to the invite's dialog. They=20 >would share fate. [Christer] I agree. I am not even sure we should call it a subscription dialog, but a invite dialog subscription. We also need to remember that there is a difference in how an invite dialog and subscription dialog are created. Due to the forking rules for SUBSCRIBE, the receival of a NOTIFY can create a subscription dialog. An invite dialog is always created by a responses (provisional or final), and I don't think we want to change that. >> What it it's a 480? A 500? Even if _you_ know where to look it up, will implementors?=20 >> Even if they do, are the rules sufficiently labyrinthine that the=20 >> chances of misimplementation are high?) The "pushing my buttons"=20 >> comment came from your implication that INFO was basically the=20 >> same as NOTIFY in this context -- which is imperfect in myriad ways.=20 >> For example: >> such a statement would mean that the INFO usage survives the >> termination of the INVITE dialog >> (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's >> probably not what you meant, but (except at the most superficial >> level) it's so far away from what you might actually want as to be >> a very poor starting point. >=20 >Right, it's not what I meant. :) [Christer] Good :) If we only have one usage, the invite usage, everthing else would share the fate of the INVITE dialog. For example, when the 200 OK is received, and all other early dialogs are terminated, all "invite dialog subscriptions" related to those dialogs are also automatically terminated. >>Can this be salvaged? Yes -- and Dean's earlier proposal for INFO=20 >>packages does so by making such things explicit. There's another=20 >>question about whether it's worth salvaging, and I think that's a=20 >>little less cut-and-dried (despite my strong opinion on the topic) --=20 >>but I'm boggled by the extreme pushback to making this negotiation=20 >>explicit in the face of clear examples of how things break when we don't. >=20 >I don't think anyone is pushing back against making negotiation explicit. >=20 >=20 >>(For the record: "Allow-Event" in an INVITE has very well defined=20 >>semantics -- it means, "if you send me a SUBSCRIBE for this event=20 >>package, I can send NOTIFYs". It is exactly backwards from the meaning >>"I can receive NOTIFYs of this type".) >=20 >Yes I agree... didn't say otherwise. :) [Christer] One issue with the subscription mechanism is that when A is interested to receive events from B it sends a subscription to B. There is basically no good way for A to tell B "Hey, I have some events I would like to send you (if you support them), so please subscribe to them". For some applications B KNOWS it will have to subscribe to certain events from A, but in some cases B may again subscribe to events "just in case". I think it would be useful if A somehow could indiate which events it expects B to subscribe to for this specific call. 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 Mon Oct 15 04:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLMc-0007UF-Ig; Mon, 15 Oct 2007 04:31:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhLMb-0007Tj-6p for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 04:31:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLMa-0007S2-DZ for sip@ietf.org; Mon, 15 Oct 2007 04:31:48 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhLMV-0007I2-6H for sip@ietf.org; Mon, 15 Oct 2007 04:31:48 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l9F8VZhS010107 for ; Mon, 15 Oct 2007 03:31:37 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 03:31:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 10:31:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2007 10:31:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180017E1D88@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgPBcv4h6/g5D89QjaqwYyPe0P9cw== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 15 Oct 2007 08:31:33.0401 (UTC) FILETIME=[CAEF9090:01C80F05] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-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: , Errors-To: sip-bounces@ietf.org (As WG chair) This is to announce a working group last call of=20 http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03. txt I would request comments on this document be made (to list and to author mentioned in the document) by Monday October 29th 2007. Please clearly identify the text of the document that is being commented on, the nature of the comment (NIT, minor technical, major technical, etc), and any suggested resolution, even if it is only some alternatives. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 15 05:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLxC-0002JB-V5; Mon, 15 Oct 2007 05:09:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhLxA-0002Gc-CC for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 05:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLx9-0002Ef-Jq for sip@ietf.org; Mon, 15 Oct 2007 05:09:35 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhLwy-0000Yx-Jm for sip@ietf.org; Mon, 15 Oct 2007 05:09:30 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1446136wxc for ; Mon, 15 Oct 2007 02:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=NzaCMocdF1nn9sF5z2smViPkss4BwtVP7ERMnToeHhY=; b=O6LMCNaeTJunzm4rMtfWj05gY6F80BWXxny8WbliCmpCQQa3slh3MuhiO5fGXqNWXSOMn1R+DIWpKbAYIBqFJE9c5gXHRKu8II44ySnQVYgK5FZTsFhqXZ3NsZawmspERns5/8V+F5PoRaqQ8V+rUJIQ+O5HM/DUihTYr0YuXOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Bfh5ITum7+fnb261JJbu3eeAA6QI60lAMVDRPbD/osqfL3fRW1GY26FMke9i0MdAXK7+Ap2UE/Rbgp2U95ctM9qBVGcoBXY7UQ1B3xLpaH2BDlIwkS+b8Jf30ua1N7QoY1NQumrHjSix3dLkF81lPMIWu2SPf8yguwF2UfDLt6Q= Received: by 10.70.108.18 with SMTP id g18mr10667735wxc.1192439318914; Mon, 15 Oct 2007 02:08:38 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Mon, 15 Oct 2007 02:08:38 -0700 (PDT) Message-ID: <18a603a60710150208j78804102uf4ac27c0ad388192@mail.gmail.com> Date: Mon, 15 Oct 2007 11:08:38 +0200 From: "Pars Mutaf" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) In-Reply-To: <200710121832.l9CIWp6Y024439@dragon.ariadne.com> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> <200710121832.l9CIWp6Y024439@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Content-Type: multipart/mixed; boundary="===============0103408925==" Errors-To: sip-bounces@ietf.org --===============0103408925== Content-Type: multipart/alternative; boundary="----=_Part_31661_32629571.1192439318912" ------=_Part_31661_32629571.1192439318912 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, Dale.Worley@comcast.net wrote: > > From: "Pars Mutaf" > > I won't publish my SIP URI in a phone book allowing anyone to see it. > We already agreed on that. > > I'll tell it to people that I know only. I'll tell it using a user > friendly > mechanism called "pairing" : We meet each other with our cell phones, > and agree to exchange our contact information. So, the procedure is > under our control. Pairing is good for us also because it allows us to > exchange a secret key (note that this is already enough motivation for > the pairing idea). > > So your usage model is that you will only want to communicate with > people that you already know, and in most cases, have personally met. > This means that you have no need of a directory, as your SIP device > will be used to remember the URI of every person that you can call. Right. This model is the one being used today. Note that Bluetooth already comes with a pairing solution. We should make this idea technology independent and hopefully allow users to pair their devices through the Internet, i.e. over long distances. There are important motivations for that. Note that this is much like how many mobile phone users use their > mobiles, but the opposite of the normal model of landline telephones, > where it is expected that the public can discover and contact you. > > My question was: do we need the SIP trapezoid in this case. > > If you assume that each mobile has a fixed IPv6 address, then the > address-based URI will always reach the mobile. And in that case, you > don't need a home proxy that translates an AOR into a contact URI -- > in effect, that translation process has been moved down into the > network layer by the process of routing to that IPv6 address. > > But it seems unlikely that an individual will have a fixed IPv6 > address over the long term. For one, it seems unlikely that *every* > network will provide uniform IPv6 mobility. For another, what if the > user replaces his mobile? OK. We should use DNS perhaps to meet these requirements. You can change your mobile IPv6 home address whenever you want I have the DNS name of your device (obtained via pairing). Is it acceptable to have fixed DNS name over long term? There are also other interesting issues: With the proposed model, I'm not sure if the operator needs to know my SIP URI. Note also that the SIP URI is never transmitted in clear-text, we have IPsec between the peers from the beginning (thanks to pairing). But I guess these issues need to be discussed in more detail. https://www1.ietf.org/mailman/listinfo/humanresolvers Thanks, pars 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 > ------=_Part_31661_32629571.1192439318912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/12/07, Dale.Worley@comcast.net <Dale.Worley@comcast.net > wrote:
   From: "Pars Mutaf" < pars.mutaf@gmail.com>

   I won't publish my SIP URI in a phone book allowing anyone to see it.
   We already agreed on that.

   I'll tell it to people that I know only. I'll tell it using a user friendly
   mechanism called "pairing" : We meet each other with our cell phones,
   and agree to exchange our contact information. So, the procedure is
   under our control. Pairing is good for us also because it allows us to
   exchange a secret key (note that this is already enough motivation for
   the pairing idea).

So your usage model is that you will only want to communicate with
people that you already know, and in most cases, have personally met.
This means that you have no need of a directory, as your SIP device
will be used to remember the URI of every person that you can call.

Right. This model is the one being used today. Note that Bluetooth already
comes with a pairing solution.

We should make this idea technology independent and hopefully allow
users to pair their devices through the Internet, i.e. over long distances.
There are important motivations for that.


Note that this is much like how many mobile phone users use their
mobiles, but the opposite of the normal model of landline telephones,
where it is expected that the public can discover and contact you.

   My question was: do we need the SIP trapezoid in this case.

If you assume that each mobile has a fixed IPv6 address, then the
address-based URI will always reach the mobile.  And in that case, you
don't need a home proxy that translates an AOR into a contact URI --
in effect, that translation process has been moved down into the
network layer by the process of routing to that IPv6 address.

But it seems unlikely that an individual will have a fixed IPv6
address over the long term.  For one, it seems unlikely that *every*
network will provide uniform IPv6 mobility.  
 

For another, what if the
user replaces his mobile?

OK. We should use DNS perhaps to meet these requirements.
You can change your mobile IPv6 home address whenever you want
I have the DNS name of your device (obtained via pairing). Is it
acceptable to have fixed DNS name over long term?

There are also other interesting issues: With the proposed model,
I'm not sure if the operator needs to know my SIP URI.

Note also that the SIP URI is never transmitted in clear-text, we have
IPsec between the peers from the beginning (thanks to pairing).

But I guess these issues need to be discussed in more detail.

https://www1.ietf.org/mailman/listinfo/humanresolvers

Thanks,
pars


 

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

------=_Part_31661_32629571.1192439318912-- --===============0103408925== 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 --===============0103408925==-- From sip-bounces@ietf.org Mon Oct 15 05:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhM55-0001vC-3p; Mon, 15 Oct 2007 05:17:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhM52-0001r1-TO for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 05:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhM51-0001po-VN for sip@ietf.org; Mon, 15 Oct 2007 05:17:43 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhM4v-0000l9-NY for sip@ietf.org; Mon, 15 Oct 2007 05:17:43 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1447826wxc for ; Mon, 15 Oct 2007 02:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=JK1e6YnMKDQTjdqR5wAUOOciwJjzpF+0QnPBv6g4spQ=; b=ZAj87WwrCvdmrxwvwTkUzECq7N0xdvd5RvT1w56PjwqIwGuosEJI38UFMX3qVRWbJhTwFL3ROQ66utOtMK73lX+CDxC2JQP793Yl2YL7A0jexcRLGzdYxy6GsKe6Nfz7xR7f5gwE4vckuRScJcr8NanpSpRvfCx9zfI+jxqwoxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YD1v/Q0gjoe/C1FKzi96xYkUkA0eiTCjfB14U29gMna+8atHyya3qzoF2BHH6j7KDldgGNjKqiUz1UZZNO84eH7L9yujcshdBfISi8RtI6PmjrpiuXUtu40DmP9GfT+unqLgAMDY7O9W6+NcxZTthHSCK6ubG1jtf3FWKIGy6QY= Received: by 10.70.39.5 with SMTP id m5mr10681570wxm.1192439832041; Mon, 15 Oct 2007 02:17:12 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Mon, 15 Oct 2007 02:17:11 -0700 (PDT) Message-ID: <18a603a60710150217l61d24aebged5497386ec2c993@mail.gmail.com> Date: Mon, 15 Oct 2007 11:17:11 +0200 From: "Pars Mutaf" To: "sergiole@tml.hut.fi" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) In-Reply-To: <20071012213057.xekhg90hesks8kc8@horde-intra.tml.hut.fi> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> <20071012213057.xekhg90hesks8kc8@horde-intra.tml.hut.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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: , Content-Type: multipart/mixed; boundary="===============0114946744==" Errors-To: sip-bounces@ietf.org --===============0114946744== Content-Type: multipart/alternative; boundary="----=_Part_31686_18338242.1192439832040" ------=_Part_31686_18338242.1192439832040 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/12/07, sergiole@tml.hut.fi wrote: > > > > > I understand that the problem you want to solve is the following : > > > Or, when you meet someone and want get your phones paired, you > > just type the target name because you have your cell phone in your hand. > > The phones get paired. You don't need to type a long SIP URI and > > Mobile IPv6 home address. > > also mentioned in other email: > > > I'll tell it to people that I know only. I'll tell it using a user > friendly > > mechanism called "pairing" : We meet each other with our cell phones, > > and agree to exchange our contact information. > > > I guess that what you want to avoid is to input in your phone the > URI of the person you met, and instead automatically interchange URIs. Yes and also IPv6 home address, DNS name, IPsec key, why not e-mail address, etc. In any case someone needs to enter something in their phone, either > a URI, search keyword, TEL, etc to pair a contact... Right. https://www1.ietf.org/mailman/listinfo/humanresolvers Thanks, pars SE > > > > Quoting Pars Mutaf : > > > On 10/12/07, Spencer Dawkins wrote: > >> > >> > The privacy problem: normally I shouldn't be able to discover > >> your SIP URI. > >> > >> I'm guessing that if you can't tell people your SIP AOR, then SIP is > not > >> for > >> you. > > > > > > Hello, > > > > I won't publish my SIP URI in a phone book allowing anyone to see it. > > We already agreed on that. > > > > I'll tell it to people that I know only. I'll tell it using a user > friendly > > mechanism called "pairing" : We meet each other with our cell phones, > > and agree to exchange our contact information. So, the procedure is > > under our control. Pairing is good for us also because it allows us to > > exchange a secret key (note that this is already enough motivation for > > the pairing idea). > > > > The point is that, if I give you my SIP URI (using the pairing > procedure) > > then I can also give you my Mobile IPv6 home address using the same > > pairing procedure. In other words, there is _no more resolution_ from > > SIP URI to home IP address. You get them **concurrently**. > > > > We have each other's SIP URIs and home addresses. > > ->SIP application is happy, it has the target SIP URI. > > ->Routing problem is solved by mobile IPv6. > > > > My question was: do we need the SIP trapezoid in this case. > > > > Thanks, > > pars > > > > > > > > > > > > > > Thanks, > >> > >> Spencer > >> > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP 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_31686_18338242.1192439832040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 10/12/07, sergiole@tml.hut.fi <sergiole@tml.hut.fi> wrote:



I understand that the problem you want to solve is the following :

> Or, when you meet someone and want get your phones paired, you
> just type the target name because you have your cell phone in your hand.
> The phones get paired. You don't need to type a long SIP URI and
> Mobile IPv6 home address.

also mentioned in other email:

> I'll tell it to people that I know only. I'll tell it using a user friendly
> mechanism called "pairing" : We meet each other with our cell phones,
> and agree to exchange our contact information.


  I guess that what you want to avoid is to input in your phone the
URI of the person you met, and instead automatically interchange URIs.

Yes and also IPv6 home address, DNS name, IPsec key, why not e-mail address, etc.  

  In any case someone needs to enter something in their phone, either
a URI, search keyword, TEL, etc to pair a contact...

SE



Quoting Pars Mutaf <pars.mutaf@gmail.com>:

> On 10/12/07, Spencer Dawkins <spencer@mcsr-labs.org> wrote:
>>
>> > The privacy problem: normally I shouldn't be able to discover
>> your SIP URI.
>>
>> I'm guessing that if you can't tell people your SIP AOR, then SIP is not
>> for
>> you.
>
>
> Hello,
>
> I won't publish my SIP URI in a phone book allowing anyone to see it.
> We already agreed on that.
>
> I'll tell it to people that I know only. I'll tell it using a user friendly
> mechanism called "pairing" : We meet each other with our cell phones,
> and agree to exchange our contact information. So, the procedure is
> under our control. Pairing is good for us also because it allows us to
> exchange a secret key (note that this is already enough motivation for
> the pairing idea).
>
> The point is that, if I give you my SIP URI (using the pairing procedure)
> then I can also give you my Mobile IPv6 home address using the same
> pairing procedure. In other words, there is _no more resolution_ from
> SIP URI to home IP address. You get them **concurrently**.
>
> We have each other's SIP URIs and home addresses.
> ->SIP application is happy, it has the target SIP URI.
> ->Routing problem is solved by mobile IPv6.
>
> My question was: do we need the SIP trapezoid in this case.
>
> Thanks,
> pars
>
>
>
>
>
>
> Thanks,
>>
>> Spencer
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP 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_31686_18338242.1192439832040-- --===============0114946744== 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 --===============0114946744==-- From sip-bounces@ietf.org Mon Oct 15 10:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXJ-0005ME-7j; Mon, 15 Oct 2007 10:03:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhQXG-0005Lw-Pz for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:03:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXF-0005Lb-QK for sip@ietf.org; Mon, 15 Oct 2007 10:03:09 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQXF-0003vn-Ah for sip@ietf.org; Mon, 15 Oct 2007 10:03:09 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE33rJ010319; Mon, 15 Oct 2007 07:03:03 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE30nC021694; Mon, 15 Oct 2007 07:03:02 -0700 Received: from 172.24.29.123 ([172.24.29.123]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Oct 2007 14:03:01 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 15 Oct 2007 07:00:28 -0500 Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) From: Eric Burger To: Christer Holmberg Message-ID: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJAADI363AAJeVhlw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: sip-bounces@ietf.org Under what circumstances would A know what B needs, without B explicitly signaling B's needs to A? On 10/15/07 3:24 AM, "Christer Holmberg" wrote: [snip] > [Christer] One issue with the subscription mechanism is that when A is > interested to receive events from B it sends a subscription to B. There > is basically no good way for A to tell B "Hey, I have some events I > would like to send you (if you support them), so please subscribe to > them". For some applications B KNOWS it will have to subscribe to > certain events from A, but in some cases B may again subscribe to events > "just in case". I think it would be useful if A somehow could indiate > which events it expects B to subscribe to for this specific call. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 15 10:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXO-0005Ni-73; Mon, 15 Oct 2007 10:03:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhQXL-0005Mr-Gb for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:03:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQXK-0005Mb-JP for sip@ietf.org; Mon, 15 Oct 2007 10:03:14 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQXJ-0003wR-WC for sip@ietf.org; Mon, 15 Oct 2007 10:03:14 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE34H6010384; Mon, 15 Oct 2007 07:03:04 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FE30nE021694; Mon, 15 Oct 2007 07:03:03 -0700 Received: from 172.24.29.123 ([172.24.29.123]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Oct 2007 14:03:02 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 15 Oct 2007 07:42:10 -0500 Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) From: Eric Burger To: Paul Kyzivat , Christer Holmberg , Dean Willis Message-ID: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgPIGuuqhbOQHsTEdyRsgAWy4mm/w== In-Reply-To: <47128B84.9030208@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: sip-bounces@ietf.org Dialog termination is where I see the most potential for confusion. I would also offer these problems are not insurmountable. However, I would be curious to find out if solving these problems does not reconstruct RFC 3265 in its full glory. Let us take two scenarios for the easy case of transporting user stimulus. In the first case, the user presses a button and hangs up. Because of normal Internet routing, the INFO (Invite-based Notification Function Output ;-) message arrives after the BYE arrives. What to do? What if the button pressed was "don't launch missiles?" In the second case, the application is using digit maps, because the application developer realizes that 1100 bytes of SIP headers to transport one byte of user stimulus information is stupid. The device buffers some digits, but the user hangs up. What does the endpoint do? Does it send the collected digits? Does it eat the collected digits? Any argument other than an explicit negotiation (like KPML does) is not going to work in the general case. This is because if we say, for DTMF, "always send buffered digits," then what we are really saying is, "always send what you have before the dialog terminates." I could easily envision packages that would have tons of state that is immediately irrelevant at dialog termination. Dumping tons of bytes on the network again totally defeats the "We want this because it is lightweight" argument. On 10/14/07 5:35 PM, "Paul Kyzivat" wrote: > > > Christer Holmberg wrote: > >> I haven't thought about this proposal in detail yet, but we would also >> need to take the the dialog-reuse spec (which proposes NOT to mix dialog >> usages) into consideration. But, if we somehow could bind the >> subscription lifetime to the dialog lifetime I think that at least some >> of the issues in that spec would be solved. > > The lifetime of a dialog isn't an independent variable - it ends when > the last dialog usage ends. > > If you are really talking about implicit *subscriptions*, then you > either must explicitly end them, or else define their *implicit* end in > terms of something that has an explicit endpoint. > > I expect that you are talking about something that either shares the > invite dialog usage, or else a distinct dialog usage that implicitly > starts and stops concurrently with the invite dialog usage. > > Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 15 10:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQmN-0004Eq-6x; Mon, 15 Oct 2007 10:18:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhQmK-0004EL-SY for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQmJ-0004EC-RA for sip@ietf.org; Mon, 15 Oct 2007 10:18:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQmD-00025f-Fx for sip@ietf.org; Mon, 15 Oct 2007 10:18:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D1A49206EA; Mon, 15 Oct 2007 16:18:21 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-2d-471376add0ba Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDC842051A; Mon, 15 Oct 2007 16:18:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:18:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Mon, 15 Oct 2007 16:18:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJAADI363AAJeVhlwAEyr4A References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 15 Oct 2007 14:18:21.0525 (UTC) FILETIME=[3D8B5050:01C80F36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: sip-bounces@ietf.org Hi, It's not about A knowing what B "needs" - it's about A telling B that there may be some information he is interested in sending - IF B wants it. Regards, Christer=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 15. lokakuuta 2007 15:00 > To: Christer Holmberg > Cc: IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 > Under what circumstances would A know what B needs, without B=20 > explicitly signaling B's needs to A? >=20 >=20 > On 10/15/07 3:24 AM, "Christer Holmberg"=20 > > wrote: > [snip]=20 > > [Christer] One issue with the subscription mechanism is=20 > that when A is=20 > > interested to receive events from B it sends a subscription to B.=20 > > There is basically no good way for A to tell B "Hey, I have some=20 > > events I would like to send you (if you support them), so please=20 > > subscribe to them". For some applications B KNOWS it will have to=20 > > subscribe to certain events from A, but in some cases B may again=20 > > subscribe to events "just in case". I think it would be useful if A=20 > > somehow could indiate which events it expects B to=20 > subscribe to for this specific call. >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 15 10:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQxT-0004lU-Jw; Mon, 15 Oct 2007 10:30:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhQxR-0004jc-Op for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQxQ-0004iE-JK for sip@ietf.org; Mon, 15 Oct 2007 10:30:12 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQxP-0002Qj-9w for sip@ietf.org; Mon, 15 Oct 2007 10:30:12 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FEU5bG028247; Mon, 15 Oct 2007 07:30:05 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9FEU4Zu030125; Mon, 15 Oct 2007 07:30:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Mon, 15 Oct 2007 07:30:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJAADI363AAJeVhlwAEyr4AAABuzGs= From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: sip-bounces@ietf.org That indicates an explicit subscription model from B with an event type offer from A. Since we don't want our initial message to get as long as IMAP's, I would offer if there are optional things for B to discover from A, it should use OPTION. That said, I do not see how an unsolicited INFO showing up on A's door could possibly be good, especially if, as pointed out below, A might not be interested. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. ----- Original Message ----- From: Christer Holmberg To: Eric Burger Cc: IETF SIP List Sent: Mon Oct 15 07:18:20 2007 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Hi, It's not about A knowing what B "needs" - it's about A telling B that there may be some information he is interested in sending - IF B wants it. Regards, Christer > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: 15. lokakuuta 2007 15:00 > To: Christer Holmberg > Cc: IETF SIP List > Subject: Re: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > Under what circumstances would A know what B needs, without B > explicitly signaling B's needs to A? > > > On 10/15/07 3:24 AM, "Christer Holmberg" > > wrote: > [snip] > > [Christer] One issue with the subscription mechanism is > that when A is > > interested to receive events from B it sends a subscription to B. > > There is basically no good way for A to tell B "Hey, I have some > > events I would like to send you (if you support them), so please > > subscribe to them". For some applications B KNOWS it will have to > > subscribe to certain events from A, but in some cases B may again > > subscribe to events "just in case". I think it would be useful if A > > somehow could indiate which events it expects B to > subscribe to for this specific call. > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 15 11:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRNd-0003IL-0V; Mon, 15 Oct 2007 10:57:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhRNY-0003Es-Em for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 10:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRNX-0003Ej-Mu; Mon, 15 Oct 2007 10:57:11 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhRNW-0003bh-A4; Mon, 15 Oct 2007 10:57:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3917C328EF; Mon, 15 Oct 2007 14:56:40 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhRN2-0000GE-4Z; Mon, 15 Oct 2007 10:56:40 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 15 Oct 2007 10:56:40 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in 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: , Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-15.txt Technical Summary 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 registrar and for communicating a GRUU to a peer within a dialog. Working Group Summary The document complements work already performed in RFC 4474 for authenticated request identity, and forms an integral part of the chartered work in this area. There is consensus in the working group to publish this document. Document Quality The document has been well discussed by a significant number of members of the working group. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 15 11:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRol-0001uq-6s; Mon, 15 Oct 2007 11:25:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhRoi-0001uW-P7 for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 11:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRoh-0001ta-E1 for sip@ietf.org; Mon, 15 Oct 2007 11:25:15 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhRob-0005dv-3v for sip@ietf.org; Mon, 15 Oct 2007 11:25:15 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188792000"; d="scan'208";a="134939901" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Oct 2007 11:24:48 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9FFOkje011848; Mon, 15 Oct 2007 11:24:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9FFOCkZ005411; Mon, 15 Oct 2007 15:24:38 GMT 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.1830); Mon, 15 Oct 2007 11:24:25 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:24:24 -0400 Message-ID: <4713862A.30003@cisco.com> Date: Mon, 15 Oct 2007 11:24:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2007 15:24:24.0707 (UTC) FILETIME=[77C8E530:01C80F3F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--25.259200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3703; t=1192461886; x=1193325886; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Unsolicited=20NOTIFY/INFO=20versus=20Solicite d=20State=20Update |Sender:=20 |To:=20Eric=20Burger=20; bh=xTWNsIRWzWGAYEEMC0OgSvUBPVtTfPR9+vqkrp2j5S8=; b=TZVYjMZTNThbCPgBbhx30CBGLTNOgmcQPqiA5HMaTUlaNQkdpjfk120T+3kX9CGyC+ypxJI1 or6gbnFEY28yYSSErSKTM7Jbmmyp6cqvhzWmrpH96BH0SNlE/kzuyRc/; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > A few times I have seen a comment stating the endpoint interested in > potentially receiving DTMF notifications may not know whether or not it > needs DTMF. As such, the endpoint would be forced to always issue a > SUBSCRIBE, even if it will not be interested in DTMF. > > Could someone please describe a scenario in which the endpoint does NOT > KNOW, a'priori, it will be interested in DTMF? > > All the ones I can think of, like supplemental dial digits, ACD, register > recall, and return to application are all known to the AS or Proxy driving > the interaction. > > What else is out there? I think I have heard that SIP-H.323 GWs fall into this category. (As well as gateways to some other more proprietary protocols that shall remain unnamed here.) Paul > On 10/10/07 12:20 PM, "Christer Holmberg" > wrote: > >> Hi, >> >>>> Ignorning the reason why people are using INFO is not going >>>> to make things better either... >>>> >>>> I think most people are aware of KPML etc - we don't need to >>>> tell them that. >>> I seriously don't think people are using INFO because they think it's >>> better than KPML. >>> I think peopled use to use INFO because (a) they implemented it before >>> RFC 2833, and (b) because it was difficult for them to implement >>> RFC 2833 when it got implemented and (c) KPML didn't exist at that time. >> (d) they think it's a waste of resources to establish multiple additional >> subscription dialogs (there may be other type of data than DTMF they are >> willing to receive) which in many cases may not even be used during the call >> (it can not be assumed that the one sending the subscription always knows >> exactly when it will receive events). Maybe DTMF is not the best example in >> the world (my fault - I should have been more generic), but I am sure there >> could be events which would not be used in a very high percentage of all >> calls, but still the additional subscription dialog(s) would have to be >> established - just in case. >> >> I still strongly think it would be much better to describe the >> issues/advantages/disadvantages with BOTH INFO and events, and study what >> possible needs to defined related to negotiation etc, instead of just ignoring >> the real world and providing flexibility to people using SIP for their >> applications... >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> I believe at this point, this is an imaginary issue. >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 15 12:14:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSWB-0001oJ-JU; Mon, 15 Oct 2007 12:10:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhSW9-0001o1-7f for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 12:10:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSW8-0001nt-89 for sip@ietf.org; Mon, 15 Oct 2007 12:10:08 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhSW7-0002yR-MD for sip@ietf.org; Mon, 15 Oct 2007 12:10:08 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9FGA1GP016554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 11:10:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471390D4.3010600@nostrum.com> Date: Mon, 15 Oct 2007 11:09:56 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> In-Reply-To: <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 20:43:55 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Errors-To: sip-bounces@ietf.org Pars: This is sounding like it's less and less a SIP problem at all. Based on what you say below, I think all you need is some additional vCard fields (one for voice SIP URIs, and maybe one for home IPv6 addresses -- but I'd pursue these as separate efforts, if I were you). You can then send these vCards around in OBEX, email, web pages, or whatever else makes sense. Note that OBEX over Bluetooth, IrDA, and/or SMS completely satisfies the requirements you describe below -- and these are already well-defined, mature, and widely deployed technologies. Look at RFC 4770 to see how vCard extensions look. /a Pars Mutaf wrote: > > > On 10/12/07, *Spencer Dawkins* > wrote: > > > The privacy problem: normally I shouldn't be able to discover > your SIP URI. > > I'm guessing that if you can't tell people your SIP AOR, then SIP > is not for > you. > > > Hello, > > I won't publish my SIP URI in a phone book allowing anyone to see it. > We already agreed on that. > > I'll tell it to people that I know only. I'll tell it using a user > friendly > mechanism called "pairing" : We meet each other with our cell phones, > and agree to exchange our contact information. So, the procedure is > under our control. Pairing is good for us also because it allows us to > exchange a secret key (note that this is already enough motivation for > the pairing idea). > > The point is that, if I give you my SIP URI (using the pairing procedure) > then I can also give you my Mobile IPv6 home address using the same > pairing procedure. In other words, there is _no more resolution_ from > SIP URI to home IP address. You get them **concurrently**. > > We have each other's SIP URIs and home addresses. > ->SIP application is happy, it has the target SIP URI. > ->Routing problem is solved by mobile IPv6. > > My question was: do we need the SIP trapezoid in this case. > > Thanks, > pars > > > > > > > Thanks, > > Spencer > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu > for questions on current sip > Use sipping@ietf.org for new > developments on the application of sip > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 15 14:09:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUJV-0000G4-Id; Mon, 15 Oct 2007 14:05:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhUJS-0000Fr-Pz for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUJR-0000Fh-UE for sip@ietf.org; Mon, 15 Oct 2007 14:05:09 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUJL-0004Mb-Lj for sip@ietf.org; Mon, 15 Oct 2007 14:05:09 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9FI4fDg025164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Oct 2007 13:04:42 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Mon, 15 Oct 2007 13:04:25 -0500 To: Eric Burger X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip , "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: , Errors-To: sip-bounces@ietf.org On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: > Right: "DTMF may not be the only information users want to send to > each > other during a session." This is why one MUST establish multiple > subscription dialogs. How else would one keep track of the different > elements / local routing decisions? If you are proposing application > routing a'la P-Asserted-Service... > One of the arguments for INFO is that it happens in a dialog, not a session. That is, even if you have multiple event streams, they happen on the same dialog. The trick is demuxing the event streams, or in other words, figuring out the context for each event. INFO currently gives us nothing but the content- modifiers to figure this out. That's not enough, as has widely been argued. Francois proposed using an event wrapper within the dialog This does give us a bigger handle for demuxing. For example, we could reasonably demux jpegs which are snapshots from the built-in camera from jpegs that are intended as keypad overlays or HTML imagemaps. Might could have done that with content-disposition too, so it's an imperfect example. Is the event class enough of a differentiator? For example, we probably wouldn't be able to differentiate two different DTMF sources being routed to different applications within a single dialog. I suspect that's an acceptable limitation, at lest for the sorts of applications that seem to attract INFO use. -- 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 15 14:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhURP-0008Hc-IS; Mon, 15 Oct 2007 14:13:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhURN-0008FC-DE for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhURM-0008F4-Eg for sip@ietf.org; Mon, 15 Oct 2007 14:13:20 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhURG-0004lr-9i for sip@ietf.org; Mon, 15 Oct 2007 14:13:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9FICsf16915; Mon, 15 Oct 2007 18:12:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Mon, 15 Oct 2007 13:12:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1282A8C0@zrc2hxm0.corp.nortel.com> In-Reply-To: <47128B84.9030208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) thread-index: AcgOqi4NU+OezSztTv6L1L1O0hVLCAArKk2g References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> <47! 128B84.90 30208@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List , Michael Procter , 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: , Errors-To: sip-bounces@ietf.org My take is that we were talking about an implicit "start" and "end" based on the life of the INVITE dialog usage. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Sunday, October 14, 2007 14:35 > To: Christer Holmberg > Cc: Michael Procter; Dean Willis; Audet, Francois=20 > (SC100:3055); IETF SIP List > Subject: Re: [Sip] Francois' counter to INFO (was Re: What=20 > are we arguing aboutwhen we say INFO?) >=20 >=20 >=20 > Christer Holmberg wrote: >=20 > > I haven't thought about this proposal in detail yet, but we=20 > would also=20 > > need to take the the dialog-reuse spec (which proposes NOT to mix=20 > > dialog > > usages) into consideration. But, if we somehow could bind the=20 > > subscription lifetime to the dialog lifetime I think that at least=20 > > some of the issues in that spec would be solved. >=20 > The lifetime of a dialog isn't an independent variable - it=20 > ends when the last dialog usage ends. >=20 > If you are really talking about implicit *subscriptions*,=20 > then you either must explicitly end them, or else define=20 > their *implicit* end in terms of something that has an=20 > explicit endpoint. >=20 > I expect that you are talking about something that either=20 > shares the invite dialog usage, or else a distinct dialog=20 > usage that implicitly starts and stops concurrently with the=20 > invite dialog usage. >=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 From sip-bounces@ietf.org Mon Oct 15 14:29:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUem-0004YL-9X; Mon, 15 Oct 2007 14:27:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhUeg-0004Vx-9P for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:27:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUee-0004Vh-FK for sip@ietf.org; Mon, 15 Oct 2007 14:27:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhUee-000125-2K for sip@ietf.org; Mon, 15 Oct 2007 14:27:04 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9FIR0514497; Mon, 15 Oct 2007 18:27:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 15 Oct 2007 13:26:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgPVzOIDQso0MFiR6K/lh5Go7j7OgAALCag References: From: "Brian Stucker" To: "Dean Willis" , "Eric Burger" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip , Francois Audet , "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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: >=20 > > Right: "DTMF may not be the only information users want to send to=20 > > each other during a session." This is why one MUST=20 > establish multiple=20 > > subscription dialogs. How else would one keep track of the=20 > different=20 > > elements / local routing decisions? If you are proposing=20 > application=20 > > routing a'la P-Asserted-Service... > > >=20 > One of the arguments for INFO is that it happens in a dialog,=20 > not a session. That is, even if you have multiple event=20 > streams, they happen on the same dialog. >=20 > The trick is demuxing the event streams, or in other words,=20 > figuring out the context for each event. INFO currently gives=20 > us nothing but the content- modifiers to figure this out.=20 > That's not enough, as has widely been argued. How does 3265 make this any better? We're talking about identifying a data blob using an event plus a content-type instead of a supported plus a content-type for a period of time to start and end in conjunction with the INVITE dialog (so the subsciption-state header is mooted). So a NOTIFY with an event header or an INFO without an event header, all other things being the same and the constrained semantics of the NOTIFY usage being put forward here...=20 Wouldn't it be equally valid to simply allow the INFO message to carry an event header and say that INFO is the same as a NOTIFY with an implicit subscription to an INVITE dialog? Isn't this pretty much what it does already (minus the event header). Deep thought: Is all INFO is missing is simply the event header? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 15 14:35:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUlz-0003BZ-Jt; Mon, 15 Oct 2007 14:34:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhUly-0003BC-E5 for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUlx-0003B2-LD for sip@ietf.org; Mon, 15 Oct 2007 14:34:37 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUlr-0005yU-T3 for sip@ietf.org; Mon, 15 Oct 2007 14:34:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FF3A204FA; Mon, 15 Oct 2007 20:34:31 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-6a-4713b2b7a343 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4A1AC204D6; Mon, 15 Oct 2007 20:34:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 20:34:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Mon, 15 Oct 2007 20:34:29 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgNrbvrguQAYhokTGKoV9E4ABKiYAAFMkJAADI363AAJeVhlwAEyr4AAABuzGsACF5ZYA== References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 15 Oct 2007 18:34:30.0767 (UTC) FILETIME=[065387F0:01C80F5A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >That indicates an explicit subscription model from B with an=20 >event type offer from A. Since we don't want our initial=20 >message to get as long as IMAP's, No, we don't want to destroy SIP's good reputation of having short and compact messages... >I would offer if there are optional things for B to discover from A, it should use=20 >OPTION.=20 No. This is something that can be done per-call basis. We don't want our initial call setups flows to get too long, do we? ;) >That said, I do not see how an unsolicited INFO showing up on A's door could possibly be good, especially if,=20 >as pointed out below, A might not be interested. I didn't say that. It would be useful with negotiation also for INFO. Regards, Christer > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger > Cc: IETF SIP List > Sent: Mon Oct 15 07:18:20 2007 > Subject: RE: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > Hi, >=20 > It's not about A knowing what B "needs" - it's about A=20 > telling B that there may be some information he is interested=20 > in sending - IF B wants it. >=20 > Regards, >=20 > Christer=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 15. lokakuuta 2007 15:00 > > To: Christer Holmberg > > Cc: IETF SIP List > > Subject: Re: What are we arguing about when we say INFO? (was > > Re: [Sip] INFO) > >=20 > > Under what circumstances would A know what B needs, without B=20 > > explicitly signaling B's needs to A? > >=20 > >=20 > > On 10/15/07 3:24 AM, "Christer Holmberg"=20 > > > > wrote: > > [snip] > > > [Christer] One issue with the subscription mechanism is > > that when A is > > > interested to receive events from B it sends a subscription to B.=20 > > > There is basically no good way for A to tell B "Hey, I have some=20 > > > events I would like to send you (if you support them), so please=20 > > > subscribe to them". For some applications B KNOWS it will have to=20 > > > subscribe to certain events from A, but in some cases B may again=20 > > > subscribe to events "just in case". I think it would be=20 > useful if A=20 > > > somehow could indiate which events it expects B to > > subscribe to for this specific call. > >=20 > >=20 > > Notice: This email message, together with any attachments, may=20 > > contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > > affiliated entities, that may be confidential, proprietary, =20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 Mon Oct 15 14:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV43-00004w-V9; Mon, 15 Oct 2007 14:53:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhV41-0008Ug-Qd for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV40-0008Te-Tp for sip@ietf.org; Mon, 15 Oct 2007 14:53:16 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhV3u-0006nQ-Ej for sip@ietf.org; Mon, 15 Oct 2007 14:53:16 -0400 Received: (qmail 17845 invoked by uid 0); 15 Oct 2007 18:52:45 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Oct 2007 18:52:45 -0000 Message-ID: <4713B6FD.504@zonnet.nl> Date: Mon, 15 Oct 2007 20:52:45 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: IETF SIP List , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Eric, It's not that the "receiver" of DTMF events does not know it is interested, it's that the SUBSCRIBE/NOTIFY model forces the receiver to always subscribe, even if in 99% of the calls the other side is not expected to press any key during mid-call. For example, there exist call center applications in which pressing a digit (say '1') indicates that the caller is annoying and should be placed on a blacklist. In this scenario the DTMF event is rare; INFO would be more efficient in this case (if supported of course). In other scenario's (such as IVR systems) DTMF events are common; then SUBSCRIBE/NOTIFY may make more sense (overhead becomes less significant compared to total) Regards, Jeroen Eric Burger wrote: > A few times I have seen a comment stating the endpoint interested in > potentially receiving DTMF notifications may not know whether or not it > needs DTMF. As such, the endpoint would be forced to always issue a > SUBSCRIBE, even if it will not be interested in DTMF. > > Could someone please describe a scenario in which the endpoint does NOT > KNOW, a'priori, it will be interested in DTMF? > > All the ones I can think of, like supplemental dial digits, ACD, register > recall, and return to application are all known to the AS or Proxy driving > the interaction. > > What else is out there? > > > On 10/10/07 12:20 PM, "Christer Holmberg" > wrote: > > >> Hi, >> >> >>>> Ignorning the reason why people are using INFO is not going >>>> to make things better either... >>>> >>>> I think most people are aware of KPML etc - we don't need to >>>> tell them that. >>>> >>> I seriously don't think people are using INFO because they think it's >>> better than KPML. >>> >>> I think peopled use to use INFO because (a) they implemented it before >>> RFC 2833, and (b) because it was difficult for them to implement >>> RFC 2833 when it got implemented and (c) KPML didn't exist at that time. >>> >> (d) they think it's a waste of resources to establish multiple additional >> subscription dialogs (there may be other type of data than DTMF they are >> willing to receive) which in many cases may not even be used during the call >> (it can not be assumed that the one sending the subscription always knows >> exactly when it will receive events). Maybe DTMF is not the best example in >> the world (my fault - I should have been more generic), but I am sure there >> could be events which would not be used in a very high percentage of all >> calls, but still the additional subscription dialog(s) would have to be >> established - just in case. >> >> I still strongly think it would be much better to describe the >> issues/advantages/disadvantages with BOTH INFO and events, and study what >> possible needs to defined related to negotiation etc, instead of just ignoring >> the real world and providing flexibility to people using SIP for their >> applications... >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> I believe at this point, this is an imaginary issue. >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 15 15:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVVL-0000MS-AC; Mon, 15 Oct 2007 15:21:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhVVI-0000ME-I6 for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 15:21:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVVH-0000Li-O7 for sip@ietf.org; Mon, 15 Oct 2007 15:21:27 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhVVH-0003T5-Dc for sip@ietf.org; Mon, 15 Oct 2007 15:21:27 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Mon, 15 Oct 2007 15:21:26 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 15 Oct 2007 15:21:26 -0400 From: Hadriel Kaplan To: Eric Burger , Christer Holmberg Date: Mon, 15 Oct 2007 15:21:17 -0400 Thread-Topic: Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoAAA8Q80APKhriYAC5BgcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List Subject: [Sip] RE: Unsolicited NOTIFY/INFO versus Solicited State Update 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Monday, October 15, 2007 7:49 AM > To: Christer Holmberg; Hadriel Kaplan > Cc: IETF SIP List > Subject: Unsolicited NOTIFY/INFO versus Solicited State Update > > A few times I have seen a comment stating the endpoint interested in > potentially receiving DTMF notifications may not know whether or not it > needs DTMF. As such, the endpoint would be forced to always issue a > SUBSCRIBE, even if it will not be interested in DTMF. > > Could someone please describe a scenario in which the endpoint does NOT > KNOW, a'priori, it will be interested in DTMF? > > All the ones I can think of, like supplemental dial digits, ACD, register > recall, and return to application are all known to the AS or Proxy drivin= g > the interaction. > > What else is out there? A PSTN gateway has no idea what the PSTN-side call goes to or came from. I= t may or may not need DTMF. That PSTN GW has to subscribe for every call i= f it (or the other end) doesn't do 2833, regardless if any DTMF get pressed= . The same for a SIP-H.323 gateway, a Skype-SIP gateway, etc. (for H.323 i= n particular the probability of 2833 support is very low) And even for a SIP AS that knows it needs DTMF, for some applications a KPM= L model will be more efficient than INFO, for others less... much less. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 15 15:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVtm-0005sQ-9s; Mon, 15 Oct 2007 15:46:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhVtj-0005pv-Df for sip-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 15:46:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVti-0005oR-JG for sip@ietf.org; Mon, 15 Oct 2007 15:46:42 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhVtd-0006aC-6J for sip@ietf.org; Mon, 15 Oct 2007 15:46:37 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Mon, 15 Oct 2007 15:46:36 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 15 Oct 2007 15:46:34 -0400 From: Hadriel Kaplan To: Eric Burger , Paul Kyzivat , Christer Holmberg , Dean Willis Date: Mon, 15 Oct 2007 15:46:22 -0400 Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgPIGuuqhbOQHsTEdyRsgAWy4mm/wAQD6gA Message-ID: References: <47128B84.9030208@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > > Let us take two scenarios for the easy case of transporting user stimulus= . > In the first case, the user presses a button and hangs up. Because of > normal Internet routing, the INFO (Invite-based Notification Function > Output > ;-) message arrives after the BYE arrives. What to do? What if the > button > pressed was "don't launch missiles?" And what happens if the Bye gets to the far end before a 2833 event? Impro= bable but not impossible. I would expect an application providing a "don't= launch missiles" type user input to provide a "missile launch order confir= med" that the user would wait to hear before hanging up. ;) > In the second case, the application is using digit maps, because the > application developer realizes that 1100 bytes of SIP headers to transpor= t > one byte of user stimulus information is stupid. The device buffers some > digits, but the user hangs up. What does the endpoint do? Does it send > the > collected digits? Does it eat the collected digits? Any argument other > than an explicit negotiation (like KPML does) is not going to work in the > general case. This is because if we say, for DTMF, "always send buffered > digits," then what we are really saying is, "always send what you have > before the dialog terminates." I could easily envision packages that > would > have tons of state that is immediately irrelevant at dialog termination. > Dumping tons of bytes on the network again totally defeats the "We want > this > because it is lightweight" argument. I'm not sure whether whomever writes a info-dtmf event package someday woul= d define it to support digit maps or not... my guess is they would not. Bu= t even if they did, I would assume the digits would be discarded in such a = case, and defined to do so. So what? The user hung up, without pressing a= sequence of digits that matched a map. What's wrong with discarding the d= igits? -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 03:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihgfx-0004rj-Fs; Tue, 16 Oct 2007 03:17:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihgfu-0004qQ-ML for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 03:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihgfu-0004ns-1Y for sip@ietf.org; Tue, 16 Oct 2007 03:17:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihgfi-0007fL-3d for sip@ietf.org; Tue, 16 Oct 2007 03:17:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6BBDF2076B; Tue, 16 Oct 2007 09:16:44 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-83-4714655c02de Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 55C7B20579; Tue, 16 Oct 2007 09:16:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 09:16:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Tue, 16 Oct 2007 09:16:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Thread-Index: AcgPIGuuqhbOQHsTEdyRsgAWy4mm/wAo1LCg References: <47128B84.9030208@cisco.com> From: "Christer Holmberg" To: "Eric Burger" , "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 16 Oct 2007 07:16:44.0170 (UTC) FILETIME=[818F06A0:01C80FC4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >Dialog termination is where I see the most potential for=20 >confusion. I would also offer these problems are not=20 >insurmountable. However, I would be curious to find out if=20 >solving these problems does not reconstruct RFC 3265 in its=20 >full glory. >=20 >Let us take two scenarios for the easy case of transporting=20 >user stimulus. >In the first case, the user presses a button and hangs up. =20 >Because of normal Internet routing, the INFO (Invite-based=20 >Notification Function Output >;-) message arrives after the BYE arrives. What to do? What=20 >if the button pressed was "don't launch missiles?" > >In the second case, the application is using digit maps,=20 >because the application developer realizes that 1100 bytes of=20 >SIP headers to transport one byte of user stimulus=20 >information is stupid. The device buffers some digits, but=20 >the user hangs up. What does the endpoint do? Does it send=20 >the collected digits? Does it eat the collected digits? Any=20 >argument other than an explicit negotiation (like KPML does)=20 >is not going to work in the general case. This is because if=20 >we say, for DTMF, "always send buffered digits," then what we=20 >are really saying is, "always send what you have before the=20 >dialog terminates." I could easily envision packages that=20 >would have tons of state that is immediately irrelevant at=20 >dialog termination. >Dumping tons of bytes on the network again totally defeats=20 >the "We want this because it is lightweight" argument. In both your examples: after the dialog is terminated, all data (e.g. buffered digits) and late messages (INFO not to launch missiles) will be discarded. That is normal SIP behavior. And, if you are going to use INFO to prevent world war III I THINK you would wait for the 200 OK before sending BYE :) 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 Tue Oct 16 04:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhZI-0002Zb-3L; Tue, 16 Oct 2007 04:14:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhhZG-0002Wl-96 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 04:14:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhZF-0002VT-1t for sip@ietf.org; Tue, 16 Oct 2007 04:14:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhhZB-0001Mg-F0 for sip@ietf.org; Tue, 16 Oct 2007 04:14:17 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D037C2102B; Tue, 16 Oct 2007 10:14:16 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-ff-471472d8abe9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ADB7C203C1; Tue, 16 Oct 2007 10:14:16 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 10:14:16 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 10:14:16 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2F11728EA; Tue, 16 Oct 2007 11:14:16 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 672234DC26; Tue, 16 Oct 2007 11:14:15 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DB2CB4DC25; Tue, 16 Oct 2007 11:14:14 +0300 (EEST) Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) From: Salvatore Loreto To: Christer Holmberg In-Reply-To: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <4710E415.3 070602@n ostrum.com> Content-Type: text/plain Date: Tue, 16 Oct 2007 11:14:12 +0300 Message-Id: <1192522452.4337.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 16 Oct 2007 08:14:16.0329 (UTC) FILETIME=[8B34AF90:01C80FCC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List , Francois Audet , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Mon, 2007-10-15 at 09:24 +0200, Christer Holmberg wrote: > [Christer] One issue with the subscription mechanism is that when A is > interested to receive events from B it sends a subscription to B. There > is basically no good way for A to tell B "Hey, I have some events I > would like to send you (if you support them), so please subscribe to > them". For some applications B KNOWS it will have to subscribe to > certain events from A, but in some cases B may again subscribe to events > "just in case". I think it would be useful if A somehow could indiate > which events it expects B to subscribe to for this specific call. > > Regards, > > Christer I fully agree. I do think it should be useful if we could discriminate somehow the following three cases - A is only interested to receive events from B - A is interested to receive events from B, but A is also interested to send events to B (A ask B to subscribe) - A is not interested to receive events from B, but A wants send events to B regards Sal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 05:09:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiLL-0004OD-W4; Tue, 16 Oct 2007 05:04:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhiLL-0004LA-0P for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 05:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiLK-0004KZ-14 for sip@ietf.org; Tue, 16 Oct 2007 05:04:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhiLD-0002do-Hy for sip@ietf.org; Tue, 16 Oct 2007 05:04:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0233A2059B; Tue, 16 Oct 2007 11:03:50 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-6f-47147e758298 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD2ED2015B; Tue, 16 Oct 2007 11:03:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 11:03:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 16 Oct 2007 11:03:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+wAOMs5UkADqmUsAAKRtNuAIKOB0AAAqJ7AAAUMvLQAJzElcAAAF9YEAX+GsThAAp1SmAADwbqOwAuoE8AAFOVHYAARWd2oA== References: From: "Christer Holmberg" To: "Eric Burger" X-OriginalArrivalTime: 16 Oct 2007 09:03:49.0665 (UTC) FILETIME=[7773C110:01C80FD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca 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: , Errors-To: sip-bounces@ietf.org Hi,=20 =09 >No. For subscribe/notify interaction, it is trivial: whomever issues the subscribe gets the notify. Easy for the stack to figure out. For INFO=20 >interaction, everything goes to call control. That works if your model is pure softswitch/feature server, but not many folks are doing that anymore. Assume two applications are interested of the same event, so they both subscribe to it. Now, how does the SENDER know to which subscription to use for a specific application? Regards, Christer =09 =09 =09 =09 Hi, =09 As I have said before: you have similar problems with other mechanisms. =09 Regards, =09 Christer =09 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: 12. lokakuuta 2007 12:45 > To: Christer Holmberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO > > Routing of the message once it gets to the device > (application), not route to the device (transport). > > -- > Sent from my wireless e-mail device. Sorry if terse. We all > need lemonade: see > for what lemonade is. > > ----- Original Message ----- > From: Christer Holmberg > To: Eric Burger; Hadriel Kaplan > Cc: sip > Sent: Thu Oct 11 19:38:06 2007 > Subject: RE: [Sip] INFO > > > Hi Eric, > > I am not sure I understand what you mean, but INFOs are > routed according to the route set of the invite dialog they > are sent within. > > If you want to transport information using some other path > you can of course not send the information within the invite dialog. > > Regards, > > Christer > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 0:35 > > To: Christer Holmberg; Hadriel Kaplan > > Cc: sip > > Subject: Re: [Sip] INFO > > > > Right: "DTMF may not be the only information users want to send to > > each other during a session." This is why one MUST > establish multiple > > subscription dialogs. How else would one keep track of the > different > > elements / local routing decisions? If you are proposing > application > > routing a'la P-Asserted-Service... > > > > > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > wrote: > > > > > > > > > > > Hi, > > > > > > Let's also keep in mind that DTMF may not be the only information > > > users want to send to each other during a session. So, you > > will need > > > to establish subscription dialogs for every type of event > that the > > > users may want to send during the session... > > > > > > Regards, > > > > > > Christer > > > > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> [mailto:christer.holmberg@ericsson.com] > > >> Sent: 11. syyskuuta 2007 12:27 > > >> To: Hadriel Kaplan; Eric Burger > > >> Cc: sip > > >> Subject: RE: [Sip] INFO > > >> > > >> > > >> Hi, > > >> > > >>>> Consider a PSTN call. The call goes from the gateway to > > >> softswitch / > > >>>> Proxy. Proxy routes to VM App Server. INFO has to > pass through > > >>>> softswitch / Proxy. > > >>>> In KPML-land, VM App Server *directly* subscribes to UAC > > key press > > >> state, bypassing the softswitch. > > >> > > >> [Christer] As I've said before, there are environments > where some > > >> proxies must (for whatever reason) be passed through. I guess an > > >> outbound proxy is a good example. > > >> > > >>>> KPML and INFO have the same number of messages for a > > SINGLE digit; > > >> KPML wins > > >>>> hands-down for multiple digits or reports. > > >>> > > >>> Not exactly - for a single digit, KPML would generate a > > >>> Subscribe/200/Notify/200 before the single DTMF was even > > pressed - > > >>> before the actual Notify with the digits in it. > > >>> And of course there is now also a subscribe dialog involved. > > >>> Assuming a one-shot single digit type, then, we're > talking 6 SIP > > >>> messages for KPML vs. 2 for Info. > > >> > > >> [Christer] And, in cases where you need to send DTMFs > (or whatever > > >> information) in both directions you actually need 2 subscription > > >> dialogs > > >> - one in each direction, and maintaining dialog state also > > consumes > > >> resources. And, in some cases you may not even know > > whether you will > > >> ever have to use the dialog. > > >> > > >> > > >>>> More importantly, let's take a Call Management (CM) > > >> application that > > >>>> calls a VM application when they cannot find the > > >> subscriber. INFO has > > >> > > >>>> to pass through the softswitch / Proxy to the CM > > >> application. Cool - > > >>>> it is a proxy, so it knows to relay. But OOPS! The CM > > application > > >>>> has to proxy the INFOs to the VM application. Yes - you > > could be a > > >>>> good programmer and remember to do that EVERYWHERE you > place an > > >>>> outbound call, but it is really easy to get wrong. > > >>> > > >>> I'm not sure I understand the scenario. The VM learned > > about this > > >>> call how? > > >>> By being in the signaling path, no? So why wouldn't the > > CM forward > > >>> INFO along the path? (I mean it is in the same dialog, > > after all)=20 > > >>> Now I don't doubt it could screw that up, and eat the > > info thinking > > >>> it was for itself, but lots of things can get screwed up > > - my guess > > >>> is KPML will not be impervious to screw ups. > > >> > > >> [Christer] I also have problems understanding the > > scenario. INFO is > > >> routed to wherever the INVITE that initiated the dialog > > was routed... > > >> > > >> 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 > > >> > > > > > > > > > > > Notice: This email message, together with any attachments, > > may contain information of BEA Systems, Inc., its > > subsidiaries and affiliated entities, that may be > > confidential, proprietary, copyrighted and/or legally > > privileged, and is intended solely for the use of the > > individual or entity named in this message. If you are not > > the intended recipient, and have received this message in > > error, please immediately return this by email and then delete it. > > > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > =09 =09 =09 =09 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 16 05:31:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhifE-0001zZ-67; Tue, 16 Oct 2007 05:24:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhifC-0001yV-D8 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 05:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhifB-0001yN-Og for sip@ietf.org; Tue, 16 Oct 2007 05:24:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihif5-0003J2-FI for sip@ietf.org; Tue, 16 Oct 2007 05:24:33 -0400 Received: by wx-out-0506.google.com with SMTP id s8so1764703wxc for ; Tue, 16 Oct 2007 02:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=C4waP5yu50OTUPkIe77ZKrGfE1tEa84ISwippKrsUIg=; b=b9i+oY0hc0O/VPLJbj6iqiT/QFsb+R9IUJoOROe3di2XC9Pm3AZK7HSyz5M0RWdLCH4B1+dJjwL7HR7PJxuvt4/xINdbu4tozq775bxJsWQzgikrrdq90SUj5Yal12s0MUQr/4nYgg5a+Y4ItJ8jL6Br9v4v6etvZoG5C+xNu30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=udsalgDin/vfKOZTMKIT+pqwfQVZA9RTHL9DMOb001Osszz895HLuO6o+tH3flL9KdugkeWyZwXAxea9fTT5bfJwBg2EzS5pQ3CcCfOIle1WOkBHrwQdoTuSdxyMo0mrMTMrXbjmDlBKUWM/Q/EvYET5XDOXxjUVDFbgJFK4ySE= Received: by 10.70.33.8 with SMTP id g8mr12719317wxg.1192526637003; Tue, 16 Oct 2007 02:23:57 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Tue, 16 Oct 2007 02:23:56 -0700 (PDT) Message-ID: <18a603a60710160223j1b395430q493a8598caea35db@mail.gmail.com> Date: Tue, 16 Oct 2007 11:23:56 +0200 From: "Pars Mutaf" To: "Adam Roach" Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) In-Reply-To: <471390D4.3010600@nostrum.com> MIME-Version: 1.0 References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> <471390D4.3010600@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Content-Type: multipart/mixed; boundary="===============0595760382==" Errors-To: sip-bounces@ietf.org --===============0595760382== Content-Type: multipart/alternative; boundary="----=_Part_38814_32174816.1192526637001" ------=_Part_38814_32174816.1192526637001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/15/07, Adam Roach wrote: > > This is sounding like it's less and less a SIP problem at all. Based on > what you say below, I think all you need is some additional vCard fields > (one for voice SIP URIs, and maybe one for home IPv6 addresses -- but > I'd pursue these as separate efforts, if I were you). You can then send > these vCards around in OBEX, email, web pages, or whatever else makes > sense. Note that OBEX over Bluetooth, IrDA, and/or SMS completely > satisfies the requirements you describe below -- and these are already > well-defined, mature, and widely deployed technologies. > > Look at RFC 4770 to see how vCard extensions look. vCARD is OK. I have asked a SIP question (I think this is the right place). Please answer my question about SIP trapezoid, or if you don't know, that's OK. As for your proposal for using Bluetooth or IrDA (discussion topic for humanresolvers ML), this is of course a point of view. But I think you missed the point. This is clearly an IP layer problem and technology independent. Why not use Wi-Fi? or WiMax? Why not use the Internet? You really don't see the benefits? /a > > Pars Mutaf wrote: > > > > > > On 10/12/07, *Spencer Dawkins* > > wrote: > > > > > The privacy problem: normally I shouldn't be able to discover > > your SIP URI. > > > > I'm guessing that if you can't tell people your SIP AOR, then SIP > > is not for > > you. > > > > > > Hello, > > > > I won't publish my SIP URI in a phone book allowing anyone to see it. > > We already agreed on that. > > > > I'll tell it to people that I know only. I'll tell it using a user > > friendly > > mechanism called "pairing" : We meet each other with our cell phones, > > and agree to exchange our contact information. So, the procedure is > > under our control. Pairing is good for us also because it allows us to > > exchange a secret key (note that this is already enough motivation for > > the pairing idea). > > > > The point is that, if I give you my SIP URI (using the pairing > procedure) > > then I can also give you my Mobile IPv6 home address using the same > > pairing procedure. In other words, there is _no more resolution_ from > > SIP URI to home IP address. You get them **concurrently**. > > > > We have each other's SIP URIs and home addresses. > > ->SIP application is happy, it has the target SIP URI. > > ->Routing problem is solved by mobile IPv6. > > > > My question was: do we need the SIP trapezoid in this case. > > > > Thanks, > > pars > > > > > > > > > > > > > > Thanks, > > > > Spencer > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu > > for questions on current > sip > > Use sipping@ietf.org for new > > developments on the application of sip > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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_38814_32174816.1192526637001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/15/07, Adam Roach <adam@nostrum.com > wrote:
This is sounding like it's less and less a SIP problem at all. Based on
what you say below, I think all you need is some additional vCard fields
(one for voice SIP URIs, and maybe one for home IPv6 addresses -- but
I'd pursue these as separate efforts, if I were you). You can then send
these vCards around in OBEX, email, web pages, or whatever else makes
sense. Note that OBEX over Bluetooth, IrDA, and/or SMS completely
satisfies the requirements you describe below -- and these are already
well-defined, mature, and widely deployed technologies.

Look at RFC 4770 to see how vCard extensions look.

vCARD is OK.

I have asked a SIP question (I think this is the right place). Please answer
my question about SIP trapezoid, or if you don't know, that's OK.

As for your proposal for using Bluetooth or IrDA (discussion topic for
humanresolvers ML), this is of course a point of view. But I think you missed
the point. This is clearly an IP layer problem and technology independent.
Why not use Wi-Fi? or WiMax? Why not use the Internet?

You really don't see the benefits?



/a

Pars Mutaf wrote:
>
>
> On 10/12/07, *Spencer Dawkins* <spencer@mcsr-labs.org
> <mailto: spencer@mcsr-labs.org>> wrote:
>
>     > The privacy problem: normally I shouldn't be able to discover
>     your SIP URI.
>
>     I'm guessing that if you can't tell people your SIP AOR, then SIP
>     is not for
>     you.
>
>
> Hello,
>
> I won't publish my SIP URI in a phone book allowing anyone to see it.
> We already agreed on that.
>
> I'll tell it to people that I know only. I'll tell it using a user
> friendly
> mechanism called "pairing" : We meet each other with our cell phones,
> and agree to exchange our contact information. So, the procedure is
> under our control. Pairing is good for us also because it allows us to
> exchange a secret key (note that this is already enough motivation for
> the pairing idea).
>
> The point is that, if I give you my SIP URI (using the pairing procedure)
> then I can also give you my Mobile IPv6 home address using the same
> pairing procedure. In other words, there is _no more resolution_ from
> SIP URI to home IP address. You get them **concurrently**.
>
> We have each other's SIP URIs and home addresses.
> ->SIP application is happy, it has the target SIP URI.
> ->Routing problem is solved by mobile IPv6.
>
> My question was: do we need the SIP trapezoid in this case.
>
> Thanks,
> pars
>
>
>
>
>
>
>     Thanks,
>
>     Spencer
>
>
>
>
>     _______________________________________________
>     Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
>     This list is for NEW development of the core SIP Protocol
>     Use sip-implementors@cs.columbia.edu
>     <mailto: sip-implementors@cs.columbia.edu> for questions on current sip
>     Use sipping@ietf.org <mailto: sipping@ietf.org> for new
>     developments on the application of sip
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_38814_32174816.1192526637001-- --===============0595760382== 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 --===============0595760382==-- From sip-bounces@ietf.org Tue Oct 16 08:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlV3-0006Pe-HF; Tue, 16 Oct 2007 08:26:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhlV0-0006NF-RT for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 08:26:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlUz-0006B9-2h for sip@ietf.org; Tue, 16 Oct 2007 08:26:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhlSS-0000vf-EU for sip@ietf.org; Tue, 16 Oct 2007 08:23:37 -0400 X-IronPort-AV: E=Sophos;i="4.21,283,1188802800"; d="scan'208";a="23904751" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2007 05:23:36 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9GCNZxW026713; Tue, 16 Oct 2007 05:23:35 -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 l9GCNW0G019400; Tue, 16 Oct 2007 12:23:35 GMT 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.1830); Tue, 16 Oct 2007 08:23:34 -0400 Received: from [10.86.242.67] ([10.86.242.67]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 08:23:34 -0400 Message-ID: <4714AD44.1040805@cisco.com> Date: Tue, 16 Oct 2007 08:23:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 12:23:34.0489 (UTC) FILETIME=[5EF6C490:01C80FEF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.002 X-TM-AS-Result: No--50.009000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9236; t=1192537415; x=1193401415; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=JiHBd4NAwV4KglE7m9b4Ezn9eO1HAlEYdrLL5Z2u5gE=; b=ea/enziFhg46gfCa+cuEdFaSR5dl7hNYOmea0DFyUb2+QVbE0VqA8+gdNS38EeIQUcqo62Fo JyG5RbFaCX9nmwGP5fB9B7uQNXBzWrUOyHtb0tE84XIWYcoSEv4t6S1a; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >> No. For subscribe/notify interaction, it is trivial: whomever issues > the subscribe gets the notify. Easy for the stack to figure out. For > INFO >> interaction, everything goes to call control. That works if your model > is pure softswitch/feature server, but not many folks are doing that > anymore. > > Assume two applications are interested of the same event, so they both > subscribe to it. Now, how does the SENDER know to which subscription to > use for a specific application? Is this a trick question? Or don't I understand you? If two applications have concurrent and identical subscriptions for the same event then they should both receive equivalent notifications. Paul > > > > > > > Hi, > > As I have said before: you have similar problems with > other mechanisms. > > Regards, > > Christer > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 12. lokakuuta 2007 12:45 > > To: Christer Holmberg > > Cc: sip@ietf.org > > Subject: Re: [Sip] INFO > > > > Routing of the message once it gets to the device > > (application), not route to the device (transport). > > > > -- > > Sent from my wireless e-mail device. Sorry if terse. > We all > > need lemonade: see > > > for what lemonade is. > > > > ----- Original Message ----- > > From: Christer Holmberg > > > To: Eric Burger; Hadriel Kaplan > > > Cc: sip > > Sent: Thu Oct 11 19:38:06 2007 > > Subject: RE: [Sip] INFO > > > > > > Hi Eric, > > > > I am not sure I understand what you mean, but INFOs > are > > routed according to the route set of the invite dialog > they > > are sent within. > > > > If you want to transport information using some other > path > > you can of course not send the information within the > invite dialog. > > > > Regards, > > > > Christer > > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@bea.com] > > > Sent: 12. lokakuuta 2007 0:35 > > > To: Christer Holmberg; Hadriel Kaplan > > > Cc: sip > > > Subject: Re: [Sip] INFO > > > > > > Right: "DTMF may not be the only information users > want to send to > > > each other during a session." This is why one MUST > > establish multiple > > > subscription dialogs. How else would one keep track > of the > > different > > > elements / local routing decisions? If you are > proposing > > application > > > routing a'la P-Asserted-Service... > > > > > > > > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > Let's also keep in mind that DTMF may not be the > only information > > > > users want to send to each other during a session. > So, you > > > will need > > > > to establish subscription dialogs for every type > of event > > that the > > > > users may want to send during the session... > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > >> -----Original Message----- > > > >> From: Christer Holmberg (JO/LMF) > > > >> [mailto:christer.holmberg@ericsson.com] > > > >> Sent: 11. syyskuuta 2007 12:27 > > > >> To: Hadriel Kaplan; Eric Burger > > > >> Cc: sip > > > >> Subject: RE: [Sip] INFO > > > >> > > > >> > > > >> Hi, > > > >> > > > >>>> Consider a PSTN call. The call goes from the > gateway to > > > >> softswitch / > > > >>>> Proxy. Proxy routes to VM App Server. INFO > has to > > pass through > > > >>>> softswitch / Proxy. > > > >>>> In KPML-land, VM App Server *directly* > subscribes to UAC > > > key press > > > >> state, bypassing the softswitch. > > > >> > > > >> [Christer] As I've said before, there are > environments > > where some > > > >> proxies must (for whatever reason) be passed > through. I guess an > > > >> outbound proxy is a good example. > > > >> > > > >>>> KPML and INFO have the same number of messages > for a > > > SINGLE digit; > > > >> KPML wins > > > >>>> hands-down for multiple digits or reports. > > > >>> > > > >>> Not exactly - for a single digit, KPML would > generate a > > > >>> Subscribe/200/Notify/200 before the single DTMF > was even > > > pressed - > > > >>> before the actual Notify with the digits in it. > > > >>> And of course there is now also a subscribe > dialog involved. > > > >>> Assuming a one-shot single digit type, then, > we're > > talking 6 SIP > > > >>> messages for KPML vs. 2 for Info. > > > >> > > > >> [Christer] And, in cases where you need to send > DTMFs > > (or whatever > > > >> information) in both directions you actually need > 2 subscription > > > >> dialogs > > > >> - one in each direction, and maintaining dialog > state also > > > consumes > > > >> resources. And, in some cases you may not even > know > > > whether you will > > > >> ever have to use the dialog. > > > >> > > > >> > > > >>>> More importantly, let's take a Call Management > (CM) > > > >> application that > > > >>>> calls a VM application when they cannot find > the > > > >> subscriber. INFO has > > > >> > > > >>>> to pass through the softswitch / Proxy to the > CM > > > >> application. Cool - > > > >>>> it is a proxy, so it knows to relay. But OOPS! > The CM > > > application > > > >>>> has to proxy the INFOs to the VM application. > Yes - you > > > could be a > > > >>>> good programmer and remember to do that > EVERYWHERE you > > place an > > > >>>> outbound call, but it is really easy to get > wrong. > > > >>> > > > >>> I'm not sure I understand the scenario. The VM > learned > > > about this > > > >>> call how? > > > >>> By being in the signaling path, no? So why > wouldn't the > > > CM forward > > > >>> INFO along the path? (I mean it is in the same > dialog, > > > after all) > > > >>> Now I don't doubt it could screw that up, and > eat the > > > info thinking > > > >>> it was for itself, but lots of things can get > screwed up > > > - my guess > > > >>> is KPML will not be impervious to screw ups. > > > >> > > > >> [Christer] I also have problems understanding the > > > scenario. INFO is > > > >> routed to wherever the INVITE that initiated the > dialog > > > was routed... > > > >> > > > >> 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 > > > >> > > > > > > > > > > > > > > > > Notice: This email message, together with any > attachments, > > > may contain information of BEA Systems, Inc., > its > > > subsidiaries and affiliated entities, that may be > > > confidential, proprietary, copyrighted and/or > legally > > > privileged, and is intended solely for the use of > the > > > individual or entity named in this message. If you > are not > > > the intended recipient, and have received this > message in > > > error, please immediately return this by email and > then delete it. > > > > > > > Notice: This email message, together with any > attachments, > > may contain information of BEA Systems, Inc., its > > subsidiaries and affiliated entities, that may be > > confidential, proprietary, copyrighted and/or > legally > > privileged, and is intended solely for the use of the > > individual or entity named in this message. If you are > not > > the intended recipient, and have received this message > in > > error, please immediately return this by email and > then delete it. > > > > > > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries and > affiliated entities, that may be confidential, proprietary, copyrighted > and/or legally privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not the intended > recipient, and have received this message in error, please immediately > return this by email and then delete it. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 09:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmZx-0000Lm-M1; Tue, 16 Oct 2007 09:35:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhmZv-0000J0-TV for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 09:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmZt-0000Ht-JG for sip@ietf.org; Tue, 16 Oct 2007 09:35:23 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhmZn-0003w3-FQ for sip@ietf.org; Tue, 16 Oct 2007 09:35:21 -0400 Received: by py-out-1112.google.com with SMTP id d32so6947768pye for ; Tue, 16 Oct 2007 06:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=e5G7aFoL1jtHPqpT074TOfyt3kUyKSgVvs8D35PNcA0=; b=C+jEyvQPdIk9H+tsDOQWQxEOen29syRVTN+gZzv57zACx7EZazmsr+33M7pPVG5PIBVOqicZqnSRcKw8GOWscJbYwGhWyXBcyfocZ0fl+w3T/2C5LPJ3tlaJ4hj+QxGyRXIklgXP04UGi85+82TOD7lfHlP0VL/90Rr0OzT1lX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=pFZHID42hc5RkeZDb81nqmSc/8xed7s1GrI74vl9redfzxl9kPFPm0LHKQw4PPG4giNz8aNV7bUOX/dRoITwIyWmIW2Q/PH/X5I6UtTsM8t6y0o9PPk8PzuN6Opc7V/rxbxTjaHW4cgVHDxknzQ3Bc18Br3Nb+uUfxHO5uSFHhA= Received: by 10.65.53.3 with SMTP id f3mr13872256qbk.1192541702200; Tue, 16 Oct 2007 06:35:02 -0700 (PDT) Received: from ?148.204.25.18? ( [148.204.25.18]) by mx.google.com with ESMTPS id f15sm3049740qba.2007.10.16.06.35.00 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Oct 2007 06:35:01 -0700 (PDT) Message-ID: <4714BE03.9040005@gmail.com> Date: Tue, 16 Oct 2007 08:34:59 -0500 From: =?ISO-8859-1?Q?Luis_Alberto_Cacho_Garc=EDa?= User-Agent: Thunderbird 2.0.0.0 (X11/20070326) 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] SIP in a FPGA with VHDL 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: , Errors-To: sip-bounces@ietf.org Hi, i'm newbie in this topic (SIP), and I tried to implement over FPGA specify in a Xilinx Spartan 3E, but the fact is that i don't know the architecture of SIP, I study the RFC3261 but I don't understand very well. I request your help to understand the protocol and implement in a FPGA with VHDL. I wait your answer. thanks... PD: Sorry, but my english is not very good xD _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 14:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihqcg-0000av-8k; Tue, 16 Oct 2007 13:54:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihqce-0000W1-UZ for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 13:54:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihqcd-0000RW-DJ for sip@ietf.org; Tue, 16 Oct 2007 13:54:27 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihqcc-00085t-2k for sip@ietf.org; Tue, 16 Oct 2007 13:54:27 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 55606203F7; Tue, 16 Oct 2007 19:54:25 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-1f-4714fad1f649 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3270720071; Tue, 16 Oct 2007 19:54:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 19:54:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 16 Oct 2007 19:54:20 +0200 Message-ID: In-Reply-To: <4714AD44.1040805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQD9zDAdc6EZwDQLWxi6sCX68Y/wADQisQ References: <4714AD44.1040805@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Oct 2007 17:54:24.0951 (UTC) FILETIME=[96C2E470:01C8101D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>No. For subscribe/notify interaction, it is trivial:=20 >>>whomever issues the subscribe gets the notify. Easy for the stack to figure=20 >>>out. For INFO >>>interaction, everything goes to call control. That works if your=20 >>>model is pure softswitch/feature server, but not many folks are=20 >>>doing that anymore. >>=20 >>Assume two applications are interested of the same event, so they both >>subscribe to it. Now, how does the SENDER know to which subscription=20 >>to use for a specific application? >=20 >Is this a trick question? Or don't I understand you? >=20 >If two applications have concurrent and identical=20 >subscriptions for the same event then they should both=20 >receive equivalent notifications. Yes, and that means that both applications will receive the event, even if the sender only intended to send the event to one of the applications. So, in that case: if the same information is sent in an INFO, the receiver will provide it to both application that has indicated to the stack that they want that type of information to be dispatched to them. Regards, Christer > >=20 > > =09 > > =09 > >=20 > > =09 > > =09 > > Hi, > > =09 > > As I have said before: you have similar=20 > problems with other=20 > > mechanisms. > > =09 > > Regards, > > =09 > > Christer > > =09 > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@bea.com] > > > Sent: 12. lokakuuta 2007 12:45 > > > To: Christer Holmberg > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO > > > > > > Routing of the message once it gets to the device > > > (application), not route to the device (transport). > > > > > > -- > > > Sent from my wireless e-mail device. Sorry if terse. > > We all > > > need lemonade: see > > > > > for what lemonade is. > > > > > > ----- Original Message ----- > > > From: Christer Holmberg > > > > > To: Eric Burger; Hadriel Kaplan > > > > > Cc: sip > > > Sent: Thu Oct 11 19:38:06 2007 > > > Subject: RE: [Sip] INFO > > > > > > > > > Hi Eric, > > > > > > I am not sure I understand what you mean, but=20 > INFOs are > > > routed according to the route set of the=20 > invite dialog they > > > are sent within. > > > > > > If you want to transport information using=20 > some other path > > > you can of course not send the information=20 > within the invite=20 > > dialog. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > -----Original Message----- > > > > From: Eric Burger [mailto:eburger@bea.com] > > > > Sent: 12. lokakuuta 2007 0:35 > > > > To: Christer Holmberg; Hadriel Kaplan > > > > Cc: sip > > > > Subject: Re: [Sip] INFO > > > > > > > > Right: "DTMF may not be the only=20 > information users want to send=20 > > to > > > > each other during a session." This is why one MUST > > > establish multiple > > > > subscription dialogs. How else would one=20 > keep track of the > > > different > > > > elements / local routing decisions? If you=20 > are proposing > > > application > > > > routing a'la P-Asserted-Service... > > > > > > > > > > > > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)" > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Let's also keep in mind that DTMF may not=20 > be the only=20 > > information > > > > > users want to send to each other during a session. > > So, you > > > > will need > > > > > to establish subscription dialogs for=20 > every type of event > > > that the > > > > > users may want to send during the session... > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > >> -----Original Message----- > > > > >> From: Christer Holmberg (JO/LMF) > > > > >> [mailto:christer.holmberg@ericsson.com] > > > > >> Sent: 11. syyskuuta 2007 12:27 > > > > >> To: Hadriel Kaplan; Eric Burger > > > > >> Cc: sip > > > > >> Subject: RE: [Sip] INFO > > > > >> > > > > >> > > > > >> Hi, > > > > >> > > > > >>>> Consider a PSTN call. The call goes=20 > from the gateway to > > > > >> softswitch / > > > > >>>> Proxy. Proxy routes to VM App Server.=20 > INFO has to > > > pass through > > > > >>>> softswitch / Proxy. > > > > >>>> In KPML-land, VM App Server *directly*=20 > subscribes to UAC > > > > key press > > > > >> state, bypassing the softswitch. > > > > >> > > > > >> [Christer] As I've said before, there=20 > are environments > > > where some > > > > >> proxies must (for whatever reason) be=20 > passed through. I guess=20 > > an > > > > >> outbound proxy is a good example. > > > > >> > > > > >>>> KPML and INFO have the same number of=20 > messages for a > > > > SINGLE digit; > > > > >> KPML wins > > > > >>>> hands-down for multiple digits or reports. > > > > >>> > > > > >>> Not exactly - for a single digit, KPML=20 > would generate a > > > > >>> Subscribe/200/Notify/200 before the=20 > single DTMF was even > > > > pressed - > > > > >>> before the actual Notify with the digits in it. > > > > >>> And of course there is now also a=20 > subscribe dialog involved. > > > > >>> Assuming a one-shot single digit type,=20 > then, we're > > > talking 6 SIP > > > > >>> messages for KPML vs. 2 for Info. > > > > >> > > > > >> [Christer] And, in cases where you need=20 > to send DTMFs > > > (or whatever > > > > >> information) in both directions you actually need > > 2 subscription > > > > >> dialogs > > > > >> - one in each direction, and maintaining=20 > dialog state also > > > > consumes > > > > >> resources. And, in some cases you may=20 > not even know > > > > whether you will > > > > >> ever have to use the dialog. > > > > >> > > > > >> > > > > >>>> More importantly, let's take a Call Management > > (CM) > > > > >> application that > > > > >>>> calls a VM application when they=20 > cannot find the > > > > >> subscriber. INFO has > > > > >> > > > > >>>> to pass through the softswitch / Proxy=20 > to the CM > > > > >> application. Cool - > > > > >>>> it is a proxy, so it knows to relay. But OOPS! > > The CM > > > > application > > > > >>>> has to proxy the INFOs to the VM application. > > Yes - you > > > > could be a > > > > >>>> good programmer and remember to do=20 > that EVERYWHERE you > > > place an > > > > >>>> outbound call, but it is really easy=20 > to get wrong. > > > > >>> > > > > >>> I'm not sure I understand the scenario.=20 > The VM learned > > > > about this > > > > >>> call how? > > > > >>> By being in the signaling path, no? So=20 > why wouldn't the > > > > CM forward > > > > >>> INFO along the path? (I mean it is in=20 > the same dialog, > > > > after all)=20 > > > > >>> Now I don't doubt it could screw that=20 > up, and eat the > > > > info thinking > > > > >>> it was for itself, but lots of things=20 > can get screwed up > > > > - my guess > > > > >>> is KPML will not be impervious to screw ups. > > > > >> > > > > >> [Christer] I also have problems understanding the > > > > scenario. INFO is > > > > >> routed to wherever the INVITE that=20 > initiated the dialog > > > > was routed... > > > > >> > > > > >> Regards, > > > > >> > > > > >> Christer > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > > >> This list is for NEW development of the=20 > core SIP Protocol Use > > > > >> sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > >> sipping@ietf.org for new developments on=20 > the application of=20 > > sip > > > > >> > > > > > > > > > > > > > > > > > > > > > Notice: This email message, together with=20 > any attachments, > > > > may contain information of BEA Systems, Inc., its > > > > subsidiaries and affiliated entities, that may be > > > > confidential, proprietary, copyrighted =20 > and/or legally > > > > privileged, and is intended solely for the=20 > use of the > > > > individual or entity named in this message.=20 > If you are not > > > > the intended recipient, and have received=20 > this message in > > > > error, please immediately return this by=20 > email and then delete=20 > > it. > > > > > > > > > > Notice: This email message, together with=20 > any attachments, > > > may contain information of BEA Systems, Inc., its > > > subsidiaries and affiliated entities, that may be > > > confidential, proprietary, copyrighted =20 > and/or legally > > > privileged, and is intended solely for the use of the > > > individual or entity named in this message.=20 > If you are not > > > the intended recipient, and have received=20 > this message in > > > error, please immediately return this by=20 > email and then delete it. > > > > > =09 > > =09 > >=20 > > =09 > > =09 > > Notice: This email message, together with any attachments, may=20 > > contain information of BEA Systems, Inc., its subsidiaries and=20 > > affiliated entities, that may be confidential, proprietary,=20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > >=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=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 16 14:41:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrIu-0003MX-Lr; Tue, 16 Oct 2007 14:38:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhrIt-0003Hs-Af for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 14:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrIs-0003GL-I2 for sip@ietf.org; Tue, 16 Oct 2007 14:38:06 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhrIr-0008BZ-6Y for sip@ietf.org; Tue, 16 Oct 2007 14:38:06 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9GIbo2F099742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 13:37:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471504F9.9040200@nostrum.com> Date: Tue, 16 Oct 2007 13:37:45 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Pars Mutaf Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> <471390D4.3010600@nostrum.com> <18a603a60710160223j1b395430q493a8598caea35db@mail.gmail.com> In-Reply-To: <18a603a60710160223j1b395430q493a8598caea35db@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 20:43:55 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Pars Mutaf wrote: > I have asked a SIP question (I think this is the right place). Please > answer > my question about SIP trapezoid, or if you don't know, that's OK. Nothing mandates a trapezoid. That kind of deployment can be useful for certain architectures, but SIP can work just fine without it. A trapezoid deployment can be useful for certain things; three come to mind immediately: * Rendezvous (although technically all you need for rendezvous is a triangle, not a trapezoid). Note that there are other potential solutions here, such as fixed IP addresses (including mobile IP), dynamic DNS, DHTs, and HIP. * NAT and firewall traversal (using the outbound extensions). This is only necessary if you're behind a NAT or a Firewall. Even then, there may be other solutions depending on what you are trying to accomplish, such as STUN/TURN, SOCKS, VPNs, uPNP, etc. * Network provided services. Most services can be successfully implemented in the terminal, but there seems to be a trend of pushing most services into the network (probably because it's difficult to charge people recurring fees for something their phone knows how to do). If you end up with users who have network-provided services, then you'll need to go through their servers. If you don't need any of these things, then a trapezoid is unnecessary. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 16 15:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrmp-0003sg-2r; Tue, 16 Oct 2007 15:09:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihrmn-0003ps-CR for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 15:09:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrmm-0003nA-Dn for sip@ietf.org; Tue, 16 Oct 2007 15:09:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihrmm-00029k-1e for sip@ietf.org; Tue, 16 Oct 2007 15:09:00 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188792000"; d="scan'208";a="135030533" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Oct 2007 15:08:59 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9GJ8vSS017759; Tue, 16 Oct 2007 15:08:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9GJ8I8t000601; Tue, 16 Oct 2007 19:08:53 GMT 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.1830); Tue, 16 Oct 2007 15:08:48 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 15:08:47 -0400 Message-ID: <47150C3E.4030100@cisco.com> Date: Tue, 16 Oct 2007 15:08:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <4714AD44.1040805@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 19:08:47.0989 (UTC) FILETIME=[FAF07250:01C81027] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.002 X-TM-AS-Result: No--19.022500-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2010; t=1192561737; x=1193425737; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=Gaw71PCk5td9DAbGhozluxJ0bhAqdhoS1cQRC7tT11I=; b=ep0DP+obvcbXplENq6rGDzcBZ/zffyoqFlVHt2dBP1z7JL9j+Z3bwnfYdgjzN9xgel0YRAN5 i/UFTIMbCnsPgcBst3E6p10HBcWbnreiaAgOq6QYsmPHY5N5BRbEuIdZ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>>> No. For subscribe/notify interaction, it is trivial: >>>> whomever issues the subscribe gets the notify. Easy for the stack to > figure >>>> out. For INFO >>>> interaction, everything goes to call control. That works if your >>>> model is pure softswitch/feature server, but not many folks are >>>> doing that anymore. >>> Assume two applications are interested of the same event, so they both > >>> subscribe to it. Now, how does the SENDER know to which subscription >>> to use for a specific application? >> Is this a trick question? Or don't I understand you? >> >> If two applications have concurrent and identical >> subscriptions for the same event then they should both >> receive equivalent notifications. > > Yes, and that means that both applications will receive the event, even > if the sender only intended to send the event to one of the > applications. > > So, in that case: if the same information is sent in an INFO, the > receiver will provide it to both application that has indicated to the > stack that they want that type of information to be dispatched to them. I have lost my way in this conversation. In the context of sub/not when we talk about multiple applications being interested in the same event, they are typically not resident in the same UA. For instance for DTMF we may have a pre-paid application acting as a B2BUA and an IVR at the far end that also wants to interact with the caller. You are talking about two applications resident in the same UA. That is usually outside the scope of our discussions. In general the source if the info (the notifier or sender of INFO) won't know where it wants to send the info, or that there might be multiple consumers of it. In the case of sub/not it is told this by SUBSCRIBEs. In the case of INFO there really isn't any point in it knowing if there are multiple consumers, since that won't alter its behavior. 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 Tue Oct 16 15:21:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrw1-0006fr-Ou; Tue, 16 Oct 2007 15:18:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihrvz-0006du-LC for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 15:18:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihrvy-0006dE-P5 for sip@ietf.org; Tue, 16 Oct 2007 15:18:30 -0400 Received: from chip2og56.obsmtp.com ([64.18.13.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihrvy-0002Q5-7q for sip@ietf.org; Tue, 16 Oct 2007 15:18:30 -0400 Received: from source ([192.150.11.134]) by chip2ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 16 Oct 2007 12:18:23 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l9GJGGIQ028346; Tue, 16 Oct 2007 12:16:16 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l9GJI1FX005665; Tue, 16 Oct 2007 12:18:04 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 04:18:02 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 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 trapezoid (was Re: IETF solution for pairing cellularhosts) Date: Tue, 16 Oct 2007 12:17:51 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE14B@namail5.corp.adobe.com> In-Reply-To: <471504F9.9040200@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP trapezoid (was Re: IETF solution for pairing cellularhosts) Thread-Index: AcgQJGupsIysVHnlTUGxNtiRyCYr1gAA7qDg References: <18a603a60710120619h7dba8cabsa49986efa1484664@mail.gmail.com> <470F8B54.1030506@cisco.com> <18a603a60710120812l3e9fc91r1a94aa80caebc091@mail.gmail.com> <470F9C47.4040702@cisco.com> <18a603a60710120951t473af562qd99bd695681aeba3@mail.gmail.com> <115501c80cf3$35f27ed0$6a01a8c0@china.huawei.com> <18a603a60710121043m2c0801bfnc07884dd408b3c4e@mail.gmail.com> <471390D4.3010600@nostrum.com><18a603a60710160223j1b395430q493a8598caea35db@mail.gmail.com> <471504F9.9040200@nostrum.com> From: "Henry Sinnreich" To: "Adam Roach" , "Pars Mutaf" X-OriginalArrivalTime: 16 Oct 2007 19:18:02.0028 (UTC) FILETIME=[452C16C0:01C81029] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: sip-bounces@ietf.org Adam's summary is the best of such that I have seen. One could only add regarding NAT traversal, in P2P SIP networks many folks are convinced that a large number of peers behind p2p-friendly NAT can act as STUN and media relay servers for other peers and for p2p clients as well. This has however yet to be proven from deployment statistics on the Internet, but for what it's worth, Skype has proven such an approach can work. Henry -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, October 16, 2007 11:38 AM To: Pars Mutaf Cc: sip@ietf.org Subject: Re: [Sip] SIP trapezoid (was Re: IETF solution forpairing cellularhosts) Pars Mutaf wrote: > I have asked a SIP question (I think this is the right place). Please=20 > answer > my question about SIP trapezoid, or if you don't know, that's OK. Nothing mandates a trapezoid. That kind of deployment can be useful for=20 certain architectures, but SIP can work just fine without it. A trapezoid deployment can be useful for certain things; three come to=20 mind immediately: * Rendezvous (although technically all you need for rendezvous is a triangle, not a trapezoid). Note that there are other potential solutions here, such as fixed IP addresses (including mobile IP), dynamic DNS, DHTs, and HIP. * NAT and firewall traversal (using the outbound extensions). This is only necessary if you're behind a NAT or a Firewall. Even then, there may be other solutions depending on what you are trying to accomplish, such as STUN/TURN, SOCKS, VPNs, uPNP, etc. * Network provided services. Most services can be successfully implemented in the terminal, but there seems to be a trend of pushing most services into the network (probably because it's difficult to charge people recurring fees for something their phone knows how to do). If you end up with users who have network-provided services, then you'll need to go through their servers. If you don't need any of these things, then a trapezoid is unnecessary. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 16 16:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhssJ-0003so-Cd; Tue, 16 Oct 2007 16:18:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhssH-0003r4-Cy for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 16:18:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhssG-0003kA-FU for sip@ietf.org; Tue, 16 Oct 2007 16:18:44 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihsrq-0004SZ-Uj for sip@ietf.org; Tue, 16 Oct 2007 16:18:19 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l9GKI1Oa026122; Tue, 16 Oct 2007 15:18:01 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l9GKHuj13317; Tue, 16 Oct 2007 15:17:56 -0500 (CDT) Message-ID: <47151C74.10303@alcatel-lucent.com> Date: Tue, 16 Oct 2007 15:17:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Rohan Mahy , Brett Tate Subject: [Sip] connect-reuse-08 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: , Errors-To: sip-bounces@ietf.org Folks: Based on the quick discussion during the second SIP WG meeting in the Chicago IETF, connect-reuse has been revised to include the updated Abstract. It has also been aligned with domain-certs and includes discussion for SCTP as an additional transport. Until the IETF archive is updated, the -08 version can be obtained from: https://svn.resiprocate.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-08.txt https://svn.resiprocate.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-08.html A diff between -07 and -08 is at: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-07.txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-08.txt Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 16:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtN5-0006uz-CE; Tue, 16 Oct 2007 16:50:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhtN3-0006ut-Gn for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 16:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtN2-0006ul-O8 for sip@ietf.org; Tue, 16 Oct 2007 16:50:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhtN2-0005Ns-A0 for sip@ietf.org; Tue, 16 Oct 2007 16:50:32 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GKoKoh002742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 15:50:21 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1274760A@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1274760A@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <919971E4-873B-48FD-8784-67C706EE15DD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Date: Tue, 16 Oct 2007 15:50:02 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 12, 2007, at 11:32 AM, Brian Stucker wrote: > I'm missing something here. > > When I send a SUBSCRIBE I'm saying the following, "For the resource > identified by the request-URI, I'd like to synchronize with a > particular > state machine for X seconds with the state data encoded in format Y." > The other end can accept or reject the request as a whole, there is no > offer/answer negotiation going on. > Mostly. Except that you're ALSO saying "And I expect the data transmitted to me as a result of this subscription to have the meaning (aka semantic) specified by the specific event package named in the subscription." That's more than saying "Please send me jpeg images". And with Francois' proposal, you're saying that you'd like to synchronize with that same state machine, as it applies to the current dialog, for the duration of the current dialog, with the state data encoded as indicated by the event package and to have the meaning specified by the event package. > If we were to trigger a subscription based upon the INVITE that takes > care of targeting the resource and the duration of interest and leaves > out identifying the particular state machine you want to synchronize > with and how you want to encode the state data. Huh? No you still have to say which event package you're talking about. > > Can't I identify the state machine I want to synchronize with using a > supported header and the encoding using the accept header, specifying > the pair-values that are legal in an IETF document? Isn't this what > RFC-3312 did, and although integrated differently into the protocol > because the state machine being synchronized was SIP itself what > RFC-3262 does? > Not quite sure of the relationship to 3312. It seems to me that RFC 3312 negotiates a fixed set of preconditions with explicit values, whereas INFO (and events) encompasses a much broader range. That's why RFC 3265 adds the event-package name and registry process. -_ 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 16 16:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtSh-0000d2-HB; Tue, 16 Oct 2007 16:56:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhtSf-0000cT-V5 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 16:56:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtSf-0000cJ-39 for sip@ietf.org; Tue, 16 Oct 2007 16:56:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhtSe-0005Wz-Jt for sip@ietf.org; Tue, 16 Oct 2007 16:56:21 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GKuFkc002773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 15:56:16 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Tue, 16 Oct 2007 15:55:58 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 12, 2007, at 12:02 PM, Brian Stucker wrote: >> >> That's back to the question of "Is SIP an application >> protocol or a transport protocol"? >> >> Should the SIP-layer software be aware of and coupled to the >> state of the application that's using SIP? >> >> If so, then the proper design model is to build a new SIP >> request method for every new piece of application functionality. > > You forgot about supported. > Well, it's entirely possible that Supported and Accept will get damned big. I'd still like to have a query-for-specific or "opt in" model rather than a blanket "here's everything I can possibly deal with" model for declaration of extensions. RFC 3265 meets that requirement. >> >> So for example, DTMF: Using this model of SIP extension, we >> might define a new "DTMF" method. It would look just like >> DTMF-over-INFO, except the name of the method would be DTMF. >> It clearly resolves the INFO-context question, because now we >> KNOW we're getting dialog- related DTMF over it, and we know >> what to do with it. We know what we can transport in >> DTMF-requests, because the RFC that defines the DTMF >> extension method will also define exactly what payload format to use. > > INVITE > Supported: foo > Allow: INFO > Accept: application/foo > But the MIME people aren't going to let you register a new MIME type for "foo" that is specific to each application semantic that might possibly use "foo". > 200 OK > Supported: foo > Allow: INFO > Accept: application/foo > > ... > > INFO > Content-Type: application/foo > [DTMF] > > > Where is this broken? >> Broken in its usage of MIME. Let's say we have something (not DTMF) that needs to transport jpg images that are used as soft-key overlays. To do what you're suggesting, we'd need a new MIME-type registration that says "This is just like jpeg, except that it is only useful for keypad overlays". The MIME folks would birth kittens. >> This too is a clean solution to the problem, although it >> embodies a different design philosophy than the same-dialog NOTIFY. >> >> This leads back to my question: What is the right extension >> modality for SIP? Until we have an answer here, we're going >> to keep going back and forth on this. MAKE A DECISION, PEOPLE! > > You can't feasibly make a clean one. There will always be SDP vs. > non-SDP extension modalities. > Yeah, that's true. But maybe we narrow it down to SDP vs non-SDP instead of SDP vs SIP method vs MIME type vs event-package vs MSRP vs whatever. -- 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 16 16:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtV4-0002yS-ED; Tue, 16 Oct 2007 16:58:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhtV1-0002sI-Ko for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 16:58:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtV0-0002ri-N4 for sip@ietf.org; Tue, 16 Oct 2007 16:58:46 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhtV0-0005aL-Cj for sip@ietf.org; Tue, 16 Oct 2007 16:58:46 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GKwcwl002824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 15:58:39 -0500 In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F01816D0B@MAIL02.cedarpointcom.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com>!!! ! ! ! ! < 8F6 5 DB 2 7-41 E D-42F 3-97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F01816D0B@MAIL02.cedarpointcom.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <788BC4DD-F1C1-4C66-AA30-051AAC59499B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Tue, 16 Oct 2007 15:58:21 -0500 To: Sumit Garg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , Francois Audet , Christer Holmberg , "DRAGE, Keith \(Keith\)" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On Oct 12, 2007, at 1:19 PM, Sumit Garg wrote: > > I see the need for being able to implicitly SUBSCRIBE for certain > events > in the INVITE/200 OK itself. Whether we get those notifications in an > INFO or a NOTIFY does not matter that much. I could even use the RTCP > summary if it was in the BYE/200 (where it logically belongs). > I think you mean "explicitly subscribe", not "implicitly subscribe. If you've said (in the INVITE or in the 200 OK) which events you're hoping to see, that's explicit. Explicit is Good. It means never having to guess. -- 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 16 17:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtc9-0004sH-11; Tue, 16 Oct 2007 17:06:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihtc6-0004qT-S4 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtc6-0004q8-0q for sip@ietf.org; Tue, 16 Oct 2007 17:06:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihtbz-0004d9-R8 for sip@ietf.org; Tue, 16 Oct 2007 17:06:06 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GL5ibp002901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 16:05:46 -0500 In-Reply-To: <4710E415.3070602@nostrum.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!! .com> ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <4! 710E415.3070602@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <173CE682-9694-4E17-AC14-8E3081DFF680@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Tue, 16 Oct 2007 16:05:27 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List , Francois Audet 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: , Errors-To: sip-bounces@ietf.org On Oct 13, 2007, at 10:28 AM, Adam Roach wrote: > Answering a little bit of your scenario and a little bit of Francois': > > 1. Support must be explicit. Everything described so far makes > indication of the ability to receive an INVITE (or NOTIFY in > Francois' case) implicit in circumstances where such an > implication can be accidental. There are legitimate situations in > which any of the proposed heuristics used to perform such an > implication may legitimately exist and yet not mean that the > recipient is requesting INFO (or NOTIFY) requests. > I don't see this, in Francois' proposal at least. If an INVITE request contains Supported: In-Dialog-Events Accept-Event-Packages: DTMF (syntax is negotiable, of course) then this is explicitly saying "You can send me events of the DTMF event package related to this dialog and I am prepared to deal with them". It's pretty much everything that a SUBSCRIBE has I'd suggest further it doesn't really need to generate an initial NOTIFY, depending on the event package. -- 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 16 17:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtgd-0002NQ-2J; Tue, 16 Oct 2007 17:10:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihtgb-0002LH-C8 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtga-0002H7-20 for sip@ietf.org; Tue, 16 Oct 2007 17:10:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhtgY-0004kc-Re for sip@ietf.org; Tue, 16 Oct 2007 17:10:44 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GLAVdT002940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 16:10:32 -0500 In-Reply-To: <47128B84.9030208@cisco.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CCF5C86@sea02-mxc01.citel.com> <47! 128B84.9030208@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing aboutwhen we say INFO?) Date: Tue, 16 Oct 2007 16:10:14 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List , Francois Audet , Michael Procter , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 14, 2007, at 4:35 PM, Paul Kyzivat wrote: > > > Christer Holmberg wrote: > >> I haven't thought about this proposal in detail yet, but we would >> also >> need to take the the dialog-reuse spec (which proposes NOT to mix >> dialog >> usages) into consideration. But, if we somehow could bind the >> subscription lifetime to the dialog lifetime I think that at least >> some >> of the issues in that spec would be solved. > > The lifetime of a dialog isn't an independent variable - it ends > when the last dialog usage ends. > > If you are really talking about implicit *subscriptions*, then you > either must explicitly end them, or else define their *implicit* > end in terms of something that has an explicit endpoint. > > I expect that you are talking about something that either shares > the invite dialog usage, or else a distinct dialog usage that > implicitly starts and stops concurrently with the invite dialog usage. I believe we're talking about something that explicitly shares the INVITE dialog usage. Once a BYE transaction has been processed, it's over with. Yeah, you get all the usual dialog-usage termination race conditions (like BYE overlaps) but that's just the way it is with dialogs. Heck, that's the way it is with any session-oriented protocol, even TCP. -- 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 16 17:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtgX-0002Bh-SZ; Tue, 16 Oct 2007 17:10:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhtgV-00029Y-O1 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhtgU-00026o-C0 for sip@ietf.org; Tue, 16 Oct 2007 17:10:38 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhtgO-0004k0-1o for sip@ietf.org; Tue, 16 Oct 2007 17:10:38 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6C3FB20906; Tue, 16 Oct 2007 23:10:16 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-fc-471528b83435 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5D78420573; Tue, 16 Oct 2007 23:10:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 23:10:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 16 Oct 2007 23:10:15 +0200 Message-ID: In-Reply-To: <47150C3E.4030100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQKAHCwy/wjZbYSJesVb1mzmyhCgADyrmQ References: <4714AD44.1040805@cisco.com> <47150C3E.4030100@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Oct 2007 21:10:15.0841 (UTC) FILETIME=[F2D66910:01C81038] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: sip-bounces@ietf.org Hi,=20 =20 >>>>>No. For subscribe/notify interaction, it is trivial:=20 >>>>>whomever issues the subscribe gets the notify. Easy for=20 >>>>>the stack to figure out. For INFO >>>>>interaction, everything goes to call control. That works if your=20 >>>>>model is pure softswitch/feature server, but not many folks are=20 >>>>>doing that anymore. >>>>Assume two applications are interested of the same event, so they=20 >>>>both subscribe to it. Now, how does the SENDER know to which=20 >>>>subscription to use for a specific application? >>>Is this a trick question? Or don't I understand you? >>> >>>If two applications have concurrent and identical subscriptions for=20 >>>the same event then they should both receive equivalent=20 >>>notifications. >>=20 >>Yes, and that means that both applications will receive the event,=20 >>even if the sender only intended to send the event to one of the=20 >>applications. >>=20 >>So, in that case: if the same information is sent in an INFO, the=20 >>receiver will provide it to both application that has indicated to the >>stack that they want that type of information to be dispatched to them. >=20 >I have lost my way in this conversation. >=20 >In the context of sub/not when we talk about multiple=20 >applications being interested in the same event, they are=20 >typically not resident in the same UA.=20 > >For instance for DTMF we may have a pre-paid application acting as a B2BUA and an=20 >IVR at the far end that also wants to interact with the caller. Then the B2BUA has to be designed in a way so things works. It can choose to collect the pre-paid DTMFs before contacting the IVR, or something else. It's not up to us to design those B2BUAs. =20 =20 >You are talking about two applications resident in the same=20 >UA. That is usually outside the scope of our discussions. I would hope so, but I think Eric brought this case up at one point. >In general the source if the info (the notifier or sender of=20 >INFO) won't know where it wants to send the info, or that=20 >there might be multiple consumers of it. In the case of=20 >sub/not it is told this by SUBSCRIBEs.=20 >In the case of INFO there really isn't any point in it=20 >knowing if there are multiple consumers, since that won't=20 >alter its behavior. Fine, so it's not a problem then. 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 Tue Oct 16 17:21:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtoe-00009S-57; Tue, 16 Oct 2007 17:19:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihtob-000093-IA for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:19:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihtoa-00007g-EM for sip@ietf.org; Tue, 16 Oct 2007 17:19:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhtoZ-0006dg-W4 for sip@ietf.org; Tue, 16 Oct 2007 17:19:00 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GLImrS003018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 16:18:50 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 16 Oct 2007 16:18:32 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip , Francois Audet , "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: , Errors-To: sip-bounces@ietf.org On Oct 15, 2007, at 1:26 PM, Brian Stucker wrote: >> >> The trick is demuxing the event streams, or in other words, >> figuring out the context for each event. INFO currently gives >> us nothing but the content- modifiers to figure this out. >> That's not enough, as has widely been argued. > > How does 3265 make this any better? > > We're talking about identifying a data blob using an event plus a > content-type instead of a supported plus a content-type for a > period of > time to start and end in conjunction with the INVITE dialog (so the > subsciption-state header is mooted). > > 3265 makes it better in two ways: 1) It provides distinct dialogs for each channel of the mux. Thus, two events of the same class, but related to different subscriptions, can be distinguished. 2) It provides semantic distinction, such that two events that transport the same kind of content but that have different effects on the application can be distinguished. The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but retains 2. The argument is that this makes it good enough for some applications. However, there are obviously applications where it might NOT be good enough, and a separate dialog ala 3265 would be required. > So a NOTIFY with an event header or an INFO without an event > header, all > other things being the same and the constrained semantics of the > NOTIFY > usage being put forward here... > > Wouldn't it be equally valid to simply allow the INFO message to carry > an event header and say that INFO is the same as a NOTIFY with an > implicit subscription to an INVITE dialog? Isn't this pretty much what > it does already (minus the event header). > There needs to be an explicit declaration of willingness to receive the semantic load indicated by the event package. Given that, one could certainly envision revising INFO to do the job. > Deep thought: Is all INFO is missing is simply the event header? Yes. The problem is that INVITE and 200 (OK) are missing the "subscribe" header. -- 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 16 17:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihts5-0005HP-86; Tue, 16 Oct 2007 17:22:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihts3-0005Fh-QQ for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihts3-0005DD-1o for sip@ietf.org; Tue, 16 Oct 2007 17:22:35 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihtrv-0005c5-Cy for sip@ietf.org; Tue, 16 Oct 2007 17:22:33 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9GLMEFC003045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 16:22:15 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B782CF5-DFBE-4C93-AE60-4F319552BC43@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 16 Oct 2007 16:21:57 -0500 To: Christer Holmberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: sip-bounces@ietf.org On Oct 16, 2007, at 4:03 AM, Christer Holmberg wrote: > > Hi, > >> No. For subscribe/notify interaction, it is trivial: whomever issues > the subscribe gets the notify. Easy for the stack to figure out. For > INFO >> interaction, everything goes to call control. That works if your >> model > is pure softswitch/feature server, but not many folks are doing that > anymore. > > Assume two applications are interested of the same event, so they both > subscribe to it. Now, how does the SENDER know to which > subscription to > use for a specific application? In 3265, by which application is holding the dialog. With events in an INVITE bounded dialog, we don't have that extra bit of demux, and everything goes through the application holding the INVITE dialog, which then gets to figure out what's going on. -- 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 16 17:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihu2p-0006CE-5c; Tue, 16 Oct 2007 17:33:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihu2n-0006BW-4O for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 17:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihu2m-0006Ad-7y for sip@ietf.org; Tue, 16 Oct 2007 17:33:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihu2k-0006dj-S4 for sip@ietf.org; Tue, 16 Oct 2007 17:33:40 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED54321217; Tue, 16 Oct 2007 23:33:36 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-49-47152e30e70b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D2A25211A2; Tue, 16 Oct 2007 23:33:36 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 23:33:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Tue, 16 Oct 2007 23:33:35 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQOt6Yg7CeOUKnSey8D8xIE0xCigAAEj9g References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Dean Willis" , "Brian Stucker" X-OriginalArrivalTime: 16 Oct 2007 21:33:36.0374 (UTC) FILETIME=[359EC960:01C8103C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip , Francois Audet 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>The trick is demuxing the event streams, or in other words, figuring=20 >>>out the context for each event. INFO currently gives us nothing but=20 >>>the content- modifiers to figure this out. >>>That's not enough, as has widely been argued. >> >>How does 3265 make this any better? >> >>We're talking about identifying a data blob using an event plus a=20 >>content-type instead of a supported plus a content-type for a period=20 >>of time to start and end in conjunction with the INVITE dialog (so the >>subsciption-state header is mooted). >> >> >=20 >3265 makes it better in two ways: >=20 >1) It provides distinct dialogs for each channel of the mux.=20 >Thus, two events of the same class, but related to different=20 >subscriptions, can be distinguished. >=20 >2) It provides semantic distinction, such that two events=20 >that transport the same kind of content but that have=20 >different effects on the application can be distinguished. >=20 >The provide NOTIFY-over-an-INVITE dialog loses advantage 1,=20 >but retains 2. The argument is that this makes it good enough=20 >for some applications. However, there are obviously=20 >applications where it might NOT be good enough, and a=20 >separate dialog ala 3265 would be required. I don't think anyone has proposed to forbid using separate dialogs. And, eventhough the receiver may be able to dispatch the event to the correct application, the sender may still have to send it on each subscription (if it doesn't know which application is associated with each subscription), so the result would be the same as using INFO. But, these are the kind of things we would need to document. What are the issues, limitations etc with different solutions. Then let's the implementors use what they need. >>So a NOTIFY with an event header or an INFO without an event header,=20 >>all other things being the same and the constrained=20 >>semantics of the=20 >>NOTIFY usage being put forward here... >> >>Wouldn't it be equally valid to simply allow the INFO message to carry >>an event header and say that INFO is the same as a NOTIFY with an=20 >>implicit subscription to an INVITE dialog? Isn't this=20 >>pretty much what=20 >>it does already (minus the event header). >> >=20 >There needs to be an explicit declaration of willingness to=20 >receive the semantic load indicated by the event package.=20 >Given that, one could certainly envision revising INFO to do the job. >=20 >>Deep thought: Is all INFO is missing is simply the event header? >=20 >Yes. The problem is that INVITE and 200 (OK) are missing the=20 >"subscribe" header. All we need is draft-subscribe-header-for-invite... :) 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 Tue Oct 16 19:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhvWa-00074C-Ds; Tue, 16 Oct 2007 19:08:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhvWY-0006zJ-Hx for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 19:08:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhvWX-0006yy-Jj for sip@ietf.org; Tue, 16 Oct 2007 19:08:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhvWX-0001pg-8i for sip@ietf.org; Tue, 16 Oct 2007 19:08:29 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188792000"; d="scan'208";a="74171940" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Oct 2007 19:08:20 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9GN8KQA020121; Tue, 16 Oct 2007 19:08:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9GN7fkb015199; Tue, 16 Oct 2007 23:08:08 GMT 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.1830); Tue, 16 Oct 2007 19:08:05 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 19:08:05 -0400 Message-ID: <47154456.4050300@cisco.com> Date: Tue, 16 Oct 2007 19:08:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 23:08:05.0083 (UTC) FILETIME=[686F22B0:01C81049] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.002 X-TM-AS-Result: No--25.349000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1278; t=1192576100; x=1193440100; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=e+8SdPuD41prP5mEeUFxcBFBA5TOrD4RG0+hfr+Hf4Y=; b=NZD6Sc5jnMKp/BN8pZTtZij7udKJ/SEUAqQN6igL+9GKSRrUS4AjCNQNRLMCdKppHkjcE/Dk POvVAX3AMTnjmv7pvAbsu4LqMNe8BJgp2NHKIBrv1k/MF8KroayPoUm2; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > All we need is draft-subscribe-header-for-invite... :) THis of course is predicated on the assumption that the same two parties are the right ones to be involved in the subscription and the invite. This works out ok for DTMF. It remains to be seen where else it is valid. It might seem that it would be valid for the dialog event package. But it might not be if the goal is to get consolidated event state for all UASs of the same AOR. Its far from clear that the subscriber would know. So there probably at least needs to be some way to accept the INVITE but reject the bundled subscription. And in that case the caller needs to move to "plan B". The "bundled subscriptions" need to be negotiated in both directions. That means something like: INVITE must contain: - these are the events I am willing to send - these are the events I desire to receive response must contain: - these are the events I will send (subset from invite) - these are the events you should send (subset from invite) Note that probably excludes events that take various combinations of parameters, and subscriptions that require filters. (Though both of these could probably be required by adding enough complexity.) 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 Tue Oct 16 20:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhwZO-0005N0-2o; Tue, 16 Oct 2007 20:15:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhwZF-000585-8K for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 20:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhwZE-00057Q-4y; Tue, 16 Oct 2007 20:15:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhwZD-0005Y3-1P; Tue, 16 Oct 2007 20:15:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D77A426E90; Wed, 17 Oct 2007 00:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhwYv-0005gq-Oc; Tue, 16 Oct 2007 20:15:01 -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, 16 Oct 2007 20:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-rph-new-namespaces-00.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: , 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 : IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Header Namespaces Author(s) : J. Polk Filename : draft-ietf-sip-rph-new-namespaces-00.txt Pages : 10 Date : 2007-10-16 This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00.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-rph-new-namespaces-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-16191624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rph-new-namespaces-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rph-new-namespaces-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16191624.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 16 20:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhwZX-0005eG-IG; Tue, 16 Oct 2007 20:15:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhwZS-0005XC-7Z for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 20:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhwZR-0005VY-8B; Tue, 16 Oct 2007 20:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhwZQ-0005YP-47; Tue, 16 Oct 2007 20:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 07607329F1; Wed, 17 Oct 2007 00:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhwYv-0005h8-Ss; Tue, 16 Oct 2007 20:15:01 -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, 16 Oct 2007 20:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-08.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: , 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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy, et al. Filename : draft-ietf-sip-connect-reuse-08.txt Pages : 21 Date : 2007-10-16 This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse should be predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. A single connection cannot be reused for the TCP or SCTP transport between two peers, and this document provides insight into why this is the case. As a remedy, it suggests using two TCP connections (or two SCTP associations), each opened pro- actively towards the recipient by the sender. Finally, this document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-08.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-connect-reuse-08.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-connect-reuse-08.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: <2007-10-16194709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16194709.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 16 21:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhxzM-0007vK-29; Tue, 16 Oct 2007 21:46:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhxzK-0007tl-Qa for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 21:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhxzJ-0007tV-Sw for sip@ietf.org; Tue, 16 Oct 2007 21:46:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhxzE-0000h6-F8 for sip@ietf.org; Tue, 16 Oct 2007 21:46:21 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9H1k9g3004608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 20:46:10 -0500 In-Reply-To: <1192172786.17547.19.camel@n85.nomadiclab.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.nortel!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Date: Tue, 16 Oct 2007 20:45:52 -0500 To: Salvatore Loreto X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 12, 2007, at 2:06 AM, Salvatore Loreto wrote: > >> >> INFO, as written, lacks contextual negotiation. You're proposing to >> replace the method name with NOTIFY and use the event-package >> framework for content and context expression, using a header-field in >> the INVITE request to engage context negotiation. It seems to me like >> that would work. There's nothing "implicit" about it, and it is no >> worse for overhead than using Supported or Allow. It also has the >> advantage of letting us reuse an existing registration framework, >> IANA process, and specification review process under RFC 3427. Very >> tidy, I think I like it. > > the proposal is interesting. > However there should be cases where you need to send whatever > information in both directions, or cases where when you send an > information via Notify you need to receive back some information (e.g. > the fact that you receive a 200Ok as answer to the Notify it is not > enough). > How do you think your proposal should work in those cases ? perhaps > with > 2 subscription one in each direction? > Yes, although I prefer to think of it (in this example) as each end having independently declared a willingness to receive events of the given package within the current INVITE-bounded dialog. It might also be reasonable to envision two different event packages, designed to work together. >> >> I would argue that it would be nice to have an extension mechanism >> that allows a UA to be asked "Do you support this specific >> extension?" without the UA having to encode every extension it >> supports in every request it sends, but that's a different issue. > > that is also something nice. Are you thinking a mechanism like an > OPTION > that instead to be general just asks for a specific extension? > Yes, I think that would do the trick. Maybe it's just me, but I find the process of including fully- populated Supported and Allow header fields in every request to be a bit daunting. Not to mention repetitious, bandwidth and CPU consumptive, and so on. Especially if we adopt the SIP-is-an- application-protocol model that requires us to add a new method for every payload type. Note that I have no idea how many UAs actually comply with RFC 3261 on this particular point. SUBSCRIBE gives us something that will do the job. Without preceding contact, we can ask for a subscription to a package, and get an error response if it isn't there. This is a nice property: It keeps us from having to advertise every event package to which we might possibly accept a subscription in every message we send. -- 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 16 21:54:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihy6Q-00046u-FO; Tue, 16 Oct 2007 21:53:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihy6O-00046d-L0 for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 21:53:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihy6N-00046U-Pq for sip@ietf.org; Tue, 16 Oct 2007 21:53:39 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihy6N-0000KR-GL for sip@ietf.org; Tue, 16 Oct 2007 21:53:39 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9H1rcjd021430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 20:53:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 16 Oct 2007 20:53:22 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 71.164.172.176 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4542/Tue Oct 16 15:31:56 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip-implementors@lists.cs.columbia.edu Subject: [Sip] SIPit hotel additional information 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: , Errors-To: sip-bounces@ietf.org (Apologies for the extra list traffic here.) The hosts of SIPit 21 have asked me to remind attendees that the deadline for booking rooms at the event hotel is at the end of this week. If you haven't registered for the event and plan to stay at the BUPT High-Tech Mansion, please send your request for a room reservation to the hosts as soon as possible (see www.sipit21.org/ inform.html for more info). Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 16 22:01:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyCf-00014k-CJ; Tue, 16 Oct 2007 22:00:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhyCb-00011v-LM for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 22:00:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyCa-00011Z-K6 for sip@ietf.org; Tue, 16 Oct 2007 22:00:04 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhyCa-0001xF-9Q for sip@ietf.org; Tue, 16 Oct 2007 22:00:04 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Tue, 16 Oct 2007 22:00:03 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 16 Oct 2007 22:00:03 -0400 From: Hadriel Kaplan To: Dean Willis , Brian Stucker Date: Tue, 16 Oct 2007 21:59:00 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgQOihRkeRFFuwEQB6F8d38b8cw/AAIi4BA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > On Oct 15, 2007, at 1:26 PM, Brian Stucker wrote: > > How does 3265 make this any better? > > > 3265 makes it better in two ways: > > 1) It provides distinct dialogs for each channel of the mux. Thus, > two events of the same class, but related to different subscriptions, > can be distinguished. > > 2) It provides semantic distinction, such that two events that > transport the same kind of content but that have different effects on > the application can be distinguished. > > The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but > retains 2. The argument is that this makes it good enough for some > applications. However, there are obviously applications where it > might NOT be good enough, and a separate dialog ala 3265 would be > required. Actually, I'd argue the converse as well: there are applications where "adv= antage 1" is a disadvantage, or at least potentially confusing. DTMF is a = primary example of this. If two app servers kpml subscribe to my Invite di= alog, I will send them both the dtmf event, assuming the regex works out. = Which one should act on it? They both will. Neither knows about the other= . (although I should note I don't think supporting two kpml subscriptions = is even required by rfc4730, which makes it even less deterministic, and gi= ves up "advantage 1" anyway) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 22:07:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyIC-0005zd-N9; Tue, 16 Oct 2007 22:05:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhyI9-0005rJ-SM for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 22:05:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyI8-0005pK-S9 for sip@ietf.org; Tue, 16 Oct 2007 22:05:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhyI8-0002l5-FZ for sip@ietf.org; Tue, 16 Oct 2007 22:05:48 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9H25iYJ004763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 21:05:46 -0500 In-Reply-To: <47154456.4050300@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 16 Oct 2007 21:05:28 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip , Francois Audet , Brian Stucker , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > The "bundled subscriptions" need to be negotiated in both > directions. That means something like: > > INVITE must contain: > - these are the events I am willing to send > - these are the events I desire to receive Do we need that first line ? Or do we just need "These are the events I'm willing to receive. If I get them, great. If I don't, well, I don't care, I'll assume that sending them wasn't important to you." > > response must contain: > - these are the events I will send (subset from invite) Same here. I don't think the receiver needs to know what events will be sent. They already know that any events that will be sent will be a subset of the events they've said they're ready to handle. > - these are the events you should send (subset from invite) Let's take for example DTMF. If you tell me you can receive DTMF events, I might send you some. If you don't, I won't send you any. If you tell me you can receive DTMF events and I don't send any, do you care whether it's because I don't know how or because I don't have any to send you? Is there a use case for turning this into a full bidirectional offer- answer? If so, it's starting to sound a lot more like an event-media session (described in SDP and negotiated by offer-answer) than what I'm thinking would be appropriate for INVITE-bounded notification. Or maybe its should be a pair of SUBSCRIBE-bounded opposing dialogs. -- 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 16 22:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyZV-0004T3-Mp; Tue, 16 Oct 2007 22:23:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IhyZT-0004Sj-Tz for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 22:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhyZT-0004Q7-1n for sip@ietf.org; Tue, 16 Oct 2007 22:23:43 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhyZJ-0002Pb-Tj for sip@ietf.org; Tue, 16 Oct 2007 22:23:40 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Tue, 16 Oct 2007 22:23:18 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 16 Oct 2007 22:23:18 -0400 From: Hadriel Kaplan To: Dean Willis Date: Tue, 16 Oct 2007 22:22:13 -0400 Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Topic: [Sip] Francois' counter to INFO (was Re: What are we arguing about when we say INFO?) Thread-Index: AcgQYLo6RwufiBQaRzSQWnTMDFJkFgAAMGZQ Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com> <46F7D719.2070004@nostrum.com> <0a5401c8005c$a80fad10$800101df@acmepacket.com> <46FAA68A.1090408@nostrum.com> <0af301c8007c$94d37590$800101df@acmepacket.com> <46FAC69C.4070402@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com> <46FAE230.1070807@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com> <46FBAD3D.3090109@nostrum.com> <46FBBA78.7070903@nostrum.com> <200709271439.l8REd4LE030665@dragon.ariadne.com> <46FBD4C0.30601@nostrum.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.c! orp.nortel!! .com> ! ! ! ! ! < 8F6 5 DB 2 7-41E D-42F 3- 97F5-D550C3E72902@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <1ECE0EB50388174790F9694F77522CCF127005A1@zrc2hxm0.corp.nortel.com> <80A1B08F-B39F-4CE7-8A15-A187D1A73213@softarmor.com> <1192172786.17547.19.camel@n85.nomadiclab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > the proposal is interesting. > > However there should be cases where you need to send whatever > > information in both directions, or cases where when you send an > > information via Notify you need to receive back some information (e.g. > > the fact that you receive a 200Ok as answer to the Notify it is not > > enough). > > How do you think your proposal should work in those cases ? perhaps > > with > > 2 subscription one in each direction? > > > > Yes, although I prefer to think of it (in this example) as each end > having independently declared a willingness to receive events of the > given package within the current INVITE-bounded dialog. > > It might also be reasonable to envision two different event packages, > designed to work together. Yeah, IMHO this shouldn't really be Subscriptions with a capital "S", as in= rfc 3265, with Subscription state and initial Notifies and all. It's real= ly just info-event-package negotiation. > >> > >> I would argue that it would be nice to have an extension mechanism > >> that allows a UA to be asked "Do you support this specific > >> extension?" without the UA having to encode every extension it > >> supports in every request it sends, but that's a different issue. > > > > that is also something nice. Are you thinking a mechanism like an > > OPTION > > that instead to be general just asks for a specific extension? > > > > Yes, I think that would do the trick. > > Maybe it's just me, but I find the process of including fully- > populated Supported and Allow header fields in every request to be a > bit daunting. Not to mention repetitious, bandwidth and CPU > consumptive, and so on. I don't see how OPTIONS helps in reducing any of that. You'd have to send = one for every call. That's more work than a list in a header, no? > SUBSCRIBE gives us something that will do the job. Without preceding > contact, we can ask for a subscription to a package, and get an error > response if it isn't there. And with this new model, you'd not get the info-event-package in responses = for the INVITE, and know the same. Well... you'd know for this INVITE-dial= og the far end does not support info-event foo. It may for other INVITE-di= alogs, but that's arguably more flexible than SUBSCRIBE. > This is a nice property: It keeps us from having to advertise every > event package to which we might possibly accept a subscription in > every message we send. We're only talking about event packages which make sense for INVITE-dialog = piggy-backing. This wouldn't apply to things like presence, reg-event, etc= . Although I'm not sure how that would be documentable, other than definin= g something new and distinct from rfc3265 event packages. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 16 22:46:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihysw-0001j0-00; Tue, 16 Oct 2007 22:43:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ihyst-0001gn-RM for sip-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 22:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihyst-0001gX-4m for sip@ietf.org; Tue, 16 Oct 2007 22:43:47 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihysr-0002qq-Q7 for sip@ietf.org; Tue, 16 Oct 2007 22:43:47 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9H2hPFX036576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Oct 2007 21:43:30 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AD5F0F7-E064-4D29-ABFC-D36AAAF101EB@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 16 Oct 2007 21:43:25 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip-implementors@lists.cs.columbia.edu Subject: [Sip] Registration for SIPit 21 (please register this week) 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: , Errors-To: sip-bounces@ietf.org Hi Folks - While discussing event preparations with the host for SIPit 21 today, I discovered I made a calendar-math error early on. We target having the registration deadline two weeks before the event because there's a _lot_ of preparation the host and I need to do once we know who's going to be there. And as you know, we set the deadline to be Oct 29 which is only _one_ week before the event. The host team is graciously working with me to compensate for the really short prep time that's going to leave us. You can ease that pain alot by registering by Oct 22 (when we _should_ have set the deadline), or sending me email if you're planning to attend but can't register until right up against the 29th deadline. So again, if at all possible, please register for SIPit 21 by next Monday Oct 22. Thanks, and my apologies for the inconvenience. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 17 00:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii0ZP-0000IH-Ri; Wed, 17 Oct 2007 00:31:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii0ZO-0000IB-3t for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 00:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii0ZN-0000I2-Ai for sip@ietf.org; Wed, 17 Oct 2007 00:31:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii0ZH-0005Kk-5i for sip@ietf.org; Wed, 17 Oct 2007 00:31:45 -0400 X-IronPort-AV: E=Sophos;i="4.21,287,1188792000"; d="scan'208";a="74188488" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Oct 2007 00:31:34 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9H4VXlh032673; Wed, 17 Oct 2007 00:31:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9H4VK8X018376; Wed, 17 Oct 2007 04:31:21 GMT 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.1830); Wed, 17 Oct 2007 00:31:20 -0400 Received: from [10.86.240.4] ([10.86.240.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 00:31:20 -0400 Message-ID: <47159016.6040609@cisco.com> Date: Wed, 17 Oct 2007 00:31:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 04:31:20.0207 (UTC) FILETIME=[90D431F0:01C81076] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--25.711100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2340; t=1192595493; x=1193459493; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Dean=20Willis=20; bh=CgWOuslc/UKZI2LzPt1bjx2y/RBdjvekdtDBxUVwDjI=; b=qzOlmAO724ntS0IDPRxVmDIB0stKxt4gMBFDLFSJBiT60x5f922JS2T0tbeg1v4EoTrfkQ+m xDbvYROokFvsavsfHE5TzEay7xYoyNwmwWdBeIOxkZy78mYI4KYxt96o; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip , Francois Audet , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org inline Dean Willis wrote: > > On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > >> The "bundled subscriptions" need to be negotiated in both directions. >> That means something like: >> >> INVITE must contain: >> - these are the events I am willing to send >> - these are the events I desire to receive > > Do we need that first line ? Or do we just need "These are the events > I'm willing to receive. If I get them, great. If I don't, well, I don't > care, I'll assume that sending them wasn't important to you." I think the first line is needed, so that the UAS will know whether it will be getting what it wants this way. It needs to know that so it doesn't fall back to "plan B" - generating an explicit subscription. >> response must contain: >> - these are the events I will send (subset from invite) > > Same here. I don't think the receiver needs to know what events will be > sent. They already know that any events that will be sent will be a > subset of the events they've said they're ready to handle. Same answer here. If I want DTMF, I might prefer to get it this way, but if that doesn't work out I will then probably send an explicit subscription for it. Paul >> - these are the events you should send (subset from invite) > > > Let's take for example DTMF. If you tell me you can receive DTMF events, > I might send you some. If you don't, I won't send you any. If you tell > me you can receive DTMF events and I don't send any, do you care whether > it's because I don't know how or because I don't have any to send you? > > > Is there a use case for turning this into a full bidirectional > offer-answer? If so, it's starting to sound a lot more like an > event-media session (described in SDP and negotiated by offer-answer) > than what I'm thinking would be appropriate for INVITE-bounded > notification. Or maybe its should be a pair of SUBSCRIBE-bounded > opposing dialogs. > > -- > 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 Wed Oct 17 03:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii30N-0001YM-0Q; Wed, 17 Oct 2007 03:07:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii30K-0001W4-CM for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 03:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii306-0001G2-PA for sip@ietf.org; Wed, 17 Oct 2007 03:07:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii2zr-0000gG-OB for sip@ietf.org; Wed, 17 Oct 2007 03:07:27 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0B1555480C6; Wed, 17 Oct 2007 09:06:55 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-99-4715b48ec510 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7D48208E9; Wed, 17 Oct 2007 09:06:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:06:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 09:06:53 +0200 Message-ID: In-Reply-To: <47154456.4050300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQSXQUR/DIFC36RWWxdZFXVH3+IwAQpsiA References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Oct 2007 07:06:54.0688 (UTC) FILETIME=[4C9CF600:01C8108C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>All we need is draft-subscribe-header-for-invite... :) >=20 >THis of course is predicated on the assumption that the same=20 >two parties are the right ones to be involved in the=20 >subscription and the invite.=20 >This works out ok for DTMF. It remains to be seen where else=20 >it is valid. >=20 >It might seem that it would be valid for the dialog event=20 >package. But it might not be if the goal is to get=20 >consolidated event state for all UASs of the same AOR. Its=20 >far from clear that the subscriber would know.=20 >So there probably at least needs to be some way to accept the=20 >INVITE but reject the bundled subscription. And in that case=20 >the caller needs to move to "plan B". >=20 >The "bundled subscriptions" need to be negotiated in both directions.=20 >That means something like: >=20 >INVITE must contain: >- these are the events I am willing to send >- these are the events I desire to receive >=20 >response must contain: >- these are the events I will send (subset from invite) > - these are the events you should send (subset from invite) Maybe we could re-use the SDP direction attributes (sendrecv, sendonly, recvonly) for this? 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 Wed Oct 17 08:48:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8EB-000857-7A; Wed, 17 Oct 2007 08:42:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii8E9-00084Q-2L for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 08:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8E7-00083U-Rj for sip@ietf.org; Wed, 17 Oct 2007 08:42:19 -0400 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 1Ii8E1-00033d-Bd for sip@ietf.org; Wed, 17 Oct 2007 08:42:19 -0400 X-IronPort-AV: E=Sophos;i="4.21,289,1188802800"; d="scan'208";a="24331629" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 17 Oct 2007 05:42:00 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9HCfxYn014153; Wed, 17 Oct 2007 08:41:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9HCfikJ022446; Wed, 17 Oct 2007 12:41:55 GMT 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.1830); Wed, 17 Oct 2007 08:41:44 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 08:41:43 -0400 Message-ID: <47160307.7080408@cisco.com> Date: Wed, 17 Oct 2007 08:41:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 12:41:43.0974 (UTC) FILETIME=[12C2BC60:01C810BB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--23.137500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1530; t=1192624919; x=1193488919; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=pKECJVgHXLzuCk9CgjgOwZbmjGB07DGhwD2PJ8RzF50=; b=PaAT19UupYoWpwR40idRAf1KT2hIJ6bUWlqU775xfjtm+wvXW4IAQ0Ibs45ZKfWvWkheMZQp AYKoWvuWgJh29yV4i1kM+JEsLRPlNtOhr95KJEF4FE/M4h3lsZH4LM3k; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>> All we need is draft-subscribe-header-for-invite... :) >> THis of course is predicated on the assumption that the same >> two parties are the right ones to be involved in the >> subscription and the invite. >> This works out ok for DTMF. It remains to be seen where else >> it is valid. >> >> It might seem that it would be valid for the dialog event >> package. But it might not be if the goal is to get >> consolidated event state for all UASs of the same AOR. Its >> far from clear that the subscriber would know. >> So there probably at least needs to be some way to accept the >> INVITE but reject the bundled subscription. And in that case >> the caller needs to move to "plan B". >> >> The "bundled subscriptions" need to be negotiated in both directions. >> That means something like: >> >> INVITE must contain: >> - these are the events I am willing to send >> - these are the events I desire to receive >> >> response must contain: >> - these are the events I will send (subset from invite) >> - these are the events you should send (subset from invite) > > Maybe we could re-use the SDP direction attributes (sendrecv, sendonly, > recvonly) for this? Are you serious? Or have you been smoking something? :-) Certainly you can use the SDP direction attributes if you want to establish media sessions for this event signaling. But AFAIK the point here is to negotiate the use of signaling in the sip session itself. 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 17 08:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8Lv-0003Ic-8u; Wed, 17 Oct 2007 08:50:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii8Lt-0003I4-Es for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 08:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8Ls-0003GA-5Z for sip@ietf.org; Wed, 17 Oct 2007 08:50:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii8Ll-0003Hc-CR for sip@ietf.org; Wed, 17 Oct 2007 08:50:19 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D0DAC2010B; Wed, 17 Oct 2007 14:50:02 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-c5-471604faef2d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B08922015B; Wed, 17 Oct 2007 14:50:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 14:50:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 14:50:01 +0200 Message-ID: In-Reply-To: <47160307.7080408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQu5HiV1T05sKLSy+Dbq0nvsdKUQAAB+VQ References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47160307.7080408@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Oct 2007 12:50:02.0537 (UTC) FILETIME=[3BED6990:01C810BC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>The "bundled subscriptions" need to be negotiated in both directions. >>>That means something like: >>> >>> INVITE must contain: >>> - these are the events I am willing to send >>> - these are the events I desire to receive >>> >>> response must contain: >>> - these are the events I will send (subset from invite) >>> - these are the events you should send (subset from invite) >>=20 >> Maybe we could re-use the SDP direction attributes (sendrecv,=20 >> sendonly, >> recvonly) for this? >=20 >Are you serious? Or have you been smoking something? :-) Sometimes I think that would help in these discussions :) >Certainly you can use the SDP direction attributes if you=20 >want to establish media sessions for this event signaling.=20 >But AFAIK the point here is to negotiate the use of signaling=20 >in the sip session itself. I guess I should have been more clear. I didn't mean that we start using SDP for this, but that we could use something SIMILAR to the direction attributes - but in the form of some SIP header parameters. 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 Wed Oct 17 09:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8m7-0005MW-VW; Wed, 17 Oct 2007 09:17:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii8m3-00059x-Nl for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 09:17:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8m1-00056N-UE for sip@ietf.org; Wed, 17 Oct 2007 09:17:21 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8m1-0004oE-CX for sip@ietf.org; Wed, 17 Oct 2007 09:17:21 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l9HDGFNw021140; Wed, 17 Oct 2007 15:16:17 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Oct 2007 15:17:17 +0200 Message-ID: <47160B59.8000806@alcatel-lucent.fr> Date: Wed, 17 Oct 2007 15:17:13 +0200 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Dean Willis , IETF SIP List Subject: Re: [Sip] RR-fix: open issue on transport protocol parameter References: <46FCF307.30402@alcatel-lucent.fr> <2396C577-3C8D-4CC6-A481-9EB7205F0B95@nostrum.com> <31E44296-C279-4D4C-8FF1-1F101FD64255@softarmor.com> In-Reply-To: <31E44296-C279-4D4C-8FF1-1F101FD64255@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 13:17:17.0808 (UTC) FILETIME=[0A9FF700:01C810C0] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: sip-bounces@ietf.org Ok, I will try to make it in version -01, any other comment on the draft? ... any volunteer reviewer(s)? Thomas Dean Willis wrote: > > On Oct 1, 2007, at 1:51 PM, Robert Sparks wrote: > >> Actually, I don't think either of these proposals is the solution for >> this particular issue. >> >> Jiri hit it on the head - the problem with the scenario you describe >> was at P2 - it _really_ >> needed to record-route. >> >> There's already some text in 3261 that pushes in this direction and >> probably what we want >> to do is just make that more clear in this document. The essence is >> that if you are a proxy >> and you change the transport characteristics as you forward a >> message, you need to record-route. > > And not only that, the proxy either needs to double-record or do a > reverse patch-up on responses. > > -- > 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 17 09:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8sc-00079R-Ok; Wed, 17 Oct 2007 09:24:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii8sb-00078f-Hz for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 09:24:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8sa-00077i-Lp for sip@ietf.org; Wed, 17 Oct 2007 09:24:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8sa-000578-6Z for sip@ietf.org; Wed, 17 Oct 2007 09:24:08 -0400 X-IronPort-AV: E=Sophos;i="4.21,289,1188802800"; d="scan'208";a="238509116" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2007 06:24:06 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9HDO6XN018537; Wed, 17 Oct 2007 09:24:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9HDNV8x010949; Wed, 17 Oct 2007 13:23:58 GMT 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.1830); Wed, 17 Oct 2007 09:23:54 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 09:23:53 -0400 Message-ID: <47160CE9.4050705@cisco.com> Date: Wed, 17 Oct 2007 09:23:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47160307.7080408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 13:23:53.0864 (UTC) FILETIME=[F6B15080:01C810C0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--13.044900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1635; t=1192627446; x=1193491446; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=jg2Y8yfbliKhEWS3mIQ5w31v1HaxgyosraUSocyj7II=; b=qr5jU9+vOhNLrfuw2xqiuTqJYwnW0x/S0DHR2Adj46T/HYNe+UfAu0xafBHljebepxUw2GIj Wy8UHOK40ON4Fs3h0hbOpe0Z53FW57CwwmUZ+cpYsBSQ3ysOYqslNYfk; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>>> The "bundled subscriptions" need to be negotiated in both directions. > >>>> That means something like: >>>> >>>> INVITE must contain: >>>> - these are the events I am willing to send >>>> - these are the events I desire to receive >>>> >>>> response must contain: >>>> - these are the events I will send (subset from invite) >>>> - these are the events you should send (subset from invite) >>> Maybe we could re-use the SDP direction attributes (sendrecv, >>> sendonly, >>> recvonly) for this? >> Are you serious? Or have you been smoking something? :-) > > Sometimes I think that would help in these discussions :) > >> Certainly you can use the SDP direction attributes if you >> want to establish media sessions for this event signaling. >> But AFAIK the point here is to negotiate the use of signaling >> in the sip session itself. > > I guess I should have been more clear. I didn't mean that we start using > SDP for this, but that we could use something SIMILAR to the direction > attributes - but in the form of some SIP header parameters. Oh - thats not quite so crazy. Yes, I suppose something like that could be done. But given how much confusion that seems to have caused with SDP, I would certainly think twice before using it again. Note that this will need to be more than a one-time negotiation. Its possible that the agreement will need to be renegotiated in mid-call. (This comes up at least in 3pcc scenarios, where a device in the middle is performing a transfer without the knowledge of the other side.) 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 17 09:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii99p-0003zS-Cn; Wed, 17 Oct 2007 09:41:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii99m-0003re-Vt for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 09:41:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii99l-0003fW-H4 for sip@ietf.org; Wed, 17 Oct 2007 09:41:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii99f-0005gb-RJ for sip@ietf.org; Wed, 17 Oct 2007 09:41:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C51920851; Wed, 17 Oct 2007 15:41:47 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-90-4716111b9761 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 11A3B2083F; Wed, 17 Oct 2007 15:41:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 15:41:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 15:41:44 +0200 Message-ID: In-Reply-To: <47160CE9.4050705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQwQK7ClSVe9AMRdW4e7m1CingzgAAE4MQ References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47160307.7080408@cisco.com> <47160CE9.4050705@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Oct 2007 13:41:46.0729 (UTC) FILETIME=[762B8590:01C810C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip , Francois Audet , Brian Stucker , 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>>>The "bundled subscriptions" need to be negotiated in both directions. >>>>>=20 >>>>> That means something like: >>>>> >>>>> INVITE must contain: >>>>> - these are the events I am willing to send >>>>> - these are the events I desire to receive >>>>> >>>>> response must contain: >>>>> - these are the events I will send (subset from invite) >>>>> - these are the events you should send (subset from invite) >>>> Maybe we could re-use the SDP direction attributes (sendrecv,=20 >>>> sendonly, recvonly) for this? >>> Are you serious? Or have you been smoking something? :-) >>=20 >> Sometimes I think that would help in these discussions :) >>=20 >>>Certainly you can use the SDP direction attributes if you want to=20 >>>establish media sessions for this event signaling. >>>But AFAIK the point here is to negotiate the use of signaling in the=20 >>>sip session itself. >>=20 >>I guess I should have been more clear. I didn't mean that we start=20 >>using SDP for this, but that we could use something SIMILAR to the=20 >>direction attributes - but in the form of some SIP header=20 >>parameters. >=20 >Oh - thats not quite so crazy. >=20 >Yes, I suppose something like that could be done. But given=20 >how much confusion that seems to have caused with SDP, I=20 >would certainly think twice before using it again. >=20 >Note that this will need to be more than a one-time=20 >negotiation. Its possible that the agreement will need to be=20 >renegotiated in mid-call.=20 >(This comes up at least in 3pcc scenarios, where a device in=20 >the middle is performing a transfer without the knowledge of=20 >the other side.) I agree. I guess there could also be needs to add/remove "event subscriptions" (or whatever we would call it) during the call, so... 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 Wed Oct 17 09:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9Bx-0007GE-Db; Wed, 17 Oct 2007 09:44:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ii9Bv-0007F7-Lb for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 09:44:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9Bu-0007CX-KZ for sip@ietf.org; Wed, 17 Oct 2007 09:44:06 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii9Bu-0005mS-5N for sip@ietf.org; Wed, 17 Oct 2007 09:44:06 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 09:43:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 09:43:55 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F01875F85@MAIL02.cedarpointcom.com> In-Reply-To: <47160CE9.4050705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgQwXlOX5G9IzzdRZm7oNC/2CJEVAAALchA References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com><47160307.7080408@cisco.com> <47160CE9.4050705@cisco.com> From: "Sumit Garg" To: "Paul Kyzivat" , "Christer Holmberg" X-OriginalArrivalTime: 17 Oct 2007 13:43:57.0671 (UTC) FILETIME=[C437AF70:01C810C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip , Francois Audet , Dean Willis , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Another approach to avoid unnecessarily long bodies: (this would be more on lines of offer-answer) INVITE- these are events A desires to receive. 1st reliable response (provisional/200OK) from B: - this is the subset of events (from the offer from A) which can be provided by B. - this is the set of events B desires from A. ACK/PRACK: - this is the subset of events (from the offer from B) which can be provided by A. Wouldn't the best approach be to supersede the INFO RFC with one which takes care of issues, i.e. with these additional headers. We can't get people to change the old implementations, but at least the for new usages if the additional work required is a smaller delta (from base INFO, as compared to having to implement SUBSCRIBE/NOTIFY), they might be more amenable to use the new EVENT based INFO mechanism. -Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, October 17, 2007 9:24 AM To: Christer Holmberg Cc: sip; Francois Audet; Brian Stucker; Dean Willis Subject: Re: [Sip] INFO Christer Holmberg wrote: > Hi, >=20 >>>> The "bundled subscriptions" need to be negotiated in both directions. >=20 >>>> That means something like: >>>> >>>> INVITE must contain: >>>> - these are the events I am willing to send >>>> - these are the events I desire to receive >>>> >>>> response must contain: >>>> - these are the events I will send (subset from invite) >>>> - these are the events you should send (subset from invite) >>> Maybe we could re-use the SDP direction attributes (sendrecv,=20 >>> sendonly, >>> recvonly) for this? >> Are you serious? Or have you been smoking something? :-) >=20 > Sometimes I think that would help in these discussions :) >=20 >> Certainly you can use the SDP direction attributes if you want to=20 >> establish media sessions for this event signaling. >> But AFAIK the point here is to negotiate the use of signaling in the=20 >> sip session itself. >=20 > I guess I should have been more clear. I didn't mean that we start=20 > using SDP for this, but that we could use something SIMILAR to the=20 > direction attributes - but in the form of some SIP header parameters. Oh - thats not quite so crazy. Yes, I suppose something like that could be done. But given how much confusion that seems to have caused with SDP, I would certainly think twice before using it again. Note that this will need to be more than a one-time negotiation. Its possible that the agreement will need to be renegotiated in mid-call.=20 (This comes up at least in 3pcc scenarios, where a device in the middle is performing a transfer without the knowledge of the other side.) 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 Wed Oct 17 10:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA4A-0004tW-BA; Wed, 17 Oct 2007 10:40:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiA49-0004sb-1n for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 10:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiA48-0004sD-45 for sip@ietf.org; Wed, 17 Oct 2007 10:40:08 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiA3z-00075h-Vb for sip@ietf.org; Wed, 17 Oct 2007 10:40:06 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Wed, 17 Oct 2007 10:39:42 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 17 Oct 2007 10:39:42 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Wed, 17 Oct 2007 10:39:39 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgQYnzu1vCr0qi1TsmA2S68GWD2TAAAnxaA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip , Francois Audet , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, October 16, 2007 10:05 PM > To: Paul Kyzivat > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > Subject: Re: [Sip] INFO > > > On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > > > The "bundled subscriptions" need to be negotiated in both > > directions. That means something like: > > > > INVITE must contain: > > - these are the events I am willing to send > > - these are the events I desire to receive > > Do we need that first line ? Or do we just need "These are the events > I'm willing to receive. If I get them, great. If I don't, well, I > don't care, I'll assume that sending them wasn't important to you." But that's not always the case with dtmf. If a softphone makes a call, wou= ld the softphone always care to receive DTMF? Not all of them would. But = they would want to tell the far-end they can _send_ DTMF. Not that I think= this means we need a send/receive distinction - I think just a "I support = dtmf-info" semantic is good enough for dtmf. > Is there a use case for turning this into a full bidirectional offer- > answer? I guess the question is if it matters that a UA which can only send event f= oo but can't do anything useful receiving foo, could be sent foo anyway. F= or example, suppose we created an event-package for a jpeg picture, for rem= ote-party call display. If a hard-phone has no LCD to display a picture, b= ut has a stored jpeg to give to the far-end, would it matter if it can't sa= y "I can send a jpeg but don't want to receive one"? Obviously it could ju= st accept a received one (ie, 200 ok the INFO) and discard the jpeg. But i= s that the right thing to do? I dunno. We could just leave the concept up= to specific info-event-package definitions to handle - i.e., make an event= -package define send vs. receive event-packages pairs if it cares about it. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 11:23:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiAfh-000284-3R; Wed, 17 Oct 2007 11:18:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiAff-00022S-Dh for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 11:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiAfe-00021d-Pn for sip@ietf.org; Wed, 17 Oct 2007 11:18:54 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiAfY-0008Ex-LC for sip@ietf.org; Wed, 17 Oct 2007 11:18:54 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l9HFFmF27384; Wed, 17 Oct 2007 15:15:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 10:18:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1291D63C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgQYnzu1vCr0qi1TsmA2S68GWD2TAAAnxaAABr2fHA= References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Dean Willis" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org I think the recv/send/sendrecv approach that Christer was proposing addresses this.=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, October 17, 2007 07:40 > To: Dean Willis; Paul Kyzivat > Cc: sip; Audet, Francois (SC100:3055); Stucker, Brian=20 > (RICH1:AR00); Christer Holmberg > Subject: RE: [Sip] INFO >=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, October 16, 2007 10:05 PM > > To: Paul Kyzivat > > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > > Subject: Re: [Sip] INFO > > > > > > On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > > > > > The "bundled subscriptions" need to be negotiated in both=20 > > > directions. That means something like: > > > > > > INVITE must contain: > > > - these are the events I am willing to send > > > - these are the events I desire to receive > > > > Do we need that first line ? Or do we just need "These are=20 > the events=20 > > I'm willing to receive. If I get them, great. If I don't, well, I=20 > > don't care, I'll assume that sending them wasn't important to you." >=20 > But that's not always the case with dtmf. If a softphone=20 > makes a call, would the softphone always care to receive=20 > DTMF? Not all of them would. But they would want to tell=20 > the far-end they can _send_ DTMF. Not that I think this=20 > means we need a send/receive distinction - I think just a "I=20 > support dtmf-info" semantic is good enough for dtmf. >=20 >=20 > > Is there a use case for turning this into a full=20 > bidirectional offer-=20 > > answer? >=20 > I guess the question is if it matters that a UA which can=20 > only send event foo but can't do anything useful receiving=20 > foo, could be sent foo anyway. For example, suppose we=20 > created an event-package for a jpeg picture, for remote-party=20 > call display. If a hard-phone has no LCD to display a=20 > picture, but has a stored jpeg to give to the far-end, would=20 > it matter if it can't say "I can send a jpeg but don't want=20 > to receive one"? Obviously it could just accept a received=20 > one (ie, 200 ok the INFO) and discard the jpeg. But is that=20 > the right thing to do? I dunno. We could just leave the=20 > concept up to specific info-event-package definitions to=20 > handle - i.e., make an event-package define send vs. receive=20 > event-packages pairs if it cares about it. >=20 > -hadriel >=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 Wed Oct 17 12:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiBb9-0007Ey-M1; Wed, 17 Oct 2007 12:18:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiBb7-0007EN-Mf for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 12:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiBb6-0007Bq-Da for sip@ietf.org; Wed, 17 Oct 2007 12:18:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiBb0-0001nT-5L for sip@ietf.org; Wed, 17 Oct 2007 12:18:16 -0400 X-IronPort-AV: E=Sophos;i="4.21,290,1188792000"; d="scan'208";a="74222181" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Oct 2007 12:17:47 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9HGHkU2026350; Wed, 17 Oct 2007 12:17:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9HGHdk9021791; Wed, 17 Oct 2007 16:17:39 GMT 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.1830); Wed, 17 Oct 2007 12:17:31 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 12:17:31 -0400 Message-ID: <47163591.8040007@cisco.com> Date: Wed, 17 Oct 2007 12:17:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sumit Garg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com><47160307.7080408@cisco.com> <47160CE9.4050705@cisco.com> <59184B4E920E854DA8ACF8E44917D49F01875F85@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F01875F85@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 16:17:31.0154 (UTC) FILETIME=[37E19F20:01C810D9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--13.199400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3842; t=1192637866; x=1193501866; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Sumit=20Garg=20; bh=RZkBzHF0SV4ztsGc9HWKLBzsgrXidGYiYoANNFrVPBc=; b=TYDSgfz9y0OHc0MWXvQWlrlnGLA2Mdq4YNhiBCBCSOQ68yA23KCWpmsipP7zaytKKFiwGIHh uEr9AOZBAXtahSrgn2ONmJNIm7/RbUJ0SgAYQX3rWr38Ht9ACABCTdIT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip , Francois Audet , Brian Stucker , Dean Willis , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Sumit Garg wrote: > Another approach to avoid unnecessarily long bodies: (this would be more > on lines of offer-answer) > INVITE- these are events A desires to receive. > > 1st reliable response (provisional/200OK) from B: > - this is the subset of events (from the offer from A) which can > be provided by B. > - this is the set of events B desires from A. > > ACK/PRACK: > - this is the subset of events (from the offer from B) which can > be provided by A. That would work. I find it slightly more attractive than the sendrecv/sendonly/recvonly/inactive approach, though both are roughly equivalent in power. > Wouldn't the best approach be to supersede the INFO RFC with one which > takes care of issues, i.e. with these additional headers. > We can't get people to change the old implementations, but at least the > for new usages if the additional work required is a smaller delta (from > base INFO, as compared to having to implement SUBSCRIBE/NOTIFY), they > might be more amenable to use the new EVENT based INFO mechanism. Frankly, I think what we are discussing would be better applied using NOTIFY in the INVITE dialog. We would then be devising a new means to negotiate event packages that will share the invite dialog, but using the same NOTIFY messages to carry the data, not INFO. Paul > -Sumit > > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all progress > depends on the unreasonable man." > -- George Bernard Shaw > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, October 17, 2007 9:24 AM > To: Christer Holmberg > Cc: sip; Francois Audet; Brian Stucker; Dean Willis > Subject: Re: [Sip] INFO > > > > Christer Holmberg wrote: >> Hi, >> >>>>> The "bundled subscriptions" need to be negotiated in both > directions. >>>>> That means something like: >>>>> >>>>> INVITE must contain: >>>>> - these are the events I am willing to send >>>>> - these are the events I desire to receive >>>>> >>>>> response must contain: >>>>> - these are the events I will send (subset from invite) >>>>> - these are the events you should send (subset from invite) >>>> Maybe we could re-use the SDP direction attributes (sendrecv, >>>> sendonly, >>>> recvonly) for this? >>> Are you serious? Or have you been smoking something? :-) >> Sometimes I think that would help in these discussions :) >> >>> Certainly you can use the SDP direction attributes if you want to >>> establish media sessions for this event signaling. >>> But AFAIK the point here is to negotiate the use of signaling in the >>> sip session itself. >> I guess I should have been more clear. I didn't mean that we start >> using SDP for this, but that we could use something SIMILAR to the >> direction attributes - but in the form of some SIP header parameters. > > Oh - thats not quite so crazy. > > Yes, I suppose something like that could be done. But given how much > confusion that seems to have caused with SDP, I would certainly think > twice before using it again. > > Note that this will need to be more than a one-time negotiation. Its > possible that the agreement will need to be renegotiated in mid-call. > (This comes up at least in 3pcc scenarios, where a device in the middle > is performing a transfer without the knowledge of the other side.) > > 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 Wed Oct 17 12:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiC7h-0003KK-Qy; Wed, 17 Oct 2007 12:51:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiC7f-0003Hf-C3 for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 12:51:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiC7e-0003GX-GJ for sip@ietf.org; Wed, 17 Oct 2007 12:51:54 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiC7Z-0002SQ-0x for sip@ietf.org; Wed, 17 Oct 2007 12:51:49 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Wed, 17 Oct 2007 12:51:48 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 17 Oct 2007 12:51:48 -0400 From: Hadriel Kaplan To: Francois Audet , Dean Willis , Paul Kyzivat Date: Wed, 17 Oct 2007 12:51:47 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgQYnzu1vCr0qi1TsmA2S68GWD2TAAAnxaAABr2fHAAAznPUA== Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <1ECE0EB50388174790F9694F77522CCF1291D63C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1291D63C@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Yes, but Dean is asking if we even need the concept of a recv/send/sendrecv= . You would need to specify recv/send/sendrecv for each info-event-package= . The question is: is it necessary for a general info-event-package negotiati= on mechanism? -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, October 17, 2007 11:18 AM > To: Hadriel Kaplan; Dean Willis; Paul Kyzivat > Cc: sip; Brian Stucker; Christer Holmberg > Subject: RE: [Sip] INFO > > I think the recv/send/sendrecv approach that Christer was proposing > addresses this. > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Wednesday, October 17, 2007 07:40 > > To: Dean Willis; Paul Kyzivat > > Cc: sip; Audet, Francois (SC100:3055); Stucker, Brian > > (RICH1:AR00); Christer Holmberg > > Subject: RE: [Sip] INFO > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, October 16, 2007 10:05 PM > > > To: Paul Kyzivat > > > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > > > Subject: Re: [Sip] INFO > > > > > > > > > On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote: > > > > > > > The "bundled subscriptions" need to be negotiated in both > > > > directions. That means something like: > > > > > > > > INVITE must contain: > > > > - these are the events I am willing to send > > > > - these are the events I desire to receive > > > > > > Do we need that first line ? Or do we just need "These are > > the events > > > I'm willing to receive. If I get them, great. If I don't, well, I > > > don't care, I'll assume that sending them wasn't important to you." > > > > But that's not always the case with dtmf. If a softphone > > makes a call, would the softphone always care to receive > > DTMF? Not all of them would. But they would want to tell > > the far-end they can _send_ DTMF. Not that I think this > > means we need a send/receive distinction - I think just a "I > > support dtmf-info" semantic is good enough for dtmf. > > > > > > > Is there a use case for turning this into a full > > bidirectional offer- > > > answer? > > > > I guess the question is if it matters that a UA which can > > only send event foo but can't do anything useful receiving > > foo, could be sent foo anyway. For example, suppose we > > created an event-package for a jpeg picture, for remote-party > > call display. If a hard-phone has no LCD to display a > > picture, but has a stored jpeg to give to the far-end, would > > it matter if it can't say "I can send a jpeg but don't want > > to receive one"? Obviously it could just accept a received > > one (ie, 200 ok the INFO) and discard the jpeg. But is that > > the right thing to do? I dunno. We could just leave the > > concept up to specific info-event-package definitions to > > handle - i.e., make an event-package define send vs. receive > > event-packages pairs if it cares about it. > > > > -hadriel > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 12:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiC5X-0000tR-GD; Wed, 17 Oct 2007 12:49:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiC5V-0000sR-22 for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 12:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiC5U-0000pW-3U for sip@ietf.org; Wed, 17 Oct 2007 12:49:40 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiC5N-0002e8-Oh for sip@ietf.org; Wed, 17 Oct 2007 12:49:40 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQ200L0LEPKZG@siemenscomms.co.uk> for sip@ietf.org; Wed, 17 Oct 2007 17:48:56 +0100 (BST) Date: Wed, 17 Oct 2007 17:49:16 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: <47163591.8040007@cisco.com> To: Paul Kyzivat , Sumit Garg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D05A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgQ2oLsi/c3Tks0Tou2i66AtkMIygAAuLbA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47160307.7080408@cisco.com> <47160CE9.4050705@cisco.com> <59184B4E920E854DA8ACF8E44917D49F01875F85@MAIL02.cedarpointcom.com> <47163591.8040007@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: sip , Francois Audet , Dean Willis , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17 October 2007 17:17 > To: Sumit Garg > Cc: sip; Francois Audet; Brian Stucker; Dean Willis; Christer Holmberg > Subject: Re: [Sip] INFO > > > > Sumit Garg wrote: > > Another approach to avoid unnecessarily long bodies: (this > would be more > > on lines of offer-answer) > > INVITE- these are events A desires to receive. > > > > 1st reliable response (provisional/200OK) from B: > > - this is the subset of events (from the offer from > A) which can > > be provided by B. > > - this is the set of events B desires from A. > > > > ACK/PRACK: > > - this is the subset of events (from the offer from > B) which can > > be provided by A. > > That would work. I find it slightly more attractive than the > sendrecv/sendonly/recvonly/inactive approach, though both are roughly > equivalent in power. [JRE] A down side is that for mid-dialog changes it requires re-INVITE, rather than UPDATE. John > > > Wouldn't the best approach be to supersede the INFO RFC > with one which > > takes care of issues, i.e. with these additional headers. > > We can't get people to change the old implementations, but > at least the > > for new usages if the additional work required is a smaller > delta (from > > base INFO, as compared to having to implement > SUBSCRIBE/NOTIFY), they > > might be more amenable to use the new EVENT based INFO mechanism. > > Frankly, I think what we are discussing would be better applied using > NOTIFY in the INVITE dialog. We would then be devising a new means to > negotiate event packages that will share the invite dialog, but using > the same NOTIFY messages to carry the data, not INFO. > > Paul > > > -Sumit > > > > "The reasonable man adapts himself to the world; the > unreasonable one > > persists in trying to adapt the world to himself. Therefore > all progress > > depends on the unreasonable man." > > -- George Bernard Shaw > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, October 17, 2007 9:24 AM > > To: Christer Holmberg > > Cc: sip; Francois Audet; Brian Stucker; Dean Willis > > Subject: Re: [Sip] INFO > > > > > > > > Christer Holmberg wrote: > >> Hi, > >> > >>>>> The "bundled subscriptions" need to be negotiated in both > > directions. > >>>>> That means something like: > >>>>> > >>>>> INVITE must contain: > >>>>> - these are the events I am willing to send > >>>>> - these are the events I desire to receive > >>>>> > >>>>> response must contain: > >>>>> - these are the events I will send (subset from invite) > >>>>> - these are the events you should send (subset from invite) > >>>> Maybe we could re-use the SDP direction attributes (sendrecv, > >>>> sendonly, > >>>> recvonly) for this? > >>> Are you serious? Or have you been smoking something? :-) > >> Sometimes I think that would help in these discussions :) > >> > >>> Certainly you can use the SDP direction attributes if you want to > >>> establish media sessions for this event signaling. > >>> But AFAIK the point here is to negotiate the use of > signaling in the > >>> sip session itself. > >> I guess I should have been more clear. I didn't mean that we start > >> using SDP for this, but that we could use something SIMILAR to the > >> direction attributes - but in the form of some SIP header > parameters. > > > > Oh - thats not quite so crazy. > > > > Yes, I suppose something like that could be done. But given how much > > confusion that seems to have caused with SDP, I would > certainly think > > twice before using it again. > > > > Note that this will need to be more than a one-time negotiation. Its > > possible that the agreement will need to be renegotiated in > mid-call. > > (This comes up at least in 3pcc scenarios, where a device > in the middle > > is performing a transfer without the knowledge of the other side.) > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 12:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiCDR-0000BM-JD; Wed, 17 Oct 2007 12:57:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiCDQ-0000BH-Cl for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 12:57:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiCDP-0000B2-JC for sip@ietf.org; Wed, 17 Oct 2007 12:57:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiCDO-0002dk-S8 for sip@ietf.org; Wed, 17 Oct 2007 12:57:51 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9HGvcUA007700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Oct 2007 11:57:41 -0500 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Wed, 17 Oct 2007 11:57:36 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip , Paul Kyzivat , Christer Holmberg , Francois Audet , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On Oct 17, 2007, at 9:39 AM, Hadriel Kaplan wrote: >>> >>> INVITE must contain: >>> - these are the events I am willing to send >>> - these are the events I desire to receive >> >> Do we need that first line ? Or do we just need "These are the events >> I'm willing to receive. If I get them, great. If I don't, well, I >> don't care, I'll assume that sending them wasn't important to you." > > But that's not always the case with dtmf. If a softphone makes a > call, would the softphone always care to receive DTMF? Not all of > them would. But they would want to tell the far-end they can > _send_ DTMF. Not that I think this means we need a send/receive > distinction - I think just a "I support dtmf-info" semantic is good > enough for dtmf. I think we need two different approaches here. There is a big difference between "I could deal with X should you want to send it" and "I NEED you to send me X" or "I want to know if you intend to send me X". The first is a simple declarative, along the lines of what we do with Supported and Allow. The latter two are more directive, something like what we do with a Require. Otherwise said, there's a difference between "I support" and "I will use" or "Will you use?". > >> Is there a use case for turning this into a full bidirectional offer- >> answer? > > I guess the question is if it matters that a UA which can only send > event foo but can't do anything useful receiving foo, could be sent > foo anyway. For example, suppose we created an event-package for a > jpeg picture, for remote-party call display. If a hard-phone has > no LCD to display a picture, but has a stored jpeg to give to the > far-end, would it matter if it can't say "I can send a jpeg but > don't want to receive one"? Obviously it could just accept a > received one (ie, 200 ok the INFO) and discard the jpeg. But is > that the right thing to do? I dunno. We could just leave the > concept up to specific info-event-package definitions to handle - > i.e., make an event-package define send vs. receive event-packages > pairs if it cares about it. I suspect that things that need two way send-receive negotiation need to use full subscriptions. Actually, they may need to use full subscriptions in each direction. But let's play with this negotiation a minute. Suppose instead of having a single header field for "all the events- in-invite-dialogs we know about", we have two header fields: one for events we are willing to receive, and another for events we are offering to send. Those two sets might not match for a given device, but they would need to reduce down to pairwise matches after the offer-answer phase, so that neither end would be intending to send something the other hadn't indicated a willingness to receive. So, for example. Alice might INVITE Gateway, saying "I understand keymap and image-display events and may send you keypad events", and gateway might answer in the 200 OK "I understand keypad events and may send you keymap events" (note that gateway is NOT offering to send image-display events) . Alice might then echo (in ACK) "We agree that I may send you keypad events and that you may send me keymap events". Or, as you suggested, we could define directional event packages and use a single header field. Alice might INVITE Gateway, saying "I'm offering to use send-keypad and receive-keymap and receive-image-display events". Gateway responds with "I will support receive-keypad and send-keymap events" (note it didn't include send-image-display). Alice then ACKS with "I understand I will be doing send-keypad and receive-keymap". The two are functionally equivalent, I think we just have a syntax question. I suspect that the two-header approach is easier to parse. But a broader question is lurking here . . . How is this not just an example of a more general feature or capability negotiation mechanism? If instead of "event packages" we talk about "features", where a feature might be "send event X", "receive event X", or perhaps something broader like "transition to a DOOM game"? Could we use it to discover a peers screen resolution, keyboard layout, or access network bandwidth? Could we do the same media-channel O/A that we do in SDP? I believe the answer is "yes", but it requires a registry process for each of the "features", much as we currently have a registry process for event packages. Do we want to go in this direction? If not, where do we draw the line? And just exactly how does this relate to RFC 3840/3841 preferences and capabilities negotiation (which, I might add, don't really work in a proxyless world). -- 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 17 13:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiCst-00082A-Pg; Wed, 17 Oct 2007 13:40:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiCsr-00080D-CP for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 13:40:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiCsq-0007yr-4F for sip@ietf.org; Wed, 17 Oct 2007 13:40:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiCsp-0004PV-4L for sip@ietf.org; Wed, 17 Oct 2007 13:40:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,290,1188802800"; d="scan'208";a="536563196" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2007 10:40:36 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9HHeacs027083; Wed, 17 Oct 2007 10:40:36 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9HHeEsv017958; Wed, 17 Oct 2007 17:40:32 GMT 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.1830); Wed, 17 Oct 2007 13:40:31 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 13:40:30 -0400 Message-ID: <47164904.8020100@cisco.com> Date: Wed, 17 Oct 2007 13:40:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 17:40:30.0865 (UTC) FILETIME=[D0053810:01C810E4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--22.096800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5676; t=1192642836; x=1193506836; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=yOGlQbcsgpu/RKUOC4OR8oDivWU1JZPbpZktkWXKlQg=; b=cMJZat9t6g6Dzozz+pFdRSQnm5FgCdkX+B888gLbhvJ/XRexdV6mdoyDkKDl/bE0rGtTTtTP BVsfNvkItq9R5ilW32I2HDNLE6y8bZanV52I6hXiuNmg77r2jgqxps7y; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip , Francois Audet , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org We don't need all these nuances - just a few. It isn't important to say "I could deal with X if you sent it but I don't want you to send it." There are two paradigms already used in sip, and discussed here, and either could be used: 1) X tells Y: I would like you to send A,B,C Y tells X: I will send you B,C; I would like you to send B,C,D,E X tells Y: Please send B,E 2) X tells Y: I can send A,B,C; want to receive B,C,D,E Y tells X: I will send you B,C; Please send me B,E The use of the directionality attributes is an encoding of (2): 2b) X tells Y: sendonly(A), sendrecv(B,C), recvonly(D,E) Y tells X: inactive(A,D), sendrecv(B), sendonly(C), recvonly(E) Paul Dean Willis wrote: > > On Oct 17, 2007, at 9:39 AM, Hadriel Kaplan wrote: > >>>> >>>> INVITE must contain: >>>> - these are the events I am willing to send >>>> - these are the events I desire to receive >>> >>> Do we need that first line ? Or do we just need "These are the events >>> I'm willing to receive. If I get them, great. If I don't, well, I >>> don't care, I'll assume that sending them wasn't important to you." >> >> But that's not always the case with dtmf. If a softphone makes a >> call, would the softphone always care to receive DTMF? Not all of >> them would. But they would want to tell the far-end they can _send_ >> DTMF. Not that I think this means we need a send/receive distinction >> - I think just a "I support dtmf-info" semantic is good enough for dtmf. > > I think we need two different approaches here. > > There is a big difference between "I could deal with X should you want > to send it" and "I NEED you to send me X" or "I want to know if you > intend to send me X". > > The first is a simple declarative, along the lines of what we do with > Supported and Allow. The latter two are more directive, something like > what we do with a Require. > > Otherwise said, there's a difference between "I support" and "I will > use" or "Will you use?". > > >> >>> Is there a use case for turning this into a full bidirectional offer- >>> answer? >> >> I guess the question is if it matters that a UA which can only send >> event foo but can't do anything useful receiving foo, could be sent >> foo anyway. For example, suppose we created an event-package for a >> jpeg picture, for remote-party call display. If a hard-phone has no >> LCD to display a picture, but has a stored jpeg to give to the >> far-end, would it matter if it can't say "I can send a jpeg but don't >> want to receive one"? Obviously it could just accept a received one >> (ie, 200 ok the INFO) and discard the jpeg. But is that the right >> thing to do? I dunno. We could just leave the concept up to specific >> info-event-package definitions to handle - i.e., make an event-package >> define send vs. receive event-packages pairs if it cares about it. > > I suspect that things that need two way send-receive negotiation need to > use full subscriptions. Actually, they may need to use full > subscriptions in each direction. > > But let's play with this negotiation a minute. > > Suppose instead of having a single header field for "all the > events-in-invite-dialogs we know about", we have two header fields: one > for events we are willing to receive, and another for events we are > offering to send. Those two sets might not match for a given device, but > they would need to reduce down to pairwise matches after the > offer-answer phase, so that neither end would be intending to send > something the other hadn't indicated a willingness to receive. > > So, for example. Alice might INVITE Gateway, saying "I understand keymap > and image-display events and may send you keypad events", and gateway > might answer in the 200 OK "I understand keypad events and may send you > keymap events" (note that gateway is NOT offering to send image-display > events) . Alice might then echo (in ACK) "We agree that I may send you > keypad events and that you may send me keymap events". > > Or, as you suggested, we could define directional event packages and use > a single header field. > > Alice might INVITE Gateway, saying "I'm offering to use send-keypad and > receive-keymap and receive-image-display events". Gateway responds with > "I will support receive-keypad and send-keymap events" (note it didn't > include send-image-display). Alice then ACKS with "I understand I will > be doing send-keypad and receive-keymap". > > The two are functionally equivalent, I think we just have a syntax > question. I suspect that the two-header approach is easier to parse. > > But a broader question is lurking here . . . > > How is this not just an example of a more general feature or capability > negotiation mechanism? If instead of "event packages" we talk about > "features", where a feature might be "send event X", "receive event X", > or perhaps something broader like "transition to a DOOM game"? Could we > use it to discover a peers screen resolution, keyboard layout, or access > network bandwidth? Could we do the same media-channel O/A that we do in > SDP? I believe the answer is "yes", but it requires a registry process > for each of the "features", much as we currently have a registry process > for event packages. Do we want to go in this direction? If not, where do > we draw the line? And just exactly how does this relate to RFC 3840/3841 > preferences and capabilities negotiation (which, I might add, don't > really work in a proxyless world). > > -- > 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 17 13:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiD3A-0005fo-SB; Wed, 17 Oct 2007 13:51:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiD39-0005dx-B4 for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 13:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiD38-0005dD-BM for sip@ietf.org; Wed, 17 Oct 2007 13:51:18 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiD2y-0004vD-UC for sip@ietf.org; Wed, 17 Oct 2007 13:51:18 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9HHoWk11036; Wed, 17 Oct 2007 17:50:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Wed, 17 Oct 2007 12:50:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1291DC2C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgQOt6Yg7CeOUKnSey8D8xIE0xCigAAEj9gACiSaYA= References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Christer Holmberg" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sip , Francois Audet 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, October 16, 2007 4:34 PM > To: Dean Willis; Stucker, Brian (RICH1:AR00) > Cc: Eric Burger; sip; Audet, Francois (SC100:3055); Hadriel Kaplan > Subject: RE: [Sip] INFO >=20 >=20 > Hi,=20 >=20 > >>>The trick is demuxing the event streams, or in other=20 > words, figuring=20 > >>>out the context for each event. INFO currently gives us=20 > nothing but=20 > >>>the content- modifiers to figure this out. > >>>That's not enough, as has widely been argued. > >> > >>How does 3265 make this any better? > >> > >>We're talking about identifying a data blob using an event plus a=20 > >>content-type instead of a supported plus a content-type for=20 > a period=20 > >>of time to start and end in conjunction with the INVITE=20 > dialog (so the >=20 > >>subsciption-state header is mooted). > >> > >> > >=20 > >3265 makes it better in two ways: > >=20 > >1) It provides distinct dialogs for each channel of the mux.=20 > >Thus, two events of the same class, but related to different=20 > >subscriptions, can be distinguished. > >=20 > >2) It provides semantic distinction, such that two events that=20 > >transport the same kind of content but that have different=20 > effects on=20 > >the application can be distinguished. > >=20 > >The provide NOTIFY-over-an-INVITE dialog loses advantage 1,=20 > but retains=20 > >2. The argument is that this makes it good enough for some=20 > >applications. However, there are obviously applications=20 > where it might=20 > >NOT be good enough, and a separate dialog ala 3265 would be required. >=20 > I don't think anyone has proposed to forbid using separate dialogs. >=20 > And, eventhough the receiver may be able to dispatch the=20 > event to the correct application, the sender may still have=20 > to send it on each subscription (if it doesn't know which=20 > application is associated with each subscription), so the=20 > result would be the same as using INFO. >=20 > But, these are the kind of things we would need to document.=20 > What are the issues, limitations etc with different=20 > solutions. Then let's the implementors use what they need. >=20 > >>So a NOTIFY with an event header or an INFO without an=20 > event header,=20 > >>all other things being the same and the constrained=20 > semantics of the=20 > >>NOTIFY usage being put forward here... > >> > >>Wouldn't it be equally valid to simply allow the INFO=20 > message to carry >=20 > >>an event header and say that INFO is the same as a NOTIFY with an=20 > >>implicit subscription to an INVITE dialog? Isn't this=20 > pretty much what=20 > >>it does already (minus the event header). > >> > >=20 > >There needs to be an explicit declaration of willingness to=20 > >receive the semantic load indicated by the event package.=20 > >Given that, one could certainly envision revising INFO to do the job. > >=20 > >>Deep thought: Is all INFO is missing is simply the event header? > >=20 > >Yes. The problem is that INVITE and 200 (OK) are missing the=20 > >"subscribe" header. >=20 > All we need is draft-subscribe-header-for-invite... :) And/or event header for INFO. Or perhaps not, but at least it's clearer (to me) what's missing now. >=20 > Regards, >=20 > Christer >=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 Wed Oct 17 13:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiD36-0005d4-QQ; Wed, 17 Oct 2007 13:51:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiD34-0005cy-Ue for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 13:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiD34-0005cp-4T for sip@ietf.org; Wed, 17 Oct 2007 13:51:14 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiD2x-0004v4-V4 for sip@ietf.org; Wed, 17 Oct 2007 13:51:14 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9HHoUk11012; Wed, 17 Oct 2007 17:50:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 17 Oct 2007 12:50:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgQNwPGHSYUtF9MTf+CvYtV/k4GaAApZIJg References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 16, 2007 3:56 PM > To: Stucker, Brian (RICH1:AR00) > Cc: DRAGE, Keith (Keith); IETF SIP List; Audet, Francois=20 > (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > On Oct 12, 2007, at 12:02 PM, Brian Stucker wrote: >=20 > >> > >> That's back to the question of "Is SIP an application=20 > protocol or a=20 > >> transport protocol"? > >> > >> Should the SIP-layer software be aware of and coupled to=20 > the state of=20 > >> the application that's using SIP? > >> > >> If so, then the proper design model is to build a new SIP request=20 > >> method for every new piece of application functionality. > > > > You forgot about supported. > > >=20 > Well, it's entirely possible that Supported and Accept will=20 > get damned big. I'd still like to have a query-for-specific=20 > or "opt in" =20 > model rather than a blanket "here's everything I can possibly=20 > deal with" model for declaration of extensions. RFC 3265=20 > meets that requirement. >=20 > >> > >> So for example, DTMF: Using this model of SIP extension, we might=20 > >> define a new "DTMF" method. It would look just like=20 > DTMF-over-INFO,=20 > >> except the name of the method would be DTMF. > >> It clearly resolves the INFO-context question, because now we KNOW=20 > >> we're getting dialog- related DTMF over it, and we know what to do=20 > >> with it. We know what we can transport in DTMF-requests,=20 > because the=20 > >> RFC that defines the DTMF extension method will also=20 > define exactly=20 > >> what payload format to use. > > > > INVITE > > Supported: foo > > Allow: INFO > > Accept: application/foo > > >=20 > But the MIME people aren't going to let you register a new=20 > MIME type for "foo" that is specific to each application=20 > semantic that might possibly use "foo". >=20 > > 200 OK > > Supported: foo > > Allow: INFO > > Accept: application/foo > > > > ... > > > > INFO > > Content-Type: application/foo > > [DTMF] > > > > > > Where is this broken? > >> >=20 > Broken in its usage of MIME. >=20 > Let's say we have something (not DTMF) that needs to=20 > transport jpg images that are used as soft-key overlays. To=20 > do what you're suggesting, we'd need a new MIME-type=20 > registration that says "This is just like jpeg, except that=20 > it is only useful for keypad overlays". =20 > The MIME folks would birth kittens. I think you may have misunderstood my example here. I'm postulating that you don't change the MIME type (jpeg) you change the supported/required header value. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 14:43:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDn5-0004UT-Dq; Wed, 17 Oct 2007 14:38:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiDn3-0004U4-BI for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 14:38:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiDn2-0004Rg-Fg for sip@ietf.org; Wed, 17 Oct 2007 14:38:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiDmy-0006rj-1q for sip@ietf.org; Wed, 17 Oct 2007 14:38:40 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9HIcSem008378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Oct 2007 13:38:30 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 17 Oct 2007 13:38:27 -0500 To: "Brian Stucker" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 17, 2007, at 12:50 PM, Brian Stucker wrote: >> >> Let's say we have something (not DTMF) that needs to >> transport jpg images that are used as soft-key overlays. To >> do what you're suggesting, we'd need a new MIME-type >> registration that says "This is just like jpeg, except that >> it is only useful for keypad overlays". >> The MIME folks would birth kittens. > > I think you may have misunderstood my example here. I'm postulating > that > you don't change the MIME type (jpeg) you change the supported/ > required > header value. I think that conflicts with the way Supported and Require work. They both purely say "Can support these options at any time", not "I expect you to use this particular option's handling for this particular message" Let's say you support jpeg for image-mapped touch screen and jpeg for storing in my pone book and displaying with caller ID. You'd indicate support for both in "Supported" and would not reject a request with Require for both. I send you a jpeg. How do I tell you whether to put it on your screen as an image map or store it in your phone book? -- 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 17 15:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiEvD-0007Yx-Cr; Wed, 17 Oct 2007 15:51:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiEvC-0007Y6-2c for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 15:51:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiEvA-0007WP-P4 for sip@ietf.org; Wed, 17 Oct 2007 15:51:12 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiEvA-00017P-DU for sip@ietf.org; Wed, 17 Oct 2007 15:51:12 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9HJp8c20833; Wed, 17 Oct 2007 19:51:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Wed, 17 Oct 2007 14:51:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1291E117@zrc2hxm0.corp.nortel.com> In-Reply-To: <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) thread-index: AcgQ7PMeZmIqL2E6RxilLmyFvwNh1QACgLXQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, October 17, 2007 1:38 PM > To: Stucker, Brian (RICH1:AR00) > Cc: DRAGE, Keith (Keith); IETF SIP List; Audet, Francois=20 > (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was=20 > Re: [Sip] INFO) >=20 >=20 > On Oct 17, 2007, at 12:50 PM, Brian Stucker wrote: >=20 > >> > >> Let's say we have something (not DTMF) that needs to transport jpg=20 > >> images that are used as soft-key overlays. To do what you're=20 > >> suggesting, we'd need a new MIME-type registration that=20 > says "This is=20 > >> just like jpeg, except that it is only useful for keypad overlays". > >> The MIME folks would birth kittens. > > > > I think you may have misunderstood my example here. I'm postulating=20 > > that you don't change the MIME type (jpeg) you change the=20 > supported/=20 > > required header value. >=20 >=20 > I think that conflicts with the way Supported and Require=20 > work. They both purely say "Can support these options at any=20 > time", not "I expect you to use this particular option's=20 > handling for this particular message" >=20 > Let's say you support jpeg for image-mapped touch screen and=20 > jpeg for storing in my pone book and displaying with caller=20 > ID. You'd indicate support for both in "Supported" and would=20 > not reject a request with Require for both. >=20 > I send you a jpeg. How do I tell you whether to put it on=20 > your screen as an image map or store it in your phone book? >=20 You're right. I see the difference now. Thanks, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 17 16:50:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiFn1-0008Py-2h; Wed, 17 Oct 2007 16:46:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiFmy-0008Pm-5d for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 16:46:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiFmx-0008BN-8d for sip@ietf.org; Wed, 17 Oct 2007 16:46:47 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiFmn-0002qK-Ot for sip@ietf.org; Wed, 17 Oct 2007 16:46:37 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ200037PPO5K@usaga01-in.huawei.com> for sip@ietf.org; Wed, 17 Oct 2007 13:46:37 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ2003LJPPMA6@usaga01-in.huawei.com> for sip@ietf.org; Wed, 17 Oct 2007 13:46:36 -0700 (PDT) Date: Wed, 17 Oct 2007 15:46:02 -0500 From: Spencer Dawkins Subject: Re: [Sip] INFO To: sip Message-id: <030101c810fe$bb8544b0$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47160307.7080408@cisco.com> <47160CE9.4050705@cisco.com> <59184B4E920E854DA8ACF8E44917D49F01875F85@MAIL02.cedarpointcom.com> <47163591.8040007@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: sip-bounces@ietf.org >> Wouldn't the best approach be to supersede the INFO RFC with one which >> takes care of issues, i.e. with these additional headers. >> We can't get people to change the old implementations, but at least the >> for new usages if the additional work required is a smaller delta (from >> base INFO, as compared to having to implement SUBSCRIBE/NOTIFY), they >> might be more amenable to use the new EVENT based INFO mechanism. > > Frankly, I think what we are discussing would be better applied using > NOTIFY in the INVITE dialog. We would then be devising a new means to > negotiate event packages that will share the invite dialog, but using > the same NOTIFY messages to carry the data, not INFO. > > Paul FWIW, I agree with Paul here. Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 17:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiGHg-0003c6-7A; Wed, 17 Oct 2007 17:18:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiGHe-0003Yy-0G for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 17:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiGHd-0003X2-9e for sip@ietf.org; Wed, 17 Oct 2007 17:18:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiGHb-0004TO-TJ for sip@ietf.org; Wed, 17 Oct 2007 17:18:29 -0400 X-IronPort-AV: E=Sophos;i="4.21,291,1188802800"; d="scan'208";a="238802435" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2007 14:18:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9HLIRGD028732; Wed, 17 Oct 2007 14:18:27 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9HLILsd028638; Wed, 17 Oct 2007 21:18:22 GMT 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.1830); Wed, 17 Oct 2007 17:18:08 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 17:18:07 -0400 Message-ID: <47167C0E.70006@cisco.com> Date: Wed, 17 Oct 2007 17:18:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> In-Reply-To: <47164904.8020100@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 21:18:07.0521 (UTC) FILETIME=[3664D110:01C81103] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--23.434700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9115; t=1192655907; x=1193519907; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=qQY2j2B1ZhwhKO6W3PyTmJDjWO/vcMzNWXepryVIkcc=; b=aB1Gkk1jxRGhPOXdoX+Ix05MLDDQtWOClZJPKfFZGh0zCbmLXBq9fujRKQTky6cFy4W++ckF LjRyUle8oGds0PMimLAuLNCQlOWgxXD36USymbMcYEY3GKN5552zooA81Srj4yCyKnrGtaX/94 KSH73l08ASdvLyqgnA2LBCwik=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: sip , Francois Audet , Brian Stucker , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org As a swag for how to encode this in actual headers, how about: INVITE ... Exchange-Events: dtmf;sendrecv, foo;sendonly; bar;recvonly; xyzzy;sendrecv 200 OK Exchange-Events: dtmf;recvonly, foo;recvonly; bar:sendonly; xyzzy:inactive Each event type named in Exchange-Events in the INVITE is a candidate for use with the directionality specified by the direction parameter. Event types not listed implicitly have a direction of "inactive". Event types listed without a direction are implicitly sendrecv. The Exchange-Events in the response defines which event types will actually be exchanged, and the direction(s) they will be sent. Default directions are the same as above. The valid directions in the response are constrained by what was in the request in the same way as in sdp. One agreed upon, NOTIFY may be sent in the agreed upon direction(s) within the INVITE dialog usage. Whether an initial NOTIFY is required will be determined on a per-event-package basis. (Its not needed to establish the dialog, so its a matter if it is semantically needed in the context of the event type.) Just as there are INVITEs that don't offer SDP (because they don't know what to offer) there is a need for INVITEs that don't offer events. An INVITE that contains no Exchange-Events header is not offering any. In that case the offer of events is in a reliable response and the final answer about what events will be used is in the ACK or PRACK. (To indicate that you don't desire to exchange any events, include a Exchange-Events header with no events listed.) There is no separate subscription or timer. The dialog usage is refreshed by INVITE or UPDATE in the conventional manner. Events to be exchanged are renegotiated from scratch with every reINVITE or UPDATE. If an event type takes parameters, they can be included in Exchange-Events. That can work in some simple cases, but not in complex cases. I think event types that need complex parameters will be problematic in this usage. (Note that the kpml package only requires parameters to identify the dialog. In this usage those won't be needed.) There is a problem if the event type may (or must) use a body in the subscribe. The kpml package falls into this category. :-( The body could simply be included in the message carrying the Exchange-Events header. But that potentially means a bunch of body parts with the recipient having the problem of deciding how each part should be matched to a particular event type. That is more or less the same problem we are trying to solve here, so its not good. Also, it would seem that every time you send a reinvite or update you might have to send these again. One alternative is simply to say that this mechanism cannot be used with event packages that require a subscribe body. That seems to exclude the use of KPML. :-( Paul Paul Kyzivat wrote: > We don't need all these nuances - just a few. It isn't important to say > "I could deal with X if you sent it but I don't want you to send it." > > There are two paradigms already used in sip, and discussed here, and > either could be used: > > 1) X tells Y: I would like you to send A,B,C > Y tells X: I will send you B,C; I would like you to send B,C,D,E > X tells Y: Please send B,E > > 2) X tells Y: I can send A,B,C; want to receive B,C,D,E > Y tells X: I will send you B,C; Please send me B,E > > The use of the directionality attributes is an encoding of (2): > > 2b) X tells Y: sendonly(A), sendrecv(B,C), recvonly(D,E) > Y tells X: inactive(A,D), sendrecv(B), sendonly(C), recvonly(E) > > Paul > > Dean Willis wrote: >> >> On Oct 17, 2007, at 9:39 AM, Hadriel Kaplan wrote: >> >>>>> >>>>> INVITE must contain: >>>>> - these are the events I am willing to send >>>>> - these are the events I desire to receive >>>> >>>> Do we need that first line ? Or do we just need "These are the events >>>> I'm willing to receive. If I get them, great. If I don't, well, I >>>> don't care, I'll assume that sending them wasn't important to you." >>> >>> But that's not always the case with dtmf. If a softphone makes a >>> call, would the softphone always care to receive DTMF? Not all of >>> them would. But they would want to tell the far-end they can _send_ >>> DTMF. Not that I think this means we need a send/receive distinction >>> - I think just a "I support dtmf-info" semantic is good enough for dtmf. >> >> I think we need two different approaches here. >> >> There is a big difference between "I could deal with X should you want >> to send it" and "I NEED you to send me X" or "I want to know if you >> intend to send me X". >> >> The first is a simple declarative, along the lines of what we do with >> Supported and Allow. The latter two are more directive, something like >> what we do with a Require. >> >> Otherwise said, there's a difference between "I support" and "I will >> use" or "Will you use?". >> >> >>> >>>> Is there a use case for turning this into a full bidirectional offer- >>>> answer? >>> >>> I guess the question is if it matters that a UA which can only send >>> event foo but can't do anything useful receiving foo, could be sent >>> foo anyway. For example, suppose we created an event-package for a >>> jpeg picture, for remote-party call display. If a hard-phone has no >>> LCD to display a picture, but has a stored jpeg to give to the >>> far-end, would it matter if it can't say "I can send a jpeg but don't >>> want to receive one"? Obviously it could just accept a received one >>> (ie, 200 ok the INFO) and discard the jpeg. But is that the right >>> thing to do? I dunno. We could just leave the concept up to >>> specific info-event-package definitions to handle - i.e., make an >>> event-package define send vs. receive event-packages pairs if it >>> cares about it. >> >> I suspect that things that need two way send-receive negotiation need >> to use full subscriptions. Actually, they may need to use full >> subscriptions in each direction. >> >> But let's play with this negotiation a minute. >> >> Suppose instead of having a single header field for "all the >> events-in-invite-dialogs we know about", we have two header fields: >> one for events we are willing to receive, and another for events we >> are offering to send. Those two sets might not match for a given >> device, but they would need to reduce down to pairwise matches after >> the offer-answer phase, so that neither end would be intending to send >> something the other hadn't indicated a willingness to receive. >> >> So, for example. Alice might INVITE Gateway, saying "I understand >> keymap and image-display events and may send you keypad events", and >> gateway might answer in the 200 OK "I understand keypad events and may >> send you keymap events" (note that gateway is NOT offering to send >> image-display events) . Alice might then echo (in ACK) "We agree that >> I may send you keypad events and that you may send me keymap events". >> >> Or, as you suggested, we could define directional event packages and >> use a single header field. >> >> Alice might INVITE Gateway, saying "I'm offering to use send-keypad >> and receive-keymap and receive-image-display events". Gateway responds >> with "I will support receive-keypad and send-keymap events" (note it >> didn't include send-image-display). Alice then ACKS with "I understand >> I will be doing send-keypad and receive-keymap". >> >> The two are functionally equivalent, I think we just have a syntax >> question. I suspect that the two-header approach is easier to parse. >> >> But a broader question is lurking here . . . >> >> How is this not just an example of a more general feature or >> capability negotiation mechanism? If instead of "event packages" we >> talk about "features", where a feature might be "send event X", >> "receive event X", or perhaps something broader like "transition to a >> DOOM game"? Could we use it to discover a peers screen resolution, >> keyboard layout, or access network bandwidth? Could we do the same >> media-channel O/A that we do in SDP? I believe the answer is "yes", >> but it requires a registry process for each of the "features", much as >> we currently have a registry process for event packages. Do we want to >> go in this direction? If not, where do we draw the line? And just >> exactly how does this relate to RFC 3840/3841 preferences and >> capabilities negotiation (which, I might add, don't really work in a >> proxyless world). >> >> -- >> 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 Wed Oct 17 18:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiHKR-0003hW-AY; Wed, 17 Oct 2007 18:25:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiHKP-0003gF-Vu for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 18:25:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiHKP-0003GI-8o for sip@ietf.org; Wed, 17 Oct 2007 18:25:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiHKD-0006W3-Nf for sip@ietf.org; Wed, 17 Oct 2007 18:25:13 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9HMP9YB009736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Oct 2007 17:25:10 -0500 In-Reply-To: <47167C0E.70006@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Wed, 17 Oct 2007 17:25:07 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip , Francois Audet , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On Oct 17, 2007, at 4:18 PM, Paul Kyzivat wrote: > As a swag for how to encode this in actual headers, how about: > > INVITE ... > Exchange-Events: dtmf;sendrecv, foo;sendonly; > bar;recvonly; xyzzy;sendrecv > > 200 OK > Exchange-Events: dtmf;recvonly, foo;recvonly; > bar:sendonly; xyzzy:inactive It's more concise to have: INVITE ... Send-Events: dtmf, foo, xyzzy Recv-Events: dtmf, bar, xyzzy 200 OK ... Send-Events: bar Recv-Events: dtmf, foo ACK ... Send-Events: dtmf, foo Recv Events: bar Do we need to encode in 200 OK that xyyyz was offered and rejected, or is just not including it in the 200 OK enough? I think that if you offer to send it, and I don't offer to receive it, then we know we aren't using it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 17 18:58:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiHmv-0004uv-Mz; Wed, 17 Oct 2007 18:54:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiHms-0004qa-Vi for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 18:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiHmr-0004lt-O9 for sip@ietf.org; Wed, 17 Oct 2007 18:54:49 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiHmj-0007gb-Ju for sip@ietf.org; Wed, 17 Oct 2007 18:54:47 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Wed, 17 Oct 2007 18:54:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 17 Oct 2007 18:54:31 -0400 From: Hadriel Kaplan To: Dean Willis , Paul Kyzivat Date: Wed, 17 Oct 2007 18:54:29 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgRDr6Oo+G7TQdmQI2lxcZR2ze5gwAALjJw Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> In-Reply-To: <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip , Francois Audet , Brian Stucker , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Why does there need to be a 3-way exchange? Can the 200-ok have Events listed that weren't offered? (why would it bothe= r to? The offerer didn't say it could do them.) So isn't the ACK always a mirror image of the 200ok, in which case why both= er? Unless you had competing Event types, where only one should be used, or cou= ldn't do some combo of them. And then this concept is getting bloated, and= will end up looking like SDP capabilities negotiation. And I'm still stuck on your last question, which is what application use-ca= se really needs directionality, other than as a nit? -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, October 17, 2007 6:25 PM > To: Paul Kyzivat > Cc: sip; Francois Audet; Christer Holmberg; Brian Stucker > Subject: Re: [Sip] INFO > > > On Oct 17, 2007, at 4:18 PM, Paul Kyzivat wrote: > > > As a swag for how to encode this in actual headers, how about: > > > > INVITE ... > > Exchange-Events: dtmf;sendrecv, foo;sendonly; > > bar;recvonly; xyzzy;sendrecv > > > > 200 OK > > Exchange-Events: dtmf;recvonly, foo;recvonly; > > bar:sendonly; xyzzy:inactive > > It's more concise to have: > > INVITE ... > Send-Events: dtmf, foo, xyzzy > Recv-Events: dtmf, bar, xyzzy > > > 200 OK ... > Send-Events: bar > Recv-Events: dtmf, foo > > ACK ... > Send-Events: dtmf, foo > Recv Events: bar > > Do we need to encode in 200 OK that xyyyz was offered and rejected, > or is just not including it in the 200 OK enough? > > I think that if you offer to send it, and I don't offer to receive > it, then we know we aren't using it. > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 17 21:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiKMR-0006oB-JF; Wed, 17 Oct 2007 21:39:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiKMP-0006o5-SC for sip-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 21:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiKMP-0006jA-1f for sip@ietf.org; Wed, 17 Oct 2007 21:39:41 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiKMG-0003um-Tu for sip@ietf.org; Wed, 17 Oct 2007 21:39:39 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Wed, 17 Oct 2007 21:39:27 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 17 Oct 2007 21:39:27 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Wed, 17 Oct 2007 21:38:55 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgRBP6cAa/BpRJ8T22TcAe6xZ2UdAAIICTA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> In-Reply-To: <47167C0E.70006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: sip-bounces@ietf.org Howdy, Inline comments, but also: this seems like going down the road of complexit= y again. One of the reasons I think people use INFO-dtmf instead of KPML i= s it's so darn simple/easy. If we want people to change their implementati= ons to support negotiation and explicit content context indication, it shou= ld be as trivial as possible, IMHO. No bells, no whistles. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Just as there are INVITEs that don't offer SDP (because they don't know > what to offer) there is a need for INVITEs that don't offer events. An > INVITE that contains no Exchange-Events header is not offering any. In > that case the offer of events is in a reliable response and the final > answer about what events will be used is in the ACK or PRACK. (To > indicate that you don't desire to exchange any events, include a > Exchange-Events header with no events listed.) Why do this? What use case is there for not saying what you can do in the = Invite? Offer-less Invites cause enough problems. We shouldn't repeat the= m. > There is a problem if the event type may (or must) use a body in the > subscribe. The kpml package falls into this category. :-( > The body could simply be included in the message carrying the > Exchange-Events header. But that potentially means a bunch of body parts > with the recipient having the problem of deciding how each part should > be matched to a particular event type. That is more or less the same > problem we are trying to solve here, so its not good. Also, it would > seem that every time you send a reinvite or update you might have to > send these again. Ya that's bad. If someone wants to define an info-event that needs such th= ings, they can define it to exchange it in an INFO when they do. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 04:07:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQL1-0003g9-9T; Thu, 18 Oct 2007 04:02:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiQKz-0003d9-MH for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 04:02:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQKy-0003c7-QI for sip@ietf.org; Thu, 18 Oct 2007 04:02:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiQKy-0005mQ-FS for sip@ietf.org; Thu, 18 Oct 2007 04:02:36 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9I82TgY012499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Oct 2007 03:02:30 -0500 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Thu, 18 Oct 2007 03:02:21 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip , Paul Kyzivat , Brian Stucker , Francois Audet , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > Why does there need to be a 3-way exchange? > Can the 200-ok have Events listed that weren't offered? (why would > it bother to? The offerer didn't say it could do them.) > So isn't the ACK always a mirror image of the 200ok, in which case > why bother? > Unless you had competing Event types, where only one should be > used, or couldn't do some combo of them. And then this concept is > getting bloated, and will end up looking like SDP capabilities > negotiation. > The only argument I can see is -- it prevents race conditions. Don't send an event until the ACK. > And I'm still stuck on your last question, which is what > application use-case really needs directionality, other than as a nit? Yeah, me too. Or to rephrase, what application needs "I want to send . . ." rather than "I understand . . ." -- 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 18 05:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRl0-0001nc-6s; Thu, 18 Oct 2007 05:33:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiRkv-0001ci-GQ for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 05:33:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRku-0001bz-Ap for sip@ietf.org; Thu, 18 Oct 2007 05:33:28 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiRkt-0007ga-SS for sip@ietf.org; Thu, 18 Oct 2007 05:33:28 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1IiRlg-0002Lg-Ph; Thu, 18 Oct 2007 02:34:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Thu, 18 Oct 2007 02:33:05 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> In-Reply-To: <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgRXrYgbraXHVdGSvOOsguRIsHQQwACImAg References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> From: "Michael Procter" To: "Dean Willis" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip , Paul Kyzivat , Christer Holmberg , Francois Audet , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: >=20 > > Why does there need to be a 3-way exchange? > > Can the 200-ok have Events listed that weren't offered? (why would > > it bother to? The offerer didn't say it could do them.) > > So isn't the ACK always a mirror image of the 200ok, in which case > > why bother? > > Unless you had competing Event types, where only one should be > > used, or couldn't do some combo of them. And then this concept is > > getting bloated, and will end up looking like SDP capabilities > > negotiation. > > >=20 > The only argument I can see is -- it prevents race conditions. Don't > send an event until the ACK. That sounds like the media clipping problem. If the INVITE indicates willingness to receive a specific event, then maybe it should be able to do so before it has seen the 200 response. Then the UAS needn't wait for the ACK before sending events. > > And I'm still stuck on your last question, which is what > > application use-case really needs directionality, other than as a > nit? >=20 > Yeah, me too. Or to rephrase, what application needs "I want to > send . . ." rather than "I understand . . ." DTMF? I noticed this problem with RFC2833 negotiation a couple of years ago. A device wanted to indicate willingness to send RFC2833, but wasn't able to render received indications. Since SDP describes what the device can receive, the 'solution' was to fib. Not necessarily something that needs to be supported, but a data point from the field to be considered. Regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 05:49:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRzD-0003cZ-Kv; Thu, 18 Oct 2007 05:48:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiRzA-0003bI-Sf for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 05:48:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRz9-0003aG-Qm for sip@ietf.org; Thu, 18 Oct 2007 05:48:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiRz9-00005v-7R for sip@ietf.org; Thu, 18 Oct 2007 05:48:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 38BBF2007B; Thu, 18 Oct 2007 11:48:10 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-80-47172bda9f2d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FCC2200CC; Thu, 18 Oct 2007 11:48:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 11:48:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 18 Oct 2007 11:48:07 +0200 Message-ID: In-Reply-To: <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgQ7O/h6hEj0G9+SdOGbKQOV7XMiQAfbZYw References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Brian Stucker" X-OriginalArrivalTime: 18 Oct 2007 09:48:09.0822 (UTC) FILETIME=[FDDAFFE0:01C8116B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>Let's say we have something (not DTMF) that needs to transport jpg=20 >>>images that are used as soft-key overlays. To do what you're=20 >>>suggesting, we'd need a new MIME-type registration that says "This is >>>just like jpeg, except that it is only useful for keypad overlays". >>>The MIME folks would birth kittens. >> >>I think you may have misunderstood my example here. I'm postulating=20 >>that you don't change the MIME type (jpeg) you change the supported/=20 >>required header value. >=20 >=20 >I think that conflicts with the way Supported and Require=20 >work. They both purely say "Can support these options at any=20 >time", not "I expect you to use this particular option's=20 >handling for this particular message" >=20 >Let's say you support jpeg for image-mapped touch screen and=20 >jpeg for storing in my pone book and displaying with caller=20 >ID. You'd indicate support for both in "Supported" and would=20 >not reject a request with Require for both. >=20 >I send you a jpeg. How do I tell you whether to put it on=20 >your screen as an image map or store it in your phone book? If the application on the receiving side (or the person your're talking to) has asked you to send a jpeg, it most likely knows what to do it. This is similar to when the receiver subscribes to an "jpeg event". The one sending the jpeg may not know what the receiver is going to do with it, but the one subscribing to the event knows. If you send a jpeg just "out of the blue", you may not know what the receiver is going to do with it. The receiving end may prompt the user what to do, it may do something by default, etc. That is an implementation issue - not a SIP protocol issue. SIP is simply used to transport the jpeg. That is the whole purpose of INFO - sending data which is not related to the SIP session itself. 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 Thu Oct 18 05:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiS8r-0007EJ-73; Thu, 18 Oct 2007 05:58:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiS8p-0007Dv-CQ for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 05:58:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiS8o-00072Z-Du for sip@ietf.org; Thu, 18 Oct 2007 05:58:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiS8j-0000KC-Ll for sip@ietf.org; Thu, 18 Oct 2007 05:58:06 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0710920987; Thu, 18 Oct 2007 11:58:05 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-6b-47172e2cadc0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D3A0A20051; Thu, 18 Oct 2007 11:58:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 11:58:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 18 Oct 2007 11:58:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgQ7O/h6hEj0G9+SdOGbKQOV7XMiQAfbZYwAACnJOA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com>!! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3-97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com><38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com><5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com><690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Dean Willis" , "Brian Stucker" X-OriginalArrivalTime: 18 Oct 2007 09:58:04.0359 (UTC) FILETIME=[603A2570:01C8116D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" 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: , Errors-To: sip-bounces@ietf.org =20 > Hi,=20 >=20 > >>>Let's say we have something (not DTMF) that needs to transport jpg=20 > >>>images that are used as soft-key overlays. To do what you're=20 > >>>suggesting, we'd need a new MIME-type registration that=20 > says "This is >=20 > >>>just like jpeg, except that it is only useful for keypad overlays". > >>>The MIME folks would birth kittens. > >> > >>I think you may have misunderstood my example here. I'm postulating=20 > >>that you don't change the MIME type (jpeg) you change the=20 > supported/=20 > >>required header value. > >=20 > >=20 > >I think that conflicts with the way Supported and Require work. They=20 > >both purely say "Can support these options at any time", not=20 > "I expect=20 > >you to use this particular option's handling for this particular=20 > >message" > >=20 > >Let's say you support jpeg for image-mapped touch screen and=20 > jpeg for=20 > >storing in my pone book and displaying with caller ID. You'd=20 > indicate=20 > >support for both in "Supported" and would not reject a request with=20 > >Require for both. > >=20 > >I send you a jpeg. How do I tell you whether to put it on=20 > your screen=20 > >as an image map or store it in your phone book? >=20 > If the application on the receiving side (or the person=20 > your're talking > to) has asked you to send a jpeg, it most likely knows what to do it. > This is similar to when the receiver subscribes to an "jpeg=20 > event". The one sending the jpeg may not know what the=20 > receiver is going to do with it, but the one subscribing to=20 > the event knows. >=20 > If you send a jpeg just "out of the blue", you may not know=20 > what the receiver is going to do with it. The receiving end=20 > may prompt the user what to do, it may do something by=20 > default, etc. That is an implementation issue - not a SIP=20 > protocol issue. SIP is simply used to transport the jpeg.=20 > That is the whole purpose of INFO - sending data which is not=20 > related to the SIP session itself. I guess I should say "SIP core" instead of "SIP session". 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 Thu Oct 18 08:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUlX-0004Ux-4s; Thu, 18 Oct 2007 08:46:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiUlU-0004Ui-Jw for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 08:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUlT-0004UT-Hn for sip@ietf.org; Thu, 18 Oct 2007 08:46:15 -0400 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 1IiUlS-0007ix-6P for sip@ietf.org; Thu, 18 Oct 2007 08:46:15 -0400 X-IronPort-AV: E=Sophos;i="4.21,295,1188802800"; d="scan'208";a="24820788" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2007 05:46:13 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ICkCAT005344; Thu, 18 Oct 2007 08:46:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9ICk88X001647; Thu, 18 Oct 2007 12:46:08 GMT 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.1830); Thu, 18 Oct 2007 08:46:08 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 08:46:07 -0400 Message-ID: <47175590.3050003@cisco.com> Date: Thu, 18 Oct 2007 08:46:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 12:46:07.0967 (UTC) FILETIME=[DA869EF0:01C81184] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--21.037400-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3350; t=1192711572; x=1193575572; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=dyukqdus3WE0AZh7hys6optZzEzOphIPjYUm7DCQDfs=; b=lVRVvtiOH2PJv7CwCeb0nKJyMvl0aDofVfu5ecT5z2Ev1G94oWYjvrFCmRqTN2WvCf/5ANrT B0anV88fokp12ssDT8oYQpoVWiSgBfnWA54ilVtRDwJe6GOF9G7r7Qjs; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Howdy, > Inline comments, but also: this seems like going down the road of complexity again. One of the reasons I think people use INFO-dtmf instead of KPML is it's so darn simple/easy. If we want people to change their implementations to support negotiation and explicit content context indication, it should be as trivial as possible, IMHO. No bells, no whistles. SIP is not simple. If you have mastered doing the rest of sip then this is not a burden. IMO people are more concerned with extra messages and extra state than they are with making it extra simple. I do agree that things should be as simple as possible - but no simpler. Too often things are made "simple" at the expense of being inadequate for the real job. INFO is in fact an example of this. More below. >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> Just as there are INVITEs that don't offer SDP (because they don't know >> what to offer) there is a need for INVITEs that don't offer events. An >> INVITE that contains no Exchange-Events header is not offering any. In >> that case the offer of events is in a reliable response and the final >> answer about what events will be used is in the ACK or PRACK. (To >> indicate that you don't desire to exchange any events, include a >> Exchange-Events header with no events listed.) > > Why do this? What use case is there for not saying what you can do in the Invite? Offer-less Invites cause enough problems. We shouldn't repeat them. I know of lots of cases that can loosely be categorized as 3pcc where there is a B2BUA in the middle that initiates invites. It needs to learn the capabilities of one UA and then offer them to another. Because it is simply going to act as a signaling relay it doesn't have any preferences of its own about these things. In general I have found that 3pcc is a good source of requirements that are otherwise often overlooked. Better to capture them up front than discover them later. >> There is a problem if the event type may (or must) use a body in the >> subscribe. The kpml package falls into this category. :-( >> The body could simply be included in the message carrying the >> Exchange-Events header. But that potentially means a bunch of body parts >> with the recipient having the problem of deciding how each part should >> be matched to a particular event type. That is more or less the same >> problem we are trying to solve here, so its not good. Also, it would >> seem that every time you send a reinvite or update you might have to >> send these again. > > Ya that's bad. If someone wants to define an info-event that needs such things, they can define it to exchange it in an INFO when they do. I'm hoping we don't have to define a whole new set of event packages. That is one of the reasons I would prefer to use an in-invite-dialog-usage NOTIFY than INFO for this. Ideally already existing event packages can then be used in this new way. Maybe some of them will need some slight enhancement, but that would be better than having to define a whole new and parallel set. Not only will that speed things up in the standardization process, but also it will simplify implementation and improve chances of support. 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 18 08:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUoK-0005a3-Pd; Thu, 18 Oct 2007 08:49:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiUoI-0005Yj-Cb for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 08:49:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUoH-0005XM-4h for sip@ietf.org; Thu, 18 Oct 2007 08:49:09 -0400 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 1IiUoA-0007n9-Ua for sip@ietf.org; Thu, 18 Oct 2007 08:49:09 -0400 X-IronPort-AV: E=Sophos;i="4.21,295,1188802800"; d="scan'208";a="536956923" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2007 05:48:50 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ICmoPO007353; Thu, 18 Oct 2007 08:48:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ICmgkH008388; Thu, 18 Oct 2007 12:48:49 GMT 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.1830); Thu, 18 Oct 2007 08:48:46 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 08:48:46 -0400 Message-ID: <4717562E.20706@cisco.com> Date: Thu, 18 Oct 2007 08:48:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> In-Reply-To: <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 12:48:46.0409 (UTC) FILETIME=[38F6F390:01C81185] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--13.025600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1211; t=1192711730; x=1193575730; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Dean=20Willis=20; bh=zxypovsEYqFCtE7D6jjwQjt17qCa9DF9oSqVZoKorA4=; b=WlxJYXvFfGp6aZyyLij3kx6l6B6XAiGTWoIiQLG9tG4HRElUbjStZ/7FZRK89nQYk8GzKM5H eBrt/ylwn4DD+X0RPxq6rTYn9dtlf5I+j01fjKZGdwcbTCRCO6un8xI2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip , Francois Audet , Brian Stucker , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org I think this problem can be solved with a 2-way exchange. Introducing a 3-way exchange means that the "delayed offer" needed for 3pcc can't be supported in a straightforward way. IMO that is a strong argument against it. Paul Dean Willis wrote: > > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > >> Why does there need to be a 3-way exchange? >> Can the 200-ok have Events listed that weren't offered? (why would it >> bother to? The offerer didn't say it could do them.) >> So isn't the ACK always a mirror image of the 200ok, in which case why >> bother? >> Unless you had competing Event types, where only one should be used, >> or couldn't do some combo of them. And then this concept is getting >> bloated, and will end up looking like SDP capabilities negotiation. >> > > The only argument I can see is -- it prevents race conditions. Don't > send an event until the ACK. > >> And I'm still stuck on your last question, which is what application >> use-case really needs directionality, other than as a nit? > > Yeah, me too. Or to rephrase, what application needs "I want to send . . > ." rather than "I understand . . ." > > > -- > 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 18 08:57:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUvo-0004Tt-UG; Thu, 18 Oct 2007 08:56:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiUvn-0004T4-7T for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 08:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiUvm-0004S1-96 for sip@ietf.org; Thu, 18 Oct 2007 08:56:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiUvf-0008BC-ME for sip@ietf.org; Thu, 18 Oct 2007 08:56:54 -0400 X-IronPort-AV: E=Sophos;i="4.21,295,1188802800"; d="scan'208";a="239165860" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Oct 2007 05:56:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9ICuj7G016566; Thu, 18 Oct 2007 05:56:45 -0700 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 l9ICu8ml001323; Thu, 18 Oct 2007 12:56:45 GMT 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.1830); Thu, 18 Oct 2007 08:56:42 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 08:56:41 -0400 Message-ID: <4717580A.8010001@cisco.com> Date: Thu, 18 Oct 2007 08:56:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com>< 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 12:56:41.0889 (UTC) FILETIME=[545F7110:01C81186] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--36.009000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3011; t=1192712205; x=1193576205; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20What=20are=20we=20arguing=20about=20when=20we=20say=2 0INFO?=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20; bh=irUE9LFcD6U3EFkJndn+NqNAtivt/Uv4VRTfvWCsVSk=; b=Xr9Axh7iWU6tV1b7rRPh70U0sQXdgbtZbW9oXj2CEceyEZ8/vF8kxy5hwHtURUsm8KJB39dm HwYrOk8MNAbm4isXS+rQzB37wSEBRGrBTE/caiqf7qEXDcesVWEhExOB; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF SIP List , Francois Audet , Brian Stucker , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org inline Christer Holmberg wrote: > Hi, > >>>> Let's say we have something (not DTMF) that needs to transport jpg >>>> images that are used as soft-key overlays. To do what you're >>>> suggesting, we'd need a new MIME-type registration that says "This is > >>>> just like jpeg, except that it is only useful for keypad overlays". >>>> The MIME folks would birth kittens. >>> I think you may have misunderstood my example here. I'm postulating >>> that you don't change the MIME type (jpeg) you change the supported/ >>> required header value. >> >> I think that conflicts with the way Supported and Require >> work. They both purely say "Can support these options at any >> time", not "I expect you to use this particular option's >> handling for this particular message" >> >> Let's say you support jpeg for image-mapped touch screen and >> jpeg for storing in my pone book and displaying with caller >> ID. You'd indicate support for both in "Supported" and would >> not reject a request with Require for both. >> >> I send you a jpeg. How do I tell you whether to put it on >> your screen as an image map or store it in your phone book? > > If the application on the receiving side (or the person your're talking > to) has asked you to send a jpeg, it most likely knows what to do it. > This is similar to when the receiver subscribes to an "jpeg event". The > one sending the jpeg may not know what the receiver is going to do with > it, but the one subscribing to the event knows. In pretty much all the cases under discussion it is not a matter of asking a specific question that has one answer, and the mechanisms under discussion are not equipped for that. Rather it is a matter of expressing an interest in being notified of a class of things if and when they happen or come available. And in Dean's case an interest has been expressed in events serving two purposes: touch screen maps and caller pictures. It just happens that both are represented by the same data type. Matching the delivered information to the particular requested "event type" is in fact thw problem we are trying to solve. How are you imagining that this matching is taking place? Paul > If you send a jpeg just "out of the blue", you may not know what the > receiver is going to do with it. The receiving end may prompt the user > what to do, it may do something by default, etc. That is an > implementation issue - not a SIP protocol issue. SIP is simply used to > transport the jpeg. That is the whole purpose of INFO - sending data > which is not related to the SIP session itself. > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 09:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVAC-0005QW-46; Thu, 18 Oct 2007 09:11:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiVAA-0005PH-Ag for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 09:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiV75-0000Rb-E8 for sip@ietf.org; Thu, 18 Oct 2007 09:08:35 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiV6z-0000B4-6k for sip@ietf.org; Thu, 18 Oct 2007 09:08:35 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQ300453Z50IX@siemenscomms.co.uk> for sip@ietf.org; Thu, 18 Oct 2007 14:07:49 +0100 (BST) Date: Thu, 18 Oct 2007 14:08:09 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: <4717562E.20706@cisco.com> To: Paul Kyzivat , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D0F5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgRhz/Ek9ppgWpHS26lNLjD/hgHUwAAJu4A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <4717562E.20706@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip , Francois Audet , Christer Holmberg , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Paul, Yes, I agree. Your argument is a stronger one than the UPDATE argument I put forward earlier. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 18 October 2007 13:49 > To: Dean Willis > Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg > Subject: Re: [Sip] INFO > > I think this problem can be solved with a 2-way exchange. > Introducing a > 3-way exchange means that the "delayed offer" needed for 3pcc > can't be > supported in a straightforward way. IMO that is a strong argument > against it. > > Paul > > Dean Willis wrote: > > > > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > > > >> Why does there need to be a 3-way exchange? > >> Can the 200-ok have Events listed that weren't offered? > (why would it > >> bother to? The offerer didn't say it could do them.) > >> So isn't the ACK always a mirror image of the 200ok, in > which case why > >> bother? > >> Unless you had competing Event types, where only one > should be used, > >> or couldn't do some combo of them. And then this concept > is getting > >> bloated, and will end up looking like SDP capabilities negotiation. > >> > > > > The only argument I can see is -- it prevents race > conditions. Don't > > send an event until the ACK. > > > >> And I'm still stuck on your last question, which is what > application > >> use-case really needs directionality, other than as a nit? > > > > Yeah, me too. Or to rephrase, what application needs "I > want to send . . > > ." rather than "I understand . . ." > > > > > > -- > > 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 18 09:39:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVWw-0006pg-UN; Thu, 18 Oct 2007 09:35:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiVWu-0006mO-GO for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 09:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiVWt-0006gp-AP for sip@ietf.org; Thu, 18 Oct 2007 09:35:15 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiVWi-0001jI-Mx for sip@ietf.org; Thu, 18 Oct 2007 09:35:11 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ400MCN0DVDX@usaga01-in.huawei.com> for sip@ietf.org; Thu, 18 Oct 2007 06:34:43 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ4003QL0DU67@usaga01-in.huawei.com> for sip@ietf.org; Thu, 18 Oct 2007 06:34:43 -0700 (PDT) Date: Thu, 18 Oct 2007 08:34:05 -0500 From: Spencer Dawkins Subject: Re: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03 To: IETF SIP List Message-id: <07f301c8118b$8de4af40$6a01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5D1A7985295922448D5550C94DE29180017E1D88@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: sip-bounces@ietf.org Hi, Keith, I reviewed 00/01 of this draft pretty seriously, and have reviewed the 02 and 03 diffs. It's ready for publication as an Informational RFC. I have one question, mostly involving future-proofing, and it may not require any changes to the current draft. This text was added in 03: Essential Corrections to SIP: A collection of fixes to SIP that address important bugs and vulnerabilities. These include a fix requiring loop detection in any proxy that forks [82] and a clarification on how record-routing works [110]. This points to two references, but it's likely there will be others in the future, (my impression from http://www3.ietf.org/proceedings/07mar/minutes/sip.html and http://www3.ietf.org/proceedings/07jul/minutes/sip.html is that we have not identified the last essential correction to SIP). Is there any convention that the SIP working group can adopt so that implementers can know that some future "fix to some random thing we all thought worked, but it doesn't" is ALSO an essential correction? Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 10:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWPa-0000yV-AQ; Thu, 18 Oct 2007 10:31:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWPX-0000un-Hy for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWPW-0000n1-Ee for sip@ietf.org; Thu, 18 Oct 2007 10:31:42 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiWPO-0003v3-An for sip@ietf.org; Thu, 18 Oct 2007 10:31:40 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 10:31:20 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 10:31:20 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 18 Oct 2007 10:31:19 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgRXT2pje27cJkUSPWuKU/G6kGoOQANf6Pg Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> <3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> In-Reply-To: <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > > > Why does there need to be a 3-way exchange? > > Can the 200-ok have Events listed that weren't offered? (why would > > it bother to? The offerer didn't say it could do them.) > > So isn't the ACK always a mirror image of the 200ok, in which case > > why bother? > > Unless you had competing Event types, where only one should be > > used, or couldn't do some combo of them. And then this concept is > > getting bloated, and will end up looking like SDP capabilities > > negotiation. > > > > The only argument I can see is -- it prevents race conditions. Don't > send an event until the ACK. We could just define that no INFO (or NOTIFY if that be the method) can be = sent until the ACK, regardless. Like BYEs. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 10:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWUv-0002YA-3N; Thu, 18 Oct 2007 10:37:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWUs-0002T6-AU for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWUr-0002I8-F5 for sip@ietf.org; Thu, 18 Oct 2007 10:37:13 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiWUf-00049p-87 for sip@ietf.org; Thu, 18 Oct 2007 10:37:08 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 10:36:55 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 10:36:55 -0400 From: Hadriel Kaplan To: Dean Willis Date: Thu, 18 Oct 2007 10:36:54 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgRXaI1UOTZceBoSh+B0GRMdInp+AANf+SA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> <47154456.4050300@cisco.com> <47164904.8020100@cisco.com> <47167C0E.70006@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip , Paul Kyzivat 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > On Oct 17, 2007, at 8:38 PM, Hadriel Kaplan wrote: > > >> There is a problem if the event type may (or must) use a body in the > >> subscribe. The kpml package falls into this category. :-( > >> The body could simply be included in the message carrying the > >> Exchange-Events header. But that potentially means a bunch of body > >> parts > >> with the recipient having the problem of deciding how each part > >> should > >> be matched to a particular event type. That is more or less the same > >> problem we are trying to solve here, so its not good. Also, it would > >> seem that every time you send a reinvite or update you might have to > >> send these again. > > > > Ya that's bad. If someone wants to define an info-event that needs > > such things, they can define it to exchange it in an INFO when they > > do. > > > > The trick here is to split it into two events packages -- one that > defines the input template, and another that generates key events > within that template. Sure, but the event package offered in the Invite only needs to be one. An= d if someone were to actually go do this thing, you could define a paramete= r to indicate the attachment is the subscription information (vs. the event= itself), so that there would need to be only one event name and other even= ts could re-use the parameter instead of having to define 2 event names. B= ut that's getting ahead of ourselves anyway. ;) > If the events in play change, I can't see NOT needing a reINVITE, or > classicaly, new SUBSCRIBE requests. Sure, Paul mentioned a re-Invite restarting the subscriptions, which seemed= reasonable. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 10:42:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWZk-0001aq-VT; Thu, 18 Oct 2007 10:42:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWZi-0001Zv-Ta for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:42:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWZi-0001Zj-1G for sip@ietf.org; Thu, 18 Oct 2007 10:42:14 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiWZh-0004oC-LE for sip@ietf.org; Thu, 18 Oct 2007 10:42:13 -0400 X-AuditID: c26e2f18-000027d80000110c-5b-471770af5ab0 Received: from viper.eu.tieto.com ([194.110.47.167]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:41:51 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:42:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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, 18 Oct 2007 17:42:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Playing media message on unanswered call Thread-Index: AcgRlRDWNQr115kMRkizEHK5Y/Ioaw== From: To: X-OriginalArrivalTime: 18 Oct 2007 14:42:11.0922 (UTC) FILETIME=[115DD320:01C81195] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] Playing media message on unanswered call 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: , Errors-To: sip-bounces@ietf.org Hello all, I am thinking about one problem, consider following message flow: 1. UE A sends SIP INVITE message with SDP offer to EU B 2. On originating call leg there is application server announced about = the call. 3. 180 Ringing message with SDP answer is sent from UE B to UE A (AS is = announced that the call is in progress) 4. Time frame allocated to establish the call passed at AS and the = message needs to be played ... Can now the AS make use of negotiated media paths and play some "called = party not available" message without sending 200 OK message first? My assumption here is that media paths are negoiated (UE A claims = sendrecv audio channel so it must be prepare to receive media) so AS = "can" send this message. Consider also little complication, AS is not able to play media in a = codec claimed in the answer. Can AS send another 180 ringing message = where the appropriate codec will be issued? I will appreciate any clarification on this issues. br, Martin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 10:48:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWef-0001vb-F0; Thu, 18 Oct 2007 10:47:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWec-0001tu-Qh for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 10:47:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWeb-0001su-Ui for sip@ietf.org; Thu, 18 Oct 2007 10:47:17 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiWeb-0004wG-IP for sip@ietf.org; Thu, 18 Oct 2007 10:47:17 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 10:47:17 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 10:47:17 -0400 From: Hadriel Kaplan To: Michael Procter Date: Thu, 18 Oct 2007 10:47:15 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgRXrYgbraXHVdGSvOOsguRIsHQQwACImAgAAtMebA= Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Michael Procter [mailto:michael.procter@citel.com] > Sent: Thursday, October 18, 2007 5:33 AM > To: Dean Willis; Hadriel Kaplan > Cc: sip; Paul Kyzivat; Brian Stucker; Francois Audet; Christer Holmberg > Subject: RE: [Sip] INFO > > Dean Willis wrote: > > The only argument I can see is -- it prevents race conditions. Don't > > send an event until the ACK. > > That sounds like the media clipping problem. If the INVITE indicates > willingness to receive a specific event, then maybe it should be able to > do so before it has seen the 200 response. Then the UAS needn't wait > for the ACK before sending events. Actually, I think it the other way - if there were no such thing as media b= efore 200ok/ACK, there wouldn't be an early media problem. So I think the = INFO needs to wait for the ACK period, like BYE's do. > > > And I'm still stuck on your last question, which is what > > > application use-case really needs directionality, other than as a > > nit? > > > > Yeah, me too. Or to rephrase, what application needs "I want to > > send . . ." rather than "I understand . . ." > > DTMF? I noticed this problem with RFC2833 negotiation a couple of years > ago. A device wanted to indicate willingness to send RFC2833, but > wasn't able to render received indications. Since SDP describes what > the device can receive, the 'solution' was to fib. Yeah, that was my first response to Dean's question (that DTMF has such a u= se-case), but "fibbing" about it isn't really harmful. You may get extrane= ous INFO, which you just don't render. (just like for 2833) The question i= s if the extra complexity of directionality is worth it or not, and is it n= ecessary to provide in the general negotiation vs. in individual event pack= ages. In other words, if some event package got defined which really neede= d directionality, it could handle that itself with two event names. But if= it would be a common problem it's better for the general solution to handl= e it, IMO. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 11:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWy0-00008I-Sk; Thu, 18 Oct 2007 11:07:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWxy-0008Tr-3c for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 11:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWxx-0008Tb-AX for sip@ietf.org; Thu, 18 Oct 2007 11:07:17 -0400 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 1IiWxv-0005BS-V0 for sip@ietf.org; Thu, 18 Oct 2007 11:07:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,295,1188802800"; d="scan'208";a="24889963" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2007 08:07:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9IF7FSP028717; Thu, 18 Oct 2007 08:07:15 -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 l9IF70xT015528; Thu, 18 Oct 2007 15:07:10 GMT 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.1830); Thu, 18 Oct 2007 11:07:09 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 11:07:09 -0400 Message-ID: <4717769A.8050903@cisco.com> Date: Thu, 18 Oct 2007 11:07:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 15:07:09.0448 (UTC) FILETIME=[8DF62880:01C81198] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--26.315700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2682; t=1192720035; x=1193584035; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=gPvw0CvQJ+julApYeDlu0MecUY7yhGsT5NXcZhbKZP8=; b=tSiNFi6QTU0jp4IVjJQAU5uwOfQc8+J1vupReKs0JHduIzHcfzkW2OiXv/Mb00suGXqmAMmJ wRn+9TNu1jw71nmdtOjsQ8Sdg5m6M8ImAvLqIAzWRPnIZHCghOOMYceu; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip , Michael Procter 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: , Errors-To: sip-bounces@ietf.org THe general case for event packages is that they are asymmetric (unidirectional). It seems to be the infrequent case where it makes sense to support an event in both directions. So making bidirectionality the default seems wrong. Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Michael Procter [mailto:michael.procter@citel.com] >> Sent: Thursday, October 18, 2007 5:33 AM >> To: Dean Willis; Hadriel Kaplan >> Cc: sip; Paul Kyzivat; Brian Stucker; Francois Audet; Christer Holmberg >> Subject: RE: [Sip] INFO >> >> Dean Willis wrote: >>> The only argument I can see is -- it prevents race conditions. Don't >>> send an event until the ACK. >> That sounds like the media clipping problem. If the INVITE indicates >> willingness to receive a specific event, then maybe it should be able to >> do so before it has seen the 200 response. Then the UAS needn't wait >> for the ACK before sending events. > > Actually, I think it the other way - if there were no such thing as media before 200ok/ACK, there wouldn't be an early media problem. So I think the INFO needs to wait for the ACK period, like BYE's do. > > >>>> And I'm still stuck on your last question, which is what >>>> application use-case really needs directionality, other than as a >>> nit? >>> >>> Yeah, me too. Or to rephrase, what application needs "I want to >>> send . . ." rather than "I understand . . ." >> DTMF? I noticed this problem with RFC2833 negotiation a couple of years >> ago. A device wanted to indicate willingness to send RFC2833, but >> wasn't able to render received indications. Since SDP describes what >> the device can receive, the 'solution' was to fib. > > Yeah, that was my first response to Dean's question (that DTMF has such a use-case), but "fibbing" about it isn't really harmful. You may get extraneous INFO, which you just don't render. (just like for 2833) The question is if the extra complexity of directionality is worth it or not, and is it necessary to provide in the general negotiation vs. in individual event packages. In other words, if some event package got defined which really needed directionality, it could handle that itself with two event names. But if it would be a common problem it's better for the general solution to handle it, IMO. > > -hadriel > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 11:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWu3-0002pF-NG; Thu, 18 Oct 2007 11:03:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiWu1-0002lJ-IL for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 11:03:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWu0-0002kP-BF for sip@ietf.org; Thu, 18 Oct 2007 11:03:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiWtz-0005OR-Rz for sip@ietf.org; Thu, 18 Oct 2007 11:03:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,295,1188802800"; d="scan'208";a="537022805" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2007 08:03:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9IF36gX018637; Thu, 18 Oct 2007 08:03:06 -0700 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 l9IF2osj028256; Thu, 18 Oct 2007 15:03:06 GMT 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.1830); Thu, 18 Oct 2007 11:02:59 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 11:02:59 -0400 Message-ID: <471775A0.8080108@cisco.com> Date: Thu, 18 Oct 2007 11:02:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin.Hynar@tietoenator.com Subject: Re: [Sip] Playing media message on unanswered call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 15:02:59.0254 (UTC) FILETIME=[F8D59560:01C81197] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--14.750900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2360; t=1192719786; x=1193583786; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Playing=20media=20message=20on=20unanswered=2 0call |Sender:=20; bh=PmC/cK4o7T3YkIDHRTaVRMilreqFaca224B4MHUwKkw=; b=lK7l2IvMZesA6vbCGFDEROj5HH75JHJ9zYFVsTfuXAoMV7H6vYGe97i1WbFda/mqKy8WTSLs H4V7BPaeiJ0Gl0TRd0eqR6f6HbpGFqwzsgIV1bZH3rjxppsL1NlNe0L7; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: sip-bounces@ietf.org Martin, You left out a few details that are significant: - Does the AS act as a B2BUA for the call? - If so, is it in the media path too (terminating and reoriginating the media), or only in the signaling path? If the AS is in the media path then of course it can originate its own media and send it in that path. But, while it can relay media without actual codec support, it won't be able to originate its own media if it doesn't support the codec selected by UE B. The AS MAY send another 180 with a different answer to the offer that is compatible with its own supported codecs. But to do so legally, it must select a different to-tag in that response. That makes it appear to UE A that the call was forked (which in fact it was). The latter approach should cover all of your cases. It does however depend on UE A properly handling the forking case and making a suitable decision about which media to render. Paul Martin.Hynar@tietoenator.com wrote: > Hello all, > > I am thinking about one problem, consider following message flow: > > 1. UE A sends SIP INVITE message with SDP offer to EU B > 2. On originating call leg there is application server announced about the call. > 3. 180 Ringing message with SDP answer is sent from UE B to UE A (AS is announced that the call is in progress) > 4. Time frame allocated to establish the call passed at AS and the message needs to be played ... > > Can now the AS make use of negotiated media paths and play some "called party not available" message without sending 200 OK message first? > > My assumption here is that media paths are negoiated (UE A claims sendrecv audio channel so it must be prepare to receive media) so AS "can" send this message. > > > Consider also little complication, AS is not able to play media in a codec claimed in the answer. Can AS send another 180 ringing message where the appropriate codec will be issued? > > I will appreciate any clarification on this issues. > > br, Martin > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 11:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXan-0000o1-A6; Thu, 18 Oct 2007 11:47:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiXal-0000m1-Dr for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 11:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXak-0000ko-Kc for sip@ietf.org; Thu, 18 Oct 2007 11:47:22 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiXae-0006Lw-Gq for sip@ietf.org; Thu, 18 Oct 2007 11:47:22 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 11:47:11 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 11:47:11 -0400 From: Hadriel Kaplan To: Christer Holmberg , Dean Willis , Brian Stucker Date: Thu, 18 Oct 2007 11:47:02 -0400 Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgQ7O/h6hEj0G9+SdOGbKQOV7XMiQAfbZYwAArMENA= Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > If the application on the receiving side (or the person your're talking > to) has asked you to send a jpeg, it most likely knows what to do it. > This is similar to when the receiver subscribes to an "jpeg event". The > one sending the jpeg may not know what the receiver is going to do with > it, but the one subscribing to the event knows. But I can have multiple jpegs available: one for a snapshot of me for calle= r-id display, one for my company logo for vendor-id display, one I give out= for a contact/buddy-icon of me, etc. If you subscribe to me with an event= of "jpeg", which jpeg do you want? I don't know which to give you. I wou= ld need to know what you want it for. You need to use distinct event types= to ask/subscribe for, like "caller-id-pic", "company-logo", "buddy-icon". = And since you can subscribe to multiples, I need to tell you which type I'= m giving you a jpeg for. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 12:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXoY-00075d-Sf; Thu, 18 Oct 2007 12:01:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiXoV-0006vc-Kw for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 12:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXoU-0006qe-4s for sip@ietf.org; Thu, 18 Oct 2007 12:01:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiXoN-0006sn-Uz for sip@ietf.org; Thu, 18 Oct 2007 12:01:34 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9IG1JcS016108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Oct 2007 11:01:20 -0500 In-Reply-To: References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! ! < 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E416D68-C608-4628-9C50-933566B4CE4C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 18 Oct 2007 11:01:11 -0500 To: Christer Holmberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On Oct 18, 2007, at 4:48 AM, Christer Holmberg wrote: > > > If the application on the receiving side (or the person your're > talking > to) has asked you to send a jpeg, it most likely knows what to do it. > This is similar to when the receiver subscribes to an "jpeg event". > The > one sending the jpeg may not know what the receiver is going to do > with > it, but the one subscribing to the event knows. > What if the receiving side has asked for jpegs foor two different functionalities in the same dialog? How does it know which treatment to apply to a given jpeg? The answer is: It looks at the event package wrapping the jpeg. Without that function (which INFO doesn't currently have, and that that's what is broken), it just doesn't know. -- 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 18 12:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXvE-0007SH-U5; Thu, 18 Oct 2007 12:08:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiXvC-0007QA-GV for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 12:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXvB-0007OT-EO for sip@ietf.org; Thu, 18 Oct 2007 12:08:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiXv9-0007fU-Vc for sip@ietf.org; Thu, 18 Oct 2007 12:08:29 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9IG8GtS016178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Oct 2007 11:08:18 -0500 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Thu, 18 Oct 2007 11:08:09 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip , Michael Procter 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: , Errors-To: sip-bounces@ietf.org On Oct 18, 2007, at 9:47 AM, Hadriel Kaplan wrote: > >>>> And I'm still stuck on your last question, which is what >>>> application use-case really needs directionality, other than as a >>> nit? >>> >>> Yeah, me too. Or to rephrase, what application needs "I want to >>> send . . ." rather than "I understand . . ." >> >> DTMF? I noticed this problem with RFC2833 negotiation a couple of >> years >> ago. A device wanted to indicate willingness to send RFC2833, but >> wasn't able to render received indications. Since SDP describes what >> the device can receive, the 'solution' was to fib. > > Yeah, that was my first response to Dean's question (that DTMF has > such a use-case), but "fibbing" about it isn't really harmful. You > may get extraneous INFO, which you just don't render. (just like > for 2833) The question is if the extra complexity of > directionality is worth it or not, and is it necessary to provide > in the general negotiation vs. in individual event packages. In > other words, if some event package got defined which really needed > directionality, it could handle that itself with two event names. > But if it would be a common problem it's better for the general > solution to handle it, IMO. I think my point has been missed. Why did the device need to indicate willingness to send 2833 tones? It can't send them unless the other side has indicated willingness to accept them. And, as pointed out, it doesn't have to be able to receive them to be able to send them. -- 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 18 12:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXzZ-0005pc-Mn; Thu, 18 Oct 2007 12:13:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiXzW-0005lU-7G for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 12:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXzV-0005lK-A1 for sip@ietf.org; Thu, 18 Oct 2007 12:12:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiXzP-0007rj-4D for sip@ietf.org; Thu, 18 Oct 2007 12:12:57 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9IGCYWP016220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Oct 2007 11:12:35 -0500 In-Reply-To: <4717769A.8050903@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> <4717769A.8050903@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EF669F8-C178-4500-820D-86BDBF53874F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Thu, 18 Oct 2007 11:12:26 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip , Michael Procter 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: , Errors-To: sip-bounces@ietf.org On Oct 18, 2007, at 10:07 AM, Paul Kyzivat wrote: > THe general case for event packages is that they are asymmetric > (unidirectional). It seems to be the infrequent case where it makes > sense to support an event in both directions. So making > bidirectionality the default seems wrong. > I agree. I didn't mean to suggest bidirectionality. I'm suggesting that all that is really needed is the ability to indicate willingness to receive. Each end offers what it is willing to receive, without saying anything about what it can send. It chooses what to send based on its private knowledge of what it can send intersected with the other sides offer to receive. Is there really a use case that needs more than this? There may well be. I just don't know what it is yet. -- 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 18 12:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiYdB-0000EI-Ev; Thu, 18 Oct 2007 12:53:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiYd8-0000Am-Jz for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 12:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiYd7-00008p-EX for sip@ietf.org; Thu, 18 Oct 2007 12:53:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiYd1-0000gz-A3 for sip@ietf.org; Thu, 18 Oct 2007 12:53:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,296,1188792000"; d="scan'208";a="74286623" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2007 12:53:32 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9IGrV1J001016; Thu, 18 Oct 2007 12:53:31 -0400 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 l9IGr3kV007696; Thu, 18 Oct 2007 16:53:23 GMT 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.1830); Thu, 18 Oct 2007 12:52:56 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 12:52:55 -0400 Message-ID: <47178F6A.20109@cisco.com> Date: Thu, 18 Oct 2007 12:52:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com> <24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B34D@sea02-mxc01.citel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 16:52:55.0411 (UTC) FILETIME=[54734430:01C811A7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--16.963400-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=931; t=1192726412; x=1193590412; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Dean=20Willis=20; bh=hQRaTJm5eyr8kHKb9geZvUXJj7rS/UPscPA7WAlT5u4=; b=AX8RDSmDgZvd+/JgrR8HeVoaFiZ58NwT2PEcR6rIOpEhbqOKvo3o0y4LSG/aAUokrnpJzE+T Q7peocm45fwkerWkxvtRwF+FdkwgS42txT7GMvCeOY0+IlIFTUgwbyhD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip , Michael Procter 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > I think my point has been missed. Why did the device need to indicate > willingness to send 2833 tones? It can't send them unless the other side > has indicated willingness to accept them. And, as pointed out, it > doesn't have to be able to receive them to be able to send them. There are a (growing) number of ways to transmit DTMF information. A particular UA that is interested in receiving DTMF needs nail down a way of doing so. And a UA that is to send DTMF needs to nail down the way(s?) it will be sending it. After the initial invite there needs to be some way for the recipient to decide if a way has been agreed upon. If not, then it still may have the option of sending an explicit subscription. But it needs to know if that is required. If nobody every explicitly confirms that they agree to send DTMF in some agreed upon way then things are messed up. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 13:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZ9d-0001y6-2f; Thu, 18 Oct 2007 13:27:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZ9a-0001wG-4X for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZ9Z-0001r0-8Z for sip@ietf.org; Thu, 18 Oct 2007 13:27:25 -0400 Received: from mail58.messagelabs.com ([193.109.255.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IiZ9L-0001ip-Tp for sip@ietf.org; Thu, 18 Oct 2007 13:27:17 -0400 X-VirusChecked: Checked X-Env-Sender: rayees.khan@digitalk.com X-Msg-Ref: server-12.tower-58.messagelabs.com!1192728420!120379006!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [213.249.130.39] Received: (qmail 29473 invoked from network); 18 Oct 2007 17:27:00 -0000 Received: from mail.digitalk.com (HELO svr-zoe.digitalk.com) (213.249.130.39) by server-12.tower-58.messagelabs.com with SMTP; 18 Oct 2007 17:27:00 -0000 Received: from svr-elmo.digitalk.com (unverified) by svr-zoe.digitalk.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Thu, 18 Oct 2007 18:27:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Playing media message on unanswered call Date: Thu, 18 Oct 2007 18:26:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Playing media message on unanswered call Thread-Index: AcgRlRDWNQr115kMRkizEHK5Y/IoawAFieeA From: "Rayees Khan" To: , X-Spam-Score: -4.0 (----) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Errors-To: sip-bounces@ietf.org The AS can play media straightway only if it is in the media path and it supports the negotiated codec.=20 In other case, AS needs to change the media path/capabilities. One of the ways to do that is use UPDATE method, though this would work only if the UA supports UPDATE. regards -----Original Message----- From: Martin.Hynar@tietoenator.com [mailto:Martin.Hynar@tietoenator.com] Sent: Thursday, October 18, 2007 3:42 PM To: sip@ietf.org Subject: [Sip] Playing media message on unanswered call Hello all, I am thinking about one problem, consider following message flow: 1. UE A sends SIP INVITE message with SDP offer to EU B 2. On originating call leg there is application server announced about the call. 3. 180 Ringing message with SDP answer is sent from UE B to UE A (AS is announced that the call is in progress) 4. Time frame allocated to establish the call passed at AS and the message needs to be played ... Can now the AS make use of negotiated media paths and play some "called party not available" message without sending 200 OK message first? My assumption here is that media paths are negoiated (UE A claims sendrecv audio channel so it must be prepare to receive media) so AS "can" send this message. Consider also little complication, AS is not able to play media in a codec claimed in the answer. Can AS send another 180 ringing message where the appropriate codec will be issued? I will appreciate any clarification on this issues. br, Martin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ---------------------------------------------------------------------------= ------- IMPORTANT The information contained in this e-mail and any attachments is intended only for the named recipient and may be privileged or confidential. If you are not the intended recipient, please notify us immediately=20 on +44 (0)1908 425000 and do not disclose, copy, distribute=20 or take any action based on the contents of this e-mail.=20 You should understand and accept that, when communicating with us by e-mail, it is not a totally secure communication medium. We accept no liability for any direct, indirect or consequential loss arising from any action taken in reliance on the information contained in this e-mail and give no warranty or representation as to its accuracy or reliability. DIGITALK has the facility to monitor and read both incoming and outgoing communications by e-mail. In line with industry efforts to reduce the proliferation of un-solicited SPAM, DIGITALK uses=20 methods and ban-lists to prevent malicious content reaching our users. This message and any attachments has been scanned for known viruses. However, we would advise you to ensure the content is indeed virus free. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or breach of confidentiality in relation to transmissions sent by e-mail. VAT No: GB 876 3287 81. Reg No: 3080801 Place of Registration: England Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes ---------------------------------------------------------------------------= -------" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 13:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCE-0004V5-HY; Thu, 18 Oct 2007 13:30:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZCC-0004SC-2C for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:30:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCB-0004RF-81 for sip@ietf.org; Thu, 18 Oct 2007 13:30:07 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZC9-00024F-SU for sip@ietf.org; Thu, 18 Oct 2007 13:30:07 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHU158010415; Thu, 18 Oct 2007 10:30:01 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHTnVb004252; Thu, 18 Oct 2007 10:30:00 -0700 Received: from 172.24.29.145 ([172.24.29.145]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 17:29:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 11:04:42 -0400 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPP4ok3YzPZtPuQNq/ugL66xKBEwCWKvuM In-Reply-To: <4713862A.30003@cisco.com> Mime-version: 1.0 x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: , Content-Type: multipart/mixed; boundary="===============1878944797==" Errors-To: sip-bounces@ietf.org --===============1878944797== Content-type: multipart/alternative; boundary="B_3275558992_3842854" --B_3275558992_3842854 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Is it the gateway is doing DTMF -> H.245 mapping, or is it just for doing compressed codec transport? On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: > > > > Eric Burger wrote: >> > A few times I have seen a comment stating the endpoint interested in >> > potentially receiving DTMF notifications may not know whether or not it >> > needs DTMF. As such, the endpoint would be forced to always issue a >> > SUBSCRIBE, even if it will not be interested in DTMF. >> > >> > Could someone please describe a scenario in which the endpoint does NOT >> > KNOW, a'priori, it will be interested in DTMF? >> > >> > All the ones I can think of, like supplemental dial digits, ACD, register >> > recall, and return to application are all known to the AS or Proxy driving >> > the interaction. >> > >> > What else is out there? > > I think I have heard that SIP-H.323 GWs fall into this category. > > (As well as gateways to some other more proprietary protocols that shall > remain unnamed here.) > > Paul > >> > On 10/10/07 12:20 PM, "Christer Holmberg" >> > wrote: >> > >>> >> Hi, >>> >> >>>>> >>>> Ignorning the reason why people are using INFO is not going >>>>> >>>> to make things better either... >>>>> >>>> >>>>> >>>> I think most people are aware of KPML etc - we don't need to >>>>> >>>> tell them that. >>>> >>> I seriously don't think people are using INFO because they think it's >>>> >>> better than KPML. >>>> >>> I think peopled use to use INFO because (a) they implemented it before >>>> >>> RFC 2833, and (b) because it was difficult for them to implement >>>> >>> RFC 2833 when it got implemented and (c) KPML didn't exist at that >>>> time. >>> >> (d) they think it's a waste of resources to establish multiple additional >>> >> subscription dialogs (there may be other type of data than DTMF they are >>> >> willing to receive) which in many cases may not even be used during the >>> call >>> >> (it can not be assumed that the one sending the subscription always knows >>> >> exactly when it will receive events). Maybe DTMF is not the best example in >>> >> the world (my fault - I should have been more generic), but I am sure >>> there >>> >> could be events which would not be used in a very high percentage of all >>> >> calls, but still the additional subscription dialog(s) would have to be >>> >> established - just in case. >>> >> >>> >> I still strongly think it would be much better to describe the >>> >> issues/advantages/disadvantages with BOTH INFO and events, and study what >>> >> possible needs to defined related to negotiation etc, instead of just >>> ignoring >>> >> the real world and providing flexibility to people using SIP for their >>> >> applications... >>> >> >>> >> Regards, >>> >> >>> >> Christer >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> I believe at this point, this is an imaginary issue. >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> >> This list is for NEW development of the core SIP Protocol >>> >> Use sip-implementors@cs.columbia.edu for questions on current sip >>> >> Use sipping@ietf.org for new developments on the application of sip >> > >> > >> > Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --B_3275558992_3842854 Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7bit Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Is it the gateway is doing DTMF -> H.245 mapping, or is it just for doing compressed codec transport?


On 10/15/07 8:24 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:




Eric Burger wrote:
> A few times I have seen a comment stating the endpoint interested in
> potentially receiving DTMF notifications may not know whether or not it
> needs DTMF. As such, the endpoint would be forced to always issue a
> SUBSCRIBE, even if it will not be interested in DTMF.
>
> Could someone please describe a scenario in which the endpoint does NOT
> KNOW, a'priori, it will be interested in DTMF?
>
> All the ones I can think of, like supplemental dial digits, ACD, register
> recall, and return to application are all known to the AS or Proxy driving
> the interaction.
>
> What else is out there?

I think I have heard that SIP-H.323 GWs fall into this category.

(As well as gateways to some other more proprietary protocols that shall
remain unnamed here.)

        Paul

> On 10/10/07 12:20 PM, "Christer Holmberg" <christer.holmberg@ericsson.com>
> wrote:
>
>> Hi,
>>
>>>> Ignorning the reason why people are using INFO is not going
>>>> to make things better either...
>>>>
>>>> I think most people are aware of KPML etc - we don't need to
>>>> tell them that.
>>> I seriously don't think people are using INFO because they think it's
>>> better than KPML.
>>> I think peopled use to use INFO because (a) they implemented it before
>>> RFC 2833, and (b) because it was difficult for them to implement
>>> RFC 2833 when it got implemented and (c) KPML didn't exist at that time.
>> (d) they think it's a waste of resources to establish multiple additional
>> subscription dialogs (there may be other type of data than DTMF they are
>> willing to receive) which in many cases may not even be used during the call
>> (it can not be assumed that the one sending the subscription always knows
>> exactly when it will receive events). Maybe DTMF is not the best example in
>> the world (my fault - I should have been more generic), but I am sure there
>> could be events which would not be used in a very high percentage of all
>> calls, but still the additional subscription dialog(s) would have to be
>> established - just in case.
>>
>> I still strongly think it would be much better to describe the
>> issues/advantages/disadvantages with BOTH INFO and events, and study what
>> possible needs to defined related to negotiation etc, instead of just ignoring
>> the real world and providing flexibility to people using SIP for their
>> applications...
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I believe at this point, this is an imaginary issue.
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
> Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --B_3275558992_3842854-- --===============1878944797== 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 --===============1878944797==-- From sip-bounces@ietf.org Thu Oct 18 13:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCU-0004vz-0P; Thu, 18 Oct 2007 13:30:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZCS-0004ul-CS for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCR-0004uA-Jk for sip@ietf.org; Thu, 18 Oct 2007 13:30:23 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiZCK-0001oU-Lt for sip@ietf.org; Thu, 18 Oct 2007 13:30:23 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHU3EW010752; Thu, 18 Oct 2007 10:30:03 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHTnVd004252; Thu, 18 Oct 2007 10:30:02 -0700 Received: from 172.24.29.145 ([172.24.29.145]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 17:29:56 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 11:16:46 -0400 Subject: Re: [Sip] INFO From: Eric Burger To: Brian Stucker , Dean Willis Message-ID: Thread-Topic: [Sip] INFO Thread-Index: AcgPVzOIDQso0MFiR6K/lh5Go7j7OgAALCagAJCAXzY= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip , Fran=?ISO-8859-1?B?5w==?=ois Audet , "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: , Errors-To: sip-bounces@ietf.org Got it in 1! Tagging the message with the context, also known as event in 3265 parlance, fixes the INFO application routing / context problem. I was one of the first to say we could fix INFO. In fact, I started revising Dean's draft of almost 5 years ago before I realized I was totally recreating SUBSCRIBE/NOTIFY. In particular, the requesting party MUST do something that looks like a SUBSCRIBE, outside of the INVITE? Why? Because the call will fail if the particular reporting, like DTMF, is no supported. If the argument is reporting DTMF is a rare occurrence for, e.g., H.323 gateways, then failing a call to the H.323 gateway from a SIP Phone is not a desirable feature. The reason I decided not to go on that route is at best you save 2 messages (the instant NOTIFY and 200 OK) over using 3265. At that point, might as well use 3265. That said, I suppose, we could offer a "fast start" 3265. [If this has shades of H.323...] In this scenario the fact you advertise support or acceptance of particular INFO-packages is enough to enable a sender to send appropriately tagged INFO's to you. Of course, if one of those INFO's fails, then I will bet 75% of the implementations will tear down the call. 25% will leave the call up and RTP port open forever. I would also offer we give this mechanism a new method name, as it will NOT be backwards-compatible with INFO. On 10/15/07 11:26 AM, "Brian Stucker" wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: >> >>> Right: "DTMF may not be the only information users want to send to >>> each other during a session." This is why one MUST >> establish multiple >>> subscription dialogs. How else would one keep track of the >> different >>> elements / local routing decisions? If you are proposing >> application >>> routing a'la P-Asserted-Service... >>> >> >> One of the arguments for INFO is that it happens in a dialog, >> not a session. That is, even if you have multiple event >> streams, they happen on the same dialog. >> >> The trick is demuxing the event streams, or in other words, >> figuring out the context for each event. INFO currently gives >> us nothing but the content- modifiers to figure this out. >> That's not enough, as has widely been argued. > > How does 3265 make this any better? > > We're talking about identifying a data blob using an event plus a > content-type instead of a supported plus a content-type for a period of > time to start and end in conjunction with the INVITE dialog (so the > subsciption-state header is mooted). > > So a NOTIFY with an event header or an INFO without an event header, all > other things being the same and the constrained semantics of the NOTIFY > usage being put forward here... > > Wouldn't it be equally valid to simply allow the INFO message to carry > an event header and say that INFO is the same as a NOTIFY with an > implicit subscription to an INVITE dialog? Isn't this pretty much what > it does already (minus the event header). > > Deep thought: Is all INFO is missing is simply the event header? > > Regards, > Brian > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 13:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCL-0004ja-Ls; Thu, 18 Oct 2007 13:30:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZCH-0004bt-4B for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:30:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZCF-0004XI-UA for sip@ietf.org; Thu, 18 Oct 2007 13:30:11 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZCF-00024c-6m for sip@ietf.org; Thu, 18 Oct 2007 13:30:11 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHU6r9010826; Thu, 18 Oct 2007 10:30:06 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IHTnVh004252; Thu, 18 Oct 2007 10:30:05 -0700 Received: from 172.24.29.145 ([172.24.29.145]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 17:29:58 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 11:21:04 -0400 From: Eric Burger To: Hadriel Kaplan , Christer Holmberg Message-ID: Thread-Topic: Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgGj+H+as8V1uACTdamWS27UHhNngADmFpAARYdxpAAFxqtoAAA8Q80APKhriYAC5BgcACSs2+1 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List Subject: [Sip] Re: Unsolicited NOTIFY/INFO versus Solicited State Update 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: , Errors-To: sip-bounces@ietf.org If the other end does not do 2833, than anything we do here is NOT going to work. This is because the other end will have to be modified to do whatever we decide to do here (like INFO packages). At that point, it could do 2833. In fact, if the argument is how to support low power / low capability devices, I would offer 2833 is insanely easier than anything in the SIP layer. On 10/15/07 12:21 PM, "Hadriel Kaplan" wrote: >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: Monday, October 15, 2007 7:49 AM >> To: Christer Holmberg; Hadriel Kaplan >> Cc: IETF SIP List >> Subject: Unsolicited NOTIFY/INFO versus Solicited State Update >> >> A few times I have seen a comment stating the endpoint interested in >> potentially receiving DTMF notifications may not know whether or not it >> needs DTMF. As such, the endpoint would be forced to always issue a >> SUBSCRIBE, even if it will not be interested in DTMF. >> >> Could someone please describe a scenario in which the endpoint does NOT >> KNOW, a'priori, it will be interested in DTMF? >> >> All the ones I can think of, like supplemental dial digits, ACD, register >> recall, and return to application are all known to the AS or Proxy driving >> the interaction. >> >> What else is out there? > > A PSTN gateway has no idea what the PSTN-side call goes to or came from. It > may or may not need DTMF. That PSTN GW has to subscribe for every call if it > (or the other end) doesn't do 2833, regardless if any DTMF get pressed. The > same for a SIP-H.323 gateway, a Skype-SIP gateway, etc. (for H.323 in > particular the probability of 2833 support is very low) > > And even for a SIP AS that knows it needs DTMF, for some applications a KPML > model will be more efficient than INFO, for others less... much less. > > -hadriel > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 13:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZUB-0000oX-D1; Thu, 18 Oct 2007 13:48:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZU9-0000ic-Dj for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 13:48:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZU8-0000cs-Cu for sip@ietf.org; Thu, 18 Oct 2007 13:48:40 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiZU5-0002fW-MP for sip@ietf.org; Thu, 18 Oct 2007 13:48:38 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9IHmYh02867; Thu, 18 Oct 2007 17:48:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Thu, 18 Oct 2007 12:48:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgPVzOIDQso0MFiR6K/lh5Go7j7OgAALCagAJCAXzYABOILwA== References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Eric Burger" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: sip , Francois Audet , "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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Thursday, October 18, 2007 10:17 AM > To: Stucker, Brian (RICH1:AR00); Dean Willis > Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois=20 > (SC100:3055); Hadriel Kaplan > Subject: Re: [Sip] INFO >=20 > Got it in 1! Tagging the message with the context, also=20 > known as event in > 3265 parlance, fixes the INFO application routing / context=20 > problem. I was one of the first to say we could fix INFO. =20 > In fact, I started revising Dean's draft of almost 5 years=20 > ago before I realized I was totally recreating SUBSCRIBE/NOTIFY. >=20 > In particular, the requesting party MUST do something that=20 > looks like a SUBSCRIBE, outside of the INVITE? Why? Because=20 > the call will fail if the particular reporting, like DTMF, is=20 > no supported. If the argument is reporting DTMF is a rare=20 > occurrence for, e.g., H.323 gateways, then failing a call to=20 > the H.323 gateway from a SIP Phone is not a desirable feature. It doesn't *have* to fail. You can define different levels of requirement for something. I think this is being a bit too harsh. >=20 > The reason I decided not to go on that route is at best you=20 > save 2 messages (the instant NOTIFY and 200 OK) over using=20 > 3265. At that point, might as well use 3265. Actually, You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE anymore: http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01 You can suppress the auto-NOTIFY to your SUBSCRIBE, but the implication here is that you can't SUBSCRIBE (safely) until you have at least an early dialog or you otherwise know that the subscription isn't going to fork because you won't get NOTIFYs back from forked dialogs that you can 481. Again, seems complex to do something outside of the INVITE itself even if it's not the most flexible mechanism. Regards, Brian >=20 >=20 > That said, I suppose, we could offer a "fast start" 3265. =20 > [If this has shades of H.323...] In this scenario the fact=20 > you advertise support or acceptance of particular=20 > INFO-packages is enough to enable a sender to send=20 > appropriately tagged INFO's to you. This is going to be super-confusing I think to people. Just use NOTIFY if it looks, acts, and smells like NOTIFY. >=20 > Of course, if one of those INFO's fails, then I will bet 75%=20 > of the implementations will tear down the call. 25% will=20 > leave the call up and RTP port open forever. If your implementation is that broken what we do about INFO doesn't seem relevant to increasing or decreasing the stability of the software. >=20 > I would also offer we give this mechanism a new method name,=20 > as it will NOT be backwards-compatible with INFO. >=20 >=20 > On 10/15/07 11:26 AM, "Brian Stucker" wrote: >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: > >>=20 > >>> Right: "DTMF may not be the only information users want=20 > to send to=20 > >>> each other during a session." This is why one MUST > >> establish multiple > >>> subscription dialogs. How else would one keep track of the > >> different > >>> elements / local routing decisions? If you are proposing > >> application > >>> routing a'la P-Asserted-Service... > >>>=20 > >>=20 > >> One of the arguments for INFO is that it happens in a=20 > dialog, not a=20 > >> session. That is, even if you have multiple event streams, they=20 > >> happen on the same dialog. > >>=20 > >> The trick is demuxing the event streams, or in other=20 > words, figuring=20 > >> out the context for each event. INFO currently gives us=20 > nothing but=20 > >> the content- modifiers to figure this out. > >> That's not enough, as has widely been argued. > >=20 > > How does 3265 make this any better? > >=20 > > We're talking about identifying a data blob using an event plus a=20 > > content-type instead of a supported plus a content-type for=20 > a period=20 > > of time to start and end in conjunction with the INVITE=20 > dialog (so the=20 > > subsciption-state header is mooted). > >=20 > > So a NOTIFY with an event header or an INFO without an=20 > event header,=20 > > all other things being the same and the constrained=20 > semantics of the=20 > > NOTIFY usage being put forward here... > >=20 > > Wouldn't it be equally valid to simply allow the INFO=20 > message to carry=20 > > an event header and say that INFO is the same as a NOTIFY with an=20 > > implicit subscription to an INVITE dialog? Isn't this=20 > pretty much what=20 > > it does already (minus the event header). > >=20 > > Deep thought: Is all INFO is missing is simply the event header? > >=20 > > Regards, > > Brian > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 18 14:16:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZqe-0000vx-Tp; Thu, 18 Oct 2007 14:11:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiZqc-0000v9-Re for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 14:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiZqc-0000uz-3b for sip@ietf.org; Thu, 18 Oct 2007 14:11:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiZqa-0003Ad-Rb for sip@ietf.org; Thu, 18 Oct 2007 14:11:54 -0400 X-IronPort-AV: E=Sophos;i="4.21,296,1188792000"; d="scan'208";a="74294130" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2007 14:11:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9IIBqUt008898; Thu, 18 Oct 2007 14:11:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9IIBqkB008112; Thu, 18 Oct 2007 18:11:52 GMT 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.1830); Thu, 18 Oct 2007 14:11:51 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 14:11:51 -0400 Message-ID: <4717A1E8.3020107@cisco.com> Date: Thu, 18 Oct 2007 14:11:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 18:11:51.0076 (UTC) FILETIME=[5B206640:01C811B2] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--28.824400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5300; t=1192731112; x=1193595112; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Unsolicited=20NOTIFY/INFO=20versus=20Solicite d=20State=20Update |Sender:=20 |To:=20Eric=20Burger=20; bh=Gc/JCbi6zDghiQvI1D9oW4E5XUSdfB0Zn4e6SzTHVaE=; b=VPUSmvsLJrlGzG1vHR8UxMqeOR1Z+uy3nJVFMuqGGDkGU2D7V3f91oMO70L3XNvxsMt2LDF6 pVP3tgX6i6limJqX27U56tO95dw06r3slyFOydyhJo/fAWzuaKb/scQT; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > Is it the gateway is doing DTMF -> H.245 mapping, or is it just for > doing compressed codec transport? I know next to nothing about H.323. My understanding is that it thinks DTMF must travel in the signaling path for H.323, and I gather that means using H.245. Paul > On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: > > > > > Eric Burger wrote: > > A few times I have seen a comment stating the endpoint interested in > > potentially receiving DTMF notifications may not know whether or > not it > > needs DTMF. As such, the endpoint would be forced to always issue a > > SUBSCRIBE, even if it will not be interested in DTMF. > > > > Could someone please describe a scenario in which the endpoint > does NOT > > KNOW, a'priori, it will be interested in DTMF? > > > > All the ones I can think of, like supplemental dial digits, ACD, > register > > recall, and return to application are all known to the AS or Proxy > driving > > the interaction. > > > > What else is out there? > > I think I have heard that SIP-H.323 GWs fall into this category. > > (As well as gateways to some other more proprietary protocols that shall > remain unnamed here.) > > Paul > > > On 10/10/07 12:20 PM, "Christer Holmberg" > > > wrote: > > > > > Hi, > > > > > >>> Ignorning the reason why people are using INFO is not going > > >>> to make things better either... > > >>> > > >>> I think most people are aware of KPML etc - we don't need to > > >>> tell them that. > > >> I seriously don't think people are using INFO because they think > it's > > >> better than KPML. > > >> I think peopled use to use INFO because (a) they implemented it > before > > >> RFC 2833, and (b) because it was difficult for them to implement > > >> RFC 2833 when it got implemented and (c) KPML didn't exist at > that time. > > > (d) they think it's a waste of resources to establish multiple > additional > > > subscription dialogs (there may be other type of data than DTMF > they are > > > willing to receive) which in many cases may not even be used > during the call > > > (it can not be assumed that the one sending the subscription > always knows > > > exactly when it will receive events). Maybe DTMF is not the best > example in > > > the world (my fault - I should have been more generic), but I am > sure there > > > could be events which would not be used in a very high percentage > of all > > > calls, but still the additional subscription dialog(s) would have > to be > > > established - just in case. > > > > > > I still strongly think it would be much better to describe the > > > issues/advantages/disadvantages with BOTH INFO and events, and > study what > > > possible needs to defined related to negotiation etc, instead of > just ignoring > > > the real world and providing flexibility to people using SIP for > their > > > applications... > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe at this point, this is an imaginary issue. > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries and > affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 14:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iia1b-0003r6-3p; Thu, 18 Oct 2007 14:23:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iia1Y-0003oT-UP for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 14:23:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iia1X-0003mE-VN for sip@ietf.org; Thu, 18 Oct 2007 14:23:12 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iia1X-0003wR-1I for sip@ietf.org; Thu, 18 Oct 2007 14:23:11 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IIN9F3022274; Thu, 18 Oct 2007 11:23:09 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IIN01J022717; Thu, 18 Oct 2007 11:23:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Date: Thu, 18 Oct 2007 11:23:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgRsmE8TYWUrYAgTvaEG4TxK44OFAAAYxxq From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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: , Errors-To: sip-bounces@ietf.org Correct, but only really for the purposes of signaling. Remember, in the context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on the SIP side, it is a boat anchor. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. ----- Original Message ----- From: Paul Kyzivat To: Eric Burger Cc: IETF SIP List Sent: Thu Oct 18 11:11:52 2007 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Eric Burger wrote: > Is it the gateway is doing DTMF -> H.245 mapping, or is it just for > doing compressed codec transport? I know next to nothing about H.323. My understanding is that it thinks DTMF must travel in the signaling path for H.323, and I gather that means using H.245. Paul > On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: > > > > > Eric Burger wrote: > > A few times I have seen a comment stating the endpoint interested in > > potentially receiving DTMF notifications may not know whether or > not it > > needs DTMF. As such, the endpoint would be forced to always issue a > > SUBSCRIBE, even if it will not be interested in DTMF. > > > > Could someone please describe a scenario in which the endpoint > does NOT > > KNOW, a'priori, it will be interested in DTMF? > > > > All the ones I can think of, like supplemental dial digits, ACD, > register > > recall, and return to application are all known to the AS or Proxy > driving > > the interaction. > > > > What else is out there? > > I think I have heard that SIP-H.323 GWs fall into this category. > > (As well as gateways to some other more proprietary protocols that shall > remain unnamed here.) > > Paul > > > On 10/10/07 12:20 PM, "Christer Holmberg" > > > wrote: > > > > > Hi, > > > > > >>> Ignorning the reason why people are using INFO is not going > > >>> to make things better either... > > >>> > > >>> I think most people are aware of KPML etc - we don't need to > > >>> tell them that. > > >> I seriously don't think people are using INFO because they think > it's > > >> better than KPML. > > >> I think peopled use to use INFO because (a) they implemented it > before > > >> RFC 2833, and (b) because it was difficult for them to implement > > >> RFC 2833 when it got implemented and (c) KPML didn't exist at > that time. > > > (d) they think it's a waste of resources to establish multiple > additional > > > subscription dialogs (there may be other type of data than DTMF > they are > > > willing to receive) which in many cases may not even be used > during the call > > > (it can not be assumed that the one sending the subscription > always knows > > > exactly when it will receive events). Maybe DTMF is not the best > example in > > > the world (my fault - I should have been more generic), but I am > sure there > > > could be events which would not be used in a very high percentage > of all > > > calls, but still the additional subscription dialog(s) would have > to be > > > established - just in case. > > > > > > I still strongly think it would be much better to describe the > > > issues/advantages/disadvantages with BOTH INFO and events, and > study what > > > possible needs to defined related to negotiation etc, instead of > just ignoring > > > the real world and providing flexibility to people using SIP for > their > > > applications... > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe at this point, this is an imaginary issue. > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries and > affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 14:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiaAZ-0000K8-Ep; Thu, 18 Oct 2007 14:32:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiaAX-0000Ic-HG for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 14:32:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiaAW-0000IK-Eo for sip@ietf.org; Thu, 18 Oct 2007 14:32:28 -0400 Received: from server104.appriver.com ([207.97.242.49] helo=outbound.appriver.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiaAU-0004Rs-VB for sip@ietf.org; Thu, 18 Oct 2007 14:32:28 -0400 Received: by outbound.appriver.com (CommuniGate Pro PIPE 5.1.12) with PIPE id 11712749; Thu, 18 Oct 2007 14:32:33 -0400 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by outbound.appriver.com (CommuniGate Pro SMTP 5.1.12) with SMTP id 11712742; Thu, 18 Oct 2007 14:32:29 -0400 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.1.15.47) with SMTP id M2007101814322129829 ; Thu, 18 Oct 2007 14:32:21 -0400 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Oct 2007 14:32:21 -0400 Message-ID: <6E9C6C7D27E3714190801A551BE37610075980DB@server507.bur.ibasis.net> From: Manpreet Singh To: Eric Burger , pkyzivat@cisco.com Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Date: Thu, 18 Oct 2007 14:32:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: msingh@ibasis.net X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->UNITED STATES->UNITED STATES X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Note: User Rule Hits: X-Note: Global Rule Hits: 70 71 117 X-Note: Mail Class: VALID X-Spam-Score: 0.0 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 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: , Content-Type: multipart/mixed; boundary="===============0958319899==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0958319899== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C811B5.3822A90C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C811B5.3822A90C Content-Type: text/plain RFC 2833 on the SIP side can be easily converted to h245 out of band signaling on H323 side for dtmf. I believe some vendors do it. Its pretty much out of band in media plane to out of band in signaling plane. Thanks -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Thursday, October 18, 2007 2:23 PM To: pkyzivat@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Correct, but only really for the purposes of signaling. Remember, in the context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on the SIP side, it is a boat anchor. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. ----- Original Message ----- From: Paul Kyzivat To: Eric Burger Cc: IETF SIP List Sent: Thu Oct 18 11:11:52 2007 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Eric Burger wrote: > Is it the gateway is doing DTMF -> H.245 mapping, or is it just for > doing compressed codec transport? I know next to nothing about H.323. My understanding is that it thinks DTMF must travel in the signaling path for H.323, and I gather that means using H.245. Paul > On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: > > > > > Eric Burger wrote: > > A few times I have seen a comment stating the endpoint interested in > > potentially receiving DTMF notifications may not know whether or > not it > > needs DTMF. As such, the endpoint would be forced to always issue a > > SUBSCRIBE, even if it will not be interested in DTMF. > > > > Could someone please describe a scenario in which the endpoint > does NOT > > KNOW, a'priori, it will be interested in DTMF? > > > > All the ones I can think of, like supplemental dial digits, ACD, > register > > recall, and return to application are all known to the AS or Proxy > driving > > the interaction. > > > > What else is out there? > > I think I have heard that SIP-H.323 GWs fall into this category. > > (As well as gateways to some other more proprietary protocols that shall > remain unnamed here.) > > Paul > > > On 10/10/07 12:20 PM, "Christer Holmberg" > > > wrote: > > > > > Hi, > > > > > >>> Ignorning the reason why people are using INFO is not going > > >>> to make things better either... > > >>> > > >>> I think most people are aware of KPML etc - we don't need to > > >>> tell them that. > > >> I seriously don't think people are using INFO because they think > it's > > >> better than KPML. > > >> I think peopled use to use INFO because (a) they implemented it > before > > >> RFC 2833, and (b) because it was difficult for them to implement > > >> RFC 2833 when it got implemented and (c) KPML didn't exist at > that time. > > > (d) they think it's a waste of resources to establish multiple > additional > > > subscription dialogs (there may be other type of data than DTMF > they are > > > willing to receive) which in many cases may not even be used > during the call > > > (it can not be assumed that the one sending the subscription > always knows > > > exactly when it will receive events). Maybe DTMF is not the best > example in > > > the world (my fault - I should have been more generic), but I am > sure there > > > could be events which would not be used in a very high percentage > of all > > > calls, but still the additional subscription dialog(s) would have > to be > > > established - just in case. > > > > > > I still strongly think it would be much better to describe the > > > issues/advantages/disadvantages with BOTH INFO and events, and > study what > > > possible needs to defined related to negotiation etc, instead of > just ignoring > > > the real world and providing flexibility to people using SIP for > their > > > applications... > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe at this point, this is an imaginary issue. > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries and > affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for > the use of the individual or entity named in this message. If you > are not the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not the > intended recipient, and have received this message in error, please > immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C811B5.3822A90C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State = Update

RFC 2833 on the SIP side can be easily converted to = h245 out of band signaling on H323 side for dtmf. I believe some = vendors do it. Its pretty much out of band in media plane to out of = band in signaling plane.

Thanks 

-----Original Message-----
From: Eric Burger [mailto:eburger@bea.com]
Sent: Thursday, October 18, 2007 2:23 PM
To: pkyzivat@cisco.com
Cc: sip@ietf.org
Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus = Solicited State Update

Correct, but only really for the purposes of = signaling. Remember, in the context of SIP, it is H.323 on the other = side. If it cannot take RFC2833 on the SIP side, it is a boat = anchor.

--
Sent from my wireless e-mail device. Sorry if = terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> = for what lemonade is.

----- Original Message -----
From: Paul Kyzivat <pkyzivat@cisco.com>
To: Eric Burger
Cc: IETF SIP List <sip@ietf.org>
Sent: Thu Oct 18 11:11:52 2007
Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus = Solicited State Update



Eric Burger wrote:
> Is it the gateway is doing DTMF -> H.245 = mapping, or is it just for
> doing compressed codec transport?

I know next to nothing about H.323. My understanding = is that it thinks DTMF must travel in the signaling path for H.323, and = I gather that means using H.245.

        Paul

> On 10/15/07 8:24 AM, "Paul Kyzivat" = <pkyzivat@cisco.com> wrote:
>
>
>
>
>     Eric Burger = wrote:
>     >  A few times = I have seen a comment stating the endpoint interested in
>     >  potentially = receiving DTMF notifications may not know whether or
>     not it
>     >  needs DTMF. = As such, the endpoint would be forced to always issue a
>     >  SUBSCRIBE, = even if it will not be interested in DTMF.
>     >
>     >  Could = someone please describe a scenario in which the endpoint
>     does NOT
>     >  KNOW, = a'priori, it will be interested in DTMF?
>     >
>     >  All the ones = I can think of, like supplemental dial digits, ACD,
>     register
>     >  recall, and = return to application are all known to the AS or Proxy
>     driving
>     >  the = interaction.
>     >
>     >  What else is = out there?
>
>     I think I have heard = that SIP-H.323 GWs fall into this category.
>
>     (As well as gateways to = some other more proprietary protocols that shall
>     remain unnamed = here.)
>
>          = ;   Paul
>
>     >  On 10/10/07 = 12:20 PM, "Christer Holmberg"
>     = <christer.holmberg@ericsson.com>
>     >  = wrote:
>     >
>     > > Hi,
>     > >
>     > >>> = Ignorning the reason why people are using INFO is not going
>     > >>> to = make things better either...
>     > = >>>
>     > >>> I = think most people are aware of KPML etc - we don't need to
>     > >>> tell = them that.
>     > >> I = seriously don't think people are using INFO because they think
>     it's
>     > >> better = than KPML.
>     > >> I think = peopled use to use INFO because (a) they implemented it
>     before
>     > >> RFC 2833, = and (b) because it was difficult for them to implement
>     > >> RFC 2833 = when it got implemented and (c) KPML didn't exist at
>     that time.
>     > > (d) they = think it's a waste of resources to establish multiple
>     additional
>     > > subscription = dialogs (there may be other type of data than DTMF
>     they are
>     > > willing to = receive) which in many cases may not even be used
>     during the call
>     > > (it can not = be assumed that the one sending the subscription
>     always knows
>     > > exactly when = it will receive events). Maybe DTMF is not the best
>     example in
>     > > the world (my = fault - I should have been more generic), but I am
>     sure there
>     > > could be = events which would not be used in a very high percentage
>     of all
>     > > calls, but = still the additional subscription dialog(s) would have
>     to be
>     > > established - = just in case.
>     > >
>     > > I still = strongly think it would be much better to describe the
>     > > = issues/advantages/disadvantages with BOTH INFO and events, and
>     study what
>     > > possible = needs to defined related to negotiation etc, instead of
>     just ignoring
>     > > the real = world and providing flexibility to people using SIP for
>     their
>     > > = applications...
>     > >
>     > > = Regards,
>     > >
>     > > = Christer
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > I believe at = this point, this is an imaginary issue.
>     > >
>     > >
>     > >
>     > > = _______________________________________________
>     > > Sip mailing = list  https://www1.ietf.org/mailman/listinfo/sip
>     > > This list is = for NEW development of the core SIP Protocol
>     > > Use = sip-implementors@cs.columbia.edu for questions on current sip
>     > > Use = sipping@ietf.org for new developments on the application of sip
>     >
>     >
>     >  = Notice:  This email message, together with any attachments, = may
>     contain = information  of  BEA Systems,  Inc.,  its = subsidiaries  and
>      affiliated = entities,  that may be confidential,  proprietary,
>      copyrighted  = and/or legally privileged, and is intended solely for
>     the use of the = individual or entity named in this message. If you
>     are not the intended = recipient, and have received this message in
>     error, please = immediately return this by email and then delete it.
>     >
>     >
>     >  = _______________________________________________
>     >  Sip mailing = list  https://www1.ietf.org/mailman/listinfo/sip
>     >  This list is = for NEW development of the core SIP Protocol
>     >  Use = sip-implementors@cs.columbia.edu for questions on current sip
>     >  Use = sipping@ietf.org for new developments on the application of sip
>     >
>
>
>
> Notice: This email message, together with any = attachments, may contain
> information of BEA Systems, Inc., its = subsidiaries and affiliated
> entities, that may be confidential, = proprietary, copyrighted and/or
> legally privileged, and is intended solely for = the use of the
> individual or entity named in this message. If = you are not the
> intended recipient, and have received this = message in error, please
> immediately return this by email and then = delete it.

Notice:  This email message, together with any = attachments, may contain information  of  BEA Systems,  = Inc.,  its subsidiaries  and  affiliated entities,  = that may be confidential,  proprietary,  copyrighted  = and/or legally privileged, and is intended solely for the use of the = individual or entity named in this message. If you are not the intended = recipient, and have received this message in error, please immediately = return this by email and then delete it.


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

------_=_NextPart_001_01C811B5.3822A90C-- --===============0958319899== 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 --===============0958319899==-- From sip-bounces@ietf.org Thu Oct 18 15:28:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiayx-0005tV-OU; Thu, 18 Oct 2007 15:24:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiayv-0005tG-AW for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 15:24:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiayu-0005st-DX for sip@ietf.org; Thu, 18 Oct 2007 15:24:32 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiayu-0006IM-3f for sip@ietf.org; Thu, 18 Oct 2007 15:24:32 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 15:24:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 15:24:31 -0400 From: Hadriel Kaplan To: Eric Burger , Jeroen van Bemmel Date: Thu, 18 Oct 2007 15:24:29 -0400 Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPXJ8N44xdGPwJTaecPpT/+WU0VwCPYP1RAAgOmgA= Message-ID: References: <4713B6FD.504@zonnet.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: sip-bounces@ietf.org How does the number of seats matter? Without a single button being pushed, KPML needs a Sub/200/Notify/200 to cr= eate the subscription, and a Notify/200 to tear it down. 6 messages. The call needed an Invite/1xx/200/ACK and then Bye/200. 6 Messages. Both create state for a dialog. So basically we're talking about DOUBLE the number of messages and state, w= ithout a button even being pressed. Now I know I'm not counting all the me= ssages for REFER transfers, which are popular in call-centers, but call-tra= nsfers need new KPML subscribes too. -hadriel > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Thursday, October 18, 2007 11:18 AM > To: Jeroen van Bemmel > Cc: IETF SIP List > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > I would buy the efficiency argument if we were talking about 100,000 seat > call centers. However, even for a 10,000 seat call center, we are talkin= g > about a pretty trivial number of messages compared to the total > interaction. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 16:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iic1J-0004SZ-Db; Thu, 18 Oct 2007 16:31:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iic1I-0004S5-1V for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 16:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iic1G-0004Ol-Vk for sip@ietf.org; Thu, 18 Oct 2007 16:31:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iic1A-00082r-Kz for sip@ietf.org; Thu, 18 Oct 2007 16:31:02 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2318A20975; Thu, 18 Oct 2007 22:30:46 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-0e-4717c276677e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F1061208AB; Thu, 18 Oct 2007 22:30:45 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 22:30:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 18 Oct 2007 22:30:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgRiEwCym90RvPNTwiA6o6UDBk/9AAO5xBm References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com>< 8F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> <4717580A.8010001@c isco.com > From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 18 Oct 2007 20:30:45.0413 (UTC) FILETIME=[C2C74D50:01C811C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: IETF SIP List , Francois Audet , Brian Stucker , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org Hi, >>>> Let's say we have something (not DTMF) that needs to transport jpg >>>> images that are used as soft-key overlays. To do what you're >>>> suggesting, we'd need a new MIME-type registration that says "This = is > >>>> just like jpeg, except that it is only useful for keypad overlays". >>>> The MIME folks would birth kittens. >>> I think you may have misunderstood my example here. I'm postulating >>> that you don't change the MIME type (jpeg) you change the supported/ >>> required header value. >> >> I think that conflicts with the way Supported and Require >> work. They both purely say "Can support these options at any >> time", not "I expect you to use this particular option's >> handling for this particular message" >> >> Let's say you support jpeg for image-mapped touch screen and >> jpeg for storing in my pone book and displaying with caller >> ID. You'd indicate support for both in "Supported" and would >> not reject a request with Require for both. >> >> I send you a jpeg. How do I tell you whether to put it on >> your screen as an image map or store it in your phone book? > > If the application on the receiving side (or the person your're = talking > to) has asked you to send a jpeg, it most likely knows what to do it. > This is similar to when the receiver subscribes to an "jpeg event". = The > one sending the jpeg may not know what the receiver is going to do = with > it, but the one subscribing to the event knows. >In pretty much all the cases under discussion it is not a matter of >asking a specific question that has one answer, and the mechanisms = under >discussion are not equipped for that. Rather it is a matter of >expressing an interest in being notified of a class of things if and >when they happen or come available. I am not objecting to that. >And in Dean's case an interest has been expressed in events serving two >purposes: touch screen maps and caller pictures. It just happens that >both are represented by the same data type. I agree to that also. But, even in the subscription case it is not the = SIP core protocol which indicates what to do with the data - it's the = event type, or some information element within the event. Regards, Christer =20 =20 Paul > If you send a jpeg just "out of the blue", you may not know what the > receiver is going to do with it. The receiving end may prompt the user > what to do, it may do something by default, etc. That is an > implementation issue - not a SIP protocol issue. SIP is simply used to > transport the jpeg. That is the whole purpose of INFO - sending data > which is not related to the SIP session itself. > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 16:45:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicDn-0004Q3-Au; Thu, 18 Oct 2007 16:43:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IicDl-0004NR-He for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 16:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicDk-0004Mi-LB for sip@ietf.org; Thu, 18 Oct 2007 16:43:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IicDg-0008Pq-53 for sip@ietf.org; Thu, 18 Oct 2007 16:43:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ACF71209A5; Thu, 18 Oct 2007 22:43:46 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-84-4717c5820619 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8002220778; Thu, 18 Oct 2007 22:43:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 22:43:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Date: Thu, 18 Oct 2007 22:43:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we arguing about when we say INFO? (was Re: [Sip] INFO) Thread-Index: AcgRoCFBJBN/hH5uQK6179EW5JkupAAJiGe9 References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116DFF008@zrc2hxm2.corp.nortel.com><46F7D719.2070004@nostrum.com><0a5401c8005c$a80fad10$800101df@acmepacket.com><46FAA68A.1090408@nostrum.com><0af301c8007c$94d37590$800101df@acmepacket.com><46FAC69C.4070402@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8169@zrc2hxm2.corp.nortel.com><46FAE230.1070807@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA437116FF8412@zrc2hxm2.corp.nortel.com><46FBAD3D.3090109@nostrum.com><46FBBA78.7070903@nostrum.com><200709271439.l8REd4LE030665@dragon.ariadne.com><46FBD4C0.30601@nostrum.com><6FC4416DDE56C44DA0AEE67BC7CA4371170F0690@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12325A94@zrc2hxm0.corp.nortel!!.com> !! ! ! ! ! ! ! ! ! < 8 F6 5 D B 2 7-41 E D-42F 3- 97F5-D550C3E72902@softarmor.com><1ECE0EB50388174790F9694F77522CCF1242520C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> <0E416D68-C608-4628-9C50-933566B4CE4C@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 18 Oct 2007 20:43:45.0920 (UTC) FILETIME=[93FF3800:01C811C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List , Francois Audet , "DRAGE, Keith \(Keith\)" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hi, =20 >>If the application on the receiving side (or the person your're=20 >>talking to) has asked you to send a jpeg, it most likely knows what to = do it. >>This is similar to when the receiver subscribes to an "jpeg event".=20 >>The one sending the jpeg may not know what the receiver is going to do = >>with it, but the one subscribing to the event knows. > > >What if the receiving side has asked for jpegs foor two different=20 >functionalities in the same dialog? How does it know which treatment=20 >to apply to a given jpeg? > >The answer is: It looks at the event package wrapping the jpeg.=20 >Without that function (which INFO doesn't currently have, and that=20 >that's what is broken), it just doesn't know. INFO itself is not the problem - INFO simply carries the MIME. The = problem, if there is one (depends on the use-case and what you are = carrying), is that you don't provide enough information in the MIME = (maybe Content-Disposition is not enough etc). NOTIFY doesn't solve this problem either - NOTIFY simply carries the = event package. The what-to-do is defiend by the event package, or by = some information within the event package. One question: do you think there should be a separate event for every = possible way a receiver may process the jpeg? Regards, Christer =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 18 17:09:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicYP-0008E7-LT; Thu, 18 Oct 2007 17:05:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IicYN-0008DV-6V for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 17:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicYM-0008DM-Eh for sip@ietf.org; Thu, 18 Oct 2007 17:05:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IicYD-0000ea-JU for sip@ietf.org; Thu, 18 Oct 2007 17:05:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 133452023C; Thu, 18 Oct 2007 23:05:00 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-9c-4717ca7c471c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00FB7201A9; Thu, 18 Oct 2007 23:05:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 23:04:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Thu, 18 Oct 2007 23:04:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgRXT2pje27cJkUSPWuKU/G6kGoOQANf6PgAA2TSyk= References: <1ECE0EB50388174790F9694F77522CCF1282A94C@zrc2hxm0.corp.nortel.com><47154456.4050300@cisco.com><47164904.8020100@cisco.com> <47167C0E.70006@cisco.com><3EB06150-3F5E-4667-B808-9B582ABBCE5D@softarmor.com><24F7A660-58B5-42CB-9DE4-8279EAA0C3F8@softarmor.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Dean Willis" X-OriginalArrivalTime: 18 Oct 2007 21:04:59.0394 (UTC) FILETIME=[8B0BEE20:01C811CA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: sip-bounces@ietf.org Hi, =20 >> Why does there need to be a 3-way exchange? >> Can the 200-ok have Events listed that weren't offered? (why would >> it bother to? The offerer didn't say it could do them.) >> So isn't the ACK always a mirror image of the 200ok, in which case >> why bother? >> Unless you had competing Event types, where only one should be >> used, or couldn't do some combo of them. And then this concept is >> getting bloated, and will end up looking like SDP capabilities >> negotiation. >> > >The only argument I can see is -- it prevents race conditions. Don't >send an event until the ACK. >We could just define that no INFO (or NOTIFY if that be the method) can = be sent until the ACK, regardless. Like BYEs. I guess the ACK could also be PRACK, because I don't think we want to = prevent INTIFY (it's shorter than "INFO or NOTIFY" :) before 200 OK. Regarding the race condition, I guess the problem is in the backward = direction. In the forward direction it's not a problem, once the calling = party has received the response. Regards, Christer=20 =20 =20 =20 -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 17:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicjO-0006UB-CF; Thu, 18 Oct 2007 17:16:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IicjM-0006SO-7A for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 17:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IicjL-0006Qf-18 for sip@ietf.org; Thu, 18 Oct 2007 17:16:35 -0400 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 1Iicj4-00012g-Kn for sip@ietf.org; Thu, 18 Oct 2007 17:16:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,297,1188802800"; d="scan'208";a="25055789" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2007 14:16:18 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ILGItq018741; Thu, 18 Oct 2007 14:16:18 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9ILFtsr017966; Thu, 18 Oct 2007 21:16:17 GMT 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.1830); Thu, 18 Oct 2007 17:16:03 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:16:02 -0400 Message-ID: <4717CD10.3040600@cisco.com> Date: Thu, 18 Oct 2007 17:16:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 21:16:02.0967 (UTC) FILETIME=[16912270:01C811CC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--32.960200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6858; t=1192742178; x=1193606178; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Unsolicited=20NOTIFY/INFO=20versus=20Solicite d=20State=20Update |Sender:=20; bh=+OPN7/pO5OrNW+9n5yKnzUHDKAxwmFWSI5mZjA1X6bc=; b=bKG1v1gEaZ88g1zfFNRnmLfn8QJoWeIeloLWjv7c7XKenT90guQcYC0QNDaPWICAWJa711RB bHho7nnWbujKgBeiI11qHlVeRHdwvTKrTP95oSsaZbu+xHqpUWiDVwzhCW3RE+ISFLWAbsOlNB xGykydileYyipJ7tqVmQcA1PM=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > Correct, but only really for the purposes of signaling. Remember, in the context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on the SIP side, it is a boat anchor. I'm out of my element here, but its my *impression* that it can come to a decision whether the gw must terminate the media or not. If it can use out of band dtmf on the sip side, and map it to H.245 on the other side, then it may be able to avoid terminating the media, which could save resources for other purposes. Paul > Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. > > ----- Original Message ----- > From: Paul Kyzivat > To: Eric Burger > Cc: IETF SIP List > Sent: Thu Oct 18 11:11:52 2007 > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > > > Eric Burger wrote: >> Is it the gateway is doing DTMF -> H.245 mapping, or is it just for >> doing compressed codec transport? > > I know next to nothing about H.323. My understanding is that it thinks > DTMF must travel in the signaling path for H.323, and I gather that > means using H.245. > > Paul > >> On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: >> >> >> >> >> Eric Burger wrote: >> > A few times I have seen a comment stating the endpoint interested in >> > potentially receiving DTMF notifications may not know whether or >> not it >> > needs DTMF. As such, the endpoint would be forced to always issue a >> > SUBSCRIBE, even if it will not be interested in DTMF. >> > >> > Could someone please describe a scenario in which the endpoint >> does NOT >> > KNOW, a'priori, it will be interested in DTMF? >> > >> > All the ones I can think of, like supplemental dial digits, ACD, >> register >> > recall, and return to application are all known to the AS or Proxy >> driving >> > the interaction. >> > >> > What else is out there? >> >> I think I have heard that SIP-H.323 GWs fall into this category. >> >> (As well as gateways to some other more proprietary protocols that shall >> remain unnamed here.) >> >> Paul >> >> > On 10/10/07 12:20 PM, "Christer Holmberg" >> >> > wrote: >> > >> > > Hi, >> > > >> > >>> Ignorning the reason why people are using INFO is not going >> > >>> to make things better either... >> > >>> >> > >>> I think most people are aware of KPML etc - we don't need to >> > >>> tell them that. >> > >> I seriously don't think people are using INFO because they think >> it's >> > >> better than KPML. >> > >> I think peopled use to use INFO because (a) they implemented it >> before >> > >> RFC 2833, and (b) because it was difficult for them to implement >> > >> RFC 2833 when it got implemented and (c) KPML didn't exist at >> that time. >> > > (d) they think it's a waste of resources to establish multiple >> additional >> > > subscription dialogs (there may be other type of data than DTMF >> they are >> > > willing to receive) which in many cases may not even be used >> during the call >> > > (it can not be assumed that the one sending the subscription >> always knows >> > > exactly when it will receive events). Maybe DTMF is not the best >> example in >> > > the world (my fault - I should have been more generic), but I am >> sure there >> > > could be events which would not be used in a very high percentage >> of all >> > > calls, but still the additional subscription dialog(s) would have >> to be >> > > established - just in case. >> > > >> > > I still strongly think it would be much better to describe the >> > > issues/advantages/disadvantages with BOTH INFO and events, and >> study what >> > > possible needs to defined related to negotiation etc, instead of >> just ignoring >> > > the real world and providing flexibility to people using SIP for >> their >> > > applications... >> > > >> > > Regards, >> > > >> > > Christer >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > I believe at this point, this is an imaginary issue. >> > > >> > > >> > > >> > > _______________________________________________ >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > > This list is for NEW development of the core SIP Protocol >> > > Use sip-implementors@cs.columbia.edu for questions on current sip >> > > Use sipping@ietf.org for new developments on the application of sip >> > >> > >> > Notice: This email message, together with any attachments, may >> contain information of BEA Systems, Inc., its subsidiaries and >> affiliated entities, that may be confidential, proprietary, >> copyrighted and/or legally privileged, and is intended solely for >> the use of the individual or entity named in this message. If you >> are not the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > >> >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual >> or entity named in this message. If you are not the intended recipient, >> and have received this message in error, please immediately return this >> by email and then delete it. > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 17:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicqg-0002Jg-Jr; Thu, 18 Oct 2007 17:24:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iicqe-0002D7-Et for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 17:24:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicqd-00029I-Bb for sip@ietf.org; Thu, 18 Oct 2007 17:24:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iicqc-0001az-Pp for sip@ietf.org; Thu, 18 Oct 2007 17:24:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,297,1188802800"; d="scan'208";a="537200302" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2007 14:24:05 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ILO50N014384; Thu, 18 Oct 2007 17:24:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9ILNO8d020581; Thu, 18 Oct 2007 21:24:04 GMT 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.1830); Thu, 18 Oct 2007 17:23:39 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:23:39 -0400 Message-ID: <4717CED7.4010702@cisco.com> Date: Thu, 18 Oct 2007 17:23:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip] INFO) References: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D59@zrc2hxm2.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1266D01A@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF126BD0B2@zrc2hxm0.corp.nortel.com> <38CF40C2-19E8-4C83-9B66-DDC2862F1724@softarmor.com> <5D1A7985295922448D5550C94DE29180017E16E9@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12747724@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1291DC2A@zrc2hxm0.corp.nortel.com> <690341E0-593E-40ED-B6DD-C23C86AF9EE6@softarmor.com> <0E416D68-C608-4628-9C50-933566B4CE4C@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 21:23:39.0087 (UTC) FILETIME=[266F85F0:01C811CD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--24.267200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2484; t=1192742645; x=1193606645; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20What=20are=20we=20arguing=20about=20when=20we=20say=2 0INFO?=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20 |To:=20Christer=20Holmberg=20; bh=xleDw4HlRoGPC31pilTJHCYtJP8RNtoJt/n2RYXcoSs=; b=KNO2k0ElD+3GQBNMt61KXbOC4LVaKVhwiKiIEX9lt+WB2h1aUprBCjkbg4lpdK63I58J+Eps 381+ebmzovzYpz+mhWPVxf7k3Q9fjz2qoCiVVK/tf1fmQXcVOavOII8o; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List , Francois Audet , Brian Stucker , "DRAGE, Keith \(Keith\)" , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>> If the application on the receiving side (or the person your're >>> talking to) has asked you to send a jpeg, it most likely knows what to do it. >>> This is similar to when the receiver subscribes to an "jpeg event". >>> The one sending the jpeg may not know what the receiver is going to do >>> with it, but the one subscribing to the event knows. >> >> What if the receiving side has asked for jpegs foor two different >> functionalities in the same dialog? How does it know which treatment >> to apply to a given jpeg? >> >> The answer is: It looks at the event package wrapping the jpeg. >> Without that function (which INFO doesn't currently have, and that >> that's what is broken), it just doesn't know. > > INFO itself is not the problem - INFO simply carries the MIME. The problem, if there is one (depends on the use-case and what you are carrying), is that you don't provide enough information in the MIME (maybe Content-Disposition is not enough etc). > > NOTIFY doesn't solve this problem either - NOTIFY simply carries the event package. The what-to-do is defiend by the event package, or by some information within the event package. > > One question: do you think there should be a separate event for every possible way a receiver may process the jpeg? If there are different possible uses, and there is reason why the sender and the receiver need to agree on the use, then yes. If the different uses are strictly a matter of local preference, then no. In the case at hand, it may be that I just send you jpegs. If I happen to send one that is my picture, you will (perhaps) recognize it as me and decide to put it in your address book. And if I happen to send you a key map then maybe you will install it on your touch screen phone. If that is my only expectation, then fine. But if I expect that when I send you a jpeg of a key map that it will automatically be installed on your phone for the remaining duration of our call, then it is important that your device understand that. Paul > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 17:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidKr-00089b-T8; Thu, 18 Oct 2007 17:55:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IidKq-00089W-Du for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 17:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidKp-00089D-HQ for sip@ietf.org; Thu, 18 Oct 2007 17:55:19 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidJD-0002TG-7g for sip@ietf.org; Thu, 18 Oct 2007 17:55:19 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9ILrUbl008379; Thu, 18 Oct 2007 14:53:30 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9ILrNtO026872; Thu, 18 Oct 2007 14:53:29 -0700 Received: from 172.24.28.204 ([172.24.28.204]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 21:53:27 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 16:02:13 -0400 Subject: Re: [Sip] INFO From: Eric Burger To: Brian Stucker Message-ID: Thread-Topic: [Sip] INFO Thread-Index: AcgPVzOIDQso0MFiR6K/lh5Go7j7OgAALCagAJCAXzYABOILwAAFFhSy In-Reply-To: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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: , Errors-To: sip-bounces@ietf.org Missing the point. If, for some reason, a NOTIFY gets a, for example, 410 response (instead of 200 OK), the *subscription* dialog terminates. If an INFO gets a 410, the *call dialog* terminates. Probably not the behavior people expect. On 10/18/07 1:48 PM, "Brian Stucker" wrote: >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: Thursday, October 18, 2007 10:17 AM >> To: Stucker, Brian (RICH1:AR00); Dean Willis >> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois >> (SC100:3055); Hadriel Kaplan >> Subject: Re: [Sip] INFO >> >> Got it in 1! Tagging the message with the context, also >> known as event in >> 3265 parlance, fixes the INFO application routing / context >> problem. I was one of the first to say we could fix INFO. >> In fact, I started revising Dean's draft of almost 5 years >> ago before I realized I was totally recreating SUBSCRIBE/NOTIFY. >> >> In particular, the requesting party MUST do something that >> looks like a SUBSCRIBE, outside of the INVITE? Why? Because >> the call will fail if the particular reporting, like DTMF, is >> no supported. If the argument is reporting DTMF is a rare >> occurrence for, e.g., H.323 gateways, then failing a call to >> the H.323 gateway from a SIP Phone is not a desirable feature. > > It doesn't *have* to fail. You can define different levels of > requirement for something. I think this is being a bit too harsh. > >> >> The reason I decided not to go on that route is at best you >> save 2 messages (the instant NOTIFY and 200 OK) over using >> 3265. At that point, might as well use 3265. > > Actually, > > You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE > anymore: > > http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01 > > You can suppress the auto-NOTIFY to your SUBSCRIBE, but the implication > here is that you can't SUBSCRIBE (safely) until you have at least an > early dialog or you otherwise know that the subscription isn't going to > fork because you won't get NOTIFYs back from forked dialogs that you can > 481. > > Again, seems complex to do something outside of the INVITE itself even > if it's not the most flexible mechanism. > > Regards, > Brian > >> >> >> That said, I suppose, we could offer a "fast start" 3265. >> [If this has shades of H.323...] In this scenario the fact >> you advertise support or acceptance of particular >> INFO-packages is enough to enable a sender to send >> appropriately tagged INFO's to you. > > This is going to be super-confusing I think to people. Just use NOTIFY > if it looks, acts, and smells like NOTIFY. > >> >> Of course, if one of those INFO's fails, then I will bet 75% >> of the implementations will tear down the call. 25% will >> leave the call up and RTP port open forever. > > If your implementation is that broken what we do about INFO doesn't seem > relevant to increasing or decreasing the stability of the software. > >> >> I would also offer we give this mechanism a new method name, >> as it will NOT be backwards-compatible with INFO. >> >> >> On 10/15/07 11:26 AM, "Brian Stucker" wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>>> On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: >>>> >>>>> Right: "DTMF may not be the only information users want >> to send to >>>>> each other during a session." This is why one MUST >>>> establish multiple >>>>> subscription dialogs. How else would one keep track of the >>>> different >>>>> elements / local routing decisions? If you are proposing >>>> application >>>>> routing a'la P-Asserted-Service... >>>>> >>>> >>>> One of the arguments for INFO is that it happens in a >> dialog, not a >>>> session. That is, even if you have multiple event streams, they >>>> happen on the same dialog. >>>> >>>> The trick is demuxing the event streams, or in other >> words, figuring >>>> out the context for each event. INFO currently gives us >> nothing but >>>> the content- modifiers to figure this out. >>>> That's not enough, as has widely been argued. >>> >>> How does 3265 make this any better? >>> >>> We're talking about identifying a data blob using an event plus a >>> content-type instead of a supported plus a content-type for >> a period >>> of time to start and end in conjunction with the INVITE >> dialog (so the >>> subsciption-state header is mooted). >>> >>> So a NOTIFY with an event header or an INFO without an >> event header, >>> all other things being the same and the constrained >> semantics of the >>> NOTIFY usage being put forward here... >>> >>> Wouldn't it be equally valid to simply allow the INFO >> message to carry >>> an event header and say that INFO is the same as a NOTIFY with an >>> implicit subscription to an INVITE dialog? Isn't this >> pretty much what >>> it does already (minus the event header). >>> >>> Deep thought: Is all INFO is missing is simply the event header? >>> >>> Regards, >>> Brian >>> >> >> >> >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not >> the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 18:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidSD-0000tl-60; Thu, 18 Oct 2007 18:02:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IidSB-0000r8-8V for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 18:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidSA-0000qc-Lt for sip@ietf.org; Thu, 18 Oct 2007 18:02:54 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidRH-0002om-6t for sip@ietf.org; Thu, 18 Oct 2007 18:02:54 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IM1tEl023477; Thu, 18 Oct 2007 15:01:55 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IM1qZq008278; Thu, 18 Oct 2007 15:01:54 -0700 Received: from 172.24.28.89 ([172.24.28.89]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 22:01:53 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 18:01:45 -0400 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update From: Eric Burger To: Hadriel Kaplan Message-ID: Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPXJ8N44xdGPwJTaecPpT/+WU0VwCPYP1RAAgOmgAABgbiiQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: sip-bounces@ietf.org Ooooooh. That=B9s right. Six messages. Instead of...??? Well? We are not talking about wireless networks here. Baseband networking sends the bits, whether they are being used or not. What I was saying is I would buy the efficiency argument IIF the example is for a network where that matters. I am offering that double the number of messages means we go from 1% utilization to 2%? Who cares? And yes, this is from the chair of lemonade, where we care VERY MUCH about efficiency. However, that is a very different, very limited environment. In fact, so far the only excuse for "not worth doing a proper subscription" has been the H.323 gateway, which clearly will be on the broadband side of = a wired network. On 10/18/07 3:24 PM, "Hadriel Kaplan" wrote: > How does the number of seats matter? > Without a single button being pushed, KPML needs a Sub/200/Notify/200 to > create the subscription, and a Notify/200 to tear it down. 6 messages. > The call needed an Invite/1xx/200/ACK and then Bye/200. 6 Messages. > Both create state for a dialog. >=20 > So basically we're talking about DOUBLE the number of messages and state, > without a button even being pressed. Now I know I'm not counting all the > messages for REFER transfers, which are popular in call-centers, but > call-transfers need new KPML subscribes too. >=20 > -hadriel >=20 >=20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: Thursday, October 18, 2007 11:18 AM >> To: Jeroen van Bemmel >> Cc: IETF SIP List >> Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update >>=20 >> I would buy the efficiency argument if we were talking about 100,000 sea= t >> call centers. However, even for a 10,000 seat call center, we are talki= ng >> about a pretty trivial number of messages compared to the total >> interaction. >>=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 18:14:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidbL-0002QM-JV; Thu, 18 Oct 2007 18:12:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IidbI-0002OM-Ao for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 18:12:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidbH-0002ND-4Z for sip@ietf.org; Thu, 18 Oct 2007 18:12:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IidbG-0003sM-9d for sip@ietf.org; Thu, 18 Oct 2007 18:12:19 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9IMCFh08865; Thu, 18 Oct 2007 22:12:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Thu, 18 Oct 2007 17:12:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgPVzOIDQso0MFiR6K/lh5Go7j7OgAALCagAJCAXzYABOILwAAFFhSyAARnyDA= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Eric Burger" X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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: , Errors-To: sip-bounces@ietf.org Eric, Where did you find the requirement that a 4xx to an INFO kills the call? I just re-read RFC-2976, there's nothing in there that says anything about an error response to an INFO killing the call dialog at all. Section 2.2: "A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a UAS if the INFO request does not match any existing call leg." (No requirement to kill the call dialog, although it would seem appropriate to do so) "Other request failure (4xx), Server Failure (5xx) and Global Failure (6xx) responses MAY be sent for the INFO Request." (No requirement to kill the call dialog) Sction 2.4: "...the INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP." Regards, Brian > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Thursday, October 18, 2007 3:02 PM > To: Stucker, Brian (RICH1:AR00) > Cc: sip > Subject: Re: [Sip] INFO >=20 > Missing the point. >=20 > If, for some reason, a NOTIFY gets a, for example, 410=20 > response (instead of 200 OK), the *subscription* dialog terminates. >=20 > If an INFO gets a 410, the *call dialog* terminates. >=20 > Probably not the behavior people expect. >=20 >=20 > On 10/18/07 1:48 PM, "Brian Stucker" wrote: >=20 > >> -----Original Message----- > >> From: Eric Burger [mailto:eburger@bea.com] > >> Sent: Thursday, October 18, 2007 10:17 AM > >> To: Stucker, Brian (RICH1:AR00); Dean Willis > >> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois (SC100:3055);=20 > >> Hadriel Kaplan > >> Subject: Re: [Sip] INFO > >>=20 > >> Got it in 1! Tagging the message with the context, also known as=20 > >> event in > >> 3265 parlance, fixes the INFO application routing /=20 > context problem. =20 > >> I was one of the first to say we could fix INFO. > >> In fact, I started revising Dean's draft of almost 5 years=20 > ago before=20 > >> I realized I was totally recreating SUBSCRIBE/NOTIFY. > >>=20 > >> In particular, the requesting party MUST do something that=20 > looks like=20 > >> a SUBSCRIBE, outside of the INVITE? Why? Because the=20 > call will fail=20 > >> if the particular reporting, like DTMF, is no supported. If the=20 > >> argument is reporting DTMF is a rare occurrence for, e.g., H.323=20 > >> gateways, then failing a call to the H.323 gateway from a=20 > SIP Phone=20 > >> is not a desirable feature. > >=20 > > It doesn't *have* to fail. You can define different levels of=20 > > requirement for something. I think this is being a bit too harsh. > >=20 > >>=20 > >> The reason I decided not to go on that route is at best you save 2=20 > >> messages (the instant NOTIFY and 200 OK) over using 3265. At that=20 > >> point, might as well use 3265. > >=20 > > Actually, > >=20 > > You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE > > anymore: > >=20 > > http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01 > >=20 > > You can suppress the auto-NOTIFY to your SUBSCRIBE, but the=20 > > implication here is that you can't SUBSCRIBE (safely) until=20 > you have=20 > > at least an early dialog or you otherwise know that the=20 > subscription=20 > > isn't going to fork because you won't get NOTIFYs back from forked=20 > > dialogs that you can 481. > >=20 > > Again, seems complex to do something outside of the INVITE=20 > itself even=20 > > if it's not the most flexible mechanism. > >=20 > > Regards, > > Brian > >=20 > >>=20 > >>=20 > >> That said, I suppose, we could offer a "fast start" 3265. > >> [If this has shades of H.323...] In this scenario the fact you=20 > >> advertise support or acceptance of particular=20 > INFO-packages is enough=20 > >> to enable a sender to send appropriately tagged INFO's to you. > >=20 > > This is going to be super-confusing I think to people. Just=20 > use NOTIFY=20 > > if it looks, acts, and smells like NOTIFY. > >=20 > >>=20 > >> Of course, if one of those INFO's fails, then I will bet=20 > 75% of the=20 > >> implementations will tear down the call. 25% will leave=20 > the call up=20 > >> and RTP port open forever. > >=20 > > If your implementation is that broken what we do about INFO doesn't=20 > > seem relevant to increasing or decreasing the stability of=20 > the software. > >=20 > >>=20 > >> I would also offer we give this mechanism a new method name, as it=20 > >> will NOT be backwards-compatible with INFO. > >>=20 > >>=20 > >> On 10/15/07 11:26 AM, "Brian Stucker" wrote: > >>=20 > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>>> On Oct 11, 2007, at 4:34 PM, Eric Burger wrote: > >>>>=20 > >>>>> Right: "DTMF may not be the only information users want > >> to send to > >>>>> each other during a session." This is why one MUST > >>>> establish multiple > >>>>> subscription dialogs. How else would one keep track of the > >>>> different > >>>>> elements / local routing decisions? If you are proposing > >>>> application > >>>>> routing a'la P-Asserted-Service... > >>>>>=20 > >>>>=20 > >>>> One of the arguments for INFO is that it happens in a > >> dialog, not a > >>>> session. That is, even if you have multiple event streams, they=20 > >>>> happen on the same dialog. > >>>>=20 > >>>> The trick is demuxing the event streams, or in other > >> words, figuring > >>>> out the context for each event. INFO currently gives us > >> nothing but > >>>> the content- modifiers to figure this out. > >>>> That's not enough, as has widely been argued. > >>>=20 > >>> How does 3265 make this any better? > >>>=20 > >>> We're talking about identifying a data blob using an event plus a=20 > >>> content-type instead of a supported plus a content-type for > >> a period > >>> of time to start and end in conjunction with the INVITE > >> dialog (so the > >>> subsciption-state header is mooted). > >>>=20 > >>> So a NOTIFY with an event header or an INFO without an > >> event header, > >>> all other things being the same and the constrained > >> semantics of the > >>> NOTIFY usage being put forward here... > >>>=20 > >>> Wouldn't it be equally valid to simply allow the INFO > >> message to carry > >>> an event header and say that INFO is the same as a NOTIFY with an=20 > >>> implicit subscription to an INVITE dialog? Isn't this > >> pretty much what > >>> it does already (minus the event header). > >>>=20 > >>> Deep thought: Is all INFO is missing is simply the event header? > >>>=20 > >>> Regards, > >>> Brian > >>>=20 > >>=20 > >>=20 > >>=20 > >> Notice: This email message, together with any attachments, may=20 > >> contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > >> affiliated entities, that may be confidential, proprietary, =20 > >> copyrighted and/or legally privileged, and is intended solely for=20 > >> the use of the individual or entity named in this message.=20 > If you are=20 > >> not the intended recipient, and have received this message=20 > in error,=20 > >> please immediately return this by email and then delete it. > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 18 18:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidnK-0005oa-HH; Thu, 18 Oct 2007 18:24:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IidnI-0005jV-JV for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 18:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidnH-0005ht-JN for sip@ietf.org; Thu, 18 Oct 2007 18:24:43 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidnF-0003rW-V8 for sip@ietf.org; Thu, 18 Oct 2007 18:24:43 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IMObqT003192; Thu, 18 Oct 2007 15:24:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9IMOYcL011409; Thu, 18 Oct 2007 15:24:36 -0700 Received: from 172.24.28.89 ([172.24.28.89]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 22:24:34 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 18:24:30 -0400 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgRzCeAVJUyirz5TNSqforTx+CVqQACX8Nb In-Reply-To: <4717CD10.3040600@cisco.com> Mime-version: 1.0 x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 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: , Content-Type: multipart/mixed; boundary="===============0610491850==" Errors-To: sip-bounces@ietf.org --===============0610491850== Content-type: multipart/alternative; boundary="B_3275576670_4372064" --B_3275576670_4372064 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable That is one whacky gateway. We=B9re not talking about an application here. Sounds like a theoretically interesting problem, but show me the data sheet of such a beast. On 10/18/07 5:16 PM, "Paul Kyzivat" wrote: >=20 >=20 >=20 > Eric Burger wrote: >> > Correct, but only really for the purposes of signaling. Remember, in t= he >> context of SIP, it is H.323 on the other side. If it cannot take RFC2833= on >> the SIP side, it is a boat anchor. >=20 > I'm out of my element here, but its my *impression* that it can come to > a decision whether the gw must terminate the media or not. If it can use > out of band dtmf on the sip side, and map it to H.245 on the other side, > then it may be able to avoid terminating the media, which could save > resources for other purposes. >=20 > Paul >=20 >> > Sent from my wireless e-mail device. Sorry if terse. We all need lemo= nade: >> see for what lemonade is. >> > >> > ----- Original Message ----- >> > From: Paul Kyzivat >> > To: Eric Burger >> > Cc: IETF SIP List >> > Sent: Thu Oct 18 11:11:52 2007 >> > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Upda= te >> > >> > >> > >> > Eric Burger wrote: >>> >> Is it the gateway is doing DTMF -> H.245 mapping, or is it just for >>> >> doing compressed codec transport? >> > >> > I know next to nothing about H.323. My understanding is that it thinks >> > DTMF must travel in the signaling path for H.323, and I gather that >> > means using H.245. >> > >> > Paul >> > >>> >> On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Eric Burger wrote: >>>> >> > A few times I have seen a comment stating the endpoint inter= ested in >>>> >> > potentially receiving DTMF notifications may not know whethe= r or >>> >> not it >>>> >> > needs DTMF. As such, the endpoint would be forced to always = issue a >>>> >> > SUBSCRIBE, even if it will not be interested in DTMF. >>>> >> > >>>> >> > Could someone please describe a scenario in which the endpoi= nt >>> >> does NOT >>>> >> > KNOW, a'priori, it will be interested in DTMF? >>>> >> > >>>> >> > All the ones I can think of, like supplemental dial digits, = ACD, >>> >> register >>>> >> > recall, and return to application are all known to the AS or Proxy >>> >> driving >>>> >> > the interaction. >>>> >> > >>>> >> > What else is out there? >>> >> >>> >> I think I have heard that SIP-H.323 GWs fall into this category. >>> >> >>> >> (As well as gateways to some other more proprietary protocols th= at >>> shall >>> >> remain unnamed here.) >>> >> >>> >> Paul >>> >> >>>> >> > On 10/10/07 12:20 PM, "Christer Holmberg" >>> >> >>>> >> > wrote: >>>> >> > >>>>> >> > > Hi, >>>>> >> > > >>>>>>> >> > >>> Ignorning the reason why people are using INFO is not = going >>>>>>> >> > >>> to make things better either... >>>>>>> >> > >>> >>>>>>> >> > >>> I think most people are aware of KPML etc - we don't n= eed to >>>>>>> >> > >>> tell them that. >>>>>> >> > >> I seriously don't think people are using INFO because th= ey think >>> >> it's >>>>>> >> > >> better than KPML. >>>>>> >> > >> I think peopled use to use INFO because (a) they impleme= nted it >>> >> before >>>>>> >> > >> RFC 2833, and (b) because it was difficult for them to implement >>>>>> >> > >> RFC 2833 when it got implemented and (c) KPML didn't exi= st at >>> >> that time. >>>>> >> > > (d) they think it's a waste of resources to establish mult= iple >>> >> additional >>>>> >> > > subscription dialogs (there may be other type of data than= DTMF >>> >> they are >>>>> >> > > willing to receive) which in many cases may not even be us= ed >>> >> during the call >>>>> >> > > (it can not be assumed that the one sending the subscripti= on >>> >> always knows >>>>> >> > > exactly when it will receive events). Maybe DTMF is not th= e best >>> >> example in >>>>> >> > > the world (my fault - I should have been more generic), bu= t I am >>> >> sure there >>>>> >> > > could be events which would not be used in a very high percentage >>> >> of all >>>>> >> > > calls, but still the additional subscription dialog(s) wou= ld have >>> >> to be >>>>> >> > > established - just in case. >>>>> >> > > >>>>> >> > > I still strongly think it would be much better to describe= the >>>>> >> > > issues/advantages/disadvantages with BOTH INFO and events,= and >>> >> study what >>>>> >> > > possible needs to defined related to negotiation etc, inst= ead of >>> >> just ignoring >>>>> >> > > the real world and providing flexibility to people using S= IP for >>> >> their >>>>> >> > > applications... >>>>> >> > > >>>>> >> > > Regards, >>>>> >> > > >>>>> >> > > Christer >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > I believe at this point, this is an imaginary issue. >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > _______________________________________________ >>>>> >> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/s= ip >>>>> >> > > This list is for NEW development of the core SIP Protocol >>>>> >> > > Use sip-implementors@cs.columbia.edu for questions on curr= ent sip >>>>> >> > > Use sipping@ietf.org for new developments on the applicati= on of sip >>>> >> > >>>> >> > >>>> >> > Notice: This email message, together with any attachments, = may >>> >> contain information of BEA Systems, Inc., its subsidiaries = and >>> >> affiliated entities, that may be confidential, proprietary, >>> >> copyrighted and/or legally privileged, and is intended solely = for >>> >> the use of the individual or entity named in this message. If yo= u >>> >> are not the intended recipient, and have received this message i= n >>> >> error, please immediately return this by email and then delete i= t. >>>> >> > >>>> >> > >>>> >> > _______________________________________________ >>>> >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> >> > This list is for NEW development of the core SIP Protocol >>>> >> > Use sip-implementors@cs.columbia.edu for questions on curren= t sip >>>> >> > Use sipping@ietf.org for new developments on the application= of sip >>>> >> > >>> >> >>> >> >>> >> >>> >> Notice: This email message, together with any attachments, may conta= in >>> >> information of BEA Systems, Inc., its subsidiaries and affiliated >>> >> entities, that may be confidential, proprietary, copyrighted and/or >>> >> legally privileged, and is intended solely for the use of the indivi= dual >>> >> or entity named in this message. If you are not the intended recipie= nt, >>> >> and have received this message in error, please immediately return t= his >>> >> by email and then delete it. >> > >> > Notice: This email message, together with any attachments, may contai= n >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual= or >> entity named in this message. If you are not the intended recipient, and= have >> received this message in error, please immediately return this by email = and >> then delete it. >> > >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. --B_3275576670_4372064 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7bit Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update That is one whacky gateway.  We’re not talking about an application here.  Sounds like a theoretically interesting problem, but show me the data sheet of such a beast.


On 10/18/07 5:16 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:




Eric Burger wrote:
> Correct, but only really for the purposes of signaling. Remember, in the context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on the SIP side, it is a boat anchor.

I'm out of my element here, but its my *impression* that it can come to
a decision whether the gw must terminate the media or not. If it can use
out of band dtmf on the sip side, and map it to H.245 on the other side,
then it may be able to avoid terminating the media, which could save
resources for other purposes.

        Paul

> Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
>
> ----- Original Message -----
> From: Paul Kyzivat <pkyzivat@cisco.com>
> To: Eric Burger
> Cc: IETF SIP List <sip@ietf.org>
> Sent: Thu Oct 18 11:11:52 2007
> Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update
>
>
>
> Eric Burger wrote:
>> Is it the gateway is doing DTMF -> H.245 mapping, or is it just for
>> doing compressed codec transport?
>
> I know next to nothing about H.323. My understanding is that it thinks
> DTMF must travel in the signaling path for H.323, and I gather that
> means using H.245.
>
>       Paul
>
>> On 10/15/07 8:24 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
>>
>>
>>
>>
>>     Eric Burger wrote:
>>     >  A few times I have seen a comment stating the endpoint interested in
>>     >  potentially receiving DTMF notifications may not know whether or
>>     not it
>>     >  needs DTMF. As such, the endpoint would be forced to always issue a
>>     >  SUBSCRIBE, even if it will not be interested in DTMF.
>>     >
>>     >  Could someone please describe a scenario in which the endpoint
>>     does NOT
>>     >  KNOW, a'priori, it will be interested in DTMF?
>>     >
>>     >  All the ones I can think of, like supplemental dial digits, ACD,
>>     register
>>     >  recall, and return to application are all known to the AS or Proxy
>>     driving
>>     >  the interaction.
>>     >
>>     >  What else is out there?
>>
>>     I think I have heard that SIP-H.323 GWs fall into this category.
>>
>>     (As well as gateways to some other more proprietary protocols that shall
>>     remain unnamed here.)
>>
>>             Paul
>>
>>     >  On 10/10/07 12:20 PM, "Christer Holmberg"
>>     <christer.holmberg@ericsson.com>
>>     >  wrote:
>>     >
>>     > > Hi,
>>     > >
>>     > >>> Ignorning the reason why people are using INFO is not going
>>     > >>> to make things better either...
>>     > >>>
>>     > >>> I think most people are aware of KPML etc - we don't need to
>>     > >>> tell them that.
>>     > >> I seriously don't think people are using INFO because they think
>>     it's
>>     > >> better than KPML.
>>     > >> I think peopled use to use INFO because (a) they implemented it
>>     before
>>     > >> RFC 2833, and (b) because it was difficult for them to implement
>>     > >> RFC 2833 when it got implemented and (c) KPML didn't exist at
>>     that time.
>>     > > (d) they think it's a waste of resources to establish multiple
>>     additional
>>     > > subscription dialogs (there may be other type of data than DTMF
>>     they are
>>     > > willing to receive) which in many cases may not even be used
>>     during the call
>>     > > (it can not be assumed that the one sending the subscription
>>     always knows
>>     > > exactly when it will receive events). Maybe DTMF is not the best
>>     example in
>>     > > the world (my fault - I should have been more generic), but I am
>>     sure there
>>     > > could be events which would not be used in a very high percentage
>>     of all
>>     > > calls, but still the additional subscription dialog(s) would have
>>     to be
>>     > > established - just in case.
>>     > >
>>     > > I still strongly think it would be much better to describe the
>>     > > issues/advantages/disadvantages with BOTH INFO and events, and
>>     study what
>>     > > possible needs to defined related to negotiation etc, instead of
>>     just ignoring
>>     > > the real world and providing flexibility to people using SIP for
>>     their
>>     > > applications...
>>     > >
>>     > > Regards,
>>     > >
>>     > > Christer
>>     > >
>>     > >
>>     > >
>>     > >
>>     > >
>>     > >
>>     > >
>>     > >
>>     > >
>>     > > I believe at this point, this is an imaginary issue.
>>     > >
>>     > >
>>     > >
>>     > > _______________________________________________
>>     > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>     > > This list is for NEW development of the core SIP Protocol
>>     > > Use sip-implementors@cs.columbia.edu for questions on current sip
>>     > > Use sipping@ietf.org for new developments on the application of sip
>>     >
>>     >
>>     >  Notice:  This email message, together with any attachments, may
>>     contain information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>      affiliated entities,  that may be confidential,  proprietary,
>>      copyrighted  and/or legally privileged, and is intended solely for
>>     the use of the individual or entity named in this message. If you
>>     are not the intended recipient, and have received this message in
>>     error, please immediately return this by email and then delete it.
>>     >
>>     >
>>     >  _______________________________________________
>>     >  Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>     >  This list is for NEW development of the core SIP Protocol
>>     >  Use sip-implementors@cs.columbia.edu for questions on current sip
>>     >  Use sipping@ietf.org for new developments on the application of sip
>>     >
>>
>>
>>
>> Notice: This email message, together with any attachments, may contain
>> information of BEA Systems, Inc., its subsidiaries and affiliated
>> entities, that may be confidential, proprietary, copyrighted and/or
>> legally privileged, and is intended solely for the use of the individual
>> or entity named in this message. If you are not the intended recipient,
>> and have received this message in error, please immediately return this
>> by email and then delete it.
>
> Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --B_3275576670_4372064-- --===============0610491850== 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 --===============0610491850==-- From sip-bounces@ietf.org Thu Oct 18 19:07:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieNd-000197-Rc; Thu, 18 Oct 2007 19:02:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IieNc-00018l-8M for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 19:02:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieNb-00018U-EP for sip@ietf.org; Thu, 18 Oct 2007 19:02:15 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IieNa-0004yu-Uz for sip@ietf.org; Thu, 18 Oct 2007 19:02:15 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9IN29bh050177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 18:02:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4717E5E9.4070306@nostrum.com> Date: Thu, 18 Oct 2007 18:02:01 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 16:05:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Errors-To: sip-bounces@ietf.org The interaction between errors and dialog termination wasn't crystal clear in 3261; and multiple usages within a dialog makes it even more messy. That's why Robert has poured so much effort into draft-ietf-sipping-dialogusage. It's an incredibly useful document the puts crystal clarity around exactly these kinds of issues. If we had the critical corrections process in place when it was progressing, it would have probably been part of that process. As it is, it forms an important adjunct to 3261. I can't completely back out whether Eric meant to talk about two usages in a single dialog or two different dialogs. In any case, if you get a 410 in response to a request -- including an INFO request -- the whole dialog goes away, including all of its usages (not just the usage the INFO was associated with -- although that's kind of a nebulous concept, since INFO isn't inherently associated with a *usage*, merely with a *dialog*. This is another place where INFO is underspecified; to be fair, though, the concept of usages developed after INFO was published). So, to be clear: if you send an INFO and get any of 404, 410, 416, 482-485, 502, or 604, then the dialog goes away. Period. If INFO causes a 480 or 481, then the INVITE usage goes away. If the INVITE was the last usage in the dialog, then the dialog goes away. /a Brian Stucker wrote: > Eric, > > Where did you find the requirement that a 4xx to an INFO kills the call? > I just re-read RFC-2976, there's nothing in there that says anything > about an error response to an INFO killing the call dialog at all. > > Section 2.2: > > "A 481 Call Leg/Transaction Does Not Exist message MUST be sent by > a UAS if the INFO request does not match any existing call leg." > > (No requirement to kill the call dialog, although it would seem > appropriate to do so) > > > "Other request failure (4xx), Server Failure (5xx) and Global Failure > (6xx) responses MAY be sent for the INFO Request." > > (No requirement to kill the call dialog) > > Sction 2.4: > > "...the INFO message MUST NOT change the state of the SIP call, > or the sessions initiated by SIP." > > Regards, > Brian > > >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: Thursday, October 18, 2007 3:02 PM >> To: Stucker, Brian (RICH1:AR00) >> Cc: sip >> Subject: Re: [Sip] INFO >> >> Missing the point. >> >> If, for some reason, a NOTIFY gets a, for example, 410 >> response (instead of 200 OK), the *subscription* dialog terminates. >> >> If an INFO gets a 410, the *call dialog* terminates. >> >> Probably not the behavior people expect. >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 19:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiedj-0006we-Ny; Thu, 18 Oct 2007 19:18:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiedi-0006w0-Ej for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 19:18:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiedh-0006tE-Gb for sip@ietf.org; Thu, 18 Oct 2007 19:18:53 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiedc-0005L9-5R for sip@ietf.org; Thu, 18 Oct 2007 19:18:48 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 19:18:47 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 19:18:47 -0400 From: Hadriel Kaplan To: Eric Burger Date: Thu, 18 Oct 2007 19:18:46 -0400 Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPXJ8N44xdGPwJTaecPpT/+WU0VwCPYP1RAAgOmgAABgbiiQABSRJQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Thursday, October 18, 2007 6:02 PM > To: Hadriel Kaplan > Cc: IETF SIP List > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > Ooooooh. That=B9s right. Six messages. Instead of...??? Well? You said: "However, even for a 10,000 seat call center, we are talking abou= t a pretty trivial number of messages compared to the total interaction." By "total interaction", I assumed you meant from a SIP signaling perspectiv= e. Doubling the number of SIP messages is more than a "trivial number" com= pared to the total number of SIP messages. Or at least, I wouldn't mind th= at kind of "trivial" increase to my salary. ;) > We are not talking about wireless networks here. Baseband networking send= s > the bits, whether they are being used or not. Absolutely. And we're not talking about IP routers or Ethernet switches ei= ther. I'm talking about SIP servers. You know, those things you say are ancient = concepts: stateful proxies, or app servers, or b2bua's, or PBXs/call-manage= rs, etc. I know not everyone thinks those things should exist. No one's f= orcing them on you. But they do exist. And doubling the number of SIP mes= sages and state has an impact on them... a cost which does not need to be i= ncurred. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 19:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiemo-0005YL-S4; Thu, 18 Oct 2007 19:28:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiemm-0005QJ-8s for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 19:28:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iieml-0005Mj-Cd for sip@ietf.org; Thu, 18 Oct 2007 19:28:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiemk-0005Vn-Oj for sip@ietf.org; Thu, 18 Oct 2007 19:28:15 -0400 X-IronPort-AV: E=Sophos;i="4.21,297,1188802800"; d="scan'208";a="537242674" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2007 16:28:12 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9INSBGc024728; Thu, 18 Oct 2007 19:28:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9INRckV025736; Thu, 18 Oct 2007 23:28:07 GMT 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.1830); Thu, 18 Oct 2007 19:28:04 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 19:28:04 -0400 Message-ID: <4717EC02.2000303@cisco.com> Date: Thu, 18 Oct 2007 19:28:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> In-Reply-To: <4717E5E9.4070306@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 23:28:04.0348 (UTC) FILETIME=[8813F3C0:01C811DE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002 X-TM-AS-Result: No--38.998300-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3453; t=1192750091; x=1193614091; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Adam=20Roach=20; bh=W++VMl4jKEgMnE6EoguPnHilL7Re30p9W7lvyeZkagM=; b=O4pplphrEQ9Xl4ICRAnPdLxLPTaP4w4yPTKPMUZRxjLEEP/28pTPfYIqciRofdz6S/hZOjCY GsuDXnBoLdcsgbZkijmCnsmCpPAFsZx8t3PFs5pQfOvuYMm5O1Niue9s; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org I mostly agree with Adam. The place where I take exception is INFO. It is my impression that INFO was designed for use with INVITE, and so should be considered to be part of an invite-dialog-usage. And Robert specified it that way in the dialogusage draft. Paul Adam Roach wrote: > The interaction between errors and dialog termination wasn't crystal > clear in 3261; and multiple usages within a dialog makes it even more > messy. That's why Robert has poured so much effort into > draft-ietf-sipping-dialogusage. It's an incredibly useful document the > puts crystal clarity around exactly these kinds of issues. If we had the > critical corrections process in place when it was progressing, it would > have probably been part of that process. As it is, it forms an important > adjunct to 3261. > > I can't completely back out whether Eric meant to talk about two usages > in a single dialog or two different dialogs. In any case, if you get a > 410 in response to a request -- including an INFO request -- the whole > dialog goes away, including all of its usages (not just the usage the > INFO was associated with -- although that's kind of a nebulous concept, > since INFO isn't inherently associated with a *usage*, merely with a > *dialog*. This is another place where INFO is underspecified; to be > fair, though, the concept of usages developed after INFO was published). > > So, to be clear: if you send an INFO and get any of 404, 410, 416, > 482-485, 502, or 604, then the dialog goes away. Period. > > If INFO causes a 480 or 481, then the INVITE usage goes away. If the > INVITE was the last usage in the dialog, then the dialog goes away. > > /a > > Brian Stucker wrote: >> Eric, >> >> Where did you find the requirement that a 4xx to an INFO kills the call? >> I just re-read RFC-2976, there's nothing in there that says anything >> about an error response to an INFO killing the call dialog at all. >> >> Section 2.2: >> >> "A 481 Call Leg/Transaction Does Not Exist message MUST be sent by >> a UAS if the INFO request does not match any existing call leg." >> >> (No requirement to kill the call dialog, although it would seem >> appropriate to do so) >> >> >> "Other request failure (4xx), Server Failure (5xx) and Global Failure >> (6xx) responses MAY be sent for the INFO Request." >> >> (No requirement to kill the call dialog) >> >> Sction 2.4: >> >> "...the INFO message MUST NOT change the state of the SIP call, >> or the sessions initiated by SIP." >> >> Regards, >> Brian >> >> >>> -----Original Message----- >>> From: Eric Burger [mailto:eburger@bea.com] Sent: Thursday, October >>> 18, 2007 3:02 PM >>> To: Stucker, Brian (RICH1:AR00) >>> Cc: sip >>> Subject: Re: [Sip] INFO >>> >>> Missing the point. >>> >>> If, for some reason, a NOTIFY gets a, for example, 410 response >>> (instead of 200 OK), the *subscription* dialog terminates. >>> >>> If an INFO gets a 410, the *call dialog* terminates. >>> >>> Probably not the behavior people expect. >>> >>> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 19:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiet2-0001Kn-7c; Thu, 18 Oct 2007 19:34:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiet0-0001IL-TB for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 19:34:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiesz-0001HP-Um for sip@ietf.org; Thu, 18 Oct 2007 19:34:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiesz-0005gX-AS for sip@ietf.org; Thu, 18 Oct 2007 19:34:41 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9INYOK02478; Thu, 18 Oct 2007 23:34:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Thu, 18 Oct 2007 18:34:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF129C8A67@zrc2hxm0.corp.nortel.com> In-Reply-To: <4717E5E9.4070306@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgR2u57lDlHVFXLQSePpJ3jjrKqJQAAkqMA References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> From: "Brian Stucker" To: "Adam Roach" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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: , Errors-To: sip-bounces@ietf.org Duh. I knew I was forgetting something. I wouldn't say 2976 is a bastion example of specificity so I figured it must be coming from somewhere else. However, this usecase seems to also be true of NOTIFY usage within an INVITE dialog in the specific case of a 410 response if I read tables 1/2 correctly from the dialogusage draft.=20 Why are we talking about 410 anyway? I don't think I've ever seen one generated in the wild. It still seems to be boiling down to whether or not you want to force folks to explicitly SUBSCRIBE to usages within the INVITE dialog. If you use a SUBSCRIBE you can support directionality and that's about it. I don't think you get a cleaner idea of whether or not the dialog should exist or not than you have over INFO+event, or an implicit subscription. Even for DTMF digits, if you setup the call, and then made your subscription to KPML or whatever, within the dialog, and got back a 489 it seems somewhat uncertain to me what the correct behavior at the UA should be. If the UA was accessing a service that required SIP signaling level awareness of DTMF digits, it may be perfectly reasonable to kill the call. If it instead assumes 2833 support because 2833 was accepted in the SDP it may continue on with the call but be broken because the thing that needs the digits isn't on the media path, etc. Or if it tried for KPML and 2833 and killed the call because KPML was rejected, the call may have worked fine because the KPML was being rejected in favor of 2833 by a gateway, etc. I just don't see how you can always figure out that the application is broken (especially with something like DTMF which has a couple ways of doing it) and the dialog needs to end from one reporting failure. I can definitely envision cases where you could tell, but I can also come up with usecases (like DTMF) where it's not so clear. Regards, Brian=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Thursday, October 18, 2007 6:02 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Eric Burger; sip > Subject: Re: [Sip] INFO >=20 > The interaction between errors and dialog termination wasn't=20 > crystal clear in 3261; and multiple usages within a dialog=20 > makes it even more messy. That's why Robert has poured so=20 > much effort into draft-ietf-sipping-dialogusage. It's an=20 > incredibly useful document the puts crystal clarity around=20 > exactly these kinds of issues. If we had the critical=20 > corrections process in place when it was progressing, it=20 > would have probably been part of that process. As it is, it=20 > forms an important adjunct to 3261. >=20 > I can't completely back out whether Eric meant to talk about=20 > two usages in a single dialog or two different dialogs. In=20 > any case, if you get a 410 in response to a request --=20 > including an INFO request -- the whole dialog goes away,=20 > including all of its usages (not just the usage the INFO was=20 > associated with -- although that's kind of a nebulous=20 > concept, since INFO isn't inherently associated with a=20 > *usage*, merely with a *dialog*. This is another place where=20 > INFO is underspecified; to be fair, though, the concept of=20 > usages developed after INFO was published). >=20 > So, to be clear: if you send an INFO and get any of 404, 410,=20 > 416, 482-485, 502, or 604, then the dialog goes away. Period. >=20 > If INFO causes a 480 or 481, then the INVITE usage goes away.=20 > If the INVITE was the last usage in the dialog, then the=20 > dialog goes away. >=20 > /a >=20 > Brian Stucker wrote: > > Eric, > > > > Where did you find the requirement that a 4xx to an INFO=20 > kills the call? > > I just re-read RFC-2976, there's nothing in there that says=20 > anything=20 > > about an error response to an INFO killing the call dialog at all. > > > > Section 2.2: > > > > "A 481 Call Leg/Transaction Does Not Exist message=20 > MUST be sent by > > a UAS if the INFO request does not match any existing=20 > call leg." > > > > (No requirement to kill the call dialog, although it would seem=20 > > appropriate to do so) > > > > > > "Other request failure (4xx), Server Failure (5xx) and Global=20 > > Failure > > (6xx) responses MAY be sent for the INFO Request." > > > > (No requirement to kill the call dialog) > > > > Sction 2.4: > > > > "...the INFO message MUST NOT change the state of the=20 > SIP call, or=20 > > the sessions initiated by SIP." > > > > Regards, > > Brian > > > > =20 > >> -----Original Message----- > >> From: Eric Burger [mailto:eburger@bea.com] > >> Sent: Thursday, October 18, 2007 3:02 PM > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: sip > >> Subject: Re: [Sip] INFO > >> > >> Missing the point. > >> > >> If, for some reason, a NOTIFY gets a, for example, 410 response=20 > >> (instead of 200 OK), the *subscription* dialog terminates. > >> > >> If an INFO gets a 410, the *call dialog* terminates. > >> > >> Probably not the behavior people expect. > >> > >> =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 Thu Oct 18 20:09:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IifPT-0006vW-A0; Thu, 18 Oct 2007 20:08:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IifPQ-0006uc-Nn for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 20:08:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IifPP-0006tx-QM for sip@ietf.org; Thu, 18 Oct 2007 20:08:11 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IifPP-0006bO-90 for sip@ietf.org; Thu, 18 Oct 2007 20:08:11 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9J085tl031078; Thu, 18 Oct 2007 17:08:05 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9J084tc020942; Thu, 18 Oct 2007 17:08:04 -0700 Received: from 10.43.242.72 ([10.43.242.72]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Oct 2007 00:08:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 18 Oct 2007 20:07:59 -0400 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update From: Eric Burger To: Hadriel Kaplan Message-ID: Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPXJ8N44xdGPwJTaecPpT/+WU0VwCPYP1RAAgOmgAABgbiiQABSRJQAAMfi7c= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: , Errors-To: sip-bounces@ietf.org >>> a cost which does not need to be incurred. ... Unless you want to make sure you interoperate in all situations, not just your controlled call center. I would offer one could ALWAYS do a much more efficient protocol for a closed environment. We spend a lot of overhead to make sure all the corner cases work. This is one of those corner cases. On 10/18/07 7:18 PM, "Hadriel Kaplan" wrote: >=20 >=20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: Thursday, October 18, 2007 6:02 PM >> To: Hadriel Kaplan >> Cc: IETF SIP List >> Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update >>=20 >> Ooooooh. That=B9s right. Six messages. Instead of...??? Well? >=20 > You said: "However, even for a 10,000 seat call center, we are talking ab= out a > pretty trivial number of messages compared to the total interaction." > By "total interaction", I assumed you meant from a SIP signaling perspect= ive. > Doubling the number of SIP messages is more than a "trivial number" compa= red > to the total number of SIP messages. Or at least, I wouldn't mind that k= ind > of "trivial" increase to my salary. ;) >=20 >=20 >> We are not talking about wireless networks here. Baseband networking sen= ds >> the bits, whether they are being used or not. >=20 > Absolutely. And we're not talking about IP routers or Ethernet switches > either. > I'm talking about SIP servers. You know, those things you say are ancien= t > concepts: stateful proxies, or app servers, or b2bua's, or PBXs/call-mana= gers, > etc. I know not everyone thinks those things should exist. No one's for= cing > them on you. But they do exist. And doubling the number of SIP messages= and > state has an impact on them... a cost which does not need to be incurred. >=20 > -hadriel >=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 18 21:09:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IigIL-0000xs-6C; Thu, 18 Oct 2007 21:04:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IigIJ-0000x0-9v for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 21:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IigII-0000ue-3M for sip@ietf.org; Thu, 18 Oct 2007 21:04:54 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IigI5-0000NO-BQ for sip@ietf.org; Thu, 18 Oct 2007 21:04:51 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 21:04:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 21:04:30 -0400 From: Hadriel Kaplan To: Eric Burger Date: Thu, 18 Oct 2007 21:03:53 -0400 Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgPXJ8N44xdGPwJTaecPpT/+WU0VwCPYP1RAAgOmgAABgbiiQABSRJQAAMfi7cAAO+fQA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > > >>> a cost which does not need to be incurred. > ... Unless you want to make sure you interoperate in all situations, not > just your controlled call center. I don't mean to be flippant, but as far as I can tell INFO-dtmf has had a b= etter track record of interoperability than KPML. At least in the sense of= (a) if you did it and the far-end did it, does it work, and (b) how many d= evices do it. It's an unfair comparison, because it's been around longer, = and at least one very popular vendor had it deployed widely early and docum= ented it on their website and many others were simply forced to do what the= y did to interoperate. Having said that, there is more than one flavor out there, and there is no = negotiation. Both of those issues can be fixed with an RFC. They *are* fi= xed with KPML, but the cost is too high, and the solution too complicated f= or the problem, IMO. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 18 22:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihUe-0006bt-Qn; Thu, 18 Oct 2007 22:21:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IihUa-0006al-Ou for sip-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 22:21:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IihUZ-0006Xq-UQ for sip@ietf.org; Thu, 18 Oct 2007 22:21:40 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IihUU-0001lm-2y for sip@ietf.org; Thu, 18 Oct 2007 22:21:34 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 18 Oct 2007 22:21:33 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 18 Oct 2007 22:21:33 -0400 From: Hadriel Kaplan To: Eric Burger , "pkyzivat@cisco.com" Date: Thu, 18 Oct 2007 22:20:54 -0400 Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Topic: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Thread-Index: AcgRsmE8TYWUrYAgTvaEG4TxK44OFAAAYxxqAARQ4XA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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: , Errors-To: sip-bounces@ietf.org Plenty of IWF devices do SIP-2833 to/from H.245-UII to make DTMF work (AFAI= K, all of them do). That requires media to go through the IWF-box, but tha= t's life today. Of course if there were a SIP signaling path for DTMF, the= n media could go direct. But that's crazy talk. ;) And those same IWF devices also do SIP-INFO to/from H.245-UII, for cases wh= ere the SIP side needs signaling-path DTMF. -hadriel > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Thursday, October 18, 2007 2:23 PM > To: pkyzivat@cisco.com > Cc: sip@ietf.org > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > Correct, but only really for the purposes of signaling. Remember, in the > context of SIP, it is H.323 on the other side. If it cannot take RFC2833 > on the SIP side, it is a boat anchor. > > -- > Sent from my wireless e-mail device. Sorry if terse. We all need > lemonade: see for what > lemonade is. > > ----- Original Message ----- > From: Paul Kyzivat > To: Eric Burger > Cc: IETF SIP List > Sent: Thu Oct 18 11:11:52 2007 > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > > > Eric Burger wrote: > > Is it the gateway is doing DTMF -> H.245 mapping, or is it just for > > doing compressed codec transport? > > I know next to nothing about H.323. My understanding is that it thinks > DTMF must travel in the signaling path for H.323, and I gather that > means using H.245. > > Paul > > > On 10/15/07 8:24 AM, "Paul Kyzivat" wrote: > > > > > > > > > > Eric Burger wrote: > > > A few times I have seen a comment stating the endpoint intereste= d > in > > > potentially receiving DTMF notifications may not know whether or > > not it > > > needs DTMF. As such, the endpoint would be forced to always issu= e > a > > > SUBSCRIBE, even if it will not be interested in DTMF. > > > > > > Could someone please describe a scenario in which the endpoint > > does NOT > > > KNOW, a'priori, it will be interested in DTMF? > > > > > > All the ones I can think of, like supplemental dial digits, ACD, > > register > > > recall, and return to application are all known to the AS or > Proxy > > driving > > > the interaction. > > > > > > What else is out there? > > > > I think I have heard that SIP-H.323 GWs fall into this category. > > > > (As well as gateways to some other more proprietary protocols that > shall > > remain unnamed here.) > > > > Paul > > > > > On 10/10/07 12:20 PM, "Christer Holmberg" > > > > > wrote: > > > > > > > Hi, > > > > > > > >>> Ignorning the reason why people are using INFO is not going > > > >>> to make things better either... > > > >>> > > > >>> I think most people are aware of KPML etc - we don't need to > > > >>> tell them that. > > > >> I seriously don't think people are using INFO because they > think > > it's > > > >> better than KPML. > > > >> I think peopled use to use INFO because (a) they implemented i= t > > before > > > >> RFC 2833, and (b) because it was difficult for them to > implement > > > >> RFC 2833 when it got implemented and (c) KPML didn't exist at > > that time. > > > > (d) they think it's a waste of resources to establish multiple > > additional > > > > subscription dialogs (there may be other type of data than DTMF > > they are > > > > willing to receive) which in many cases may not even be used > > during the call > > > > (it can not be assumed that the one sending the subscription > > always knows > > > > exactly when it will receive events). Maybe DTMF is not the bes= t > > example in > > > > the world (my fault - I should have been more generic), but I a= m > > sure there > > > > could be events which would not be used in a very high > percentage > > of all > > > > calls, but still the additional subscription dialog(s) would > have > > to be > > > > established - just in case. > > > > > > > > I still strongly think it would be much better to describe the > > > > issues/advantages/disadvantages with BOTH INFO and events, and > > study what > > > > possible needs to defined related to negotiation etc, instead o= f > > just ignoring > > > > the real world and providing flexibility to people using SIP fo= r > > their > > > > applications... > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe at this point, this is an imaginary issue. > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current > sip > > > > Use sipping@ietf.org for new developments on the application of > sip > > > > > > > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its subsidiaries and > > affiliated entities, that may be confidential, proprietary, > > copyrighted and/or legally privileged, and is intended solely for > > the use of the individual or entity named in this message. If you > > are not the intended recipient, and have received this message in > > error, please immediately return this by email and then delete it. > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current si= p > > > Use sipping@ietf.org for new developments on the application of > sip > > > > > > > > > > > Notice: This email message, together with any attachments, may contain > > information of BEA Systems, Inc., its subsidiaries and affiliated > > entities, that may be confidential, proprietary, copyrighted and/or > > legally privileged, and is intended solely for the use of the individua= l > > or entity named in this message. If you are not the intended recipient, > > and have received this message in error, please immediately return this > > by email and then delete it. > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this b= y > email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 00:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iijsl-0001Tw-3y; Fri, 19 Oct 2007 00:54:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iijsj-0001To-Rt for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 00:54:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iijsi-0001Rr-MQ for sip@ietf.org; Fri, 19 Oct 2007 00:54:44 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iijsg-0004tg-5O for sip@ietf.org; Fri, 19 Oct 2007 00:54:42 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id F1A8D1EC6A3; Fri, 19 Oct 2007 07:54:40 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwQ3PPH6XzNt; Fri, 19 Oct 2007 07:54:34 +0300 (EEST) Received: from rautu (telomeres197.gprs.dnafinland.fi [62.78.111.197]) by tutpro.com (Postfix) with ESMTP; Fri, 19 Oct 2007 07:54:34 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 0A37620B346; Fri, 19 Oct 2007 07:54:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18200.14465.711973.668861@tutpro.com> Date: Fri, 19 Oct 2007 07:54:25 +0300 To: Eric Burger Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: sip-bounces@ietf.org Eric Burger writes: > What I was saying is I would buy the efficiency argument IIF the example is > for a network where that matters. > > I am offering that double the number of messages means we go from 1% > utilization to 2%? Who cares? it is not only network utilization, but also doubling the number of messages the proxies need to route. i start to get really worried, if this kind of subscribe/notify complexity is introduced for each call. -- 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 Fri Oct 19 01:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikFY-0003dg-3x; Fri, 19 Oct 2007 01:18:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IikFV-0003bz-Ph for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 01:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikFT-0003ar-OZ for sip@ietf.org; Fri, 19 Oct 2007 01:18:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IikFN-0007Ev-Hg for sip@ietf.org; Fri, 19 Oct 2007 01:18:15 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9J5HvaQ020604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 19 Oct 2007 00:17:59 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AB180CC-04D4-49A9-B47E-519B9939AB6C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 19 Oct 2007 00:17:48 -0500 To: sip List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] fork-loop-fix response code 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: , Errors-To: sip-bounces@ietf.org Anybody have an objection to using the response code 440 in fork-loop- fix? -- 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 19 02:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IilXp-00034Z-Nt; Fri, 19 Oct 2007 02:41:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IilXn-00031p-Iq for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 02:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IilXm-0002yP-KB for sip@ietf.org; Fri, 19 Oct 2007 02:41:14 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IilXd-0000hP-D7 for sip@ietf.org; Fri, 19 Oct 2007 02:41:11 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQ500C2IBVAER@siemenscomms.co.uk> for sip@ietf.org; Fri, 19 Oct 2007 07:40:22 +0100 (BST) Date: Fri, 19 Oct 2007 07:40:43 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: <4717F4A8.3050504@nostrum.com> To: Adam Roach , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgR5UMYtEHcVhWySICJIkOxRUCxqgANP1Ag Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Adam, Now that you have reminded us of the dialogusage draft, perhaps it would be appropriate to remind people of the following from the abstract: "This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them." In other words, while it will only be an Informational RFC, it seems to deprecate introduction of further dialog reuses. So if we were to go with NOTIFY, would this be a new dialog usage, and if so, do we really want to go ahead with something in contradiction to the sentiment of that recently-approved draft? John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 19 October 2007 01:05 > To: Paul Kyzivat > Cc: sip; Brian Stucker > Subject: Re: [Sip] INFO > > Paul Kyzivat wrote: > > I mostly agree with Adam. The place where I take exception > is INFO. It > > is my impression that INFO was designed for use with INVITE, and so > > should be considered to be part of an invite-dialog-usage. > And Robert > > specified it that way in the dialogusage draft. > > You're correct. I had forgotten about that, and the dialogusage draft > does make it clear: INFO is part of the INVITE usage. RFC > 2976 predates > the current terminology, but a quick re-read does show that > it's pretty > clearly appropriate only for INVITE usages. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 19 03:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iimav-0006FF-Mn; Fri, 19 Oct 2007 03:48:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iimat-0006E6-Vc for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 03:48:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iimag-0005XR-4S for sip@ietf.org; Fri, 19 Oct 2007 03:48:18 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IimaQ-0008Jy-GC for sip@ietf.org; Fri, 19 Oct 2007 03:48:02 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1Iimbf-0002sK-5I; Fri, 19 Oct 2007 00:49:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 19 Oct 2007 00:47:46 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgR5UMYtEHcVhWySICJIkOxRUCxqgANP1AgAAIk8yA= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> From: "Michael Procter" To: "Elwell, John" , "Adam Roach" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org John, My impression of the discussion so far is that using NOTIFY (or INTIFY as Christer suggests) in this way would not constitute a new dialog-usage. A new usage would imply periodic resubscription and specific termination, whereas sending INTIFY within the context of the INVITE-usage means that the lifetime issues can be ignored: terminate the call, and INTIFY no longer has a context. This neatly avoids violating the letter of the dialogusage draft, but you could probably argue that creating sub-usages of the INVITE-usage isn't necessarily in keeping with the spirit of the draft... Regards, Michael > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 19 October 2007 07:41 > To: Adam Roach; Paul Kyzivat > Cc: sip; Brian Stucker > Subject: RE: [Sip] INFO >=20 > Adam, >=20 > Now that you have reminded us of the dialogusage draft, perhaps it > would > be appropriate to remind people of the following from the abstract: > "This memo argues that multiple dialog usages should be avoided. It > discusses alternatives to their use and clarifies essential behavior > for > elements that cannot currently avoid them." > In other words, while it will only be an Informational RFC, it seems > to > deprecate introduction of further dialog reuses. So if we were to go > with NOTIFY, would this be a new dialog usage, and if so, do we really > want to go ahead with something in contradiction to the sentiment of > that recently-approved draft? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 19 October 2007 01:05 > > To: Paul Kyzivat > > Cc: sip; Brian Stucker > > Subject: Re: [Sip] INFO > > > > Paul Kyzivat wrote: > > > I mostly agree with Adam. The place where I take exception > > is INFO. It > > > is my impression that INFO was designed for use with INVITE, and > so > > > should be considered to be part of an invite-dialog-usage. > > And Robert > > > specified it that way in the dialogusage draft. > > > > You're correct. I had forgotten about that, and the dialogusage > draft > > does make it clear: INFO is part of the INVITE usage. RFC > > 2976 predates > > the current terminology, but a quick re-read does show that > > it's pretty > > clearly appropriate only for INVITE usages. > > > > /a > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 04:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinYL-00011H-1h; Fri, 19 Oct 2007 04:49:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IinYI-00011A-VN for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 04:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinYI-000112-6N for sip@ietf.org; Fri, 19 Oct 2007 04:49:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IinYG-0004ak-RC for sip@ietf.org; Fri, 19 Oct 2007 04:49:54 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58182205F8; Fri, 19 Oct 2007 10:49:47 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-58-47186fab596b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 25724205A5; Fri, 19 Oct 2007 10:49:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 10:49:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 19 Oct 2007 10:49:46 +0200 Message-ID: In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgR5UMYtEHcVhWySICJIkOxRUCxqgANP1AgAAIk8yAAAkxEYA== References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> From: "Christer Holmberg" To: "Michael Procter" , "Elwell, John" , "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Oct 2007 08:49:46.0981 (UTC) FILETIME=[0069A150:01C8122D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: sip , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hi, Michael is correct. The idea would be to only have ONE SINGLE USAGE - the invite usage, and define some kind of invite-usage-subscription mechanism for that. I strongly do not think that we should start to define things based on multiple usages, because Robert's draft shows all the issues with that. So, whatever method (INFO, NOTIFY, INTIFY,...) we use, it has to be something which is allowed for an invite usage, and can also be identified to belong to an invite usage. The issue with NOTIFY in th invite-usage-subscription proposal is that it is a subscription usage command, currently not defined/allowed for invite usages. So, we would have to change that, or use another method. Regards, Christer =20 > -----Original Message----- > From: Michael Procter [mailto:michael.procter@citel.com]=20 > Sent: 19. lokakuuta 2007 10:48 > To: Elwell, John; Adam Roach; Paul Kyzivat > Cc: sip; Brian Stucker > Subject: RE: [Sip] INFO >=20 > John, >=20 > My impression of the discussion so far is that using NOTIFY=20 > (or INTIFY as Christer suggests) in this way would not=20 > constitute a new dialog-usage. A new usage would imply=20 > periodic resubscription and specific termination, whereas=20 > sending INTIFY within the context of the INVITE-usage means=20 > that the lifetime issues can be ignored: terminate the call,=20 > and INTIFY no longer has a context. >=20 > This neatly avoids violating the letter of the dialogusage=20 > draft, but you could probably argue that creating sub-usages=20 > of the INVITE-usage isn't necessarily in keeping with the=20 > spirit of the draft... >=20 > Regards, >=20 > Michael >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 19 October 2007 07:41 > > To: Adam Roach; Paul Kyzivat > > Cc: sip; Brian Stucker > > Subject: RE: [Sip] INFO > >=20 > > Adam, > >=20 > > Now that you have reminded us of the dialogusage draft, perhaps it=20 > > would be appropriate to remind people of the following from the=20 > > abstract: > > "This memo argues that multiple dialog usages should be=20 > avoided. It=20 > > discusses alternatives to their use and clarifies essential=20 > behavior=20 > > for elements that cannot currently avoid them." > > In other words, while it will only be an Informational RFC,=20 > it seems=20 > > to deprecate introduction of further dialog reuses. So if=20 > we were to=20 > > go with NOTIFY, would this be a new dialog usage, and if so, do we=20 > > really want to go ahead with something in contradiction to the=20 > > sentiment of that recently-approved draft? > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@nostrum.com] > > > Sent: 19 October 2007 01:05 > > > To: Paul Kyzivat > > > Cc: sip; Brian Stucker > > > Subject: Re: [Sip] INFO > > > > > > Paul Kyzivat wrote: > > > > I mostly agree with Adam. The place where I take exception > > > is INFO. It > > > > is my impression that INFO was designed for use with INVITE, and > > so > > > > should be considered to be part of an invite-dialog-usage. > > > And Robert > > > > specified it that way in the dialogusage draft. > > > > > > You're correct. I had forgotten about that, and the dialogusage > > draft > > > does make it clear: INFO is part of the INVITE usage. RFC > > > 2976 predates > > > the current terminology, but a quick re-read does show that it's=20 > > > pretty clearly appropriate only for INVITE usages. > > > > > > /a > > > > > > > > > _______________________________________________ > > > 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 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 Fri Oct 19 04:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinYS-00019C-Bt; Fri, 19 Oct 2007 04:50:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IinYQ-000185-I2 for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 04:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IinYP-000164-AF for sip@ietf.org; Fri, 19 Oct 2007 04:50:01 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IinYI-0004aN-UN for sip@ietf.org; Fri, 19 Oct 2007 04:50:01 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQ500M5AHU28C@siemenscomms.co.uk> for sip@ietf.org; Fri, 19 Oct 2007 09:49:15 +0100 (BST) Date: Fri, 19 Oct 2007 09:49:35 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> To: Michael Procter , Adam Roach , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgR5UMYtEHcVhWySICJIkOxRUCxqgANP1AgAAIk8yAAAgVSoA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Michael, Yes, I guess some of the postings on this thread have hinted that it would be the same dialog usage. I suppose if the subscriptions are deemed to terminate at the time of the BYE transaction, then it would indeed by the same dialog usage. So it would appear to be within the letter of the dialogusage draft. However, one or two postings have suggested different. John > -----Original Message----- > From: Michael Procter [mailto:michael.procter@citel.com] > Sent: 19 October 2007 08:48 > To: Elwell, John; Adam Roach; Paul Kyzivat > Cc: sip; Brian Stucker > Subject: RE: [Sip] INFO > > John, > > My impression of the discussion so far is that using NOTIFY (or INTIFY > as Christer suggests) in this way would not constitute a new > dialog-usage. A new usage would imply periodic resubscription and > specific termination, whereas sending INTIFY within the context of the > INVITE-usage means that the lifetime issues can be ignored: terminate > the call, and INTIFY no longer has a context. > > This neatly avoids violating the letter of the dialogusage draft, but > you could probably argue that creating sub-usages of the INVITE-usage > isn't necessarily in keeping with the spirit of the draft... > > Regards, > > Michael > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 19 October 2007 07:41 > > To: Adam Roach; Paul Kyzivat > > Cc: sip; Brian Stucker > > Subject: RE: [Sip] INFO > > > > Adam, > > > > Now that you have reminded us of the dialogusage draft, perhaps it > > would > > be appropriate to remind people of the following from the abstract: > > "This memo argues that multiple dialog usages should be avoided. It > > discusses alternatives to their use and clarifies essential behavior > > for > > elements that cannot currently avoid them." > > In other words, while it will only be an Informational RFC, it seems > > to > > deprecate introduction of further dialog reuses. So if we were to go > > with NOTIFY, would this be a new dialog usage, and if so, > do we really > > want to go ahead with something in contradiction to the sentiment of > > that recently-approved draft? > > > > John > > > > > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@nostrum.com] > > > Sent: 19 October 2007 01:05 > > > To: Paul Kyzivat > > > Cc: sip; Brian Stucker > > > Subject: Re: [Sip] INFO > > > > > > Paul Kyzivat wrote: > > > > I mostly agree with Adam. The place where I take exception > > > is INFO. It > > > > is my impression that INFO was designed for use with INVITE, and > > so > > > > should be considered to be part of an invite-dialog-usage. > > > And Robert > > > > specified it that way in the dialogusage draft. > > > > > > You're correct. I had forgotten about that, and the dialogusage > > draft > > > does make it clear: INFO is part of the INVITE usage. RFC > > > 2976 predates > > > the current terminology, but a quick re-read does show that > > > it's pretty > > > clearly appropriate only for INVITE usages. > > > > > > /a > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 19 07:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqLP-0006e8-0b; Fri, 19 Oct 2007 07:48:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiqLM-0006Xl-4b for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 07:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqLL-0006WM-BA for sip@ietf.org; Fri, 19 Oct 2007 07:48:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiqLF-0003b5-5Y for sip@ietf.org; Fri, 19 Oct 2007 07:48:43 -0400 X-IronPort-AV: E=Sophos;i="4.21,300,1188792000"; d="scan'208";a="135195543" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2007 07:47:54 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9JBlroF003724; Fri, 19 Oct 2007 07:47:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9JBlnk9002022; Fri, 19 Oct 2007 11:47:49 GMT 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.1830); Fri, 19 Oct 2007 07:47:49 -0400 Received: from [10.86.242.58] ([10.86.242.58]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 07:47:48 -0400 Message-ID: <47189963.10709@cisco.com> Date: Fri, 19 Oct 2007 07:47:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 11:47:48.0881 (UTC) FILETIME=[DF523810:01C81245] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--31.117900-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4062; t=1192794473; x=1193658473; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=52dN/uLqS+th3haqN13K/eHpMqR0T34QLqz9G+6Z7aY=; b=j4YLcnY863c3Tdmbcf/7QPDiDPf4FtI4P4Kv93VAC6uywX5Ap8TE+pm1ls4y70vkAInjd0+D c74nfI1wtr2TjwsIYsN70B/uWE+8Sd48qRMwRqlG8tV7X+GVPsrvC8W6; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Yes, my thinking has been that this would be a matter of negotiating the use of NOTIFY *within* the invite-dialog-usage. Of course that isn't legal today - this would be an extension to both 3261 and 3265. Paul Elwell, John wrote: > Michael, > > Yes, I guess some of the postings on this thread have hinted that it > would be the same dialog usage. I suppose if the subscriptions are > deemed to terminate at the time of the BYE transaction, then it would > indeed by the same dialog usage. So it would appear to be within the > letter of the dialogusage draft. However, one or two postings have > suggested different. > > John > >> -----Original Message----- >> From: Michael Procter [mailto:michael.procter@citel.com] >> Sent: 19 October 2007 08:48 >> To: Elwell, John; Adam Roach; Paul Kyzivat >> Cc: sip; Brian Stucker >> Subject: RE: [Sip] INFO >> >> John, >> >> My impression of the discussion so far is that using NOTIFY (or INTIFY >> as Christer suggests) in this way would not constitute a new >> dialog-usage. A new usage would imply periodic resubscription and >> specific termination, whereas sending INTIFY within the context of the >> INVITE-usage means that the lifetime issues can be ignored: terminate >> the call, and INTIFY no longer has a context. >> >> This neatly avoids violating the letter of the dialogusage draft, but >> you could probably argue that creating sub-usages of the INVITE-usage >> isn't necessarily in keeping with the spirit of the draft... >> >> Regards, >> >> Michael >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens.com] >>> Sent: 19 October 2007 07:41 >>> To: Adam Roach; Paul Kyzivat >>> Cc: sip; Brian Stucker >>> Subject: RE: [Sip] INFO >>> >>> Adam, >>> >>> Now that you have reminded us of the dialogusage draft, perhaps it >>> would >>> be appropriate to remind people of the following from the abstract: >>> "This memo argues that multiple dialog usages should be avoided. It >>> discusses alternatives to their use and clarifies essential behavior >>> for >>> elements that cannot currently avoid them." >>> In other words, while it will only be an Informational RFC, it seems >>> to >>> deprecate introduction of further dialog reuses. So if we were to go >>> with NOTIFY, would this be a new dialog usage, and if so, >> do we really >>> want to go ahead with something in contradiction to the sentiment of >>> that recently-approved draft? >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: 19 October 2007 01:05 >>>> To: Paul Kyzivat >>>> Cc: sip; Brian Stucker >>>> Subject: Re: [Sip] INFO >>>> >>>> Paul Kyzivat wrote: >>>>> I mostly agree with Adam. The place where I take exception >>>> is INFO. It >>>>> is my impression that INFO was designed for use with INVITE, and >>> so >>>>> should be considered to be part of an invite-dialog-usage. >>>> And Robert >>>>> specified it that way in the dialogusage draft. >>>> You're correct. I had forgotten about that, and the dialogusage >>> draft >>>> does make it clear: INFO is part of the INVITE usage. RFC >>>> 2976 predates >>>> the current terminology, but a quick re-read does show that >>>> it's pretty >>>> clearly appropriate only for INVITE usages. >>>> >>>> /a >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the >> application of sip >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 19 07:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqRr-0005tc-OL; Fri, 19 Oct 2007 07:55:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiqRp-0005nd-4L for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 07:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqRm-0005fd-NB; Fri, 19 Oct 2007 07:55:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IiqRe-0003pM-1T; Fri, 19 Oct 2007 07:55:22 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1192794897!3769689!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 3575 invoked from network); 19 Oct 2007 11:54:57 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-128.messagelabs.com with SMTP; 19 Oct 2007 11:54:57 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l9JBsv6F003074; Fri, 19 Oct 2007 04:54:57 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l9JBsuFJ027742; Fri, 19 Oct 2007 06:54:56 -0500 (CDT) 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 l9JBssdm027728; Fri, 19 Oct 2007 06:54:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Oct 2007 19:54:52 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B05086D63@ZMY16EXM66.ds.mot.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 500 Conference Server full response - is this response code in use Thread-Index: AcgR5UMYtEHcVhWySICJIkOxRUCxqgANP1AgAAIk8yAAAgVSoAAG4EoA References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip-implementors@cs.columbia.edu Subject: [Sip] 500 Conference Server full response - is this response code in use 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: , Errors-To: sip-bounces@ietf.org Hi The earlier draft on SIP conferencing models draft-rosenberg-sip-conferencing-models-01.txt, defines a 5xx response: 500 conference server full response to indicate that the conference server has reached its maximum capacity of users. But I do not see this response in subsequent versions of draft / RFC. So which is the response code that is currently used to indicate this scenario? Or is it not required at all. Thanks Regards Ranjit - _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 19 10:11:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IisSv-00079u-Eo; Fri, 19 Oct 2007 10:04:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IisSs-00078a-EB for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IisSr-00072H-Kk for sip@ietf.org; Fri, 19 Oct 2007 10:04:37 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IisSh-0000XV-FK for sip@ietf.org; Fri, 19 Oct 2007 10:04:33 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 19 Oct 2007 10:04:20 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 19 Oct 2007 10:04:20 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Elwell, John" Date: Fri, 19 Oct 2007 10:04:19 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgSR8gBcpV0HW0sSUqJ9gq5wSenigAEPHLA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> In-Reply-To: <47189963.10709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip , Michael Procter , Roach , Adam, Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Which is one of the reasons I think it should be INFO. Using it would only= be an update to rfc2976, right? -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, October 19, 2007 7:48 AM > To: Elwell, John > Cc: sip; Michael Procter; Adam Roach; Brian Stucker > Subject: Re: [Sip] INFO > > Yes, my thinking has been that this would be a matter of negotiating the > use of NOTIFY *within* the invite-dialog-usage. Of course that isn't > legal today - this would be an extension to both 3261 and 3265. > > Paul > > Elwell, John wrote: > > Michael, > > > > Yes, I guess some of the postings on this thread have hinted that it > > would be the same dialog usage. I suppose if the subscriptions are > > deemed to terminate at the time of the BYE transaction, then it would > > indeed by the same dialog usage. So it would appear to be within the > > letter of the dialogusage draft. However, one or two postings have > > suggested different. > > > > John > > > >> -----Original Message----- > >> From: Michael Procter [mailto:michael.procter@citel.com] > >> Sent: 19 October 2007 08:48 > >> To: Elwell, John; Adam Roach; Paul Kyzivat > >> Cc: sip; Brian Stucker > >> Subject: RE: [Sip] INFO > >> > >> John, > >> > >> My impression of the discussion so far is that using NOTIFY (or INTIFY > >> as Christer suggests) in this way would not constitute a new > >> dialog-usage. A new usage would imply periodic resubscription and > >> specific termination, whereas sending INTIFY within the context of the > >> INVITE-usage means that the lifetime issues can be ignored: terminate > >> the call, and INTIFY no longer has a context. > >> > >> This neatly avoids violating the letter of the dialogusage draft, but > >> you could probably argue that creating sub-usages of the INVITE-usage > >> isn't necessarily in keeping with the spirit of the draft... > >> > >> Regards, > >> > >> Michael > >> > >>> -----Original Message----- > >>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>> Sent: 19 October 2007 07:41 > >>> To: Adam Roach; Paul Kyzivat > >>> Cc: sip; Brian Stucker > >>> Subject: RE: [Sip] INFO > >>> > >>> Adam, > >>> > >>> Now that you have reminded us of the dialogusage draft, perhaps it > >>> would > >>> be appropriate to remind people of the following from the abstract: > >>> "This memo argues that multiple dialog usages should be avoided. It > >>> discusses alternatives to their use and clarifies essential behavior > >>> for > >>> elements that cannot currently avoid them." > >>> In other words, while it will only be an Informational RFC, it seems > >>> to > >>> deprecate introduction of further dialog reuses. So if we were to go > >>> with NOTIFY, would this be a new dialog usage, and if so, > >> do we really > >>> want to go ahead with something in contradiction to the sentiment of > >>> that recently-approved draft? > >>> > >>> John > >>> > >>> > >>>> -----Original Message----- > >>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>> Sent: 19 October 2007 01:05 > >>>> To: Paul Kyzivat > >>>> Cc: sip; Brian Stucker > >>>> Subject: Re: [Sip] INFO > >>>> > >>>> Paul Kyzivat wrote: > >>>>> I mostly agree with Adam. The place where I take exception > >>>> is INFO. It > >>>>> is my impression that INFO was designed for use with INVITE, and > >>> so > >>>>> should be considered to be part of an invite-dialog-usage. > >>>> And Robert > >>>>> specified it that way in the dialogusage draft. > >>>> You're correct. I had forgotten about that, and the dialogusage > >>> draft > >>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>> 2976 predates > >>>> the current terminology, but a quick re-read does show that > >>>> it's pretty > >>>> clearly appropriate only for INVITE usages. > >>>> > >>>> /a > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the > >> application of sip > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 12:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiuBx-0005Bb-3h; Fri, 19 Oct 2007 11:55:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiuBv-0005AS-CZ for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 11:55:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiuBu-0005AC-GX for sip@ietf.org; Fri, 19 Oct 2007 11:55:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiuBt-0001Lu-Jn for sip@ietf.org; Fri, 19 Oct 2007 11:55:14 -0400 X-IronPort-AV: E=Sophos;i="4.21,301,1188802800"; d="scan'208";a="239812664" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2007 08:55:12 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9JFtBeB008859; Fri, 19 Oct 2007 11:55:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9JFsxkR024576; Fri, 19 Oct 2007 15:55:11 GMT 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.1830); Fri, 19 Oct 2007 11:55:01 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 11:55:00 -0400 Message-ID: <4718D354.3030701@cisco.com> Date: Fri, 19 Oct 2007 11:55:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 15:55:00.0979 (UTC) FILETIME=[67F0C430:01C81268] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--44.348500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6510; t=1192809311; x=1193673311; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=0wn2+gzhDiTb+zQ1Os2gvV6JUOhS3MRAgbO5PoK1M5o=; b=qcKVqMgQu+aH37ndzwWYnwLcVrXYTP7gD53rEZyQtYFjxa0qrEt1ErNgnXdykxyINoJ/oC+U bi8WektdrS6aqbGUY7JcSWwLlER0KB65Owgj+BnJFeN7E6gN7Uz9ybRp; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: sip , Adam Roach , Michael Procter , "Elwell, John" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Which is one of the reasons I think it should be INFO. Using it would only be an update to rfc2976, right? > -hadriel I don't think the distinction is significant. Either way it should be designed to be backward compatible. And neither way will require actually changing those other documents. Using NOTIFY: - will need some new header(s) in INVITE and responses to negotiate this new capability within the invite dialog usage. - once that is done it will have established some new rules for using NOTIFY in that context. This will not be used unless negotiated, so there aren't any backward compatibility issues. - for those that *do* support this, the same code should ideally be able to use either this technique or real subscriptions, with only minor tweaks. - I would expect that any event packages defined in the future that could meaningfully be used in this way would be designed from the ground up to support both styles. Using INFO: - I don't think it will be sufficient to just add headers to NOTIFY itself. IMO there still needs to be negotiation of the particular usages of NOTIFY. So there still need to be new header(s) in invite and responses. - once the negotiation is done there will need to be some new header(s) to provide added context for the INFO. - any usage that currently has an event package would have to be modified to be used with INFO. Bottom line - I think a "lighter weight" subscription mechanism serves all the same needs that an enhanced INFO does, is no harder to implement, and has other benefits. Thanks, Paul >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 19, 2007 7:48 AM >> To: Elwell, John >> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >> Subject: Re: [Sip] INFO >> >> Yes, my thinking has been that this would be a matter of negotiating the >> use of NOTIFY *within* the invite-dialog-usage. Of course that isn't >> legal today - this would be an extension to both 3261 and 3265. >> >> Paul >> >> Elwell, John wrote: >>> Michael, >>> >>> Yes, I guess some of the postings on this thread have hinted that it >>> would be the same dialog usage. I suppose if the subscriptions are >>> deemed to terminate at the time of the BYE transaction, then it would >>> indeed by the same dialog usage. So it would appear to be within the >>> letter of the dialogusage draft. However, one or two postings have >>> suggested different. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>> Sent: 19 October 2007 08:48 >>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>> Cc: sip; Brian Stucker >>>> Subject: RE: [Sip] INFO >>>> >>>> John, >>>> >>>> My impression of the discussion so far is that using NOTIFY (or INTIFY >>>> as Christer suggests) in this way would not constitute a new >>>> dialog-usage. A new usage would imply periodic resubscription and >>>> specific termination, whereas sending INTIFY within the context of the >>>> INVITE-usage means that the lifetime issues can be ignored: terminate >>>> the call, and INTIFY no longer has a context. >>>> >>>> This neatly avoids violating the letter of the dialogusage draft, but >>>> you could probably argue that creating sub-usages of the INVITE-usage >>>> isn't necessarily in keeping with the spirit of the draft... >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>> Sent: 19 October 2007 07:41 >>>>> To: Adam Roach; Paul Kyzivat >>>>> Cc: sip; Brian Stucker >>>>> Subject: RE: [Sip] INFO >>>>> >>>>> Adam, >>>>> >>>>> Now that you have reminded us of the dialogusage draft, perhaps it >>>>> would >>>>> be appropriate to remind people of the following from the abstract: >>>>> "This memo argues that multiple dialog usages should be avoided. It >>>>> discusses alternatives to their use and clarifies essential behavior >>>>> for >>>>> elements that cannot currently avoid them." >>>>> In other words, while it will only be an Informational RFC, it seems >>>>> to >>>>> deprecate introduction of further dialog reuses. So if we were to go >>>>> with NOTIFY, would this be a new dialog usage, and if so, >>>> do we really >>>>> want to go ahead with something in contradiction to the sentiment of >>>>> that recently-approved draft? >>>>> >>>>> John >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>> Sent: 19 October 2007 01:05 >>>>>> To: Paul Kyzivat >>>>>> Cc: sip; Brian Stucker >>>>>> Subject: Re: [Sip] INFO >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>>> I mostly agree with Adam. The place where I take exception >>>>>> is INFO. It >>>>>>> is my impression that INFO was designed for use with INVITE, and >>>>> so >>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>> And Robert >>>>>>> specified it that way in the dialogusage draft. >>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>> draft >>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>> 2976 predates >>>>>> the current terminology, but a quick re-read does show that >>>>>> it's pretty >>>>>> clearly appropriate only for INVITE usages. >>>>>> >>>>>> /a >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the >>>> application of sip >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 12:26:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiubi-0002F2-UZ; Fri, 19 Oct 2007 12:21:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiubg-0002Am-KD for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 12:21:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiubf-0002AA-Gj for sip@ietf.org; Fri, 19 Oct 2007 12:21:51 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiube-0002DD-M5 for sip@ietf.org; Fri, 19 Oct 2007 12:21:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9JGLP709353; Fri, 19 Oct 2007 16:21:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 19 Oct 2007 11:21:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> In-Reply-To: <4718D354.3030701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgSaIapQleuBNC6QK+9JntVjBH01QAAw9mQ References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: sip , Adam Roach , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org If we're going to change the way that error messages are handled that are returned for NOTIFY messages isn't it going to be a bit complicated to determine at the transaction layer if the NOTIFY was negotiated via INVITE or via SUBSCRIBE? I mean, the endpoints may know what's going on, but boxes in the middle might not.=20 I'm a bit concerned that by tweaking 3265 in this way we're going to move more complexity into all subscription processing whether it's a usage within a dialog, a separate dialog or this new thing. Regards, Brian=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 19, 2007 10:55 AM > To: Hadriel Kaplan > Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker,=20 > Brian (RICH1:AR00) > Subject: Re: [Sip] INFO >=20 >=20 >=20 > Hadriel Kaplan wrote: > > Which is one of the reasons I think it should be INFO. =20 > Using it would only be an update to rfc2976, right? > > -hadriel >=20 > I don't think the distinction is significant. Either way it=20 > should be designed to be backward compatible. And neither way=20 > will require actually changing those other documents. >=20 > Using NOTIFY: >=20 > - will need some new header(s) in INVITE and responses to=20 > negotiate this > new capability within the invite dialog usage. >=20 > - once that is done it will have established some new rules for using > NOTIFY in that context. This will not be used unless negotiated, > so there aren't any backward compatibility issues. >=20 > - for those that *do* support this, the same code should ideally be > able to use either this technique or real subscriptions, with only > minor tweaks. >=20 > - I would expect that any event packages defined in the future that > could meaningfully be used in this way would be designed from the > ground up to support both styles. >=20 > Using INFO: >=20 > - I don't think it will be sufficient to just add headers to > NOTIFY itself. IMO there still needs to be negotiation of > the particular usages of NOTIFY. So there still need to be > new header(s) in invite and responses. >=20 > - once the negotiation is done there will need to be some new > header(s) to provide added context for the INFO. >=20 > - any usage that currently has an event package would have > to be modified to be used with INFO. >=20 > Bottom line - I think a "lighter weight" subscription=20 > mechanism serves all the same needs that an enhanced INFO=20 > does, is no harder to implement, and has other benefits. > =09 > Thanks, > Paul >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 19, 2007 7:48 AM > >> To: Elwell, John > >> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >> Subject: Re: [Sip] INFO > >> > >> Yes, my thinking has been that this would be a matter of=20 > negotiating=20 > >> the use of NOTIFY *within* the invite-dialog-usage. Of course that=20 > >> isn't legal today - this would be an extension to both=20 > 3261 and 3265. > >> > >> Paul > >> > >> Elwell, John wrote: > >>> Michael, > >>> > >>> Yes, I guess some of the postings on this thread have=20 > hinted that it=20 > >>> would be the same dialog usage. I suppose if the=20 > subscriptions are=20 > >>> deemed to terminate at the time of the BYE transaction, then it=20 > >>> would indeed by the same dialog usage. So it would appear to be=20 > >>> within the letter of the dialogusage draft. However, one or two=20 > >>> postings have suggested different. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Michael Procter [mailto:michael.procter@citel.com] > >>>> Sent: 19 October 2007 08:48 > >>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>> Cc: sip; Brian Stucker > >>>> Subject: RE: [Sip] INFO > >>>> > >>>> John, > >>>> > >>>> My impression of the discussion so far is that using NOTIFY (or=20 > >>>> INTIFY as Christer suggests) in this way would not=20 > constitute a new=20 > >>>> dialog-usage. A new usage would imply periodic=20 > resubscription and=20 > >>>> specific termination, whereas sending INTIFY within the=20 > context of=20 > >>>> the INVITE-usage means that the lifetime issues can be ignored:=20 > >>>> terminate the call, and INTIFY no longer has a context. > >>>> > >>>> This neatly avoids violating the letter of the=20 > dialogusage draft,=20 > >>>> but you could probably argue that creating sub-usages of the=20 > >>>> INVITE-usage isn't necessarily in keeping with the=20 > spirit of the draft... > >>>> > >>>> Regards, > >>>> > >>>> Michael > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>> Sent: 19 October 2007 07:41 > >>>>> To: Adam Roach; Paul Kyzivat > >>>>> Cc: sip; Brian Stucker > >>>>> Subject: RE: [Sip] INFO > >>>>> > >>>>> Adam, > >>>>> > >>>>> Now that you have reminded us of the dialogusage draft,=20 > perhaps it=20 > >>>>> would be appropriate to remind people of the following from the=20 > >>>>> abstract: > >>>>> "This memo argues that multiple dialog usages should be=20 > avoided. =20 > >>>>> It discusses alternatives to their use and clarifies essential=20 > >>>>> behavior for elements that cannot currently avoid them." > >>>>> In other words, while it will only be an Informational RFC, it=20 > >>>>> seems to deprecate introduction of further dialog=20 > reuses. So if we=20 > >>>>> were to go with NOTIFY, would this be a new dialog=20 > usage, and if=20 > >>>>> so, > >>>> do we really > >>>>> want to go ahead with something in contradiction to the=20 > sentiment=20 > >>>>> of that recently-approved draft? > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>> Sent: 19 October 2007 01:05 > >>>>>> To: Paul Kyzivat > >>>>>> Cc: sip; Brian Stucker > >>>>>> Subject: Re: [Sip] INFO > >>>>>> > >>>>>> Paul Kyzivat wrote: > >>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>> is INFO. It > >>>>>>> is my impression that INFO was designed for use with=20 > INVITE, and > >>>>> so > >>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>> And Robert > >>>>>>> specified it that way in the dialogusage draft. > >>>>>> You're correct. I had forgotten about that, and the dialogusage > >>>>> draft > >>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>> 2976 predates > >>>>>> the current terminology, but a quick re-read does show=20 > that it's=20 > >>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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=20 > 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=20 > >>>>> sip-implementors@cs.columbia.edu for questions on=20 > 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=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 Fri Oct 19 12:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiuto-0008VI-N1; Fri, 19 Oct 2007 12:40:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiutn-0008UV-6G for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 12:40:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiutm-0008U7-EA for sip@ietf.org; Fri, 19 Oct 2007 12:40:34 -0400 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiutm-0002td-8H for sip@ietf.org; Fri, 19 Oct 2007 12:40:34 -0400 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.32]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Oct 2007 12:40:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] fork-loop-fix response code Date: Fri, 19 Oct 2007 12:40:33 -0400 Message-ID: In-Reply-To: <6AB180CC-04D4-49A9-B47E-519B9939AB6C@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] fork-loop-fix response code Thread-Index: AcgSEDnxmfiKgdjcRrigl1LxB3oyEQAWhyFg From: "Brett Tate" To: "Dean Willis" , "sip List" X-OriginalArrivalTime: 19 Oct 2007 16:40:36.0429 (UTC) FILETIME=[C6654FD0:01C8126E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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: , Errors-To: sip-bounces@ietf.org > Anybody have an objection to using the response=20 > code 440 in fork-loop- fix? Are you recommending using 440 instead of 482 Loop Detected? When would 440 be triggered instead of 482? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 12:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv19-0006zn-K6; Fri, 19 Oct 2007 12:48:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiv17-0006tg-E7 for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 12:48:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv16-0006pE-AK for sip@ietf.org; Fri, 19 Oct 2007 12:48:08 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiv16-0003C3-0F for sip@ietf.org; Fri, 19 Oct 2007 12:48:08 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9JGlxax022643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Oct 2007 11:48:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] fork-loop-fix response code Date: Fri, 19 Oct 2007 11:47:56 -0500 To: "Brett Tate" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 16:05:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Remember from the discussion in Chicago that we are merging in the max-breadth draft, which creates a new response code that 482 would not be appropriate for. There will be, of course, an opportunity to review and debate this if you want to, but I want the next version of the draft to have a concrete number in it. RjS On Oct 19, 2007, at 11:40 AM, Brett Tate wrote: >> Anybody have an objection to using the response >> code 440 in fork-loop- fix? > > Are you recommending using 440 instead of 482 Loop Detected? > > When would 440 be triggered instead of 482? > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 12:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv5T-0007dO-Pi; Fri, 19 Oct 2007 12:52:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiv5R-0007bS-G1 for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 12:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiv5Q-0007af-CB for sip@ietf.org; Fri, 19 Oct 2007 12:52:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiv5L-0007r7-4H for sip@ietf.org; Fri, 19 Oct 2007 12:52:36 -0400 X-IronPort-AV: E=Sophos;i="4.21,301,1188792000"; d="scan'208";a="135211426" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2007 12:52:28 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9JGqSd6004722; Fri, 19 Oct 2007 12:52:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9JGqKk7013591; Fri, 19 Oct 2007 16:52:20 GMT 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.1830); Fri, 19 Oct 2007 12:52:17 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 12:52:17 -0400 Message-ID: <4718E0C0.5000308@cisco.com> Date: Fri, 19 Oct 2007 12:52:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 16:52:17.0127 (UTC) FILETIME=[680B5770:01C81270] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--48.050300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8219; t=1192812748; x=1193676748; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Brian=20Stucker=20; bh=i4yzrhI+vhqYV4wGI9cHUzaB1PjjBv/KXrCw91szphk=; b=RL2gMD+LpbxPyH9C2Aajin+6/xueuxtCB1qUdKqO3LrX0qd6PpWH11lZ9vmxfi5yqmuo+GCE tA5Sc/OIw01YqJXsPFtRR9XPhJdaMkLtaKQuDQE2xfy5QBarklvitCAq; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: sip , Adam Roach , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > If we're going to change the way that error messages are handled that > are returned for NOTIFY messages isn't it going to be a bit complicated > to determine at the transaction layer if the NOTIFY was negotiated via > INVITE or via SUBSCRIBE? > > I mean, the endpoints may know what's going on, but boxes in the middle > might not. I don't see any reason why *proxy* middle boxes need to know anything about this. B2BUAs will need to know, but then they will know. > I'm a bit concerned that by tweaking 3265 in this way we're going to > move more complexity into all subscription processing whether it's a > usage within a dialog, a separate dialog or this new thing. It would only affect those that support it. And I don't think it will be a big deal, but then this is just speculation at this point, since no details have been worked out. Its always possible that it would turn into a mess. Paul > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 19, 2007 10:55 AM >> To: Hadriel Kaplan >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >> Brian (RICH1:AR00) >> Subject: Re: [Sip] INFO >> >> >> >> Hadriel Kaplan wrote: >>> Which is one of the reasons I think it should be INFO. >> Using it would only be an update to rfc2976, right? >>> -hadriel >> I don't think the distinction is significant. Either way it >> should be designed to be backward compatible. And neither way >> will require actually changing those other documents. >> >> Using NOTIFY: >> >> - will need some new header(s) in INVITE and responses to >> negotiate this >> new capability within the invite dialog usage. >> >> - once that is done it will have established some new rules for using >> NOTIFY in that context. This will not be used unless negotiated, >> so there aren't any backward compatibility issues. >> >> - for those that *do* support this, the same code should ideally be >> able to use either this technique or real subscriptions, with only >> minor tweaks. >> >> - I would expect that any event packages defined in the future that >> could meaningfully be used in this way would be designed from the >> ground up to support both styles. >> >> Using INFO: >> >> - I don't think it will be sufficient to just add headers to >> NOTIFY itself. IMO there still needs to be negotiation of >> the particular usages of NOTIFY. So there still need to be >> new header(s) in invite and responses. >> >> - once the negotiation is done there will need to be some new >> header(s) to provide added context for the INFO. >> >> - any usage that currently has an event package would have >> to be modified to be used with INFO. >> >> Bottom line - I think a "lighter weight" subscription >> mechanism serves all the same needs that an enhanced INFO >> does, is no harder to implement, and has other benefits. >> >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, October 19, 2007 7:48 AM >>>> To: Elwell, John >>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>> Subject: Re: [Sip] INFO >>>> >>>> Yes, my thinking has been that this would be a matter of >> negotiating >>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>> isn't legal today - this would be an extension to both >> 3261 and 3265. >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> Michael, >>>>> >>>>> Yes, I guess some of the postings on this thread have >> hinted that it >>>>> would be the same dialog usage. I suppose if the >> subscriptions are >>>>> deemed to terminate at the time of the BYE transaction, then it >>>>> would indeed by the same dialog usage. So it would appear to be >>>>> within the letter of the dialogusage draft. However, one or two >>>>> postings have suggested different. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>>>> Sent: 19 October 2007 08:48 >>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>> Cc: sip; Brian Stucker >>>>>> Subject: RE: [Sip] INFO >>>>>> >>>>>> John, >>>>>> >>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>> INTIFY as Christer suggests) in this way would not >> constitute a new >>>>>> dialog-usage. A new usage would imply periodic >> resubscription and >>>>>> specific termination, whereas sending INTIFY within the >> context of >>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>> terminate the call, and INTIFY no longer has a context. >>>>>> >>>>>> This neatly avoids violating the letter of the >> dialogusage draft, >>>>>> but you could probably argue that creating sub-usages of the >>>>>> INVITE-usage isn't necessarily in keeping with the >> spirit of the draft... >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>> Sent: 19 October 2007 07:41 >>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>> Cc: sip; Brian Stucker >>>>>>> Subject: RE: [Sip] INFO >>>>>>> >>>>>>> Adam, >>>>>>> >>>>>>> Now that you have reminded us of the dialogusage draft, >> perhaps it >>>>>>> would be appropriate to remind people of the following from the >>>>>>> abstract: >>>>>>> "This memo argues that multiple dialog usages should be >> avoided. >>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>> behavior for elements that cannot currently avoid them." >>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>> seems to deprecate introduction of further dialog >> reuses. So if we >>>>>>> were to go with NOTIFY, would this be a new dialog >> usage, and if >>>>>>> so, >>>>>> do we really >>>>>>> want to go ahead with something in contradiction to the >> sentiment >>>>>>> of that recently-approved draft? >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>> To: Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: Re: [Sip] INFO >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>> is INFO. It >>>>>>>>> is my impression that INFO was designed for use with >> INVITE, and >>>>>>> so >>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>> And Robert >>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>>>> draft >>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>> 2976 predates >>>>>>>> the current terminology, but a quick re-read does show >> that it's >>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>>>>> sipping@ietf.org for new developments on the >>>>>> application of sip >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>>>> sipping@ietf.org for new developments on the application of sip >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 13:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiw0B-0008Po-Rg; Fri, 19 Oct 2007 13:51:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiw0A-0008Pi-9K for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 13:51:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiw09-0008K5-Ew for sip@ietf.org; Fri, 19 Oct 2007 13:51:13 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiw04-0005vp-Ud for sip@ietf.org; Fri, 19 Oct 2007 13:51:09 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 19 Oct 2007 13:51:08 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 19 Oct 2007 13:51:08 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 19 Oct 2007 13:50:51 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgSaHQLgCOHLAWaS/GTvbHnWxelwQACCZrA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> In-Reply-To: <4718D354.3030701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Adam Roach , sip , Michael, Stucker , Brian, Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > I don't think the distinction is significant. Either way it should be > designed to be backward compatible. And neither way will require > actually changing those other documents. > > Using NOTIFY: > > - will need some new header(s) in INVITE and responses to negotiate this > new capability within the invite dialog usage. No matter which Method gets used, there will need to be some new header(s) = in INVITE to negotiate. So that's equal. > - once that is done it will have established some new rules for using > NOTIFY in that context. This will not be used unless negotiated, > so there aren't any backward compatibility issues. > > - for those that *do* support this, the same code should ideally be > able to use either this technique or real subscriptions, with only > minor tweaks. I don't see how that's knowable. For one, code is obviously implementation= dependent. For another, we would be changing the way in which subscribe b= odies could be sent (i.e., they wouldn't, not in the subscription-creation)= , the handling of subscription duration, and adding a directional negotiati= on mechanism. Lastly, you don't *have* to support rfc3265 at all to suppor= t 3261, so the code change could be quite a bit more. > - I would expect that any event packages defined in the future that > could meaningfully be used in this way would be designed from the > ground up to support both styles. True of both cases, I presume. > Using INFO: > > - I don't think it will be sufficient to just add headers to > NOTIFY itself. IMO there still needs to be negotiation of > the particular usages of NOTIFY. So there still need to be > new header(s) in invite and responses. I'm confused by this - did you mean INFO, and just that the INVITE needs th= e negotiation headers (as it does for NOTIFY)? > - once the negotiation is done there will need to be some new > header(s) to provide added context for the INFO. > > - any usage that currently has an event package would have > to be modified to be used with INFO. Any current event-package could not simply be used in a NOTIFY model either= , for the reason you pointed out in an earlier email: we wouldn't want the = package's subscribe body to be in the Invite. And really there are some th= at would be illogical to do so (like reg-event). So in that sense it's a w= ash: any current event-package wanting to be used would need an extension t= o say so and how, and any future ones would need to define whether or not t= hey support this new Invite-Notify/INFO and how. > Bottom line - I think a "lighter weight" subscription mechanism serves > all the same needs that an enhanced INFO does, is no harder to > implement, and has other benefits. That's assuming we need to actually make this create a real Subscription. = That would mean you'd be including all the concepts of Subscribe usages in = an Invite-created dialog, having two usages in the same dialog, etc. Since= the lifetime, relationship, context, usage, etc., between the Invite and e= vent-notification is inexorably linked, there is no need for a real Subscri= ption. And we already have a method that has that direct relationship to I= nvite: INFO. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 16:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiyoj-0001Ra-LG; Fri, 19 Oct 2007 16:51:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiyoe-00017K-W7 for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 16:51:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiyoe-0000wJ-0w for sip@ietf.org; Fri, 19 Oct 2007 16:51:32 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiyob-0005Rr-Gf for sip@ietf.org; Fri, 19 Oct 2007 16:51:29 -0400 Received: (qmail 3489 invoked by uid 0); 19 Oct 2007 20:52:39 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Oct 2007 20:52:39 -0000 Message-ID: <471918CA.5010103@zonnet.nl> Date: Fri, 19 Oct 2007 22:51:22 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> In-Reply-To: <4718E0C0.5000308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Paul, > > I don't see any reason why *proxy* middle boxes need to know anything > about this. B2BUAs will need to know, but then they will know. > There are (as always) subtle differences. NOTIFY for SUBSCRIBE is needed to handle forking (proxies pass at most 1 2xx response for SUBSCRIBE), while NOTIFY for INVITE would not be needed for this reason. Proxies Record-Route NOTIFY due to the above reason, they could avoid doing that for INVITE-NOTIFYs. Record-Routing INFO is useless and somewhat wasteful, so well designed proxies don't do that. Also, I assume there will be no need to "immediately send NOTIFY" for INVITE-based events. All in all, IMO using INFO instead of NOTIFY here is preferrable (also given that existing implementations already use INFO within INVITE dialogs). Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 17:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyxJ-0005vM-Bh; Fri, 19 Oct 2007 17:00:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IiyxG-0005t4-Jo for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 17:00:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiyxF-0005st-Ne for sip@ietf.org; Fri, 19 Oct 2007 17:00:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiyxE-0005kL-Cd for sip@ietf.org; Fri, 19 Oct 2007 17:00:25 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83F96204AC; Fri, 19 Oct 2007 23:00:23 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-8d-47191ae765d8 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 623E52043C; Fri, 19 Oct 2007 23:00:23 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 23:00:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 19 Oct 2007 22:55:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgSaIapQleuBNC6QK+9JntVjBH01QAAw9mQAAm0wEg= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Brian Stucker" , "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 19 Oct 2007 21:00:22.0966 (UTC) FILETIME=[10B21D60:01C81293] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org Hi, =20 I share Brian's concern regarding stateful intermediates. They may not = have knowledge of the new way NOTIFY is used, and they MAY do unwanted = things in certain situations. =20 Regards, =20 Christer ________________________________ From: Brian Stucker [mailto:bstucker@nortel.com] Sent: Fri 19/10/2007 18:21 To: Paul Kyzivat; Hadriel Kaplan Cc: sip; Adam Roach; Michael Procter; Elwell,John Subject: RE: [Sip] INFO If we're going to change the way that error messages are handled that are returned for NOTIFY messages isn't it going to be a bit complicated to determine at the transaction layer if the NOTIFY was negotiated via INVITE or via SUBSCRIBE? I mean, the endpoints may know what's going on, but boxes in the middle might not. I'm a bit concerned that by tweaking 3265 in this way we're going to move more complexity into all subscription processing whether it's a usage within a dialog, a separate dialog or this new thing. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, October 19, 2007 10:55 AM > To: Hadriel Kaplan > Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, > Brian (RICH1:AR00) > Subject: Re: [Sip] INFO > > > > Hadriel Kaplan wrote: > > Which is one of the reasons I think it should be INFO.=20 > Using it would only be an update to rfc2976, right? > > -hadriel > > I don't think the distinction is significant. Either way it > should be designed to be backward compatible. And neither way > will require actually changing those other documents. > > Using NOTIFY: > > - will need some new header(s) in INVITE and responses to > negotiate this > new capability within the invite dialog usage. > > - once that is done it will have established some new rules for using > NOTIFY in that context. This will not be used unless negotiated, > so there aren't any backward compatibility issues. > > - for those that *do* support this, the same code should ideally be > able to use either this technique or real subscriptions, with only > minor tweaks. > > - I would expect that any event packages defined in the future that > could meaningfully be used in this way would be designed from the > ground up to support both styles. > > Using INFO: > > - I don't think it will be sufficient to just add headers to > NOTIFY itself. IMO there still needs to be negotiation of > the particular usages of NOTIFY. So there still need to be > new header(s) in invite and responses. > > - once the negotiation is done there will need to be some new > header(s) to provide added context for the INFO. > > - any usage that currently has an event package would have > to be modified to be used with INFO. > > Bottom line - I think a "lighter weight" subscription > mechanism serves all the same needs that an enhanced INFO > does, is no harder to implement, and has other benefits. > =20 > Thanks, > Paul > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 19, 2007 7:48 AM > >> To: Elwell, John > >> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >> Subject: Re: [Sip] INFO > >> > >> Yes, my thinking has been that this would be a matter of > negotiating > >> the use of NOTIFY *within* the invite-dialog-usage. Of course that > >> isn't legal today - this would be an extension to both > 3261 and 3265. > >> > >> Paul > >> > >> Elwell, John wrote: > >>> Michael, > >>> > >>> Yes, I guess some of the postings on this thread have > hinted that it > >>> would be the same dialog usage. I suppose if the > subscriptions are > >>> deemed to terminate at the time of the BYE transaction, then it > >>> would indeed by the same dialog usage. So it would appear to be > >>> within the letter of the dialogusage draft. However, one or two > >>> postings have suggested different. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Michael Procter [mailto:michael.procter@citel.com] > >>>> Sent: 19 October 2007 08:48 > >>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>> Cc: sip; Brian Stucker > >>>> Subject: RE: [Sip] INFO > >>>> > >>>> John, > >>>> > >>>> My impression of the discussion so far is that using NOTIFY (or > >>>> INTIFY as Christer suggests) in this way would not > constitute a new > >>>> dialog-usage. A new usage would imply periodic > resubscription and > >>>> specific termination, whereas sending INTIFY within the > context of > >>>> the INVITE-usage means that the lifetime issues can be ignored: > >>>> terminate the call, and INTIFY no longer has a context. > >>>> > >>>> This neatly avoids violating the letter of the > dialogusage draft, > >>>> but you could probably argue that creating sub-usages of the > >>>> INVITE-usage isn't necessarily in keeping with the > spirit of the draft... > >>>> > >>>> Regards, > >>>> > >>>> Michael > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>> Sent: 19 October 2007 07:41 > >>>>> To: Adam Roach; Paul Kyzivat > >>>>> Cc: sip; Brian Stucker > >>>>> Subject: RE: [Sip] INFO > >>>>> > >>>>> Adam, > >>>>> > >>>>> Now that you have reminded us of the dialogusage draft, > perhaps it > >>>>> would be appropriate to remind people of the following from the > >>>>> abstract: > >>>>> "This memo argues that multiple dialog usages should be > avoided.=20 > >>>>> It discusses alternatives to their use and clarifies essential > >>>>> behavior for elements that cannot currently avoid them." > >>>>> In other words, while it will only be an Informational RFC, it > >>>>> seems to deprecate introduction of further dialog > reuses. So if we > >>>>> were to go with NOTIFY, would this be a new dialog > usage, and if > >>>>> so, > >>>> do we really > >>>>> want to go ahead with something in contradiction to the > sentiment > >>>>> of that recently-approved draft? > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>> Sent: 19 October 2007 01:05 > >>>>>> To: Paul Kyzivat > >>>>>> Cc: sip; Brian Stucker > >>>>>> Subject: Re: [Sip] INFO > >>>>>> > >>>>>> Paul Kyzivat wrote: > >>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>> is INFO. It > >>>>>>> is my impression that INFO was designed for use with > INVITE, and > >>>>> so > >>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>> And Robert > >>>>>>> specified it that way in the dialogusage draft. > >>>>>> You're correct. I had forgotten about that, and the dialogusage > >>>>> draft > >>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>> 2976 predates > >>>>>> the current terminology, but a quick re-read does show > that it's > >>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>> This list is for NEW development of the core SIP Protocol Use > >>>>>> sip-implementors@cs.columbia.edu for questions on > current sip Use > >>>>>> sipping@ietf.org for new developments on the > >>>> application of sip > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol Use > >>>>> sip-implementors@cs.columbia.edu for questions on > current sip Use > >>>>> sipping@ietf.org for new developments on the application of sip > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 17:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiz6b-0003XG-4G; Fri, 19 Oct 2007 17:10:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iiz6Z-0003RH-HA for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 17:10:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiz6Y-0003Dk-EV for sip@ietf.org; Fri, 19 Oct 2007 17:10:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iiz6R-00064j-Ry for sip@ietf.org; Fri, 19 Oct 2007 17:09:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 336AE20F21; Fri, 19 Oct 2007 23:09:55 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-7d-47191d23d05e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C5C620400; Fri, 19 Oct 2007 23:09:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 23:09:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Fri, 19 Oct 2007 23:09:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgScL9gl0lr4O3BTcaN77kGrmh1CQAImIgl References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Brian Stucker" X-OriginalArrivalTime: 19 Oct 2007 21:09:54.0589 (UTC) FILETIME=[6568DCD0:01C81294] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org Hi, =20 One potential issue: the stateful intermediate receives a NOTIFY without = any previous SUBSCRIBE. Is there a chance it would act on this, e.g. by = sending a 4xx response, or are we sure it would always simply forward = the NOTIFY and assume the endpoint will handle it? =20 Regards, =20 Christer =20 =20 ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Fri 19/10/2007 18:52 To: Brian Stucker Cc: sip; Adam Roach; Michael Procter; Elwell,John Subject: Re: [Sip] INFO Brian Stucker wrote: > If we're going to change the way that error messages are handled that > are returned for NOTIFY messages isn't it going to be a bit = complicated > to determine at the transaction layer if the NOTIFY was negotiated via > INVITE or via SUBSCRIBE? > > I mean, the endpoints may know what's going on, but boxes in the = middle > might not. I don't see any reason why *proxy* middle boxes need to know anything about this. B2BUAs will need to know, but then they will know. > I'm a bit concerned that by tweaking 3265 in this way we're going to > move more complexity into all subscription processing whether it's a > usage within a dialog, a separate dialog or this new thing. It would only affect those that support it. And I don't think it will be a big deal, but then this is just speculation at this point, since no details have been worked out. Its always possible that it would turn into a mess. Paul > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 19, 2007 10:55 AM >> To: Hadriel Kaplan >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >> Brian (RICH1:AR00) >> Subject: Re: [Sip] INFO >> >> >> >> Hadriel Kaplan wrote: >>> Which is one of the reasons I think it should be INFO.=20 >> Using it would only be an update to rfc2976, right? >>> -hadriel >> I don't think the distinction is significant. Either way it >> should be designed to be backward compatible. And neither way >> will require actually changing those other documents. >> >> Using NOTIFY: >> >> - will need some new header(s) in INVITE and responses to >> negotiate this >> new capability within the invite dialog usage. >> >> - once that is done it will have established some new rules for using >> NOTIFY in that context. This will not be used unless negotiated, >> so there aren't any backward compatibility issues. >> >> - for those that *do* support this, the same code should ideally be >> able to use either this technique or real subscriptions, with only >> minor tweaks. >> >> - I would expect that any event packages defined in the future that >> could meaningfully be used in this way would be designed from the >> ground up to support both styles. >> >> Using INFO: >> >> - I don't think it will be sufficient to just add headers to >> NOTIFY itself. IMO there still needs to be negotiation of >> the particular usages of NOTIFY. So there still need to be >> new header(s) in invite and responses. >> >> - once the negotiation is done there will need to be some new >> header(s) to provide added context for the INFO. >> >> - any usage that currently has an event package would have >> to be modified to be used with INFO. >> >> Bottom line - I think a "lighter weight" subscription >> mechanism serves all the same needs that an enhanced INFO >> does, is no harder to implement, and has other benefits. >> =20 >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, October 19, 2007 7:48 AM >>>> To: Elwell, John >>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>> Subject: Re: [Sip] INFO >>>> >>>> Yes, my thinking has been that this would be a matter of >> negotiating >>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>> isn't legal today - this would be an extension to both >> 3261 and 3265. >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> Michael, >>>>> >>>>> Yes, I guess some of the postings on this thread have >> hinted that it >>>>> would be the same dialog usage. I suppose if the >> subscriptions are >>>>> deemed to terminate at the time of the BYE transaction, then it >>>>> would indeed by the same dialog usage. So it would appear to be >>>>> within the letter of the dialogusage draft. However, one or two >>>>> postings have suggested different. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>>>> Sent: 19 October 2007 08:48 >>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>> Cc: sip; Brian Stucker >>>>>> Subject: RE: [Sip] INFO >>>>>> >>>>>> John, >>>>>> >>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>> INTIFY as Christer suggests) in this way would not >> constitute a new >>>>>> dialog-usage. A new usage would imply periodic >> resubscription and >>>>>> specific termination, whereas sending INTIFY within the >> context of >>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>> terminate the call, and INTIFY no longer has a context. >>>>>> >>>>>> This neatly avoids violating the letter of the >> dialogusage draft, >>>>>> but you could probably argue that creating sub-usages of the >>>>>> INVITE-usage isn't necessarily in keeping with the >> spirit of the draft... >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>> Sent: 19 October 2007 07:41 >>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>> Cc: sip; Brian Stucker >>>>>>> Subject: RE: [Sip] INFO >>>>>>> >>>>>>> Adam, >>>>>>> >>>>>>> Now that you have reminded us of the dialogusage draft, >> perhaps it >>>>>>> would be appropriate to remind people of the following from the >>>>>>> abstract: >>>>>>> "This memo argues that multiple dialog usages should be >> avoided.=20 >>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>> behavior for elements that cannot currently avoid them." >>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>> seems to deprecate introduction of further dialog >> reuses. So if we >>>>>>> were to go with NOTIFY, would this be a new dialog >> usage, and if >>>>>>> so, >>>>>> do we really >>>>>>> want to go ahead with something in contradiction to the >> sentiment >>>>>>> of that recently-approved draft? >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>> To: Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: Re: [Sip] INFO >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>> is INFO. It >>>>>>>>> is my impression that INFO was designed for use with >> INVITE, and >>>>>>> so >>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>> And Robert >>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>>>> draft >>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>> 2976 predates >>>>>>>> the current terminology, but a quick re-read does show >> that it's >>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>> >>>>>>>> /a >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>>>>> sipping@ietf.org for new developments on the >>>>>> application of sip >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>>>> sipping@ietf.org for new developments on the application of sip >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 18:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij09l-0002S7-7i; Fri, 19 Oct 2007 18:17:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij09j-0002Rl-Go for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 18:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij09i-0002QP-Ft for sip@ietf.org; Fri, 19 Oct 2007 18:17:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij09b-0005gz-MF for sip@ietf.org; Fri, 19 Oct 2007 18:17:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,302,1188802800"; d="scan'208";a="181751479" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2007 15:17:12 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9JMHCHL009867; Fri, 19 Oct 2007 15:17:12 -0700 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 l9JMH4bF004100; Fri, 19 Oct 2007 22:17:05 GMT 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.1830); Fri, 19 Oct 2007 18:17:04 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 18:17:03 -0400 Message-ID: <47192CDF.3050804@cisco.com> Date: Fri, 19 Oct 2007 18:17:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471918CA.5010103@zonnet.nl> In-Reply-To: <471918CA.5010103@zonnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 22:17:04.0015 (UTC) FILETIME=[C72279F0:01C8129D] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--19.158700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2336; t=1192832232; x=1193696232; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=Mp0KRI9yEY2Brby5FJ+3E5jeHM0WLJLR9Up4Hzl4M1M=; b=PimioxK8fU5wwi9+xBs4BpualG433eiz37PwUuSOp/O9sVDmIzfEg3qrxwbz5NVmzXI2S7hv ryzS/dqjp9FmI4HKCBklpAMMeOzjap9NVAGBJnCkR7y2jPREkkzrnzaq; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Paul, >> >> I don't see any reason why *proxy* middle boxes need to know anything >> about this. B2BUAs will need to know, but then they will know. >> > There are (as always) subtle differences. NOTIFY for SUBSCRIBE is needed > to handle forking (proxies pass at most 1 2xx response for SUBSCRIBE), > while NOTIFY for INVITE would not be needed for this reason. Proxies > Record-Route NOTIFY due to the above reason, they could avoid doing that > for INVITE-NOTIFYs. I don't follow. If the proxy was going to R-R, it needed to do so in the SUBSCRIBE. (Or it wouldn't even see the NOTIFY.) If its doing asymmetric R-R then it may need to update the R-R entry, but that is conditional on the entry it put there in the SUBSCRIBE. The UAS for the NOTIFY needs to recognize if it establishes a new dialog and if so remember the R-R, but again that doesn't impact a proxy. > Record-Routing INFO is useless and somewhat > wasteful, so well designed proxies don't do that. > > Also, I assume there will be no need to "immediately send NOTIFY" for > INVITE-based events. True. But that again is a matter for the UAC and UAS, not the proxies. > All in all, IMO using INFO instead of NOTIFY here is preferrable (also > given that existing implementations already use INFO within INVITE > dialogs). No matter what we do, the existing standardized uses of INFO will remain. And I think it is safe to assume that the existing *unstandardized* uses of INFO will not do the kind of negotiation we are talking about, so they won't carry over directly. So we are really only talking about new things. If we use NOTIFY, then existing, already standardized event packages can (hopefully) be easily adapted to support the new technique as well as the old. Because the semantics of the package wouldn't change, I would hope that it would be easy to get those changes adopted. If we use INFO, then I guess we can hopefully easily adapt existing non-standard INFO usages. But because they haven't been standardized, that may be more difficult. I suppose one could adapt existing event packages to use INFO for this style and NOTIFY for freestanding subscriptions. Mechanically its not a big deal, but it certainly seems odd. Thanks, 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 19 18:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0Kd-0007eI-HU; Fri, 19 Oct 2007 18:28:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij0Kb-0007e9-F1 for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 18:28:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0Ka-0007dU-Kf for sip@ietf.org; Fri, 19 Oct 2007 18:28:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij0KZ-0000m8-Qn for sip@ietf.org; Fri, 19 Oct 2007 18:28:36 -0400 X-IronPort-AV: E=Sophos;i="4.21,302,1188802800"; d="scan'208";a="239993867" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2007 15:28:34 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9JMSYsd028908; Fri, 19 Oct 2007 18:28:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9JMSH8X029382; Fri, 19 Oct 2007 22:28:17 GMT 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.1830); Fri, 19 Oct 2007 18:28:17 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 18:28:16 -0400 Message-ID: <47192F80.4040308@cisco.com> Date: Fri, 19 Oct 2007 18:28:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 22:28:16.0939 (UTC) FILETIME=[583A87B0:01C8129F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--36.423200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4559; t=1192832914; x=1193696914; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=XpBMGbzIeVt1AF9jb/cV5XqvFLukkAYc5Q6BJ51VTUI=; b=vAt205zlqipXdLQeeNg73HfGVqseApmMciUASK/ZRc7Bn1h9J5Qcb3xM27dK9sbogOS94b9G //USdjFjARxrX03leqYBvETiV2G2j7UV7edIOyfTDjxPGlZZlFKuSuRk; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip , Adam Roach , Michael Procter , "Elwell, John" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> I don't think the distinction is significant. Either way it should be >> designed to be backward compatible. And neither way will require >> actually changing those other documents. >> >> Using NOTIFY: >> >> - will need some new header(s) in INVITE and responses to negotiate this >> new capability within the invite dialog usage. > > No matter which Method gets used, there will need to be some new header(s) in INVITE to negotiate. So that's equal. > > >> - once that is done it will have established some new rules for using >> NOTIFY in that context. This will not be used unless negotiated, >> so there aren't any backward compatibility issues. >> >> - for those that *do* support this, the same code should ideally be >> able to use either this technique or real subscriptions, with only >> minor tweaks. > > I don't see how that's knowable. For one, code is obviously implementation dependent. For another, we would be changing the way in which subscribe bodies could be sent (i.e., they wouldn't, not in the subscription-creation), the handling of subscription duration, and adding a directional negotiation mechanism. I agree this is speculation. > Lastly, you don't *have* to support rfc3265 at all to support 3261, so the code change could be quite a bit more. For somebody that doesn't support 3265, and doesn't want to, but that does want to support these new packages within an INVITE, this is all new implementation in any case. Sure, it would require supporting the NOTIFY *method*, as it is used in this new usage. But the hard work is in supporting the packages, not the method. And that part is the same either way. >> - I would expect that any event packages defined in the future that >> could meaningfully be used in this way would be designed from the >> ground up to support both styles. > > True of both cases, I presume. So you are assuming that we would define packages that use a common encoding and semantics for messages, but that convey them in NOTIFY for subscriptions and in INFO for invite-dialog usage? That is certainly possible. It just seems unappealing to me. >> Using INFO: >> >> - I don't think it will be sufficient to just add headers to >> NOTIFY itself. IMO there still needs to be negotiation of >> the particular usages of NOTIFY. So there still need to be >> new header(s) in invite and responses. > > I'm confused by this - did you mean INFO, and just that the INVITE needs the negotiation headers (as it does for NOTIFY)? Sorry - yes I typed NOTIFY where I meant INFO. :-( >> - once the negotiation is done there will need to be some new >> header(s) to provide added context for the INFO. >> >> - any usage that currently has an event package would have >> to be modified to be used with INFO. > > Any current event-package could not simply be used in a NOTIFY model either, for the reason you pointed out in an earlier email: we wouldn't want the package's subscribe body to be in the Invite. And really there are some that would be illogical to do so (like reg-event). So in that sense it's a wash: any current event-package wanting to be used would need an extension to say so and how, and any future ones would need to define whether or not they support this new Invite-Notify/INFO and how. > > >> Bottom line - I think a "lighter weight" subscription mechanism serves >> all the same needs that an enhanced INFO does, is no harder to >> implement, and has other benefits. > > That's assuming we need to actually make this create a real Subscription. That would mean you'd be including all the concepts of Subscribe usages in an Invite-created dialog, having two usages in the same dialog, etc. Since the lifetime, relationship, context, usage, etc., between the Invite and event-notification is inexorably linked, there is no need for a real Subscription. And we already have a method that has that direct relationship to Invite: INFO. By "lighter weight subscription model" I mean negotiating the use of the event package within the invite dialog usage. Its still a subscription in some sense, but isn't independently refreshed or expired. Regardless of INFO or NOTIFY, are we converging on using an adaptation of the event package template for defining such a thing - one that ideally would support both styles of 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 19 18:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0QU-0005C4-Uh; Fri, 19 Oct 2007 18:34:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij0QS-00058s-EQ for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 18:34:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij0QR-00054q-4S for sip@ietf.org; Fri, 19 Oct 2007 18:34:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij0QQ-0000wj-3d for sip@ietf.org; Fri, 19 Oct 2007 18:34:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,302,1188792000"; d="scan'208";a="74361188" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2007 18:34:37 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9JMYbJA029767; Fri, 19 Oct 2007 18:34:37 -0400 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 l9JMYWkD009324; Fri, 19 Oct 2007 22:34:37 GMT 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.1830); Fri, 19 Oct 2007 18:34:33 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 18:34:33 -0400 Message-ID: <471930F9.3060207@cisco.com> Date: Fri, 19 Oct 2007 18:34:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 22:34:33.0455 (UTC) FILETIME=[38A64FF0:01C812A0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--42.159200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9891; t=1192833277; x=1193697277; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=T0cyoGMpWyNI3pMNEVkoYOhRIFjYkvLKPdyiXBCea/g=; b=HiapTov4jRRqUGLAdke1GpVMLm2+Sx03CeRIy5KEC5QcKV4xalZwVbLp67Fl9SJAAycb+ey1 Ux2A0NRjZWhmaxT2f7v4YO/Lr4UTh6oRNrgnLLwMVXcg62oJSZpzDvnW; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > > One potential issue: the stateful intermediate receives a NOTIFY without any previous SUBSCRIBE. Is there a chance it would act on this, e.g. by sending a 4xx response, or are we sure it would always simply forward the NOTIFY and assume the endpoint will handle it? Are you talking about a B2BUA or a proxy? If a B2BUA, it suffers the common problem that it needs to be aware of pretty much all the standards in use by those it is connecting. If it was not aware of this new extension, and it was trying to enforce rules about what messages are allowed in what contexts, then yes it might cause trouble. But we specify stuff all the time that has similar issues with B2BUAs. Its up to B2BUAs to figure out how to be transparent or else go away. If its a proxy it has no business making such a judgment. Paul > Regards, > > Christer > > > > ________________________________ > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Fri 19/10/2007 18:52 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > > > Brian Stucker wrote: >> If we're going to change the way that error messages are handled that >> are returned for NOTIFY messages isn't it going to be a bit complicated >> to determine at the transaction layer if the NOTIFY was negotiated via >> INVITE or via SUBSCRIBE? >> >> I mean, the endpoints may know what's going on, but boxes in the middle >> might not. > > I don't see any reason why *proxy* middle boxes need to know anything > about this. B2BUAs will need to know, but then they will know. > >> I'm a bit concerned that by tweaking 3265 in this way we're going to >> move more complexity into all subscription processing whether it's a >> usage within a dialog, a separate dialog or this new thing. > > It would only affect those that support it. > > And I don't think it will be a big deal, but then this is just > speculation at this point, since no details have been worked out. Its > always possible that it would turn into a mess. > > Paul > >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Friday, October 19, 2007 10:55 AM >>> To: Hadriel Kaplan >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >>> Brian (RICH1:AR00) >>> Subject: Re: [Sip] INFO >>> >>> >>> >>> Hadriel Kaplan wrote: >>>> Which is one of the reasons I think it should be INFO. >>> Using it would only be an update to rfc2976, right? >>>> -hadriel >>> I don't think the distinction is significant. Either way it >>> should be designed to be backward compatible. And neither way >>> will require actually changing those other documents. >>> >>> Using NOTIFY: >>> >>> - will need some new header(s) in INVITE and responses to >>> negotiate this >>> new capability within the invite dialog usage. >>> >>> - once that is done it will have established some new rules for using >>> NOTIFY in that context. This will not be used unless negotiated, >>> so there aren't any backward compatibility issues. >>> >>> - for those that *do* support this, the same code should ideally be >>> able to use either this technique or real subscriptions, with only >>> minor tweaks. >>> >>> - I would expect that any event packages defined in the future that >>> could meaningfully be used in this way would be designed from the >>> ground up to support both styles. >>> >>> Using INFO: >>> >>> - I don't think it will be sufficient to just add headers to >>> NOTIFY itself. IMO there still needs to be negotiation of >>> the particular usages of NOTIFY. So there still need to be >>> new header(s) in invite and responses. >>> >>> - once the negotiation is done there will need to be some new >>> header(s) to provide added context for the INFO. >>> >>> - any usage that currently has an event package would have >>> to be modified to be used with INFO. >>> >>> Bottom line - I think a "lighter weight" subscription >>> mechanism serves all the same needs that an enhanced INFO >>> does, is no harder to implement, and has other benefits. >>> >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Friday, October 19, 2007 7:48 AM >>>>> To: Elwell, John >>>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>>> Subject: Re: [Sip] INFO >>>>> >>>>> Yes, my thinking has been that this would be a matter of >>> negotiating >>>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>>> isn't legal today - this would be an extension to both >>> 3261 and 3265. >>>>> Paul >>>>> >>>>> Elwell, John wrote: >>>>>> Michael, >>>>>> >>>>>> Yes, I guess some of the postings on this thread have >>> hinted that it >>>>>> would be the same dialog usage. I suppose if the >>> subscriptions are >>>>>> deemed to terminate at the time of the BYE transaction, then it >>>>>> would indeed by the same dialog usage. So it would appear to be >>>>>> within the letter of the dialogusage draft. However, one or two >>>>>> postings have suggested different. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>>>>> Sent: 19 October 2007 08:48 >>>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>>> Cc: sip; Brian Stucker >>>>>>> Subject: RE: [Sip] INFO >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>>> INTIFY as Christer suggests) in this way would not >>> constitute a new >>>>>>> dialog-usage. A new usage would imply periodic >>> resubscription and >>>>>>> specific termination, whereas sending INTIFY within the >>> context of >>>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>>> terminate the call, and INTIFY no longer has a context. >>>>>>> >>>>>>> This neatly avoids violating the letter of the >>> dialogusage draft, >>>>>>> but you could probably argue that creating sub-usages of the >>>>>>> INVITE-usage isn't necessarily in keeping with the >>> spirit of the draft... >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>>> Sent: 19 October 2007 07:41 >>>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: RE: [Sip] INFO >>>>>>>> >>>>>>>> Adam, >>>>>>>> >>>>>>>> Now that you have reminded us of the dialogusage draft, >>> perhaps it >>>>>>>> would be appropriate to remind people of the following from the >>>>>>>> abstract: >>>>>>>> "This memo argues that multiple dialog usages should be >>> avoided. >>>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>>> behavior for elements that cannot currently avoid them." >>>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>>> seems to deprecate introduction of further dialog >>> reuses. So if we >>>>>>>> were to go with NOTIFY, would this be a new dialog >>> usage, and if >>>>>>>> so, >>>>>>> do we really >>>>>>>> want to go ahead with something in contradiction to the >>> sentiment >>>>>>>> of that recently-approved draft? >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>>> To: Paul Kyzivat >>>>>>>>> Cc: sip; Brian Stucker >>>>>>>>> Subject: Re: [Sip] INFO >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>>> is INFO. It >>>>>>>>>> is my impression that INFO was designed for use with >>> INVITE, and >>>>>>>> so >>>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>>> And Robert >>>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>>>>> draft >>>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>>> 2976 predates >>>>>>>>> the current terminology, but a quick re-read does show >>> that it's >>>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>>> >>>>>>>>> /a >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>>>>> sipping@ietf.org for new developments on the >>>>>>> application of sip >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>>>> sipping@ietf.org for new developments on the application of sip >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 20:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2PV-0008Iz-Do; Fri, 19 Oct 2007 20:41:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij2PU-0008Is-1M for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 20:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij2PT-0008Gv-1V for sip@ietf.org; Fri, 19 Oct 2007 20:41:47 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij2PG-0000rh-Hr for sip@ietf.org; Fri, 19 Oct 2007 20:41:42 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 19 Oct 2007 20:41:25 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 19 Oct 2007 20:41:25 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 19 Oct 2007 20:40:19 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgSn5O1tdxD+NJiTpCj7m8ymoWcYQADwsMA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471918CA.5010103@zonnet.nl> <47192CDF.3050804@cisco.com> In-Reply-To: <47192CDF.3050804@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Jeroen van Bemmel wrote: > > All in all, IMO using INFO instead of NOTIFY here is preferrable (also > > given that existing implementations already use INFO within INVITE > > dialogs). > > No matter what we do, the existing standardized uses of INFO will remain. > > And I think it is safe to assume that the existing *unstandardized* uses > of INFO will not do the kind of negotiation we are talking about, so > they won't carry over directly. > > So we are really only talking about new things. Actually, I'm not so sure of that. I don't know how many would do it, but = I think making it as painless/trivial as possible increases the odds of imp= lementation and thus upgrade. And following Christer's point, I think it a= lso gives an existence proof that INFO as a method will make it through mos= t anything along the path to the UA. -hadriel p.s. FWIW, I know my employer would implement it; but I don't think it matt= ers much to us whether it's Notify or Info. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 19 21:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij3Bn-0008AA-SD; Fri, 19 Oct 2007 21:31:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij3Bm-00088i-Al for sip-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 21:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij3Bl-00083h-Bp for sip@ietf.org; Fri, 19 Oct 2007 21:31:41 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij3Bc-000261-7Q for sip@ietf.org; Fri, 19 Oct 2007 21:31:38 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Fri, 19 Oct 2007 21:31:26 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 19 Oct 2007 21:31:26 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 19 Oct 2007 21:30:18 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgSn3FtPCWv+g5CQKOoUy6c0515OgAEncyw Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> In-Reply-To: <47192F80.4040308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Hadriel Kaplan wrote: > > For somebody that doesn't support 3265, and doesn't want to, but that > does want to support these new packages within an INVITE, this is all > new implementation in any case. Sure, it would require supporting the > NOTIFY *method*, as it is used in this new usage. But the hard work is > in supporting the packages, not the method. And that part is the same > either way. > > >> - I would expect that any event packages defined in the future that > >> could meaningfully be used in this way would be designed from the > >> ground up to support both styles. > > > > True of both cases, I presume. > > So you are assuming that we would define packages that use a common > encoding and semantics for messages, but that convey them in NOTIFY for > subscriptions and in INFO for invite-dialog usage? > > That is certainly possible. It just seems unappealing to me. Turning the tables on you: what does the method name matter? :) For one thing, it's explicit - INFO would be for notifications tied to an I= nvite dialog and usage, but not integral to its usage. I.e., exactly what = it meant before. It would just have a new "Event"-type header, and the Inv= ite transaction would have carried negotiation for which events could be us= ed - neither of which require a new method name. I guess one question is which Method is more appropriate, given the dialog-= usage draft. The other question is: are we really creating an implicitly-signaled Subscr= iption. In other words, is the Invite really like REFER in this regard? I= f so, then we're really saying one should be able to send a Notify with sub= scription-state terminated, or with an expires parameter and needing refres= h with a Subscribe. Meanwhile we already have an expires mechanism for Inv= ite sessions, and it really means the Notify is tied to some second usage o= ther than the Invite's. What would a Notify with a subscription-state of "= terminated" mean in this new mechanism? (or would that header not be includ= ed?) If we're not doing that stuff, then there is no real, distinct Subscr= iption a la Notify, and using INFO would be clear about that. > By "lighter weight subscription model" I mean negotiating the use of the > event package within the invite dialog usage. Its still a subscription > in some sense, but isn't independently refreshed or expired. Then why use a method name that has those traits? There really is NOT a Su= bscription in the 3265 sense of the word, is there? -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 20 02:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij7XV-0002O2-Sa; Sat, 20 Oct 2007 02:10:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ij7XT-0002M2-E9 for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 02:10:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij7XS-0002ID-Cd for sip@ietf.org; Sat, 20 Oct 2007 02:10:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ij7XO-0004GP-V0 for sip@ietf.org; Sat, 20 Oct 2007 02:10:20 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B185D205EB; Sat, 20 Oct 2007 08:10:17 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-e0-47199bc9a93a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9437D204FC; Sat, 20 Oct 2007 08:10:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Oct 2007 08:10:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sat, 20 Oct 2007 08:08:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgSoEDCE0jWBPYZTveMth+TtKrClAAP2zFR References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 Oct 2007 06:10:17.0151 (UTC) FILETIME=[E2C334F0:01C812DF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hi Paul, =20 I am talking about a proxy. =20 So, you are saying that the proxy would always forward the NOTIFY, even = if it does not have any state of a subscription dialog, or subscription = usage within a dialog? =20 Regards, =20 Christer ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Sat 20/10/2007 00:34 To: Christer Holmberg Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John Subject: Re: [Sip] INFO Christer Holmberg wrote: > Hi, >=20 > One potential issue: the stateful intermediate receives a NOTIFY = without any previous SUBSCRIBE. Is there a chance it would act on this, = e.g. by sending a 4xx response, or are we sure it would always simply = forward the NOTIFY and assume the endpoint will handle it? Are you talking about a B2BUA or a proxy? If a B2BUA, it suffers the common problem that it needs to be aware of pretty much all the standards in use by those it is connecting. If it was not aware of this new extension, and it was trying to enforce rules about what messages are allowed in what contexts, then yes it might cause trouble. But we specify stuff all the time that has similar issues with B2BUAs. Its up to B2BUAs to figure out how to be transparent or else go away. If its a proxy it has no business making such a judgment. Paul > Regards, >=20 > Christer >=20 >=20 > > ________________________________ > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Fri 19/10/2007 18:52 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > > > Brian Stucker wrote: >> If we're going to change the way that error messages are handled that >> are returned for NOTIFY messages isn't it going to be a bit = complicated >> to determine at the transaction layer if the NOTIFY was negotiated = via >> INVITE or via SUBSCRIBE? >> >> I mean, the endpoints may know what's going on, but boxes in the = middle >> might not. > > I don't see any reason why *proxy* middle boxes need to know anything > about this. B2BUAs will need to know, but then they will know. > >> I'm a bit concerned that by tweaking 3265 in this way we're going to >> move more complexity into all subscription processing whether it's a >> usage within a dialog, a separate dialog or this new thing. > > It would only affect those that support it. > > And I don't think it will be a big deal, but then this is just > speculation at this point, since no details have been worked out. Its > always possible that it would turn into a mess. > > Paul > >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Friday, October 19, 2007 10:55 AM >>> To: Hadriel Kaplan >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >>> Brian (RICH1:AR00) >>> Subject: Re: [Sip] INFO >>> >>> >>> >>> Hadriel Kaplan wrote: >>>> Which is one of the reasons I think it should be INFO. >>> Using it would only be an update to rfc2976, right? >>>> -hadriel >>> I don't think the distinction is significant. Either way it >>> should be designed to be backward compatible. And neither way >>> will require actually changing those other documents. >>> >>> Using NOTIFY: >>> >>> - will need some new header(s) in INVITE and responses to >>> negotiate this >>> new capability within the invite dialog usage. >>> >>> - once that is done it will have established some new rules for = using >>> NOTIFY in that context. This will not be used unless negotiated, >>> so there aren't any backward compatibility issues. >>> >>> - for those that *do* support this, the same code should ideally be >>> able to use either this technique or real subscriptions, with = only >>> minor tweaks. >>> >>> - I would expect that any event packages defined in the future that >>> could meaningfully be used in this way would be designed from the >>> ground up to support both styles. >>> >>> Using INFO: >>> >>> - I don't think it will be sufficient to just add headers to >>> NOTIFY itself. IMO there still needs to be negotiation of >>> the particular usages of NOTIFY. So there still need to be >>> new header(s) in invite and responses. >>> >>> - once the negotiation is done there will need to be some new >>> header(s) to provide added context for the INFO. >>> >>> - any usage that currently has an event package would have >>> to be modified to be used with INFO. >>> >>> Bottom line - I think a "lighter weight" subscription >>> mechanism serves all the same needs that an enhanced INFO >>> does, is no harder to implement, and has other benefits. >>> =20 >>> Thanks, >>> Paul >>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Friday, October 19, 2007 7:48 AM >>>>> To: Elwell, John >>>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>>> Subject: Re: [Sip] INFO >>>>> >>>>> Yes, my thinking has been that this would be a matter of >>> negotiating >>>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>>> isn't legal today - this would be an extension to both >>> 3261 and 3265. >>>>> Paul >>>>> >>>>> Elwell, John wrote: >>>>>> Michael, >>>>>> >>>>>> Yes, I guess some of the postings on this thread have >>> hinted that it >>>>>> would be the same dialog usage. I suppose if the >>> subscriptions are >>>>>> deemed to terminate at the time of the BYE transaction, then it >>>>>> would indeed by the same dialog usage. So it would appear to be >>>>>> within the letter of the dialogusage draft. However, one or two >>>>>> postings have suggested different. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>>>>> Sent: 19 October 2007 08:48 >>>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>>> Cc: sip; Brian Stucker >>>>>>> Subject: RE: [Sip] INFO >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>>> INTIFY as Christer suggests) in this way would not >>> constitute a new >>>>>>> dialog-usage. A new usage would imply periodic >>> resubscription and >>>>>>> specific termination, whereas sending INTIFY within the >>> context of >>>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>>> terminate the call, and INTIFY no longer has a context. >>>>>>> >>>>>>> This neatly avoids violating the letter of the >>> dialogusage draft, >>>>>>> but you could probably argue that creating sub-usages of the >>>>>>> INVITE-usage isn't necessarily in keeping with the >>> spirit of the draft... >>>>>>> Regards, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>>> Sent: 19 October 2007 07:41 >>>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: RE: [Sip] INFO >>>>>>>> >>>>>>>> Adam, >>>>>>>> >>>>>>>> Now that you have reminded us of the dialogusage draft, >>> perhaps it >>>>>>>> would be appropriate to remind people of the following from the >>>>>>>> abstract: >>>>>>>> "This memo argues that multiple dialog usages should be >>> avoided. >>>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>>> behavior for elements that cannot currently avoid them." >>>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>>> seems to deprecate introduction of further dialog >>> reuses. So if we >>>>>>>> were to go with NOTIFY, would this be a new dialog >>> usage, and if >>>>>>>> so, >>>>>>> do we really >>>>>>>> want to go ahead with something in contradiction to the >>> sentiment >>>>>>>> of that recently-approved draft? >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>>> To: Paul Kyzivat >>>>>>>>> Cc: sip; Brian Stucker >>>>>>>>> Subject: Re: [Sip] INFO >>>>>>>>> >>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>>> is INFO. It >>>>>>>>>> is my impression that INFO was designed for use with >>> INVITE, and >>>>>>>> so >>>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>>> And Robert >>>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>>> You're correct. I had forgotten about that, and the = dialogusage >>>>>>>> draft >>>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>>> 2976 predates >>>>>>>>> the current terminology, but a quick re-read does show >>> that it's >>>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>>> >>>>>>>>> /a >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>>>>> sipping@ietf.org for new developments on the >>>>>>> application of sip >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>>>> sipping@ietf.org for new developments on the application of sip >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 20 10:34:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjFGI-0004Qt-Vr; Sat, 20 Oct 2007 10:25:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjFGG-0004Op-1H for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 10:25:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjFGE-0004OM-Un for sip@ietf.org; Sat, 20 Oct 2007 10:25:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjFGD-00038V-Oz for sip@ietf.org; Sat, 20 Oct 2007 10:25:06 -0400 X-IronPort-AV: E=Sophos;i="4.21,303,1188792000"; d="scan'208";a="74399342" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2007 10:25:03 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9KEP3tI016997; Sat, 20 Oct 2007 10:25:03 -0400 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 l9KEOkk7017568; Sat, 20 Oct 2007 14:24:46 GMT 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.1830); Sat, 20 Oct 2007 10:24:45 -0400 Received: from [10.86.242.117] ([10.86.242.117]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Oct 2007 10:24:45 -0400 Message-ID: <471A0FAC.2090101@cisco.com> Date: Sat, 20 Oct 2007 10:24:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2007 14:24:45.0461 (UTC) FILETIME=[F6740C50:01C81324] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--33.140500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12039; t=1192890303; x=1193754303; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Christer=20Holmberg=20; bh=L0eFW78P6AI4VViQ+b7ktZU4s8I+QF+fKqobLqrWxHk=; b=wlEW5WlfMBGOEmdMIQz+29EX33Vf/GpTTsUaLuqJDvN4YpvJ+OL38mZrV/8BKY+gXnVLv/Qg 1eKm5snvaVy+b5UyFTrUkKYNLUnnWvBhV+dFK7MOedLXzpV2HwFOnBbJ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi Paul, > > I am talking about a proxy. > > So, you are saying that the proxy would always forward the NOTIFY, even if it does not have any state of a subscription dialog, or subscription usage within a dialog? Well... There are transaction-stateless proxies, and transaction-stateful proxies, and dialog-stateful proxies. Only a dialog-stateful proxy could make the kind of decision you are talking about. AFAIK there is very little written about dialog-stateful proxies. I think perhaps they have little utility, and have been superseded by B2BUAs. So there isn't a lot to go on in determining what they are permitted to do. In general I think a "proxy" is only permitted to return an error to a request if it: - isn't able to forward as requested - is carrying out policy on behalf of the sender or the recipient. (I suppose policy of the carrier also applies on the assumption that the caller or callee select the carrier and hence implicitly agree to its policies.) My personal opinion is that the kind of checking you are talking about is just "meddling" in the affairs of the UAs, and should not be done. But I suppose one might desire a policy that enforces standards in this way. But if so, as a UA I don't want my agents enforcing policies that prevent valid usages by my UA. Perhaps Hadriel would like to comment on this. His company makes SBCs that I think are in the business of sticking their nose into other people's sip usage and policing it. Do they do this kind of enforcement? Paul > Regards, > > Christer > > ________________________________ > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sat 20/10/2007 00:34 > To: Christer Holmberg > Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > > > Christer Holmberg wrote: >> Hi, >> >> One potential issue: the stateful intermediate receives a NOTIFY without any previous SUBSCRIBE. Is there a chance it would act on this, e.g. by sending a 4xx response, or are we sure it would always simply forward the NOTIFY and assume the endpoint will handle it? > > Are you talking about a B2BUA or a proxy? > > If a B2BUA, it suffers the common problem that it needs to be aware of > pretty much all the standards in use by those it is connecting. > > If it was not aware of this new extension, and it was trying to enforce > rules about what messages are allowed in what contexts, then yes it > might cause trouble. But we specify stuff all the time that has similar > issues with B2BUAs. Its up to B2BUAs to figure out how to be transparent > or else go away. > > If its a proxy it has no business making such a judgment. > > Paul > > >> Regards, >> >> Christer >> >> >> >> ________________________________ >> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Fri 19/10/2007 18:52 >> To: Brian Stucker >> Cc: sip; Adam Roach; Michael Procter; Elwell,John >> Subject: Re: [Sip] INFO >> >> >> >> >> >> Brian Stucker wrote: >>> If we're going to change the way that error messages are handled that >>> are returned for NOTIFY messages isn't it going to be a bit complicated >>> to determine at the transaction layer if the NOTIFY was negotiated via >>> INVITE or via SUBSCRIBE? >>> >>> I mean, the endpoints may know what's going on, but boxes in the middle >>> might not. >> I don't see any reason why *proxy* middle boxes need to know anything >> about this. B2BUAs will need to know, but then they will know. >> >>> I'm a bit concerned that by tweaking 3265 in this way we're going to >>> move more complexity into all subscription processing whether it's a >>> usage within a dialog, a separate dialog or this new thing. >> It would only affect those that support it. >> >> And I don't think it will be a big deal, but then this is just >> speculation at this point, since no details have been worked out. Its >> always possible that it would turn into a mess. >> >> Paul >> >>> Regards, >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, October 19, 2007 10:55 AM >>>> To: Hadriel Kaplan >>>> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, >>>> Brian (RICH1:AR00) >>>> Subject: Re: [Sip] INFO >>>> >>>> >>>> >>>> Hadriel Kaplan wrote: >>>>> Which is one of the reasons I think it should be INFO. >>>> Using it would only be an update to rfc2976, right? >>>>> -hadriel >>>> I don't think the distinction is significant. Either way it >>>> should be designed to be backward compatible. And neither way >>>> will require actually changing those other documents. >>>> >>>> Using NOTIFY: >>>> >>>> - will need some new header(s) in INVITE and responses to >>>> negotiate this >>>> new capability within the invite dialog usage. >>>> >>>> - once that is done it will have established some new rules for using >>>> NOTIFY in that context. This will not be used unless negotiated, >>>> so there aren't any backward compatibility issues. >>>> >>>> - for those that *do* support this, the same code should ideally be >>>> able to use either this technique or real subscriptions, with only >>>> minor tweaks. >>>> >>>> - I would expect that any event packages defined in the future that >>>> could meaningfully be used in this way would be designed from the >>>> ground up to support both styles. >>>> >>>> Using INFO: >>>> >>>> - I don't think it will be sufficient to just add headers to >>>> NOTIFY itself. IMO there still needs to be negotiation of >>>> the particular usages of NOTIFY. So there still need to be >>>> new header(s) in invite and responses. >>>> >>>> - once the negotiation is done there will need to be some new >>>> header(s) to provide added context for the INFO. >>>> >>>> - any usage that currently has an event package would have >>>> to be modified to be used with INFO. >>>> >>>> Bottom line - I think a "lighter weight" subscription >>>> mechanism serves all the same needs that an enhanced INFO >>>> does, is no harder to implement, and has other benefits. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Friday, October 19, 2007 7:48 AM >>>>>> To: Elwell, John >>>>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker >>>>>> Subject: Re: [Sip] INFO >>>>>> >>>>>> Yes, my thinking has been that this would be a matter of >>>> negotiating >>>>>> the use of NOTIFY *within* the invite-dialog-usage. Of course that >>>>>> isn't legal today - this would be an extension to both >>>> 3261 and 3265. >>>>>> Paul >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Michael, >>>>>>> >>>>>>> Yes, I guess some of the postings on this thread have >>>> hinted that it >>>>>>> would be the same dialog usage. I suppose if the >>>> subscriptions are >>>>>>> deemed to terminate at the time of the BYE transaction, then it >>>>>>> would indeed by the same dialog usage. So it would appear to be >>>>>>> within the letter of the dialogusage draft. However, one or two >>>>>>> postings have suggested different. >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Michael Procter [mailto:michael.procter@citel.com] >>>>>>>> Sent: 19 October 2007 08:48 >>>>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat >>>>>>>> Cc: sip; Brian Stucker >>>>>>>> Subject: RE: [Sip] INFO >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> My impression of the discussion so far is that using NOTIFY (or >>>>>>>> INTIFY as Christer suggests) in this way would not >>>> constitute a new >>>>>>>> dialog-usage. A new usage would imply periodic >>>> resubscription and >>>>>>>> specific termination, whereas sending INTIFY within the >>>> context of >>>>>>>> the INVITE-usage means that the lifetime issues can be ignored: >>>>>>>> terminate the call, and INTIFY no longer has a context. >>>>>>>> >>>>>>>> This neatly avoids violating the letter of the >>>> dialogusage draft, >>>>>>>> but you could probably argue that creating sub-usages of the >>>>>>>> INVITE-usage isn't necessarily in keeping with the >>>> spirit of the draft... >>>>>>>> Regards, >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>>>> Sent: 19 October 2007 07:41 >>>>>>>>> To: Adam Roach; Paul Kyzivat >>>>>>>>> Cc: sip; Brian Stucker >>>>>>>>> Subject: RE: [Sip] INFO >>>>>>>>> >>>>>>>>> Adam, >>>>>>>>> >>>>>>>>> Now that you have reminded us of the dialogusage draft, >>>> perhaps it >>>>>>>>> would be appropriate to remind people of the following from the >>>>>>>>> abstract: >>>>>>>>> "This memo argues that multiple dialog usages should be >>>> avoided. >>>>>>>>> It discusses alternatives to their use and clarifies essential >>>>>>>>> behavior for elements that cannot currently avoid them." >>>>>>>>> In other words, while it will only be an Informational RFC, it >>>>>>>>> seems to deprecate introduction of further dialog >>>> reuses. So if we >>>>>>>>> were to go with NOTIFY, would this be a new dialog >>>> usage, and if >>>>>>>>> so, >>>>>>>> do we really >>>>>>>>> want to go ahead with something in contradiction to the >>>> sentiment >>>>>>>>> of that recently-approved draft? >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] >>>>>>>>>> Sent: 19 October 2007 01:05 >>>>>>>>>> To: Paul Kyzivat >>>>>>>>>> Cc: sip; Brian Stucker >>>>>>>>>> Subject: Re: [Sip] INFO >>>>>>>>>> >>>>>>>>>> Paul Kyzivat wrote: >>>>>>>>>>> I mostly agree with Adam. The place where I take exception >>>>>>>>>> is INFO. It >>>>>>>>>>> is my impression that INFO was designed for use with >>>> INVITE, and >>>>>>>>> so >>>>>>>>>>> should be considered to be part of an invite-dialog-usage. >>>>>>>>>> And Robert >>>>>>>>>>> specified it that way in the dialogusage draft. >>>>>>>>>> You're correct. I had forgotten about that, and the dialogusage >>>>>>>>> draft >>>>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC >>>>>>>>>> 2976 predates >>>>>>>>>> the current terminology, but a quick re-read does show >>>> that it's >>>>>>>>>> pretty clearly appropriate only for INVITE usages. >>>>>>>>>> >>>>>>>>>> /a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>> current sip Use >>>>>>>>>> sipping@ietf.org for new developments on the >>>>>>>> application of sip >>>>>>>>> _______________________________________________ >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>> current sip Use >>>>>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 20 11:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjG4g-0001JJ-Sy; Sat, 20 Oct 2007 11:17:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjG4f-0001Ir-8k for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 11:17:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjG4e-0001Ee-Aa for sip@ietf.org; Sat, 20 Oct 2007 11:17:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjG4a-0004uE-CJ for sip@ietf.org; Sat, 20 Oct 2007 11:17:10 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C52F820174; Sat, 20 Oct 2007 17:17:07 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-09-471a1bf33347 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A3F842006F; Sat, 20 Oct 2007 17:17:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Oct 2007 17:17:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sat, 20 Oct 2007 17:17:05 +0200 Message-ID: In-Reply-To: <471A0FAC.2090101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgTJQjKVhao4n9+RgOQqEuM9MyRvwABudAg References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <471A0FAC.2090101@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 Oct 2007 15:17:07.0269 (UTC) FILETIME=[471DE750:01C8132C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org Hi Paul, So, I guess the compact version of your answer to my question is: "I am not sure" :) So, if there is a chance that there is something which will go wrong I think we should really also consider using another method than NOTIFY. Regards, Christer =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20. lokakuuta 2007 17:25 > To: Christer Holmberg > Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO >=20 >=20 >=20 > Christer Holmberg wrote: > > Hi Paul, > > =20 > > I am talking about a proxy. > > =20 > > So, you are saying that the proxy would always forward the=20 > NOTIFY, even if it does not have any state of a subscription=20 > dialog, or subscription usage within a dialog? >=20 > Well... >=20 > There are transaction-stateless proxies, and=20 > transaction-stateful proxies, and dialog-stateful proxies. >=20 > Only a dialog-stateful proxy could make the kind of decision=20 > you are talking about. >=20 > AFAIK there is very little written about dialog-stateful=20 > proxies. I think perhaps they have little utility, and have=20 > been superseded by B2BUAs. So there isn't a lot to go on in=20 > determining what they are permitted to do. >=20 > In general I think a "proxy" is only permitted to return an=20 > error to a request if it: > - isn't able to forward as requested > - is carrying out policy on behalf of the sender > or the recipient. (I suppose policy of the > carrier also applies on the assumption that > the caller or callee select the carrier and > hence implicitly agree to its policies.) >=20 > My personal opinion is that the kind of checking you are=20 > talking about is just "meddling" in the affairs of the UAs,=20 > and should not be done.=20 > But I suppose one might desire a policy that enforces=20 > standards in this way. But if so, as a UA I don't want my=20 > agents enforcing policies that prevent valid usages by my UA. >=20 > Perhaps Hadriel would like to comment on this. His company=20 > makes SBCs that I think are in the business of sticking their=20 > nose into other people's sip usage and policing it. Do they=20 > do this kind of enforcement? >=20 > Paul >=20 > > Regards, > > =20 > > Christer > >=20 > > ________________________________ > >=20 > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Sat 20/10/2007 00:34 > > To: Christer Holmberg > > Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John > > Subject: Re: [Sip] INFO > >=20 > >=20 > >=20 > >=20 > >=20 > > Christer Holmberg wrote: > >> Hi, > >> > >> One potential issue: the stateful intermediate receives a=20 > NOTIFY without any previous SUBSCRIBE. Is there a chance it=20 > would act on this, e.g. by sending a 4xx response, or are we=20 > sure it would always simply forward the NOTIFY and assume the=20 > endpoint will handle it? > >=20 > > Are you talking about a B2BUA or a proxy? > >=20 > > If a B2BUA, it suffers the common problem that it needs to=20 > be aware of=20 > > pretty much all the standards in use by those it is connecting. > >=20 > > If it was not aware of this new extension, and it was trying to=20 > > enforce rules about what messages are allowed in what=20 > contexts, then=20 > > yes it might cause trouble. But we specify stuff all the=20 > time that has=20 > > similar issues with B2BUAs. Its up to B2BUAs to figure out=20 > how to be=20 > > transparent or else go away. > >=20 > > If its a proxy it has no business making such a judgment. > >=20 > > Paul > >=20 > >=20 > >> Regards, > >> > >> Christer > >> > >> > >> > >> ________________________________ > >> > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Fri 19/10/2007 18:52 > >> To: Brian Stucker > >> Cc: sip; Adam Roach; Michael Procter; Elwell,John > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> > >> > >> Brian Stucker wrote: > >>> If we're going to change the way that error messages are handled=20 > >>> that are returned for NOTIFY messages isn't it going to be a bit=20 > >>> complicated to determine at the transaction layer if the=20 > NOTIFY was=20 > >>> negotiated via INVITE or via SUBSCRIBE? > >>> > >>> I mean, the endpoints may know what's going on, but boxes in the=20 > >>> middle might not. > >> I don't see any reason why *proxy* middle boxes need to=20 > know anything=20 > >> about this. B2BUAs will need to know, but then they will know. > >> > >>> I'm a bit concerned that by tweaking 3265 in this way=20 > we're going to=20 > >>> move more complexity into all subscription processing=20 > whether it's a=20 > >>> usage within a dialog, a separate dialog or this new thing. > >> It would only affect those that support it. > >> > >> And I don't think it will be a big deal, but then this is just=20 > >> speculation at this point, since no details have been=20 > worked out. Its=20 > >> always possible that it would turn into a mess. > >> > >> Paul > >> > >>> Regards, > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Friday, October 19, 2007 10:55 AM > >>>> To: Hadriel Kaplan > >>>> Cc: Elwell, John; sip; Michael Procter; Adam Roach;=20 > Stucker, Brian=20 > >>>> (RICH1:AR00) > >>>> Subject: Re: [Sip] INFO > >>>> > >>>> > >>>> > >>>> Hadriel Kaplan wrote: > >>>>> Which is one of the reasons I think it should be INFO. > >>>> Using it would only be an update to rfc2976, right? > >>>>> -hadriel > >>>> I don't think the distinction is significant. Either way=20 > it should=20 > >>>> be designed to be backward compatible. And neither way=20 > will require=20 > >>>> actually changing those other documents. > >>>> > >>>> Using NOTIFY: > >>>> > >>>> - will need some new header(s) in INVITE and responses=20 > to negotiate=20 > >>>> this > >>>> new capability within the invite dialog usage. > >>>> > >>>> - once that is done it will have established some new=20 > rules for using > >>>> NOTIFY in that context. This will not be used unless=20 > negotiated, > >>>> so there aren't any backward compatibility issues. > >>>> > >>>> - for those that *do* support this, the same code should=20 > ideally be > >>>> able to use either this technique or real=20 > subscriptions, with only > >>>> minor tweaks. > >>>> > >>>> - I would expect that any event packages defined in the=20 > future that > >>>> could meaningfully be used in this way would be=20 > designed from the > >>>> ground up to support both styles. > >>>> > >>>> Using INFO: > >>>> > >>>> - I don't think it will be sufficient to just add headers to > >>>> NOTIFY itself. IMO there still needs to be negotiation of > >>>> the particular usages of NOTIFY. So there still need to be > >>>> new header(s) in invite and responses. > >>>> > >>>> - once the negotiation is done there will need to be some new > >>>> header(s) to provide added context for the INFO. > >>>> > >>>> - any usage that currently has an event package would have > >>>> to be modified to be used with INFO. > >>>> > >>>> Bottom line - I think a "lighter weight" subscription mechanism=20 > >>>> serves all the same needs that an enhanced INFO does, is=20 > no harder=20 > >>>> to implement, and has other benefits. > >>>> =20 > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: Friday, October 19, 2007 7:48 AM > >>>>>> To: Elwell, John > >>>>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >>>>>> Subject: Re: [Sip] INFO > >>>>>> > >>>>>> Yes, my thinking has been that this would be a matter of > >>>> negotiating > >>>>>> the use of NOTIFY *within* the invite-dialog-usage. Of course=20 > >>>>>> that isn't legal today - this would be an extension to both > >>>> 3261 and 3265. > >>>>>> Paul > >>>>>> > >>>>>> Elwell, John wrote: > >>>>>>> Michael, > >>>>>>> > >>>>>>> Yes, I guess some of the postings on this thread have > >>>> hinted that it > >>>>>>> would be the same dialog usage. I suppose if the > >>>> subscriptions are > >>>>>>> deemed to terminate at the time of the BYE=20 > transaction, then it=20 > >>>>>>> would indeed by the same dialog usage. So it would=20 > appear to be=20 > >>>>>>> within the letter of the dialogusage draft. However,=20 > one or two=20 > >>>>>>> postings have suggested different. > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Michael Procter [mailto:michael.procter@citel.com] > >>>>>>>> Sent: 19 October 2007 08:48 > >>>>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>>>>>> Cc: sip; Brian Stucker > >>>>>>>> Subject: RE: [Sip] INFO > >>>>>>>> > >>>>>>>> John, > >>>>>>>> > >>>>>>>> My impression of the discussion so far is that using=20 > NOTIFY (or=20 > >>>>>>>> INTIFY as Christer suggests) in this way would not > >>>> constitute a new > >>>>>>>> dialog-usage. A new usage would imply periodic > >>>> resubscription and > >>>>>>>> specific termination, whereas sending INTIFY within the > >>>> context of > >>>>>>>> the INVITE-usage means that the lifetime issues can=20 > be ignored: > >>>>>>>> terminate the call, and INTIFY no longer has a context. > >>>>>>>> > >>>>>>>> This neatly avoids violating the letter of the > >>>> dialogusage draft, > >>>>>>>> but you could probably argue that creating sub-usages of the=20 > >>>>>>>> INVITE-usage isn't necessarily in keeping with the > >>>> spirit of the draft... > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Michael > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>>>>> Sent: 19 October 2007 07:41 > >>>>>>>>> To: Adam Roach; Paul Kyzivat > >>>>>>>>> Cc: sip; Brian Stucker > >>>>>>>>> Subject: RE: [Sip] INFO > >>>>>>>>> > >>>>>>>>> Adam, > >>>>>>>>> > >>>>>>>>> Now that you have reminded us of the dialogusage draft, > >>>> perhaps it > >>>>>>>>> would be appropriate to remind people of the following from=20 > >>>>>>>>> the > >>>>>>>>> abstract: > >>>>>>>>> "This memo argues that multiple dialog usages should be > >>>> avoided. > >>>>>>>>> It discusses alternatives to their use and=20 > clarifies essential=20 > >>>>>>>>> behavior for elements that cannot currently avoid them." > >>>>>>>>> In other words, while it will only be an=20 > Informational RFC, it=20 > >>>>>>>>> seems to deprecate introduction of further dialog > >>>> reuses. So if we > >>>>>>>>> were to go with NOTIFY, would this be a new dialog > >>>> usage, and if > >>>>>>>>> so, > >>>>>>>> do we really > >>>>>>>>> want to go ahead with something in contradiction to the > >>>> sentiment > >>>>>>>>> of that recently-approved draft? > >>>>>>>>> > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>>>>>> Sent: 19 October 2007 01:05 > >>>>>>>>>> To: Paul Kyzivat > >>>>>>>>>> Cc: sip; Brian Stucker > >>>>>>>>>> Subject: Re: [Sip] INFO > >>>>>>>>>> > >>>>>>>>>> Paul Kyzivat wrote: > >>>>>>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>>>>>> is INFO. It > >>>>>>>>>>> is my impression that INFO was designed for use with > >>>> INVITE, and > >>>>>>>>> so > >>>>>>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>>>>>> And Robert > >>>>>>>>>>> specified it that way in the dialogusage draft. > >>>>>>>>>> You're correct. I had forgotten about that, and the=20 > >>>>>>>>>> dialogusage > >>>>>>>>> draft > >>>>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>>>>>> 2976 predates > >>>>>>>>>> the current terminology, but a quick re-read does show > >>>> that it's > >>>>>>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>>>>>> > >>>>>>>>>> /a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>>> This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>>>> sip-implementors@cs.columbia.edu for questions on > >>>> current sip Use > >>>>>>>>>> sipping@ietf.org for new developments on the > >>>>>>>> application of sip > >>>>>>>>> _______________________________________________ > >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>> This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>>> sip-implementors@cs.columbia.edu for questions on > >>>> current sip Use > >>>>>>>>> sipping@ietf.org for new developments on the application of=20 > >>>>>>>>> sip > >>>>>> _______________________________________________ > >>>>>> 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=20 > 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=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 Sat Oct 20 12:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjGt3-0002Jq-EU; Sat, 20 Oct 2007 12:09:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjGt1-0002Im-DQ for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 12:09:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjGt0-0002Id-LM for sip@ietf.org; Sat, 20 Oct 2007 12:09:14 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjGt0-0006Si-D1 for sip@ietf.org; Sat, 20 Oct 2007 12:09:14 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQ700ETPWVDWC@usaga01-in.huawei.com> for sip@ietf.org; Sat, 20 Oct 2007 09:09:13 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQ700HIDWVBQP@usaga01-in.huawei.com> for sip@ietf.org; Sat, 20 Oct 2007 09:09:13 -0700 (PDT) Date: Sat, 20 Oct 2007 11:08:37 -0500 From: Spencer Dawkins Subject: Re: [Sip] INFO To: sip Message-id: <02b901c81333$79a6bf10$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <471A0FAC.2090101@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: sip-bounces@ietf.org Hi, Christer, I am probably misunderstanding, but I thought Paul's answer was that if a proxy goes into business for itself, it's not really a proxy, and if a proxy goes into business for itself, that's not because we took this mode of operation into account, but because the people who built this "proxy" were able to make it completely transparent, so that we didn't need to take this mode of operation into account. Paul, back to you if I got this wrong. Spencer From: "Christer Holmberg" To: "Paul Kyzivat" Hi Paul, So, I guess the compact version of your answer to my question is: "I am not sure" :) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 20 13:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjHqW-0006Ax-S7; Sat, 20 Oct 2007 13:10:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjHqU-00067b-UT for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 13:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjHqT-00064y-QF for sip@ietf.org; Sat, 20 Oct 2007 13:10:41 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjHqK-0001Ct-MO for sip@ietf.org; Sat, 20 Oct 2007 13:10:38 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 20 Oct 2007 13:10:22 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 20 Oct 2007 13:10:22 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Sat, 20 Oct 2007 13:08:58 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgTJ4Fyq5AmWDZoTz2gFkeKOULp9AADcMzw Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <471A0FAC.2090101@cisco.com> In-Reply-To: <471A0FAC.2090101@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Adam Roach , sip , Michael, Stucker , Brian, Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > My personal opinion is that the kind of checking you are talking about > is just "meddling" in the affairs of the UAs, and should not be done. > But I suppose one might desire a policy that enforces standards in this > way. But if so, as a UA I don't want my agents enforcing policies that > prevent valid usages by my UA. > > Perhaps Hadriel would like to comment on this. His company makes SBCs > that I think are in the business of sticking their nose into other > people's sip usage and policing it. Cute. I believe Christer's makes them too, as does yours, and a dozen othe= rs on this list. We don't "stick our nose into other people's usage". The= y sent SIP to us. We can't force a UA not to send something to us. But it= doesn't mean we have to accept it. No one forces you to send your SIP req= uests to us or any SBC, AFAIK. > Do they do this kind of enforcement? Of course we could do that kind of enforcement, depending on configuration,= as I assume you guys do. My guess is even "Proxies" do it, based on confi= g. (and there are plenty of record-routing proxies) The RFCs say to forwar= d SIP requests, just as they expect routers to forward packets, but that do= esn't stop routers from having ACLs, policing, shaping, filtering routes, e= tc. Email servers block emails based on usage too. Regardless, I'm with you that we can't consider local device policies as a = roadblock to all new things. (Although pragmatism has its place) It's jus= t that it is an advantage for a mechanism if we know it works in more cases= due to empirical evidence. I think there is also some evidence that a Not= ify in an Invite dialog works, because there is at least one vendor out the= re that uses Notify in an Invite for DTMF. But many more do Info, I believ= e, so I assume its chance of success is greater. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 20 13:56:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjIVW-0002uh-Dr; Sat, 20 Oct 2007 13:53:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjIVU-0002rs-5u for sip-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 13:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjIVS-0002qw-Q9 for sip@ietf.org; Sat, 20 Oct 2007 13:53:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjIVJ-0002xW-CL for sip@ietf.org; Sat, 20 Oct 2007 13:53:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BE27820197; Sat, 20 Oct 2007 19:52:47 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-be-471a406f583d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 587F420078; Sat, 20 Oct 2007 19:52:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Oct 2007 19:52:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Sat, 20 Oct 2007 19:52:46 +0200 Message-ID: In-Reply-To: <02b901c81333$79a6bf10$6501a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgTNQHiJft8Bv9vQ2G2EvMzvHyH4AADHg0g References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><471A0FAC.2090101@cisco.com> <02b901c81333$79a6bf10$6501a8c0@china.h uawei.co m> From: "Christer Holmberg" To: "Spencer Dawkins" , "sip" X-OriginalArrivalTime: 20 Oct 2007 17:52:46.0798 (UTC) FILETIME=[05E8EEE0:01C81342] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >I am probably misunderstanding, but I thought Paul's answer=20 >was that if a proxy goes into business for itself, it's not=20 >really a proxy, and if a proxy goes into business for itself,=20 >that's not because we took this mode of operation into=20 >account, but because the people who built this "proxy" were=20 >able to make it completely transparent, so that we didn't=20 >need to take this mode of operation into account. My understanding from what Paul said was that a dialog-stateful proxy is still a proxy. Whether in real life people add lots of other stuff to dialog-stateful proxies, so they become B2BUAs, I don't know, but a "pure" dialog-stateful proxy is still a proxy. Regards, Christer >=20 > Paul, back to you if I got this wrong. >=20 > Spencer >=20 > From: "Christer Holmberg" > To: "Paul Kyzivat" >=20 > Hi Paul, >=20 > So, I guess the compact version of your answer to my question=20 > is: "I am not sure" :)=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=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 Sun Oct 21 12:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjdJz-0007Ml-N4; Sun, 21 Oct 2007 12:06:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjdJx-0007LN-EJ for sip-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 12:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjdJw-0007H9-D2 for sip@ietf.org; Sun, 21 Oct 2007 12:06:32 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjdJi-00062L-M6 for sip@ietf.org; Sun, 21 Oct 2007 12:06:24 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9LG5Poc025628; Sun, 21 Oct 2007 11:05:25 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Oct 2007 11:05:25 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Oct 2007 18:05:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Oct 2007 18:05:23 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001810865@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: RE: [rohc] Volunteers to review the SigComp Section ofdraft-ietf-sip-hitchhikers-guide-03] Thread-Index: AcgSTl0uoOifETBITLC/ug/C2Wx0HQBhXSqw From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 21 Oct 2007 16:05:23.0367 (UTC) FILETIME=[2FBD2370:01C813FC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: IETF SIP List Subject: [Sip] FW: [Fwd: RE: [rohc] Volunteers to review the SigComp Section ofdraft-ietf-sip-hitchhikers-guide-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: , Errors-To: sip-bounces@ietf.org These are comments from a member of the ROHC group on the Sigcomp = related portion of this draft. Regards Keith=20 -----Original Message----- From: Carl Knutsson [mailto:carl.knutsson@effnet.com]=20 Sent: Friday, October 19, 2007 1:39 PM To: DRAGE, Keith (Keith) Subject: [Fwd: RE: [rohc] Volunteers to review the SigComp Section = ofdraft-ietf-sip-hitchhikers-guide-03] Hi Keith, I got this review from Abbie. /Calle -------- Original Message -------- Subject: RE: [rohc] Volunteers to review the SigComp Section ofdraft-ietf-sip-hitchhikers-guide-03 Date: Fri, 19 Oct 2007 13:07:42 +0100 From: West, Abigail To: Carl Knutsson , rohc References: <47134F97.9050202@effnet.com> Hi Carl, I've just had a look at this document. I haven't read through all of it = in detail as I'm no SIP expert. However, I have read the SIP = Compression section and have some comments: draft-ietf-rohc-sigcomp-sip-08.txt (currently in EDIT) is discusses how = to apply SigComp to SIP. It is not a SIP specification as defined in = this document but I think it should be mentioned so that there is a = reference for it in the first paragraph along the lines of: "... Sigcomp is not formally part of SIP. SigComp for SIP [x] explains = how to use SigComp for compressing SIP. However, ..." RFC3486 defines two parameters, not one (though their syntax is the = same). One is a URI parameter, the other is for the via header. In both cases, the parameter is not only used to indicate that SigComp = is supported, it is also used to request compression. I hope this is useful. Best regards, Abbie -- Abbie West (ne=E9 Surtees) Consultant Engineer Roke Manor Research Ltd Tel: +44 (0)1794 833131 Fax: +44 (0)1794 833433 Please note that though my email address is West I am using my maiden = name for work in this area and mail to abigail.surtees@roke.co.uk will = also reach me. > -----Original Message----- > From: Carl Knutsson [mailto:carl.knutsson@effnet.com] > Sent: 15 October 2007 12:32 > To: rohc > Subject: [rohc] Volunteers to review the SigComp Section > ofdraft-ietf-sip-hitchhikers-guide-03 >=20 > Hi all, >=20 > I am looking for volunteers to review the sip-hitchhikers-guide (SIP=20 > WG Last-call). It is an summary of how all SIP related specifications=20 > fit together. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers -guide-03.txt >=20 >=20 > It probably won't take more than a few minutes. I would appreciate if=20 > someone would volunteer for the review. >=20 > /Calle > ROHC WG chair >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=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 21 20:36:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl97-00064C-Cu; Sun, 21 Oct 2007 20:27:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijl95-00063e-Pg for sip-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 20:27:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijl94-00063W-Ts for sip@ietf.org; Sun, 21 Oct 2007 20:27:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijl94-0001ai-J3 for sip@ietf.org; Sun, 21 Oct 2007 20:27:50 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9M0RYaX010760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 21 Oct 2007 19:27:36 -0500 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <922FC37B-E48D-4DF4-BFF4-FA83B0A7FB2E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Sun, 21 Oct 2007 19:27:17 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Roach , sip List , Paul Kyzivat , Brian Stucker , Michael Procter , John Elwell 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: , Errors-To: sip-bounces@ietf.org On Oct 19, 2007, at 9:04 AM, Hadriel Kaplan wrote: > Which is one of the reasons I think it should be INFO. Using it > would only be an update to rfc2976, right? > -hadriel I concur. And an RFC that clearly replaces the broken RFC 2976 gives us a great thing to whack developers with. Backward compatibility issues can be worked out with an option tag. -- 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 21 20:39:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjlJR-0000cC-V4; Sun, 21 Oct 2007 20:38:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjlJP-0000ak-VL for sip-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 20:38:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjlJO-0000Zv-WB for sip@ietf.org; Sun, 21 Oct 2007 20:38:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjlJO-0001uq-ME for sip@ietf.org; Sun, 21 Oct 2007 20:38:30 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9M0cA1N010864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 21 Oct 2007 19:38:11 -0500 In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Sun, 21 Oct 2007 19:37:52 -0500 To: Christer Holmberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Adam Roach , sip , Paul Kyzivat , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote: > Hi Paul, > > I am talking about a proxy. > > So, you are saying that the proxy would always forward the NOTIFY, > even if it does not have any state of a subscription dialog, or > subscription usage within a dialog? > Many proxies blindly forward NOTIFY. I know this because certain very popular phone adapters with blue boxes use unsolicited NOTIFY for their message waiting indicators, and many operators seem to have deployed them with some success, despite much gnashing of teeth on my part. -- 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 21 21:17:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjlsH-0004NM-TH; Sun, 21 Oct 2007 21:14:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjlsE-0004Mc-A2 for sip-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 21:14:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjlsD-0004MT-92 for sip@ietf.org; Sun, 21 Oct 2007 21:14:29 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjlsC-0004dJ-Uy for sip@ietf.org; Sun, 21 Oct 2007 21:14:29 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2007102200523001400labphe>; Mon, 22 Oct 2007 00:52:30 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9M0qUlW013997 for ; Sun, 21 Oct 2007 20:52:30 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9M0qUUO013993; Sun, 21 Oct 2007 20:52:30 -0400 Date: Sun, 21 Oct 2007 20:52:30 -0400 Message-Id: <200710220052.l9M0qUUO013993@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] Use of the Require header in responses 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: , Errors-To: sip-bounces@ietf.org This message is to clarify an issue that has been causing me some confusion, namely the meaning and use of the Require header in responses. I hope it helps others avoid my mistakes. The bulk of RFC 3261 (including section 8.1.1.9 "Supported and Require", 20.32 "Require", and 20.37 "Supported") describes the use of the Supported and Require headers in a very straightforward way: Supported is used to inform the other end of a dialog that the UA supports the specified extensions. Require is used in requests to compel the other UA to reject a request if the other UA does not support the specified extensions. Within this framework, using Require in a response is pointless -- if the UAC does not support the extension, it would be required to discard the response, thus leaving it with no way of knowing that the UAS wants to make use of the extension. However, there is separate meaning for Require when it is used in a response, namely to indicate that the UAS has performed some particular processing specified in the extension in question. This use is described in section 8.2.4 "Applying Extensions": Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. Of course, exactly what processing is implied by a Require header in a response is determined by the specification of the extension in question. If I recall correctly, there are three extensions or proposed extensions that use Require headers in responses routinely. One is the GRUU extension, but I've forgotten the other two. 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 Mon Oct 22 01:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjphE-00013u-3e; Mon, 22 Oct 2007 01:19:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjphB-0000wf-65 for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 01:19:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjpeB-0007jo-JX for sip@ietf.org; Mon, 22 Oct 2007 01:16:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjpeB-0007YG-06 for sip@ietf.org; Mon, 22 Oct 2007 01:16:15 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9M5F9NE012177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2007 00:15:10 -0500 In-Reply-To: <200710220052.l9M0qUUO013993@dragon.ariadne.com> References: <200710220052.l9M0qUUO013993@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Use of the Require header in responses Date: Mon, 22 Oct 2007 00:14:51 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: sip-bounces@ietf.org On Oct 21, 2007, at 7:52 PM, Dale.Worley@comcast.net wrote: > > However, there is separate meaning for Require when it is used in a > response, namely to indicate that the UAS has performed some > particular processing specified in the extension in question. > > This use is described in section 8.2.4 "Applying Extensions": > > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, the > server > MUST NOT apply extensions not listed in the Supported header > field in > the request. > > Of course, exactly what processing is implied by a Require header in a > response is determined by the specification of the extension in > question. > > If I recall correctly, there are three extensions or proposed > extensions that use Require headers in responses routinely. One is > the GRUU extension, but I've forgotten the other two. draft-ietf-sip-answermode uses its own extension header fields in responses to indicate which mode was applied to the request. This seemed a lot cleaner than a "Require" in the response. -- 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 22 02:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjqLF-0007XO-Cl; Mon, 22 Oct 2007 02:00:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjqLD-0007Tr-2B for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 02:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjqLA-0007ME-Jh for sip@ietf.org; Mon, 22 Oct 2007 02:00:40 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjqKz-0001V8-Tg for sip@ietf.org; Mon, 22 Oct 2007 02:00:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 090B02066F; Mon, 22 Oct 2007 08:00:29 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-ce-471c3c7cdd9c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E6D1520689; Mon, 22 Oct 2007 08:00:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 08:00:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 08:00:26 +0200 Message-ID: In-Reply-To: <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUQ96WRtMqUo55RO2hW5TwHO+7YAALNgMg References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 22 Oct 2007 06:00:28.0247 (UTC) FILETIME=[D8931670:01C81470] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Adam Roach , sip , Paul Kyzivat , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I am talking about a proxy. >> >>So, you are saying that the proxy would always forward the NOTIFY,=20 >>even if it does not have any state of a subscription dialog, or=20 >>subscription usage within a dialog? >> >=20 >Many proxies blindly forward NOTIFY. I know this because=20 >certain very popular phone adapters with blue boxes use=20 >unsolicited NOTIFY for their message waiting indicators, and=20 >many operators seem to have deployed them with some success,=20 >despite much gnashing of teeth on my part. "MANY" is not the same thing as "ALL" :) 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 Mon Oct 22 03:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijreu-0004wo-8D; Mon, 22 Oct 2007 03:25:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijres-0004wU-Ae for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 03:25:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijree-0004gN-UT for sip@ietf.org; Mon, 22 Oct 2007 03:24:53 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijrea-00052O-Pc for sip@ietf.org; Mon, 22 Oct 2007 03:24:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l9M7LkS19473; Mon, 22 Oct 2007 07:21:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 02:24:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE46@zrc2hxm0.corp.nortel.com> In-Reply-To: <4718E0C0.5000308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgScUju5j9HY9iNQBmpRws4AyBHbwCCxeeA References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 19, 2007 11:52 AM > To: Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell, John > Subject: Re: [Sip] INFO >=20 >=20 >=20 > Brian Stucker wrote: > > If we're going to change the way that error messages are=20 > handled that=20 > > are returned for NOTIFY messages isn't it going to be a bit=20 > > complicated to determine at the transaction layer if the NOTIFY was=20 > > negotiated via INVITE or via SUBSCRIBE? > >=20 > > I mean, the endpoints may know what's going on, but boxes in the=20 > > middle might not. >=20 > I don't see any reason why *proxy* middle boxes need to know=20 > anything about this. B2BUAs will need to know, but then they=20 > will know. Call stateful proxies (not B2BUAs) will probably chew up your call dialog.=20 >=20 > > I'm a bit concerned that by tweaking 3265 in this way we're=20 > going to=20 > > move more complexity into all subscription processing=20 > whether it's a=20 > > usage within a dialog, a separate dialog or this new thing. >=20 > It would only affect those that support it. >=20 > And I don't think it will be a big deal, but then this is=20 > just speculation at this point, since no details have been=20 > worked out. Its always possible that it would turn into a mess. Maybe. Let's just keep the middle in mind so the ends works. >=20 > Paul >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 19, 2007 10:55 AM > >> To: Hadriel Kaplan > >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, Brian=20 > >> (RICH1:AR00) > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> Hadriel Kaplan wrote: > >>> Which is one of the reasons I think it should be INFO. =20 > >> Using it would only be an update to rfc2976, right? > >>> -hadriel > >> I don't think the distinction is significant. Either way=20 > it should be=20 > >> designed to be backward compatible. And neither way will require=20 > >> actually changing those other documents. > >> > >> Using NOTIFY: > >> > >> - will need some new header(s) in INVITE and responses to=20 > negotiate=20 > >> this > >> new capability within the invite dialog usage. > >> > >> - once that is done it will have established some new=20 > rules for using > >> NOTIFY in that context. This will not be used unless negotiated, > >> so there aren't any backward compatibility issues. > >> > >> - for those that *do* support this, the same code should ideally be > >> able to use either this technique or real=20 > subscriptions, with only > >> minor tweaks. > >> > >> - I would expect that any event packages defined in the future that > >> could meaningfully be used in this way would be=20 > designed from the > >> ground up to support both styles. > >> > >> Using INFO: > >> > >> - I don't think it will be sufficient to just add headers to > >> NOTIFY itself. IMO there still needs to be negotiation of > >> the particular usages of NOTIFY. So there still need to be > >> new header(s) in invite and responses. > >> > >> - once the negotiation is done there will need to be some new > >> header(s) to provide added context for the INFO. > >> > >> - any usage that currently has an event package would have > >> to be modified to be used with INFO. > >> > >> Bottom line - I think a "lighter weight" subscription mechanism=20 > >> serves all the same needs that an enhanced INFO does, is=20 > no harder to=20 > >> implement, and has other benefits. > >> =09 > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Friday, October 19, 2007 7:48 AM > >>>> To: Elwell, John > >>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >>>> Subject: Re: [Sip] INFO > >>>> > >>>> Yes, my thinking has been that this would be a matter of > >> negotiating > >>>> the use of NOTIFY *within* the invite-dialog-usage. Of=20 > course that=20 > >>>> isn't legal today - this would be an extension to both > >> 3261 and 3265. > >>>> Paul > >>>> > >>>> Elwell, John wrote: > >>>>> Michael, > >>>>> > >>>>> Yes, I guess some of the postings on this thread have > >> hinted that it > >>>>> would be the same dialog usage. I suppose if the > >> subscriptions are > >>>>> deemed to terminate at the time of the BYE transaction, then it=20 > >>>>> would indeed by the same dialog usage. So it would appear to be=20 > >>>>> within the letter of the dialogusage draft. However, one or two=20 > >>>>> postings have suggested different. > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Michael Procter [mailto:michael.procter@citel.com] > >>>>>> Sent: 19 October 2007 08:48 > >>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>>>> Cc: sip; Brian Stucker > >>>>>> Subject: RE: [Sip] INFO > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> My impression of the discussion so far is that using=20 > NOTIFY (or=20 > >>>>>> INTIFY as Christer suggests) in this way would not > >> constitute a new > >>>>>> dialog-usage. A new usage would imply periodic > >> resubscription and > >>>>>> specific termination, whereas sending INTIFY within the > >> context of > >>>>>> the INVITE-usage means that the lifetime issues can be=20 > ignored:=20 > >>>>>> terminate the call, and INTIFY no longer has a context. > >>>>>> > >>>>>> This neatly avoids violating the letter of the > >> dialogusage draft, > >>>>>> but you could probably argue that creating sub-usages of the=20 > >>>>>> INVITE-usage isn't necessarily in keeping with the > >> spirit of the draft... > >>>>>> Regards, > >>>>>> > >>>>>> Michael > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>>> Sent: 19 October 2007 07:41 > >>>>>>> To: Adam Roach; Paul Kyzivat > >>>>>>> Cc: sip; Brian Stucker > >>>>>>> Subject: RE: [Sip] INFO > >>>>>>> > >>>>>>> Adam, > >>>>>>> > >>>>>>> Now that you have reminded us of the dialogusage draft, > >> perhaps it > >>>>>>> would be appropriate to remind people of the=20 > following from the > >>>>>>> abstract: > >>>>>>> "This memo argues that multiple dialog usages should be > >> avoided. =20 > >>>>>>> It discusses alternatives to their use and clarifies=20 > essential=20 > >>>>>>> behavior for elements that cannot currently avoid them." > >>>>>>> In other words, while it will only be an=20 > Informational RFC, it=20 > >>>>>>> seems to deprecate introduction of further dialog > >> reuses. So if we > >>>>>>> were to go with NOTIFY, would this be a new dialog > >> usage, and if > >>>>>>> so, > >>>>>> do we really > >>>>>>> want to go ahead with something in contradiction to the > >> sentiment > >>>>>>> of that recently-approved draft? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>>>> Sent: 19 October 2007 01:05 > >>>>>>>> To: Paul Kyzivat > >>>>>>>> Cc: sip; Brian Stucker > >>>>>>>> Subject: Re: [Sip] INFO > >>>>>>>> > >>>>>>>> Paul Kyzivat wrote: > >>>>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>>>> is INFO. It > >>>>>>>>> is my impression that INFO was designed for use with > >> INVITE, and > >>>>>>> so > >>>>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>>>> And Robert > >>>>>>>>> specified it that way in the dialogusage draft. > >>>>>>>> You're correct. I had forgotten about that, and the=20 > dialogusage > >>>>>>> draft > >>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>>>> 2976 predates > >>>>>>>> the current terminology, but a quick re-read does show > >> that it's > >>>>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>> This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>> sip-implementors@cs.columbia.edu for questions on > >> current sip Use > >>>>>>>> sipping@ietf.org for new developments on the > >>>>>> application of sip > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>>> sipping@ietf.org for new developments on the=20 > application of sip > >>>> _______________________________________________ > >>>> 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=20 > current sip Use=20 > >>>> 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=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 Mon Oct 22 03:39:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjrqZ-00013b-6h; Mon, 22 Oct 2007 03:37:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjrqX-00013P-5Q for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 03:37:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjrqW-000134-58 for sip@ietf.org; Mon, 22 Oct 2007 03:37:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjrqV-0005Rc-2V for sip@ietf.org; Mon, 22 Oct 2007 03:37:08 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9M7Zj908757; Mon, 22 Oct 2007 07:35:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 02:35:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE48@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgScL9gl0lr4O3BTcaN77kGrmh1CQAImIglAHp19bA= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> From: "Brian Stucker" To: "Christer Holmberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, October 19, 2007 4:10 PM > To: Paul Kyzivat; Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO >=20 > Hi, > =20 > One potential issue: the stateful intermediate receives a=20 > NOTIFY without any previous SUBSCRIBE. Is there a chance it=20 > would act on this, e.g. by sending a 4xx response, or are we=20 > sure it would always simply forward the NOTIFY and assume the=20 > endpoint will handle it? It depends upon how much state this stateful intermediate is keeping. If it's transaction stateful, then no, it shouldn't care (as it won't have remembered any of the previous transactions once their response was sent back anyway). However, it is entirely possible that, without performing anything untoward (i.e. not a B2BUA) that a proxy may remember whether or not a SUBSCRIBE had previously been sent for a particular NOTIFY and kill the NOTIFY as a security measure thinking that someone's up to no good trying to spoof a subscription. Yes, this would generally break implicit subscriptions, but they've generally pretty ill-advised because of their security profile. For example, I may send regevent NOTIFYs to endpoints telling them they've been forcefully deregistered looking for a gullible UA that will bump itself off the network. I'm just concerned that by using a method from 3265, with new semantics, that it could confuse boxes that aren't aware of what's going on. If it were a different method, either INFO+ or something new, then I'd be less concerned because the whole thing would just look like a regular transaction to the untrained implementation. > =20 > Regards, > =20 > Christer > =20 > =20 >=20 > ________________________________ >=20 > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Fri 19/10/2007 18:52 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO >=20 >=20 >=20 >=20 >=20 > Brian Stucker wrote: > > If we're going to change the way that error messages are=20 > handled that=20 > > are returned for NOTIFY messages isn't it going to be a bit=20 > > complicated to determine at the transaction layer if the NOTIFY was=20 > > negotiated via INVITE or via SUBSCRIBE? > > > > I mean, the endpoints may know what's going on, but boxes in the=20 > > middle might not. >=20 > I don't see any reason why *proxy* middle boxes need to know=20 > anything about this. B2BUAs will need to know, but then they=20 > will know. >=20 > > I'm a bit concerned that by tweaking 3265 in this way we're=20 > going to=20 > > move more complexity into all subscription processing=20 > whether it's a=20 > > usage within a dialog, a separate dialog or this new thing. >=20 > It would only affect those that support it. >=20 > And I don't think it will be a big deal, but then this is=20 > just speculation at this point, since no details have been=20 > worked out. Its always possible that it would turn into a mess. >=20 > Paul >=20 > > Regards, > > Brian > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 19, 2007 10:55 AM > >> To: Hadriel Kaplan > >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, Brian=20 > >> (RICH1:AR00) > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> Hadriel Kaplan wrote: > >>> Which is one of the reasons I think it should be INFO.=20 > >> Using it would only be an update to rfc2976, right? > >>> -hadriel > >> I don't think the distinction is significant. Either way=20 > it should be=20 > >> designed to be backward compatible. And neither way will require=20 > >> actually changing those other documents. > >> > >> Using NOTIFY: > >> > >> - will need some new header(s) in INVITE and responses to=20 > negotiate=20 > >> this > >> new capability within the invite dialog usage. > >> > >> - once that is done it will have established some new=20 > rules for using > >> NOTIFY in that context. This will not be used unless negotiated, > >> so there aren't any backward compatibility issues. > >> > >> - for those that *do* support this, the same code should ideally be > >> able to use either this technique or real=20 > subscriptions, with only > >> minor tweaks. > >> > >> - I would expect that any event packages defined in the future that > >> could meaningfully be used in this way would be=20 > designed from the > >> ground up to support both styles. > >> > >> Using INFO: > >> > >> - I don't think it will be sufficient to just add headers to > >> NOTIFY itself. IMO there still needs to be negotiation of > >> the particular usages of NOTIFY. So there still need to be > >> new header(s) in invite and responses. > >> > >> - once the negotiation is done there will need to be some new > >> header(s) to provide added context for the INFO. > >> > >> - any usage that currently has an event package would have > >> to be modified to be used with INFO. > >> > >> Bottom line - I think a "lighter weight" subscription mechanism=20 > >> serves all the same needs that an enhanced INFO does, is=20 > no harder to=20 > >> implement, and has other benefits. > >> =20 > >> Thanks, > >> Paul > >> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Friday, October 19, 2007 7:48 AM > >>>> To: Elwell, John > >>>> Cc: sip; Michael Procter; Adam Roach; Brian Stucker > >>>> Subject: Re: [Sip] INFO > >>>> > >>>> Yes, my thinking has been that this would be a matter of > >> negotiating > >>>> the use of NOTIFY *within* the invite-dialog-usage. Of=20 > course that=20 > >>>> isn't legal today - this would be an extension to both > >> 3261 and 3265. > >>>> Paul > >>>> > >>>> Elwell, John wrote: > >>>>> Michael, > >>>>> > >>>>> Yes, I guess some of the postings on this thread have > >> hinted that it > >>>>> would be the same dialog usage. I suppose if the > >> subscriptions are > >>>>> deemed to terminate at the time of the BYE transaction, then it=20 > >>>>> would indeed by the same dialog usage. So it would appear to be=20 > >>>>> within the letter of the dialogusage draft. However, one or two=20 > >>>>> postings have suggested different. > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Michael Procter [mailto:michael.procter@citel.com] > >>>>>> Sent: 19 October 2007 08:48 > >>>>>> To: Elwell, John; Adam Roach; Paul Kyzivat > >>>>>> Cc: sip; Brian Stucker > >>>>>> Subject: RE: [Sip] INFO > >>>>>> > >>>>>> John, > >>>>>> > >>>>>> My impression of the discussion so far is that using=20 > NOTIFY (or=20 > >>>>>> INTIFY as Christer suggests) in this way would not > >> constitute a new > >>>>>> dialog-usage. A new usage would imply periodic > >> resubscription and > >>>>>> specific termination, whereas sending INTIFY within the > >> context of > >>>>>> the INVITE-usage means that the lifetime issues can be ignored: > >>>>>> terminate the call, and INTIFY no longer has a context. > >>>>>> > >>>>>> This neatly avoids violating the letter of the > >> dialogusage draft, > >>>>>> but you could probably argue that creating sub-usages of the=20 > >>>>>> INVITE-usage isn't necessarily in keeping with the > >> spirit of the draft... > >>>>>> Regards, > >>>>>> > >>>>>> Michael > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>>> Sent: 19 October 2007 07:41 > >>>>>>> To: Adam Roach; Paul Kyzivat > >>>>>>> Cc: sip; Brian Stucker > >>>>>>> Subject: RE: [Sip] INFO > >>>>>>> > >>>>>>> Adam, > >>>>>>> > >>>>>>> Now that you have reminded us of the dialogusage draft, > >> perhaps it > >>>>>>> would be appropriate to remind people of the=20 > following from the > >>>>>>> abstract: > >>>>>>> "This memo argues that multiple dialog usages should be > >> avoided.=20 > >>>>>>> It discusses alternatives to their use and clarifies=20 > essential=20 > >>>>>>> behavior for elements that cannot currently avoid them." > >>>>>>> In other words, while it will only be an=20 > Informational RFC, it=20 > >>>>>>> seems to deprecate introduction of further dialog > >> reuses. So if we > >>>>>>> were to go with NOTIFY, would this be a new dialog > >> usage, and if > >>>>>>> so, > >>>>>> do we really > >>>>>>> want to go ahead with something in contradiction to the > >> sentiment > >>>>>>> of that recently-approved draft? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Adam Roach [mailto:adam@nostrum.com] > >>>>>>>> Sent: 19 October 2007 01:05 > >>>>>>>> To: Paul Kyzivat > >>>>>>>> Cc: sip; Brian Stucker > >>>>>>>> Subject: Re: [Sip] INFO > >>>>>>>> > >>>>>>>> Paul Kyzivat wrote: > >>>>>>>>> I mostly agree with Adam. The place where I take exception > >>>>>>>> is INFO. It > >>>>>>>>> is my impression that INFO was designed for use with > >> INVITE, and > >>>>>>> so > >>>>>>>>> should be considered to be part of an invite-dialog-usage. > >>>>>>>> And Robert > >>>>>>>>> specified it that way in the dialogusage draft. > >>>>>>>> You're correct. I had forgotten about that, and the=20 > dialogusage > >>>>>>> draft > >>>>>>>> does make it clear: INFO is part of the INVITE usage. RFC > >>>>>>>> 2976 predates > >>>>>>>> the current terminology, but a quick re-read does show > >> that it's > >>>>>>>> pretty clearly appropriate only for INVITE usages. > >>>>>>>> > >>>>>>>> /a > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>> This list is for NEW development of the core SIP=20 > Protocol Use=20 > >>>>>>>> sip-implementors@cs.columbia.edu for questions on > >> current sip Use > >>>>>>>> sipping@ietf.org for new developments on the > >>>>>> application of sip > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>>> sipping@ietf.org for new developments on the=20 > application of sip > >>>> _______________________________________________ > >>>> 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=20 > 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 >=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 22 03:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijryd-0000Lo-Di; Mon, 22 Oct 2007 03:45:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijryb-0000JM-EX for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 03:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjrxT-0007a8-Cg for sip@ietf.org; Mon, 22 Oct 2007 03:44:19 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjrxT-0005fX-05 for sip@ietf.org; Mon, 22 Oct 2007 03:44:19 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1IjrwQ-0000Mg-Qp; Mon, 22 Oct 2007 00:43:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Use of the Require header in responses Date: Mon, 22 Oct 2007 00:43:08 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CD7B6AC@sea02-mxc01.citel.com> In-Reply-To: <200710220052.l9M0qUUO013993@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Use of the Require header in responses Thread-Index: AcgUSc4wr1ES7mX7SEuqqOeFqqlsvAANKo0g References: <200710220052.l9M0qUUO013993@dragon.ariadne.com> From: "Michael Procter" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > If I recall correctly, there are three extensions or proposed > extensions that use Require headers in responses routinely. One is > the GRUU extension, but I've forgotten the other two. RFC3262 (PRACK) uses 'Require: 100rel' in provisional responses, to trigger a PRACK (along with the RSeq header). Maybe this is what you remember? Best regards, Michael _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 03:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijs27-0004jw-2B; Mon, 22 Oct 2007 03:49:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijs25-0004hr-3a for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 03:49:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijs24-0004gw-47 for sip@ietf.org; Mon, 22 Oct 2007 03:49:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijs23-0005rL-OD for sip@ietf.org; Mon, 22 Oct 2007 03:49:04 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9M7mJO00379; Mon, 22 Oct 2007 07:48:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 02:48:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> In-Reply-To: <47192F80.4040308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgSn2VPIerEPjA8QJWz1hKlY6eWDQB3xBUw References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip , Adam Roach , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Hadriel Kaplan wrote: > >> -----Original Message----- > > Lastly, you don't *have* to support rfc3265 at all to=20 > support 3261, so the code change could be quite a bit more. >=20 > For somebody that doesn't support 3265, and doesn't want to,=20 > but that does want to support these new packages within an=20 > INVITE, this is all new implementation in any case. Sure, it=20 > would require supporting the NOTIFY *method*, as it is used=20 > in this new usage. But the hard work is in supporting the=20 > packages, not the method. And that part is the same either way. >=20 I don't agree that the method won't be hard to support. For one thing, many people use stock SIP stacks they got from somewhere else and have no idea how to add a new method or usage of a method because they've simply never had to do so before or simply can't due to other issues. Adding methods or a new nuance to an existing method may look easy on paper, but it can be a lot harder to do in practice. Much harder than, say, putting code together to toString your registration entries into XML for regevent. It's not necessarily the same either. If we use the same method, but a different dialog usage, then you could potentially have to remember which usage created the subscription in order to send the NOTIFY or process the error responses (if you're given a chance to do so by your SIP stack) in a new way. We need to take into account some history here when we're talking about fundamental tweaks to the way NOTIFY or INFO work. The dialog-usage draft makes necessary tweaks because things were broken already, but we are not similarly forced to fool with NOTIFY in this case. Non-trivial. May be worth doing, but let's not assume it's going to be simple until we have more details. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 03:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijs8F-0004GD-7l; Mon, 22 Oct 2007 03:55:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijs8E-0004G8-2d for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 03:55:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijs8D-0004FP-3T for sip@ietf.org; Mon, 22 Oct 2007 03:55:25 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijs8C-0006pm-IS for sip@ietf.org; Mon, 22 Oct 2007 03:55:24 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQA00D7ZZBPFE@siemenscomms.co.uk> for sip@ietf.org; Mon, 22 Oct 2007 08:55:01 +0100 (BST) Date: Mon, 22 Oct 2007 08:55:23 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO In-reply-to: To: Hadriel Kaplan , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D2AE@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO Thread-Index: AcgSn3FtPCWv+g5CQKOoUy6c0515OgAEncywAHN+K4A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 20 October 2007 02:30 > To: Paul Kyzivat > Cc: sip > Subject: RE: [Sip] INFO > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Hadriel Kaplan wrote: > > > > For somebody that doesn't support 3265, and doesn't want > to, but that > > does want to support these new packages within an INVITE, > this is all > > new implementation in any case. Sure, it would require > supporting the > > NOTIFY *method*, as it is used in this new usage. But the > hard work is > > in supporting the packages, not the method. And that part > is the same > > either way. > > > > >> - I would expect that any event packages defined in the > future that > > >> could meaningfully be used in this way would be > designed from the > > >> ground up to support both styles. > > > > > > True of both cases, I presume. > > > > So you are assuming that we would define packages that use a common > > encoding and semantics for messages, but that convey them > in NOTIFY for > > subscriptions and in INFO for invite-dialog usage? > > > > That is certainly possible. It just seems unappealing to me. > > Turning the tables on you: what does the method name matter? :) > For one thing, it's explicit - INFO would be for > notifications tied to an Invite dialog and usage, but not > integral to its usage. I.e., exactly what it meant before. > It would just have a new "Event"-type header, and the Invite > transaction would have carried negotiation for which events > could be used - neither of which require a new method name. > > I guess one question is which Method is more appropriate, > given the dialog-usage draft. [JRE] This has got me thinking again. A few days ago there seemed to be some consensus that we were not talking about a new dialog usage within an INVITE-initiated dialog, but merely an extension of the INVITE usage, which terminates with the BYE transaction. Now this would be different from NOTIFY requests arising from REFER implicit subscriptions - these constitute a separate dialog usage, termination of which is determined by the Subscription-State header field. IMO it gets very messy if we use the same method for requests relating to the INVITE usage and to other usages. So I am coming round to thinking NOTIFY would not be a good choice. 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 Mon Oct 22 04:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsDI-0006rd-DB; Mon, 22 Oct 2007 04:00:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjsDG-0006rS-B1 for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 04:00:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsDF-0006rH-IY for sip@ietf.org; Mon, 22 Oct 2007 04:00:37 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjsDF-00070u-3f for sip@ietf.org; Mon, 22 Oct 2007 04:00:37 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQA00B5KYZ9G8@siemenscomms.co.uk> for sip@ietf.org; Mon, 22 Oct 2007 08:47:33 +0100 (BST) Date: Mon, 22 Oct 2007 08:47:55 +0100 From: "Elwell, John" Subject: RE: [Sip] Use of the Require header in responses In-reply-to: <200710220052.l9M0qUUO013993@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D2A9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Sip] Use of the Require header in responses Thread-Index: AcgUScy8IYb8zA2KS7GE/UMioagJ4AANe2TA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <200710220052.l9M0qUUO013993@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 22 October 2007 01:53 > To: sip@ietf.org > Subject: [Sip] Use of the Require header in responses > > This message is to clarify an issue that has been causing me some > confusion, namely the meaning and use of the Require header in > responses. I hope it helps others avoid my mistakes. > > The bulk of RFC 3261 (including section 8.1.1.9 "Supported and > Require", 20.32 "Require", and 20.37 "Supported") describes the use of > the Supported and Require headers in a very straightforward way: > Supported is used to inform the other end of a dialog that the UA > supports the specified extensions. Require is used in requests to > compel the other UA to reject a request if the other UA does not > support the specified extensions. > > Within this framework, using Require in a response is pointless -- if > the UAC does not support the extension, it would be required to > discard the response, thus leaving it with no way of knowing that the > UAS wants to make use of the extension. > > However, there is separate meaning for Require when it is used in a > response, namely to indicate that the UAS has performed some > particular processing specified in the extension in question. > > This use is described in section 8.2.4 "Applying Extensions": > > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, > the server > MUST NOT apply extensions not listed in the Supported > header field in > the request. > > Of course, exactly what processing is implied by a Require header in a > response is determined by the specification of the extension in > question. > > If I recall correctly, there are three extensions or proposed > extensions that use Require headers in responses routinely. One is > the GRUU extension, but I've forgotten the other two. [JRE] I think RFC 3262 is one such extension. 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 Mon Oct 22 04:12:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsLA-0003tv-Cu; Mon, 22 Oct 2007 04:08:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjsL7-0003sG-Jc for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 04:08:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsL6-0003pc-Ie for sip@ietf.org; Mon, 22 Oct 2007 04:08:44 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjsL2-0007PG-4c for sip@ietf.org; Mon, 22 Oct 2007 04:08:40 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9M88Lh10549; Mon, 22 Oct 2007 08:08:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 03:08:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE53@zrc2hxm0.corp.nortel.com> In-Reply-To: <471930F9.3060207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgSoD2e1zm9g0PbTUKQzOdlSMU2owB37yEg References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 19, 2007 5:35 PM > To: Christer Holmberg > Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael=20 > Procter; Elwell,John > Subject: Re: [Sip] INFO >=20 >=20 >=20 > Christer Holmberg wrote: > > Hi, > > =20 > > One potential issue: the stateful intermediate receives a=20 > NOTIFY without any previous SUBSCRIBE. Is there a chance it=20 > would act on this, e.g. by sending a 4xx response, or are we=20 > sure it would always simply forward the NOTIFY and assume the=20 > endpoint will handle it? >=20 > Are you talking about a B2BUA or a proxy? >=20 > If a B2BUA, it suffers the common problem that it needs to be=20 > aware of pretty much all the standards in use by those it is=20 > connecting. No it doesn't. A B2BUA does not need to understand a great many things. One thing it does need to understand is how all of the fundamental SIP methods interact with one another. A B2BUA could be doing anything or nothing, but it always has to know when and how dialogs/usages are created, maintained and destroyed. That's the minimum requirement. >=20 > If it was not aware of this new extension, and it was trying=20 > to enforce rules about what messages are allowed in what=20 > contexts, then yes it might cause trouble. But we specify=20 > stuff all the time that has similar issues with B2BUAs. Its=20 > up to B2BUAs to figure out how to be transparent or else go away. Nice thought, but they aren't going to go away. It is currently the case, and going to continue to be the case, that a great deal of the SIP endpoints in this world will only be addressable with a B2BUA in the path for a wide variety of possible reasons.=20 Before you flame me, go ask your system engineers how many SIP endpoints they've personally seen commercially deployed that were addressable via the Internet that were not protected by some sort of ALG or B2BUA scheme that you'd be willing to post the address of their SIP proxy and the usernames of several account holders there. There may be a few, but they're pretty rare, and that's why it matters. It'd be a shame that, by not acknowledging this simple fact, that we wind up building our own walled garden. We need to make things work the best we can in the environment we're given, not the one we wish we had. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 04:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsaY-00037W-UJ; Mon, 22 Oct 2007 04:24:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjsaU-00033z-SV for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 04:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsaT-00030d-Oc for sip@ietf.org; Mon, 22 Oct 2007 04:24:37 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjsaK-0002yY-KU for sip@ietf.org; Mon, 22 Oct 2007 04:24:34 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9M8Nnh11990; Mon, 22 Oct 2007 08:23:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 03:23:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> In-Reply-To: <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUQ+CUxavdspxkRMyhMtoqRNnyQQAQKa1g References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> From: "Brian Stucker" To: "Dean Willis" , "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip , Adam Roach , Paul Kyzivat , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org Let me send you my "Twinkle, twinkle, MWI" script. A few hours of having the right people's phones blinking like they're possessed will fix that. If not, you can still use it to create the most complicated set of Christmas tree lights ever assembled. Regards, Brian=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, October 21, 2007 7:38 PM > To: Christer Holmberg > Cc: Paul Kyzivat; sip; Elwell, John; Michael Procter; Adam=20 > Roach; Stucker, Brian (RICH1:AR00) > Subject: Re: [Sip] INFO >=20 >=20 > On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote: >=20 > > Hi Paul, > > > > I am talking about a proxy. > > > > So, you are saying that the proxy would always forward the NOTIFY,=20 > > even if it does not have any state of a subscription dialog, or=20 > > subscription usage within a dialog? > > >=20 > Many proxies blindly forward NOTIFY. I know this because=20 > certain very popular phone adapters with blue boxes use=20 > unsolicited NOTIFY for their message waiting indicators, and=20 > many operators seem to have deployed them with some success,=20 > despite much gnashing of teeth on my part. >=20 > -- > Dean >=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 22 04:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjsfT-0000mE-3b; Mon, 22 Oct 2007 04:29:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjsfQ-0000h6-Lt for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 04:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijsf7-00005o-QX for sip@ietf.org; Mon, 22 Oct 2007 04:29:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijsf0-0003BY-20 for sip@ietf.org; Mon, 22 Oct 2007 04:29:25 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l9M8PxS29510; Mon, 22 Oct 2007 08:26:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 03:28:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgSn2VPIerEPjA8QJWz1hKlY6eWDQB3xBUwAACRTCAAARHu4A== References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> From: "Brian Stucker" To: "Michael Procter" , "Paul Kyzivat" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip , Adam Roach , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Michael Procter [mailto:michael.procter@citel.com]=20 > Sent: Monday, October 22, 2007 3:01 AM > To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan > Cc: Elwell, John; sip; Adam Roach > Subject: RE: [Sip] INFO >=20 >=20 > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: 22 October 2007 08:48 > > To: Paul Kyzivat; Hadriel Kaplan > > Cc: Elwell, John; sip; Michael Procter; Adam Roach > > Subject: RE: [Sip] INFO > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel=20 > Kaplan wrote: > > > >> -----Original Message----- > > > > Lastly, you don't *have* to support rfc3265 at all to > > > support 3261, so the code change could be quite a bit more. > > > > > > For somebody that doesn't support 3265, and doesn't want to, but=20 > > > that does want to support these new packages within an=20 > INVITE, this=20 > > > is all new implementation in any case. Sure, it would require=20 > > > supporting the NOTIFY *method*, as it is used in this new=20 > usage. But=20 > > > the hard work is in supporting the packages, not the method. And=20 > > > that part is the same either way. > > > > >=20 > > I don't agree that the method won't be hard to support. For=20 > one thing,=20 > > many people use stock SIP stacks they got from somewhere=20 > else and have=20 > > no idea how to add a new method or usage of a method=20 > because they've=20 > > simply never had to do so before or simply can't due to=20 > other issues. > > Adding methods or a new nuance to an existing method may=20 > look easy on=20 > > paper, but it can be a lot harder to do in practice. Much=20 > harder than,=20 > > say, putting code together to toString your registration=20 > entries into=20 > > XML for regevent. >=20 > On a similar note, I suspect that adding a header (Event?) to=20 > INFO would be simpler than subtracting a mandatory header=20 > (Subscription-State) from NOTIFY, purely in terms of the=20 > support for each in 3rd party stacks. >=20 > Of course, I am making a whole bunch of assumptions here that=20 > aren't necessarily true. So maybe this decision can be=20 > postponed until a few more details are ironed out. >=20 In this case, I think it's a pretty safe assumption. Subtracting mandatory headers from a method is not a great idea because now you've added a new path in the code where the header is semi-mandatory and the information to determine when it is mandatory, and when it is not, is not present in the message itself (so the stack may have to ask the application what's going on when it's trying to verify that the message is minimally correct which may not be possible/desirable). If I get an INFO with an event header in it, and I'm not looking for an event header in an INFO, then I'm no worse off than I am today, right? Besides, the event header isn't useful to the lower protocol layers. It's only useful to the application itself, whereas the subscription-state header is often handled by another chunk of code whose sole responsibility is to maintain subscriptions and is neither part of the stack, nor the application, but used by both. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 07:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjvCE-0007Je-8h; Mon, 22 Oct 2007 07:11:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjvCA-0007GL-DH for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 07:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjvC9-00077V-5m for sip@ietf.org; Mon, 22 Oct 2007 07:11:41 -0400 Received: from web8409.mail.in.yahoo.com ([202.43.219.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IjvBy-0002L7-K7 for sip@ietf.org; Mon, 22 Oct 2007 07:11:37 -0400 Received: (qmail 2350 invoked by uid 60001); 22 Oct 2007 11:10:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bbqASwPfuLchtNgjXn8xOcE1CWvEoNC/1FrIsAGVcmn3yScgx8rnGynxAGsDmMCDqLFoobgWMMqY0pIfehs8orDpswQRfuAT9TT4hV7eGnAaRbMk8Ny7zwTHRqDJdpRhbXmxa+3cyE5Ukw7IZ9u2+GuDeqfgzfP8izoMNX+NG3Q=; X-YMail-OSG: nQ0qvvQVM1kf8Rz0n_o5dGgAoozSxr67xOrYRwJK2ltbPSmewKLTj4rmIlQIXp2vuA7nrkVG9ohVkJE6fDHsUUMvXn6GL3H_jA_9uB7p04P7gKM3FP_CcQ2h7g-- Received: from [125.17.98.12] by web8409.mail.in.yahoo.com via HTTP; Mon, 22 Oct 2007 12:10:14 BST Date: Mon, 22 Oct 2007 12:10:14 +0100 (BST) From: rohit agrawal To: sip@ietf.org MIME-Version: 1.0 Message-ID: <497763.1451.qm@web8409.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] Query on third party registrations 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="===============1608793616==" Errors-To: sip-bounces@ietf.org --===============1608793616== Content-Type: multipart/alternative; boundary="0-1241567777-1193051414=:1451" Content-Transfer-Encoding: 8bit --0-1241567777-1193051414=:1451 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi All, I have following two queries. If any of you can give them a thought and reply I would be thankful to you. 1) What is the necessity of third party registration in IMS ? Why S-CSCF should register endpoints with its own FROM header in the REGISTER message ? Can we have some realistic examples on the same ? If in those examples the FROM header is those of endpoints won't the services will be executed at AS ? 2) IF third party registration is done and AS needs to do authentication, whose credentials should come in the re-register message ? Regards Rohit Agrawal --------------------------------- Why delete messages? Unlimited storage is just a click away. --0-1241567777-1193051414=:1451 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 
I have following two queries. If any of you can give them a thought and reply I would be thankful to you.
 
1) What is the necessity of third party registration in IMS ? Why S-CSCF should register endpoints with its own FROM header in the REGISTER message ? Can we have some realistic examples on the same ? If in those examples the FROM header is those of endpoints won't the services will be executed at AS ?
2) IF third party registration is done and AS needs to do authentication, whose credentials should come in the re-register message ?
 
Regards
Rohit Agrawal

Why delete messages? Unlimited storage is just a click away. --0-1241567777-1193051414=:1451-- --===============1608793616== 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 --===============1608793616==-- From sip-bounces@ietf.org Mon Oct 22 09:42:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxVx-0000yq-Rj; Mon, 22 Oct 2007 09:40:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjxVv-0000qK-8y for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:40:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxVr-0000Qa-J7 for sip@ietf.org; Mon, 22 Oct 2007 09:40:11 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxVo-0000vd-7i for sip@ietf.org; Mon, 22 Oct 2007 09:40:08 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MDdgp5054526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 08:39:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471CA819.7010600@nostrum.com> Date: Mon, 22 Oct 2007 08:39:37 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Sumit Garg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 23:02:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip , Paul Kyzivat , Christer Holmberg , Brian Stucker , Michael Procter , "Elwell, John" , 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: , Errors-To: sip-bounces@ietf.org Sumit Garg wrote: > Unsolicited NOTIFYs are widely used for Voicemail and are allowed in > RFC3265 > Um.... no. Please refer to the following excerpt from the section you quoted. > > Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is invalid, and > MUST receive a "481 Subscription does not exist" response (unless > some other 400- or 500-class error code is more applicable), as > described in section 3.2.4. In other words, knowledge of a > subscription must exist in both the subscriber and the notifier to be > valid, even if installed via a non-SUBSCRIBE mechanism. > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 09:42:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxTd-0003Nv-3l; Mon, 22 Oct 2007 09:37:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjxTb-0003K5-FS for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:37:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxTa-0003Id-NN for sip@ietf.org; Mon, 22 Oct 2007 09:37:50 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxTZ-0000qY-Tl for sip@ietf.org; Mon, 22 Oct 2007 09:37:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,311,1188802800"; d="scan'208";a="25769283" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 Oct 2007 06:37:49 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9MDbnCj027925; Mon, 22 Oct 2007 06:37:49 -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 l9MDbMxV004559; Mon, 22 Oct 2007 13:37:40 GMT 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.1830); Mon, 22 Oct 2007 09:37:25 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 09:37:25 -0400 Message-ID: <471CA794.6050606@cisco.com> Date: Mon, 22 Oct 2007 09:37:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 13:37:25.0527 (UTC) FILETIME=[AE8C0270:01C814B0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--32.511500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4386; t=1193060269; x=1193924269; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20; bh=HXswWs3ZiMnyixXDTKV2d9T6cJmPSQmNTWk2Dl6CZBc=; b=QePQf9wyHKMGOWakFxdUiZW1oLYaocqqz8lbI4Bost8syJtvN0QJifKGIQXIIwoAf7k7euk/ upN2nvA6FLTwSQbdpAq1aNgyYi5vlnx36Z39mZJNRurAfkzWaIa7xWCe; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip , Adam Roach , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org I'm clearly in the minority here, in preferring NOTIFY over INFO. (Minority of one?) I agree that it is impossible to make definitive claims that something is easy to implement when talking about some hypothetical sip stack. So I will refrain from making such a claim from now on. I also agree that the name of the method is secondary to getting the functionality right. So I am fine with leaving the decision about the method until everything else is worked out. So, I think the next question is whether there should be a single event package definition mechanism for this new approach and for the 3265 type of events, or if these should be entirely disjoint. I realize existing event package definitions won't be applicable without at least some tweaks, and not all event types are suitable for both mechanisms. But I do think there are event types that are suitable for both mechanisms (e.g. dtmf and dialog) and it would be better if we didn't require independent definitions for them in both contexts. What do others think of that? Thanks, Paul Brian Stucker wrote: > > >> -----Original Message----- >> From: Michael Procter [mailto:michael.procter@citel.com] >> Sent: Monday, October 22, 2007 3:01 AM >> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan >> Cc: Elwell, John; sip; Adam Roach >> Subject: RE: [Sip] INFO >> >> >>> -----Original Message----- >>> From: Brian Stucker [mailto:bstucker@nortel.com] >>> Sent: 22 October 2007 08:48 >>> To: Paul Kyzivat; Hadriel Kaplan >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach >>> Subject: RE: [Sip] INFO >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel >> Kaplan wrote: >>>>>> -----Original Message----- >>>>> Lastly, you don't *have* to support rfc3265 at all to >>>> support 3261, so the code change could be quite a bit more. >>>> >>>> For somebody that doesn't support 3265, and doesn't want to, but >>>> that does want to support these new packages within an >> INVITE, this >>>> is all new implementation in any case. Sure, it would require >>>> supporting the NOTIFY *method*, as it is used in this new >> usage. But >>>> the hard work is in supporting the packages, not the method. And >>>> that part is the same either way. >>>> >>> I don't agree that the method won't be hard to support. For >> one thing, >>> many people use stock SIP stacks they got from somewhere >> else and have >>> no idea how to add a new method or usage of a method >> because they've >>> simply never had to do so before or simply can't due to >> other issues. >>> Adding methods or a new nuance to an existing method may >> look easy on >>> paper, but it can be a lot harder to do in practice. Much >> harder than, >>> say, putting code together to toString your registration >> entries into >>> XML for regevent. >> On a similar note, I suspect that adding a header (Event?) to >> INFO would be simpler than subtracting a mandatory header >> (Subscription-State) from NOTIFY, purely in terms of the >> support for each in 3rd party stacks. >> >> Of course, I am making a whole bunch of assumptions here that >> aren't necessarily true. So maybe this decision can be >> postponed until a few more details are ironed out. >> > > In this case, I think it's a pretty safe assumption. Subtracting > mandatory headers from a method is not a great idea because now you've > added a new path in the code where the header is semi-mandatory and the > information to determine when it is mandatory, and when it is not, is > not present in the message itself (so the stack may have to ask the > application what's going on when it's trying to verify that the message > is minimally correct which may not be possible/desirable). > > If I get an INFO with an event header in it, and I'm not looking for an > event header in an INFO, then I'm no worse off than I am today, right? > Besides, the event header isn't useful to the lower protocol layers. > It's only useful to the application itself, whereas the > subscription-state header is often handled by another chunk of code > whose sole responsibility is to maintain subscriptions and is neither > part of the stack, nor the application, but used by both. > > Regards, > Brian > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 09:42:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxSL-0001UO-5S; Mon, 22 Oct 2007 09:36:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjxSH-0001Ra-U8 for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxRx-0000kv-4l for sip@ietf.org; Mon, 22 Oct 2007 09:36:09 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjxRl-00025S-F6 for sip@ietf.org; Mon, 22 Oct 2007 09:36:04 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 09:35:36 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Sip] INFO MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2007 09:35:33 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgUQ+CUxavdspxkRMyhMtoqRNnyQQAQKa1gAArItHA= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> From: "Sumit Garg" To: "Brian Stucker" , "Dean Willis" , "Christer Holmberg" X-OriginalArrivalTime: 22 Oct 2007 13:35:36.0038 (UTC) FILETIME=[6D495060:01C814B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip , "Elwell, John" , Paul Kyzivat , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org Unsolicited NOTIFYs are widely used for Voicemail and are allowed in RFC3265 Please refer to the following section.... 3.2. Description of NOTIFY Behavior NOTIFY messages are sent to inform subscribers of changes in state to which the subscriber has a subscription. Subscriptions are typically put in place using the SUBSCRIBE method; however, it is possible that other means have been used. If any non-SUBSCRIBE mechanisms are defined to create subscriptions, it is the responsibility of the parties defining those mechanisms to ensure that correlation of a NOTIFY message to the corresponding subscription is possible. Designers of such mechanisms are also warned to make a distinction between sending a NOTIFY message to a subscriber who is aware of the subscription, and sending a NOTIFY message to an unsuspecting node. The latter behavior is invalid, and MUST receive a "481 Subscription does not exist" response (unless some other 400- or 500-class error code is more applicable), as described in section 3.2.4. In other words, knowledge of a subscription must exist in both the subscriber and the notifier to be valid, even if installed via a non-SUBSCRIBE mechanism. A NOTIFY does not terminate its corresponding subscription; in other words, a single SUBSCRIBE request may trigger several NOTIFY requests. =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Brian Stucker [mailto:bstucker@nortel.com]=20 Sent: Monday, October 22, 2007 4:24 AM To: Dean Willis; Christer Holmberg Cc: sip; Adam Roach; Paul Kyzivat; Michael Procter; Elwell,John Subject: RE: [Sip] INFO Let me send you my "Twinkle, twinkle, MWI" script. A few hours of having the right people's phones blinking like they're possessed will fix that. If not, you can still use it to create the most complicated set of Christmas tree lights ever assembled. Regards, Brian=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, October 21, 2007 7:38 PM > To: Christer Holmberg > Cc: Paul Kyzivat; sip; Elwell, John; Michael Procter; Adam Roach;=20 > Stucker, Brian (RICH1:AR00) > Subject: Re: [Sip] INFO >=20 >=20 > On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote: >=20 > > Hi Paul, > > > > I am talking about a proxy. > > > > So, you are saying that the proxy would always forward the NOTIFY,=20 > > even if it does not have any state of a subscription dialog, or=20 > > subscription usage within a dialog? > > >=20 > Many proxies blindly forward NOTIFY. I know this because certain very=20 > popular phone adapters with blue boxes use unsolicited NOTIFY for=20 > their message waiting indicators, and many operators seem to have=20 > deployed them with some success, despite much gnashing of teeth on my=20 > part. >=20 > -- > Dean >=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 Mon Oct 22 09:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxjE-0000uY-7D; Mon, 22 Oct 2007 09:54:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjxjC-0000t7-0X for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxjB-0000s3-6l for sip@ietf.org; Mon, 22 Oct 2007 09:53:57 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijxj8-00036e-D3 for sip@ietf.org; Mon, 22 Oct 2007 09:53:57 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MDrXF3055427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Oct 2007 08:53:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471CAB58.9090806@nostrum.com> Date: Mon, 22 Oct 2007 08:53:28 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: IETF SIP Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> In-Reply-To: <471CA794.6050606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 23:02:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I'm clearly in the minority here, in preferring NOTIFY over INFO. > (Minority of one?) It's ridiculously rare that I disagree with you, Paul, but I'm afraid I'm going to have to weigh in on the "please don't use NOTIFY" camp. If you go back and read Sumit's message of a few minutes ago, you'll see that proper usage of NOTIFY is a matter is extreme confusion. What you propose will muddy the waters enough that I fear they'll change from "difficult to navigate" to "opaque and impossible to traverse at all." > I also agree that the name of the method is secondary to getting the > functionality right. So I am fine with leaving the decision about the > method until everything else is worked out. I completely agree here. In fact, my top preference would be to define a new method for this thing under discussion (paired with a deprecation of the much-abused INFO); with my second choice being a package-based fixup of INFO. Re-using NOTIFY would come in dead last -- by which I mean far behind "let's re-purpose ACK for this new meaning." > So, I think the next question is whether there should be a single > event package definition mechanism for this new approach and for the > 3265 type of events, or if these should be entirely disjoint. I > realize existing event package definitions won't be applicable without > at least some tweaks, and not all event types are suitable for both > mechanisms. But I do think there are event types that are suitable for > both mechanisms (e.g. dtmf and dialog) and it would be better if we > didn't require independent definitions for them in both contexts. I think the similarities are superficial at best. Re-use of the MIME type between these constructs would definitely be useful -- but I can't see what you gain by attempting to re-use more than that. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 09:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxlx-0005Oo-RB; Mon, 22 Oct 2007 09:56:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijxlv-0005Lt-9N for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:56:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxlu-0005LM-4y for sip@ietf.org; Mon, 22 Oct 2007 09:56:46 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijxlt-0001tU-Q5 for sip@ietf.org; Mon, 22 Oct 2007 09:56:46 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Mon, 22 Oct 2007 09:56:45 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 22 Oct 2007 09:56:45 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 22 Oct 2007 09:56:43 -0400 Subject: RE: [Sip] INFO Thread-Topic: [Sip] INFO Thread-Index: AcgUsL2CoooFEIpVSdiI+nt+OWW2SwAAfVkA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> In-Reply-To: <471CA794.6050606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: sip-bounces@ietf.org Yes I think that makes a lot of sense. So an RFC for event foo, would say = whether it applies to Invite-usage and can be sent in an INFO. But what if= a new event does not make sense in a true Subscribe model? Would 3265 man= date that an event definition support the event in a Subscribe-based usage?= I can think of at least two event types that would make sense in an INFO = model but not in a Sub/Not. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, October 22, 2007 9:37 AM > To: Brian Stucker > Cc: Michael Procter; Hadriel Kaplan; Elwell, John; sip; Adam Roach > Subject: Re: [Sip] INFO > > I'm clearly in the minority here, in preferring NOTIFY over INFO. > (Minority of one?) > > I agree that it is impossible to make definitive claims that something > is easy to implement when talking about some hypothetical sip stack. So > I will refrain from making such a claim from now on. > > I also agree that the name of the method is secondary to getting the > functionality right. So I am fine with leaving the decision about the > method until everything else is worked out. > > So, I think the next question is whether there should be a single event > package definition mechanism for this new approach and for the 3265 type > of events, or if these should be entirely disjoint. I realize existing > event package definitions won't be applicable without at least some > tweaks, and not all event types are suitable for both mechanisms. But I > do think there are event types that are suitable for both mechanisms > (e.g. dtmf and dialog) and it would be better if we didn't require > independent definitions for them in both contexts. > > What do others think of that? > > Thanks, > Paul > > Brian Stucker wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 09:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxnR-0007Uu-Vk; Mon, 22 Oct 2007 09:58:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjxnL-0007Qj-Sv for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxnK-0007QM-R7 for sip@ietf.org; Mon, 22 Oct 2007 09:58:14 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjxnK-0003Sl-ED for sip@ietf.org; Mon, 22 Oct 2007 09:58:14 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MDw4MI055721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2007 08:58:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <471CA794.6050606@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO Date: Mon, 22 Oct 2007 08:57:57 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 23:02:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote: > I'm clearly in the minority here, in preferring NOTIFY over INFO. > (Minority of one?) No Paul - not one. Many - we've just been worn down and aren't being as vocal as we should. Thanks for keeping up this end of the discussion. Others should chime in here. (Or is it just me and Paul?) RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 09:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxnx-0008Ah-Vb; Mon, 22 Oct 2007 09:58:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijxnt-00083R-Ah for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxnr-000830-Rs for sip@ietf.org; Mon, 22 Oct 2007 09:58:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijxnr-00026l-Is for sip@ietf.org; Mon, 22 Oct 2007 09:58:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,311,1188792000"; d="scan'208";a="74481574" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2007 09:58:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9MDwh8q001914; Mon, 22 Oct 2007 09:58:43 -0400 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 l9MDwbkX029234; Mon, 22 Oct 2007 13:58:39 GMT 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.1830); Mon, 22 Oct 2007 09:58:39 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 09:58:38 -0400 Message-ID: <471CAC8E.7000700@cisco.com> Date: Mon, 22 Oct 2007 09:58:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> In-Reply-To: <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 13:58:38.0777 (UTC) FILETIME=[A5768A90:01C814B3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--5.139400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1253; t=1193061523; x=1193925523; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Dean=20Willis=20; bh=8EYoGMLog+9XZ2mG7b8xt2KtaZaTHNfqq0HCji75txk=; b=Ic0zkeed3yuEPJhfpR5ahfQvmJ69BF6A8sQl+rDarWfVgGRTGHzM/EvVNLILIgqvvKBJxh2j klszZ7rBXxb7fLmFJ18M4ME06hCMX9GONCO6C0ghTT0HP42mLVpxDJIu; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Adam Roach , sip , Brian Stucker , Michael Procter , "Elwell, John" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote: > >> Hi Paul, >> >> I am talking about a proxy. >> >> So, you are saying that the proxy would always forward the NOTIFY, >> even if it does not have any state of a subscription dialog, or >> subscription usage within a dialog? >> > > Many proxies blindly forward NOTIFY. I know this because certain very > popular phone adapters with blue boxes use unsolicited NOTIFY for their > message waiting indicators, and many operators seem to have deployed > them with some success, despite much gnashing of teeth on my part. And apparently SBCs do too for this usage at least. I gnash my teeth over this stuff too, and I don't carry water for those who decided to do so. But it does happen. And after awhile you do have to consider that maybe the standard stuff isn't sufficient if everybody wants to violate it. Jonathan had a draft a long time ago about creating implicit subscriptions as part of registration. It isn't exactly the same problem, but I wonder if we ought to be examining the bigger problem of why the existing subscription mechanism isn't sufficient for all notification needs, and how best to fix that. 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 22 10:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxog-0000J4-2I; Mon, 22 Oct 2007 09:59:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijxoe-0000Gx-7L for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 09:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxoc-0000Ee-7z for sip@ietf.org; Mon, 22 Oct 2007 09:59:34 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=MAILSRV01.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjxoT-0003Ym-RR for sip@ietf.org; Mon, 22 Oct 2007 09:59:34 -0400 Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Oct 2007 09:59:23 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] INFO Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2007 09:59:22 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> In-Reply-To: <471CA819.7010600@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO thread-index: AcgUsUeVIqGk4uLNSU2NE/2jglcFOgAAbXag References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> <471CA819.7010600@nostrum.com> From: "Sumit Garg" To: "Adam Roach" X-OriginalArrivalTime: 22 Oct 2007 13:59:23.0370 (UTC) FILETIME=[C00AE4A0:01C814B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip , Paul Kyzivat , Christer Holmberg , Brian Stucker , Michael Procter , "Elwell, John" , 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: , Errors-To: sip-bounces@ietf.org It says, knowledge of the subscription (as in for a service/event) and not the subscribe dialog (as identified by the dialog identifiers, as there isn't any...thus nothing for the proxy to work on). 481 applies to knowledge of the dialog identifiers and thus would be generated by an unsuspecting UA who does not know about a dynamic (which has dialog ids) subscription or one negotiated through other means.=20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Monday, October 22, 2007 9:40 AM To: Sumit Garg Cc: Brian Stucker; Dean Willis; Christer Holmberg; sip; Paul Kyzivat; Michael Procter; Elwell,John Subject: Re: [Sip] INFO Sumit Garg wrote: > Unsolicited NOTIFYs are widely used for Voicemail and are allowed in > RFC3265 > =20 Um.... no. Please refer to the following excerpt from the section you quoted. > > Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is invalid, and > MUST receive a "481 Subscription does not exist" response (unless > some other 400- or 500-class error code is more applicable), as > described in section 3.2.4. In other words, knowledge of a > subscription must exist in both the subscriber and the notifier to be > valid, even if installed via a non-SUBSCRIBE mechanism. > =20 /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 10:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxt6-0004bU-1x; Mon, 22 Oct 2007 10:04:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijxt2-0004Xw-DH for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxt1-0004Xk-CK for sip@ietf.org; Mon, 22 Oct 2007 10:04:07 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjxsM-0003rP-RJ for sip@ietf.org; Mon, 22 Oct 2007 10:04:07 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9ME2tEW095842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2007 09:02:55 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO Date: Mon, 22 Oct 2007 09:02:48 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Adam Roach , sip , Paul Kyzivat , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org Hrm. I may have sent that without thinking enough and without enough context. I am guilty of not following this thread closely enough, and I replied to the wrong question I think. To be sure - I'm over in the camp that says to use the whole SIP- Events framework to do these kinds of things (I'm not supporting implicit subscriptions). On Oct 22, 2007, at 8:57 AM, Robert Sparks wrote: > > On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote: > >> I'm clearly in the minority here, in preferring NOTIFY over INFO. >> (Minority of one?) > > No Paul - not one. > > Many - we've just been worn down and aren't being as vocal as we > should. Thanks for keeping > up this end of the discussion. Others should chime in here. (Or is > it just me and Paul?) > > RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 10:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy1m-0002rt-TP; Mon, 22 Oct 2007 10:13:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijy1k-0002mf-4d for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:13:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy1i-0002l9-HC for sip@ietf.org; Mon, 22 Oct 2007 10:13:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijy1h-0003S9-Vx for sip@ietf.org; Mon, 22 Oct 2007 10:13:06 -0400 X-IronPort-AV: E=Sophos;i="4.21,311,1188792000"; d="scan'208";a="135360114" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2007 10:13:05 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9MED59m010918; Mon, 22 Oct 2007 10:13:05 -0400 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 l9MED0kT005837; Mon, 22 Oct 2007 14:13:01 GMT 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.1830); Mon, 22 Oct 2007 10:13:00 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 10:12:59 -0400 Message-ID: <471CAFEB.2040808@cisco.com> Date: Mon, 22 Oct 2007 10:12:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE53@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12A5DE53@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 14:13:00.0000 (UTC) FILETIME=[A6CABE00:01C814B5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--19.840500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3587; t=1193062385; x=1193926385; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Brian=20Stucker=20; bh=RzhrRLyfHM2FMHlZu1Ao1hrsG7A9VUD5yD9+aQAHxTc=; b=VS4Uv8R/lYhOozJ20rAyESIp/v0AA3FtTGEU7yXNy87YOABm9x3kEx3wvQ0EQZkqpPhenb4N fKL0atlN7i7IuKHgqWbr4Lx/IGDMuUkNDnVu74idEywakRNKzEFuA9/n; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Brian Stucker wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 19, 2007 5:35 PM >> To: Christer Holmberg >> Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael >> Procter; Elwell,John >> Subject: Re: [Sip] INFO >> >> >> >> Christer Holmberg wrote: >>> Hi, >>> >>> One potential issue: the stateful intermediate receives a >> NOTIFY without any previous SUBSCRIBE. Is there a chance it >> would act on this, e.g. by sending a 4xx response, or are we >> sure it would always simply forward the NOTIFY and assume the >> endpoint will handle it? >> >> Are you talking about a B2BUA or a proxy? >> >> If a B2BUA, it suffers the common problem that it needs to be >> aware of pretty much all the standards in use by those it is >> connecting. > > No it doesn't. A B2BUA does not need to understand a great many things. > One thing it does need to understand is how all of the fundamental SIP > methods interact with one another. A B2BUA could be doing anything or > nothing, but it always has to know when and how dialogs/usages are > created, maintained and destroyed. That's the minimum requirement. > >> If it was not aware of this new extension, and it was trying >> to enforce rules about what messages are allowed in what >> contexts, then yes it might cause trouble. But we specify >> stuff all the time that has similar issues with B2BUAs. Its >> up to B2BUAs to figure out how to be transparent or else go away. > > Nice thought, but they aren't going to go away. It is currently the > case, and going to continue to be the case, that a great deal of the SIP > endpoints in this world will only be addressable with a B2BUA in the > path for a wide variety of possible reasons. Note I said "*figure out how to be transparent* or else go away." A B2BUA ought to do the policy enforcement it was *intended* to do, and not break anything else. If it was *intended* to block all but a specific set of standard usage patterns, then so be it. In that case as the specs evolve and the UAs that use the specs evolve to use the new features, then the B2BUA will have to evolve to allow the new usages that should now be considered legal. A B2BUA (or proxy) that is in strict enforcement mode is as likely to block new headers as it is to block messages sent outside their expected context. So we will have similar problems with them no matter what approach we take. > Before you flame me, go ask your system engineers how many SIP endpoints > they've personally seen commercially deployed that were addressable via > the Internet that were not protected by some sort of ALG or B2BUA scheme > that you'd be willing to post the address of their SIP proxy and the > usernames of several account holders there. > > There may be a few, but they're pretty rare, and that's why it matters. > > It'd be a shame that, by not acknowledging this simple fact, that we > wind up building our own walled garden. We need to make things work the > best we can in the environment we're given, not the one we wish we had. I won't disagree. But we also have to assume that they will evolve to fit the changing standards. That is one advantage to standards relative to proprietary approaches. At least I think we are, and should try to remain, in a position where the SBCs follow the standards, as opposed to where we are re NATs and FWs, where we have to go to ridiculous extremes (ICE) to work around them. 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 22 10:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy60-0001gj-VA; Mon, 22 Oct 2007 10:17:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijy5y-0001e4-Lk for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:17:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy5x-0001dK-P1 for sip@ietf.org; Mon, 22 Oct 2007 10:17:29 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijy5x-0003hI-G2 for sip@ietf.org; Mon, 22 Oct 2007 10:17:29 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MEHExh057090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 09:17:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471CB0E5.6030201@nostrum.com> Date: Mon, 22 Oct 2007 09:17:09 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Sumit Garg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> <471CA819.7010600@nostrum.com> <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 23:02:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip , Paul Kyzivat , Dean Willis , Brian Stucker , Michael Procter , "Elwell, John" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Sumit Garg wrote: > It says, knowledge of the subscription (as in for a service/event) and > not the subscribe dialog (as identified by the dialog identifiers The subscription inherently *includes* identifiers. An example of how this was intended to work at the time is REFER. You have a subscription that is created -- dialog identifiers and all -- using something other than a SUBSCRIBE. If you haven't exchanged enough information via *some* mechanism to have dialog identifiers, then there is no subscription. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 10:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy8E-0004Gj-9E; Mon, 22 Oct 2007 10:19:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijy8C-0004Fv-3S for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:19:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy8B-0004Eq-1r for sip@ietf.org; Mon, 22 Oct 2007 10:19:47 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijy8A-0003pv-Ls for sip@ietf.org; Mon, 22 Oct 2007 10:19:46 -0400 X-IronPort-AV: E=Sophos;i="4.21,311,1188792000"; d="scan'208";a="135360434" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2007 10:19:45 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9MEJkC8013958; Mon, 22 Oct 2007 10:19:46 -0400 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 l9MEJfkF008058; Mon, 22 Oct 2007 14:19:41 GMT 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.1830); Mon, 22 Oct 2007 10:19:33 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 10:19:32 -0400 Message-ID: <471CB174.2060708@cisco.com> Date: Mon, 22 Oct 2007 10:19:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sumit Garg Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> <471CA819.7010600@nostrum.com> <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 14:19:32.0480 (UTC) FILETIME=[90BA7000:01C814B6] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--30.889200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2284; t=1193062786; x=1193926786; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO |Sender:=20 |To:=20Sumit=20Garg=20; bh=JGz7qsWMmnQp5u5iLWXfvL1EljiRpDfiuIVAq45fPFs=; b=e7OgaK7ob4MpiV/6gXfytShA2Xn5Kxlx0MxsUREuipiPfLl9vSnA++T+Lfpoq5J1mRMKeXjh cRoOhhGuSnwlhirTnCRiO9VMnRj5QTyJvbjL7Aafa7xyU3XMwdlRIBZT; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Adam Roach , sip , Christer Holmberg , Brian Stucker , Michael Procter , "Elwell, John" , 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: , Errors-To: sip-bounces@ietf.org Adam is the expert, since he is the author of 3265. And ignoring that I still agree with him. 3265 says that the NOTIFY will be sent within a dialog, except in the case of forking, where the first NOTIFY may complete the establishment of a dialog. Its impossible to have a 3265 compliant usage that doesn't somehow have that dialog. All the "unsolicited notify" MWI usages I am aware are sent without an established dialog, and so are non conforming to 3265. Paul Sumit Garg wrote: > It says, knowledge of the subscription (as in for a service/event) and > not the subscribe dialog (as identified by the dialog identifiers, as > there isn't any...thus nothing for the proxy to work on). 481 applies to > knowledge of the dialog identifiers and thus would be generated by an > unsuspecting UA who does not know about a dynamic (which has dialog ids) > subscription or one negotiated through other means. > > > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all progress > depends on the unreasonable man." > -- George Bernard Shaw > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, October 22, 2007 9:40 AM > To: Sumit Garg > Cc: Brian Stucker; Dean Willis; Christer Holmberg; sip; Paul Kyzivat; > Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > Sumit Garg wrote: >> Unsolicited NOTIFYs are widely used for Voicemail and are allowed in >> RFC3265 >> > > Um.... no. > > Please refer to the following excerpt from the section you quoted. > >> Designers of such mechanisms are also >> warned to make a distinction between sending a NOTIFY message to a >> subscriber who is aware of the subscription, and sending a NOTIFY >> message to an unsuspecting node. The latter behavior is invalid, > and >> MUST receive a "481 Subscription does not exist" response (unless >> some other 400- or 500-class error code is more applicable), as >> described in section 3.2.4. In other words, knowledge of a >> subscription must exist in both the subscriber and the notifier to > be >> valid, even if installed via a non-SUBSCRIBE mechanism. >> > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 10:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjyGh-0007Oa-9b; Mon, 22 Oct 2007 10:28:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjyGf-0007NF-HB for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:28:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjyGe-0007MK-EZ for sip@ietf.org; Mon, 22 Oct 2007 10:28:32 -0400 Received: from harjus.tutpro.com ([192.98.100.3] helo=taimen.tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjyGe-00049u-2P for sip@ietf.org; Mon, 22 Oct 2007 10:28:32 -0400 Received: by taimen.tutpro.com (Postfix, from userid 1000) id A46A233A906; Mon, 22 Oct 2007 17:28:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18204.45973.607471.176076@harjus.tutpro.com> Date: Mon, 22 Oct 2007 17:28:37 +0300 To: Paul Kyzivat Subject: Re: [Sip] INFO In-Reply-To: <471CB174.2060708@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> <471CA819.7010600@nostrum.com> <59184B4E920E854DA8ACF8E44917D49F018765E5@MAIL02.cedarpointcom.com> <471CB174.2060708@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Adam Roach , sip , Dean Willis , Brian Stucker , Michael Procter , "Elwell, John" , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > Its impossible to have a 3265 compliant usage that doesn't somehow have > that dialog. All the "unsolicited notify" MWI usages I am aware are sent > without an established dialog, and so are non conforming to 3265. and are not a good idea. if a SIP UA wants to receive MWI notifys, it must first subscribe to them. -- 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 22 11:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjyjC-00064N-A2; Mon, 22 Oct 2007 10:58:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjyjA-00063C-Mn for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 10:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijyj9-00062P-Dz for sip@ietf.org; Mon, 22 Oct 2007 10:57:59 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijyj3-0006IK-6Z for sip@ietf.org; Mon, 22 Oct 2007 10:57:59 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9MEvJ906814; Mon, 22 Oct 2007 14:57:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 09:57:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5E2BC@zrc2hxm0.corp.nortel.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F018765C6@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUQ+CUxavdspxkRMyhMtoqRNnyQQAQKa1gAArItHAAAwKnoA== References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com><4718E0C0.5000308@cisco.com><471930F9.3060207@cisco.com><09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12A5DE54@zrc2hxm0.corp.nortel.com> <59184B4E920E854DA! 8ACF8E449 17D49F018765C6@MAIL02.cedarpointcom.com> From: "Brian Stucker" To: "Sumit Garg" , "Dean Willis" , "Christer Holmberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: sip , "Elwell, John" , Paul Kyzivat , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org I know that, but it's a bad idea. Regards, Brian=20 > -----Original Message----- > From: Sumit Garg [mailto:sgarg@cedarpointcom.com]=20 > Sent: Monday, October 22, 2007 8:36 AM > To: Stucker, Brian (RICH1:AR00); Dean Willis; Christer Holmberg > Cc: sip; Adam Roach; Paul Kyzivat; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO >=20 > Unsolicited NOTIFYs are widely used for Voicemail and are allowed in > RFC3265 > Please refer to the following section.... >=20 >=20 > 3.2. Description of NOTIFY Behavior > NOTIFY messages are sent to inform subscribers of changes=20 > in state to > which the subscriber has a subscription. Subscriptions=20 > are typically > put in place using the SUBSCRIBE method; however, it is=20 > possible that > other means have been used. >=20 > If any non-SUBSCRIBE mechanisms are defined to create=20 > subscriptions, > it is the responsibility of the parties defining those=20 > mechanisms to > ensure that correlation of a NOTIFY message to the corresponding > subscription is possible. Designers of such mechanisms are also > warned to make a distinction between sending a NOTIFY message to a > subscriber who is aware of the subscription, and sending a NOTIFY > message to an unsuspecting node. The latter behavior is=20 > invalid, and > MUST receive a "481 Subscription does not exist" response (unless > some other 400- or 500-class error code is more applicable), as > described in section 3.2.4. In other words, knowledge of a > subscription must exist in both the subscriber and the=20 > notifier to be > valid, even if installed via a non-SUBSCRIBE mechanism. >=20 > A NOTIFY does not terminate its corresponding=20 > subscription; in other > words, a single SUBSCRIBE request may trigger several NOTIFY > requests. > =20 >=20 >=20 > "The reasonable man adapts himself to the world; the=20 > unreasonable one persists in trying to adapt the world to=20 > himself. Therefore all progress depends on the unreasonable man." > -- George Bernard Shaw >=20 > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Monday, October 22, 2007 4:24 AM > To: Dean Willis; Christer Holmberg > Cc: sip; Adam Roach; Paul Kyzivat; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO >=20 > Let me send you my "Twinkle, twinkle, MWI" script. A few=20 > hours of having the right people's phones blinking like=20 > they're possessed will fix that. > If not, you can still use it to create the most complicated=20 > set of Christmas tree lights ever assembled. >=20 > Regards, > Brian=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Sunday, October 21, 2007 7:38 PM > > To: Christer Holmberg > > Cc: Paul Kyzivat; sip; Elwell, John; Michael Procter; Adam Roach;=20 > > Stucker, Brian (RICH1:AR00) > > Subject: Re: [Sip] INFO > >=20 > >=20 > > On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote: > >=20 > > > Hi Paul, > > > > > > I am talking about a proxy. > > > > > > So, you are saying that the proxy would always forward=20 > the NOTIFY,=20 > > > even if it does not have any state of a subscription dialog, or=20 > > > subscription usage within a dialog? > > > > >=20 > > Many proxies blindly forward NOTIFY. I know this because=20 > certain very=20 > > popular phone adapters with blue boxes use unsolicited NOTIFY for=20 > > their message waiting indicators, and many operators seem to have=20 > > deployed them with some success, despite much gnashing of=20 > teeth on my=20 > > part. > >=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=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 Mon Oct 22 11:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjysT-0004hb-9t; Mon, 22 Oct 2007 11:07:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IjysQ-0004dh-MV for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 11:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjysP-0004Xi-Kr for sip@ietf.org; Mon, 22 Oct 2007 11:07:33 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijyqz-0006lv-Ea for sip@ietf.org; Mon, 22 Oct 2007 11:07:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9MF5Wh00160; Mon, 22 Oct 2007 15:05:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 10:05:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5E317@zrc2hxm0.corp.nortel.com> In-Reply-To: <471CAFEB.2040808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUta588jDYq6LlQaShLi4m+Rvk5gABrZOA References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE53@zrc2hxm0.corp.nortel.com> <471CAFEB.2040808@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach , Christer Holmberg 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Brian Stucker wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, October 19, 2007 5:35 PM > >> To: Christer Holmberg > >> Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael Procter;=20 > >> Elwell,John > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> Christer Holmberg wrote: > >>> Hi, > >>> =20 > >>> One potential issue: the stateful intermediate receives a > >> NOTIFY without any previous SUBSCRIBE. Is there a chance=20 > it would act=20 > >> on this, e.g. by sending a 4xx response, or are we sure it would=20 > >> always simply forward the NOTIFY and assume the endpoint=20 > will handle=20 > >> it? > >> > >> Are you talking about a B2BUA or a proxy? > >> > >> If a B2BUA, it suffers the common problem that it needs to=20 > be aware=20 > >> of pretty much all the standards in use by those it is connecting. > >=20 > > No it doesn't. A B2BUA does not need to understand a great=20 > many things. > > One thing it does need to understand is how all of the=20 > fundamental SIP=20 > > methods interact with one another. A B2BUA could be doing=20 > anything or=20 > > nothing, but it always has to know when and how dialogs/usages are=20 > > created, maintained and destroyed. That's the minimum requirement. > >=20 > >> If it was not aware of this new extension, and it was trying to=20 > >> enforce rules about what messages are allowed in what=20 > contexts, then=20 > >> yes it might cause trouble. But we specify stuff all the time that=20 > >> has similar issues with B2BUAs. Its up to B2BUAs to figure=20 > out how to=20 > >> be transparent or else go away. > >=20 > > Nice thought, but they aren't going to go away. It is currently the=20 > > case, and going to continue to be the case, that a great=20 > deal of the=20 > > SIP endpoints in this world will only be addressable with a=20 > B2BUA in=20 > > the path for a wide variety of possible reasons. >=20 > Note I said "*figure out how to be transparent* or else go away." >=20 > A B2BUA ought to do the policy enforcement it was *intended*=20 > to do, and not break anything else. If it was *intended* to=20 > block all but a specific set of standard usage patterns, then=20 > so be it. In that case as the specs evolve and the UAs that=20 > use the specs evolve to use the new features, then the B2BUA=20 > will have to evolve to allow the new usages that should now=20 > be considered legal. >=20 > A B2BUA (or proxy) that is in strict enforcement mode is as=20 > likely to block new headers as it is to block messages sent=20 > outside their expected context. So we will have similar=20 > problems with them no matter what approach we take. Yes, but allowing a new header is typically a matter of configuration. Changing the transaction model for a given method is probably not. >=20 > > Before you flame me, go ask your system engineers how many SIP=20 > > endpoints they've personally seen commercially deployed that were=20 > > addressable via the Internet that were not protected by=20 > some sort of=20 > > ALG or B2BUA scheme that you'd be willing to post the=20 > address of their=20 > > SIP proxy and the usernames of several account holders there. > >=20 > > There may be a few, but they're pretty rare, and that's why=20 > it matters. > >=20 > > It'd be a shame that, by not acknowledging this simple=20 > fact, that we=20 > > wind up building our own walled garden. We need to make things work=20 > > the best we can in the environment we're given, not the one=20 > we wish we had. >=20 > I won't disagree. But we also have to assume that they will=20 > evolve to fit the changing standards. That is one advantage=20 > to standards relative to proprietary approaches. Eventually, but we need to be smart about how we go about fitting things in where there are options available to us and show others the value of supporting a particular standard that is important, etc. Just expecting everyone to blindly go off and implement everything we write down is obviously not realistic. >=20 > At least I think we are, and should try to remain, in a=20 > position where the SBCs follow the standards, as opposed to=20 > where we are re NATs and FWs, where we have to go to=20 > ridiculous extremes (ICE) to work around them. >=20 Yes. We should strike a balance, where possible, for everyone's sake. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 11:24:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijz7R-0005so-6E; Mon, 22 Oct 2007 11:23:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijz7O-0005s1-Ds for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 11:23:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijz7N-0005rF-F9 for sip@ietf.org; Mon, 22 Oct 2007 11:23:01 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijz7G-0007of-Ga for sip@ietf.org; Mon, 22 Oct 2007 11:23:01 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQB0006MK1QDK@usaga01-in.huawei.com> for sip@ietf.org; Mon, 22 Oct 2007 08:22:38 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQB00DIQK1NWK@usaga01-in.huawei.com> for sip@ietf.org; Mon, 22 Oct 2007 08:22:38 -0700 (PDT) Date: Mon, 22 Oct 2007 10:22:04 -0500 From: Spencer Dawkins Subject: Re: [Sip] INFO To: sip@ietf.org Message-id: <03f701c814bf$4d3076f0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE53@zrc2hxm0.corp.nortel.com> <471CAFEB.2040808@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: sip-bounces@ietf.org Just to synchronize with a parallel universe... about five minutes after completing WGLC on MEDIACTRL requirements, we started wondering about scenarios where there's an SBC/B2BUA between the Application Server and Media Server. We're having The Usual Discussion where some people are saying "SBCs can change our dialog identifier components (local-tag/call-ID/remote-tag), so we need a new header" and other people are saying "SBCs can drop new headers, so we DON'T need a new header". Hilarity ensues. I was especially pleased to see Paul's note: > Note I said "*figure out how to be transparent* or else go away." > > A B2BUA ought to do the policy enforcement it was *intended* to do, and > not break anything else. If it was *intended* to block all but a specific > set of standard usage patterns, then so be it. In that case as the specs > evolve and the UAs that use the specs evolve to use the new features, then > the B2BUA will have to evolve to allow the new usages that should now be > considered legal. > > A B2BUA (or proxy) that is in strict enforcement mode is as likely to > block new headers as it is to block messages sent outside their expected > context. So we will have similar problems with them no matter what > approach we take. ... at least I don't think we're missing something obvious (although it would have been nice if we were). I strongly agree with Paul's final paragraph. > At least I think we are, and should try to remain, in a position where the > SBCs follow the standards, as opposed to where we are re NATs and FWs, > where we have to go to ridiculous extremes (ICE) to work around them. > > Paul Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 12:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijzdk-0003dh-29; Mon, 22 Oct 2007 11:56:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ijzdi-0003dT-Je for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 11:56:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijzdh-0003cy-Lj for sip@ietf.org; Mon, 22 Oct 2007 11:56:25 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijzdh-0001xr-9E for sip@ietf.org; Mon, 22 Oct 2007 11:56:25 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MFttLe063705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 10:55:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471CC80F.4000600@nostrum.com> Date: Mon, 22 Oct 2007 10:55:59 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.ne! t> In-Reply-To: <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4562/Mon Oct 22 09:15:24 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip , Paul Kyzivat , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org Allow me to clarify my position further here. Robert is right: SUBSCRIBE/NOTIFY is the correct way to address these issues. If I had my druthers, we'd be using 3265 straight-up for these applications. My prior message was based on the assumption that we'd lost the "do this the right way" battle. Taken as a given, the options I outlined in my earlier note are an attempt at damage control. /a On 10/22/07 9:02 AM, Robert Sparks wrote: > Hrm. I may have sent that without thinking enough and without enough > context. > > I am guilty of not following this thread closely enough, and I replied > to the wrong question I think. > To be sure - I'm over in the camp that says to use the whole > SIP-Events framework to do these kinds > of things (I'm not supporting implicit subscriptions). > > On Oct 22, 2007, at 8:57 AM, Robert Sparks wrote: > >> >> On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote: >> >>> I'm clearly in the minority here, in preferring NOTIFY over INFO. >>> (Minority of one?) >> >> No Paul - not one. >> >> Many - we've just been worn down and aren't being as vocal as we >> should. Thanks for keeping >> up this end of the discussion. Others should chime in here. (Or is it >> just me and Paul?) >> >> RjS > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 12:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0AU-0007bx-EU; Mon, 22 Oct 2007 12:30:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik0AR-0007Za-NQ for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 12:30:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0AQ-0007ZE-Rm for sip@ietf.org; Mon, 22 Oct 2007 12:30:14 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik0AQ-0005d0-I6 for sip@ietf.org; Mon, 22 Oct 2007 12:30:14 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9MGTbO29983; Mon, 22 Oct 2007 16:29:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 11:29:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12A5E661@zrc2hxm0.corp.nortel.com> In-Reply-To: <471CC80F.4000600@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUxBwkMgqbsWqHQe+vLEwkpQ+8GwAA+ouw References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.ne! ! t> <471 CC80F.4000600@nostrum.com> From: "Brian Stucker" To: "Adam Roach" , "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip , Paul Kyzivat , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Monday, October 22, 2007 10:56 AM > To: Robert Sparks > Cc: Robert Sparks; sip; Paul Kyzivat; Stucker, Brian=20 > (RICH1:AR00); Michael Procter; Elwell, John > Subject: Re: [Sip] INFO >=20 > Allow me to clarify my position further here. >=20 > Robert is right: SUBSCRIBE/NOTIFY is the correct way to=20 > address these issues. If I had my druthers, we'd be using=20 > 3265 straight-up for these applications. My prior message was=20 > based on the assumption that we'd lost the "do this the right=20 > way" battle. Taken as a given, the options I outlined in my=20 > earlier note are an attempt at damage control. I for one am all for doing it the right way. I just don't want to muddy up the usage for NOTIFY if at all possible because it frequently takes people awhile to get 3265 right. Usages and dialogs are two areas that people frequently get confused on so the fewer the use cases we have for NOTIFY processing, the better. I'm just asking that a NOTIFY be processed the same no matter how the subscription itself was created. It sounded like this wasn't going to be the case. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 13:08:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0gh-0006uB-23; Mon, 22 Oct 2007 13:03:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik0gf-0006tj-FF for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 13:03:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0ge-0006t2-Iv for sip@ietf.org; Mon, 22 Oct 2007 13:03:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik0gd-0001XN-TC for sip@ietf.org; Mon, 22 Oct 2007 13:03:32 -0400 X-IronPort-AV: E=Sophos;i="4.21,312,1188792000"; d="scan'208";a="135371948" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2007 13:03:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9MH3LHB005127; Mon, 22 Oct 2007 13:03:21 -0400 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 l9MH38kj009675; Mon, 22 Oct 2007 17:03:17 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 13:03:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 13:03:19 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E04124777@xmb-rtp-215.amer.cisco.com> In-Reply-To: <471CA794.6050606@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUshU78l08jmNlRm2JdmzTwsyrvgAGg9GQ From: "Sanjay Sinha (sanjsinh)" To: "Paul Kyzivat (pkyzivat)" , "Brian Stucker" X-OriginalArrivalTime: 22 Oct 2007 17:03:15.0871 (UTC) FILETIME=[6FECF2F0:01C814CD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--36.386500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5782; t=1193072601; x=1193936601; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20INFO |Sender:=20 |To:=20=22Paul=20Kyzivat=20(pkyzivat)=22=20, =0A=20=20 =20=20=20=20=20=20=22Brian=20Stucker=22=20; bh=1bVldoCZEEgNKbZHkqaHenwSWjgjtiaztxEiAZdFa8w=; b=QYodrrHnvxdWTeWWy7rfFEGuBNZH90basRCD3zWktmRb0R44qYYA7zACTbCebinbQVKRfy8a AXk4aaXN6+XsKRe/Ip11TH1boWmaBtTK8HgL98sYMNz+cTnLEkJw5CFz; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org Can the method name used for signaling be a negotiated parameter as well, in addition to the event package? So if the endpoints in dialog want to use NOTIFY, they can do that and if other pair of endpoints want to use INFO or some new method, they can do that as long as both agree on that. Regarding concern of whether proxies in the middle of signaling path will pass this NOTIFY along or not, the endpoints can exchange their addresses as part of this event package negotiation, like c line in SDP. So dtmf signaling will be sent end-to-end and will not traverse a proxy that has added itself in signaling path with a RR header. Sanjay >-----Original Message----- >From: Paul Kyzivat (pkyzivat)=20 >Sent: Monday, October 22, 2007 9:37 AM >To: Brian Stucker >Cc: sip; Adam Roach; Michael Procter; Elwell,John >Subject: Re: [Sip] INFO > >I'm clearly in the minority here, in preferring NOTIFY over INFO.=20 >(Minority of one?) > >I agree that it is impossible to make definitive claims that=20 >something is easy to implement when talking about some=20 >hypothetical sip stack. So I will refrain from making such a=20 >claim from now on. > >I also agree that the name of the method is secondary to=20 >getting the functionality right. So I am fine with leaving the=20 >decision about the method until everything else is worked out. > >So, I think the next question is whether there should be a=20 >single event package definition mechanism for this new=20 >approach and for the 3265 type of events, or if these should=20 >be entirely disjoint. I realize existing event package=20 >definitions won't be applicable without at least some tweaks,=20 >and not all event types are suitable for both mechanisms. But=20 >I do think there are event types that are suitable for both=20 >mechanisms (e.g. dtmf and dialog) and it would be better if we=20 >didn't require independent definitions for them in both contexts. > >What do others think of that? > > Thanks, > Paul > >Brian Stucker wrote: >> =20 >>=20 >>> -----Original Message----- >>> From: Michael Procter [mailto:michael.procter@citel.com] >>> Sent: Monday, October 22, 2007 3:01 AM >>> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan >>> Cc: Elwell, John; sip; Adam Roach >>> Subject: RE: [Sip] INFO >>> >>> >>>> -----Original Message----- >>>> From: Brian Stucker [mailto:bstucker@nortel.com] >>>> Sent: 22 October 2007 08:48 >>>> To: Paul Kyzivat; Hadriel Kaplan >>>> Cc: Elwell, John; sip; Michael Procter; Adam Roach >>>> Subject: RE: [Sip] INFO >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel >>> Kaplan wrote: >>>>>>> -----Original Message----- >>>>>> Lastly, you don't *have* to support rfc3265 at all to >>>>> support 3261, so the code change could be quite a bit more. >>>>> >>>>> For somebody that doesn't support 3265, and doesn't want to, but=20 >>>>> that does want to support these new packages within an >>> INVITE, this >>>>> is all new implementation in any case. Sure, it would require=20 >>>>> supporting the NOTIFY *method*, as it is used in this new >>> usage. But >>>>> the hard work is in supporting the packages, not the method. And=20 >>>>> that part is the same either way. >>>>> >>>> I don't agree that the method won't be hard to support. For >>> one thing, >>>> many people use stock SIP stacks they got from somewhere >>> else and have >>>> no idea how to add a new method or usage of a method >>> because they've >>>> simply never had to do so before or simply can't due to >>> other issues. >>>> Adding methods or a new nuance to an existing method may >>> look easy on >>>> paper, but it can be a lot harder to do in practice. Much >>> harder than, >>>> say, putting code together to toString your registration >>> entries into >>>> XML for regevent. >>> On a similar note, I suspect that adding a header (Event?) to INFO=20 >>> would be simpler than subtracting a mandatory header >>> (Subscription-State) from NOTIFY, purely in terms of the=20 >support for=20 >>> each in 3rd party stacks. >>> >>> Of course, I am making a whole bunch of assumptions here=20 >that aren't=20 >>> necessarily true. So maybe this decision can be postponed until a=20 >>> few more details are ironed out. >>> >>=20 >> In this case, I think it's a pretty safe assumption. Subtracting=20 >> mandatory headers from a method is not a great idea because=20 >now you've=20 >> added a new path in the code where the header is semi-mandatory and=20 >> the information to determine when it is mandatory, and when=20 >it is not,=20 >> is not present in the message itself (so the stack may have=20 >to ask the=20 >> application what's going on when it's trying to verify that the=20 >> message is minimally correct which may not be possible/desirable). >>=20 >> If I get an INFO with an event header in it, and I'm not looking for=20 >> an event header in an INFO, then I'm no worse off than I am=20 >today, right? >> Besides, the event header isn't useful to the lower protocol layers. >> It's only useful to the application itself, whereas the=20 >> subscription-state header is often handled by another chunk of code=20 >> whose sole responsibility is to maintain subscriptions and=20 >is neither=20 >> part of the stack, nor the application, but used by both. >>=20 >> Regards, >> Brian >>=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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 13:47:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1KA-0005Oh-Ij; Mon, 22 Oct 2007 13:44:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik1K8-0005NJ-UI for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 13:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1K7-0005Kg-Er for sip@ietf.org; Mon, 22 Oct 2007 13:44:19 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik1Io-0007RO-3V for sip@ietf.org; Mon, 22 Oct 2007 13:44:19 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9MHgPQk070552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 12:42:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471CE105.7040501@nostrum.com> Date: Mon, 22 Oct 2007 12:42:29 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] INFO References: <8983EC086A9D954BA74D9763E853CF3E04124777@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04124777@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4563/Mon Oct 22 09:29:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip , "Paul Kyzivat \(pkyzivat\)" , Michael Procter , "Elwell, John" , Brian Stucker 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: , Errors-To: sip-bounces@ietf.org On 10/22/07 12:03 PM, Sanjay Sinha (sanjsinh) wrote: > Regarding concern of whether proxies in the middle of signaling path > will pass this NOTIFY along or not, the endpoints can exchange their > addresses as part of this event package negotiation, like c line in SDP. > So dtmf signaling will be sent end-to-end and will not traverse a proxy > that has added itself in signaling path with a RR header. > Say, I'm liking this idea. Perhaps we can encode the events with RTP headers as well, instead of using SIP. Most SBCs will let RTP through (and they may block peer-to-peer sip), so this has a really high chance of making it end-to-end. Just as a strawman, perhaps we could actually include an indication of the event types in the SDP itself. For example, if we wanted to use payload type number 100 to signal DTMF tones (events 0 through 15) and the dial and ringing tones (assuming as an example that these were defined as events with codes 66 and 70, respectively), we could include the following description in the SDP body: m=audio 12346 RTP/AVP 100 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15,66,70 That should keep any meddlesome middleboxes out of the way altogether. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 14:17:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1nn-0003g1-KC; Mon, 22 Oct 2007 14:14:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik1nl-0003fW-NK for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 14:14:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1nk-0003fJ-UX for sip@ietf.org; Mon, 22 Oct 2007 14:14:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik1lu-0000XC-Aw for sip@ietf.org; Mon, 22 Oct 2007 14:14:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB25B20068; Mon, 22 Oct 2007 20:12:42 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-2f-471ce81ae534 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C3112077F; Mon, 22 Oct 2007 20:12:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 20:12:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 20:10:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUshHsDvHko0N9RhWL3u2+vQHUewAJL67L References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><47192F80.4040308@cisco.com><1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com><0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com><1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Brian Stucker" X-OriginalArrivalTime: 22 Oct 2007 18:12:42.0496 (UTC) FILETIME=[236D7800:01C814D7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org Hi, =20 I don't necessarily agree with Paul that NOTIFY is better than INFO in = this case, but I DO agree with him that we should try to focus on the = other issues. =20 We can use the INTIFY method "working name" for now. Later we can then = decide to choose an existing method, or come up with something which = sounds a little more sexy :) =20 Regards, =20 Christer ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Mon 22/10/2007 15:37 To: Brian Stucker Cc: sip; Adam Roach; Michael Procter; Elwell,John Subject: Re: [Sip] INFO I'm clearly in the minority here, in preferring NOTIFY over INFO. (Minority of one?) I agree that it is impossible to make definitive claims that something is easy to implement when talking about some hypothetical sip stack. So I will refrain from making such a claim from now on. I also agree that the name of the method is secondary to getting the functionality right. So I am fine with leaving the decision about the method until everything else is worked out. So, I think the next question is whether there should be a single event package definition mechanism for this new approach and for the 3265 type of events, or if these should be entirely disjoint. I realize existing event package definitions won't be applicable without at least some tweaks, and not all event types are suitable for both mechanisms. But I do think there are event types that are suitable for both mechanisms (e.g. dtmf and dialog) and it would be better if we didn't require independent definitions for them in both contexts. What do others think of that? Thanks, Paul Brian Stucker wrote: >=20 > >> -----Original Message----- >> From: Michael Procter [mailto:michael.procter@citel.com] >> Sent: Monday, October 22, 2007 3:01 AM >> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan >> Cc: Elwell, John; sip; Adam Roach >> Subject: RE: [Sip] INFO >> >> >>> -----Original Message----- >>> From: Brian Stucker [mailto:bstucker@nortel.com] >>> Sent: 22 October 2007 08:48 >>> To: Paul Kyzivat; Hadriel Kaplan >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach >>> Subject: RE: [Sip] INFO >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel >> Kaplan wrote: >>>>>> -----Original Message----- >>>>> Lastly, you don't *have* to support rfc3265 at all to >>>> support 3261, so the code change could be quite a bit more. >>>> >>>> For somebody that doesn't support 3265, and doesn't want to, but >>>> that does want to support these new packages within an >> INVITE, this >>>> is all new implementation in any case. Sure, it would require >>>> supporting the NOTIFY *method*, as it is used in this new >> usage. But >>>> the hard work is in supporting the packages, not the method. And >>>> that part is the same either way. >>>> >>> I don't agree that the method won't be hard to support. For >> one thing, >>> many people use stock SIP stacks they got from somewhere >> else and have >>> no idea how to add a new method or usage of a method >> because they've >>> simply never had to do so before or simply can't due to >> other issues. >>> Adding methods or a new nuance to an existing method may >> look easy on >>> paper, but it can be a lot harder to do in practice. Much >> harder than, >>> say, putting code together to toString your registration >> entries into >>> XML for regevent. >> On a similar note, I suspect that adding a header (Event?) to >> INFO would be simpler than subtracting a mandatory header >> (Subscription-State) from NOTIFY, purely in terms of the >> support for each in 3rd party stacks. >> >> Of course, I am making a whole bunch of assumptions here that >> aren't necessarily true. So maybe this decision can be >> postponed until a few more details are ironed out. >> > > In this case, I think it's a pretty safe assumption. Subtracting > mandatory headers from a method is not a great idea because now you've > added a new path in the code where the header is semi-mandatory and = the > information to determine when it is mandatory, and when it is not, is > not present in the message itself (so the stack may have to ask the > application what's going on when it's trying to verify that the = message > is minimally correct which may not be possible/desirable). > > If I get an INFO with an event header in it, and I'm not looking for = an > event header in an INFO, then I'm no worse off than I am today, right? > Besides, the event header isn't useful to the lower protocol layers. > It's only useful to the application itself, whereas the > subscription-state header is often handled by another chunk of code > whose sole responsibility is to maintain subscriptions and is neither > part of the stack, nor the application, but used by both. > > Regards, > Brian > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 14:27:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1yd-0004vZ-MH; Mon, 22 Oct 2007 14:26:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik1ya-0004rN-NX for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 14:26:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1yZ-0004ot-GV for sip@ietf.org; Mon, 22 Oct 2007 14:26:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik1yY-0007Yt-Q9 for sip@ietf.org; Mon, 22 Oct 2007 14:26:07 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9MIPm920968; Mon, 22 Oct 2007 18:25:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 13:25:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12AD655E@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUshHsDvHko0N9RhWL3u2+vQHUewAJL67LAAB8V8A= References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><47192F80.4040308@cisco.com><1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com><0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com><1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> From: "Brian Stucker" To: "Christer Holmberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: sip , "Elwell, John" , Michael Procter , Adam Roach 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: , Errors-To: sip-bounces@ietf.org How about the DATA method. :) http://old.iptel.org/ietf/callprocessing/interfaces/draft-stucker-sip-pu blish-00.txt I agree, let's figure out what we want to do before we get caught up trying to optimize it. Regards, Brian=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, October 22, 2007 1:10 PM > To: Paul Kyzivat; Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO >=20 > Hi, > =20 > I don't necessarily agree with Paul that NOTIFY is better=20 > than INFO in this case, but I DO agree with him that we=20 > should try to focus on the other issues. > =20 > We can use the INTIFY method "working name" for now. Later we=20 > can then decide to choose an existing method, or come up with=20 > something which sounds a little more sexy :) > =20 > Regards, > =20 > Christer >=20 > ________________________________ >=20 > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Mon 22/10/2007 15:37 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO >=20 >=20 >=20 > I'm clearly in the minority here, in preferring NOTIFY over INFO. > (Minority of one?) >=20 > I agree that it is impossible to make definitive claims that=20 > something is easy to implement when talking about some=20 > hypothetical sip stack. So I will refrain from making such a=20 > claim from now on. >=20 > I also agree that the name of the method is secondary to=20 > getting the functionality right. So I am fine with leaving=20 > the decision about the method until everything else is worked out. >=20 > So, I think the next question is whether there should be a=20 > single event package definition mechanism for this new=20 > approach and for the 3265 type of events, or if these should=20 > be entirely disjoint. I realize existing event package=20 > definitions won't be applicable without at least some tweaks,=20 > and not all event types are suitable for both mechanisms. But=20 > I do think there are event types that are suitable for both=20 > mechanisms (e.g. dtmf and dialog) and it would be better if=20 > we didn't require independent definitions for them in both contexts. >=20 > What do others think of that? >=20 > Thanks, > Paul >=20 > Brian Stucker wrote: > >=20 > > > >> -----Original Message----- > >> From: Michael Procter [mailto:michael.procter@citel.com] > >> Sent: Monday, October 22, 2007 3:01 AM > >> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan > >> Cc: Elwell, John; sip; Adam Roach > >> Subject: RE: [Sip] INFO > >> > >> > >>> -----Original Message----- > >>> From: Brian Stucker [mailto:bstucker@nortel.com] > >>> Sent: 22 October 2007 08:48 > >>> To: Paul Kyzivat; Hadriel Kaplan > >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach > >>> Subject: RE: [Sip] INFO > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel > >> Kaplan wrote: > >>>>>> -----Original Message----- > >>>>> Lastly, you don't *have* to support rfc3265 at all to > >>>> support 3261, so the code change could be quite a bit more. > >>>> > >>>> For somebody that doesn't support 3265, and doesn't want to, but=20 > >>>> that does want to support these new packages within an > >> INVITE, this > >>>> is all new implementation in any case. Sure, it would require=20 > >>>> supporting the NOTIFY *method*, as it is used in this new > >> usage. But > >>>> the hard work is in supporting the packages, not the method. And=20 > >>>> that part is the same either way. > >>>> > >>> I don't agree that the method won't be hard to support. For > >> one thing, > >>> many people use stock SIP stacks they got from somewhere > >> else and have > >>> no idea how to add a new method or usage of a method > >> because they've > >>> simply never had to do so before or simply can't due to > >> other issues. > >>> Adding methods or a new nuance to an existing method may > >> look easy on > >>> paper, but it can be a lot harder to do in practice. Much > >> harder than, > >>> say, putting code together to toString your registration > >> entries into > >>> XML for regevent. > >> On a similar note, I suspect that adding a header (Event?) to INFO=20 > >> would be simpler than subtracting a mandatory header > >> (Subscription-State) from NOTIFY, purely in terms of the=20 > support for=20 > >> each in 3rd party stacks. > >> > >> Of course, I am making a whole bunch of assumptions here=20 > that aren't=20 > >> necessarily true. So maybe this decision can be postponed until a=20 > >> few more details are ironed out. > >> > > > > In this case, I think it's a pretty safe assumption. Subtracting=20 > > mandatory headers from a method is not a great idea because=20 > now you've=20 > > added a new path in the code where the header is semi-mandatory and=20 > > the information to determine when it is mandatory, and when=20 > it is not,=20 > > is not present in the message itself (so the stack may have=20 > to ask the=20 > > application what's going on when it's trying to verify that the=20 > > message is minimally correct which may not be possible/desirable). > > > > If I get an INFO with an event header in it, and I'm not=20 > looking for=20 > > an event header in an INFO, then I'm no worse off than I am=20 > today, right? > > Besides, the event header isn't useful to the lower protocol layers. > > It's only useful to the application itself, whereas the=20 > > subscription-state header is often handled by another chunk of code=20 > > whose sole responsibility is to maintain subscriptions and=20 > is neither=20 > > part of the stack, nor the application, but used by both. > > > > Regards, > > Brian > > >=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 >=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 22 14:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik2FU-000443-Gs; Mon, 22 Oct 2007 14:43:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik2FT-00043W-4I for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 14:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik2FS-00042h-4Q for sip@ietf.org; Mon, 22 Oct 2007 14:43:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik2DA-0001eo-QD for sip@ietf.org; Mon, 22 Oct 2007 14:43:34 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C30E20F91; Mon, 22 Oct 2007 20:40:54 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-11-471ceeb55549 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF5102024C; Mon, 22 Oct 2007 20:40:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 20:40:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO Date: Mon, 22 Oct 2007 20:40:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: AcgUshHsDvHko0N9RhWL3u2+vQHUewAJL67LAAB8V8AAAI5i7A== References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><47192F80.4040308@cisco.com><1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com><0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com><1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com><471CA794.6050606@cisco.com> <1ECE0EB503881747 90F9694F 77522CCF12AD655E@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Brian Stucker" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2007 18:40:53.0680 (UTC) FILETIME=[1373AB00:01C814DB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: sip , Adam Roach , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org >How about the DATA method. :) Naaah.... sounds too much Star Trek ;) > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, October 22, 2007 1:10 PM > To: Paul Kyzivat; Stucker, Brian (RICH1:AR00) > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: RE: [Sip] INFO > > Hi, >=20 > I don't necessarily agree with Paul that NOTIFY is better > than INFO in this case, but I DO agree with him that we > should try to focus on the other issues. >=20 > We can use the INTIFY method "working name" for now. Later we > can then decide to choose an existing method, or come up with > something which sounds a little more sexy :) >=20 > Regards, >=20 > Christer > > ________________________________ > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Mon 22/10/2007 15:37 > To: Brian Stucker > Cc: sip; Adam Roach; Michael Procter; Elwell,John > Subject: Re: [Sip] INFO > > > > I'm clearly in the minority here, in preferring NOTIFY over INFO. > (Minority of one?) > > I agree that it is impossible to make definitive claims that > something is easy to implement when talking about some > hypothetical sip stack. So I will refrain from making such a > claim from now on. > > I also agree that the name of the method is secondary to > getting the functionality right. So I am fine with leaving > the decision about the method until everything else is worked out. > > So, I think the next question is whether there should be a > single event package definition mechanism for this new > approach and for the 3265 type of events, or if these should > be entirely disjoint. I realize existing event package > definitions won't be applicable without at least some tweaks, > and not all event types are suitable for both mechanisms. But > I do think there are event types that are suitable for both > mechanisms (e.g. dtmf and dialog) and it would be better if > we didn't require independent definitions for them in both contexts. > > What do others think of that? > > Thanks, > Paul > > Brian Stucker wrote: > > > > > >> -----Original Message----- > >> From: Michael Procter [mailto:michael.procter@citel.com] > >> Sent: Monday, October 22, 2007 3:01 AM > >> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan > >> Cc: Elwell, John; sip; Adam Roach > >> Subject: RE: [Sip] INFO > >> > >> > >>> -----Original Message----- > >>> From: Brian Stucker [mailto:bstucker@nortel.com] > >>> Sent: 22 October 2007 08:48 > >>> To: Paul Kyzivat; Hadriel Kaplan > >>> Cc: Elwell, John; sip; Michael Procter; Adam Roach > >>> Subject: RE: [Sip] INFO > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Hadriel > >> Kaplan wrote: > >>>>>> -----Original Message----- > >>>>> Lastly, you don't *have* to support rfc3265 at all to > >>>> support 3261, so the code change could be quite a bit more. > >>>> > >>>> For somebody that doesn't support 3265, and doesn't want to, but > >>>> that does want to support these new packages within an > >> INVITE, this > >>>> is all new implementation in any case. Sure, it would require > >>>> supporting the NOTIFY *method*, as it is used in this new > >> usage. But > >>>> the hard work is in supporting the packages, not the method. And > >>>> that part is the same either way. > >>>> > >>> I don't agree that the method won't be hard to support. For > >> one thing, > >>> many people use stock SIP stacks they got from somewhere > >> else and have > >>> no idea how to add a new method or usage of a method > >> because they've > >>> simply never had to do so before or simply can't due to > >> other issues. > >>> Adding methods or a new nuance to an existing method may > >> look easy on > >>> paper, but it can be a lot harder to do in practice. Much > >> harder than, > >>> say, putting code together to toString your registration > >> entries into > >>> XML for regevent. > >> On a similar note, I suspect that adding a header (Event?) to INFO > >> would be simpler than subtracting a mandatory header > >> (Subscription-State) from NOTIFY, purely in terms of the > support for > >> each in 3rd party stacks. > >> > >> Of course, I am making a whole bunch of assumptions here > that aren't > >> necessarily true. So maybe this decision can be postponed until a > >> few more details are ironed out. > >> > > > > In this case, I think it's a pretty safe assumption. Subtracting > > mandatory headers from a method is not a great idea because > now you've > > added a new path in the code where the header is semi-mandatory and > > the information to determine when it is mandatory, and when > it is not, > > is not present in the message itself (so the stack may have > to ask the > > application what's going on when it's trying to verify that the > > message is minimally correct which may not be possible/desirable). > > > > If I get an INFO with an event header in it, and I'm not > looking for > > an event header in an INFO, then I'm no worse off than I am > today, right? > > Besides, the event header isn't useful to the lower protocol layers. > > It's only useful to the application itself, whereas the > > subscription-state header is often handled by another chunk of code > > whose sole responsibility is to maintain subscriptions and > is neither > > part of the stack, nor the application, but used by both. > > > > Regards, > > Brian > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 17:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4es-0004mZ-JF; Mon, 22 Oct 2007 17:17:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik4eo-0004kN-2J for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 17:17:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4en-0004jv-1J for sip@ietf.org; Mon, 22 Oct 2007 17:17:53 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik4em-0003fj-FN for sip@ietf.org; Mon, 22 Oct 2007 17:17:52 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHm6A013420; Mon, 22 Oct 2007 14:17:48 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHjJv010261; Mon, 22 Oct 2007 14:17:47 -0700 Received: from 10.34.5.152 ([10.34.5.152]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Oct 2007 21:17:45 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 22 Oct 2007 08:55:21 -0700 Subject: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgUqs3PDDDIToCeEdyH6AAWy4mm/w== In-Reply-To: <47167C0E.70006@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.4 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: sip-bounces@ietf.org On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: [snip] > One agreed upon, NOTIFY may be sent in the agreed upon direction(s) > within the INVITE dialog usage. Whether an initial NOTIFY is required > will be determined on a per-event-package basis. (Its not needed to > establish the dialog, so its a matter if it is semantically needed in > the context of the event type.) Which is not the way NOTIFY works today, which means the sender has to have code to the effect: if( !real_notify(event_object) ) { if( needs_first_notify(event_object) ) { send_event(event_object); } } else send_event(event_object); Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the complexity of your notification stack by 2. [snip] > There is no separate subscription or timer. The dialog usage is > refreshed by INVITE or UPDATE in the conventional manner. Events to be > exchanged are renegotiated from scratch with every reINVITE or UPDATE. So what does the NOTIFY put into expires? I hear hk now: "Just stuff it with 99999." OK, this now adds another hack into send_event(), "If I am a real SUBSCRIPTION, return the timer; if I am not, return 99999." Just upped the complexity by 1. Worse yet, what does the recipient do when it gets a BYE? Now it has either a resource leak or more code: if( got_bye(dialog_object) ) { for each pseudo-dialog subscription in the (dialog_object) { consider the subscription terminated; } } Upping the complexity by 2, again. Hey - we are not done yet! I will leave as an exercise to the reader the amount of complexity added to create the implicit subscription in the first place. I forgot, this really is targeted for devices that will hard code everything and not support any real SUBSCRIBE/NOTIFY packages. [facetious] It would be much cleaner to call this thing "NOTQUITENOTIFY". Of course, since we are anal about messages and bandwidth, let's save 300ns and just call the method "I". [joking] [snip] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 17:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4fU-0005Lw-2y; Mon, 22 Oct 2007 17:18:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik4fS-0005L0-Bx for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 17:18:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4fR-0005KH-IY for sip@ietf.org; Mon, 22 Oct 2007 17:18:33 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik4fR-0003hq-0M for sip@ietf.org; Mon, 22 Oct 2007 17:18:33 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHhga013327; Mon, 22 Oct 2007 14:17:43 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHfs8000414; Mon, 22 Oct 2007 14:17:42 -0700 Received: from 10.34.5.152 ([10.34.5.152]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Oct 2007 21:17:41 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 22 Oct 2007 08:20:01 -0700 Subject: KPML design (was Re: [Sip] INFO) From: Eric Burger To: Hadriel Kaplan Message-ID: Thread-Topic: KPML design (was Re: [Sip] INFO) Thread-Index: AcgQOihRkeRFFuwEQB6F8d38b8cw/AAIi4BAARJh+Bo= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.4 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: , Errors-To: sip-bounces@ietf.org It is a design feature of KPML, in fact, an advance in the state of the art, for multiple, independent, unrelated applications to subscribe for user stimulus from the same device. Making multiple subscription handling at the device optional and not mandatory was, IMHO, an unfortunate loss at the hands of work group consensus. However, stating that it is non-deterministic is incorrect. The subsequent subscribers know reliably the device rejected their subscription request. On 10/16/07 6:59 PM, "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> On Oct 15, 2007, at 1:26 PM, Brian Stucker wrote: >>> How does 3265 make this any better? >>> >> 3265 makes it better in two ways: >> >> 1) It provides distinct dialogs for each channel of the mux. Thus, >> two events of the same class, but related to different subscriptions, >> can be distinguished. >> >> 2) It provides semantic distinction, such that two events that >> transport the same kind of content but that have different effects on >> the application can be distinguished. >> >> The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but >> retains 2. The argument is that this makes it good enough for some >> applications. However, there are obviously applications where it >> might NOT be good enough, and a separate dialog ala 3265 would be >> required. > > Actually, I'd argue the converse as well: there are applications where > "advantage 1" is a disadvantage, or at least potentially confusing. DTMF is a > primary example of this. If two app servers kpml subscribe to my Invite > dialog, I will send them both the dtmf event, assuming the regex works out. > Which one should act on it? They both will. Neither knows about the other. > (although I should note I don't think supporting two kpml subscriptions is > even required by rfc4730, which makes it even less deterministic, and gives up > "advantage 1" anyway) > > -hadriel > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 17:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4fD-000587-9U; Mon, 22 Oct 2007 17:18:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik4fA-00054u-1p for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 17:18:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik4f9-00054O-3R for sip@ietf.org; Mon, 22 Oct 2007 17:18:15 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik4f8-0003gz-ES for sip@ietf.org; Mon, 22 Oct 2007 17:18:15 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHoLG013434; Mon, 22 Oct 2007 14:17:50 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MLHjJx010261; Mon, 22 Oct 2007 14:17:48 -0700 Received: from 10.34.5.152 ([10.34.5.152]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Oct 2007 21:17:46 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 22 Oct 2007 08:55:27 -0700 Subject: Complexity (was Re: [Sip] INFO) From: Eric Burger To: Paul Kyzivat , Hadriel Kaplan Message-ID: Thread-Topic: Complexity (was Re: [Sip] INFO) Thread-Index: AcgUqtFjEAI47ICeEdyH6AAWy4mm/w== In-Reply-To: <47175590.3050003@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.4 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: , Errors-To: sip-bounces@ietf.org Folks, this is getting *way* out of hand. We have one group of people saying we have working, interoperable, satisfies all requirements, protocol mechanisms for event notification. We also, I believe, have consensus, that in some corner cases, like SIP-H.323 gateways, it would be nice to save two messages in each direction by not having to explicitly subscribe for some events. Now the question in my mind is, "How complex do we want to make SIP?" Speaking as Chair and a Participant in the LEMONADE work group, I fully endorse the work and, as often is the case, added complexity, to address unique network topologies that impacts lots of users. For more information on LEMONADE, see: http://www.ietf.org/html.charters/lemonade-charter.html http://www.standardstrack.com/ietf/lemonade/ If I am willing to add quite a bit of complexity to what is considered a complex protocol like IMAP, why am I pushing back on adding complexity to SIP? It is because mobile Internet access, and as such mobile E-Mail access, is soon to become the predominant modality of user access. Rather than being an unusual corner case, mobile access, and its intermittent connectivity, low power devices, and relatively low bandwidth issues, will shortly be the normal case. What is different here? For one thing, we have had 13 years of experience since RFC 1740 (IMAP4) was published. Interestingly, at the time, bandwidth and connectivity then was only slightly better than current mobile networks. However, the content of messages has changed by orders of magnitude, which has driven the need for adding complexity to the protocol suite to serve this important market. I do NOT see this situation here. Review the archives of the past five days. Many of the proposals are of the vein: 1. Add something like accepts/sends to create an INFO-in-an-INVITE mechanism, but if you need to say anything, use SUBSCRIBE/NOTIFY 2. Add something like implicit subscriptions to NOTIFY, somewhat specified in an INVITE, but if you need to say anything, use SUBSCRIBE/NOTIFY 3. (1) above isn't INFO, so we have to create a new method and state machine to support it. 4. (2) above is *not* NOTIFY (I'll address that in a separate thread), so we have to create a new method and state machine to support it. 5. If you do not buy my argument (2) is not the same as the existing NOTIFY, it means you will be putting a bunch of "if" statements, as the behavior will be different if there is an explicit SUBSCRIBE outside a dialog or an implicit SUBSCRIBE within an INVITE-initiated dialog. With regards to point 5, I strongly urge those in the SIP audience that do not have Computer Science degrees to review Cyclomatic Complexity (McCabe). Adding complexity to the protocol *stack* to optimize a corner case is, in the words of my eldest, "less than ideal." Please let us not go there. On 10/18/07 8:46 AM, "Paul Kyzivat" wrote: [snip] > SIP is not simple. If you have mastered doing the rest of sip then this > is not a burden. IMO people are more concerned with extra messages and > extra state than they are with making it extra simple. > > I do agree that things should be as simple as possible - but no simpler. > Too often things are made "simple" at the expense of being inadequate > for the real job. INFO is in fact an example of this. [snip] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 18:29:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5gc-0005b1-Te; Mon, 22 Oct 2007 18:23:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik5ga-0005ae-F1 for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 18:23:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik5gZ-0005aP-IY for sip@ietf.org; Mon, 22 Oct 2007 18:23:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik5gY-000060-Nh for sip@ietf.org; Mon, 22 Oct 2007 18:23:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 22 Oct 2007 15:22:24 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9MMMNZF016725; Mon, 22 Oct 2007 18:22:23 -0400 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 l9MMMF8X005819; Mon, 22 Oct 2007 22:22:15 GMT 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.1830); Mon, 22 Oct 2007 18:22:15 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 18:22:15 -0400 Message-ID: <471D2296.5030708@cisco.com> Date: Mon, 22 Oct 2007 18:22:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: Complexity (was Re: [Sip] INFO) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 22:22:15.0071 (UTC) FILETIME=[FFC71AF0:01C814F9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--41.261600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5042; t=1193091743; x=1193955743; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Complexity=20(was=20Re=3A=20[Sip]=20INFO) |Sender:=20 |To:=20Eric=20Burger=20; bh=hgi0/vDzIsl/811cMRpuAtNY9gjG3HnmMXrKL4yjGbw=; b=W90zH9uGkFywhsvzAAUWQnC8r/4mChkfnHk61P+zbaZtLxrD4YJpx//zbvITs0QWQT1quHZA KbU6FyZt5vtoy99AwBLx10J9lV8YybI2eMeoQNc2D3ShbACKig6h/9W7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Errors-To: sip-bounces@ietf.org Eric, Please note that I would be happy to keep telling people to use the standards as they are. But that doesn't seem to be working, and I don't see any way to *make* it work. (Its not working on this list, and its not working for me inside my employer's domain either.) So the alternative seems to be to try and discover *something* that isn't fatally flawed, that we could successfully get people to use in those cases where they won't use what we already have. I view this discussion as trying to figure out what, if anything, that *something* might be. IMO something *similar* to a subscription, which allows negotiation of what is to be subscribed to, but without the extra round trips to set up and tear down, seems like it could do the trick. The specific details are all negotiable. But I think something that can incorporate and coexist with "real" event packages that do the same thing would be a plus. Paul Eric Burger wrote: > Folks, this is getting *way* out of hand. > > We have one group of people saying we have working, interoperable, satisfies > all requirements, protocol mechanisms for event notification. > > We also, I believe, have consensus, that in some corner cases, like > SIP-H.323 gateways, it would be nice to save two messages in each direction > by not having to explicitly subscribe for some events. > > Now the question in my mind is, "How complex do we want to make SIP?" > > Speaking as Chair and a Participant in the LEMONADE work group, I fully > endorse the work and, as often is the case, added complexity, to address > unique network topologies that impacts lots of users. For more information > on LEMONADE, see: > http://www.ietf.org/html.charters/lemonade-charter.html > http://www.standardstrack.com/ietf/lemonade/ > > If I am willing to add quite a bit of complexity to what is considered a > complex protocol like IMAP, why am I pushing back on adding complexity to > SIP? It is because mobile Internet access, and as such mobile E-Mail > access, is soon to become the predominant modality of user access. Rather > than being an unusual corner case, mobile access, and its intermittent > connectivity, low power devices, and relatively low bandwidth issues, will > shortly be the normal case. > > What is different here? For one thing, we have had 13 years of experience > since RFC 1740 (IMAP4) was published. Interestingly, at the time, bandwidth > and connectivity then was only slightly better than current mobile networks. > However, the content of messages has changed by orders of magnitude, which > has driven the need for adding complexity to the protocol suite to serve > this important market. > > I do NOT see this situation here. > > Review the archives of the past five days. Many of the proposals are of the > vein: > > 1. Add something like accepts/sends to create an INFO-in-an-INVITE > mechanism, but if you need to say anything, use SUBSCRIBE/NOTIFY > > 2. Add something like implicit subscriptions to NOTIFY, somewhat specified > in an INVITE, but if you need to say anything, use SUBSCRIBE/NOTIFY > > 3. (1) above isn't INFO, so we have to create a new method and state machine > to support it. > > 4. (2) above is *not* NOTIFY (I'll address that in a separate thread), so we > have to create a new method and state machine to support it. > > 5. If you do not buy my argument (2) is not the same as the existing NOTIFY, > it means you will be putting a bunch of "if" statements, as the behavior > will be different if there is an explicit SUBSCRIBE outside a dialog or an > implicit SUBSCRIBE within an INVITE-initiated dialog. > > With regards to point 5, I strongly urge those in the SIP audience that do > not have Computer Science degrees to review Cyclomatic Complexity (McCabe). > > Adding complexity to the protocol *stack* to optimize a corner case is, in > the words of my eldest, "less than ideal." > > Please let us not go there. > > > On 10/18/07 8:46 AM, "Paul Kyzivat" wrote: > > [snip] > >> SIP is not simple. If you have mastered doing the rest of sip then this >> is not a burden. IMO people are more concerned with extra messages and >> extra state than they are with making it extra simple. >> >> I do agree that things should be as simple as possible - but no simpler. >> Too often things are made "simple" at the expense of being inadequate >> for the real job. INFO is in fact an example of this. > > [snip] > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 19:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6Dq-0007h5-3M; Mon, 22 Oct 2007 18:58:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik6Do-0007fV-2t for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 18:58:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6Dn-0007dZ-6h for sip@ietf.org; Mon, 22 Oct 2007 18:58:07 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik6Dm-0002Yc-FC for sip@ietf.org; Mon, 22 Oct 2007 18:58:07 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MMvSCd014207; Mon, 22 Oct 2007 15:57:28 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9MMvPfA022823; Mon, 22 Oct 2007 15:57:27 -0700 Received: from 10.34.5.152 ([10.34.5.152]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Oct 2007 22:57:25 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 22 Oct 2007 15:57:19 -0700 Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgU+z7Z/Hl7JemtRjyJdmEVIpxwhwAA6b4z In-Reply-To: <471D2484.2030109@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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: , Errors-To: sip-bounces@ietf.org Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count* of 2 or 4. However, the result is similar: there is tons of Software Engineering data that shows when modules get above a cyclomatic comlexity of 7, the number of latent defects raises non-linearly. Henning (or some lurker looking for something to do): an interesting Master's Thesis would be to calculate the theoretical minimum cyclomatic complexity of the current SIP state machine. That may answer the, "Why SIP does not interoperate" question. On 10/22/07 3:30 PM, "Paul Kyzivat" wrote: > Eric, > > I disagree with your *quantitative* assessments of how much thee things > increase complexity (by factors of 2 or 4). But I certainly agree that > complexity *will* increase. > > In the end everything we are doing increases complexity, so maybe we > should all pack up shop and go home. > > Ultimately this all comes down to deciding how complex things have to > get before people can do what they think they need to do. > > Paul > > Eric Burger wrote: >> >> >> On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: >> [snip] >>> One agreed upon, NOTIFY may be sent in the agreed upon direction(s) >>> within the INVITE dialog usage. Whether an initial NOTIFY is required >>> will be determined on a per-event-package basis. (Its not needed to >>> establish the dialog, so its a matter if it is semantically needed in >>> the context of the event type.) >> >> Which is not the way NOTIFY works today, which means the sender has to have >> code to the effect: >> >> if( !real_notify(event_object) ) >> { >> if( needs_first_notify(event_object) ) >> { >> send_event(event_object); >> } >> } >> else >> send_event(event_object); >> >> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the >> complexity of your notification stack by 2. >> >> [snip] >> >>> There is no separate subscription or timer. The dialog usage is >>> refreshed by INVITE or UPDATE in the conventional manner. Events to be >>> exchanged are renegotiated from scratch with every reINVITE or UPDATE. >> >> So what does the NOTIFY put into expires? I hear hk now: "Just stuff it >> with 99999." OK, this now adds another hack into send_event(), "If I am a >> real SUBSCRIPTION, return the timer; if I am not, return 99999." Just upped >> the complexity by 1. >> >> Worse yet, what does the recipient do when it gets a BYE? Now it has either >> a resource leak or more code: >> >> if( got_bye(dialog_object) ) >> { >> for each pseudo-dialog subscription in the (dialog_object) >> { >> consider the subscription terminated; >> } >> } >> >> Upping the complexity by 2, again. >> >> Hey - we are not done yet! I will leave as an exercise to the reader the >> amount of complexity added to create the implicit subscription in the first >> place. >> >> I forgot, this really is targeted for devices that will hard code everything >> and not support any real SUBSCRIBE/NOTIFY packages. [facetious] >> >> It would be much cleaner to call this thing "NOTQUITENOTIFY". >> >> Of course, since we are anal about messages and bandwidth, let's save 300ns >> and just call the method "I". [joking] >> >> [snip] >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 20:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7J3-0006a8-PI; Mon, 22 Oct 2007 20:07:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik7J1-0006Y4-5l for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 20:07:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7J0-0006XW-B6 for sip@ietf.org; Mon, 22 Oct 2007 20:07:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik7Iz-0007rN-Tp for sip@ietf.org; Mon, 22 Oct 2007 20:07:34 -0400 X-IronPort-AV: E=Sophos;i="4.21,313,1188792000"; d="scan'208";a="74530770" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2007 18:31:02 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9MMV2Z5014217; Mon, 22 Oct 2007 18:31:02 -0400 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 l9MMTkkP010291; Mon, 22 Oct 2007 22:30:57 GMT 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.1830); Mon, 22 Oct 2007 18:30:29 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 18:30:29 -0400 Message-ID: <471D2484.2030109@cisco.com> Date: Mon, 22 Oct 2007 18:30:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2007 22:30:29.0326 (UTC) FILETIME=[26606EE0:01C814FB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--29.228500-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3180; t=1193092262; x=1193956262; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20NOTIFY=20proposal=20is=20not=20NOTIFY=20(was=20Re=3A= 20[Sip]=20INFO) |Sender:=20 |To:=20Eric=20Burger=20; bh=IAX/cVSQ5bJ23UZD065x43hgXW/4eg3iY1GZctNrC2Y=; b=Eusrk2oJ5RDsKkhKXNOZGjFjkq73XuiHUx+QxWwBhlUe5p1l5hmgNqbSn166MlgyuNpbNWN9 KTFMBS0UrTpXTpvdyUmZV2Woj1pqmj/FU46SSKNvL5uu30EyMDPRUhpe; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Errors-To: sip-bounces@ietf.org Eric, I disagree with your *quantitative* assessments of how much thee things increase complexity (by factors of 2 or 4). But I certainly agree that complexity *will* increase. In the end everything we are doing increases complexity, so maybe we should all pack up shop and go home. Ultimately this all comes down to deciding how complex things have to get before people can do what they think they need to do. Paul Eric Burger wrote: > > > On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: > [snip] >> One agreed upon, NOTIFY may be sent in the agreed upon direction(s) >> within the INVITE dialog usage. Whether an initial NOTIFY is required >> will be determined on a per-event-package basis. (Its not needed to >> establish the dialog, so its a matter if it is semantically needed in >> the context of the event type.) > > Which is not the way NOTIFY works today, which means the sender has to have > code to the effect: > > if( !real_notify(event_object) ) > { > if( needs_first_notify(event_object) ) > { > send_event(event_object); > } > } > else > send_event(event_object); > > Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the > complexity of your notification stack by 2. > > [snip] > >> There is no separate subscription or timer. The dialog usage is >> refreshed by INVITE or UPDATE in the conventional manner. Events to be >> exchanged are renegotiated from scratch with every reINVITE or UPDATE. > > So what does the NOTIFY put into expires? I hear hk now: "Just stuff it > with 99999." OK, this now adds another hack into send_event(), "If I am a > real SUBSCRIPTION, return the timer; if I am not, return 99999." Just upped > the complexity by 1. > > Worse yet, what does the recipient do when it gets a BYE? Now it has either > a resource leak or more code: > > if( got_bye(dialog_object) ) > { > for each pseudo-dialog subscription in the (dialog_object) > { > consider the subscription terminated; > } > } > > Upping the complexity by 2, again. > > Hey - we are not done yet! I will leave as an exercise to the reader the > amount of complexity added to create the implicit subscription in the first > place. > > I forgot, this really is targeted for devices that will hard code everything > and not support any real SUBSCRIBE/NOTIFY packages. [facetious] > > It would be much cleaner to call this thing "NOTQUITENOTIFY". > > Of course, since we are anal about messages and bandwidth, let's save 300ns > and just call the method "I". [joking] > > [snip] > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 20:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7F1-0002e7-Fh; Mon, 22 Oct 2007 20:03:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik7Ez-0002ch-Lm for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 20:03:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik7Ey-0002bp-QL for sip@ietf.org; Mon, 22 Oct 2007 20:03:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik7Ex-0007eX-Ud for sip@ietf.org; Mon, 22 Oct 2007 20:03:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 Oct 2007 17:03:23 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9N03NfT023490; Mon, 22 Oct 2007 17:03:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9N03Mx7019314; Tue, 23 Oct 2007 00:03:23 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Oct 2007 20:03:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Date: Mon, 22 Oct 2007 20:03:10 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E041249F6@xmb-rtp-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgU+z7Z/Hl7JemtRjyJdmEVIpxwhwAA6b4zAAIZJkA= From: "Sanjay Sinha (sanjsinh)" To: "Eric Burger" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 Oct 2007 00:03:22.0492 (UTC) FILETIME=[203E13C0:01C81508] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000 X-TM-AS-Result: No--32.141600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5849; t=1193097803; x=1193961803; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20NOTIFY=20proposal=20is=20not=20NOTIFY=20(was=20Re=3A= 20[Sip]=20INFO) |Sender:=20; bh=czzcK71+JF0lxbeENfFxnvZ7M+Ni94uULgycGfr1Tvw=; b=HTk0TwhQh4F97cwuKKTB2E15sNuEwz+alWafaZE4zbNRBN0dDldLDZ1F25Tu8TCoZKMo5bhh fgA+LOg0i2eTfMSd7Fo3vOTqrBiLIbQqpfvi55yPDAXIO2TmhPbKvvhT; Authentication-Results: sj-dkim-3; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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: , Errors-To: sip-bounces@ietf.org Well there is a trade-off, of complexity vs. less number of messages required to negotiate a signaling mechanism for dtmf or mid-call signaling data exchange. In absence of a standard way of doing implementations have been using other mechanisms like INFO or unsolicited Notify, which works well within so called walled gardens. This whole thread started with a realization that INFO is not correct for such a mechanism. So either we agree and work out something which is standard or live with proprietary implementations. Thanks. >-----Original Message----- >From: Eric Burger [mailto:eburger@bea.com]=20 >Sent: Monday, October 22, 2007 6:57 PM >To: Paul Kyzivat (pkyzivat) >Cc: sip >Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) > >Not *factors* of 2 or 4, but cyclomatic complexity increasing=20 >by a *count* of 2 or 4. > >However, the result is similar: there is tons of Software=20 >Engineering data that shows when modules get above a=20 >cyclomatic comlexity of 7, the number of latent defects raises=20 >non-linearly. > >Henning (or some lurker looking for something to do): an=20 >interesting Master's Thesis would be to calculate the=20 >theoretical minimum cyclomatic complexity of the current SIP=20 >state machine. That may answer the, "Why SIP does not=20 >interoperate" question. > > >On 10/22/07 3:30 PM, "Paul Kyzivat" wrote: > >> Eric, >>=20 >> I disagree with your *quantitative* assessments of how much thee=20 >> things increase complexity (by factors of 2 or 4). But I certainly=20 >> agree that complexity *will* increase. >>=20 >> In the end everything we are doing increases complexity, so maybe we=20 >> should all pack up shop and go home. >>=20 >> Ultimately this all comes down to deciding how complex=20 >things have to=20 >> get before people can do what they think they need to do. >>=20 >> Paul >>=20 >> Eric Burger wrote: >>>=20 >>>=20 >>> On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: >>> [snip] >>>> One agreed upon, NOTIFY may be sent in the agreed upon=20 >direction(s)=20 >>>> within the INVITE dialog usage. Whether an initial NOTIFY is=20 >>>> required will be determined on a per-event-package basis. (Its not=20 >>>> needed to establish the dialog, so its a matter if it is=20 >>>> semantically needed in the context of the event type.) >>>=20 >>> Which is not the way NOTIFY works today, which means the sender has=20 >>> to have code to the effect: >>>=20 >>> if( !real_notify(event_object) ) >>> { >>> if( needs_first_notify(event_object) ) >>> { >>> send_event(event_object); >>> } >>> } >>> else >>> send_event(event_object); >>>=20 >>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised=20 >>> the complexity of your notification stack by 2. >>>=20 >>> [snip] >>>=20 >>>> There is no separate subscription or timer. The dialog usage is=20 >>>> refreshed by INVITE or UPDATE in the conventional manner.=20 >Events to=20 >>>> be exchanged are renegotiated from scratch with every=20 >reINVITE or UPDATE. >>>=20 >>> So what does the NOTIFY put into expires? I hear hk now:=20 >"Just stuff=20 >>> it with 99999." OK, this now adds another hack into send_event(),=20 >>> "If I am a real SUBSCRIPTION, return the timer; if I am not, return=20 >>> 99999." Just upped the complexity by 1. >>>=20 >>> Worse yet, what does the recipient do when it gets a BYE? =20 >Now it has=20 >>> either a resource leak or more code: >>>=20 >>> if( got_bye(dialog_object) ) >>> { >>> for each pseudo-dialog subscription in the (dialog_object) >>> { >>> consider the subscription terminated; >>> } >>> } >>>=20 >>> Upping the complexity by 2, again. >>>=20 >>> Hey - we are not done yet! I will leave as an exercise to=20 >the reader=20 >>> the amount of complexity added to create the implicit=20 >subscription in=20 >>> the first place. >>>=20 >>> I forgot, this really is targeted for devices that will hard code=20 >>> everything and not support any real SUBSCRIBE/NOTIFY packages. =20 >>> [facetious] >>>=20 >>> It would be much cleaner to call this thing "NOTQUITENOTIFY". >>>=20 >>> Of course, since we are anal about messages and bandwidth,=20 >let's save=20 >>> 300ns and just call the method "I". [joking] >>>=20 >>> [snip] >>>=20 >>>=20 >>> Notice: This email message, together with any attachments, may=20 >>> contain information of BEA Systems, Inc., its=20 >subsidiaries and =20 >>> affiliated entities, that may be confidential, proprietary, =20 >>> copyrighted and/or legally privileged, and is intended solely for=20 >>> the use of the individual or entity named in this message.=20 >If you are=20 >>> not the intended recipient, and have received this message=20 >in error,=20 >>> please immediately return this by email and then delete it. >>>=20 >>=20 > > > >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > > >_______________________________________________ >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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 22:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9EG-0007wW-5K; Mon, 22 Oct 2007 22:10:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik9EE-0007uN-CA for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 22:10:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9ED-0007lD-C0 for sip@ietf.org; Mon, 22 Oct 2007 22:10:45 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9EA-0006OX-1f for sip@ietf.org; Mon, 22 Oct 2007 22:10:42 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Mon, 22 Oct 2007 22:10:41 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 22 Oct 2007 22:10:41 -0400 From: Hadriel Kaplan To: Eric Burger , Paul Kyzivat Date: Mon, 22 Oct 2007 22:09:32 -0400 Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgUqs3PDDDIToCeEdyH6AAWy4mm/wAbe4mw Message-ID: References: <47167C0E.70006@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > > > There is no separate subscription or timer. The dialog usage is > > refreshed by INVITE or UPDATE in the conventional manner. Events to be > > exchanged are renegotiated from scratch with every reINVITE or UPDATE. > > So what does the NOTIFY put into expires? I hear hk now: "Just stuff it > with 99999." OK, this now adds another hack into send_event(), "If I am = a > real SUBSCRIPTION, return the timer; if I am not, return 99999." Just > upped the complexity by 1. Au contraire. I explicitly noted these types of issues in my emails as an = argument for why it should not create a true Subscription in the 3265 sense= of the word, and not use the Notify method. We should just exchange the e= vents we support in the Invite/response, and use the already-available Invi= te dialog and usage, and the already existent Info method to carry the even= ts. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 22 22:36:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9aW-0004Vw-PW; Mon, 22 Oct 2007 22:33:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik9aT-0004Qk-BM for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 22:33:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9aS-0004PW-Fg for sip@ietf.org; Mon, 22 Oct 2007 22:33:44 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9aO-0007L1-0R for sip@ietf.org; Mon, 22 Oct 2007 22:33:40 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9N2XWa28341; Tue, 23 Oct 2007 02:33:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Date: Mon, 22 Oct 2007 21:33:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12AD701C@zrc2hxm0.corp.nortel.com> In-Reply-To: <471D2484.2030109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgVCXjKmTh8Cd7eTJWR/lIw+VtrLwAEyNFQ References: <471D2484.2030109@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , "Eric Burger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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: , Errors-To: sip-bounces@ietf.org There's a difference. Creating complexity in parallel to existing mechanisms is one thing because it's optional you can pick and choose the complexity you want. Overlaying it on top of an existing mechanism is much worse. That's the concern I've had about using NOTIFY that Eric did a much better job of quantifying than I have been. I'm worried about stateful middleboxes that are going to have to figure out what the heck just happened with this weird NOTIFY and why this isn't an error to them even though they don't support it. You changed the rules of the game in a non-backwards-compatible way. Regards, Brian=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, October 22, 2007 5:30 PM > To: Eric Burger > Cc: sip > Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) >=20 > Eric, >=20 > I disagree with your *quantitative* assessments of how much=20 > thee things increase complexity (by factors of 2 or 4). But I=20 > certainly agree that complexity *will* increase. >=20 > In the end everything we are doing increases complexity, so=20 > maybe we should all pack up shop and go home. >=20 > Ultimately this all comes down to deciding how complex things=20 > have to get before people can do what they think they need to do. >=20 > Paul >=20 > Eric Burger wrote: > >=20 > >=20 > > On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: > > [snip] > >> One agreed upon, NOTIFY may be sent in the agreed upon=20 > direction(s)=20 > >> within the INVITE dialog usage. Whether an initial NOTIFY=20 > is required=20 > >> will be determined on a per-event-package basis. (Its not=20 > needed to=20 > >> establish the dialog, so its a matter if it is=20 > semantically needed in=20 > >> the context of the event type.) > >=20 > > Which is not the way NOTIFY works today, which means the=20 > sender has to=20 > > have code to the effect: > >=20 > > if( !real_notify(event_object) ) > > { > > if( needs_first_notify(event_object) ) > > { > > send_event(event_object); > > } > > } > > else > > send_event(event_object); > >=20 > > Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised=20 > > the complexity of your notification stack by 2. > >=20 > > [snip] > > =20 > >> There is no separate subscription or timer. The dialog usage is=20 > >> refreshed by INVITE or UPDATE in the conventional manner.=20 > Events to=20 > >> be exchanged are renegotiated from scratch with every=20 > reINVITE or UPDATE. > >=20 > > So what does the NOTIFY put into expires? I hear hk now:=20 > "Just stuff=20 > > it with 99999." OK, this now adds another hack into=20 > send_event(), "If=20 > > I am a real SUBSCRIPTION, return the timer; if I am not, return=20 > > 99999." Just upped the complexity by 1. > >=20 > > Worse yet, what does the recipient do when it gets a BYE? =20 > Now it has=20 > > either a resource leak or more code: > >=20 > > if( got_bye(dialog_object) ) > > { > > for each pseudo-dialog subscription in the (dialog_object) > > { > > consider the subscription terminated; > > } > > } > >=20 > > Upping the complexity by 2, again. > >=20 > > Hey - we are not done yet! I will leave as an exercise to=20 > the reader=20 > > the amount of complexity added to create the implicit=20 > subscription in=20 > > the first place. > >=20 > > I forgot, this really is targeted for devices that will hard code=20 > > everything and not support any real SUBSCRIBE/NOTIFY packages. =20 > > [facetious] > >=20 > > It would be much cleaner to call this thing "NOTQUITENOTIFY". > >=20 > > Of course, since we are anal about messages and bandwidth,=20 > let's save=20 > > 300ns and just call the method "I". [joking] > >=20 > > [snip] > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. > >=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=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 Mon Oct 22 22:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9g4-0001fY-9T; Mon, 22 Oct 2007 22:39:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik9g1-0001bW-RM for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 22:39:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9g0-0001Zl-UE for sip@ietf.org; Mon, 22 Oct 2007 22:39:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9g0-0007b3-IM for sip@ietf.org; Mon, 22 Oct 2007 22:39:28 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9N2cCs14761; Tue, 23 Oct 2007 02:38:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Date: Mon, 22 Oct 2007 21:38:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12AD7025@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgUqs3PDDDIToCeEdyH6AAWy4mm/wAbe4mwAAEYLpA= References: <47167C0E.70006@cisco.com> From: "Brian Stucker" To: "Hadriel Kaplan" , "Eric Burger" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, October 22, 2007 9:10 PM > To: Eric Burger; Paul Kyzivat > Cc: sip > Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) >=20 >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > > > > There is no separate subscription or timer. The dialog usage is=20 > > > refreshed by INVITE or UPDATE in the conventional manner.=20 > Events to=20 > > > be exchanged are renegotiated from scratch with every=20 > reINVITE or UPDATE. > > > > So what does the NOTIFY put into expires? I hear hk now:=20 > "Just stuff=20 > > it with 99999." OK, this now adds another hack into=20 > send_event(), "If=20 > > I am a real SUBSCRIPTION, return the timer; if I am not, return=20 > > 99999." Just upped the complexity by 1. >=20 > Au contraire. I explicitly noted these types of issues in my=20 > emails as an argument for why it should not create a true=20 > Subscription in the 3265 sense of the word, and not use the=20 > Notify method. We should just exchange the events we support=20 > in the Invite/response, and use the already-available Invite=20 > dialog and usage, and the already existent Info method to=20 > carry the events. >=20 > -hadriel >=20 If you wanted to be really evil Eric, you should have said that the expires header would be stuffed with "%39%39%39%39%39" so you had to put something in the middle to fix it because the other end's parser would choke otherwise. :) It seems like using INFO in the way Hadriel describes is entirely backwards compatable to existing INFO processing and solves the problem. Are we arguing asthetics here or does it really absolutely have to be NOTIFY given that the event packages themselves will likely need to be tweaked a little to support this usage anyhow? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 22 22:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9oH-0007g8-2t; Mon, 22 Oct 2007 22:48:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ik9oE-0007dq-Bs for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 22:47:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik9oD-0007cY-5L for sip@ietf.org; Mon, 22 Oct 2007 22:47:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik9oC-0007yW-GR for sip@ietf.org; Mon, 22 Oct 2007 22:47:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9N2kxa29074; Tue, 23 Oct 2007 02:46:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Complexity (was Re: [Sip] INFO) Date: Mon, 22 Oct 2007 21:46:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12AD703B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Complexity (was Re: [Sip] INFO) Thread-Index: AcgUqtFjEAI47ICeEdyH6AAWy4mm/wAc46fA References: <47175590.3050003@cisco.com> From: "Brian Stucker" To: "Eric Burger" , "Paul Kyzivat" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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: , Errors-To: sip-bounces@ietf.org You started it. :) I'm fine with leaving things well enough alone, declaring victory, moving on, and letting someone who needs an INFO like mechanism be the one to go through the torture of defining something that everyone can agree upon or living with RFC-3265 for their purposes. No more uses of INFO will be approved in the future, no evaluation given about existing uses, and a pointer off to the email archives for futher information (perhaps an informational reference? Is that allowed? Hmmm...) Pretty soon I think we're going to have sent the equivalent number of email messages on this topic INFO to have conveyed a single DTMF digit using KPML. :) Regards, Brian=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Monday, October 22, 2007 10:55 AM > To: Paul Kyzivat; Hadriel Kaplan > Cc: sip > Subject: Complexity (was Re: [Sip] INFO) >=20 > Folks, this is getting *way* out of hand. >=20 > We have one group of people saying we have working,=20 > interoperable, satisfies all requirements, protocol=20 > mechanisms for event notification. >=20 > We also, I believe, have consensus, that in some corner cases, like > SIP-H.323 gateways, it would be nice to save two messages in=20 > each direction by not having to explicitly subscribe for some events. >=20 > Now the question in my mind is, "How complex do we want to make SIP?" >=20 > Speaking as Chair and a Participant in the LEMONADE work=20 > group, I fully endorse the work and, as often is the case,=20 > added complexity, to address unique network topologies that=20 > impacts lots of users. For more information on LEMONADE, see: > http://www.ietf.org/html.charters/lemonade-charter.html > http://www.standardstrack.com/ietf/lemonade/ >=20 > If I am willing to add quite a bit of complexity to what is=20 > considered a complex protocol like IMAP, why am I pushing=20 > back on adding complexity to SIP? It is because mobile=20 > Internet access, and as such mobile E-Mail access, is soon to=20 > become the predominant modality of user access. Rather than=20 > being an unusual corner case, mobile access, and its=20 > intermittent connectivity, low power devices, and relatively=20 > low bandwidth issues, will shortly be the normal case. >=20 > What is different here? For one thing, we have had 13 years=20 > of experience since RFC 1740 (IMAP4) was published. =20 > Interestingly, at the time, bandwidth and connectivity then=20 > was only slightly better than current mobile networks. > However, the content of messages has changed by orders of=20 > magnitude, which has driven the need for adding complexity to=20 > the protocol suite to serve this important market. >=20 > I do NOT see this situation here. >=20 > Review the archives of the past five days. Many of the=20 > proposals are of the > vein: >=20 > 1. Add something like accepts/sends to create an=20 > INFO-in-an-INVITE mechanism, but if you need to say anything,=20 > use SUBSCRIBE/NOTIFY >=20 > 2. Add something like implicit subscriptions to NOTIFY,=20 > somewhat specified in an INVITE, but if you need to say=20 > anything, use SUBSCRIBE/NOTIFY >=20 > 3. (1) above isn't INFO, so we have to create a new method=20 > and state machine to support it. >=20 > 4. (2) above is *not* NOTIFY (I'll address that in a separate=20 > thread), so we have to create a new method and state machine=20 > to support it. >=20 > 5. If you do not buy my argument (2) is not the same as the=20 > existing NOTIFY, it means you will be putting a bunch of "if"=20 > statements, as the behavior will be different if there is an=20 > explicit SUBSCRIBE outside a dialog or an implicit SUBSCRIBE=20 > within an INVITE-initiated dialog. >=20 > With regards to point 5, I strongly urge those in the SIP=20 > audience that do not have Computer Science degrees to review=20 > Cyclomatic Complexity (McCabe). >=20 > Adding complexity to the protocol *stack* to optimize a=20 > corner case is, in the words of my eldest, "less than ideal." >=20 > Please let us not go there. >=20 >=20 > On 10/18/07 8:46 AM, "Paul Kyzivat" wrote: >=20 > [snip] > =20 > > SIP is not simple. If you have mastered doing the rest of sip then=20 > > this is not a burden. IMO people are more concerned with extra=20 > > messages and extra state than they are with making it extra simple. > >=20 > > I do agree that things should be as simple as possible -=20 > but no simpler. > > Too often things are made "simple" at the expense of being=20 > inadequate=20 > > for the real job. INFO is in fact an example of this. >=20 > [snip] >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=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 Mon Oct 22 23:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAIA-0000IO-7T; Mon, 22 Oct 2007 23:18:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkAI8-0000GD-El for sip-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 23:18:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkAI7-0000FW-IO for sip@ietf.org; Mon, 22 Oct 2007 23:18:51 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkAI7-00026K-BF for sip@ietf.org; Mon, 22 Oct 2007 23:18:51 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20071023031251b1500p09tve>; Tue, 23 Oct 2007 03:12:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9N3ColW032262 for ; Mon, 22 Oct 2007 23:12:50 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9N3Coda032258; Mon, 22 Oct 2007 23:12:50 -0400 Date: Mon, 22 Oct 2007 23:12:50 -0400 Message-Id: <200710230312.l9N3Coda032258@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com><4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><1ECE0EB50388174790F9694F77522CCF12A18AD2@zrc2hxm0.corp.nortel.com> <4718E0C0.5000308@cisco.com> <471930F9.3060207@cisco.com> <09F4DA0F-3441-4989-91F8-03F5C24BC529@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Errors-To: sip-bounces@ietf.org From: Dean Willis Many proxies blindly forward NOTIFY. I would hope so; a proxy doesn't get to decide whether the use of a request is OK, it is required to pass it to the UAS. 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 Tue Oct 23 00:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkBjW-00062Z-Ga; Tue, 23 Oct 2007 00:51:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkBjV-00062F-3v for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 00:51:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkBjT-00061J-Vo for sip@ietf.org; Tue, 23 Oct 2007 00:51:12 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkBjT-0007u5-JT for sip@ietf.org; Tue, 23 Oct 2007 00:51:11 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9N4pApu017352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 23:51:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471D7DB9.5050404@nostrum.com> Date: Mon, 22 Oct 2007 23:51:05 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><47192F80.4040308@cisco.com><1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com><0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com><1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <1ECE0EB50388! 174790F96 94F77522CCF12AD655E@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12AD6F0D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12AD6F0D@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4568/Mon Oct 22 23:23:16 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > > Man, I stopped looking for a few seconds, and we are still talking about > INFO???? > > For the record, I don't care that much what we do. I'd say in order of > preference: > (1) > SUB/NOTIFY-as-is-and-leave-us-alone-we-are-too-busy-and-who-cares-anyway > s > (2) NOTIFY-with-SUBSCRIBE-squished-into-INVITE > (3) INFO+negoatiation_mechanism > > And for why (2) before (3), it's probably because I don't understand > Adam's point that > this is the worst possible idea even (worst that repurposing ACK). > If by (2) you're talking about a SUBSCRIBE-initiated subscription usage in the same dialog as an INVITE usage, it's not nearly as bad. (It's still bad; c.f. the pain with REFER and [as a separate issue] the difficulty managing multiple usages in a dialog). What I was responding to was a proposal (by my reading) that some new header in INVITE would mean "start sending me NOTIFY messages." If that didn't make you shudder, you missed something. Go back and re-read it. For the bystanders: one problem is that you're changing what INVITE means, and you're changing what NOTIFY means -- and in a very non-trivial fashion. Eric has some good, practical examples in this thread about why this creates nearly untenable complexity for user agents. We've also known for many years now that one method with two effects is bad -- it is very difficult to account for the various failure and half-failure modes that result if one of the effects doesn't go as planned. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 23 00:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkBh6-0002wx-Ul; Tue, 23 Oct 2007 00:48:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkBh5-0002up-AC for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 00:48:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkBh4-0002ko-4m for sip@ietf.org; Tue, 23 Oct 2007 00:48:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkBh1-0007on-5f for sip@ietf.org; Tue, 23 Oct 2007 00:48:40 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F28820242; Tue, 23 Oct 2007 06:48:28 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-73-471d7d1b8c4a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED23520006; Tue, 23 Oct 2007 06:48:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 06:48:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: What we are trying to solve (RE: Complexity (was Re: [Sip] INFO)) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 23 Oct 2007 06:48:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What we are trying to solve (RE: Complexity (was Re: [Sip] INFO)) Thread-Index: AcgU+6JoZo4xm7O/RKazjGjfbXfOwgAMl3CU References: <471D2296.5030708@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Eric Burger" X-OriginalArrivalTime: 23 Oct 2007 04:48:27.0574 (UTC) FILETIME=[F3AA7560:01C8152F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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: , Errors-To: sip-bounces@ietf.org Hi, =20 A very good mail, Paul. =20 The thing we have been looking at is a mechanism to provide something = which the following characteristics: =20 1. Something similar to subscriptions; and 2. Something which allows "negotiation" without extra roundtrips 2. Something which does not require separate dialogs for each type of = data and each direction (i.e. something which is used as part of an = invite dialog usage). =20 =20 Yes, there are many questions (which method to use etc) that have to be = answered before we have a solution, but we have to start somewhere. =20 I have started to work on a high-level draft on this. =20 OR - we could write a Master Thesis showing there is no problem, ignore = the input we get from the real world, and simply tell people to use what = we have instead... =20 =20 Regards, =20 Christer =20 =20 =20 ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tue 23/10/2007 00:22 To: Eric Burger Cc: sip Subject: Re: Complexity (was Re: [Sip] INFO) Eric, Please note that I would be happy to keep telling people to use the standards as they are. But that doesn't seem to be working, and I don't see any way to *make* it work. (Its not working on this list, and its not working for me inside my employer's domain either.) So the alternative seems to be to try and discover *something* that isn't fatally flawed, that we could successfully get people to use in those cases where they won't use what we already have. I view this discussion as trying to figure out what, if anything, that *something* might be. IMO something *similar* to a subscription, which allows negotiation of what is to be subscribed to, but without the extra round trips to set up and tear down, seems like it could do the trick. The specific details are all negotiable. But I think something that can incorporate and coexist with "real" event packages that do the same thing would be a = plus. Paul Eric Burger wrote: > Folks, this is getting *way* out of hand. > > We have one group of people saying we have working, interoperable, = satisfies > all requirements, protocol mechanisms for event notification. > > We also, I believe, have consensus, that in some corner cases, like > SIP-H.323 gateways, it would be nice to save two messages in each = direction > by not having to explicitly subscribe for some events. > > Now the question in my mind is, "How complex do we want to make SIP?" > > Speaking as Chair and a Participant in the LEMONADE work group, I = fully > endorse the work and, as often is the case, added complexity, to = address > unique network topologies that impacts lots of users. For more = information > on LEMONADE, see: > http://www.ietf.org/html.charters/lemonade-charter.html > http://www.standardstrack.com/ietf/lemonade/ > > If I am willing to add quite a bit of complexity to what is considered = a > complex protocol like IMAP, why am I pushing back on adding complexity = to > SIP? It is because mobile Internet access, and as such mobile E-Mail > access, is soon to become the predominant modality of user access. = Rather > than being an unusual corner case, mobile access, and its intermittent > connectivity, low power devices, and relatively low bandwidth issues, = will > shortly be the normal case. > > What is different here? For one thing, we have had 13 years of = experience > since RFC 1740 (IMAP4) was published. Interestingly, at the time, = bandwidth > and connectivity then was only slightly better than current mobile = networks. > However, the content of messages has changed by orders of magnitude, = which > has driven the need for adding complexity to the protocol suite to = serve > this important market. > > I do NOT see this situation here. > > Review the archives of the past five days. Many of the proposals are = of the > vein: > > 1. Add something like accepts/sends to create an INFO-in-an-INVITE > mechanism, but if you need to say anything, use SUBSCRIBE/NOTIFY > > 2. Add something like implicit subscriptions to NOTIFY, somewhat = specified > in an INVITE, but if you need to say anything, use SUBSCRIBE/NOTIFY > > 3. (1) above isn't INFO, so we have to create a new method and state = machine > to support it. > > 4. (2) above is *not* NOTIFY (I'll address that in a separate thread), = so we > have to create a new method and state machine to support it. > > 5. If you do not buy my argument (2) is not the same as the existing = NOTIFY, > it means you will be putting a bunch of "if" statements, as the = behavior > will be different if there is an explicit SUBSCRIBE outside a dialog = or an > implicit SUBSCRIBE within an INVITE-initiated dialog. > > With regards to point 5, I strongly urge those in the SIP audience = that do > not have Computer Science degrees to review Cyclomatic Complexity = (McCabe). > > Adding complexity to the protocol *stack* to optimize a corner case = is, in > the words of my eldest, "less than ideal." > > Please let us not go there. > > > On 10/18/07 8:46 AM, "Paul Kyzivat" wrote: > > [snip] >=20 >> SIP is not simple. If you have mastered doing the rest of sip then = this >> is not a burden. IMO people are more concerned with extra messages = and >> extra state than they are with making it extra simple. >> >> I do agree that things should be as simple as possible - but no = simpler. >> Too often things are made "simple" at the expense of being inadequate >> for the real job. INFO is in fact an example of this. > > [snip] > > > Notice: This email message, together with any attachments, may = contain information of BEA Systems, Inc., its subsidiaries and = affiliated entities, that may be confidential, proprietary, = copyrighted and/or legally privileged, and is intended solely for the = use of the individual or entity named in this message. If you are not = the intended recipient, and have received this message in error, please = immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 23 03:35:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEEG-0003wf-Ku; Tue, 23 Oct 2007 03:31:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkEEE-0003sI-Fc for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 03:31:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEE0-0003Ml-1V for sip@ietf.org; Tue, 23 Oct 2007 03:30:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkEDz-0001Xd-DK for sip@ietf.org; Tue, 23 Oct 2007 03:30:51 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9C05421025; Tue, 23 Oct 2007 09:30:09 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-c9-471da30122b1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 69B372009B; Tue, 23 Oct 2007 09:30:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:30:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Only one single invite usage (was: RE: [Sip] INFO) Date: Tue, 23 Oct 2007 09:30:06 +0200 Message-ID: In-Reply-To: <471D7DB9.5050404@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Only one single invite usage (was: RE: [Sip] INFO) Thread-Index: AcgVMZJxI6nO95ncSMuNWtwjfzyL2gAE6ydg References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com><4717EC02.2000303@cisco.com><4717F4A8.3050504@nostrum.com><0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net><0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com><0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net><47189963.10709@cisco.com><4718D354.3030701@cisco.com><47192F80.4040308@cisco.com><1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com><0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com><1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <1ECE0EB50388!174790F96 94F77522CCF12AD655E@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12AD6F0D@zrc2hxm0.corp.nortel.com> <471D7 DB9.5050 404@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Francois Audet" X-OriginalArrivalTime: 23 Oct 2007 07:30:08.0429 (UTC) FILETIME=[89D375D0:01C81546] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Man, I stopped looking for a few seconds, and we are still talking about INFO???? >> >>For the record, I don't care that much what we do. I'd say in order of >>preference:=20 >> (1) SUB/NOTIFY-as-is-and-leave-us-alone-we-are-too-busy-and-who-cares-anyway s=20 >> (2) NOTIFY-with-SUBSCRIBE-squished-into-INVITE >> (3) INFO+negoatiation_mechanism >> >>And for why (2) before (3), it's probably because I don't understand=20 >>Adam's point that this is the worst possible idea even (worst that=20 >>repurposing ACK). >> =20 >=20 >If by (2) you're talking about a SUBSCRIBE-initiated=20 >subscription usage in the same dialog as an INVITE usage,=20 >it's not nearly as bad. (It's still bad; c.f. the pain with=20 >REFER and [as a separate issue] the difficulty managing=20 >multiple usages in a dialog). The idea is that you have only ONE SINGLE usage - the invite usage. Within that usage you then have something similar to "subscriptions" (if people get confused by that wording, then let's use something else). Ie you are NOT using INVITE in order to establish a separate subscription usage - ONLY to establish an invite usage (which then contains something similar to subscriptions). >What I was responding to was a proposal (by my reading) that some new header in INVITE would=20 >mean "start sending me NOTIFY messages." Yes. >If that didn't make you shudder, you missed something. Go=20 >back and re-read it. >=20 >For the bystanders: one problem is that you're changing what=20 >INVITE means, and you're changing what NOTIFY means -- and in=20 >a very non-trivial fashion. Eric has some good, practical=20 >examples in this thread about why this creates nearly=20 >untenable complexity for user agents. I don't think you are changing what INVITE means: You use INVITE to establish an invite usage - as you have done since the day SIP was born. What you ARE doing is enhancing the invite usage, by adding something the possibility to send something similar to events within it. >We've also known for many years now that one method with two=20 >effects is bad -- it is very difficult to account for the=20 >various failure and half-failure modes that result if one of=20 >the effects doesn't go as planned. The idea is that nothing changes. You would only have a single invite usage, and everything within shares the fate of that usage. 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 Tue Oct 23 08:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJ1p-0005zy-BO; Tue, 23 Oct 2007 08:38:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkJ1n-0005sQ-G0 for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 08:38:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJ1m-0005oK-AZ for sip@ietf.org; Tue, 23 Oct 2007 08:38:34 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkJ1l-0004R7-Tc for sip@ietf.org; Tue, 23 Oct 2007 08:38:34 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9NCcAQ1004411 for ; Tue, 23 Oct 2007 07:38:33 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 07:38:16 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 14:38:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2007 14:38:13 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800184A31A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgPBcv4h6/g5D89QjaqwYyPe0P9cwGazMjg From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 23 Oct 2007 12:38:13.0961 (UTC) FILETIME=[940FCB90:01C81571] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] RE: WGLC of draft-ietf-sip-hitchhikers-guide-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: , Errors-To: sip-bounces@ietf.org (As WG chair) There has been little response to this WGLC so far. So: 1) A REMINDER TO ALL SIP WG MEMBERS THAT THIS DOCUMENT IS UNDER WGLC. It is your duty to review it and post comments. Please do so by Monday 29th October. 2) An explicit request that at least one member of the SIP WG has read it from one end to the other, so that we know whether we are happy with the overall structure. If you have done this, and are happy (i.e. no comments at all), then please inform the WG chairs of this. 3) An explicit request to all editor's of published SIP (and SIPPING) RFCs. If you have the honour to have published an RFC, please review the entry for your document, and make sure it makes sense. If it doesn't, please comment. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: Monday, October 15, 2007 9:32 AM > To: IETF SIP List > Subject: WGLC of draft-ietf-sip-hitchhikers-guide-03 >=20 > (As WG chair) >=20 > This is to announce a working group last call of=20 >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers > -guide-03.txt >=20 > I would request comments on this document be made (to list=20 > and to author mentioned in the document) by Monday October 29th 2007. >=20 > Please clearly identify the text of the document that is=20 > being commented on, the nature of the comment (NIT, minor=20 > technical, major technical, etc), and any suggested=20 > resolution, even if it is only some alternatives. >=20 > Regards >=20 > Keith >=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 23 09:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJfL-0005Bo-Ly; Tue, 23 Oct 2007 09:19:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkJfG-00055A-Ir for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 09:19:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJfF-00054K-AW for sip@ietf.org; Tue, 23 Oct 2007 09:19:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJf9-0007OT-4Q for sip@ietf.org; Tue, 23 Oct 2007 09:19:21 -0400 X-IronPort-AV: E=Sophos;i="4.21,317,1188792000"; d="scan'208";a="135451335" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Oct 2007 09:19:00 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9NDIw0l003893; Tue, 23 Oct 2007 09:18:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9NDIj97002013; Tue, 23 Oct 2007 13:18:54 GMT 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.1830); Tue, 23 Oct 2007 09:18:49 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:18:49 -0400 Message-ID: <471DF4B8.6090202@cisco.com> Date: Tue, 23 Oct 2007 09:18:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Burger Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2007 13:18:49.0364 (UTC) FILETIME=[3FACCD40:01C81577] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15500.002 X-TM-AS-Result: No--26.305600-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6463; t=1193145538; x=1194009538; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20NOTIFY=20proposal=20is=20not=20NOTIFY=20(was=20Re=3A= 20[Sip]=20INFO) |Sender:=20 |To:=20Eric=20Burger=20; bh=ub3IKJLuYNJJphkiVHD4g7zOv7lH0cnWL/MyG7NNjdM=; b=AajA1WHnhhM1LrQNYttLO19mS1DIGVVwu67gX6cOS84rea+a9G7UBkNY9srmoso7QoucCFX/ rssDO7FQmq+XtZzt6Ogw4gjkSf1NhkES5D76vFjMvzQm5dk4G2nORAuA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count* > of 2 or 4. > > However, the result is similar: there is tons of Software Engineering data > that shows when modules get above a cyclomatic comlexity of 7, the number of > latent defects raises non-linearly. I'm not really a student of that stuff, but I believe that is for one function or other closed unit of code. When you take a system, if you add the complexity of each piece then of course you get a huge number. In theory you don't have to do that because the system is hierarchically decomposed into pieces each with acceptable complexity, and in *theory* you can understand them one at a time. However I have yet to see a reasonable sized system where the overall structure of all the pieces didn't introduce another kind of practical complexity that AFAIK isn't normally measured. > Henning (or some lurker looking for something to do): an interesting > Master's Thesis would be to calculate the theoretical minimum cyclomatic > complexity of the current SIP state machine. For one thing, SIP can't really be evaluated with a state machine because it has stacks. (Via and Route headers, etc.) But that doesn't really change the discussion. I'm not sure its a meaningful question. But it seems like if it could be answered, the answer would have to be in the thousands, or more, when viewed as a whole. (Which is why adding two or four is irrelevant.) To get a more meaningful number you would have to decompose it into a hierarchy of state machines (or functions, objects and methods, ...) and then find the worst case complexity of all those. > That may answer the, "Why SIP > does not interoperate" question. I certainly agree that SIP is very complex, contrary to the claims that were made for it early in its life. I don't have enough context to compare it complexity to that of earlier systems for the same job - it is my impression that they are worse. The complexity is why we have been writing guides and clarification documents, etc. (They don't *fix* the complexity, but they may help people to master it.) I do appreciate the point that the complexity arises one decision at a time, and we should always be trying to make things as simple as we can, given what we have to do. It always comes down to: is the benefit of this new feature worth the complexity that it brings. Not everybody comes to the same answer about such a question. Paul > On 10/22/07 3:30 PM, "Paul Kyzivat" wrote: > >> Eric, >> >> I disagree with your *quantitative* assessments of how much thee things >> increase complexity (by factors of 2 or 4). But I certainly agree that >> complexity *will* increase. >> >> In the end everything we are doing increases complexity, so maybe we >> should all pack up shop and go home. >> >> Ultimately this all comes down to deciding how complex things have to >> get before people can do what they think they need to do. >> >> Paul >> >> Eric Burger wrote: >>> >>> On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: >>> [snip] >>>> One agreed upon, NOTIFY may be sent in the agreed upon direction(s) >>>> within the INVITE dialog usage. Whether an initial NOTIFY is required >>>> will be determined on a per-event-package basis. (Its not needed to >>>> establish the dialog, so its a matter if it is semantically needed in >>>> the context of the event type.) >>> Which is not the way NOTIFY works today, which means the sender has to have >>> code to the effect: >>> >>> if( !real_notify(event_object) ) >>> { >>> if( needs_first_notify(event_object) ) >>> { >>> send_event(event_object); >>> } >>> } >>> else >>> send_event(event_object); >>> >>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the >>> complexity of your notification stack by 2. >>> >>> [snip] >>> >>>> There is no separate subscription or timer. The dialog usage is >>>> refreshed by INVITE or UPDATE in the conventional manner. Events to be >>>> exchanged are renegotiated from scratch with every reINVITE or UPDATE. >>> So what does the NOTIFY put into expires? I hear hk now: "Just stuff it >>> with 99999." OK, this now adds another hack into send_event(), "If I am a >>> real SUBSCRIPTION, return the timer; if I am not, return 99999." Just upped >>> the complexity by 1. >>> >>> Worse yet, what does the recipient do when it gets a BYE? Now it has either >>> a resource leak or more code: >>> >>> if( got_bye(dialog_object) ) >>> { >>> for each pseudo-dialog subscription in the (dialog_object) >>> { >>> consider the subscription terminated; >>> } >>> } >>> >>> Upping the complexity by 2, again. >>> >>> Hey - we are not done yet! I will leave as an exercise to the reader the >>> amount of complexity added to create the implicit subscription in the first >>> place. >>> >>> I forgot, this really is targeted for devices that will hard code everything >>> and not support any real SUBSCRIBE/NOTIFY packages. [facetious] >>> >>> It would be much cleaner to call this thing "NOTQUITENOTIFY". >>> >>> Of course, since we are anal about messages and bandwidth, let's save 300ns >>> and just call the method "I". [joking] >>> >>> [snip] >>> >>> >>> Notice: This email message, together with any attachments, may contain >>> information of BEA Systems, Inc., its subsidiaries and affiliated >>> entities, that may be confidential, proprietary, copyrighted and/or >>> legally privileged, and is intended solely for the use of the individual or >>> entity named in this message. If you are not the intended recipient, and have >>> received this message in error, please immediately return this by email and >>> then delete it. >>> > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 23 09:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkK1o-0007NE-6D; Tue, 23 Oct 2007 09:42:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkK1l-0007Jc-Ro for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 09:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkK1k-00079g-U2 for sip@ietf.org; Tue, 23 Oct 2007 09:42:36 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkK1X-0000Xe-VJ for sip@ietf.org; Tue, 23 Oct 2007 09:42:30 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQD002NTA23YT@usaga01-in.huawei.com> for sip@ietf.org; Tue, 23 Oct 2007 06:42:03 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQD00CLB9VLT9@usaga01-in.huawei.com> for sip@ietf.org; Tue, 23 Oct 2007 06:38:12 -0700 (PDT) Date: Tue, 23 Oct 2007 08:37:30 -0500 From: Spencer Dawkins Subject: Re: [Sip] RE: WGLC of draft-ietf-sip-hitchhikers-guide-03 To: IETF SIP List Message-id: <069801c81579$dc369590$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5D1A7985295922448D5550C94DE291800184A31A@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: , Errors-To: sip-bounces@ietf.org Hi, Keith (and Dean), I'm not sure from point 2 whether you saw http://www1.ietf.org/mail-archive/web/sip/current/msg20844.html or not (if not, that's perfectly understandable, because of the INFOblast on this mailing list). I have read the draft from one end to the other. I am happy with the overall structure. I did have one question for the SIP working group about how Jonathan might be able to point to future essential corrections in this document. That question should not be blocking for request-to-publish. Thanks, Spencer ----- Original Message ----- From: "DRAGE, Keith (Keith)" To: "IETF SIP List" Sent: Tuesday, October 23, 2007 7:38 AM Subject: [Sip] RE: WGLC of draft-ietf-sip-hitchhikers-guide-03 (As WG chair) There has been little response to this WGLC so far. So: 1) A REMINDER TO ALL SIP WG MEMBERS THAT THIS DOCUMENT IS UNDER WGLC. It is your duty to review it and post comments. Please do so by Monday 29th October. 2) An explicit request that at least one member of the SIP WG has read it from one end to the other, so that we know whether we are happy with the overall structure. If you have done this, and are happy (i.e. no comments at all), then please inform the WG chairs of this. 3) An explicit request to all editor's of published SIP (and SIPPING) RFCs. If you have the honour to have published an RFC, please review the entry for your document, and make sure it makes sense. If it doesn't, please comment. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Monday, October 15, 2007 9:32 AM > To: IETF SIP List > Subject: WGLC of draft-ietf-sip-hitchhikers-guide-03 > > (As WG chair) > > This is to announce a working group last call of > > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers > -guide-03.txt > > I would request comments on this document be made (to list > and to author mentioned in the document) by Monday October 29th 2007. > > Please clearly identify the text of the document that is > being commented on, the nature of the comment (NIT, minor > technical, major technical, etc), and any suggested > resolution, even if it is only some alternatives. > > Regards > > Keith > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 23 10:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKX5-0005CC-Pk; Tue, 23 Oct 2007 10:14:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkKX2-0005Bi-OM for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 10:14:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKX1-0005BB-Oz; Tue, 23 Oct 2007 10:14:55 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkKX1-0000Us-Fe; Tue, 23 Oct 2007 10:14:55 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9NEEsTX049838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2007 09:14:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <83A5BDBC-AB50-497A-877F-135F7E8C5AD0@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , sipping LIST , SIMPLE mailing list , sip-implementors@lists.cs.columbia.edu, discussion@sipforum.org From: Robert Sparks Date: Tue, 23 Oct 2007 09:14:48 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 71.164.172.176 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4573/Tue Oct 23 07:01:01 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Sip] SIPit 21 registration closes in less than a week 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: , Errors-To: sip-bounces@ietf.org The registration deadline for SIPit 21 is Oct 29, 6 days from now. If you have not already registered, but plan to attend, please register now. (If you can't register until later in the week, drop me a note - I need to get some information for the event setup from you early). RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 23 11:13:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLOn-0003Im-2G; Tue, 23 Oct 2007 11:10:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkLOk-0003D4-Ty for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 11:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLOj-00039a-Mh for sip@ietf.org; Tue, 23 Oct 2007 11:10:25 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkLOd-0004uc-85 for sip@ietf.org; Tue, 23 Oct 2007 11:10:25 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l9NFIh2I008453; Tue, 23 Oct 2007 10:18:43 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:10:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Oct 2007 10:09:57 -0500 Message-ID: <2D7CEF7F8F759C4AB79D7C46666F329C01CD4423@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDES RFC4568 usage clarification Thread-Index: AcgVhsZrNvMQegToQyiVW3jhk1Znrg== From: "Arun Punj" To: , X-OriginalArrivalTime: 23 Oct 2007 15:10:00.0168 (UTC) FILETIME=[C7C8B680:01C81586] X-Spam-Score: 0.0 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 Cc: fandreas@cisco.com, mbaugher@cisco.com, dwing@cisco.com Subject: [Sip] SDES RFC4568 usage clarification 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="===============1038512354==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1038512354== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81586.C7B10AD9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81586.C7B10AD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 A simple clarification on RFC4568 usage. =20 User alice@atlanta.com wants to make a call(audio/video) to bob@biloxi.com. Alice would like media between Alice&Bob to be encrypted, but would like the call to go through even if the encryption between Alice&Bob is not possible. I am interested in figuring out how the SDP exchange between Alice and Bob would proceed, for the two cases: 1. Bob supports encryption 2. Bob does not support encryption. =20 Various Options which I can think of are: =20 1. Alice sends INVITE to bob with SDP m =3D audio 30000 RTP/SAVP 0=20 a =3D crypto .... m =3D video 30000 RTP/SAVP 32 a =3D crypto.... =20 If bob supports encryption no problem. =20 If bob does not support encryption or specifically if it does not support RTP/SAVP profile it will be send back an OK with following SDP m=3Daudio 0 RTP/SAVP0 a=3Dinactive m =3D video 0 RTP/SAVP a=3Dinactive =20 At this point Alice does not know that bob does not support SAVP or if there is something else wrong with the crypto parameters. Is Alice supposed to send another RE-INVITE with RTP/AVP profile ? =20 2. Alice sends an INVITE to bob with SDP m=3Daudio 30000 RTP/AVP 0 m=3Dvideo 30002 RTP/AVP 32 m =3Daudio 30004 RTP/SAVP 0 a =3D crypto: xxxx m=3Dvideo 30006 RTP/SAVP 32 a=3Dcrypto: xxxxx =20 In this case, if bob does not support encryption he could pick up the right two streams ( maybe). However, if bob supports encryption and a=3Dcrypto attribute how does he know that=20 m=3Daudio 30000 RTP/AVP 0 and=20 m=3Daudio 30004 RTP/SAVP 0=20 really refer to the same media stream. =20 =20 3. Alice sends an INVITE to bob with SDP=20 =20 m =3D audio 30000 RTP/SAVP 0=20 a =3D crypto .... m =3D video 30000 RTP/SAVP 32 a =3D crypto.... =20 And bobs UA sends a 4xx media unacceptable message, and alice tries again without encryption.=20 =20 =20 Your comments will be helpful. =20 thanks Arun ------_=_NextPart_001_01C81586.C7B10AD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

A simple clarification on RFC4568 =  usage.

 

User alice@atlanta.com wants to make a = call(audio/video) to bob@biloxi.com. Alice would like media between Alice&Bob to be encrypted, but would like = the call to go through even if the encryption between Alice&Bob is not = possible. I am interested in figuring out how the SDP exchange between Alice and Bob = would proceed, for the two cases:

1. Bob supports = encryption

2. Bob does not support = encryption.

 

Various Options which I can think of = are:

 

1. Alice sends INVITE to bob with SDP

   m =3D audio 30000 RTP/SAVP 0 =

    a =3D crypto = ....

   m =3D video 30000 RTP/SAVP = 32

    a =3D = crypto....

 

   If bob supports encryption no = problem.

 

   If bob does not support encryption or = specifically if it does not support RTP/SAVP profile it will be send back an OK with following SDP

   m=3Daudio 0 =  RTP/SAVP0

   = a=3Dinactive

   m =3D video 0 = RTP/SAVP

   = a=3Dinactive

 

 At this point Alice does not know that bob does not support SAVP or if there is something = else wrong with the crypto parameters.  Is Alice supposed to send another = RE-INVITE with RTP/AVP profile ?

 

2. Alice sends an INVITE to bob with SDP

   m=3Daudio 30000 RTP/AVP = 0

   m=3Dvideo 30002 RTP/AVP = 32

   m =3Daudio 30004 RTP/SAVP = 0

   a =3D crypto: = xxxx

  m=3Dvideo 30006 RTP/SAVP = 32

   a=3Dcrypto: = xxxxx

 

  In this case, if bob does not support = encryption he could pick up the right two streams ( maybe). However, if bob supports encryption and a=3Dcrypto attribute how does he know that =

m=3Daudio 30000 RTP/AVP = 0

and

m=3Daudio 30004 RTP/SAVP 0 =

really refer to the same media = stream.

 

 

3. Alice sends an INVITE to bob with SDP

 

   m =3D audio 30000 RTP/SAVP 0 =

    a =3D crypto = ....

   m =3D video 30000 RTP/SAVP = 32

    a =3D = crypto....

 

And bobs UA sends a 4xx media unacceptable message, = and alice tries = again without encryption.

 

 

Your comments will be = helpful.

 

thanks

Arun

------_=_NextPart_001_01C81586.C7B10AD9-- --===============1038512354== 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 --===============1038512354==-- From sip-bounces@ietf.org Tue Oct 23 12:29:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMZH-0000pj-RF; Tue, 23 Oct 2007 12:25:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkMZF-0000hJ-D4 for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:25:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMZE-0000b2-4i for sip@ietf.org; Tue, 23 Oct 2007 12:25:20 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkMZD-0005hr-Nj for sip@ietf.org; Tue, 23 Oct 2007 12:25:20 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9NGPCTc029652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Oct 2007 11:25:14 -0500 In-Reply-To: <471CA794.6050606@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32EED15C-7885-4D0B-9058-48EFEF5D1ABA@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 23 Oct 2007 11:24:48 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: sip-bounces@ietf.org On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote: > > So, I think the next question is whether there should be a single > event package definition mechanism for this new approach and for > the 3265 type of events, or if these should be entirely disjoint. I > realize existing event package definitions won't be applicable > without at least some tweaks, and not all event types are suitable > for both mechanisms. But I do think there are event types that are > suitable for both mechanisms (e.g. dtmf and dialog) and it would be > better if we didn't require independent definitions for them in > both contexts. I also favor a single class of event package registrations, and leaving it to each event package to whether and how it works in each mode. -- 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 23 12:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMgv-0001hk-HC; Tue, 23 Oct 2007 12:33:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkMgt-0001gN-JF for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:33:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMgs-0001fx-O3 for sip@ietf.org; Tue, 23 Oct 2007 12:33:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkMgs-00060G-DC for sip@ietf.org; Tue, 23 Oct 2007 12:33:14 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9NGWafG029673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Oct 2007 11:32:38 -0500 In-Reply-To: <471CC80F.4000600@nostrum.com> References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.ne! ! t> <471CC80F.4000600@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F75BB9C-BE75-4897-931A-11EAD6424CB5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO Date: Tue, 23 Oct 2007 11:32:11 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip , Paul Kyzivat , Robert Sparks , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org On Oct 22, 2007, at 10:55 AM, Adam Roach wrote: > Allow me to clarify my position further here. > > Robert is right: SUBSCRIBE/NOTIFY is the correct way to address > these issues. If I had my druthers, we'd be using 3265 straight-up > for these applications. My prior message was based on the > assumption that we'd lost the "do this the right way" battle. Taken > as a given, the options I outlined in my earlier note are an > attempt at damage control. > I believe that the empirical evidence of a heck of a lot of implementations indicates that there are use cases where people would rather not have a full-blown event dialog in parallel to an INVITE dialog for very good reasons of capacity and complexity, but still need event passing. The original use of INFO for midcall telephony signaling is just one example of this. -- 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 23 13:28:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNTs-0003Yr-6Z; Tue, 23 Oct 2007 13:23:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkNTq-0003YE-28 for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 13:23:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNTp-0003Xq-7c for sip@ietf.org; Tue, 23 Oct 2007 13:23:49 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkNTo-0000MF-K0 for sip@ietf.org; Tue, 23 Oct 2007 13:23:49 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l9NHNNTH026133 for ; Tue, 23 Oct 2007 12:23:42 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 12:23:38 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 19:23:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Oct 2007 19:23:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800184A454@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-sip-connect-reuse-08.txt Thread-Index: AcgQU884Olh/7kRRT9m3/089eJov1QFRFYEQ References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 23 Oct 2007 17:23:36.0348 (UTC) FILETIME=[71CCB5C0:01C81599] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.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: , Errors-To: sip-bounces@ietf.org (As WG chair) Here we have a document that has been floating around for a while. We had a WGLC on it back on 26th October 2005 to complete 18th November 2005. After that we got buried in outbound, and sort of lost direction. At the last IETF meeting, we agreed to rescope this and as a result decided there support in progressing the document. You can find the record of that discussion in the proceedings for IETF#69. This draft reflects those WG decisions.=20 We would therefore like to renew the WGLC, and solicit comments by close of business on Tuesday 6th November on draft-ietf-sip-connect-reuse-08. Normal rules apply. Comments to the sip mailing list and authors. Please clearly identify the nature of your comment (editorial, minor technical, major). Please clearly identify the text to which your comment relates. Note that of the normative references, domain-certs is in progress as a WG item, and we should see a first draft of the WG text in the next few days. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, October 17, 2007 1:15 AM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-08.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Connection Reuse in the Session Initiation=20 > Protocol (SIP) > Author(s) : R. Mahy, et al. > Filename : draft-ietf-sip-connect-reuse-08.txt > Pages : 21 > Date : 2007-10-16 > =09 > This document enables a pair of communicating proxies to reuse a > congestion-controlled connection between themselves for sending > requests in the forward and backwards direction. Because the > connection is essentially aliased for requests going in=20 > the backwards > direction, reuse should be predicated upon both the communicating > endpoints authenticating themselves using X.509=20 > certificates through > TLS. For this reason, we only consider connection reuse=20 > for TLS over > TCP and TLS over SCTP. A single connection cannot be=20 > reused for the > TCP or SCTP transport between two peers, and this document provides > insight into why this is the case. As a remedy, it suggests using > two TCP connections (or two SCTP associations), each opened pro- > actively towards the recipient by the sender. Finally,=20 > this document > also provides guidelines on connection reuse and virtual=20 > SIP servers > and the interaction of connection reuse and DNS SRV lookups in SIP. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu > se-08.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-connect-reuse-08.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-connect-reuse-08.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=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 23 14:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOIO-0005Er-Gx; Tue, 23 Oct 2007 14:16:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkOIM-0005AE-OS for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 14:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOIM-0005A6-Et for sip@ietf.org; Tue, 23 Oct 2007 14:16:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOIL-0005f7-8P for sip@ietf.org; Tue, 23 Oct 2007 14:16:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2007 11:16:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9NIG0Em007036; Tue, 23 Oct 2007 11:16:00 -0700 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9NIFxm9014583; Tue, 23 Oct 2007 18:15:59 GMT From: "Dan Wing" To: "'Arun Punj'" References: <2D7CEF7F8F759C4AB79D7C46666F329C01CD4423@eusrcmw721.eamcs.ericsson.se> Date: Tue, 23 Oct 2007 11:15:59 -0700 Message-ID: <185301c815a0$c3fdcd00$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <2D7CEF7F8F759C4AB79D7C46666F329C01CD4423@eusrcmw721.eamcs.ericsson.se> Thread-Index: AcgVhsZrNvMQegToQyiVW3jhk1ZnrgAGahHA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2863; t=1193163360; x=1194027360; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20SDES=20RFC4568=20usage=20clarification |Sender:=20; bh=JIWRWbo0jOrUdUBwk3MJYzR/9ktCvK1/RYefl1WJZZI=; b=i7WcJwT9+m+DPQ71UO0F6EmsIIJKY4jklrZVkNDZCImo081cUhM7jmC+j//M+QmpXufgGcbx c5PMTOiRuACvs57+FL8TLO/Z20499d8xlWRglcANdms9/zVx66j09D9h; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: fandreas@cisco.com, sip@ietf.org, sip-implementors@cs.columbia.edu, mbaugher@cisco.com Subject: [Sip] RE: SDES RFC4568 usage clarification 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Arun Punj [mailto:arun.punj@ericsson.com] > Sent: Tuesday, October 23, 2007 8:10 AM > To: sip@ietf.org; sip-implementors@cs.columbia.edu > Cc: dwing@cisco.com; mbaugher@cisco.com; fandreas@cisco.com > Subject: SDES RFC4568 usage clarification > > Folks, > > > > A simple clarification on RFC4568 usage. > > > > User alice@atlanta.com wants to make a call(audio/video) to > bob@biloxi.com. Alice would like media between Alice&Bob to > be encrypted, but would like the call to go through even if > the encryption between Alice&Bob is not possible. draft-ietf-mmusic-sdp-capability-negotiation solves that exact problem, and works with forking (many of your examples below will not work as desired with forking). http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation -d > I am > interested in figuring out how the SDP exchange between Alice > and Bob would proceed, for the two cases: > > 1. Bob supports encryption > > 2. Bob does not support encryption. > > > > Various Options which I can think of are: > > > > 1. Alice sends INVITE to bob with SDP > > m = audio 30000 RTP/SAVP 0 > > a = crypto .... > > m = video 30000 RTP/SAVP 32 > > a = crypto.... > > > > If bob supports encryption no problem. > > > > If bob does not support encryption or specifically if it > does not support RTP/SAVP profile it will be send back an OK > with following SDP > > m=audio 0 RTP/SAVP0 > > a=inactive > > m = video 0 RTP/SAVP > > a=inactive > > > > At this point Alice does not know that bob does not support > SAVP or if there is something else wrong with the crypto > parameters. Is Alice supposed to send another RE-INVITE with > RTP/AVP profile ? > > > > 2. Alice sends an INVITE to bob with SDP > > m=audio 30000 RTP/AVP 0 > > m=video 30002 RTP/AVP 32 > > m =audio 30004 RTP/SAVP 0 > > a = crypto: xxxx > > m=video 30006 RTP/SAVP 32 > > a=crypto: xxxxx > > > > In this case, if bob does not support encryption he could > pick up the right two streams ( maybe). However, if bob > supports encryption and a=crypto attribute how does he know that > > m=audio 30000 RTP/AVP 0 > > and > > m=audio 30004 RTP/SAVP 0 > > really refer to the same media stream. > > > > > > 3. Alice sends an INVITE to bob with SDP > > > > m = audio 30000 RTP/SAVP 0 > > a = crypto .... > > m = video 30000 RTP/SAVP 32 > > a = crypto.... > > > > And bobs UA sends a 4xx media unacceptable message, and alice > tries again without encryption. > > > > > > Your comments will be helpful. > > > > thanks > > Arun > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 23 14:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkObf-0003of-59; Tue, 23 Oct 2007 14:35:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkObe-0003mK-BL for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 14:35:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkObe-0003eG-1D for sip@ietf.org; Tue, 23 Oct 2007 14:35:58 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkObV-0003pB-L2 for sip@ietf.org; Tue, 23 Oct 2007 14:35:49 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20071023183548m1300bqvn2e>; Tue, 23 Oct 2007 18:35:48 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9NIZllW002598 for ; Tue, 23 Oct 2007 14:35:47 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9NIZljY002594; Tue, 23 Oct 2007 14:35:47 -0400 Date: Tue, 23 Oct 2007 14:35:47 -0400 Message-Id: <200710231835.l9NIZljY002594@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200710220052.l9M0qUUO013993@dragon.ariadne.com> (Dale.Worley@comcast.net) Subject: Re: [Sip] Use of the Require header in responses References: <200710220052.l9M0qUUO013993@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: sip-bounces@ietf.org From: Dale.Worley@comcast.net Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. Let me also add that in a 421 (Extension Required) response, the Require field is used for a third purpose, to list the extenstions that the UAC does not list in Supported but that the UAS needs to invoke in order to usefully process the request. (421 should not be confused with 420 (Bad Extension, or Extension Not Implemented), which is used to reject a request with a Require or Proxy-Require header. 420 uses the Unsupported header to list the required extensions that it does not support.) If I recall correctly, there are three extensions or proposed extensions that use Require headers in responses routinely. One is the GRUU extension, but I've forgotten the other two. John Elwell points out that RFC 3262 is another case (for 1xx responses that invoke PRACK). The third was discussed in Chicago. 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 Tue Oct 23 17:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkR6V-0007lS-0i; Tue, 23 Oct 2007 17:15:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkR6T-0007k3-MM for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 17:15:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkR6T-0007jv-Bb for sip@ietf.org; Tue, 23 Oct 2007 17:15:57 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkR6T-0001iA-0Q for sip@ietf.org; Tue, 23 Oct 2007 17:15:57 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9NLFt0H072277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 16:15:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471E648F.8040402@nostrum.com> Date: Tue, 23 Oct 2007 16:15:59 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <643CA05D-9656-4A77-A403-83AF39622CEA@nostrum.com> <4C5F6FBE-1E65-402D-B9B9-321E63D80C69@estacado.ne! ! t> <471CC80F.4000600@nostrum.com> <3F75BB9C-BE75-4897-931A-11EAD6424CB5@softarmor.com> In-Reply-To: <3F75BB9C-BE75-4897-931A-11EAD6424CB5@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4575/Tue Oct 23 14:23:08 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip , Paul Kyzivat , Robert Sparks , Brian Stucker , Michael Procter , "Elwell, John" 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: , Errors-To: sip-bounces@ietf.org On 10/23/07 11:32 AM, Dean Willis wrote: > > On Oct 22, 2007, at 10:55 AM, Adam Roach wrote: > >> Allow me to clarify my position further here. >> >> Robert is right: SUBSCRIBE/NOTIFY is the correct way to address these >> issues. If I had my druthers, we'd be using 3265 straight-up for >> these applications. My prior message was based on the assumption that >> we'd lost the "do this the right way" battle. Taken as a given, the >> options I outlined in my earlier note are an attempt at damage control. >> > > I believe that the empirical evidence of a heck of a lot of > implementations indicates that there are use cases where people would > rather not have a full-blown event dialog in parallel to an INVITE > dialog for very good reasons of capacity and complexity, but still > need event passing. The original use of INFO for midcall telephony > signaling is just one example of this. Right. So, dust off your old INFO package draft and re-issue it. It appears to address the issue you describe while really only being objectionable under some relatively fringe objections (mine included). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 23 17:27:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkRFr-0006FF-4f; Tue, 23 Oct 2007 17:25:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkRFo-0006Ex-JV for sip-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 17:25:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkRFo-0006Eo-8t for sip@ietf.org; Tue, 23 Oct 2007 17:25:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkRFn-0001yL-SL for sip@ietf.org; Tue, 23 Oct 2007 17:25:36 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9NLPY37072807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 16:25:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <471E66D2.7080604@nostrum.com> Date: Tue, 23 Oct 2007 16:25:38 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO References: <1ECE0EB50388174790F9694F77522CCF129C8008@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF129C8917@zrc2hxm0.corp.nortel.com> <4717E5E9.4070306@nostrum.com> <4717EC02.2000303@cisco.com> <4717F4A8.3050504@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D037D136@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CD7B4DC@sea02-mxc01.citel.com> <0D5F89FAC29E2C41B98A6A762007F5D037D159@GBNTHT12009MSX.gb002.siemens.net> <47189963.10709@cisco.com> <4718D354.3030701@cisco.com> <47192F80.4040308@cisco.com> <1ECE0EB50388174790F9694F77522CCF12A5DE4C@zrc2hxm0.corp.nortel.com> <0D4E483A0E6E0A46861409E5D6C2011CD7B6AE@sea02-mxc01.citel.com> <1ECE0EB50388174790F9694F77522CCF12A5DE55@zrc2hxm0.corp.nortel.com> <471CA794.6050606@cisco.com> <32EED15C-7885-4D0B-9058-48EFEF5D1ABA@softarmor.com> In-Reply-To: <32EED15C-7885-4D0B-9058-48EFEF5D1ABA@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4575/Tue Oct 23 14:23:08 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip List , Paul Kyzivat 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: , Errors-To: sip-bounces@ietf.org On 10/23/07 11:24 AM, Dean Willis wrote: > > On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote: > >> >> So, I think the next question is whether there should be a single >> event package definition mechanism for this new approach and for the >> 3265 type of events, or if these should be entirely disjoint. I >> realize existing event package definitions won't be applicable >> without at least some tweaks, and not all event types are suitable >> for both mechanisms. But I do think there are event types that are >> suitable for both mechanisms (e.g. dtmf and dialog) and it would be >> better if we didn't require independent definitions for them in both >> contexts. > > I also favor a single class of event package registrations, and > leaving it to each event package to whether and how it works in each mode. I think this is a bit odd and potentially dangerous. If you look at an event package, it defines two classes of information: a lot of stuff that's pretty specific to 3265 mechanisms, and a syntax for conveying information. I think the syntax (i.e., MIME type) has a good chance of being re-usable between event packages and INFO packages. Everything else won't apply. The danger come in trying to crowbar in various 3265-related extensions and applying them to INFO. Partial notifications? Throttling? Filtering? Etags? You want to figure out how all of those work with INVITE/INFO? You take on making these things event packages straight up, and that's where we'll end up. Define a different set of INFO packages for things that make sense in INFO, and things are much cleaner. I think you'll find the set of existing event packages that make sense to "optimize" using INFO is very small -- with so little overlap, I don't believe you gain anything. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 24 04:05:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikb8E-0006cV-PT; Wed, 24 Oct 2007 03:58:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ikb8D-0006cP-6w for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 03:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikb8C-0006cG-TR for sip@ietf.org; Wed, 24 Oct 2007 03:58:24 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikb86-0002dj-CI for sip@ietf.org; Wed, 24 Oct 2007 03:58:24 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQE00M32OS32F@siemenscomms.co.uk> for sip@ietf.org; Wed, 24 Oct 2007 08:57:40 +0100 (BST) Date: Wed, 24 Oct 2007 08:58:01 +0100 From: "Elwell, John" Subject: RE: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03 In-reply-to: <5D1A7985295922448D5550C94DE29180017E1D88@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith (Keith)" , IETF SIP List , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D4FA@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgPBcv4h6/g5D89QjaqwYyPe0P9cwHARFfA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D1A7985295922448D5550C94DE29180017E1D88@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-hitchhikers-guide-03 Reviewer: John Elwell Review Date: 2007-10-24 Review Deadline: 2007-10-29 Status: WGLC Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. My 42 comments below. Minor comments: 1. "Any specification that defines an extension to SIP itself, where" Change to: "The basic SIP specification, RFC 3261 [ref], and any specification that defines an extension to SIP itself, where" 2. "Any specification that defines an extension to SDP" Change to "The basic SDP specification, RFC 4566 [ref], and any specification that defines an extension to SDP" 3. RFC 3840 has been classified as a core spec. I am not sure that it meets the criterion of applying to most calls. Some implementations only do isfocus, which hardly arises on every call. You may wish to reconsider this classification. 4. Concerning RFC 4474: "It has seen little deployment so far, but its importance as a key construct for anti-spam techniques makes it a core part of the SIP specifications." It would be worth mentioning its use for future security mechanisms (e.g., DTLS-SRTP) too: "It has seen little deployment so far, but its importance as a key construct for anti-spam techniques and new security mechanisms makes it a core part of the SIP specifications." 5. Concerning ICE: "A SIP option tag and media feature tag RFC XXXX [108] have been defined for use with ICE." It is not clear whether [108] is also a core specification. 6. "RFC 4916 [81] defines an extension to SIP that allows a UAC to determine the identity of the UAS. Due to forwarding and retargeting services, this may not be the same as the user that the UAC was originally trying to reach. The mechanism works in tandem with the SIP identity specification [19] to provide signatures over the connected party identity." It is confusing to talk about UAC and UAS here, because even with RFC 4916 it is always the UAC (for that transaction) whose identity is given. It might also be worth mentioning mid-call usage. Change to: "RFC 4916 [81] defines an extension to SIP that allows a calling UA to determine the identity of the final called user (connected user). Due to forwarding and retargeting services, this may not be the same as the user that the caller was originally trying to reach. The mechanism works in tandem with the SIP identity specification [19] to provide a signature over the connected party identity. It can also be used if a party identity changes mid call due to third party call control actions or PSTN behavior." 7. "RFC 3960 [27] defines some guidelines for handling early media - the practice of sending media from the called party towards the caller - prior to acceptance of the call. Early media is generated only from the PSTN." This is not true - application servers can generate early media. Suggest deleting the last sentence and changing the previous sentence as follows: "RFC 3960 [27] defines some guidelines for handling early media - the practice of sending media from the called party or an application server towards the caller - prior to acceptance of the call." 8. "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204 [84] defines MIME objects for representing SS7 signaling messages. These are carried in the body of SIP messages when SIP-T is used." Change to: "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204 [84] defines MIME objects for representing SS7 and QSIG signaling messages. SS7 signaling messages are carried in the body of SIP messages when SIP-T is used. QSIG signaling messages can be carried in a similar way." 9. In the PSTN section you may wish to consider adding "RFC 4497, Interworking between SIP and QSIG (B): RFC 4497 [ref] defines how to do protocol mapping from QSIG signaling to SIP." 10. Concerning RFC 3323: "Though it defines numerous privacy services, the only one broadly used is the one that supports privacy of the P-Asserted-ID header field [15]." Suggest changing "numerous" to "several". 11. Concerning RFC 3311: "This method is meant as a means for updating session information prior to the completion of the initial INVITE transaction. It was developed primarily to support RFC 3312 [59]." It is not limited to use before completion of INVITE, and one use is for session timer refresh, another is with connected-ID. Change to: "This method is meant as a means for updating session information prior to the completion of the initial INVITE transaction. It can also be used for updating call information mid-call. It was developed primarily to support RFC 3312 [59], but has found other uses, including use with RFC 4028 [ref] for session timer refresh and with RFC 4916 [ref] for connected identity." 12. Because RFC 4916, a core specification, mandates use of UPDATE, RFC 3311 should be considered a core specification. 13. Concerning RFC 4028: "Session timers introduces a fair bit of complexity for relatively little gain, and has thus seen little deployment." I am a little surprised by this statement, but if it is based on feedback from SIPit then I guess it is OK. 14. Section "Minor Extensions". Several of these are extensions to mechanisms listed later in the document, e.g., REFER, pre-conditions. Should the section be moved further back, e.g., to the end? 15. Concerning RFC 4508: "It is useful for informing the target of the REFER about the characteristics of the REFER target." Terminology is rather confusing: "target of the REFER" and "REFER target" are supposed to mean different things. Change to: "It is useful for informing the target of the REFER request about the characteristics of the intended target of the referred request." 16. "RFC 3265 defines a basic framework for event notification in SIP. It introduces the notion of an event package, which is a collection of related state and event information. Much of the state and events in SIP systems have event packages, allowing other entities to learn about changes in that state." Although several RFCs are repeated in different sections (intentionally), in this particular case the text is completely different from that in the core specs section. Suggest alignment one way or the other. 17. "RFC XXXX [96] defines a SIP event package that allows a proxy to notify a user agent about its desire for the UA to use certain codecs or generally obey certain media session policies." Change "proxy" to "policy server". 18. RFC 4458 is missing - any reason? 19. There is mention of several SDP extensions, yet in the section "Security Mechanisms", there is no mention of RFCs 4567 and 4568. 20. "17. Emergency Services Emergency services here covers both emergency calling (for example, 911 in the United States), and pre-emption services, which allow authorized individuals to gain access to network resources in time of emergency." In fact the only two RFCs listed relate to pre-emption, not emergency calling. Editorial nits: 21. "and implementations interested in a particular topic often implement" Change to: "and implementers ^^^ interested in a particular topic often implement" 22. "The SIP change process [8] defines two types of extensions to SIP. These are normal extensions and the so-called P-headers (where P stands for "preliminary", "private", or "proprietary", and the "P-" prefix is included in the header field name) are meant to be used in areas of limited applicability." Change to: "The SIP change process [8] defines two types of extensions to SIP. These are normal extensions and the so-called P-headers (where P stands for "preliminary", "private", or "proprietary", and the "P-" prefix is included in the header field name), which are meant to be used in ^^^^^^^ areas of limited applicability." 23. "RFC 3325 [15], which defines the P-Asserted-ID header field has been widely deployed." Add comma as follows: "RFC 3325 [15], which defines the P-Asserted-ID header field, has been widely deployed." 24. "RFC 4320 [18] formally updates RFC 3261, and modifies some of the behaviors associated with non-INVITE transactions. These address some problems found in timeout and failure cases." It is not clear what "these" refers to. Suggest change to: "RFC 4320 [18] formally updates RFC 3261, and modifies some of the behaviors associated with non-INVITE transactions. Modifications address some problems found in timeout and ^^^^^^^^^^^^^^ failure cases." 25. "RFC 4168 [36] defines how to carry SIP messages over the Stream Control Transmission Protocol (SCTP)." Add reference to SCTP itself. 26. "Its primary application was in support of voicemail services." What is the reason for the past tense? Can we just change "was" to "is"? 27. "defines a mechanism for learning about changes in conference state, including group membership." Change "group membership" to "conference membership". This occurs twice. 28. "when there are a multiplicity of security mechanisms" Change "are" to "is". 29-42 - padding John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: 15 October 2007 09:32 > To: IETF SIP List > Subject: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03 > > (As WG chair) > > This is to announce a working group last call of > > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers -guide-03. > txt > > I would request comments on this document be made (to list > and to author > mentioned in the document) by Monday October 29th 2007. > > Please clearly identify the text of the document that is > being commented > on, the nature of the comment (NIT, minor technical, major technical, > etc), and any suggested resolution, even if it is only some > alternatives. > > Regards > > Keith > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 24 11:27:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki4J-0003NO-OE; Wed, 24 Oct 2007 11:22:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iki4I-0003Jv-3F for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:22:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iki4H-0003JT-OE for sip@ietf.org; Wed, 24 Oct 2007 11:22:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iki4H-0008HI-9p for sip@ietf.org; Wed, 24 Oct 2007 11:22:49 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9OFMjT04525; Wed, 24 Oct 2007 15:22:46 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2007 10:19:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgWUVCB+7CtxRL6QxGlta8NeDGYow== From: "Mary Barnes" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" Subject: [Sip] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-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: , Errors-To: sip-bounces@ietf.org Following Keith's recommendation for us to at least review the entries for the RFCs that we authored, I have some feedback on the entry for RFC 4244 (History-Info) and a few other comments. =20 RFC 4244 comments (Section 5): ------------------------------=20 The statement about the primary application being voicemail is a mis-characterization and is based on the fact that we had so, so many long, long discussions on the use of History-Info for voicemail. RFC 4244 is written to provide a very general mechanism and is applicable to a variety of applications. My concern is that mis-characterization may result in folks trying to define something new when the capability already exists with History-Info (e.g., 3GPP p-served-user p-header). So, I suggest something like the following change: OLD: RFC 4244, An Extension to SIP for Request History Information (S): RFC 4244 [37] defines the History-Info header field, which indicates information on how a call came to be routed to a particular destination. Its primary application was in support of voicemail services. NEW: RFC 4244, An Extension to SIP for Request History Information (S): RFC 4244 [37] defines the History-Info header field, which indicates information on how and why a call came to be routed to a particular destination. One application was in support of voicemail services, with details of such provided in RFC 4458. Other example applications include Automatic Call Distribution and Call Transfer scenarios.=20 And, this of course, adds a reference to RFC 4458. I don't have a strong opinion as to whether detail on that RFC shouldn't be included elsewhere in this document. =20 Other comments: ---------------- It seems that all the call flow BCPs are missing and I do think those are really important and should be included in this document. The only BCP (type (B) document) listed in this document is 3PCC. The basic call flow document (RFC 3665) should be listed in section 3 (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking section 4. The SIPPING NAT scenarios document should be in the NAT section 6. These docs are all icing on the cake IMHO and help to guide implementers in using all the other docs. I realize it's difficult to figure out where to draw the line, but wouldn't a reference to the service-examples call flows also be useful? Also, wouldn't a section on IPv6 be useful? This would include draft-ietf-sipping-v6-transition-07 (which is standards track and updates RFC 3264 and is currently in the RFC Editor's Queue).=20 Regards, Mary.=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 Wed Oct 24 15:24:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikll1-00016M-Mg; Wed, 24 Oct 2007 15:19:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ikll0-00016H-LA for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:19:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikll0-000164-8I for sip@ietf.org; Wed, 24 Oct 2007 15:19:10 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iklkz-00074X-NZ for sip@ietf.org; Wed, 24 Oct 2007 15:19:10 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9OJJ7rH007584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 24 Oct 2007 14:19:09 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List From: Dean Willis Date: Wed, 24 Oct 2007 14:18:41 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Sip] INFO: A recap, sense of consensus and a proposal for direction. 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: , Errors-To: sip-bounces@ietf.org Wow, this has been a heartily discussed topic. I'd like to recap some points I think we have a mostly-working consensus on: 1) INFO is underspecified and lacks a satisfactory negotiation mechanism for usages thereof. 2) We need more than just content-type and content-disposition to describe and negotiate usages of INFO. The event package nomenclature seems to satisfy this need. 3) SIP Events (RFC 3265) could functionally replace all uses of INFO, but there are reasons (primarily relating to overhead and complexity) for the fact that we continue to see deployments using INFO. 4) The situation relating to INFO and the angst and confusion stemming from it are sufficiently motivating for us to at least heartily debate the topic, and presumably motivating enough for us to actually tackle a solution at the working group level. 5) We do NOT believe that just deprecating INFO will make the problem go away. 6) We believe that something that allows events to be negotiated as part of an INVITE-initiated dialog usage would satisfy the majority of the requirements. Some less-consensed items include: 7) Use of NOTIFY, INFO, or some other method for the invite-dialog event method. We have a majority position that is best described as "anything but NOTIFY", and the remainder is roughly split on INFO vs something else. 8) Do we use the same registry and review process for invite-dialog events as for subscribe-dialog events? This seems to be in part predicated on whether any events will occur in both types of dialogs. The emerging consensus seems to be that at least some events could be used in either dialog type, and that therefore a single registry and process is needed. However, we probably need to add a column to the registry for the dialog-type. 9) While we agree that we need to negotiate directionality of event flow (being able to send an event is not the same as being able to receive it), we're up in the air on mechanism. We have proposals for either replacing Allow-Events (in INVITE request) with two new header fields such as "Send-Events" and "Receive-Events", or of extending each event-package name with a sub-parameter indicating directionality similar to those used in SDP (send, recv, sendrecv or the like). While functionally equivalent, the first fits into our existing IANA registries more readily and is therefore easier to document. These leads to a concrete proposal: I propose we develop a new RFC that extends RFC 3265 and obsoletes RFC 2976. This RFC will document use of event bodies in INFO messages exchanged in dialog usages established by SIP INVITE transactions. This will include definition of the "Send-Events" and "Recv-Events" header fields, use of those header fields in INVITE transactions to provide an offer/answer exchange, definition and use of a new option tag for this extension, and the needed changes to the registry established by RFC 3265. There may then be a need for a subsequent RFC or RFCs to extend RFC 3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new model of INFO. So, how does this sound to people? -- 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 24 15:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikm56-00071r-No; Wed, 24 Oct 2007 15:39:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ikm54-0006qL-MA for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikm54-0006qD-Cf for sip@ietf.org; Wed, 24 Oct 2007 15:39:54 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikm4y-0003Fk-5X for sip@ietf.org; Wed, 24 Oct 2007 15:39:54 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9OJdXWT007745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Oct 2007 14:39:35 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00BF3B24-91A1-4349-B728-FB06AF7D1F14@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 24 Oct 2007 14:39:07 -0500 To: sip List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Andrew Allen , Chris Newman , Gonzalo Camarillo Subject: [Sip] IANA registries and question raised in IESG review of answermode 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: , Errors-To: sip-bounces@ietf.org A question about IANA registry came up during review of draft-ietf- sip-answermode. The draft currently defines two new header fields, "Answer-Mode" and "Priv-Answer-Mode". Each header field can take the values "Auto" or "Manual". Either value can be further modified by adding a ";require". For example: Answer-Mode: Manual;require We have an IANA registry of header fields, as well as one of parameters to header fields. This is at: http://www.iana.org/assignments/sip-parameters and the specific registry of interest is: Registry Name: Header Field Parameters and Parameter Values Reference: [RFC3968] Registration Procedures: Published RFC (A standards-track RFC is NOT required) which has columns like: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- Accept q No [RFC3261] So far , so good. The draft-ietf-sip-anwermode text currently adds four rows: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- ------- Answer-Mode Auto No [This doc] Answer-Mode Manual No [This doc] Priv-Answer-Mode Auto No [This doc] Priv-Answer-Mode Manual No [This doc] Let's go back and consider the example: Answer-Mode: Manual;require The "require" is not a full parameter of Answer-Mode. That is, it makes no sense to say: Answer-Mode: require So, where do we IANA register the "require"? O We could do something like: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- ------- Answer-Mode Auto No [This doc] Answer-Mode Manual No [This doc] Answer-Mode Auto;require No [This doc] Answer-Mode Manual;require No [This doc] Priv-Answer-Mode Auto No [This doc] Priv-Answer-Mode Manual No [This doc] Priv-Answer-Mode Auto;require No [This doc] Priv-Answer-Mode Manual;require No [This doc] We could also ignore the registration problem for "require" (which is what I did in the draft), add a new registry, or restructure the existing registry. Or it could be that the syntax used in Answer-Mode is just broken and requires revision. One suggestion I've received was to restructure to something like the following: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- ------- Answer-Mode Auto No [This doc] Answer-Mode Manual No [This doc] Answer-Mode Privauto No [This doc] Answer-Mode Privmanual No [This doc] Anybody have a great idea here? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 24 18:23:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoZC-0007pk-LH; Wed, 24 Oct 2007 18:19:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkoZA-0007lT-Rq for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 18:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoZA-0007jp-HA for sip@ietf.org; Wed, 24 Oct 2007 18:19:08 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkoZ4-0007vX-5H for sip@ietf.org; Wed, 24 Oct 2007 18:19:08 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9OMImjA016965; Wed, 24 Oct 2007 15:18:48 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id l9OMIkOA011142; Wed, 24 Oct 2007 15:18:47 -0700 Received: from 10.60.24.182 ([10.60.24.182]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 24 Oct 2007 22:18:46 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 24 Oct 2007 15:18:39 -0700 Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) Thread-Index: AcgVd01fFZ4YCTypRCmuJR0ljG+HmABFIZwl In-Reply-To: <471DF4B8.6090202@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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: , Errors-To: sip-bounces@ietf.org You are absolutely correct: one calculates complexity per-module. Decomposition is accounted for by adding 1 to the module complexity (to account for calls). The "things get dramatically worse when complexity exceeds 7" statement was with reference to any given module, *not* the entire stack. If that was the case, we never would have made it down the elevator, no less to the moon. On 10/23/07 6:18 AM, "Paul Kyzivat" wrote: > > > > Eric Burger wrote: >> Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count* >> of 2 or 4. >> >> However, the result is similar: there is tons of Software Engineering data >> that shows when modules get above a cyclomatic comlexity of 7, the number of >> latent defects raises non-linearly. > > I'm not really a student of that stuff, but I believe that is for one > function or other closed unit of code. > > When you take a system, if you add the complexity of each piece then of > course you get a huge number. In theory you don't have to do that > because the system is hierarchically decomposed into pieces each with > acceptable complexity, and in *theory* you can understand them one at a > time. > > However I have yet to see a reasonable sized system where the overall > structure of all the pieces didn't introduce another kind of practical > complexity that AFAIK isn't normally measured. > >> Henning (or some lurker looking for something to do): an interesting >> Master's Thesis would be to calculate the theoretical minimum cyclomatic >> complexity of the current SIP state machine. > > For one thing, SIP can't really be evaluated with a state machine > because it has stacks. (Via and Route headers, etc.) But that doesn't > really change the discussion. > > I'm not sure its a meaningful question. But it seems like if it could be > answered, the answer would have to be in the thousands, or more, when > viewed as a whole. (Which is why adding two or four is irrelevant.) > > To get a more meaningful number you would have to decompose it into a > hierarchy of state machines (or functions, objects and methods, ...) and > then find the worst case complexity of all those. > >> That may answer the, "Why SIP >> does not interoperate" question. > > I certainly agree that SIP is very complex, contrary to the claims that > were made for it early in its life. I don't have enough context to > compare it complexity to that of earlier systems for the same job - it > is my impression that they are worse. > > The complexity is why we have been writing guides and clarification > documents, etc. (They don't *fix* the complexity, but they may help > people to master it.) > > I do appreciate the point that the complexity arises one decision at a > time, and we should always be trying to make things as simple as we can, > given what we have to do. > > It always comes down to: is the benefit of this new feature worth the > complexity that it brings. Not everybody comes to the same answer about > such a question. > > Paul > >> On 10/22/07 3:30 PM, "Paul Kyzivat" wrote: >> >>> Eric, >>> >>> I disagree with your *quantitative* assessments of how much thee things >>> increase complexity (by factors of 2 or 4). But I certainly agree that >>> complexity *will* increase. >>> >>> In the end everything we are doing increases complexity, so maybe we >>> should all pack up shop and go home. >>> >>> Ultimately this all comes down to deciding how complex things have to >>> get before people can do what they think they need to do. >>> >>> Paul >>> >>> Eric Burger wrote: >>>> >>>> On 10/17/07 2:18 PM, "Paul Kyzivat" wrote: >>>> [snip] >>>>> One agreed upon, NOTIFY may be sent in the agreed upon direction(s) >>>>> within the INVITE dialog usage. Whether an initial NOTIFY is required >>>>> will be determined on a per-event-package basis. (Its not needed to >>>>> establish the dialog, so its a matter if it is semantically needed in >>>>> the context of the event type.) >>>> Which is not the way NOTIFY works today, which means the sender has to have >>>> code to the effect: >>>> >>>> if( !real_notify(event_object) ) >>>> { >>>> if( needs_first_notify(event_object) ) >>>> { >>>> send_event(event_object); >>>> } >>>> } >>>> else >>>> send_event(event_object); >>>> >>>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the >>>> complexity of your notification stack by 2. >>>> >>>> [snip] >>>> >>>>> There is no separate subscription or timer. The dialog usage is >>>>> refreshed by INVITE or UPDATE in the conventional manner. Events to be >>>>> exchanged are renegotiated from scratch with every reINVITE or UPDATE. >>>> So what does the NOTIFY put into expires? I hear hk now: "Just stuff it >>>> with 99999." OK, this now adds another hack into send_event(), "If I am a >>>> real SUBSCRIPTION, return the timer; if I am not, return 99999." Just >>>> upped >>>> the complexity by 1. >>>> >>>> Worse yet, what does the recipient do when it gets a BYE? Now it has >>>> either >>>> a resource leak or more code: >>>> >>>> if( got_bye(dialog_object) ) >>>> { >>>> for each pseudo-dialog subscription in the (dialog_object) >>>> { >>>> consider the subscription terminated; >>>> } >>>> } >>>> >>>> Upping the complexity by 2, again. >>>> >>>> Hey - we are not done yet! I will leave as an exercise to the reader the >>>> amount of complexity added to create the implicit subscription in the first >>>> place. >>>> >>>> I forgot, this really is targeted for devices that will hard code >>>> everything >>>> and not support any real SUBSCRIBE/NOTIFY packages. [facetious] >>>> >>>> It would be much cleaner to call this thing "NOTQUITENOTIFY". >>>> >>>> Of course, since we are anal about messages and bandwidth, let's save 300ns >>>> and just call the method "I". [joking] >>>> >>>> [snip] >>>> >>>> >>>> Notice: This email message, together with any attachments, may contain >>>> information of BEA Systems, Inc., its subsidiaries and affiliated >>>> entities, that may be confidential, proprietary, copyrighted and/or >>>> legally privileged, and is intended solely for the use of the individual or >>>> entity named in this message. If you are not the intended recipient, and >>>> have >>>> received this message in error, please immediately return this by email and >>>> then delete it. >>>> >> >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 24 19:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpkS-00039r-De; Wed, 24 Oct 2007 19:34:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkpkQ-00035w-BK for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 19:34:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpkP-00035l-Vw for sip@ietf.org; Wed, 24 Oct 2007 19:34:50 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkpkP-00052D-Hv for sip@ietf.org; Wed, 24 Oct 2007 19:34:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9ONYjT01569; Wed, 24 Oct 2007 23:34:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Date: Wed, 24 Oct 2007 18:34:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12BCA8CD@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgWUVCB+7CtxRL6QxGlta8NeDGYowAQ8mNg References: From: "Francois Audet" To: "Mary Barnes" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" 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: , Errors-To: sip-bounces@ietf.org Mary has a good point, but I think an even simpler solution is the following: NEW: RFC 4244, An Extension to SIP for Request History Information (S): RFC 4244 [37] defines the History-Info header field, which indicates information on how and why a call came to be routed to a particular destination. =20 As for RFC 4458, I think it belongs int the "SIP Service URIs" section and maybe the PSTN interop one (it's really a form of RFC 3087 service URI for PSTN interop). > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Wednesday, October 24, 2007 08:20 > To: Jonathan Rosenberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: [Sip] Some Comments: WGLC of=20 > draft-ietf-sip-hitchhikers-guide-03 >=20 >=20 > Following Keith's recommendation for us to at least review=20 > the entries for the RFCs that we authored, I have some=20 > feedback on the entry for RFC > 4244 (History-Info) and a few other comments. =20 >=20 > RFC 4244 comments (Section 5): > ------------------------------ > The statement about the primary application being voicemail=20 > is a mis-characterization and is based on the fact that we=20 > had so, so many long, long discussions on the use of=20 > History-Info for voicemail. RFC > 4244 is written to provide a very general mechanism and is=20 > applicable to a variety of applications. My concern is that=20 > mis-characterization may result in folks trying to define=20 > something new when the capability already exists with=20 > History-Info (e.g., 3GPP p-served-user p-header). > So, I suggest something like the following change: >=20 > OLD: > RFC 4244, An Extension to SIP for Request History Information (S): > RFC 4244 [37] defines the History-Info header field, which > indicates information on how a call came to be routed to a > particular destination. Its primary application was in=20 > support of > voicemail services. >=20 > NEW: > RFC 4244, An Extension to SIP for Request History Information (S): > RFC 4244 [37] defines the History-Info header field, which > indicates information on how and why a call came to be=20 > routed to a > particular destination. One application was in support of > voicemail services, with details of such provided in RFC 4458. > Other example applications include Automatic Call Distribution > and Call Transfer scenarios.=20 >=20 > And, this of course, adds a reference to RFC 4458. I don't=20 > have a strong opinion as to whether detail on that RFC=20 > shouldn't be included elsewhere > in this document. =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 Wed Oct 24 23:45:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IktWz-0001OS-0v; Wed, 24 Oct 2007 23:37:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IktWx-0001ON-Ca for sip-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 23:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IktWw-0001OE-Nn for sip@ietf.org; Wed, 24 Oct 2007 23:37:10 -0400 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 1IktWq-00065s-Eq for sip@ietf.org; Wed, 24 Oct 2007 23:37:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2007 20:36:58 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9P3awMk006737; Wed, 24 Oct 2007 23:36:58 -0400 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 l9P3avPc009143; Thu, 25 Oct 2007 03:36:58 GMT 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.1830); Wed, 24 Oct 2007 23:36:57 -0400 Received: from [10.86.242.52] ([10.86.242.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 23:36:57 -0400 Message-ID: <47200F59.2000205@cisco.com> Date: Wed, 24 Oct 2007 23:36:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> In-Reply-To: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 03:36:57.0252 (UTC) FILETIME=[4B42C640:01C816B8] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002 X-TM-AS-Result: No--25.242800-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4000; t=1193283418; x=1194147418; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20 |To:=20Dean=20Willis=20; bh=2LbQfLcZecc89lf8Q5TDb3/PsGRIevhWaXCHwDrFA+0=; b=SEcbkLj77KjS/bq0A74cTowRjq1G08O8m6EEimFbTDnFlF08R6yauyZrSDwj/Gfls1AZ9TIx /USC8OONB6Fzt3h5DppZ6Z52O2RsA489ZYzNJtkC69/cLu+VYTEOe3D7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: sip-bounces@ietf.org Dean, Nice summary. I generally agree with what you have written. My major concern is with the negotiation mechanism. In particular I think it needs to be done as a two-way handshake, not three way. A three way negotiation will not work well with 3pcc. Thanks, Paul Dean Willis wrote: > > Wow, this has been a heartily discussed topic. > > I'd like to recap some points I think we have a mostly-working consensus > on: > > 1) INFO is underspecified and lacks a satisfactory negotiation mechanism > for usages thereof. > > 2) We need more than just content-type and content-disposition to > describe and negotiate usages of INFO. The event package nomenclature > seems to satisfy this need. > > 3) SIP Events (RFC 3265) could functionally replace all uses of INFO, > but there are reasons (primarily relating to overhead and complexity) > for the fact that we continue to see deployments using INFO. > > 4) The situation relating to INFO and the angst and confusion stemming > from it are sufficiently motivating for us to at least heartily debate > the topic, and presumably motivating enough for us to actually tackle a > solution at the working group level. > > 5) We do NOT believe that just deprecating INFO will make the problem go > away. > > 6) We believe that something that allows events to be negotiated as part > of an INVITE-initiated dialog usage would satisfy the majority of the > requirements. > > > Some less-consensed items include: > > 7) Use of NOTIFY, INFO, or some other method for the invite-dialog event > method. We have a majority position that is best described as "anything > but NOTIFY", and the remainder is roughly split on INFO vs something else. > > 8) Do we use the same registry and review process for invite-dialog > events as for subscribe-dialog events? This seems to be in part > predicated on whether any events will occur in both types of dialogs. > The emerging consensus seems to be that at least some events could be > used in either dialog type, and that therefore a single registry and > process is needed. However, we probably need to add a column to the > registry for the dialog-type. > > 9) While we agree that we need to negotiate directionality of event flow > (being able to send an event is not the same as being able to receive > it), we're up in the air on mechanism. We have proposals for either > replacing Allow-Events (in INVITE request) with two new header fields > such as "Send-Events" and "Receive-Events", or of extending each > event-package name with a sub-parameter indicating directionality > similar to those used in SDP (send, recv, sendrecv or the like). While > functionally equivalent, the first fits into our existing IANA > registries more readily and is therefore easier to document. > > These leads to a concrete proposal: > > I propose we develop a new RFC that extends RFC 3265 and obsoletes RFC > 2976. > > This RFC will document use of event bodies in INFO messages exchanged in > dialog usages established by SIP INVITE transactions. This will include > definition of the "Send-Events" and "Recv-Events" header fields, use of > those header fields in INVITE transactions to provide an offer/answer > exchange, definition and use of a new option tag for this extension, and > the needed changes to the registry established by RFC 3265. > > There may then be a need for a subsequent RFC or RFCs to extend RFC 3398 > (ISUP) and RFC 4498 (QSIG) for consistency with the new model of INFO. > > So, how does this sound to people? > > -- > 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 25 06:18:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikzfp-0004P9-3s; Thu, 25 Oct 2007 06:10:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ikzfn-0004OS-OV for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 06:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikzfn-0004OK-E8 for sip@ietf.org; Thu, 25 Oct 2007 06:10:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikzfh-0006lD-74 for sip@ietf.org; Thu, 25 Oct 2007 06:10:43 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JQG001CNPJPJG@siemenscomms.co.uk> for sip@ietf.org; Thu, 25 Oct 2007 11:09:25 +0100 (BST) Date: Thu, 25 Oct 2007 11:09:46 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. In-reply-to: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> To: Dean Willis , sip List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D037D661@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgWdCuhBO0p098/SDqhNIZ6BRhWgwAeiHpw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: sip-bounces@ietf.org Dean, A good summary and proposal. I am not yet 100% convinced we need to do anything, but if we do the proposal sounds good. Just to correct one point. > There may then be a need for a subsequent RFC or RFCs to extend RFC > 3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new > model of > INFO. > I think you intended to type RFC 4497 for QSIG. However, that RFC only deals with interworking between QSIG and SIP. Tunnelling of QSIG over SIP is specified in ECMA-355 from Ecma-International. For both SIP-T and QSIG tunnelling we would need to maintain backwards compatibility with the existing standards. 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 Thu Oct 25 06:18:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikzjn-0008GH-IN; Thu, 25 Oct 2007 06:14:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IkyJw-0000Sm-Nd for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 04:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkyJw-0000Se-BR for sip@ietf.org; Thu, 25 Oct 2007 04:44:04 -0400 Received: from [220.227.165.113] (helo=communicator.systique.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkyJp-0003cg-TU for sip@ietf.org; Thu, 25 Oct 2007 04:44:04 -0400 X-IronPort-AV: E=Sophos;i="4.21,328,1188757800"; d="scan'208";a="1740705" Received: from unknown (HELO mailserver.hsc.com) ([192.168.0.39]) by communicator.systique.in with ESMTP; 25 Oct 2007 14:12:20 +0530 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Sachin Srivastava Message-ID: Date: Thu, 25 Oct 2007 13:55:43 +0530 X-MIMETrack: Serialize by Router on GGNMAIL01/SRV/HSC(Release 7.0|August 18, 2005) at 10/25/2007 01:55:44 PM, Serialize complete at 10/25/2007 01:55:44 PM Bcc: sip@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Thu, 25 Oct 2007 06:14:50 -0400 Subject: [Sip] Call split and join 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="===============0656094605==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0656094605== Content-Type: multipart/alternative; boundary="=_alternative 002F71606525737F_=" This is a multipart message in MIME format. --=_alternative 002F71606525737F_= Content-Type: text/plain; charset="US-ASCII" Hi, Can any one tell me something about Call split and join featrure. is there any document mentioning this feature. Regards, Sachin --=_alternative 002F71606525737F_= Content-Type: text/html; charset="US-ASCII"
Hi,
        Can any one tell me something about Call split and join featrure. is there any document mentioning this feature.

Regards,
Sachin --=_alternative 002F71606525737F_=-- --===============0656094605== 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 --===============0656094605==-- From sip-bounces@ietf.org Thu Oct 25 11:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4Hn-00050W-1u; Thu, 25 Oct 2007 11:06:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Il4Hh-0004vF-3e for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:06:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4Hg-0004v7-ON for sip@ietf.org; Thu, 25 Oct 2007 11:06:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il4Hg-0001Z8-8Q for sip@ietf.org; Thu, 25 Oct 2007 11:06:08 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9PF64t08174; Thu, 25 Oct 2007 15:06:04 GMT x-mimeole: Produced By Microsoft Exchange V6.5 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] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Date: Thu, 25 Oct 2007 10:03:05 -0500 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12BCA8CD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgWUVCB+7CtxRL6QxGlta8NeDGYowAQ8mNgACC9iwA= References: <1ECE0EB50388174790F9694F77522CCF12BCA8CD@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" 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: , Errors-To: sip-bounces@ietf.org I like the suggested rewording for RFC 4244 and agree that RFC 4458 would fit well in the Service URI section. Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Wednesday, October 24, 2007 6:35 PM To: Barnes, Mary (RICH2:AR00); Jonathan Rosenberg Cc: sip@ietf.org; DRAGE, Keith (Keith) Subject: RE: [Sip] Some Comments: WGLC of draft-ietf-sip-hitchhikers-guide-03 Mary has a good point, but I think an even simpler solution is the following: NEW: RFC 4244, An Extension to SIP for Request History Information (S): RFC 4244 [37] defines the History-Info header field, which indicates information on how and why a call came to be routed to a particular destination. =20 As for RFC 4458, I think it belongs int the "SIP Service URIs" section and maybe the PSTN interop one (it's really a form of RFC 3087 service URI for PSTN interop). > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Wednesday, October 24, 2007 08:20 > To: Jonathan Rosenberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: [Sip] Some Comments: WGLC of > draft-ietf-sip-hitchhikers-guide-03 >=20 >=20 > Following Keith's recommendation for us to at least review the entries > for the RFCs that we authored, I have some feedback on the entry for=20 > RFC > 4244 (History-Info) and a few other comments. =20 >=20 > RFC 4244 comments (Section 5): > ------------------------------ > The statement about the primary application being voicemail is a=20 > mis-characterization and is based on the fact that we had so, so many=20 > long, long discussions on the use of History-Info for voicemail. RFC > 4244 is written to provide a very general mechanism and is applicable=20 > to a variety of applications. My concern is that mis-characterization=20 > may result in folks trying to define something new when the capability > already exists with History-Info (e.g., 3GPP p-served-user p-header). > So, I suggest something like the following change: >=20 > OLD: > RFC 4244, An Extension to SIP for Request History Information (S): > RFC 4244 [37] defines the History-Info header field, which > indicates information on how a call came to be routed to a > particular destination. Its primary application was in support=20 > of > voicemail services. >=20 > NEW: > RFC 4244, An Extension to SIP for Request History Information (S): > RFC 4244 [37] defines the History-Info header field, which > indicates information on how and why a call came to be routed to > a > particular destination. One application was in support of > voicemail services, with details of such provided in RFC 4458. > Other example applications include Automatic Call Distribution > and Call Transfer scenarios.=20 >=20 > And, this of course, adds a reference to RFC 4458. I don't have a=20 > strong opinion as to whether detail on that RFC shouldn't be included=20 > elsewhere > in this document. =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 25 16:13:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8yU-0006IN-SC; Thu, 25 Oct 2007 16:06:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Il8yT-0006Fq-Dn for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 16:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8yT-0006Fi-4I for sip@ietf.org; Thu, 25 Oct 2007 16:06:37 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il8yR-0003LQ-QX for sip@ietf.org; Thu, 25 Oct 2007 16:06:37 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PK6HNh035941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 15:06:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4720F739.30406@nostrum.com> Date: Thu, 25 Oct 2007 15:06:17 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> In-Reply-To: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: sip-bounces@ietf.org On 10/24/07 2:18 PM, Dean Willis wrote: > I propose we develop a new RFC that extends RFC 3265 and obsoletes RFC > 2976. > > This RFC will document use of event bodies in INFO messages exchanged > in dialog usages established by SIP INVITE transactions. This will > include definition of the "Send-Events" and "Recv-Events" header > fields, use of those header fields in INVITE transactions to provide > an offer/answer exchange, definition and use of a new option tag for > this extension, and the needed changes to the registry established by > RFC 3265. I can support such a plan. I will continue to argue that the event packages and info packages should be independent of each other, but that's a minor detail. I generally agree with the larger picture. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Ye-0003UW-Fy; Thu, 25 Oct 2007 16:44:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Il9Yc-0003IQ-7k for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 16:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9Yb-0003IH-Tc for sip@ietf.org; Thu, 25 Oct 2007 16:43:57 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il9Ya-0004k3-G0 for sip@ietf.org; Thu, 25 Oct 2007 16:43:57 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PKhoTd037794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 15:43:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4720F739.30406@nostrum.com> References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 15:43:07 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org I'm pretty (actually extremely) unhappy with the idea, but I'll try not to throw myself on the tracks in front of it. Taking a tumble down the slope: These info packages need to be separate from event packages - there may be some where you just derive an info package from an event package with a trival rfc, but it will _not_ be the case that it will make sense to throw any old event package's payload into an INFO like thing like this (think of the mess you'll get into with anything with a partial payload, and the bigger mess when you get into the infrastructure of the framework, including winfo and eventlists). And we'd need to specify quite concretely what happens when one of these INFOs gets rejected. In most cases, the call is going to have to go away, and I bet that's going to make a lot of people unhappy. RjS On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: > On 10/24/07 2:18 PM, Dean Willis wrote: >> I propose we develop a new RFC that extends RFC 3265 and obsoletes >> RFC 2976. >> >> This RFC will document use of event bodies in INFO messages >> exchanged in dialog usages established by SIP INVITE transactions. >> This will include definition of the "Send-Events" and "Recv- >> Events" header fields, use of those header fields in INVITE >> transactions to provide an offer/answer exchange, definition and >> use of a new option tag for this extension, and the needed changes >> to the registry established by RFC 3265. > > > I can support such a plan. > > I will continue to argue that the event packages and info packages > should be independent of each other, but that's a minor detail. I > generally agree with the larger picture. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 17:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlA03-0000Se-AY; Thu, 25 Oct 2007 17:12:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlA00-0000NM-JZ for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 17:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il9zz-0000KL-NU for sip@ietf.org; Thu, 25 Oct 2007 17:12:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il9zy-0005le-Ft for sip@ietf.org; Thu, 25 Oct 2007 17:12:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2007 14:12:13 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9PLCDhD022921; Thu, 25 Oct 2007 17:12:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9PLCCQq011170; Thu, 25 Oct 2007 21:12:12 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 17:12:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 17:12:08 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgXSKpO76i33d1STyaz5hShqY90TQAAtwfw From: "Sanjay Sinha (sanjsinh)" To: "Robert Sparks" , "Adam Roach" X-OriginalArrivalTime: 25 Oct 2007 21:12:12.0667 (UTC) FILETIME=[B63064B0:01C8174B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--22.988200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2862; t=1193346733; x=1194210733; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20INFO=3A=20A=20recap, sense=20of=20consensus=20 and=20a=20proposal=20for=20direction. |Sender:=20 |To:=20=22Robert=20Sparks=22=20, =20=22Adam=20Roach= 22=20; bh=mfReKFh5BIioeKbFCV67a10m5zIKAGSw0F/VT+qXWnY=; b=FPFwEKlJSfmISinJytdxuboxmHGoil/rKhVkZb3suYV1z9sXQeodT82jRS+kzSt5ySJrvqbN 2OtQhymUxPKSw72xCLIok6ZI23gYf34fL3ID3GRA4FVM8t8mBPAhKACO; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Why does the call need to go away, if INFO is rejected? Isn't INFO not supposed to affect call state(s)? - Sanjay=20 >-----Original Message----- >From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 >Sent: Thursday, October 25, 2007 4:43 PM >To: Adam Roach >Cc: sip List; Dean Willis >Subject: Re: [Sip] INFO: A recap,sense of consensus and a=20 >proposal for direction. > >I'm pretty (actually extremely) unhappy with the idea, but=20 >I'll try not to throw myself on the tracks in front of it. > >Taking a tumble down the slope: > >These info packages need to be separate from event packages -=20 >there may be some where you just derive an info package from=20 >an event package with a trival rfc, but it will _not_ be the=20 >case that it will make sense to throw any old event package's=20 >payload into an INFO like thing like this (think of the mess=20 >you'll get into with anything with a partial payload, and the=20 >bigger mess when you get into the infrastructure of the=20 >framework, including winfo and eventlists). > >And we'd need to specify quite concretely what happens when=20 >one of these INFOs gets rejected. >In most cases, the call is going to have to go away, and I bet=20 >that's going to make a lot of people unhappy. > >RjS > >On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: > >> On 10/24/07 2:18 PM, Dean Willis wrote: >>> I propose we develop a new RFC that extends RFC 3265 and obsoletes =20 >>> RFC 2976. >>> >>> This RFC will document use of event bodies in INFO messages =20 >>> exchanged in dialog usages established by SIP INVITE transactions. =20 >>> This will include definition of the "Send-Events" and "Recv-=20 >>> Events" header fields, use of those header fields in INVITE =20 >>> transactions to provide an offer/answer exchange, definition and =20 >>> use of a new option tag for this extension, and the needed changes =20 >>> to the registry established by RFC 3265. >> >> >> I can support such a plan. >> >> I will continue to argue that the event packages and info packages =20 >> should be independent of each other, but that's a minor detail. I =20 >> generally agree with the larger picture. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 17:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlA9j-0002to-2b; Thu, 25 Oct 2007 17:22:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlA9g-0002pt-2f for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 17:22:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlA9f-0002o7-Mr for sip@ietf.org; Thu, 25 Oct 2007 17:22:15 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlA9f-00075k-Dd for sip@ietf.org; Thu, 25 Oct 2007 17:22:15 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PLM9pZ039718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 16:22:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <47210901.5070104@nostrum.com> Date: Thu, 25 Oct 2007 16:22:09 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org On 10/25/07 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.txt /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 17:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAT5-0008J2-1o; Thu, 25 Oct 2007 17:42:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlAT3-0008GH-PZ for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 17:42:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAT3-0008G9-82 for sip@ietf.org; Thu, 25 Oct 2007 17:42:17 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlAT2-0007ga-Uq for sip@ietf.org; Thu, 25 Oct 2007 17:42:17 -0400 Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id B0A771C8080; Thu, 25 Oct 2007 16:12:22 -0500 (CDT) From: "Frank W. Miller" To: "'Adam Roach'" , "'Sanjay Sinha \(sanjsinh\)'" Date: Thu, 25 Oct 2007 15:41:33 -0600 Message-ID: <01ba01c8174f$cfc134a0$6901a8c0@cornfed> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <47210901.5070104@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'sip List' , 'Dean Willis' Subject: [Sip] Mutual subscriptions 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: , Errors-To: sip-bounces@ietf.org Forgive me if this question has already been asked but... In reading this draft over, which is very interesting, I observe that for the case of mutual subscription, it would be much simpler to just disallow the subscribed party to reuse the dialog for the incoming subscription? Thanks, FM -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, October 25, 2007 3:22 PM To: Sanjay Sinha (sanjsinh) Cc: sip List; Dean Willis Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for direction. On 10/25/07 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.tx t /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 18:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAjw-00012i-EP; Thu, 25 Oct 2007 17:59:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlAju-00012M-O1 for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAju-00011j-Da for sip@ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlAjt-0007Tc-3R for sip@ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PLxLpb041561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 16:59:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472111BA.8040900@nostrum.com> Date: Thu, 25 Oct 2007 16:59:22 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] Mutual subscriptions References: <01ba01c8174f$cfc134a0$6901a8c0@cornfed> In-Reply-To: <01ba01c8174f$cfc134a0$6901a8c0@cornfed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'sip List' , '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: , Errors-To: sip-bounces@ietf.org On 10/25/07 4:41 PM, Frank W. Miller wrote: > Forgive me if this question has already been asked but... > > In reading this draft over, which is very interesting, I observe that > for the case of mutual subscription, it would be much simpler to just > disallow the subscribed party to reuse the dialog for the incoming > subscription? > Yes. And, with GRUUs, we now have this ability. Absent GRUUs, there was no way to guarantee that you ended up talking to exactly the same device without re-using dialogs. /a > Thanks, > FM > > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, October 25, 2007 3:22 PM > To: Sanjay Sinha (sanjsinh) > Cc: sip List; Dean Willis > Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for > direction. > > On 10/25/07 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > >> Why does the call need to go away, if INFO is rejected? Isn't INFO not >> supposed to affect call state(s)? >> >> > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.tx > t > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments oFrom sip-bounces@ietf.org Thu Oct 25 18:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAjw-00012i-EP; Thu, 25 Oct 2007 17:59:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlAju-00012M-O1 for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAju-00011j-Da for sip@ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlAjt-0007Tc-3R for sip@ietf.org; Thu, 25 Oct 2007 17:59:42 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PLxLpb041561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 16:59:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472111BA.8040900@nostrum.com> Date: Thu, 25 Oct 2007 16:59:22 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] Mutual subscriptions References: <01ba01c8174f$cfc134a0$6901a8c0@cornfed> In-Reply-To: <01ba01c8174f$cfc134a0$6901a8c0@cornfed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'sip List' , '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: , Errors-To: sip-bounces@ietf.org On 10/25/07 4:41 PM, Frank W. Miller wrote: > Forgive me if this question has already been asked but... > > In reading this draft over, which is very interesting, I observe that > for the case of mutual subscription, it would be much simpler to just > disallow the subscribed party to reuse the dialog for the incoming > subscription? > Yes. And, with GRUUs, we now have this ability. Absent GRUUs, there was no way to guarantee that you ended up talking to exactly the same device without re-using dialogs. /a > Thanks, > FM > > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, October 25, 2007 3:22 PM > To: Sanjay Sinha (sanjsinh) > Cc: sip List; Dean Willis > Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for > direction. > > On 10/25/07 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > >> Why does the call need to go away, if INFO is rejected? Isn't INFO not >> supposed to affect call state(s)? >> >> > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.tx > t > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 18:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAkR-0001UZ-Vq; Thu, 25 Oct 2007 18:00:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlAkP-0001Te-TN for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAkP-0001Rg-GN for sip@ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlAkO-0008GG-Sk for sip@ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PM070b041656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 17:00:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 16:59:53 -0500 To: "Sanjay Sinha (sanjsinh)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org And there we go... not even 20 minutes. So, you are right for INFO as we have historically known it. This new gorgon that Dean is proposing is not like that INFO. It's something that's carrying state based on (effectively) an implicit subscription (or something very much like a subscription, but without any of the control infrastructure) in the INVITE. If something goes _wrong_ in that subscription, you don't have a clean separate usage you can tear down and leave the INVITE usage up (I expect pushback here, and I anticipate that when you try to _add_ that clarity, you'll end up most, if not all, of the way to just using SUBSCRIBE). Maybe to avoid the confusion you just pointed to, we could call this beast NOTINFO? RjS On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > > - Sanjay > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Thursday, October 25, 2007 4:43 PM >> To: Adam Roach >> Cc: sip List; Dean Willis >> Subject: Re: [Sip] INFO: A recap,sense of consensus and a >> proposal for direction. >> >> I'm pretty (actually extremely) unhappyn the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 25 18:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAkR-0001UZ-Vq; Thu, 25 Oct 2007 18:00:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlAkP-0001Te-TN for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlAkP-0001Rg-GN for sip@ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlAkO-0008GG-Sk for sip@ietf.org; Thu, 25 Oct 2007 18:00:13 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9PM070b041656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 17:00:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 16:59:53 -0500 To: "Sanjay Sinha (sanjsinh)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4594/Thu Oct 25 07:45:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org And there we go... not even 20 minutes. So, you are right for INFO as we have historically known it. This new gorgon that Dean is proposing is not like that INFO. It's something that's carrying state based on (effectively) an implicit subscription (or something very much like a subscription, but without any of the control infrastructure) in the INVITE. If something goes _wrong_ in that subscription, you don't have a clean separate usage you can tear down and leave the INVITE usage up (I expect pushback here, and I anticipate that when you try to _add_ that clarity, you'll end up most, if not all, of the way to just using SUBSCRIBE). Maybe to avoid the confusion you just pointed to, we could call this beast NOTINFO? RjS On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > > - Sanjay > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Thursday, October 25, 2007 4:43 PM >> To: Adam Roach >> Cc: sip List; Dean Willis >> Subject: Re: [Sip] INFO: A recap,sense of consensus and a >> proposal for direction. >> >> I'm pretty (actually extremely) unhappy with the idea, but >> I'll try not to throw myself on the tracks in front of it. >> >> Taking a tumble down the slope: >> >> These info packages need to be separate from event packages - >> there may be some where you just derive an info package from >> an event package with a trival rfc, but it will _not_ be the >> case that it will make sense to throw any old event package's >> payload into an INFO like thing like this (think of the mess >> you'll get into with anything with a partial payload, and the >> bigger mess when you get into the infrastructure of the >> framework, including winfo and eventlists). >> >> And we'd need to specify quite concretely what happens when >> one of these INFOs gets rejected. >> In most cases, the call is going to have to go away, and I bet >> that's going to make a lot of people unhappy. >> >> RjS >> >> On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: >> >>> On 10/24/07 2:18 PM, Dean Willis wrote: >>>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>>> RFC 2976. >>>> >>>> This RFC will document use of event bodies in INFO messages >>>> exchanged in dialog usages established by SIP INVITE transactions. >>>> This will include definition of the "Send-Events" and "Recv- >>>> Events" header fields, use of those header fields in INVITE >>>> transactions to provide an offer/answer exchange, definition and >>>> use of a new option tag for this extension, and the needed changes >>>> to the registry established by RFC 3265. >>> >>> >>> I can support such a plan. >>> >>> I will continue to argue that the event packages and info packages >>> should be independent of each other, but that's a minor detail. I >>> generally agree with the larger picture. >>> >>> /a >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip with the idea, but >> I'll try not to throw myself on the tracks in front of it. >> >> Taking a tumble down the slope: >> >> These info packages need to be separate from event packages - >> there may be some where you just derive an info package from >> an event package with a trival rfc, but it will _not_ be the >> case that it will make sense to throw any old event package's >> payload into an INFO like thing like this (think of the mess >> you'll get into with anything with a partial payload, and the >> bigger mess when you get into the infrastructure of the >> framework, including winfo and eventlists). >> >> And we'd need to specify quite concretely what happens when >> one of these INFOs gets rejected. >> In most cases, the call is going to have to go away, and I bet >> that's going to make a lot of people unhappy. >> >> RjS >> >> On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: >> >>> On 10/24/07 2:18 PM, Dean Willis wrote: >>>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>>> RFC 2976. >>>> >>>> This RFC will document use of event bodies in INFO messages >>>> exchanged in dialog usages established by SIP INVITE transactions. >>>> This will include definition of the "Send-Events" and "Recv- >>>> Events" header fields, use of those header fields in INVITE >>>> transactions to provide an offer/answer exchange, definition and >>>> use of a new option tag for this extension, and the needed changes >>>> to the registry established by RFC 3265. >>> >>> >>> I can support such a plan. >>> >>> I will continue to argue that the event packages and info packages >>> should be independent of each other, but that's a minor detail. I >>> generally agree with the larger picture. >>> >>> /a >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 19:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBqM-0000Gf-3J; Thu, 25 Oct 2007 19:10:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlBqK-0000GX-39 for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 19:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBqJ-0000GP-PT for sip@ietf.org; Thu, 25 Oct 2007 19:10:23 -0400 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 1IlBqI-00015u-Fu for sip@ietf.org; Thu, 25 Oct 2007 19:10:23 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2007 16:10:22 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9PNALoQ002417; Thu, 25 Oct 2007 16:10:21 -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 l9PNA9AV001680; Thu, 25 Oct 2007 23:10:17 GMT 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.1830); Thu, 25 Oct 2007 19:10:04 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 19:10:03 -0400 Message-ID: <4721224B.4080408@cisco.com> Date: Thu, 25 Oct 2007 19:10:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 23:10:03.0801 (UTC) FILETIME=[2CE9D090:01C8175C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--21.141700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3451; t=1193353822; x=1194217822; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20; bh=WeI90TQ+4u7Z7pEiXvetePulr/+hUV3895NAXRnuGmA=; b=QjvcogyoWQU3TaCqCGXzf3+KxUSneQX3N/bubQY8wKy3HvDyvH4/2DIqDAOfVYH40fzsxr4b 4inFvYJ6CDmCQIzEPlgxNayo5ubtGcOOliWxAtcrsd8WxOaWfwbHj+wC85tihdRlQbZZErn64D 9DMMRhhTXzGZ6M8jWQsPoIweI=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > I'm pretty (actually extremely) unhappy with the idea, but I'll try not > to throw myself on the tracks in front of it. > > Taking a tumble down the slope: > > These info packages need to be separate from event packages - there may > be some > where you just derive an info package from an event package with a > trival rfc, but it will > _not_ be the case that it will make sense to throw any old event > package's payload into > an INFO like thing like this (think of the mess you'll get into with > anything with a partial > payload, and the bigger mess when you get into the infrastructure of the > framework, including winfo > and eventlists). AFAIK nobody is suggesting that by some stroke of the pen all event packages will magically become usable via this new mechanism. I agree that makes no sense. It would indeed require some action on each and every one to adapt it to work with this new environment. For many it would make no sense to do so, and would probably be impossible. For those where it is possible and desirable I think it will be sort of like making a new "skin" for a GUI - the moving parts are all the same, though perhaps not all are visible through the new skin, but the look is different. > And we'd need to specify quite concretely what happens when one of these > INFOs gets rejected. > In most cases, the call is going to have to go away, and I bet that's > going to make a lot of people unhappy. I don't understand you here. I just checked dialogusage. As far as I can tell, the behavior in there makes perfect sense here. Those errors on INFO that tear down the usage or the dialog should do the same here. If it does turn out that the error handling for this new approach are inconsistent with error handling for INFO then we should define a new method. Paul > On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: > >> On 10/24/07 2:18 PM, Dean Willis wrote: >>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>> RFC 2976. >>> >>> This RFC will document use of event bodies in INFO messages exchanged >>> in dialog usages established by SIP INVITE transactions. This will >>> include definition of the "Send-Events" and "Recv-Events" header >>> fields, use of those header fields in INVITE transactions to provide >>> an offer/answer exchange, definition and use of a new option tag for >>> this extension, and the needed changes to the registry established by >>> RFC 3265. >> >> >> I can support such a plan. >> >> I will continue to argue that the event packages and info packages >> should be independent of each other, but that's a minor detail. I >> generally agree with the larger picture. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 19:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBv2-0002WD-1J; Thu, 25 Oct 2007 19:15:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlBv0-0002Vr-4u for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 19:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBuz-0002VU-Kj for sip@ietf.org; Thu, 25 Oct 2007 19:15:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlBuy-0001fr-P7 for sip@ietf.org; Thu, 25 Oct 2007 19:15:13 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 25 Oct 2007 16:15:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9PNFCBr002004; Thu, 25 Oct 2007 16:15:12 -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 l9PNF5Fj027462; Thu, 25 Oct 2007 23:15:05 GMT 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.1830); Thu, 25 Oct 2007 19:15:05 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 19:15:04 -0400 Message-ID: <47212378.4010309@cisco.com> Date: Thu, 25 Oct 2007 19:15:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> In-Reply-To: <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 23:15:04.0885 (UTC) FILETIME=[E05F9650:01C8175C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--33.962200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4710; t=1193354112; x=1194218112; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20; bh=43rBJXqR1vkVNg++8cQCL4BSA2JN8P6RkBZb3wMc364=; b=DF+t5X8F2QGyVd1Zlib6EcWPgYWojTpc4lILaB/y9QOYMkPJGZ9R0olaU5zSjrM0gidYLwPm Di1ftRtHRsDMtW9nzrasEvLdwikGt2c8Lb/E32oL7n9n/HY3cVPKAIGv; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > And there we go... not even 20 minutes. > > So, you are right for INFO as we have historically known it. > > This new gorgon that Dean is proposing is not like that INFO. > > It's something that's carrying state based on (effectively) an implicit > subscription (or something very much like a subscription, but without > any of the control infrastructure) in the INVITE. > > If something goes _wrong_ in that subscription, you don't have a clean > separate usage you can tear down and leave the INVITE usage up (I expect > pushback here, and I anticipate that when you try to _add_ that clarity, > you'll end up most, if not all, of the way to just using SUBSCRIBE). My impression is that people are assuming that this way of handling events only makes sense when they are tightly related to the INVITE usage. So its ok if the kinds of errors that kill usages and dialogs kill the INVITE. The kinds of errors that are pertinent only to the event notification are typically the kinds of things that only affect the transaction anyway. > Maybe to avoid the confusion you just pointed to, we could call this > beast NOTINFO? Actually I'm ok with that. (I was advocating MESSAGE, not INFO. I don't see any great value in INFO over anything else.) :-) Paul > RjS > > On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > >> Why does the call need to go away, if INFO is rejected? Isn't INFO not >> supposed to affect call state(s)? >> >> - Sanjay >> >>> -----Original Message----- >>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>> Sent: Thursday, October 25, 2007 4:43 PM >>> To: Adam Roach >>> Cc: sip List; Dean Willis >>> Subject: Re: [Sip] INFO: A recap,sense of consensus and a >>> proposal for direction. >>> >>> I'm pretty (actually extremely) unhappy with the idea, but >>> I'll try not to throw myself on the tracks in front of it. >>> >>> Taking a tumble down the slope: >>> >>> These info packages need to be separate from event packages - >>> there may be some where you just derive an info package from >>> an event package with a trival rfc, but it will _not_ be the >>> case that it will make sense to throw any old event package's >>> payload into an INFO like thing like this (think of the mess >>> you'll get into with anything with a partial payload, and the >>> bigger mess when you get into the infrastructure of the >>> framework, including winfo and eventlists). >>> >>> And we'd need to specify quite concretely what happens when >>> one of these INFOs gets rejected. >>> In most cases, the call is going to have to go away, and I bet >>> that's going to make a lot of people unhappy. >>> >>> RjS >>> >>> On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: >>> >>>> On 10/24/07 2:18 PM, Dean Willis wrote: >>>>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>>>> RFC 2976. >>>>> >>>>> This RFC will document use of event bodies in INFO messages >>>>> exchanged in dialog usages established by SIP INVITE transactions. >>>>> This will include definition of the "Send-Events" and "Recv- >>>>> Events" header fields, use of those header fields in INVITE >>>>> transactions to provide an offer/answer exchange, definition and >>>>> use of a new option tag for this extension, and the needed changes >>>>> to the registry established by RFC 3265. >>>> >>>> >>>> I can support such a plan. >>>> >>>> I will continue to argue that the event packages and info packages >>>> should be independent of each other, but that's a minor detail. I >>>> generally agree with the larger picture. >>>> >>>> /a >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 25 19:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlCLZ-0003wa-Tl; Thu, 25 Oct 2007 19:42:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlCLX-0003u4-Hf for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 19:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlCLX-0003tE-7p for sip@ietf.org; Thu, 25 Oct 2007 19:42:39 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlCLQ-000230-T1 for sip@ietf.org; Thu, 25 Oct 2007 19:42:39 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Thu, 25 Oct 2007 16:42:12 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l9PNg9Kn024381; Thu, 25 Oct 2007 16:42:10 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l9PNg6RE018089; Thu, 25 Oct 2007 16:42:08 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 08:42:08 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 16:41:55 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE1CD@namail5.corp.adobe.com> In-Reply-To: <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgXUvNL9aLhrx8GSN2T/bf3+B2EGwADY8FQ References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> From: "Henry Sinnreich" To: "Robert Sparks" , "Sanjay Sinha (sanjsinh)" X-OriginalArrivalTime: 25 Oct 2007 23:42:08.0126 (UTC) FILETIME=[A7E681E0:01C81760] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Are there some compelling usage scenarios to break the tie? Henry -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Thursday, October 25, 2007 5:00 PM To: Sanjay Sinha (sanjsinh) Cc: sip List; Adam Roach; Dean Willis Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for direction. And there we go... not even 20 minutes. So, you are right for INFO as we have historically known it. This new gorgon that Dean is proposing is not like that INFO. It's something that's carrying state based on (effectively) an =20 implicit subscription (or something very much like a subscription, =20 but without any of the control infrastructure) in the INVITE. If something goes _wrong_ in that subscription, you don't have a =20 clean separate usage you can tear down and leave the INVITE usage up =20 (I expect pushback here, and I anticipate that when you try to _add_ =20 that clarity, you'll end up most, if not all, of the way to just =20 using SUBSCRIBE). Maybe to avoid the confusion you just pointed to, we could call this =20 beast NOTINFO? RjS On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote: > Why does the call need to go away, if INFO is rejected? Isn't INFO not > supposed to affect call state(s)? > > - Sanjay > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Thursday, October 25, 2007 4:43 PM >> To: Adam Roach >> Cc: sip List; Dean Willis >> Subject: Re: [Sip] INFO: A recap,sense of consensus and a >> proposal for direction. >> >> I'm pretty (actually extremely) unhappy with the idea, but >> I'll try not to throw myself on the tracks in front of it. >> >> Taking a tumble down the slope: >> >> These info packages need to be separate from event packages - >> there may be some where you just derive an info package from >> an event package with a trival rfc, but it will _not_ be the >> case that it will make sense to throw any old event package's >> payload into an INFO like thing like this (think of the mess >> you'll get into with anything with a partial payload, and the >> bigger mess when you get into the infrastructure of the >> framework, including winfo and eventlists). >> >> And we'd need to specify quite concretely what happens when >> one of these INFOs gets rejected. >> In most cases, the call is going to have to go away, and I bet >> that's going to make a lot of people unhappy. >> >> RjS >> >> On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: >> >>> On 10/24/07 2:18 PM, Dean Willis wrote: >>>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>>> RFC 2976. >>>> >>>> This RFC will document use of event bodies in INFO messages >>>> exchanged in dialog usages established by SIP INVITE transactions. >>>> This will include definition of the "Send-Events" and "Recv- >>>> Events" header fields, use of those header fields in INVITE >>>> transactions to provide an offer/answer exchange, definition and >>>> use of a new option tag for this extension, and the needed changes >>>> to the registry established by RFC 3265. >>> >>> >>> I can support such a plan. >>> >>> I will continue to argue that the event packages and info packages >>> should be independent of each other, but that's a minor detail. I >>> generally agree with the larger picture. >>> >>> /a >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 25 19:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlCSI-0001Su-HI; Thu, 25 Oct 2007 19:49:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlCSH-0001Sn-86 for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 19:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlCSG-0001Sf-Up for sip@ietf.org; Thu, 25 Oct 2007 19:49:36 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlCSA-0002GZ-P9 for sip@ietf.org; Thu, 25 Oct 2007 19:49:36 -0400 Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 4AEA6758085; Thu, 25 Oct 2007 18:49:15 -0500 (CDT) From: "Frank W. Miller" To: "'Paul Kyzivat'" , "'Robert Sparks'" Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 17:48:32 -0600 Message-ID: <01cb01c81761$8d204cf0$6901a8c0@cornfed> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4721224B.4080408@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 'sip List' , 'Adam Roach' , '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: , Errors-To: sip-bounces@ietf.org I mean this a little bit phoceciously, but where is Jonathan in all this? When I proposed some INFO based extensions a several years ago, there was a drumbeat of INFO is going away, don't use it damnit!! As far as my opinion, I don't really care. Its just more implementation effort, or not. SIP is really turning into a jobs program, job security forever... FM -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, October 25, 2007 5:10 PM To: Robert Sparks Cc: sip List; Adam Roach; Dean Willis Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for direction. Robert Sparks wrote: > I'm pretty (actually extremely) unhappy with the idea, but I'll try not > to throw myself on the tracks in front of it. > > Taking a tumble down the slope: > > These info packages need to be separate from event packages - there may > be some > where you just derive an info package from an event package with a > trival rfc, but it will > _not_ be the case that it will make sense to throw any old event > package's payload into > an INFO like thing like this (think of the mess you'll get into with > anything with a partial > payload, and the bigger mess when you get into the infrastructure of the > framework, including winfo > and eventlists). AFAIK nobody is suggesting that by some stroke of the pen all event packages will magically become usable via this new mechanism. I agree that makes no sense. It would indeed require some action on each and every one to adapt it to work with this new environment. For many it would make no sense to do so, and would probably be impossible. For those where it is possible and desirable I think it will be sort of like making a new "skin" for a GUI - the moving parts are all the same, though perhaps not all are visible through the new skin, but the look is different. > And we'd need to specify quite concretely what happens when one of these > INFOs gets rejected. > In most cases, the call is going to have to go away, and I bet that's > going to make a lot of people unhappy. I don't understand you here. I just checked dialogusage. As far as I can tell, the behavior in there makes perfect sense here. Those errors on INFO that tear down the usage or the dialog should do the same here. If it does turn out that the error handling for this new approach are inconsistent with error handling for INFO then we should define a new method. Paul > On Oct 25, 2007, at 3:06 PM, Adam Roach wrote: > >> On 10/24/07 2:18 PM, Dean Willis wrote: >>> I propose we develop a new RFC that extends RFC 3265 and obsoletes >>> RFC 2976. >>> >>> This RFC will document use of event bodies in INFO messages exchanged >>> in dialog usages established by SIP INVITE transactions. This will >>> include definition of the "Send-Events" and "Recv-Events" header >>> fields, use of those header fields in INVITE transactions to provide >>> an offer/answer exchange, definition and use of a new option tag for >>> this extension, and the needed changes to the registry established by >>> RFC 3265. >> >> >> I can support such a plan. >> >> I will continue to argue that the event packages and info packages >> should be independent of each other, but that's a minor detail. I >> generally agree with the larger picture. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 25 23:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGJf-00083f-Jr; Thu, 25 Oct 2007 23:56:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlGJd-00083Y-PH for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGJd-00083P-Eu for sip@ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGJd-0000hs-4e for sip@ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net [96.226.64.76]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9Q3ukoh034062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 22:56:51 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , sip-implementors@lists.cs.columbia.edu, discussion@sipforum.org From: Robert Sparks Date: Thu, 25 Oct 2007 22:56:39 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] SIPit 21 registration closes this weekend 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: , Errors-To: sip-bounces@ietf.org Folks - If you're planning to attend SIPit 21 but have not yet registered, now's the time. See you in Beijing! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 23:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGEK-0007kU-1n; Thu, 25 Oct 2007 23:51:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlGEJ-0007kO-1S for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 23:51:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGEI-0007iD-NY for sip@ietf.org; Thu, 25 Oct 2007 23:51:26 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGEG-0000Z0-Eh for sip@ietf.org; Thu, 25 Oct 2007 23:51:24 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 25 Oct 2007 23:51:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 25 Oct 2007 23:51:23 -0400 From: Hadriel Kaplan To: Robert Sparks , Adam Roach Date: Thu, 25 Oct 2007 23:48:31 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgXSKQg3wThunHfThm+xF2AnrLHdAANOtFw Message-ID: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGJf-00083f-Jr; Thu, 25 Oct 2007 23:56:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlGJd-00083Y-PH for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGJd-00083P-Eu for sip@ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGJd-0000hs-4e for sip@ietf.org; Thu, 25 Oct 2007 23:56:57 -0400 Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net [96.226.64.76]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9Q3ukoh034062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 22:56:51 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , sip-implementors@lists.cs.columbia.edu, discussion@sipforum.org From: Robert Sparks Date: Thu, 25 Oct 2007 22:56:39 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] SIPit 21 registration closes this weekend 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: , Errors-To: sip-bounces@ietf.org Folks - If you're planning to attend SIPit 21 but have not yet registered, now's the time. See you in Beijing! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 25 23:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGEK-0007kU-1n; Thu, 25 Oct 2007 23:51:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlGEJ-0007kO-1S for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 23:51:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGEI-0007iD-NY for sip@ietf.org; Thu, 25 Oct 2007 23:51:26 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGEG-0000Z0-Eh for sip@ietf.org; Thu, 25 Oct 2007 23:51:24 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 25 Oct 2007 23:51:23 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 25 Oct 2007 23:51:23 -0400 From: Hadriel Kaplan To: Robert Sparks , Adam Roach Date: Thu, 25 Oct 2007 23:48:31 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgXSKQg3wThunHfThm+xF2AnrLHdAANOtFw Message-ID: References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > > And we'd need to specify quite concretely what happens when one of > these INFOs gets rejected. > In most cases, the call is going to have to go away, and I bet that's > going to make a lot of people unhappy. When I looked at the usage draft a while ago it seemed to me that the failu= res you're talking about *should* make the call go away. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip t.com> References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > > And we'd need to specify quite concretely what happens when one of > these INFOs gets rejected. > In most cases, the call is going to have to go away, and I bet that's > going to make a lot of people unhappy. When I looked at the usage draft a while ago it seemed to me that the failu= res you're talking about *should* make the call go away. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 00:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGMH-0000nA-T4; Thu, 25 Oct 2007 23:59:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlGMG-0000n5-Av for sip-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 23:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGMG-0000mx-0j for sip@ietf.org; Thu, 25 Oct 2007 23:59:40 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlGME-0001HB-Mw for sip@ietf.org; Thu, 25 Oct 2007 23:59:39 -0400 Received: from [192.168.2.235] (pool-96-226-64-76.dllstx.fios.verizon.net [96.226.64.76]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9Q3xHKo058514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 22:59:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5227A3DF-247D-4FEA-8B23-E5A234DA2143@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Thu, 25 Oct 2007 22:59:10 -0500 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 96.226.64.76 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4596/Thu Oct 25 18:37:29 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org On Oct 25, 2007, at 10:48 PM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> >> And we'd need to specify quite concretely what happens when one of >> these INFOs gets rejected. >> In most cases, the call is going to have to go away, and I bet that's >> going to make a lot of people unhappy. > > When I looked at the usage draft a while ago it seemed to me that > the failures you're talking about *should* make the call go away. Oh - I very much think they should. Sorry if what I wrote above was unclear. I'm just expecting that not to be a universally shared sentiment (yet). > -hadriel > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 06:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMQY-00057Y-3e; Fri, 26 Oct 2007 06:28:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlMQW-00056v-D0 for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 06:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMQW-00056n-3J for sip@ietf.org; Fri, 26 Oct 2007 06:28:28 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlMQP-00078B-Lv for sip@ietf.org; Fri, 26 Oct 2007 06:28:28 -0400 Received: by wx-out-0506.google.com with SMTP id s8so731482wxc for ; Fri, 26 Oct 2007 03:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=BKpvo1lJ1dL4/Gb73+TynTMb87fRwxQQ22TLEJcWfIU=; b=AldtY8Aar4tv70+1kiBcgRnlcl3N2N797v4GCdw94AbCGXNIEpEonT5tDC4tVa+4pRel7xeL06uAXArTyedql0Ug7BYtycnI4q6bwxRmPi8qQ5XNyZwONayshrYTt9dcOxhB4crH3NSBvyI2unOlKX6wlaiPbdNmQkKmx1zHhnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=I2GB+/77rosSMd2ijJlzG1tugPDjoO7OrsMWpsqU7iAP3TlhRyK55fSU7G+v9uEVV8t1Uzb/UE6NKK4TiRAYPvEzAnzaddeW824rSkquH4RxDBqZY+BQKfoNkXVo1L3GL7WQ49LP+Zj9ElLHq3iEmkT/XAooyW+ajjfsgBEcpiM= Received: by 10.70.10.3 with SMTP id 3mr4754313wxj.1193394486352; Fri, 26 Oct 2007 03:28:06 -0700 (PDT) Received: by 10.70.117.20 with HTTP; Fri, 26 Oct 2007 03:28:06 -0700 (PDT) Message-ID: <18a603a60710260328h161c9a95re1ea3065ef498e22@mail.gmail.com> Date: Fri, 26 Oct 2007 12:28:06 +0200 From: "Pars Mutaf" To: sip@ietf.org Subject: Re: [Sip] IETF solution for pairing cellular hosts In-Reply-To: <470E3318.20309@cisco.com> MIME-Version: 1.0 References: <18a603a60709270649j2f6b19d3w77cc244f8403bd6c@mail.gmail.com> <18a603a60710050543n502f0c40x8b81a6e8f51455f3@mail.gmail.com> <200710082306.l98N6c8T012624@dragon.ariadne.com> <18a603a60710090117jd6a6e1eh383304af1a34278c@mail.gmail.com> <470B72FF.3010000@cisco.com> <18a603a60710090558j60934325l300ee7c3d57d2d11@mail.gmail.com> <20071009135435.502B47DF3@bender.tigertech.net> <18a603a60710090853l655f2be6u555f1daa19f3acec@mail.gmail.com> <470BAAD4.8030003@cisco.com> <470E3318.20309@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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="===============1690214354==" Errors-To: sip-bounces@ietf.org --===============1690214354== Content-Type: multipart/alternative; boundary="----=_Part_6628_23262970.1193394486347" ------=_Part_6628_23262970.1193394486347 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Before you shoot me (I agree that this is orthogonal to SIP), thanks all for your previous input, I'm here showing you the results of your input; the new IP pairing problem statement, thanks. pars IP host pairing problem statement Today, cell phone numbers are not published in a phonebook for avoiding telemarketers, prank callers, Spam and SPIT (SPam over Internet Telephony). Users today exchange their phone numbers upon user contact, often through oral communication. In IP telephony, users will need a user friendly "pairing" protocol that identifies the two phones and let them exchange their SIP URIs and Mobile IPv6 home addresses, and possibly other information. The phones will establish an IPsec security association upon this first contact. IPsec will be required not only for protecting their SIP URIs from eavesdroppers, but also for protecting data. "IP host pairing" is defined as a pairing protocol that can operate over IP; upon user contact and also over the Internet i.e. long distances. It will address three problems of pairing: 1. Pairing when there is user contact: In this case, users can exchange their names or pseudonyms helping identify the hosts to each other the first time they meet. 2. Re-pairing, or updating pairing state through the Internet: The users may change their SIP URIs and/or Mobile IPv6 home addresses or other information. The users will need to update these informations without waiting until their next meeting. Or, they may need additional information which was not previously exchanged when there was user contact. 3. Pairing without user contact (where possible): Users may know each other but user contact may not be possible. Or, two previously paired hosts may lose pairing state. Users cannot probably wait until their next meeting to recover from loss of state. Engineering problems: - Identifying the two hosts to each other in (1) and (3). - Preventing unauthorized and annoying pairing attempts from unknown users. - The design of the pairing protocol used to exchange and update the SIP URIs, home addresses and possibly other information. https://www1.ietf.org/mailman/listinfo/humanresolvers On 10/11/07, Paul Kyzivat wrote: > > Elaborating on my earlier reply... > > I question whether what you are trying to achieve even makes sense to > attempt, at least in the form you have framed the problem. And I sense > the same feeling from some of the other people, though that is only my > impression. > > Increasingly, people have multiple identifier (pseudonyms?) that they > are known by in various contexts. Some of these are unique, in that > there is a well defined relationship between the identifier and a > specific human being. In other cases the relationship between the > identifier and a human is non-unique, and other information must be used > to resolve the ambiguity. Person names are of the non-unique form. URIs > used for various forms of communication, including SIP and TEL, are > often unique. > > Just as it is increasingly common for people to use multiple identities, > it is often the case that they don't desire the association between one > of these identities and their person or other identities to be known. > However this isn't always the case. Sometimes the distinct identifiers > are simply an artifact of technology, and associations between them are > willingly exposed. > > (E.g. on some online forums I use a pseudonym. The operator of the list > knows the mapping to my email address and name, but this kept private. I > may choose to include my name, email address, or phone number in a > message on this forum - exposing the relationship - or I may carefully > refrain from doing so.) > > I think you have two problems to solve here, and they probably need > different solutions: > > 1) mapping from an ambiguous identifier for a person to an unambiguous > identifier. > > 2) given one unambiguous identifier, obtain a different unambiguous > identifier which enables a particular form of communication. > > For (1) I think the best you can expect to do is have some kind of > voluntary registry (roughly akin to the phone book) that lists the names > of people and whatever information they choose to make public that might > help disambiguate them from other people, and then a corresponding > unambiguous identifier. There doesn't have to be just one such registry. > Google does an admirable job of federating many sources of such > information. > > For (2) the solution is straightforward if the association between the > identify you have and the one you want is public. If it is not public, > then you must make a request and have it granted. If the identifier you > have enables a communication path where you can make a query then the > solution is straightforward - you just ask. If the identifier you have > (say a Social Security number) doesn't enable communication, then you > must delegate your request to some entity that knows the mapping you > desire, and the policy for determining whether to grant it to you. (This > could involve communicating with the target.) > > What seem like a bad idea to me is trying to combine (1) and (2) when > you don't have enough information to disambiguate. And IIUC that is what > you are proposing - to have an agent that knows the mapping from names > to phone numbers make queries to all people with matching names. IMO > there will be widespread objection to that, even if requests are > restricted to those requesters who have solved a CAPCHA. > > Paul > > Paul Kyzivat wrote: > > > > > > Pars Mutaf wrote: > >> > >> > >> On 10/9/07, *Joel M. Halpern* >> > wrote: > >> > >> At 08:58 AM 10/9/2007, you wrote: > >> >Where did you get this information. It is private. > >> > >> Presumably, the "this" refers to the SIP URI. > >> If you don't have the SIP URI, what string do you think you > >> have? Human names are utterly useless for this, due to collision, > >> misspelling, and many other problems. > >> > >> > >> To my knowledge, phonebook users never complained about that. > > > > Phone books worked reasonably well in a different age. And they depended > > on people being willing to advertise certain context information to the > > public at large: their phone number and an address. I think today that > > people are not so willing to disclose that information publicly. > > > > Today we often want to talk to people whose addresses we often don't > > know. Instead we may know their email address, or an IM address, etc. > > And those things are at least unique. > > > > So there are two problems here: > > - trying to find a unique address for someone given only > > some human name you have for them, and to disambiguate > > them from all the other people with similar names based > > on whatever information they might be willing to disclose > > to a random stranger. > > > > - given some unique address that is known to be associated > > with a given individual, find a different address for the > > same individual that is usable for some desired form of > > communication. > > > > The latter is probably a much more solvable problem. > > > >> The real problem of the phonebook, today, is the privacy > >> problem. An extension is needed for interactive user > >> permissions as stated by Adam Roach. > >> > >> A note about name collisions: > >> > >> Similarly to a traditional phonebook user, if you are looking > >> for a certain John Smith, hopefully you will have some > >> additional information helping filter the results. > >> > >> (in the proposed extension, the target cell phone may return > >> such information, e.g. company name, street address, etc.) > > > > I'm not likely to have my phone return that sort of information to > > unknown requestors. I don't know who would. > > > >> Note also that if anyone can send you a resolution request, that is > >> roughly equivalent, in terms of intrusiveness, to anyone causing > your > >> phone to ring. > >> > >> > >> The proposal is rather as follows (abstract): > >> > >> You solve to a challenge (e.g. a CAPTCHA) to obtain the target > >> phone number. > >> Then, you can make a call, send a message etc. > > > > Really! Maybe you are willing to give your information out to anyone who > > can solve a CAPTCHA, but I'm not. > > > > Note that in Adam's example you might be sending this request to dozens, > > hundreds, or more of targets that you are not interested in, and who are > > presumably not interested in you either. Then you are going to solve a > > capcha from each one enroute to finding the right one? And they are > > going to go along with this? > > > > Paul > > > >> Thanks, > >> pars > >> > >> > >> Alternatively, if you want a challenge / response on the resolution > >> request, you can give a challenge / response on the SIP request. > >> > >> Yours, > >> Joel > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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_6628_23262970.1193394486347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Before you shoot me (I agree that this is orthogonal to SIP),
thanks all for your previous input, I'm here showing you the
results of your input; the new IP pairing problem statement,
thanks.
pars


                  IP host pairing problem statement

Today, cell phone numbers are not published in a phonebook for avoiding
telemarketers, prank callers, Spam and SPIT (SPam over Internet
Telephony). Users today exchange their phone numbers upon user contact,
often through oral communication.

In IP telephony, users will need a user friendly "pairing" protocol
that identifies the two phones and let them exchange their SIP URIs and
Mobile IPv6 home addresses, and possibly other information. The phones
will establish an IPsec security association upon this first contact.
IPsec will be required not only for protecting their SIP URIs from
eavesdroppers, but also for protecting data.

"IP host pairing" is defined as a pairing protocol that can operate
over IP; upon user contact and also over the Internet i.e. long distances.
It will address three problems of pairing:

1. Pairing when there is user contact: In this case, users can exchange
   their names or pseudonyms helping identify the hosts to each other the
   first time they meet.
         
2. Re-pairing, or updating pairing state through the Internet: The users
   may change their SIP URIs and/or Mobile IPv6 home addresses or other
   information. The users will need to update these informations without
   waiting until their next meeting. Or, they may need additional
   information which was not previously exchanged when there was user
   contact.

3. Pairing without user contact (where possible): Users may know each
   other but user contact may not be possible. Or, two previously paired
   hosts may lose pairing state. Users cannot probably wait until their
   next meeting to recover from loss of state.

Engineering problems:

   - Identifying the two hosts to each other in (1) and (3).
   - Preventing unauthorized and annoying pairing attempts from unknown
     users.
   - The design of the pairing protocol used to exchange and update
     the SIP URIs, home addresses and possibly other information.



https://www1.ietf.org/mailman/listinfo/humanresolvers







On 10/11/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
Elaborating on my earlier reply...

I question whether what you are trying to achieve even makes sense to
attempt, at least in the form you have framed the problem. And I sense
the same feeling from some of the other people, though that is only my
impression.

Increasingly, people have multiple identifier (pseudonyms?) that they
are known by in various contexts. Some of these are unique, in that
there is a well defined relationship between the identifier and a
specific human being. In other cases the relationship between the
identifier and a human is non-unique, and other information must be used
to resolve the ambiguity. Person names are of the non-unique form. URIs
used for various forms of communication, including SIP and TEL, are
often unique.

Just as it is increasingly common for people to use multiple identities,
it is often the case that they don't desire the association between one
of these identities and their person or other identities to be known.
However this isn't always the case. Sometimes the distinct identifiers
are simply an artifact of technology, and associations between them are
willingly exposed.

(E.g. on some online forums I use a pseudonym. The operator of the list
knows the mapping to my email address and name, but this kept private. I
may choose to include my name, email address, or phone number in a
message on this forum - exposing the relationship - or I may carefully
refrain from doing so.)

I think you have two problems to solve here, and they probably need
different solutions:

1) mapping from an ambiguous identifier for a person to an unambiguous
identifier.

2) given one unambiguous identifier, obtain a different unambiguous
identifier which enables a particular form of communication.

For (1) I think the best you can expect to do is have some kind of
voluntary registry (roughly akin to the phone book) that lists the names
of people and whatever information they choose to make public that might
help disambiguate them from other people, and then a corresponding
unambiguous identifier. There doesn't have to be just one such registry.
Google does an admirable job of federating many sources of such information.

For (2) the solution is straightforward if the association between the
identify you have and the one you want is public. If it is not public,
then you must make a request and have it granted. If the identifier you
have enables a communication path where you can make a query then the
solution is straightforward - you just ask. If the identifier you have
(say a Social Security number) doesn't enable communication, then you
must delegate your request to some entity that knows the mapping you
desire, and the policy for determining whether to grant it to you. (This
could involve communicating with the target.)

What seem like a bad idea to me is trying to combine (1) and (2) when
you don't have enough information to disambiguate. And IIUC that is what
you are proposing - to have an agent that knows the mapping from names
to phone numbers make queries to all people with matching names. IMO
there will be widespread objection to that, even if requests are
restricted to those requesters who have solved a CAPCHA.

        Paul

Paul Kyzivat wrote:
>
>
> Pars Mutaf wrote:
>>
>>
>> On 10/9/07, *Joel M. Halpern* <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>> wrote:
>>
>>     At 08:58 AM 10/9/2007, you wrote:
>>      >Where did you get this information. It is private.
>>
>>     Presumably, the "this" refers to the SIP URI.
>>     If you don't have the SIP URI, what string do you think you
>>     have?  Human names are utterly useless for this, due to collision,
>>     misspelling, and many other problems.
>>
>>
>> To my knowledge, phonebook users never complained about that.
>
> Phone books worked reasonably well in a different age. And they depended
> on people being willing to advertise certain context information to the
> public at large: their phone number and an address. I think today that
> people are not so willing to disclose that information publicly.
>
> Today we often want to talk to people whose addresses we often don't
> know. Instead we may know their email address, or an IM address, etc.
> And those things are at least unique.
>
> So there are two problems here:
> - trying to find a unique address for someone given only
>   some human name you have for them, and to disambiguate
>   them from all the other people with similar names based
>   on whatever information they might be willing to disclose
>   to a random stranger.
>
> - given some unique address that is known to be associated
>   with a given individual, find a different address for the
>   same individual that is usable for some desired form of
>   communication.
>
> The latter is probably a much more solvable problem.
>
>> The real problem of the phonebook, today, is the privacy
>> problem. An extension is needed for interactive user
>> permissions as stated by Adam Roach.
>>
>> A note about name collisions:
>>
>> Similarly to a traditional phonebook user, if you are looking
>> for a certain John Smith, hopefully you will have some
>> additional information helping filter the results.
>>
>> (in the proposed extension, the target cell phone may return
>> such information, e.g. company name, street address, etc.)
>
> I'm not likely to have my phone return that sort of information to
> unknown requestors. I don't know who would.
>
>>     Note also that if anyone can send you a resolution request, that is
>>     roughly equivalent, in terms of intrusiveness, to anyone causing your
>>     phone to ring.
>>
>>
>> The proposal is rather as follows (abstract):
>>
>> You solve to a challenge ( e.g. a CAPTCHA) to obtain the target
>> phone number.
>> Then, you can make a call, send a message etc.
>
> Really! Maybe you are willing to give your information out to anyone who
> can solve a CAPTCHA, but I'm not.
>
> Note that in Adam's example you might be sending this request to dozens,
> hundreds, or more of targets that you are not interested in, and who are
> presumably not interested in you either. Then you are going to solve a
> capcha from each one enroute to finding the right one? And they are
> going to go along with this?
>
>     Paul
>
>> Thanks,
>> pars
>>
>>
>>     Alternatively, if you want a challenge / response on the resolution
>>     request, you can give a challenge / response on the SIP request.
>>
>>     Yours,
>>     Joel
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_6628_23262970.1193394486347-- --===============1690214354== 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 --===============1690214354==-- From sip-bounces@ietf.org Fri Oct 26 08:12:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlO0H-0008Vv-69; Fri, 26 Oct 2007 08:09:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlO0F-0008Vq-Tl for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 08:09:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlO0F-0008Vi-JA for sip@ietf.org; Fri, 26 Oct 2007 08:09:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlO0F-00084D-6g for sip@ietf.org; Fri, 26 Oct 2007 08:09:27 -0400 Received: from [192.168.0.48] (pool-70-21-195-31.nwrk.east.verizon.net [70.21.195.31]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9QC9N9W018494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 26 Oct 2007 08:09:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Henning Schulzrinne Date: Thu, 25 Oct 2007 23:01:40 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] draft-ietf-sip-rph-new-namespaces 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: , Errors-To: sip-bounces@ietf.org Keith asked me to review the draft; here are a few quick comments: While the mechanics and namespaces defined seem relatively straightforward, it is hard to evaluate anything beyond the syntax and editorial issues without knowing something about what motivated the design. Why 50 namespaces and not 42 or 99? Is this based on some existing PSTN technology or is this an attempt to have 50 departments in the DoD share some resource, without declaring who is more important than the other fiefdom or assistant vice deputy director? Why priority values that are even only? Depending on the motivation and background, there could well be other designs, such as 250 levels, where preemption is only within groups of 5. I'm not arguing that this is a better design, but it's hard to say anything even vaguely interesting without knowing the requirements. The wording is somewhat redundant, with the same information repeated three times, but in slightly different ways. In particular, the notion of non-preemption across namespaces seems to be couched in caveats. It seems that preemption across namespaces is sometimes permitted and sometimes not, which makes it rather difficult to build an implementation for the namespace without either a lot of configuration options or special software versions for each policy. We have seen in other areas that excessive configurability leads to interoperability problems and code complexity. I have a hard time picturing how to build such a configurable system without a monster language and all kinds of strange interactions. What happens if namespace 30 can preempt namespace 28, and vice versa? What about circular preemption chains (30 -> 17 -> 10)? In those cases, do namespaces have absolute priority, i.e., any priority in 30 beats any priority in 28? You'd have to create a matrix with 250 by 250 entries Paragraph breaks appear to be random, with a single thought split into three paragraphs (introduction). I can't parse sentences such as "matter of local policy. However, this policy is a known requirement..." What policy? The local policy, undefined? Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 26 10:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQAq-00036Z-0l; Fri, 26 Oct 2007 10:28:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQAp-00030V-3W for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:28:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQAo-00030N-Pd for sip@ietf.org; Fri, 26 Oct 2007 10:28:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQAo-00044Z-EG for sip@ietf.org; Fri, 26 Oct 2007 10:28:30 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9QESNrf029061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 09:28:24 -0500 In-Reply-To: <47200F59.2000205@cisco.com> References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <47200F59.2000205@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 09:28:17 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: sip-bounces@ietf.org On Oct 24, 2007, at 10:36 PM, Paul Kyzivat wrote: > Dean, > > Nice summary. > > I generally agree with what you have written. > > My major concern is with the negotiation mechanism. In particular I > think it needs to be done as a two-way handshake, not three way. A > three way negotiation will not work well with 3pcc. I should have commented on this in my recap as a point of discussion. But I am persuaded by your argument, and support a 2-way transacation and that was what was intended in my proposal. -- 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 26 10:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQC3-00065A-GO; Fri, 26 Oct 2007 10:29:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQC1-00060S-V4 for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:29:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQC1-0005vH-GU for sip@ietf.org; Fri, 26 Oct 2007 10:29:45 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQC1-00047R-3z for sip@ietf.org; Fri, 26 Oct 2007 10:29:45 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9QEThPX029074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 09:29:44 -0500 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D037D661@GBNTHT12009MSX.gb002.siemens.net> References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D037D661@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68039800-8D0C-458C-AED6-68115C607858@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 09:29:37 -0500 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: sip-bounces@ietf.org On Oct 25, 2007, at 5:09 AM, Elwell, John wrote: > Dean, > > A good summary and proposal. I am not yet 100% convinced we need to do > anything, but if we do the proposal sounds good. Just to correct one > point. > > >> There may then be a need for a subsequent RFC or RFCs to extend RFC >> 3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new >> model of >> INFO. >> > I think you intended to type RFC 4497 for QSIG. However, that RFC only > deals with interworking between QSIG and SIP. Tunnelling of QSIG over > SIP is specified in ECMA-355 from Ecma-International. > Yes, you're right. > For both SIP-T and QSIG tunnelling we would need to maintain backwards > compatibility with the existing standards. Of course. However, nothing prevents us from ALSO providing a forward- compatible and fully-negotiable solution, should we choose to do so. -- 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 26 10:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQG1-0002bQ-QG; Fri, 26 Oct 2007 10:33:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQG0-0002ZY-LH for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:33:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQG0-0002ZP-BA for sip@ietf.org; Fri, 26 Oct 2007 10:33:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQFz-0004HI-Uj for sip@ietf.org; Fri, 26 Oct 2007 10:33:52 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9QEXlxl029100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 09:33:49 -0500 In-Reply-To: References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 09:33:39 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip List , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Oct 25, 2007, at 3:43 PM, Robert Sparks wrote: > I'm pretty (actually extremely) unhappy with the idea, but I'll try > not to throw myself on the tracks in front of it. > > Taking a tumble down the slope: > > These info packages need to be separate from event packages - there > may be some > where you just derive an info package from an event package with a > trival rfc, but it will > _not_ be the case that it will make sense to throw any old event > package's payload into > an INFO like thing like this (think of the mess you'll get into > with anything with a partial > payload, and the bigger mess when you get into the infrastructure > of the framework, including winfo > and eventlists). > > I concur. Ever existing event package is defined to work only with SUBSCRIBE dialogs. For any of those that needs to work with INVITE dialogs, we'd need a an RFC defininging (and IANA registering) the new behavior. Future event packages would have the option of defining and registering only INVITE dialog usage, only SUBSCRIBE dialog usages, or both. > And we'd need to specify quite concretely what happens when one of > these INFOs gets rejected. > In most cases, the call is going to have to go away, and I bet > that's going to make a lot of people unhappy. Yes, that's definitely a point to document. I'm not sure I agree that a failure-to-grok-a-body response terminates the dialog, but am open to discussion. -- 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 26 10:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQJ9-0004av-Cy; Fri, 26 Oct 2007 10:37:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQJ7-0004aE-Ae for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:37:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQJ7-0004Zz-0J for sip@ietf.org; Fri, 26 Oct 2007 10:37:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQJ6-0004M9-KF for sip@ietf.org; Fri, 26 Oct 2007 10:37:04 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9QEb1Z9029144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 09:37:03 -0500 In-Reply-To: <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 09:36:56 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Oct 25, 2007, at 4:59 PM, Robert Sparks wrote: > And there we go... not even 20 minutes. > > So, you are right for INFO as we have historically known it. > > This new gorgon that Dean is proposing is not like that INFO. > > It's something that's carrying state based on (effectively) an > implicit subscription (or something very much like a subscription, > but without any of the control infrastructure) in the INVITE. I'd like to point out, it is not an implicit subscription. It's explicit. The event package usage was negotiated in the INVITE transaction. So even if we followed the current dialog usage model and terminated the dialog, that would arguably be a reasonable thing to do. The failure-to-understand a body means that there was a failure in the offer/answer exchange for the event package, and somebody needs to know about it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 26 10:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQRU-0001jV-6R; Fri, 26 Oct 2007 10:45:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQRS-0001j7-Va for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQRS-0001gj-Kf for sip@ietf.org; Fri, 26 Oct 2007 10:45:42 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlQRR-0007gX-Aa for sip@ietf.org; Fri, 26 Oct 2007 10:45:42 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9QEj9b8097346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2007 09:45:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 09:45:01 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4600/Fri Oct 26 09:02:30 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Oct 26, 2007, at 9:36 AM, Dean Willis wrote: > > On Oct 25, 2007, at 4:59 PM, Robert Sparks wrote: > >> And there we go... not even 20 minutes. >> >> So, you are right for INFO as we have historically known it. >> >> This new gorgon that Dean is proposing is not like that INFO. >> >> It's something that's carrying state based on (effectively) an >> implicit subscription (or something very much like a subscription, >> but without any of the control infrastructure) in the INVITE. > > I'd like to point out, it is not an implicit subscription. It's > explicit. The event package usage was negotiated in the INVITE > transaction. So even if we followed the current dialog usage model > and terminated the dialog, that would arguably be a reasonable > thing to do. The failure-to-understand a body means that there was > a failure in the offer/answer exchange for the event package, and > somebody needs to know about it. It's just as implicit as the subscription to the refer event package is when you accept a REFER, and it's going to suffer from exactly the same problems we have there. So, what's the duration? How do you unsubscribe? How do you learn about your permissions to subscribe to the thing (pending vs active vs denied)? I'm not really asking for that design right now, just pointing out these as examples of the questions that the _implicit_ subscription you're talking about would have to address - and remember the hairier ones after that, like how you cause a full-state notify to happen if you get out of sync in some partial scheme. > > -- > 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 26 11:12:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQpj-00029X-GO; Fri, 26 Oct 2007 11:10:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlQph-00027A-PC for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 11:10:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQph-000271-F0 for sip@ietf.org; Fri, 26 Oct 2007 11:10:45 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlQph-0005eN-4d for sip@ietf.org; Fri, 26 Oct 2007 11:10:45 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9QFAh5H098703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2007 10:10:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4722036E.5090009@nostrum.com> Date: Fri, 26 Oct 2007 10:10:38 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> In-Reply-To: <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4600/Fri Oct 26 09:02:30 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Future event packages would have the option of defining and > registering only INVITE dialog usage, only SUBSCRIBE dialog usages, or > both. But even having a structure that encourages that kind of thinking is bad hygiene. Having more than one way to do the same thing in a protocol is the fastest and most powerful way to simultaneously decrease interoperability and increase implementation burden. Implementations need to either include all possible mechanisms (I just love telling developers that they get to do RFC 4733, KPML, *and* INFO if they want to convey DTMF), or they end up not working with everything out there. Either outcome is seriously unfortunate. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 26 11:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlR5c-00059e-1V; Fri, 26 Oct 2007 11:27:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlR5a-00059Y-5y for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 11:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlR5Z-00059Q-Sk for sip@ietf.org; Fri, 26 Oct 2007 11:27:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlR5Y-00010z-Lf for sip@ietf.org; Fri, 26 Oct 2007 11:27:09 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2007 08:27:08 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QFR6Pe018635; Fri, 26 Oct 2007 08:27:06 -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 l9QFR5PZ006336; Fri, 26 Oct 2007 15:27:06 GMT 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.1830); Fri, 26 Oct 2007 11:27:01 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:27:00 -0400 Message-ID: <47220744.2040406@cisco.com> Date: Fri, 26 Oct 2007 11:27:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 15:27:00.0823 (UTC) FILETIME=[A7618E70:01C817E4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--19.592500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2836; t=1193412426; x=1194276426; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20; bh=Emzw8eUxmG3pG+2vgStrmYUKcfqy0ZwLNXTeKLMa+Nk=; b=LUW3gx+t6vGjZSOG8WetoNlU/LhjpRBoR7SVPeCEotOUxEXcc0yXBMQwJXmUfcxlsi3fL5G1 v9+X97eWZdzk8vVDWfngdx9IHgg7fhbCZQKyDUxHixzVqOgrI9Q2GMaU; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > > On Oct 26, 2007, at 9:36 AM, Dean Willis wrote: > >> >> On Oct 25, 2007, at 4:59 PM, Robert Sparks wrote: >> >>> And there we go... not even 20 minutes. >>> >>> So, you are right for INFO as we have historically known it. >>> >>> This new gorgon that Dean is proposing is not like that INFO. >>> >>> It's something that's carrying state based on (effectively) an >>> implicit subscription (or something very much like a subscription, >>> but without any of the control infrastructure) in the INVITE. >> >> I'd like to point out, it is not an implicit subscription. It's >> explicit. The event package usage was negotiated in the INVITE >> transaction. So even if we followed the current dialog usage model and >> terminated the dialog, that would arguably be a reasonable thing to >> do. The failure-to-understand a body means that there was a failure in >> the offer/answer exchange for the event package, and somebody needs to >> know about it. > > It's just as implicit as the subscription to the refer event package is > when you accept a REFER, and it's going to suffer from exactly the same > problems we have there. I agree with dean that it is explicit. It is a "subscription" in the broad sense, but not in the 3265 sense. A formalism for its properties will be needed, but we haven't settled on that yet. IMO it isn't like an implicit REFER subscription. Instead of a new dialog usage sharing the same dialog, we end up with some added behavior within the invite dialog usage. I do agree that we must tread carefully here because we are creating a new kind of thing that we didn't have before. And it could have unintended consequences, just as turned out to be the case with multiple dialog usages sharing a dialog. > So, what's the duration? How do you unsubscribe? How do you learn about > your permissions to subscribe to the thing (pending vs active vs > denied)? I'm not really asking for that design right now, just pointing > out these as examples of the questions that the _implicit_ subscription > you're talking about would have to address - and remember the hairier > ones after that, like how you cause a full-state notify to happen if you > get out of sync in some partial scheme. These are all good questions that need to be answered. It may indeed turn out that after all those things are considered it will be apparent that the whole thing is a bad idea. I expect that what people are looking for is simplicity. Namely, when an issue such as you mention starts to have a difficult answer then the solution is to limit applicability to avoid the problem. But if it turns out that the simplifications exclude all interesting uses then again we pack up and go home. Thanks, 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 26 11:39:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRF8-00051F-Sz; Fri, 26 Oct 2007 11:37:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlRF6-0004pB-3f for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 11:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRF5-0004nb-Pt for sip@ietf.org; Fri, 26 Oct 2007 11:36:59 -0400 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 1IlRF4-0001MN-I8 for sip@ietf.org; Fri, 26 Oct 2007 11:36:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2007 08:36:54 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9QFaqTS028091; Fri, 26 Oct 2007 08:36:52 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9QFamJr025572; Fri, 26 Oct 2007 15:36:48 GMT 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.1830); Fri, 26 Oct 2007 11:36:48 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 11:36:47 -0400 Message-ID: <4722098D.9020803@cisco.com> Date: Fri, 26 Oct 2007 11:36:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> <4722036E.5090009@nostrum.com> In-Reply-To: <4722036E.5090009@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 15:36:47.0300 (UTC) FILETIME=[04F2D840:01C817E6] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--25.881000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1735; t=1193413012; x=1194277012; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20; bh=soePcbGb3qk4GkKd/vBvSm22c68uc/gp8KdgohvMuuM=; b=jMsj1JRu4ieWhZQ96FlUrLp2qB5FH50PYRbdNz7nNjuHAXGhDrfwFk7/k5k3VeZzAJvICFPo 6xdY55ab+AMhC6BA0ZaQDz/EH/pB0Jm/TnUqXznWn/lA/ny5x5n0HnJX; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Adam, I agree with you on this. And yet people keep using all these different things for DTMF, with KPML apparently last in the running. I know my employer currently implements at least *two* non-standard mechanisms for DTMF, plus 4733, in a number of products. Even if we came up with a standard way that had the message conserving properties that seem to be required, it would then it would have to be added along side those. Perhaps we need a discussion specifically about DTMF - what is happening in the real world, and what the chances are for improving that situation. (Sounds like a bar BOF to me.) Paul Adam Roach wrote: > Dean Willis wrote: >> Future event packages would have the option of defining and >> registering only INVITE dialog usage, only SUBSCRIBE dialog usages, or >> both. > > But even having a structure that encourages that kind of thinking is bad > hygiene. Having more than one way to do the same thing in a protocol is > the fastest and most powerful way to simultaneously decrease > interoperability and increase implementation burden. > > Implementations need to either include all possible mechanisms (I just > love telling developers that they get to do RFC 4733, KPML, *and* INFO > if they want to convey DTMF), or they end up not working with everything > out there. Either outcome is seriously unfortunate. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 26 13:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSre-0007ee-Pw; Fri, 26 Oct 2007 13:20:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlSre-0007eZ-3c for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 13:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSrd-0007eR-QR for sip@ietf.org; Fri, 26 Oct 2007 13:20:53 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlSrc-0005EK-GV for sip@ietf.org; Fri, 26 Oct 2007 13:20:53 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9QHKbxf006072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2007 12:20:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472221E0.8040406@nostrum.com> Date: Fri, 26 Oct 2007 12:20:32 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> <4722036E.5090009@nostrum.com> <4722098D.9020803@cisco.com> In-Reply-To: <4722098D.9020803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4600/Fri Oct 26 09:02:30 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I agree with you on this. And yet people keep using all these > different things for DTMF, with KPML apparently last in the running. DTMF provides a powerful cautionary tale, but it wasn't the point I was trying to make. If we encourage two ways to do things (INFO and NOTIFY) for future event packages, this problem will spread beyond DTMF, into a variety of new specifications. So, to make sure I understand what you're agreeing with me on: are you specifically agreeing that the arguments I'm making point to needing separate namespaces for event packages and INFO packages? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 26 13:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTDI-0005RU-6c; Fri, 26 Oct 2007 13:43:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlTDB-0005RN-82 for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 13:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTD6-0005Qn-Lp for sip@ietf.org; Fri, 26 Oct 2007 13:43:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlTD2-0005yM-Tv for sip@ietf.org; Fri, 26 Oct 2007 13:43:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2007 10:43:00 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9QHgvbT022054; Fri, 26 Oct 2007 10:42:57 -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 l9QHgTm1011158; Fri, 26 Oct 2007 17:42:51 GMT 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.1830); Fri, 26 Oct 2007 13:42:37 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 13:42:37 -0400 Message-ID: <4722270E.50207@cisco.com> Date: Fri, 26 Oct 2007 13:42:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> <4722036E.5090009@nostrum.com> <4722098D.9020803@cisco.com> <472221E0.8040406@nostrum.com> In-Reply-To: <472221E0.8040406@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 17:42:37.0170 (UTC) FILETIME=[99059520:01C817F7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--15.619600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1006; t=1193420577; x=1194284577; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20; bh=qkuUOuqDqZobIMwgVLekDc1CTTH/vfO5KFxQjus+TGw=; b=cBF4ddQg7MYV+ZfvLse6uAIDxLxZ/wttpuH5tuYlnnkFhgu76cFCfd97LJtD0+KoEAkFm8Jd DoML2eAGZqPelXALMzKVmYQU5og4Qj6EKFBQiS4gAD/4BGJzilm3sE0OGLBCHdK1Ssn8SziyJA ATwRGQ45bsGUS06RchuZUuej0=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Adam Roach wrote: > Paul Kyzivat wrote: >> I agree with you on this. And yet people keep using all these >> different things for DTMF, with KPML apparently last in the running. > > DTMF provides a powerful cautionary tale, but it wasn't the point I was > trying to make. If we encourage two ways to do things (INFO and NOTIFY) > for future event packages, this problem will spread beyond DTMF, into a > variety of new specifications. > > So, to make sure I understand what you're agreeing with me on: are you > specifically agreeing that the arguments I'm making point to needing > separate namespaces for event packages and INFO packages? I'm agreeing with you that having multiple ways of doing things has negative consequences. I'm not necessarily agreeing that those consequences mean we should not do this, because we currently have multiple *unstandardized* ways of doing things and if we can turn that into standardized ways it might make things 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 26 14:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTzq-0000rW-QF; Fri, 26 Oct 2007 14:33:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlTzn-0000Cq-FS for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 14:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlTzm-0008WI-O5 for sip@ietf.org; Fri, 26 Oct 2007 14:33:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlTzg-0007mt-Gs for sip@ietf.org; Fri, 26 Oct 2007 14:33:22 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9QIWeR26873; Fri, 26 Oct 2007 18:32:41 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 13:31:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgX5IOfKsPmiGchRWW2GMKNTm+MugAGbkFw References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> From: "Francois Audet" To: "Robert Sparks" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach 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: , Errors-To: sip-bounces@ietf.org =20 > So, what's the duration? How do you unsubscribe? Isn't the whole point of this proposal that it would linked to be the duration of the dialog? Otherwise, you would just SUBSCRIBE. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 14:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUEj-0004mg-Q9; Fri, 26 Oct 2007 14:48:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlUEh-0004l1-Vf for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 14:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUEh-0004kt-ME for sip@ietf.org; Fri, 26 Oct 2007 14:48:47 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUEg-0008F3-CB for sip@ietf.org; Fri, 26 Oct 2007 14:48:47 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9QImOWA014202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2007 13:48:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 13:48:16 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4600/Fri Oct 26 09:02:30 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org So, the thing we're talking about then is not a subscription. (You will not use the same code to service it that you would have used to service a subcription). And if you accept that the fates are tightly coupled (as I think you are asserting here), then we _don't_ have separate usages that spring into being and disappear at the same time. There's only one usage - the INVITE usage. And forgive me for continuing to point, but are you going to address the authorization mechanics and if not, what are the simplifying assumptions that let us ignore them. RjS On Oct 26, 2007, at 1:31 PM, Francois Audet wrote: > >> So, what's the duration? How do you unsubscribe? > > Isn't the whole point of this proposal that it would linked to be the > duration of the dialog? > > Otherwise, you would just SUBSCRIBE. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 14:54:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUIz-0000yw-Lw; Fri, 26 Oct 2007 14:53:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlUIy-0000xo-Lp for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 14:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlUIy-0000oV-72 for sip@ietf.org; Fri, 26 Oct 2007 14:53:12 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlUIq-0008OE-KB for sip@ietf.org; Fri, 26 Oct 2007 14:53:11 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9QIqJH21640; Fri, 26 Oct 2007 18:52:20 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 13:52:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12CB0443@zrc2hxm0.corp.nortel.com> In-Reply-To: <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgYANjV3VZUYs18RACAWn9R+HfbXAAAC07w References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Friday, October 26, 2007 11:48 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; Sanjay Sinha (sanjsinh); sip List; Adam Roach > Subject: Re: [Sip] INFO: A recap, sense of consensus and a=20 > proposal for direction. >=20 > So, the thing we're talking about then is not a subscription. > (You will not use the same code to service it that you would=20 > have used to service a subcription). Fair enough. > And if you accept that the fates are tightly coupled (as I=20 > think you are asserting here), then we _don't_ have separate=20 > usages that spring into being and disappear at the same time.=20 > There's only one usage - the INVITE usage. Agree. > And forgive me for continuing to point, but are you going to=20 > address the authorization mechanics and if not, what are the=20 > simplifying assumptions that let us ignore them. I don't know.=20 Again, I'm not the one pushing for this :^) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 18:11:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXIJ-0000kb-TI; Fri, 26 Oct 2007 18:04:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlXII-0000k5-Fn for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 18:04:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXII-0000ii-4E for sip@ietf.org; Fri, 26 Oct 2007 18:04:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlXIH-00019D-HJ for sip@ietf.org; Fri, 26 Oct 2007 18:04:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,335,1188802800"; d="scan'208";a="13534984" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2007 15:04:40 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9QM4daW026319; Fri, 26 Oct 2007 18:04:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9QM4PdS002447; Fri, 26 Oct 2007 22:04:35 GMT 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.1830); Fri, 26 Oct 2007 18:04:31 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 18:04:31 -0400 Message-ID: <4722646D.7080302@cisco.com> Date: Fri, 26 Oct 2007 18:04:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> In-Reply-To: <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 22:04:31.0317 (UTC) FILETIME=[2F622050:01C8181C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--27.812700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2251; t=1193436279; x=1194300279; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20 |To:=20Robert=20Sparks=20; bh=tpr+RhLfZbCIHIf3mbSue39kAcq3z+L6DBLD9B393hY=; b=N2/lPIOo83nqqY1qCnlcXSc++G/mmVnMYbF/NeWEZd6K+v1/CNS5nq+hMf3KJ3DjPULOMtkT ZZucTA3NayquusY6g/2TCuwnMO4qWq5mqG0fnW0n7zA0EqNnlGJKWvCx; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Francois Audet , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > So, the thing we're talking about then is not a subscription. > (You will not use the same code to service it that you would have used > to service a subcription). Certainly the negotiation and establishment parts are different. It is possible that the code used to determine when to send a notification, and to process an incoming in-dialog notification, could be the same for some event types. That of course would only make sense if both forms were supported by a given UA for a particular event type. And it would only be true if the implementation *chose* to do it that way. Its clearly a local implementation issue. > And if you accept that the fates are tightly coupled (as I think you are > asserting here), then we > _don't_ have separate usages that spring into being and disappear at the > same time. There's only > one usage - the INVITE usage. Yes, I think so. That is the essential simplification that might make this attractive to some people. > And forgive me for continuing to point, but are you going to address the > authorization mechanics and if not, what are the simplifying assumptions > that let us ignore them. Well, of course it is the same UAC and UAS, so some authorization is in common. But it is true that someone might be permitted to make a call, but not to have access to the event data. In that case I think it is simply a matter of not negotiating the capability if it isn't authorized. In that case I guess it is a simplification in that there is no way to indicate that forbidden rather than unsupported. Paul > RjS > > On Oct 26, 2007, at 1:31 PM, Francois Audet wrote: > >> >>> So, what's the duration? How do you unsubscribe? >> >> Isn't the whole point of this proposal that it would linked to be the >> duration of the dialog? >> >> Otherwise, you would just SUBSCRIBE. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 18:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXTm-00082L-OD; Fri, 26 Oct 2007 18:16:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlXTl-0007zh-ED for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 18:16:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXTl-0007zZ-35 for sip@ietf.org; Fri, 26 Oct 2007 18:16:33 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlXTk-0001Ul-GD for sip@ietf.org; Fri, 26 Oct 2007 18:16:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D899C201DE; Sat, 27 Oct 2007 00:16:31 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-eb-4722673f9a9b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C28B1200E7; Sat, 27 Oct 2007 00:16:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Oct 2007 00:16:31 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Sat, 27 Oct 2007 00:13:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgYAXybguV+mIfWQaiaHeGod+H0qgAG+kjD References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com><63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com><9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com><1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "Francois Audet" X-OriginalArrivalTime: 26 Oct 2007 22:16:31.0662 (UTC) FILETIME=[DCBE0CE0:01C8181D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Hi, >So, the thing we're talking about then is not a subscription. >(You will not use the same code to service it that you would have=20 >used to service a subcription). It's not a subscription usage as defined today. >And if you accept that the fates are tightly coupled (as I think you=20 >are asserting here), then we_don't_ have separate usages that spring = into being and disappear at=20 >the same time. There's only one usage - the INVITE usage. Yes! I don't know how many times I've said that :) >And forgive me for continuing to point, but are you going to address=20 >the authorization mechanics and if not, what are the simplifying=20 >assumptions that let us ignore them. I guess we would need to think about that, but my first answer would be = that we don't need any additional mechanisms than what we already have = for the invite dialog. Regards, Christer =20 =20 RjS On Oct 26, 2007, at 1:31 PM, Francois Audet wrote: > >> So, what's the duration? How do you unsubscribe? > > Isn't the whole point of this proposal that it would linked to be the > duration of the dialog? > > Otherwise, you would just SUBSCRIBE. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 18:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXcH-0003P9-3J; Fri, 26 Oct 2007 18:25:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlXcG-0003On-9u for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 18:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXcG-0003O4-02 for sip@ietf.org; Fri, 26 Oct 2007 18:25:20 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlXcE-0007BQ-Lf for sip@ietf.org; Fri, 26 Oct 2007 18:25:19 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9QMOodE025331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2007 17:24:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4722646D.7080302@cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> <4722646D.7080302@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9502BA00-7CAF-4BE0-AB1A-156DF0611864@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 17:24:43 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4600/Fri Oct 26 09:02:30 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Francois Audet , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org On Oct 26, 2007, at 5:04 PM, Paul Kyzivat wrote: > > > Robert Sparks wrote: >> So, the thing we're talking about then is not a subscription. >> (You will not use the same code to service it that you would have >> used to service a subcription). > > Certainly the negotiation and establishment parts are different. > > It is possible that the code used to determine when to send a > notification, and to process an incoming in-dialog notification, > could be the same for some event types. > > That of course would only make sense if both forms were supported > by a given UA for a particular event type. And it would only be > true if the implementation *chose* to do it that way. Its clearly a > local implementation issue. > I disagree - you are, I think, pointing to potential code reuse for dealing with the payload of a NOTIFY. The code that is involved in dealing with the NOTIFY itself is not going to be reusable. Most, if not _all_ of the code for dealing with a _subscription_ will likely not be reusable. That code _has_ to assume the mechanics of a subscription. (A NOTIFY updates the timer for how long a subscription lasts - that notion is gone). >> And if you accept that the fates are tightly coupled (as I think >> you are asserting here), then we >> _don't_ have separate usages that spring into being and disappear >> at the same time. There's only >> one usage - the INVITE usage. > > Yes, I think so. That is the essential simplification that might > make this attractive to some people. > >> And forgive me for continuing to point, but are you going to >> address the authorization mechanics and if not, what are the >> simplifying assumptions that let us ignore them. > > Well, of course it is the same UAC and UAS, so some authorization > is in common. But it is true that someone might be permitted to > make a call, but not to have access to the event data. That would well be the normal case for most of the event packages that are currently defined (More evidence that its probably not going to be the case that the packages for this thing and the packages for events are going to closely line up). > > In that case I think it is simply a matter of not negotiating the > capability if it isn't authorized. In that case I guess it is a > simplification in that there is no way to indicate that forbidden > rather than unsupported. > > Paul > >> RjS >> On Oct 26, 2007, at 1:31 PM, Francois Audet wrote: >>> >>>> So, what's the duration? How do you unsubscribe? >>> >>> Isn't the whole point of this proposal that it would linked to be >>> the >>> duration of the dialog? >>> >>> Otherwise, you would just SUBSCRIBE. >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 26 18:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXbz-0002zT-5h; Fri, 26 Oct 2007 18:25:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlXbx-0002zL-2X for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 18:25:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlXbw-0002zB-Nf for sip@ietf.org; Fri, 26 Oct 2007 18:25:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlXbw-0001jJ-1q for sip@ietf.org; Fri, 26 Oct 2007 18:25:00 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7B127201F8; Sat, 27 Oct 2007 00:24:59 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-80-472269375616 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4EA392006B; Sat, 27 Oct 2007 00:24:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Oct 2007 00:24:55 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Sat, 27 Oct 2007 00:24:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgX5s62RJpndOZPQ66mRKQbUOq7aQANxmM7 References: <01FB5E7E-41BB-4133-8DF9-9F056F75F47D@softarmor.com> <4720F739.30406@nostrum.com> <9EBAEF40-32B9-4D78-9B58-EBB89C13C01C@softarmor.com> <4722036E.5090009@nostrum.com> <4722098D.9020803@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 26 Oct 2007 22:24:55.0261 (UTC) FILETIME=[08E928D0:01C8181F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Hi, >I agree with you on this. And yet people keep using all these different >things for DTMF, with KPML apparently last in the running. > >I know my employer currently implements at least *two* non-standard >mechanisms for DTMF, plus 4733, in a number of products. Even if we = came >up with a standard way that had the message conserving properties that >seem to be required, it would then it would have to be added along side >those. =20 Correct - what is already out there is most going to stay out there - = and there is nothing we can do about that (writing a = you-must-not-do-that-RFC won't help). But, if we can provide a more = simple way of doing things we will hopefully then see more and more = deployments using it. >Perhaps we need a discussion specifically about DTMF - what is = happening in the real world, and what the chances are for >improving = that situation. =20 Finally someone who agrees with me that there is a real world outside = our Hilton meeting rooms :) =20 > (Sounds like a bar BOF to me.) =20 If the outcome of such bar BOF is simply going to be a = we-need-to-go-out-and-make-people-understand-that-they-have-to-implement-= RFC-xxx type of statement it's not going to be very useful. Regards, =20 Christer =20 Paul Adam Roach wrote: > Dean Willis wrote: >> Future event packages would have the option of defining and >> registering only INVITE dialog usage, only SUBSCRIBE dialog usages, = or >> both. > > But even having a structure that encourages that kind of thinking is = bad > hygiene. Having more than one way to do the same thing in a protocol = is > the fastest and most powerful way to simultaneously decrease > interoperability and increase implementation burden. > > Implementations need to either include all possible mechanisms (I just > love telling developers that they get to do RFC 4733, KPML, *and* INFO > if they want to convey DTMF), or they end up not working with = everything > out there. Either outcome is seriously unfortunate. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Oct 27 00:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilcln-00043J-BF; Fri, 26 Oct 2007 23:55:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ilclm-000403-Ja for sip-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 23:55:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilclm-0003S2-6s for sip@ietf.org; Fri, 26 Oct 2007 23:55:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ilclh-0000Qu-Os for sip@ietf.org; Fri, 26 Oct 2007 23:55:26 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9R3tKXJ004680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 22:55:22 -0500 In-Reply-To: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 22:55:13 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Oct 26, 2007, at 9:45 AM, Robert Sparks wrote: > > On Oct 26, 2007, at 9:36 AM, Dean Willis wrote: > >> >> On Oct 25, 2007, at 4:59 PM, Robert Sparks wrote: >> >>> And there we go... not even 20 minutes. >>> >>> So, you are right for INFO as we have historically known it. >>> >>> This new gorgon that Dean is proposing is not like that INFO. >>> >>> It's something that's carrying state based on (effectively) an >>> implicit subscription (or something very much like a >>> subscription, but without any of the control infrastructure) in >>> the INVITE. >> >> I'd like to point out, it is not an implicit subscription. It's >> explicit. The event package usage was negotiated in the INVITE >> transaction. So even if we followed the current dialog usage model >> and terminated the dialog, that would arguably be a reasonable >> thing to do. The failure-to-understand a body means that there was >> a failure in the offer/answer exchange for the event package, and >> somebody needs to know about it. > > It's just as implicit as the subscription to the refer event > package is when you accept a REFER, and it's going to suffer from > exactly the same problems we have there. > > So, what's the duration? Until the dialog ends. > How do you unsubscribe? BYE. > How do you learn about your permissions to subscribe to the thing > (pending vs active vs denied)? You don't. Either stuff shows up, or it doesn't. Or, put another way, the other end TOLD you that you were authorized when it made the offer. There is no "pending", no "denied". > I'm not really asking for that design right now, just pointing out > these as examples of the questions that the _implicit_ subscription > you're talking about would have to address - and remember the > hairier ones after that, like how you cause a full-state notify to > happen if you get out of sync in some partial scheme. BYE. INVITE. Seriously, this stuff only makes sense for fairly atomic events. Partial notification just doesn't compute. That's why it would be silly to say it works for all event packages. -- 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 27 00:06:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlcsX-0004vH-0G; Sat, 27 Oct 2007 00:02:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IlcsV-0004ue-MM for sip-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 00:02:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlcsV-0004uW-BY for sip@ietf.org; Sat, 27 Oct 2007 00:02:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlcsU-0000ZJ-VA for sip@ietf.org; Sat, 27 Oct 2007 00:02:27 -0400 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9R42N4a004728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Oct 2007 23:02:25 -0500 In-Reply-To: <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Fri, 26 Oct 2007 23:02:17 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Francois Audet , Adam Roach 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: , Errors-To: sip-bounces@ietf.org On Oct 26, 2007, at 1:48 PM, Robert Sparks wrote: > So, the thing we're talking about then is not a subscription. Right. That's why I called it event notification within an INVITE- initiated dialog. > (You will not use the same code to service it that you would have > used to service a subcription). > Of course not. What it is is a negotiation mechanism for INFO. You'd use the same code for it that you used for servicing INFO. But now, each event-carrying message also has a naming component that tells you what you're supposed to be doing with the event notification. > And if you accept that the fates are tightly coupled (as I think > you are asserting here), then we > _don't_ have separate usages that spring into being and disappear > at the same time. There's only > one usage - the INVITE usage. > Yes, exactly. > And forgive me for continuing to point, but are you going to > address the authorization mechanics and if not, what are the > simplifying assumptions that let us ignore them. The authorization mechanics are obvious and simple. If you're authorized for the INVITE dialog, you're authorized for any event notifications offered within the INVITE transaction that instantiated the dialog. Or hey, if you decide the peer is unauthorized during a dialog, you either end it (with a BYE), or just stop sending the event notifications. If they were all that important, the other end will eventually send a BYE, right? -- 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 27 16:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ils4I-0003gW-PF; Sat, 27 Oct 2007 16:15:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ils4G-0003g9-V1 for sip-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 16:15:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ils4G-0003Zn-Jy for sip@ietf.org; Sat, 27 Oct 2007 16:15:36 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ils4B-0006e2-6o for sip@ietf.org; Sat, 27 Oct 2007 16:15:31 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Sat, 27 Oct 2007 16:15:30 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 27 Oct 2007 16:15:28 -0400 From: Hadriel Kaplan To: Robert Sparks , Francois Audet Date: Sat, 27 Oct 2007 16:15:22 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgYAZQPajd/5HhmQWCOIHC8Tl5DEgA0WrXw Message-ID: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF12CB0386@zrc2hxm0.corp.nortel.com> <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> In-Reply-To: <4F6D3011-D872-4129-80C9-2A5774FB3A11@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Sanjay Sinha \(sanjsinh\)" , sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Friday, October 26, 2007 2:48 PM > To: Francois Audet > Cc: Sanjay Sinha (sanjsinh); sip List; Adam Roach; Dean Willis > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > So, the thing we're talking about then is not a subscription. > (You will not use the same code to service it that you would have > used to service a subcription). Right, I think several of us have said it's not a subscription in the 3265 = sense of the word (and it's probably less confusing if we don't use the wor= d "subscription" at all). > And if you accept that the fates are tightly coupled (as I think you > are asserting here), then we > _don't_ have separate usages that spring into being and disappear at > the same time. There's only > one usage - the INVITE usage. Precisely. Exactly how INFO was used before. > And forgive me for continuing to point, but are you going to address > the authorization mechanics and if not, what are the simplifying > assumptions that let us ignore them. Actually I think it's clearer for this mechanism than it is for Subscriptio= ns. With Subscribe, I don't see how an Invite-generating UAC can truly aut= horize a subscriber as the UAS. It's clear how a server offering a subscri= ption service such as presence can do it, because the server should know wh= ich UA's can subscribe to its service, and can challenge them knowing the u= ser password or whatever. But how does my phone know any shared secret wit= h which to challenge some random entity subscribing to KPML for an Invite d= ialog? With this inline INFO mechanism, it would be based on the Invite. = If the UAC sent the Invite with the send/recv event headers, it's authorizi= ng the receiver of the Invite to send/recv them. If the UAS wants to accep= t the events, it responds with such headers. The INFO message would be han= dled the same way as re-Invites would, with regard to their acceptance. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 28 18:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImG9J-0001SU-A6; Sun, 28 Oct 2007 17:58:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImG9I-0001SB-2g for sip-confirm+ok@megatron.ietf.org; Sun, 28 Oct 2007 17:58:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImG9H-0001S1-Mp for sip@ietf.org; Sun, 28 Oct 2007 17:58:23 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImG9H-0003rf-Dq for sip@ietf.org; Sun, 28 Oct 2007 17:58:23 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9SLwLIa071792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Oct 2007 16:58:21 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472505F8.5090401@nostrum.com> Date: Sun, 28 Oct 2007 16:58:16 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> In-Reply-To: <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4616/Sun Oct 28 12:25:58 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "Sanjay Sinha \(sanjsinh\)" , 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Seriously, this stuff only makes sense for fairly atomic events. > Partial notification just doesn't compute. That's why it would be > silly to say it works for all event packages. You misspelled "any." /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Oct 28 23:48:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLWp-0000eh-29; Sun, 28 Oct 2007 23:43:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImLWn-0000bj-0S for sip-confirm+ok@megatron.ietf.org; Sun, 28 Oct 2007 23:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLWm-0000ak-MM for sip@ietf.org; Sun, 28 Oct 2007 23:43:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImLWh-0003Ez-DI for sip@ietf.org; Sun, 28 Oct 2007 23:43:00 -0400 Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9T3gc9H025334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 28 Oct 2007 22:42:39 -0500 In-Reply-To: <472505F8.5090401@nostrum.com> References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Date: Sun, 28 Oct 2007 22:42:30 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Sanjay Sinha \(sanjsinh\)" , 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: , Errors-To: sip-bounces@ietf.org On Oct 28, 2007, at 4:58 PM, Adam Roach wrote: > Dean Willis wrote: >> Seriously, this stuff only makes sense for fairly atomic events. >> Partial notification just doesn't compute. That's why it would be >> silly to say it works for all event packages. > > You misspelled "any." > No, I don't believe so. It would, for example, function quite well with MWI (although not be terribly useful). -- 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 29 00:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLtX-0007V7-3Z; Mon, 29 Oct 2007 00:06:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImLtV-0007Us-Ru for sip-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 00:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLtV-0007Ud-HQ for sip@ietf.org; Mon, 29 Oct 2007 00:06:29 -0400 Received: from log2.above.net.tw ([202.5.224.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImLtK-0004dY-MO for sip@ietf.org; Mon, 29 Oct 2007 00:06:29 -0400 Received: by log2.above.net.tw (Postfix, from userid 80) id 519086F6239; Mon, 29 Oct 2007 12:06:08 +0800 (CST) Received: from lab2.above.net.tw (lab2.above.net.tw [202.5.224.98]) by ms.above.net.tw (Horde MIME library) with HTTP for ; Mon, 29 Oct 2007 12:06:08 +0800 Message-ID: <20071029120608.16vubavuw4sskk84@ms.above.net.tw> Date: Mon, 29 Oct 2007 12:06:08 +0800 From: KevinKuei To: sip@ietf.org Subject: [sip] handling ACK for 2xx response in proxy?? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.10 X-ms.teltel.com.tw-MailScanner-Information: Please contact the ISP for more information X-ms.teltel.com.tw-MailScanner: Found to be clean X-ms.teltel.com.tw-MailScanner-From: kkuei@above.net.tw X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: sip-bounces@ietf.org Hello all, In RFC3261 sec.16, is there anywhere talking about stateful proxy handling ACK?? Since ACK for 2xx response is not send thru transaction, it should not be received by server transaction in proxy. Is that correct?? then.. how proxy core got ACK?? -- Kevin Kuei ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 29 00:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLxa-0000jK-BI; Mon, 29 Oct 2007 00:10:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImLxV-0000gz-Ii for sip-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 00:10:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImLxU-0000gS-PU for sip@ietf.org; Mon, 29 Oct 2007 00:10:36 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImLxO-0004s1-06 for sip@ietf.org; Mon, 29 Oct 2007 00:10:36 -0400 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9T4A7iC088731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Oct 2007 23:10:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <47255D1A.30206@nostrum.com> Date: Sun, 28 Oct 2007 23:10:02 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> In-Reply-To: <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4616/Sun Oct 28 12:25:58 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Sanjay Sinha \(sanjsinh\)" , 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: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Oct 28, 2007, at 4:58 PM, Adam Roach wrote: > >> Dean Willis wrote: >>> Seriously, this stuff only makes sense for fairly atomic events. >>> Partial notification just doesn't compute. That's why it would be >>> silly to say it works for all event packages. >> >> You misspelled "any." >> > > No, I don't believe so. It would, for example, function quite well > with MWI (although not be terribly useful). Which is pretty much my point. I assume you picked a useless example because there isn't a useful one. Is there anything better? Let's check the IANA registry. Conference? That doesn't seem to match you assertion that "partial notification just doesn't compute." Or are you thinking you'll be passing full conference state around in INFO? Dialog? No, you're in the dialog -- you know how it's going. KPML? That uses a lot of the SUBSCRIBE mechanics to set up what triggers notification. And if the endpoints are interested, send 2833/4733. MWI? I agree with what you say above -- not terribly useful. POC settings? You're in a call with the device -- it no longer matters whether it will auto answer or whether it's going to bar you from calling. REG? This gets heavily into the authorization questions Robert was raising (unless you're talking to yourself, in which case it's downright silly) -- and even if we blithely wave our hands at auth and say "send it if you like and don't send it if you don't," what is the use case? Why would someone do this? Refer? Spirits? Winfo? What would those even *mean*? We've been working on this for the past 7 years, and there's not a single reasonable proof of concept that what you're fighting so vigorously for has any practical application. The best example you can come up with is one you concede is useless. Robert has raised a host of reasonable concerns, and I've been pointing out additional sets of problems that arise from your proposal. We know the downsides, and they are non-trivial. To make a fair judgment, we need to balance those against the benefits. What are they? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 29 06:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImS2e-0002Y9-V7; Mon, 29 Oct 2007 06:40:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImS2d-0002XP-GP for sip-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 06:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImS2d-0002XH-6k; Mon, 29 Oct 2007 06:40:19 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImS2W-0006qe-Cw; Mon, 29 Oct 2007 06:40:19 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9TAe1o6341642; Mon, 29 Oct 2007 10:40:01 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9TAe1qG2338848; Mon, 29 Oct 2007 11:40:01 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9TAe1J2018210; Mon, 29 Oct 2007 11:40:01 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9TAe16J018198; Mon, 29 Oct 2007 11:40:01 +0100 To: rai@ietf.org, sip@ietf.org, MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Mon, 29 Oct 2007 12:39:59 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 29/10/2007 12:40:00, Serialize complete at 29/10/2007 12:40:00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Cc: Subject: [Sip] RAI review of draft-ietf-sip-hitchhikers-guide-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="===============1651329021==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1651329021== Content-Type: multipart/alternative; boundary="=_alternative 003A995AC2257383_=" This is a multipart message in MIME format. --=_alternative 003A995AC2257383_= Content-Type: text/plain; charset="US-ASCII" I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03 from the perspective of presence and the SIMPLE group but ended up in commenting on the whole document at the end. For background on RAI-ART, please see the FAQ at http://www.softarmor.com/rai/art/rai-art-FAQ.html Please resolve these comments along with any other Last Call comments you may receive. In my opinion this draft is basically ready for publication, but has nits that should be fixed before publication. Citations from the draft are marked by <<< text from draft >>> General comments ---------------- By its nature there are a lot of reference to drafts in the document. It will take a lot of time for these documents to become and RFC. So how we are going to publish this as an RFC? Since when the referenced drafts will become an RFC, this draft would have to be updated with new drafts, will it be held in the RFC ED queue for ever? How do we gauge the usage of an RFC or a draft? There are many places here that it is said that this or that RFC/draft got widely implemented or not. How it is measured? The wide implementation test is used to decide whether an RFC or draft are core or not and therefore there should be some text explaining how the wide implementation was determined. Better change RFC XXXX (before the reference number in []) to the name of the draft (with no version number), it will make the ride smoother. An introduction that details the various grouping should be added. It should include additional text on the group and what was the criteria for putting an RFC/draft in the group. 2. Scope of this Document -------------------------- <<< o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 >>> "to SIP itself" sounds vague. It will be better to say:"to RFC 3261" instead. Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus (or the president of the galaxy) and that RFCs/drafts mentioned in this document are based on their relation to it. <<< Excluded from this list are requirements, architectures, registry definitions, non-normative frameworks, and processes. Best Current Practices are included when they normatively define mechanisms for accomplishing a task. >>> "normatively define" not sure what is meant by normative with respect to BCP. Seems like a contradiction in terms. 3. Core SIP Specifications --------------------------- If we think on presence as eventually replacing registration, since it carries much more information about the availability of the user, should we consider also presence as a towel? <<< RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. It is the president of the galaxy [42] as far as the suite of SIP specifications is concerned. >>> RFC 3261 is a very big document. Should it be treated as one or it can be divided into parts in this document e.g. proxy, client etc.? I am not sure what would be better. 4. Public Switched Telephone Network (PSTN) Interworking --------------------------------------------------------- Regarding RFC 3578 Ugly in one corner of the galaxy may be beautiful on the other of it :-) 7. Minor Extensions -------------------- <<< RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] allows a UA sending a REFER to ask the recipient of the REFER to generate multiple SIP requests, not just one. This is useful for conferencing, where a client would like to ask a conference server to eject multiple users. >>> Should not this be referred to in the conferencing section also? <<< RFC 4483, A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for content indirection. Instead of carrying an object within a SIP body, a URL reference is carried instead, and the recipient dereferences the URL to obtain the object. The specification has potential applicability for sending large instant messages, but has yet to find much actual use. >>> The specification has also potential for sending large presence documents via a URL. <<< RFC 4583, Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a mechanism in SDP to signal floor control streams that use BFCP. It is used for Push-To-Talk and conference floor control. >>> Should not this be referred to in the conferencing section also? <<< RFC XXXX, Connectivity Preconditions for Session Description Protocol Media Streams (S): RFC XXXX [93] defines a usage of the precondition framework [59]. The connectivity precondition makes sure that the session doesn't get established until actual packet connectivity is checked. >>> Should not this be referred to in the QoS section also? 8. Conferencing ---------------- The Conferencing section should be before or after "Instant Messaging, Presence and Multimedia" as it is also an application. See the comment on whether presence is an application or not later. 10. Event Framework and Packages ---------------------------------- Suggest to divide this section to event framework section and to packages section. The event framework should include 3265, 3903, 4662 and subnot-etags which define the event framework itself. The other section will the packages sections that will list the packages. Alternatively, many of the packages are mentioned in their proper section so it may be that all the event packages can be fit into their relevant section and there is not a need for packages section. 11. Quality of Service ----------------------- <<< RFC 3313, Private SIP Extensions for Media Authorization (I): RFC 3313 [61] defines a P-header that provides a mechanism for passing an authorization token between SIP and a network QoS reservation protocol like RSVP. Its purpose is to make sure network QoS is only granted if a client has made a SIP call through the same providers network. This specification is sometimes referred to as the SIP walled garden specification by the truly paranoid androids in the SIP community. This is because it requires coupling of signaling and the underlying IP network. >>> Understand that being a "truly paranoid" is a virtue? :-) 15. Security Mechanisms ------------------------ Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474 (Identity) be mentioned here also? 16. Instant Messaging, Presence and Multimedia ----------------------------------------------- Maybe create an applications section and put also conferencing as a type of an application. Including presence here with IM and multimedia seems that presence is regarded as an additional type of media. I am not sure that I agree with this. Presence is an enabler for many other applications and it deserves a section of its own. It is very tempting to include the simple-simple content here (as an appendix?). If simple-simple is not to be included here, there should be at least a reference to simple-simple as for presence there are so many documents that are essential for doing presence and are not mentioned here (e.g. watcher format, RPID, presence rules, partial notify and publish and many many more). Roughly counting, there are about 20-25 RFCs/drafts that are very relevant to presence that are mentioned in simple-simple in addition to the ones that are mentioned here. The MSRP drafts seem to be forgotten? Thanks --Avshalom --=_alternative 003A995AC2257383_= Content-Type: text/html; charset="US-ASCII"
I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and the SIMPLE group but ended up in
commenting on the whole document at the end.

For background on RAI-ART, please see the FAQ at
http://www.softarmor.com/rai/art/rai-art-FAQ.html

Please resolve these comments along with any other Last Call comments
you may receive.

In my opinion this draft is basically ready for publication, but has
nits that should be fixed before publication.

Citations from the draft are marked by <<< text from draft >>>

General comments
----------------

By its nature there are a lot of reference to drafts in the document.
It will take a lot of time for these documents to become and RFC.
So how we are going to publish this as an RFC? Since when the
referenced drafts will become an RFC, this draft would have to be
updated with new drafts, will it be held in the
RFC ED queue for ever?

How do we gauge the usage of an RFC or a draft? There are many places
here that it is said that this or that RFC/draft got widely implemented
or not.
How it is measured? The wide implementation test is used to decide
whether an RFC or draft are core or not and therefore there should be
some text explaining how the wide implementation was determined.

Better change RFC XXXX (before the reference number in []) to the name
of the draft (with no version number), it will make the ride smoother.

An introduction that details the various grouping should be added. It
should include additional text on the group and what was the criteria
for putting an RFC/draft in the group.

2.  Scope of this Document
--------------------------

<<<
   o  Any specification that defines an extension to SIP itself, where
      an extension is a mechanism that changes or updates in some way a
      behavior specified in RFC 3261
>>>

"to SIP itself" sounds vague. It will be better to say:"to RFC 3261"
instead.
Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus
(or the president of the galaxy) and that RFCs/drafts mentioned in this
document are based on their relation to it.

<<<
   Excluded from this list are requirements, architectures, registry
   definitions, non-normative frameworks, and processes.  Best Current
   Practices are included when they normatively define mechanisms for
   accomplishing a task.
>>>
   
"normatively define" not sure what is meant by normative with
respect to BCP. Seems like a contradiction in terms.

3.  Core SIP Specifications
---------------------------

If we think on presence as eventually replacing registration, since it
carries much more information about the availability of the user,
should we consider also presence as a towel?

<<<
   RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1] is the
      core SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9].
      It is the president of the galaxy [42] as far as the suite of SIP
      specifications is concerned.
>>>

RFC 3261 is a very big document. Should it be treated as one or it can
be divided into parts in this document e.g. proxy, client etc.? I am not
sure what would be better.

4.  Public Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------

Regarding RFC 3578
Ugly in one corner of the galaxy may be beautiful on the other of it :-)

7.  Minor Extensions
--------------------

<<<
   RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
      allows a UA sending a REFER to ask the recipient of the REFER to
      generate multiple SIP requests, not just one.  This is useful for
      conferencing, where a client would like to ask a conference server
      to eject multiple users.
>>>

Should not this be referred to in the conferencing section also?

<<<
   RFC 4483, A Mechanism for Content Indirection in Session Initiation
   Protocol (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for
      content indirection.  Instead of carrying an object within a SIP
      body, a URL reference is carried instead, and the recipient
      dereferences the URL to obtain the object.  The specification has
      potential applicability for sending large instant messages, but
      has yet to find much actual use.
>>>

The specification has also potential for sending large presence
documents via a URL.

<<<
   RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a
      mechanism in SDP to signal floor control streams that use BFCP.
      It is used for Push-To-Talk and conference floor control.
>>>

Should not this be referred to in the conferencing section also?

<<<
   RFC XXXX, Connectivity Preconditions for Session Description Protocol
   Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
      framework [59].  The connectivity precondition makes sure that the
      session doesn't get established until actual packet connectivity
      is checked.
>>>

Should not this be referred to in the QoS section also?

8.  Conferencing
----------------

The Conferencing section should be before or after "Instant Messaging,
Presence and Multimedia" as it is also an application. See the comment
on whether presence is an application or not later.

10.  Event Framework and Packages
----------------------------------

Suggest to divide this section to event framework section and to
packages section. The event framework should include 3265, 3903, 4662
and subnot-etags which define the event framework itself.
The other section will the packages sections that will list the
packages.

Alternatively, many of the packages are mentioned in their proper
section so it may be that all the event packages can be fit into
their relevant section and there is not a need for packages section.

11.  Quality of Service
-----------------------

<<<
   RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
      3313 [61] defines a P-header that provides a mechanism for passing
      an authorization token between SIP and a network QoS reservation
      protocol like RSVP.  Its purpose is to make sure network QoS is
      only granted if a client has made a SIP call through the same
      providers network.  This specification is sometimes referred to as
      the SIP walled garden specification by the truly paranoid androids
      in the SIP community.  This is because it requires coupling of
      signaling and the underlying IP network.
>>>      

Understand that being a "truly paranoid" is a virtue? :-)

15.  Security Mechanisms
------------------------

Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474
(Identity) be mentioned here also?    

16.  Instant Messaging, Presence and Multimedia
-----------------------------------------------

Maybe create an applications section and put also conferencing as a type
of an application.

Including presence here with IM and multimedia seems that presence is
regarded as an additional type of media. I am not sure that I agree with
this. Presence is an enabler for many other applications and it deserves
a section of its own.

It is very tempting to include the simple-simple content here
(as an appendix?). If simple-simple is not to be included here, there
should be at least a reference to simple-simple as for presence
there are so many documents that are essential for doing presence and
are not mentioned here (e.g. watcher format, RPID, presence rules,
partial notify and publish and many many more). Roughly counting, there
are about 20-25 RFCs/drafts that are very relevant to presence that are
mentioned in simple-simple in addition to the ones that are mentioned here.

The MSRP drafts seem to be forgotten?

Thanks
--Avshalom
 --=_alternative 003A995AC2257383_=-- --===============1651329021== 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 --===============1651329021==-- From sip-bounces@ietf.org Mon Oct 29 07:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSSg-0000Ez-1m; Mon, 29 Oct 2007 07:07:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImSSd-0000Ep-W6 for sip-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 07:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSSd-0000EH-Mb for sip@ietf.org; Mon, 29 Oct 2007 07:07:11 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImSST-0008CW-A1 for sip@ietf.org; Mon, 29 Oct 2007 07:07:07 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4FF911805C for ; Mon, 29 Oct 2007 16:36:44 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 40A4F18053 for ; Mon, 29 Oct 2007 16:36:44 +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.3959); Mon, 29 Oct 2007 16:36:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] handling ACK for 2xx response in proxy?? Date: Mon, 29 Oct 2007 16:35:37 +0530 Message-ID: <01949ABCDD38EF4A95B8C347C399D1CE059D2E5C@BLR-EC-MBX02.wipro.com> In-Reply-To: <20071029120608.16vubavuw4sskk84@ms.above.net.tw> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip] handling ACK for 2xx response in proxy?? Thread-Index: AcgZ4fdMN1gmp1OyS4eGx4pzZZdxJAAOIkPQ From: To: , X-OriginalArrivalTime: 29 Oct 2007 11:06:44.0076 (UTC) FILETIME=[CA5052C0:01C81A1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: sip-bounces@ietf.org Comments inline... Thanks, Nataraju A B -----Original Message----- From: KevinKuei [mailto:kkuei@above.net.tw]=20 Sent: Monday, October 29, 2007 9:36 AM To: sip@ietf.org Subject: [sip] handling ACK for 2xx response in proxy?? Hello all, In RFC3261 sec.16, is there anywhere talking about stateful proxy handling ACK?? Since ACK for 2xx response is not send thru transaction, it should not be received by server transaction in proxy. Is that correct?? then.. how proxy core got ACK?? [ABN] the ACK message received by proxy would always be statelessly forwarded to downstream. This does not mean that a transaction is created for handling the ACK message. ACK message sent to TPT directly(by ua/proxy core) and received by core directly from TPT. -- Kevin Kuei ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 29 11:35:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWcj-0002vB-56; Mon, 29 Oct 2007 11:33:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImWci-0002uZ-07 for sip-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 11:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWch-0002uO-Mk; Mon, 29 Oct 2007 11:33:51 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImWcg-0005HD-AQ; Mon, 29 Oct 2007 11:33:51 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l9TFXXbx054771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2007 10:33:33 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0DFE7466-C622-4CB1-8C10-7CB5AF136540@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , sipping LIST , SIMPLE mailing list , sip-implementors@lists.cs.columbia.edu, discussion@sipforum.org From: Robert Sparks Date: Mon, 29 Oct 2007 10:33:24 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] SIPit 21 registration closes today 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: , Errors-To: sip-bounces@ietf.org SIPit 21 registration closes today. If you plan to attend, but have not registered, please do so immediately. See www.sipit.net for more information and the registration link. Thanks, and see you in Beijing next Monday! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 30 04:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm2f-0004oa-4Z; Tue, 30 Oct 2007 04:01:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Imm2d-0004oP-IU for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:01:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm2d-0004oE-55; Tue, 30 Oct 2007 04:01:39 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imm2b-0000ir-4t; Tue, 30 Oct 2007 04:01:39 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l9U80tZu022576; Tue, 30 Oct 2007 03:01:30 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 03:01:19 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:01:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Oct 2007 09:01:17 +0100 Message-ID: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgaGKH+zp3EvtG8TLeDyez69R12VQAQbavA References: From: "DRAGE, Keith \(Keith\)" To: "Avshalom Houri" , , , X-OriginalArrivalTime: 30 Oct 2007 08:01:17.0289 (UTC) FILETIME=[0CA51D90:01C81ACB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ea58f9afed4c81098229b1759fb296b Cc: Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-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="===============0590822343==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0590822343== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81ACB.0C8D750B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81ACB.0C8D750B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As WG chair) =20 Just a note that I should have included with the WGLC. =20 The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so). =20 The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version. =20 regards =20 Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Monday, October 29, 2007 10:40 AM To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03=20 from the perspective of presence and the SIMPLE group but ended up in=20 commenting on the whole document at the end.=20 =09 For background on RAI-ART, please see the FAQ at=20 http://www.softarmor.com/rai/art/rai-art-FAQ.html =20 =09 Please resolve these comments along with any other Last Call comments=20 you may receive.=20 =09 In my opinion this draft is basically ready for publication, but has=20 nits that should be fixed before publication.=20 =09 Citations from the draft are marked by <<< text from draft >>>=20 =09 General comments=20 ----------------=20 =09 By its nature there are a lot of reference to drafts in the document.=20 It will take a lot of time for these documents to become and RFC.=20 So how we are going to publish this as an RFC? Since when the=20 referenced drafts will become an RFC, this draft would have to be=20 updated with new drafts, will it be held in the=20 RFC ED queue for ever?=20 =09 How do we gauge the usage of an RFC or a draft? There are many places=20 here that it is said that this or that RFC/draft got widely implemented=20 or not.=20 How it is measured? The wide implementation test is used to decide=20 whether an RFC or draft are core or not and therefore there should be=20 some text explaining how the wide implementation was determined. =09 Better change RFC XXXX (before the reference number in []) to the name=20 of the draft (with no version number), it will make the ride smoother.=20 =09 An introduction that details the various grouping should be added. It=20 should include additional text on the group and what was the criteria=20 for putting an RFC/draft in the group.=20 =09 2. Scope of this Document=20 --------------------------=20 =09 <<<=20 o Any specification that defines an extension to SIP itself, where=20 an extension is a mechanism that changes or updates in some way a=20 behavior specified in RFC 3261=20 >>>=20 =09 "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"=20 instead.=20 Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus=20 (or the president of the galaxy) and that RFCs/drafts mentioned in this=20 document are based on their relation to it.=20 =09 <<<=20 Excluded from this list are requirements, architectures, registry=20 definitions, non-normative frameworks, and processes. Best Current=20 Practices are included when they normatively define mechanisms for=20 accomplishing a task.=20 >>>=20 =20 "normatively define" not sure what is meant by normative with=20 respect to BCP. Seems like a contradiction in terms.=20 =09 3. Core SIP Specifications=20 ---------------------------=20 =09 If we think on presence as eventually replacing registration, since it=20 carries much more information about the availability of the user,=20 should we consider also presence as a towel?=20 =09 <<<=20 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the=20 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9].=20 It is the president of the galaxy [42] as far as the suite of SIP=20 specifications is concerned.=20 >>>=20 =09 RFC 3261 is a very big document. Should it be treated as one or it can=20 be divided into parts in this document e.g. proxy, client etc.? I am not=20 sure what would be better.=20 =09 4. Public Switched Telephone Network (PSTN) Interworking=20 ---------------------------------------------------------=20 =09 Regarding RFC 3578=20 Ugly in one corner of the galaxy may be beautiful on the other of it :-)=20 =09 7. Minor Extensions=20 --------------------=20 =09 <<<=20 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44]=20 allows a UA sending a REFER to ask the recipient of the REFER to=20 generate multiple SIP requests, not just one. This is useful for=20 conferencing, where a client would like to ask a conference server=20 to eject multiple users.=20 >>>=20 =09 Should not this be referred to in the conferencing section also? =09 <<<=20 RFC 4483, A Mechanism for Content Indirection in Session Initiation=20 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for=20 content indirection. Instead of carrying an object within a SIP=20 body, a URL reference is carried instead, and the recipient=20 dereferences the URL to obtain the object. The specification has=20 potential applicability for sending large instant messages, but=20 has yet to find much actual use.=20 >>>=20 =09 The specification has also potential for sending large presence=20 documents via a URL.=20 =09 <<<=20 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor=20 Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a mechanism in SDP to signal floor control streams that use BFCP.=20 It is used for Push-To-Talk and conference floor control.=20 >>>=20 =09 Should not this be referred to in the conferencing section also? =09 <<<=20 RFC XXXX, Connectivity Preconditions for Session Description Protocol=20 Media Streams (S): RFC XXXX [93] defines a usage of the precondition=20 framework [59]. The connectivity precondition makes sure that the=20 session doesn't get established until actual packet connectivity=20 is checked.=20 >>>=20 =09 Should not this be referred to in the QoS section also?=20 =09 8. Conferencing=20 ----------------=20 =09 The Conferencing section should be before or after "Instant Messaging,=20 Presence and Multimedia" as it is also an application. See the comment=20 on whether presence is an application or not later.=20 =09 10. Event Framework and Packages=20 ----------------------------------=20 =09 Suggest to divide this section to event framework section and to packages section. The event framework should include 3265, 3903, 4662=20 and subnot-etags which define the event framework itself.=20 The other section will the packages sections that will list the=20 packages.=20 =09 Alternatively, many of the packages are mentioned in their proper=20 section so it may be that all the event packages can be fit into their relevant section and there is not a need for packages section.=20 =09 11. Quality of Service=20 -----------------------=20 =09 <<<=20 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC=20 3313 [61] defines a P-header that provides a mechanism for passing=20 an authorization token between SIP and a network QoS reservation=20 protocol like RSVP. Its purpose is to make sure network QoS is=20 only granted if a client has made a SIP call through the same=20 providers network. This specification is sometimes referred to as=20 the SIP walled garden specification by the truly paranoid androids=20 in the SIP community. This is because it requires coupling of=20 signaling and the underlying IP network.=20 >>> =20 =09 Understand that being a "truly paranoid" is a virtue? :-)=20 =09 15. Security Mechanisms=20 ------------------------=20 =09 Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474=20 (Identity) be mentioned here also? =20 =09 16. Instant Messaging, Presence and Multimedia=20 -----------------------------------------------=20 =09 Maybe create an applications section and put also conferencing as a type=20 of an application.=20 =09 Including presence here with IM and multimedia seems that presence is=20 regarded as an additional type of media. I am not sure that I agree with=20 this. Presence is an enabler for many other applications and it deserves=20 a section of its own.=20 =09 It is very tempting to include the simple-simple content here=20 (as an appendix?). If simple-simple is not to be included here, there=20 should be at least a reference to simple-simple as for presence=20 there are so many documents that are essential for doing presence and=20 are not mentioned here (e.g. watcher format, RPID, presence rules,=20 partial notify and publish and many many more). Roughly counting, there=20 are about 20-25 RFCs/drafts that are very relevant to presence that are=20 mentioned in simple-simple in addition to the ones that are mentioned here.=20 =09 The MSRP drafts seem to be forgotten?=20 =09 Thanks=20 --Avshalom =09 ------_=_NextPart_001_01C81ACB.0C8D750B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
(As WG chair)
 
Just a note that I should have included with = the=20 WGLC.
 
The intention with this document is to = republish on a=20 recurring basis, and therefore to keep it up to date (say once a year or = so).
 
The 1st versions is intended to include gruu, = outbound and=20 ice, but apart from that, anything that is not published in that = timeframe will=20 probably be removed unless there is exceptional justification for = keeping it,=20 with the idea that it will appear in the next = version.
 
regards
 
Keith

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, October 29, 2007 = 10:40=20 AM
To: rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03


I have been = assigned to review=20 of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and the SIMPLE group but = ended up=20 in
commenting on the = whole document=20 at the end.

For = background on=20 RAI-ART, please see the FAQ at
http://www.softarmor.com/rai/art/rai-art-FAQ.html<= /A>=20

Please resolve these = comments along=20 with any other Last Call comments
you may receive.

In my=20 opinion this draft is basically ready for publication, but has=20
nits that should be fixed = before=20 publication.

Citations from the=20 draft are marked by <<< text from draft >>>=20

General comments =
----------------

By its nature there are a lot of = reference to drafts=20 in the document.
It = will take a lot=20 of time for these documents to become and RFC.
So how we are going to publish this as = an RFC? Since=20 when the
referenced = drafts will=20 become an RFC, this draft would have to be
updated with new drafts, will it be held in the =
RFC ED queue for ever? =

How do we gauge the usage of an RFC or a = draft?=20 There are many places
here that it=20 is said that this or that RFC/draft got widely implemented =
or not.
How it is measured? The wide implementation test is used to=20 decide
whether an RFC = or draft are=20 core or not and therefore there should be
some text explaining how the wide implementation was = determined.=20

Better change RFC XXXX = (before the=20 reference number in []) to the name
of the draft (with no version number), it will make the ride=20 smoother.

An = introduction that=20 details the various grouping should be added. It
should include additional text on the = group and what=20 was the criteria
for = putting an=20 RFC/draft in the group.

2.=20  Scope of this Document
--------------------------

<<<
   o=20  Any specification that defines an extension to SIP itself, = where=20
      an = extension is a=20 mechanism that changes or updates in some way a
      behavior specified = in RFC=20 3261
>>>=20

"to SIP itself" sounds = vague. It will=20 be better to say:"to RFC 3261"
instead.
Maybe = there should=20 be an earlier definition of RFC 3261 as the SIP nucleus =
(or the president of the galaxy) and = that=20 RFCs/drafts mentioned in this
document are based on their relation to it. =

<<<
   Excluded from this list are requirements, = architectures,=20 registry
  =  definitions,=20 non-normative frameworks, and processes.  Best Current =
   Practices are included when = they=20 normatively define mechanisms for
   accomplishing a task.
>>>
 =20  
"normatively = define" not=20 sure what is meant by normative with
respect to BCP. Seems like a contradiction in terms.=20

3.  Core SIP=20 Specifications
---------------------------

If we think on presence as eventually replacing registration, = since=20 it
carries much more = information=20 about the availability of the user,
should we consider also presence as a towel? =

<<<
   RFC 3261, The Session Initiation Protocol (S): =  RFC=20 3261 [1] is the
  =  =20   core SIP protocol itself.  RFC 3261 is an update to RFC = 2543=20 [9].
    =   It is the=20 president of the galaxy [42] as far as the suite of SIP =
      specifications is=20 concerned.
>>>=20

RFC 3261 is a very big = document.=20 Should it be treated as one or it can
be divided into parts in this document e.g. proxy, client = etc.? I am=20 not
sure what would be=20 better.

4. =  Public=20 Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------= =20

Regarding RFC 3578 =
Ugly in one corner of the galaxy may be = beautiful on=20 the other of it :-)

7.=20  Minor Extensions
--------------------

<<<
 =20  RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC = XXXX=20 [44]
    =   allows a=20 UA sending a REFER to ask the recipient of the REFER to =
      generate multiple = SIP requests,=20 not just one.  This is useful for
      conferencing, where a client would like = to ask a=20 conference server
   =20   to eject multiple users.
>>>

Should not=20 this be referred to in the conferencing section also? =

<<<
   RFC 4483, A Mechanism for Content Indirection in = Session=20 Initiation
  =  Protocol=20 (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for =
      content = indirection.=20  Instead of carrying an object within a SIP
      body, a URL = reference is=20 carried instead, and the recipient
      dereferences the URL to obtain the = object.=20  The specification has
 =20     potential applicability for sending large instant = messages,=20 but
    =   has yet to=20 find much actual use.
>>>

The=20 specification has also potential for sending large presence =
documents via a URL. =

<<<
   RFC 4583, Session Description Protocol (SDP) = Format for=20 Binary Floor
  =  Control=20 Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a =
      mechanism in SDP to = signal=20 floor control streams that use BFCP.
      It is used for Push-To-Talk and = conference floor=20 control.
>>>=20

Should not this be = referred to in the=20 conferencing section also?

<<<
 =20  RFC XXXX, Connectivity Preconditions for Session Description=20 Protocol
  =  Media Streams=20 (S):  RFC XXXX [93] defines a usage of the precondition =
      framework [59]. =  The=20 connectivity precondition makes sure that the
      session doesn't get = established=20 until actual packet connectivity
      is checked.
>>>

Should not=20 this be referred to in the QoS section also?

8.  Conferencing
----------------

The Conferencing section should be = before or after=20 "Instant Messaging,
Presence and=20 Multimedia" as it is also an application. See the comment =
on whether presence is an application or = not=20 later.

10. =  Event=20 Framework and Packages
----------------------------------

Suggest to divide this section to event = framework=20 section and to
packages = section.=20 The event framework should include 3265, 3903, 4662
and subnot-etags which define the event = framework=20 itself.
The other = section will the=20 packages sections that will list the
packages.

Alternatively,=20 many of the packages are mentioned in their proper
section so it may be that all the event = packages can=20 be fit into
their = relevant section=20 and there is not a need for packages section.

11.  Quality of Service =
----------------------- =

<<<
   RFC 3313, Private SIP Extensions for Media = Authorization=20 (I):  RFC
  =    =20 3313 [61] defines a P-header that provides a mechanism for = passing=20
      an = authorization=20 token between SIP and a network QoS reservation
      protocol like RSVP. =  Its=20 purpose is to make sure network QoS is
      only granted if a client has made a SIP = call=20 through the same
  =  =20   providers network.  This specification is sometimes = referred to=20 as
      = the SIP=20 walled garden specification by the truly paranoid androids =
      in the SIP = community.=20  This is because it requires coupling of
      signaling and the = underlying IP=20 network.
>>> =    =20  

Understand = that being a=20 "truly paranoid" is a virtue? :-)

15.  Security Mechanisms
------------------------

Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC = 4474
(Identity) be = mentioned here=20 also?    

16.=20  Instant Messaging, Presence and Multimedia
----------------------------------------------- =

Maybe create an applications section and = put also=20 conferencing as a type
of an=20 application.

Including presence=20 here with IM and multimedia seems that presence is
regarded as an additional type of media. = I am not=20 sure that I agree with
this.=20 Presence is an enabler for many other applications and it = deserves=20
a section of its own. =

It is very tempting to include the = simple-simple=20 content here
(as an = appendix?). If=20 simple-simple is not to be included here, there
should be at least a reference to = simple-simple as=20 for presence
there are = so many=20 documents that are essential for doing presence and
are not mentioned here (e.g. watcher = format, RPID,=20 presence rules,
partial = notify and=20 publish and many many more). Roughly counting, there
are about 20-25 RFCs/drafts that are = very relevant=20 to presence that are
mentioned in=20 simple-simple in addition to the ones that are mentioned here.=20

The MSRP drafts seem to be = forgotten?

Thanks=20
--Avshalom
 ------_=_NextPart_001_01C81ACB.0C8D750B-- --===============0590822343== 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 --===============0590822343==-- From sip-bounces@ietf.org Tue Oct 30 04:40:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immbw-00024V-4F; Tue, 30 Oct 2007 04:38:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Immbu-0001tr-T1 for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Immbu-0001gU-IC; Tue, 30 Oct 2007 04:38:06 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Immbf-0006Sb-Gk; Tue, 30 Oct 2007 04:37:58 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9U8bWNY074880; Tue, 30 Oct 2007 08:37:32 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9U8bWZS2056390; Tue, 30 Oct 2007 09:37:32 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9U8bVW1017174; Tue, 30 Oct 2007 09:37:32 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9U8bVeV017169; Tue, 30 Oct 2007 09:37:31 +0100 In-Reply-To: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith \(Keith\)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Tue, 30 Oct 2007 10:37:30 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 30/10/2007 10:37:30, Serialize complete at 30/10/2007 10:37:30 X-Spam-Score: -4.0 (----) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: sip@ietf.org, rai@ietf.org Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-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="===============0289287388==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0289287388== Content-Type: multipart/alternative; boundary="=_alternative 002F62B5C2257384_=" This is a multipart message in MIME format. --=_alternative 002F62B5C2257384_= Content-Type: text/plain; charset="US-ASCII" Keith, Thanks for the clarification. Maybe this clarification should be part of the document itself? BR --Avshalom "DRAGE, Keith \(Keith\)" 30/10/2007 10:01 To Avshalom Houri/Haifa/IBM@IBMIL, , , cc Subject RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 (As WG chair) Just a note that I should have included with the WGLC. The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so). The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version. regards Keith From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Monday, October 29, 2007 10:40 AM To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03 from the perspective of presence and the SIMPLE group but ended up in commenting on the whole document at the end. For background on RAI-ART, please see the FAQ at http://www.softarmor.com/rai/art/rai-art-FAQ.html Please resolve these comments along with any other Last Call comments you may receive. In my opinion this draft is basically ready for publication, but has nits that should be fixed before publication. Citations from the draft are marked by <<< text from draft >>> General comments ---------------- By its nature there are a lot of reference to drafts in the document. It will take a lot of time for these documents to become and RFC. So how we are going to publish this as an RFC? Since when the referenced drafts will become an RFC, this draft would have to be updated with new drafts, will it be held in the RFC ED queue for ever? How do we gauge the usage of an RFC or a draft? There are many places here that it is said that this or that RFC/draft got widely implemented or not. How it is measured? The wide implementation test is used to decide whether an RFC or draft are core or not and therefore there should be some text explaining how the wide implementation was determined. Better change RFC XXXX (before the reference number in []) to the name of the draft (with no version number), it will make the ride smoother. An introduction that details the various grouping should be added. It should include additional text on the group and what was the criteria for putting an RFC/draft in the group. 2. Scope of this Document -------------------------- <<< o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 >>> "to SIP itself" sounds vague. It will be better to say:"to RFC 3261" instead. Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus (or the president of the galaxy) and that RFCs/drafts mentioned in this document are based on their relation to it. <<< Excluded from this list are requirements, architectures, registry definitions, non-normative frameworks, and processes. Best Current Practices are included when they normatively define mechanisms for accomplishing a task. >>> "normatively define" not sure what is meant by normative with respect to BCP. Seems like a contradiction in terms. 3. Core SIP Specifications --------------------------- If we think on presence as eventually replacing registration, since it carries much more information about the availability of the user, should we consider also presence as a towel? <<< RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. It is the president of the galaxy [42] as far as the suite of SIP specifications is concerned. >>> RFC 3261 is a very big document. Should it be treated as one or it can be divided into parts in this document e.g. proxy, client etc.? I am not sure what would be better. 4. Public Switched Telephone Network (PSTN) Interworking --------------------------------------------------------- Regarding RFC 3578 Ugly in one corner of the galaxy may be beautiful on the other of it :-) 7. Minor Extensions -------------------- <<< RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] allows a UA sending a REFER to ask the recipient of the REFER to generate multiple SIP requests, not just one. This is useful for conferencing, where a client would like to ask a conference server to eject multiple users. >>> Should not this be referred to in the conferencing section also? <<< RFC 4483, A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for content indirection. Instead of carrying an object within a SIP body, a URL reference is carried instead, and the recipient dereferences the URL to obtain the object. The specification has potential applicability for sending large instant messages, but has yet to find much actual use. >>> The specification has also potential for sending large presence documents via a URL. <<< RFC 4583, Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a mechanism in SDP to signal floor control streams that use BFCP. It is used for Push-To-Talk and conference floor control. >>> Should not this be referred to in the conferencing section also? <<< RFC XXXX, Connectivity Preconditions for Session Description Protocol Media Streams (S): RFC XXXX [93] defines a usage of the precondition framework [59]. The connectivity precondition makes sure that the session doesn't get established until actual packet connectivity is checked. >>> Should not this be referred to in the QoS section also? 8. Conferencing ---------------- The Conferencing section should be before or after "Instant Messaging, Presence and Multimedia" as it is also an application. See the comment on whether presence is an application or not later. 10. Event Framework and Packages ---------------------------------- Suggest to divide this section to event framework section and to packages section. The event framework should include 3265, 3903, 4662 and subnot-etags which define the event framework itself. The other section will the packages sections that will list the packages. Alternatively, many of the packages are mentioned in their proper section so it may be that all the event packages can be fit into their relevant section and there is not a need for packages section. 11. Quality of Service ----------------------- <<< RFC 3313, Private SIP Extensions for Media Authorization (I): RFC 3313 [61] defines a P-header that provides a mechanism for passing an authorization token between SIP and a network QoS reservation protocol like RSVP. Its purpose is to make sure network QoS is only granted if a client has made a SIP call through the same providers network. This specification is sometimes referred to as the SIP walled garden specification by the truly paranoid androids in the SIP community. This is because it requires coupling of signaling and the underlying IP network. >>> Understand that being a "truly paranoid" is a virtue? :-) 15. Security Mechanisms ------------------------ Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474 (Identity) be mentioned here also? 16. Instant Messaging, Presence and Multimedia ----------------------------------------------- Maybe create an applications section and put also conferencing as a type of an application. Including presence here with IM and multimedia seems that presence is regarded as an additional type of media. I am not sure that I agree with this. Presence is an enabler for many other applications and it deserves a section of its own. It is very tempting to include the simple-simple content here (as an appendix?). If simple-simple is not to be included here, there should be at least a reference to simple-simple as for presence there are so many documents that are essential for doing presence and are not mentioned here (e.g. watcher format, RPID, presence rules, partial notify and publish and many many more). Roughly counting, there are about 20-25 RFCs/drafts that are very relevant to presence that are mentioned in simple-simple in addition to the ones that are mentioned here. The MSRP drafts seem to be forgotten? Thanks --Avshalom_______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai --=_alternative 002F62B5C2257384_= Content-Type: text/html; charset="US-ASCII"
Keith,

Thanks for the clarification.

Maybe this clarification should be part of the document itself?

BR
--Avshalom


"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com>

30/10/2007 10:01

To
Avshalom Houri/Haifa/IBM@IBMIL, <rai@ietf.org>, <sip@ietf.org>, <jdrosen@cisco.com>
cc
Subject
RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03





(As WG chair)
 
Just a note that I should have included with the WGLC.
 
The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so).
 
The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version.
 
regards
 
Keith

From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, October 29, 2007 10:40 AM
To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com
Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and the SIMPLE group but ended up in
commenting on the whole document at the end.

For background on RAI-ART, please see the FAQ at
http://www.softarmor.com/rai/art/rai-art-FAQ.html

Please resolve these comments along with any other Last Call comments
you may receive.

In my opinion this draft is basically ready for publication, but has
nits that should be fixed before publication.

Citations from the draft are marked by <<< text from draft >>>

General comments
----------------

By its nature there are a lot of reference to drafts in the document.
It will take a lot of time for these documents to become and RFC.
So how we are going to publish this as an RFC? Since when the
referenced drafts will become an RFC, this draft would have to be
updated with new drafts, will it be held in the
RFC ED queue for ever?

How do we gauge the usage of an RFC or a draft? There are many places
here that it is said that this or that RFC/draft got widely implemented
or not.
How it is measured? The wide implementation test is used to decide
whether an RFC or draft are core or not and therefore there should be
some text explaining how the wide implementation was determined.

Better change RFC XXXX (before the reference number in []) to the name
of the draft (with no version number), it will make the ride smoother.

An introduction that details the various grouping should be added. It
should include additional text on the group and what was the criteria
for putting an RFC/draft in the group.

2.  Scope of this Document
--------------------------

<<<
  o  Any specification that defines an extension to SIP itself, where
     an extension is a mechanism that changes or updates in some way a
     behavior specified in RFC 3261
>>>

"to SIP itself" sounds vague. It will be better to say:"to RFC 3261"
instead.
Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus
(or the president of the galaxy) and that RFCs/drafts mentioned in this
document are based on their relation to it.

<<<
  Excluded from this list are requirements, architectures, registry
  definitions, non-normative frameworks, and processes.  Best Current
  Practices are included when they normatively define mechanisms for
  accomplishing a task.
>>>
   
"normatively define" not sure what is meant by normative with
respect to BCP. Seems like a contradiction in terms.

3.  Core SIP Specifications
---------------------------

If we think on presence as eventually replacing registration, since it
carries much more information about the availability of the user,
should we consider also presence as a towel?

<<<
  RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1] is the
     core SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9].
     It is the president of the galaxy [42] as far as the suite of SIP
     specifications is concerned.
>>>

RFC 3261 is a very big document. Should it be treated as one or it can
be divided into parts in this document e.g. proxy, client etc.? I am not
sure what would be better.

4.  Public Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------

Regarding RFC 3578
Ugly in one corner of the galaxy may be beautiful on the other of it :-)

7.  Minor Extensions
--------------------

<<<
  RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
     allows a UA sending a REFER to ask the recipient of the REFER to
     generate multiple SIP requests, not just one.  This is useful for
     conferencing, where a client would like to ask a conference server
     to eject multiple users.
>>>

Should not this be referred to in the conferencing section also?

<<<
  RFC 4483, A Mechanism for Content Indirection in Session Initiation
  Protocol (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for
     content indirection.  Instead of carrying an object within a SIP
     body, a URL reference is carried instead, and the recipient
     dereferences the URL to obtain the object.  The specification has
     potential applicability for sending large instant messages, but
     has yet to find much actual use.
>>>

The specification has also potential for sending large presence
documents via a URL.

<<<
  RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
  Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a
     mechanism in SDP to signal floor control streams that use BFCP.
     It is used for Push-To-Talk and conference floor control.
>>>

Should not this be referred to in the conferencing section also?

<<<
  RFC XXXX, Connectivity Preconditions for Session Description Protocol
  Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
     framework [59].  The connectivity precondition makes sure that the
     session doesn't get established until actual packet connectivity
     is checked.
>>>

Should not this be referred to in the QoS section also?

8.  Conferencing
----------------

The Conferencing section should be before or after "Instant Messaging,
Presence and Multimedia" as it is also an application. See the comment
on whether presence is an application or not later.

10.  Event Framework and Packages
----------------------------------

Suggest to divide this section to event framework section and to
packages section. The event framework should include 3265, 3903, 4662
and subnot-etags which define the event framework itself.
The other section will the packages sections that will list the
packages.

Alternatively, many of the packages are mentioned in their proper
section so it may be that all the event packages can be fit into
their relevant section and there is not a need for packages section.

11.  Quality of Service
-----------------------

<<<
  RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
     3313 [61] defines a P-header that provides a mechanism for passing
     an authorization token between SIP and a network QoS reservation
     protocol like RSVP.  Its purpose is to make sure network QoS is
     only granted if a client has made a SIP call through the same
     providers network.  This specification is sometimes referred to as
     the SIP walled garden specification by the truly paranoid androids
     in the SIP community.  This is because it requires coupling of
     signaling and the underlying IP network.
>>>      

Understand that being a "truly paranoid" is a virtue? :-)

15.  Security Mechanisms
------------------------

Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474
(Identity) be mentioned here also?    

16.  Instant Messaging, Presence and Multimedia
-----------------------------------------------

Maybe create an applications section and put also conferencing as a type
of an application.

Including presence here with IM and multimedia seems that presence is
regarded as an additional type of media. I am not sure that I agree with
this. Presence is an enabler for many other applications and it deserves
a section of its own.

It is very tempting to include the simple-simple content here
(as an appendix?). If simple-simple is not to be included here, there
should be at least a reference to simple-simple as for presence
there are so many documents that are essential for doing presence and
are not mentioned here (e.g. watcher format, RPID, presence rules,
partial notify and publish and many many more). Roughly counting, there
are about 20-25 RFCs/drafts that are very relevant to presence that are
mentioned in simple-simple in addition to the ones that are mentioned here.

The MSRP drafts seem to be forgotten?

Thanks
--Avshalom_______________________________________________
RAI mailing list
RAI@ietf.org
https://www1.ietf.org/mailman/listinfo/rai
--=_alternative 002F62B5C2257384_=-- --===============0289287388== 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 --===============0289287388==-- From sip-bounces@ietf.org Tue Oct 30 11:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtOr-0007Wg-5D; Tue, 30 Oct 2007 11:53:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImtOq-0007W6-KR for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 11:53:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtOq-0007Vd-8r for sip@ietf.org; Tue, 30 Oct 2007 11:53:04 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImtOp-00082g-IV for sip@ietf.org; Tue, 30 Oct 2007 11:53:04 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Tue, 30 Oct 2007 11:53:03 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 30 Oct 2007 11:53:02 -0400 From: Hadriel Kaplan To: Adam Roach , Dean Willis Date: Tue, 30 Oct 2007 11:52:48 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgZ4f0oFGEJX/3ETNKOPXHaseUphQAWeoZQ Message-ID: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> In-Reply-To: <47255D1A.30206@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Errors-To: sip-bounces@ietf.org Do you mean this in the context of: "are there any registered 3265-type eve= nts which would be useful for this?" Or do you mean this in the sense of: = "are there any events in general which would be useful for this?" For the former, I tend to agree with you. I don't see any registered 3265 = events which would really be useful for tying to an Invite dialog in an INF= O. For the latter, we've already been discussing one: dtmf. The next obvious = one would be ISUP info exchange (though it's not as clear if it's needed). But one can also envision future ones. For example a way to perform a trac= eroute type thing across b2bua's (like incrementing max-forwards, but not i= dentical). Or a package for sending vcard info to the caller/called. Or a= package for giving out a jpeg for photo-id, or for call screen display. O= r a package for soft-key maps for a specific call (like a call to a vmail s= erver). Or a package for giving out an HTTP URL for simultaneous click-to-= web-browsing with call. Or a package for sending a "failed media path" ind= ication. Or a package for sending instructions for a SIP-based game. Can = some or all of these be done with Subscribes? Sure. And for some I think = it probably makes sense to ONLY allow it in subscribes/publish/whatever. B= ut for some of those, or for something in the future, it may make more sens= e to only exchange it in the Invite dialog it's related to, without the ove= rhead of a Subscribe dialog. I do assume from a SIP stack model perspective and its application user tha= t there would need to be some form of clear differentiation of subscription= Event Package support/usage, and one for Info-Packages. So I guess separa= ting these from Subscription-type Event packages makes sense in that contex= t. But does that mean one can't define a new package that works both ways? -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, October 29, 2007 12:10 AM > To: Dean Willis > Cc: Sanjay Sinha (sanjsinh); sip List > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > Dean Willis wrote: > > > > On Oct 28, 2007, at 4:58 PM, Adam Roach wrote: > > > >> Dean Willis wrote: > >>> Seriously, this stuff only makes sense for fairly atomic events. > >>> Partial notification just doesn't compute. That's why it would be > >>> silly to say it works for all event packages. > >> > >> You misspelled "any." > >> > > > > No, I don't believe so. It would, for example, function quite well > > with MWI (although not be terribly useful). > > Which is pretty much my point. I assume you picked a useless example > because there isn't a useful one. Is there anything better? Let's check > the IANA registry. > > Conference? That doesn't seem to match you assertion that "partial > notification just doesn't compute." Or are you thinking you'll be > passing full conference state around in INFO? > > Dialog? No, you're in the dialog -- you know how it's going. > > KPML? That uses a lot of the SUBSCRIBE mechanics to set up what triggers > notification. And if the endpoints are interested, send 2833/4733. > > MWI? I agree with what you say above -- not terribly useful. > > POC settings? You're in a call with the device -- it no longer matters > whether it will auto answer or whether it's going to bar you from calling= . > > REG? This gets heavily into the authorization questions Robert was > raising (unless you're talking to yourself, in which case it's downright > silly) -- and even if we blithely wave our hands at auth and say "send > it if you like and don't send it if you don't," what is the use case? > Why would someone do this? > > Refer? Spirits? Winfo? What would those even *mean*? > > We've been working on this for the past 7 years, and there's not a > single reasonable proof of concept that what you're fighting so > vigorously for has any practical application. The best example you can > come up with is one you concede is useless. Robert has raised a host of > reasonable concerns, and I've been pointing out additional sets of > problems that arise from your proposal. > > We know the downsides, and they are non-trivial. To make a fair > judgment, we need to balance those against the benefits. What are they? > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 30 12:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtcw-00034S-Kr; Tue, 30 Oct 2007 12:07:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Imtcv-00031j-1d for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtcu-000304-NP for sip@ietf.org; Tue, 30 Oct 2007 12:07:36 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imtct-0001Vk-Bb for sip@ietf.org; Tue, 30 Oct 2007 12:07:36 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9UG7NZE011031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 11:07:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472756C2.1010205@nostrum.com> Date: Tue, 30 Oct 2007 11:07:30 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4632/Tue Oct 30 09:20:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org On 10/30/07 10:52 AM, Hadriel Kaplan wrote: > I do assume from a SIP stack model perspective and its application user that there would need to be some form of clear differentiation of subscription Event Package support/usage, and one for Info-Packages. So I guess separating these from Subscription-type Event packages makes sense in that context. But does that mean one can't define a new package that works both ways? > One could. [1] My argument is that one shouldn't. Because when one does, one creates two ways to do the same thing. Which means that implementors either choose a single mechanism (and fail to work with the other -- this is bad) or are forced to implement both mechanisms (doubling implementation cost -- this is also bad). Why are we putting forth mechanisms that force implementors to choose between two bad options? The examples you cite clearly work better in an INVITE context -- so define them that way, and leave SUBSCRIBE out of it. /a ---- [1] One can also pound screws into wood with a hammer -- the measure of whether to do something isn't "can we", but "what happens if we do?" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 30 12:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtgV-0000Xn-Lp; Tue, 30 Oct 2007 12:11:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImtgT-0000Ub-Kp for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:11:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtgT-0000UT-86 for sip@ietf.org; Tue, 30 Oct 2007 12:11:17 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImtgS-0000Ca-VP for sip@ietf.org; Tue, 30 Oct 2007 12:11:17 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9UGBFv1011223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 11:11:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472757A9.4030103@nostrum.com> Date: Tue, 30 Oct 2007 11:11:21 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> In-Reply-To: <472756C2.1010205@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4632/Tue Oct 30 09:20:57 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org On 10/30/07 11:07 AM, Adam Roach wrote: > > The examples you cite clearly work better in an INVITE context -- so > define them that way, and leave SUBSCRIBE out of it. Correction: I meant "...leave SUBSCRIBE and NOTIFY out of it." /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 30 12:18:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtlq-00052q-9U; Tue, 30 Oct 2007 12:16:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Imtlp-000524-EG for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtlp-00051w-4i for sip@ietf.org; Tue, 30 Oct 2007 12:16:49 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imtli-0001pj-DV for sip@ietf.org; Tue, 30 Oct 2007 12:16:49 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Tue, 30 Oct 2007 12:16:31 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 30 Oct 2007 12:16:31 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 30 Oct 2007 12:16:30 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgbDvY3JGjHH1OPR+quEfIiTN3BMQAAJbkg Message-ID: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> In-Reply-To: <472756C2.1010205@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Yeah I was thinking the same thing - if there are two ways someone will sur= ely do one and not the other and we'll have problems. I was just thinking someone may come up with one that makes sense for both,= in different usage contexts. But I guess that's really 2 different packag= e types that may just happen to share a defining RFC or have the same regis= tered package name, but are really two separate "things". Regardless, I think it's safer to say for now the two package types are unr= elated. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, October 30, 2007 12:08 PM > To: Hadriel Kaplan > Cc: Dean Willis; sip List > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > On 10/30/07 10:52 AM, Hadriel Kaplan wrote: > > I do assume from a SIP stack model perspective and its application user > that there would need to be some form of clear differentiation of > subscription Event Package support/usage, and one for Info-Packages. So = I > guess separating these from Subscription-type Event packages makes sense > in that context. But does that mean one can't define a new package that > works both ways? > > > > One could. [1] > > My argument is that one shouldn't. Because when one does, one creates > two ways to do the same thing. Which means that implementors either > choose a single mechanism (and fail to work with the other -- this is > bad) or are forced to implement both mechanisms (doubling implementation > cost -- this is also bad). > > Why are we putting forth mechanisms that force implementors to choose > between two bad options? > > The examples you cite clearly work better in an INVITE context -- so > define them that way, and leave SUBSCRIBE out of it. > > /a > > ---- > [1] One can also pound screws into wood with a hammer -- the measure of > whether to do something isn't "can we", but "what happens if we do?" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 30 14:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImvQe-0007jE-VO; Tue, 30 Oct 2007 14:03:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImvQd-0007j8-Ig for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:03:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImvQd-0007hb-7h for sip@ietf.org; Tue, 30 Oct 2007 14:03:03 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImvQc-00040X-U4 for sip@ietf.org; Tue, 30 Oct 2007 14:03:03 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l9UI3062017511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2007 13:03:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <472771DB.9080101@nostrum.com> Date: Tue, 30 Oct 2007 13:03:07 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4639/Tue Oct 30 11:08:51 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org On 10/30/07 11:16 AM, Hadriel Kaplan wrote: > Yeah I was thinking the same thing - if there are two ways someone will surely do one and not the other and we'll have problems. > I was just thinking someone may come up with one that makes sense for both, in different usage contexts. But I guess that's really 2 different package types that may just happen to share a defining RFC or have the same registered package name, but are really two separate "things". > Regardless, I think it's safer to say for now the two package types are unrelated. > Excellent. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 30 14:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvb2-00042B-Hi; Tue, 30 Oct 2007 14:13:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Imvb0-00041U-Ob for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvb0-00041M-Ee for sip@ietf.org; Tue, 30 Oct 2007 14:13:46 -0400 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 1Imvas-0006PV-7B for sip@ietf.org; Tue, 30 Oct 2007 14:13:46 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="541389978" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2007 11:13:32 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIDVAt008670; Tue, 30 Oct 2007 14:13:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIDFde020110; Tue, 30 Oct 2007 18:13:30 GMT 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.1830); Tue, 30 Oct 2007 14:13:22 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:13:21 -0400 Message-ID: <47277440.3050707@cisco.com> Date: Tue, 30 Oct 2007 14:13:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> In-Reply-To: <472756C2.1010205@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 18:13:21.0771 (UTC) FILETIME=[8E245BB0:01C81B20] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--20.779100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2668; t=1193768011; x=1194632011; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, =09sense=20of=20consensus =20and=20a=20proposal=20for=20direction. |Sender:=20 |To:=20Adam=20Roach=20; bh=MHNBuBIiZBADZuRlY7w/mxpzsaV7+EgEbyEzPQMvxGo=; b=RhFd2T9+IhU+JjGQezftJzmlqv/Xr/+LH1Ym/kJd+tP4TWptOKMWUXj8fLsEVlzYG6T9apuH 95XHH0N1y8tUzbENQBSf7lzitHnX2nO+r8+VzlGBKQfOeYdQRVdcH8WR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org OK. Adam has persuaded me that overlap with relevant existing event packages is negligible (none, or perhaps KPML - more on that later) and that recommending that new ones be created to support two mechanisms is a bad idea. So that leaves the question of whether to nail down a negotiation mechanism for "info-packages". The obvious first case to consider is DTMF. The problem of course is that we already have two standard methods for transfering DTMF (telephone-events in RTP, and KPML subscriptions.) So standardizing use of INFO for this would mean standardizing a *different* way than KPML. And most likely it would be different than the non-standard way(s?) of using INFO for DTMF in the wild. Is that going to do anybody any good, or just give people more heartburn? Perhaps we should either bless what is being used or else continue to treat it with benign neglect. Once you get past that one, I think we might as well wait until somebody has something else they want to exchange this way to before getting too caught up in inventing machinery. Paul Adam Roach wrote: > On 10/30/07 10:52 AM, Hadriel Kaplan wrote: >> I do assume from a SIP stack model perspective and its application >> user that there would need to be some form of clear differentiation of >> subscription Event Package support/usage, and one for Info-Packages. >> So I guess separating these from Subscription-type Event packages >> makes sense in that context. But does that mean one can't define a >> new package that works both ways? >> > > One could. [1] > > My argument is that one shouldn't. Because when one does, one creates > two ways to do the same thing. Which means that implementors either > choose a single mechanism (and fail to work with the other -- this is > bad) or are forced to implement both mechanisms (doubling implementation > cost -- this is also bad). > > Why are we putting forth mechanisms that force implementors to choose > between two bad options? > > The examples you cite clearly work better in an INVITE context -- so > define them that way, and leave SUBSCRIBE out of it. > > /a > > ---- > [1] One can also pound screws into wood with a hammer -- the measure of > whether to do something isn't "can we", but "what happens if we do?" > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 30 18:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImzAD-0003JU-EE; Tue, 30 Oct 2007 18:02:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ImzAC-0003JM-1e for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 18:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImzAB-0003It-ON for sip@ietf.org; Tue, 30 Oct 2007 18:02:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imz9y-0000Bb-Ot for sip@ietf.org; Tue, 30 Oct 2007 18:02:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16FFA2152E; Tue, 30 Oct 2007 23:01:46 +0100 (CET) X-AuditID: c1b4fb3e-af032bb0000007e1-2b-4727a9c97ad0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF9C5214C0; Tue, 30 Oct 2007 23:01:45 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 23:01:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Tue, 30 Oct 2007 23:01:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgbIY00oS2TP5mKSYi+xw3th4CDlAAHhxNh References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 30 Oct 2007 22:01:45.0807 (UTC) FILETIME=[76624DF0:01C81B40] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org Hi, >OK. Adam has persuaded me that overlap with relevant existing event >packages is negligible (none, or perhaps KPML - more on that later) and >that recommending that new ones be created to support two mechanisms is >a bad idea. > >So that leaves the question of whether to nail down a negotiation >mechanism for "info-packages". > >The obvious first case to consider is DTMF. The problem of course is >that we already have two standard methods for transfering DTMF >(telephone-events in RTP, and KPML subscriptions.) So standardizing use >of INFO for this would mean standardizing a *different* way than KPML. >And most likely it would be different than the non-standard way(s?) of >using INFO for DTMF in the wild. Is that going to do anybody any good, >or just give people more heartburn? Perhaps we should either bless what >is being used or else continue to treat it with benign neglect. > >Once you get past that one, I think we might as well wait until = somebody >has something else they want to exchange this way to before getting too >caught up in inventing machinery. I think we should invent the machinery, and HOPEFULLY people will then = start implement it instead of the non-standard way. I also know that other SDOs are looking into using INFO for certain = things, so I think it would be really good to define a proper mechanism = before they also start to use INFO as it's used today (with all the = problems people have listed). Regards, Christer =20 =20 =20 Paul Adam Roach wrote: > On 10/30/07 10:52 AM, Hadriel Kaplan wrote: >> I do assume from a SIP stack model perspective and its application >> user that there would need to be some form of clear differentiation = of >> subscription Event Package support/usage, and one for Info-Packages.=20 >> So I guess separating these from Subscription-type Event packages >> makes sense in that context. But does that mean one can't define a >> new package that works both ways? >> =20 > > One could. [1] > > My argument is that one shouldn't. Because when one does, one creates > two ways to do the same thing. Which means that implementors either > choose a single mechanism (and fail to work with the other -- this is > bad) or are forced to implement both mechanisms (doubling = implementation > cost -- this is also bad). > > Why are we putting forth mechanisms that force implementors to choose > between two bad options? > > The examples you cite clearly work better in an INVITE context -- so > define them that way, and leave SUBSCRIBE out of it. > > /a > > ---- > [1] One can also pound screws into wood with a hammer -- the measure = of > whether to do something isn't "can we", but "what happens if we do?" > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 30 18:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imzx7-0006dx-1s; Tue, 30 Oct 2007 18:52:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Imzx5-0006dl-DE for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 18:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imzx5-0006dd-20 for sip@ietf.org; Tue, 30 Oct 2007 18:52:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imzx3-0002T8-Oy for sip@ietf.org; Tue, 30 Oct 2007 18:52:51 -0400 X-IronPort-AV: E=Sophos;i="4.21,349,1188802800"; d="scan'208";a="13919121" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 30 Oct 2007 15:52:48 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9UMqmsD026313; Tue, 30 Oct 2007 18:52:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UMqd5I027908; Tue, 30 Oct 2007 22:52:48 GMT 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.1830); Tue, 30 Oct 2007 18:52:44 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:52:44 -0400 Message-ID: <4727B5B3.70204@cisco.com> Date: Tue, 30 Oct 2007 18:52:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for direction. References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 22:52:44.0475 (UTC) FILETIME=[957E00B0:01C81B47] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--20.875700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2695; t=1193784768; x=1194648768; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap, sense=20of=20consensus=20 and=20a=20proposal=20for=20direction. |Sender:=20 |To:=20Christer=20Holmberg=20; bh=0MBA5+swrJWCHORhKctx77wvBwwQhnln2kwI9FJgR7U=; b=SlvD6EzITX/KhIkyF3mpYsYX5fS3xXYAHMsy5VB/E1I4C0Rlllo21EdVlYEizhQQsImZxGCd 4WJPTaItYHQYiETSIze6/bHbFbWEPAWNq4jkCisdkqnUG9iU1tZiq3Nl; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip List , Adam Roach , 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: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >> OK. Adam has persuaded me that overlap with relevant existing event >> packages is negligible (none, or perhaps KPML - more on that later) and >> that recommending that new ones be created to support two mechanisms is >> a bad idea. >> >> So that leaves the question of whether to nail down a negotiation >> mechanism for "info-packages". >> >> The obvious first case to consider is DTMF. The problem of course is >> that we already have two standard methods for transfering DTMF >> (telephone-events in RTP, and KPML subscriptions.) So standardizing use >> of INFO for this would mean standardizing a *different* way than KPML. >> And most likely it would be different than the non-standard way(s?) of >> using INFO for DTMF in the wild. Is that going to do anybody any good, >> or just give people more heartburn? Perhaps we should either bless what >> is being used or else continue to treat it with benign neglect. >> >> Once you get past that one, I think we might as well wait until somebody >> has something else they want to exchange this way to before getting too >> caught up in inventing machinery. > > I think we should invent the machinery, and HOPEFULLY people will then start implement it instead of the non-standard way. My original thinking was that this was just a lightweight way to establish a slightly restricted subscription. I was thinking of it as a way to use an existing event specification in a particular sub-case where you knew you wanted the target and duration to be the same as your invite. That is why I thought the same event package definitions would apply. That is no longer the case. This is a new thing. As such, it needs to define its own scope of applicability. There must be a way to say: "THIS new behavior should be done as an info-event because ..., and THAT new behavior should be done using an event/subscription because ...". What do we use to decide on that scope? We need some use cases. Other than DTMF, do we have any? And for DTMF, do you know how to partition those cases that should use this technique from the other two standard techniques and N non-standard techniques? > I also know that other SDOs are looking into using INFO for certain things, so I think it would be really good to define a proper mechanism before they also start to use INFO as it's used today (with all the problems people have listed). Could you be more specific? I'm guessing you are talking about 3GPP? We keep getting into trouble with 3GPP because we are asked to provide mechanisms without use cases and clear requirements for the mechanism. 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 Tue Oct 30 20:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0wY-0001ma-Tq; Tue, 30 Oct 2007 19:56:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1In0wX-0001mQ-G7 for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 19:56:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In0wX-0001mH-2Z; Tue, 30 Oct 2007 19:56:21 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In0wV-0000De-2u; Tue, 30 Oct 2007 19:56:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9UNuEu12413; Tue, 30 Oct 2007 23:56:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Oct 2007 18:56:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgaGKH+zp3EvtG8TLeDyez69R12VQAQbavAAD12KJA= References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Avshalom Houri" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e2982d6e88dd9e60a92963820c317d50 Cc: Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-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="===============0080657812==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0080657812== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81B50.70A4618E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81B50.70A4618E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about SIPS, which is already in hitchiker's guide, and which is waiting on outbound because of a normative reference? ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, October 30, 2007 01:01 To: Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 (As WG chair) =20 Just a note that I should have included with the WGLC. =20 The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so). =20 The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version. =20 regards =20 Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Monday, October 29, 2007 10:40 AM To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03=20 from the perspective of presence and the SIMPLE group but ended up in=20 commenting on the whole document at the end.=20 =09 For background on RAI-ART, please see the FAQ at=20 http://www.softarmor.com/rai/art/rai-art-FAQ.html =20 =09 Please resolve these comments along with any other Last Call comments=20 you may receive.=20 =09 In my opinion this draft is basically ready for publication, but has=20 nits that should be fixed before publication.=20 =09 Citations from the draft are marked by <<< text from draft >>>=20 =09 General comments=20 ----------------=20 =09 By its nature there are a lot of reference to drafts in the document.=20 It will take a lot of time for these documents to become and RFC.=20 So how we are going to publish this as an RFC? Since when the=20 referenced drafts will become an RFC, this draft would have to be=20 updated with new drafts, will it be held in the=20 RFC ED queue for ever?=20 =09 How do we gauge the usage of an RFC or a draft? There are many places=20 here that it is said that this or that RFC/draft got widely implemented=20 or not.=20 How it is measured? The wide implementation test is used to decide=20 whether an RFC or draft are core or not and therefore there should be=20 some text explaining how the wide implementation was determined.=20 =09 Better change RFC XXXX (before the reference number in []) to the name=20 of the draft (with no version number), it will make the ride smoother.=20 =09 An introduction that details the various grouping should be added. It=20 should include additional text on the group and what was the criteria=20 for putting an RFC/draft in the group.=20 =09 2. Scope of this Document=20 --------------------------=20 =09 <<<=20 o Any specification that defines an extension to SIP itself, where=20 an extension is a mechanism that changes or updates in some way a=20 behavior specified in RFC 3261=20 >>>=20 =09 "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"=20 instead.=20 Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus=20 (or the president of the galaxy) and that RFCs/drafts mentioned in this=20 document are based on their relation to it.=20 =09 <<<=20 Excluded from this list are requirements, architectures, registry=20 definitions, non-normative frameworks, and processes. Best Current=20 Practices are included when they normatively define mechanisms for=20 accomplishing a task.=20 >>>=20 =20 "normatively define" not sure what is meant by normative with=20 respect to BCP. Seems like a contradiction in terms.=20 =09 3. Core SIP Specifications=20 ---------------------------=20 =09 If we think on presence as eventually replacing registration, since it=20 carries much more information about the availability of the user,=20 should we consider also presence as a towel?=20 =09 <<<=20 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the=20 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9].=20 It is the president of the galaxy [42] as far as the suite of SIP=20 specifications is concerned.=20 >>>=20 =09 RFC 3261 is a very big document. Should it be treated as one or it can=20 be divided into parts in this document e.g. proxy, client etc.? I am not=20 sure what would be better.=20 =09 4. Public Switched Telephone Network (PSTN) Interworking=20 =09 ---------------------------------------------------------=20 =09 Regarding RFC 3578=20 Ugly in one corner of the galaxy may be beautiful on the other of it :-)=20 =09 7. Minor Extensions=20 --------------------=20 =09 <<<=20 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44]=20 allows a UA sending a REFER to ask the recipient of the REFER to=20 generate multiple SIP requests, not just one. This is useful for=20 conferencing, where a client would like to ask a conference server=20 to eject multiple users.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC 4483, A Mechanism for Content Indirection in Session Initiation=20 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for=20 content indirection. Instead of carrying an object within a SIP=20 body, a URL reference is carried instead, and the recipient=20 dereferences the URL to obtain the object. The specification has=20 potential applicability for sending large instant messages, but=20 has yet to find much actual use.=20 >>>=20 =09 The specification has also potential for sending large presence=20 documents via a URL.=20 =09 <<<=20 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor=20 Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a=20 mechanism in SDP to signal floor control streams that use BFCP.=20 It is used for Push-To-Talk and conference floor control.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC XXXX, Connectivity Preconditions for Session Description Protocol=20 Media Streams (S): RFC XXXX [93] defines a usage of the precondition=20 framework [59]. The connectivity precondition makes sure that the=20 session doesn't get established until actual packet connectivity=20 is checked.=20 >>>=20 =09 Should not this be referred to in the QoS section also?=20 =09 8. Conferencing=20 ----------------=20 =09 The Conferencing section should be before or after "Instant Messaging,=20 Presence and Multimedia" as it is also an application. See the comment=20 on whether presence is an application or not later.=20 =09 10. Event Framework and Packages=20 ----------------------------------=20 =09 Suggest to divide this section to event framework section and to=20 packages section. The event framework should include 3265, 3903, 4662=20 and subnot-etags which define the event framework itself.=20 The other section will the packages sections that will list the=20 packages.=20 =09 Alternatively, many of the packages are mentioned in their proper=20 section so it may be that all the event packages can be fit into=20 their relevant section and there is not a need for packages section.=20 =09 11. Quality of Service=20 -----------------------=20 =09 <<<=20 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC=20 3313 [61] defines a P-header that provides a mechanism for passing=20 an authorization token between SIP and a network QoS reservation=20 protocol like RSVP. Its purpose is to make sure network QoS is=20 only granted if a client has made a SIP call through the same=20 providers network. This specification is sometimes referred to as=20 the SIP walled garden specification by the truly paranoid androids=20 in the SIP community. This is because it requires coupling of=20 signaling and the underlying IP network.=20 >>> =20 =09 Understand that being a "truly paranoid" is a virtue? :-)=20 =09 15. Security Mechanisms=20 ------------------------=20 =09 Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474=20 (Identity) be mentioned here also? =20 =09 16. Instant Messaging, Presence and Multimedia=20 -----------------------------------------------=20 =09 Maybe create an applications section and put also conferencing as a type=20 of an application.=20 =09 Including presence here with IM and multimedia seems that presence is=20 regarded as an additional type of media. I am not sure that I agree with=20 this. Presence is an enabler for many other applications and it deserves=20 a section of its own.=20 =09 It is very tempting to include the simple-simple content here=20 (as an appendix?). If simple-simple is not to be included here, there=20 should be at least a reference to simple-simple as for presence=20 there are so many documents that are essential for doing presence and=20 are not mentioned here (e.g. watcher format, RPID, presence rules,=20 partial notify and publish and many many more). Roughly counting, there=20 are about 20-25 RFCs/drafts that are very relevant to presence that are=20 mentioned in simple-simple in addition to the ones that are mentioned here.=20 =09 The MSRP drafts seem to be forgotten?=20 =09 Thanks=20 --Avshalom =09 ------_=_NextPart_001_01C81B50.70A4618E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What=20 about SIPS, which is already in hitchiker's guide, and which is waiting = on=20 outbound because of a normative reference?

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: Tuesday, October = 30, 2007=20 01:01
To: Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: RE: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03

(As WG chair)
 
Just a note that I should have included with = the=20 WGLC.
 
The intention with this document is to = republish on a=20 recurring basis, and therefore to keep it up to date (say once a year = or=20 so).
 
The 1st versions is intended to include gruu, = outbound=20 and ice, but apart from that, anything that is not published in that = timeframe=20 will probably be removed unless there is exceptional justification for = keeping=20 it, with the idea that it will appear in the next = version.
 
regards
 
Keith

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, October 29, = 2007 10:40=20 AM
To: rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03


I have been = assigned to=20 review of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and = the SIMPLE=20 group but ended up in
commenting=20 on the whole document at the end.

For background on RAI-ART, please see the FAQ at =
http://www.softarmor.com/rai/art/rai-art-FAQ.html<= /A>=20

Please resolve these = comments along=20 with any other Last Call comments
you may receive.

In my=20 opinion this draft is basically ready for publication, but = has=20
nits that should be fixed = before=20 publication.

Citations from=20 the draft are marked by <<< text from draft = >>>=20

General comments =
----------------

By its nature there are a lot of = reference to=20 drafts in the document.
It will=20 take a lot of time for these documents to become and RFC. =
So how we are going to publish this as = an RFC?=20 Since when the
referenced drafts=20 will become an RFC, this draft would have to be
updated with new drafts, will it be = held in=20 the
RFC ED queue for = ever?=20

How do we gauge the = usage of an RFC=20 or a draft? There are many places
here that it is said that this or that RFC/draft got widely = implemented
or = not.=20
How it is measured? The wide = implementation test is used to decide
whether an RFC or draft are core or not and therefore there = should=20 be
some text = explaining how the=20 wide implementation was determined.

Better change RFC XXXX (before the reference number in []) = to the=20 name
of the draft = (with no=20 version number), it will make the ride smoother. =

An introduction that details the = various grouping=20 should be added. It
should=20 include additional text on the group and what was the = criteria=20
for putting an RFC/draft in = the=20 group.

2. =  Scope of this=20 Document
--------------------------

<<<
 =20  o  Any specification that defines an extension to SIP = itself,=20 where
    =   an=20 extension is a mechanism that changes or updates in some way = a=20
      = behavior specified=20 in RFC 3261
>>>=20

"to SIP itself" sounds = vague. It=20 will be better to say:"to RFC 3261"
instead.
Maybe there=20 should be an earlier definition of RFC 3261 as the SIP = nucleus=20
(or the president of the = galaxy) and=20 that RFCs/drafts mentioned in this
document are based on their relation to it. =

<<<
   Excluded from this list are requirements, = architectures,=20 registry
 =20  definitions, non-normative frameworks, and processes. =  Best=20 Current
  =  Practices=20 are included when they normatively define mechanisms for =
   accomplishing a = task.=20
>>> =
   
"normatively define" not sure what is meant by normative = with=20
respect to BCP. Seems like a = contradiction in terms.

3.=20  Core SIP Specifications
---------------------------

If we think on presence as eventually replacing = registration, since=20 it
carries much more = information=20 about the availability of the user,
should we consider also presence as a towel? =

<<<
   RFC 3261, The Session Initiation Protocol (S): =  RFC=20 3261 [1] is the
   =20   core SIP protocol itself.  RFC 3261 is an update to RFC = 2543=20 [9].
    =   It is=20 the president of the galaxy [42] as far as the suite of SIP =
      specifications is = concerned.
>>>=20

RFC 3261 is a very big = document.=20 Should it be treated as one or it can
be divided into parts in this document e.g. proxy, client = etc.? I am=20 not
sure what would = be=20 better.

4. =  Public=20 Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------= =20

Regarding RFC = 3578
Ugly in one corner of the galaxy may = be beautiful=20 on the other of it :-)

7.=20  Minor Extensions
--------------------

<<<
 =20  RFC XXXX, Referring to Multiple Resources in SIP (S): =  RFC XXXX=20 [44]
    =   allows=20 a UA sending a REFER to ask the recipient of the REFER to =
      generate multiple = SIP=20 requests, not just one.  This is useful for
      conferencing, = where a client=20 would like to ask a conference server
      to eject multiple users. =
>>>

Should not this be referred to in the = conferencing=20 section also?

<<<
 =20  RFC 4483, A Mechanism for Content Indirection in Session=20 Initiation
  =  Protocol=20 (SIP) Messages (S):  RFC 4483 [89] defines a mechanism = for=20
      content = indirection.  Instead of carrying an object within a SIP =
      body, a = URL=20 reference is carried instead, and the recipient
      dereferences the = URL to=20 obtain the object.  The specification has
      potential = applicability for=20 sending large instant messages, but
      has yet to find much actual = use.=20
>>> =

The specification has also potential = for sending=20 large presence
documents via a=20 URL.

<<<=20
   RFC 4583, = Session=20 Description Protocol (SDP) Format for Binary Floor
   Control Protocol (BFCP) = Streams (S):=20  RFC 4583 [91] defines a
      mechanism in SDP to signal floor = control streams=20 that use BFCP.
  =  =20   It is used for Push-To-Talk and conference floor = control.=20
>>> =

Should not this be referred to in the = conferencing=20 section also?

<<<
 =20  RFC XXXX, Connectivity Preconditions for Session Description=20 Protocol
  =  Media=20 Streams (S):  RFC XXXX [93] defines a usage of the = precondition=20
      = framework [59].=20  The connectivity precondition makes sure that the =
      session doesn't = get=20 established until actual packet connectivity
      is = checked.
>>>

Should not this be referred to in the = QoS section=20 also?

8.=20  Conferencing
----------------

The=20 Conferencing section should be before or after "Instant = Messaging,=20
Presence and Multimedia" as = it is also=20 an application. See the comment
on whether presence is an application or not later.=20

10.  Event = Framework and=20 Packages
----------------------------------

Suggest to divide this section to = event framework=20 section and to
packages section.=20 The event framework should include 3265, 3903, 4662
and subnot-etags which define the = event framework=20 itself.
The other = section will=20 the packages sections that will list the
packages.

Alternatively, many of the packages are mentioned in their=20 proper
section so it = may be that=20 all the event packages can be fit into
their relevant section and there is not a need for packages = section.

11. =  Quality of=20 Service
-----------------------

<<<
 =20  RFC 3313, Private SIP Extensions for Media Authorization (I):=20  RFC
  =    =20 3313 [61] defines a P-header that provides a mechanism for = passing=20
      an = authorization=20 token between SIP and a network QoS reservation
      protocol like = RSVP.  Its=20 purpose is to make sure network QoS is
      only granted if a client has made a = SIP call=20 through the same
   =20   providers network.  This specification is sometimes = referred to=20 as
    =   the SIP=20 walled garden specification by the truly paranoid androids =
      in the SIP = community.=20  This is because it requires coupling of
      signaling and the = underlying=20 IP network.
>>>  =20    

Understand that=20 being a "truly paranoid" is a virtue? :-)

15.  Security Mechanisms =
------------------------ =

Should not RFC 3323 (Privacy), RFC = 3325=20 (Asserted-ID) and RFC 4474
(Identity) be mentioned here also?     =

16.  Instant Messaging, Presence = and=20 Multimedia
----------------------------------------------- =

Maybe create an applications section = and put also=20 conferencing as a type
of an=20 application.

Including=20 presence here with IM and multimedia seems that presence is =
regarded as an additional type of = media. I am not=20 sure that I agree with
this.=20 Presence is an enabler for many other applications and it = deserves=20
a section of its own. =

It is very tempting to = include the=20 simple-simple content here
(as an=20 appendix?). If simple-simple is not to be included here, = there=20
should be at least a = reference to=20 simple-simple as for presence
there are so many documents that are essential for doing = presence=20 and
are not mentioned = here (e.g.=20 watcher format, RPID, presence rules,
partial notify and publish and many many more). Roughly = counting,=20 there
are about 20-25 = RFCs/drafts=20 that are very relevant to presence that are
mentioned in simple-simple in addition = to the ones=20 that are mentioned here.

The=20 MSRP drafts seem to be forgotten?

Thanks
--Avshalom
------_=_NextPart_001_01C81B50.70A4618E-- --===============0080657812== 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 --===============0080657812==-- From sip-bounces@ietf.org Tue Oct 30 20:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14s-0001xI-Tb; Tue, 30 Oct 2007 20:04:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1In14r-0001x7-Cl for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 20:04:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In14r-0001wy-2h for sip@ietf.org; Tue, 30 Oct 2007 20:04:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In14q-0000V3-Qh for sip@ietf.org; Tue, 30 Oct 2007 20:04:56 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9V04r924280; Wed, 31 Oct 2007 00:04:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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] INFO: A recap, sense of consensus and a proposal for direction. Date: Tue, 30 Oct 2007 19:04:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgZ4f0oFGEJX/3ETNKOPXHaseUphQAWeoZQAEVYTjA= References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> From: "Francois Audet" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Errors-To: sip-bounces@ietf.org =20 > Or a package=20 > for sending vcard info to the caller/called. Or a package=20 > for giving out a jpeg for photo-id, or for call screen=20 > display. =20 Isn't that what the Call-info header is exactly for (RFC 3261/20.9)? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 30 23:33:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4Dy-0005fF-31; Tue, 30 Oct 2007 23:26:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1In4Dw-0005eO-ND for sip-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 23:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4Dw-0005Uj-Cx for sip@ietf.org; Tue, 30 Oct 2007 23:26:32 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In4Do-0005VB-5g for sip@ietf.org; Tue, 30 Oct 2007 23:26:29 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Tue, 30 Oct 2007 23:26:14 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 30 Oct 2007 23:26:13 -0400 From: Hadriel Kaplan To: Francois Audet Date: Tue, 30 Oct 2007 23:25:56 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgZ4f0oFGEJX/3ETNKOPXHaseUphQAWeoZQAEVYTjAABmqkMA== Message-ID: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > > > Or a package > > for sending vcard info to the caller/called. Or a package > > for giving out a jpeg for photo-id, or for call screen > > display. > > Isn't that what the Call-info header is exactly for (RFC 3261/20.9)? It was my understanding the Call-Info header was to give a URI to go fetch = stuff from, usually an HTTP URI (if one could use the term "usually" for th= e Call-Info header ;). That is highly unlikely I think, since it is highly= unlikely a SIP UA has a web-server to provide such, or one globally reacha= ble (like, good luck if it's behind a NAT/FW). I guess you could put in a = SIP URI and tell it to Subscribe for a jpeg photo-id package, and stick som= e cookie in the uri so the serving UA can correlate the subscribe request t= o the call (i.e., which call is asking for this info?). Yeah that= 's a lot more reasonable than just using the Invite dialog to send it in an= INFO. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 31 00:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4qF-0000EC-RB; Wed, 31 Oct 2007 00:06:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1In4qD-0000A5-Gp for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 00:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In4qA-0008Kf-Ad for sip@ietf.org; Wed, 31 Oct 2007 00:06:03 -0400 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In4q2-0006q4-5v for sip@ietf.org; Wed, 31 Oct 2007 00:06:00 -0400 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Wed, 31 Oct 2007 00:05:50 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 31 Oct 2007 00:05:49 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Adam Roach Date: Wed, 31 Oct 2007 00:05:48 -0400 Subject: RE: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Topic: [Sip] INFO: A recap, sense of consensus and a proposal for direction. Thread-Index: AcgbIJVUInoHC1EDRMKSwOUf4UpyOQATTxRA Message-ID: References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com> In-Reply-To: <47277440.3050707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip List , 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: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, October 30, 2007 2:13 PM > To: Adam Roach > Cc: Hadriel Kaplan; sip List; Dean Willis > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > The obvious first case to consider is DTMF. The problem of course is > that we already have two standard methods for transfering DTMF > (telephone-events in RTP, and KPML subscriptions.) So standardizing use > of INFO for this would mean standardizing a *different* way than KPML. > And most likely it would be different than the non-standard way(s?) of > using INFO for DTMF in the wild. Is that going to do anybody any good, > or just give people more heartburn? Perhaps we should either bless what > is being used or else continue to treat it with benign neglect. My vote would be to re-use the most common one, which I think is the applic= ation/dtmf-relay one. If for no other reason than to make it as easy as po= ssible, for as many non-standard implementations as possible, to implement = the negotiation and follow a standard. KPML is orthogonal to info-dtmf. It has its own use cases, if people want = to use it. The sticky part in my mind has always been what to do if both info-dtmf wer= e negotiated and 2833/4733 was offered/answered. Or even what to do with i= n-audio tones. I *think* the answer is info-dtmf should trump 2833 - i.e.,= if you negotiated info-dtmf only do that, for a variety of reasons; but wi= th delayed SDP offers that would mean you'd always end up using info-dtmf w= hen you could have done 2833 instead. And I can see the argument for "do b= oth", and that's what kpml did except it has the suppression/
 concept,=
 but I assumed that was due to pattern matching being inconsistent with in-=
band event sending one-at-a-time.  But I still think info-dtmf trumping wou=
ld be right, because the tones will get to the far end if they should.

-hadriel



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 03:54:49 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1In8J6-0006U2-GC; Wed, 31 Oct 2007 03:48:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1In8J4-0006Tw-PF
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 03:48:06 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1In8Iz-0006SN-H8
	for sip@ietf.org; Wed, 31 Oct 2007 03:48:01 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In8Iv-0006fs-KN
	for sip@ietf.org; Wed, 31 Oct 2007 03:47:58 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	F07BE20400; Wed, 31 Oct 2007 08:47:56 +0100 (CET)
X-AuditID: c1b4fb3c-ae67bbb0000007e1-d5-4728332cb252
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	D5AC82041E; Wed, 31 Oct 2007 08:47:56 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 08:47:56 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
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] INFO: A recap,
	sense of consensus and a proposal for direction.
Date: Wed, 31 Oct 2007 08:47:55 +0100
Message-ID: 
In-Reply-To: <4727B5B3.70204@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] INFO: A recap,
	sense of consensus and a proposal for direction.
Thread-Index: AcgbR5sgngl7FEgLSYO/vLtKi87DpAARmlDg
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>	
	<472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com>
	
	<4727B5B3.70204@cisco.com>
From: "Christer Holmberg" 
To: "Paul Kyzivat" 
X-OriginalArrivalTime: 31 Oct 2007 07:47:56.0762 (UTC)
	FILETIME=[59E823A0:01C81B92]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: sip List , Adam Roach ,
	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: ,
	
Errors-To: sip-bounces@ietf.org


Hi Paul,=20

>>>OK. Adam has persuaded me that overlap with relevant existing event=20
>>>packages is negligible (none, or perhaps KPML - more on that later)=20
>>>and that recommending that new ones be created to support two
mechanisms is a bad idea.
>>>
>>>So that leaves the question of whether to nail down a negotiation
mechanism for "info-packages".
>>>
>>>The obvious first case to consider is DTMF. The problem of course is=20
>>>that we already have two standard methods for transfering DTMF=20
>>>(telephone-events in RTP, and KPML subscriptions.) So standardizing=20
>>>use of INFO for this would mean standardizing a *different* way than
KPML.
>>>And most likely it would be different than the non-standard way(s?)=20
>>>of using INFO for DTMF in the wild. Is that going to do anybody any=20
>>>good, or just give people more heartburn? Perhaps we should either=20
>>>bless what is being used or else continue to treat it with benign
neglect.
>>>
>>>Once you get past that one, I think we might as well wait until=20
>>>somebody has something else they want to exchange this way to before=20
>>>getting too caught up in inventing machinery.
>>=20
>>I think we should invent the machinery, and HOPEFULLY people will then
start implement it instead of the non-standard way.
>=20
>My original thinking was that this was just a lightweight way=20
>to establish a slightly restricted subscription. I was=20
>thinking of it as a way to use an existing event=20
>specification in a particular sub-case where you knew you=20
>wanted the target and duration to be the same as your invite.=20
>That is why I thought the same event package definitions would apply.
>=20
>That is no longer the case. This is a new thing. As such, it=20
>needs to define its own scope of applicability. There must be=20
>a way to say: "THIS new behavior should be done as an=20
>info-event because ..., and THAT new behavior should be done=20
>using an event/subscription because ...".

It's up to the one defining the event packages to describe those things,
and to say whether an event package is applicable for info-events and/or
subscription-events.

>What do we use to decide on that scope? We need some use=20
>cases. Other than DTMF, do we have any? And for DTMF, do you=20
>know how to partition those cases that should use this=20
>technique from the other two standard techniques and N=20
>non-standard techniques?

That's for the implementors - not us - to decide. We provide the tools,
and a clear definition on how they can be used etc.

And, I think DTMF IS a very valid use-case to start working on this
mechanism. The issues has been around for years, and it won't go away.

Another use-case I've seen is related to interworking, where certain
H.245 messages are mapped into INFO.

Another use-case I've seen is related to video control, where INFO is
used to control video-type-of applications.

Another use-case is of course ISUP transport, and other type of
PSTN/ISDN information.

Other use-cases are when application are exchaning some data (e.g. the
here-is-a-jpeg example which comes up all the time :) between
themselves. These kind of use-cases will most likely grow as the number
of applications grow. Applications can of course also exchange data by
setting up a data channel, but there may be cases where the amount and
frequency of data is not that large.

And, we don't know how many such applications there already are out
there. If we provide a standardized tool, people will hopefully bring
those to IETF.

Another use-case (and you're going to love this one :), is SIP overlap
dialling. Some organizations have proposed requirements to optionally
support SIP overlap in IMS. Currently TISPAN is studying two mechanism.
One is based on the RFC, where a new initial INVITE is sent when more
digits are provided. The other mechanism is based on, once an early
dialog has been established with the remote peer, sending the additional
digits in-dialog, and INFO is obviously one of the candidate methods for
providing the additional digits.

>I also know that other SDOs are looking into using INFO for=20
>certain things, so I think it would be really good to define=20
>a proper mechanism before they also start to use INFO as it's=20
>used today (with all the problems people have listed).
>=20
>Could you be more specific? I'm guessing you are talking about 3GPP?

At this point I think it's more TISPAN, but much of the work will
probably end up in 3GPP sooner or later. Unfortunately I am not involved
in that work, so I can't give any details.

>We keep getting into trouble with 3GPP because we are asked=20
>to provide mechanisms without use cases and clear=20
>requirements for the mechanism.

And when 3GPP does provide use-cases we start to argue against them...

Anyway, that is another topic, so let's not get into that discussion
here and now.

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 Wed Oct 31 10:08:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InE8A-0005oY-4w; Wed, 31 Oct 2007 10:01:14 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InE88-0005ne-HV
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:01:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InE88-0005nF-5M
	for sip@ietf.org; Wed, 31 Oct 2007 10:01:12 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InE7z-000748-Uk
	for sip@ietf.org; Wed, 31 Oct 2007 10:01:10 -0400
Received: from [206.176.144.210] (206-176-144-210.waymark.net
	[206.176.144.210]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
	l9VE0b40029066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 31 Oct 2007 09:00:45 -0500
Message-ID: <47288A7F.5040906@softarmor.com>
Date: Wed, 31 Oct 2007 09:00:31 -0500
From: Dean Willis 
User-Agent: Icedove 1.5.0.14pre (X11/20071018)
MIME-Version: 1.0
To: Paul Kyzivat 
Subject: Re: [Sip] INFO: A recap,
	sense of consensus and a proposal for direction.
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<472756C2.1010205@nostrum.com>
	<47277440.3050707@cisco.com>	
	<4727B5B3.70204@cisco.com>
In-Reply-To: <4727B5B3.70204@cisco.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
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: ,
	
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:

> What do we use to decide on that scope? We need some use cases. Other
> than DTMF, do we have any? And for DTMF, do you know how to partition
> those cases that should use this technique from the other two standard
> techniques and N non-standard techniques?

We have the entire family of mid-call "telephony tunneling" events for
which we've previously agreed to use INFO as use cases.

I think the clear factor between scoping events to an INVITE dialog
(INFO) versus a SUBSCRIBE dialog is whether the events being reported
are completely bounded by an INVITE dialog. That is, they're what we
would have previously called "mid-call events".  If they have no
meaningful context before the INVITE or after the BYE, then they may be
reasonably considered to be INFO events.

--
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 31 10:21:57 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InEQN-000695-Km; Wed, 31 Oct 2007 10:20:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InEQM-000687-K9
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:20:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InEQM-00067u-9n
	for sip@ietf.org; Wed, 31 Oct 2007 10:20:02 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InEQG-00086Z-5H
	for sip@ietf.org; Wed, 31 Oct 2007 10:20:02 -0400
X-IronPort-AV: E=Sophos;i="4.21,351,1188792000"; d="scan'208";a="75015424"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2007 10:19:39 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VEJc8m013320; 
	Wed, 31 Oct 2007 10:19:38 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9VEItoF012790; 
	Wed, 31 Oct 2007 14:19:33 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 10:19:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] INFO: A recap,
	sense of consensus and a proposal fordirection.
Date: Wed, 31 Oct 2007 10:19:26 -0400
Message-ID: <8983EC086A9D954BA74D9763E853CF3E041EB780@xmb-rtp-215.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] INFO: A recap,
	sense of consensus and a proposal fordirection.
Thread-Index: AcgZ4f0oFGEJX/3ETNKOPXHaseUphQAWeoZQAEVYTjAABmqkMAAXb4nQ
From: "Sanjay Sinha (sanjsinh)" 
To: "Hadriel Kaplan" ,
	"Francois Audet" 
X-OriginalArrivalTime: 31 Oct 2007 14:19:29.0198 (UTC)
	FILETIME=[0C7D64E0:01C81BC9]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002
X-TM-AS-Result: No--17.400800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1940; t=1193840378;
	x=1194704378; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20INFO=3A=20A=20recap,
	=09sense=20of=20consensus =20and=20a=20proposal=20fordirection.
	|Sender:=20
	|To:=20=22Hadriel=20Kaplan=22=20,
	=0A=20=20=20=20=
	20=20=20=20=22Francois=20Audet=22=20;
	bh=LggZrP1r2Pe4TVOvhYiRhu0WJR0qJRT3nronOokO+I8=;
	b=lDyEE7AtuXZS9S6qfnF7bQ4GNakemDE37HqafR+/721gZ2bz+qE6oa9a4WxldJNNlEkVG8hd
	IzOBw4jU05VAxMvCwD12WA8fFtHEG44St3cGBnmPrnOM3vBG7i95x00c;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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: ,
	
Errors-To: sip-bounces@ietf.org

 >-----Original Message-----
>From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20
>Sent: Tuesday, October 30, 2007 11:26 PM
>To: Francois Audet
>Cc: sip List
>Subject: RE: [Sip] INFO: A recap, sense of consensus and a=20
>proposal fordirection.
>
>
>
>> -----Original Message-----
>> From: Francois Audet [mailto:audet@nortel.com]
>>
>> > Or a package
>> > for sending vcard info to the caller/called.  Or a package for=20
>> > giving out a jpeg for photo-id, or for call screen display.
>>
>> Isn't that what the Call-info header is exactly for (RFC 3261/20.9)?
>
>It was my understanding the Call-Info header was to give a URI=20
>to go fetch stuff from, usually an HTTP URI (if one could use=20
>the term "usually" for the Call-Info header ;).  That is=20
>highly unlikely I think, since it is highly unlikely a SIP UA=20
>has a web-server to provide such, or one globally reachable=20
>(like, good luck if it's behind a NAT/FW).  I guess you could=20
>put in a SIP URI and tell it to Subscribe for a jpeg photo-id=20
>package, and stick some cookie in the uri so the serving UA=20
>can correlate the subscribe request to the call (i.e., which=20
>call is asking for this info?).  Yeah that's a lot=20
>more reasonable than just using the Invite dialog to send it=20
>in an INFO.

One can also use out of dialog REFER with the URI in Refer-To header and
add a Target-Dialog header referencing the INVITE dialog this
information to be fetched from URI in Refer-To applies to.  The Refer-To
url can be globally reachable one.

Thanks.
>
>-hadriel
>
>
>
>_______________________________________________
>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
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 10:22:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InESV-0006sq-Mg; Wed, 31 Oct 2007 10:22:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InESU-0006rZ-8U
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:22:14 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InEST-0006rQ-Tl
	for sip@ietf.org; Wed, 31 Oct 2007 10:22:13 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InEST-00078D-Dw
	for sip@ietf.org; Wed, 31 Oct 2007 10:22:13 -0400
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9VEM0wj000797
	for ; Wed, 31 Oct 2007 09:22:10 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 09:21:44 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 15:21:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
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: WGLC of draft-ietf-sip-hitchhikers-guide-03
Date: Wed, 31 Oct 2007 15:20:45 +0100
Message-ID: <5D1A7985295922448D5550C94DE291800188662D@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE291800184A31A@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: WGLC of draft-ietf-sip-hitchhikers-guide-03
Thread-Index: AcgPBcv4h6/g5D89QjaqwYyPe0P9cwGazMjgAZXMYTA=
References: <5D1A7985295922448D5550C94DE291800184A31A@DEEXC1U01.de.lucent.com>
From: "DRAGE, Keith \(Keith\)" 
To: "IETF SIP List" 
X-OriginalArrivalTime: 31 Oct 2007 14:21:36.0629 (UTC)
	FILETIME=[5871D250:01C81BC9]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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: ,
	
Errors-To: sip-bounces@ietf.org

(As WG chair)

This WGLC is now concluded.

I believe we are still awaiting an RAI review from Brian Stucker
(apologies if I have missed it).

If there are any more comments in preparation, then please get them
submitted as soon as possible.=20

>From my review of the comments so far, I believe that the document has
been adequately reviewed, and that the comments made are all resolvable.

I would therefore ask that the editor update the document and submit a
new version, contacting the mailing list if necessary with issues, and
we'll get the publication request in for the document.

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Tuesday, October 23, 2007 1:38 PM
> To: IETF SIP List
> Subject: [Sip] RE: WGLC of draft-ietf-sip-hitchhikers-guide-03
>=20
> (As WG chair)
>=20
> There has been little response to this WGLC so far. So:
>=20
> 1)	A REMINDER TO ALL SIP WG MEMBERS THAT THIS DOCUMENT IS UNDER
> WGLC. It is your duty to review it and post comments. Please=20
> do so by Monday 29th October.
>=20
> 2)	An explicit request that at least one member of the SIP WG has
> read it from one end to the other, so that we know whether we=20
> are happy with the overall structure. If you have done this,=20
> and are happy (i.e.
> no comments at all), then please inform the WG chairs of this.
>=20
> 3)	An explicit request to all editor's of published SIP (and
> SIPPING) RFCs. If you have the honour to have published an=20
> RFC, please review the entry for your document, and make sure=20
> it makes sense. If it doesn't, please comment.
>=20
> Regards
>=20
> Keith
>=20
> > -----Original Message-----
> > From: DRAGE, Keith (Keith)
> > Sent: Monday, October 15, 2007 9:32 AM
> > To: IETF SIP List
> > Subject: WGLC of draft-ietf-sip-hitchhikers-guide-03
> >=20
> > (As WG chair)
> >=20
> > This is to announce a working group last call of
> >=20
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers
> > -guide-03.txt
> >=20
> > I would request comments on this document be made (to list and to=20
> > author mentioned in the document) by Monday October 29th 2007.
> >=20
> > Please clearly identify the text of the document that is being=20
> > commented on, the nature of the comment (NIT, minor=20
> technical, major=20
> > technical, etc), and any suggested resolution, even if it=20
> is only some=20
> > alternatives.
> >=20
> > Regards
> >=20
> > Keith
> >=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=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 Wed Oct 31 10:29:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InEXG-0002m1-Je; Wed, 31 Oct 2007 10:27:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InEXE-0002by-Mb
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:27:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InEXE-0002Xv-8o
	for sip@ietf.org; Wed, 31 Oct 2007 10:27:08 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InEX9-00008H-26
	for sip@ietf.org; Wed, 31 Oct 2007 10:27:08 -0400
X-IronPort-AV: E=Sophos;i="4.21,351,1188792000"; d="scan'208";a="135896156"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 31 Oct 2007 10:26:47 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VEQlfj018094; 
	Wed, 31 Oct 2007 10:26:47 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9VEQT5Q007505; 
	Wed, 31 Oct 2007 14:26:47 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 10:26:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] INFO: A recap,
	sense of consensus and a proposal fordirection.
Date: Wed, 31 Oct 2007 10:26:36 -0400
Message-ID: <8983EC086A9D954BA74D9763E853CF3E041EB791@xmb-rtp-215.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] INFO: A recap,
	sense of consensus and a proposal fordirection.
Thread-Index: AcgbIJVUInoHC1EDRMKSwOUf4UpyOQATTxRAABbTMmA=
From: "Sanjay Sinha (sanjsinh)" 
To: "Hadriel Kaplan" ,
	"Paul Kyzivat (pkyzivat)" ,
	"Adam Roach" 
X-OriginalArrivalTime: 31 Oct 2007 14:26:38.0484 (UTC)
	FILETIME=[0C5D3D40:01C81BCA]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002
X-TM-AS-Result: No--15.980600-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3382; t=1193840807;
	x=1194704807; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20
	|Subject:=20RE=3A=20[Sip]=20INFO=3A=20A=20recap,
	=09sense=20of=20consensus =20and=20a=20proposal=20fordirection.
	|Sender:=20
	|To:=20=22Hadriel=20Kaplan=22=20,
	=0A=20=20=20=20=
	20=20=20=20=22Paul=20Kyzivat=20(pkyzivat)=22=20,
	=0A=20
	=20=20=20=20=20=20=20=22Adam=20Roach=22=20;
	bh=dLiz7SVdEX2R7cDq0gi4/Kq2pGiDrRI8jgN+f0rjF04=;
	b=GJ/5sgNi8RbCnTGtqFFA/rzQB0dt3GXUz2JZPDQhL72vhytcFX2rntnL2tp0/qI4tPY81Tiu
	rpHATnkpAvW9PQ6LOaPBRZTeS0m2UN6asEFLcrveGzJ/9k87TE8f4C+U;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip List , 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: ,
	
Errors-To: sip-bounces@ietf.org

Pl. see inline ..

>-----Original Message-----
>From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20
>Sent: Wednesday, October 31, 2007 12:06 AM
>To: Paul Kyzivat (pkyzivat); Adam Roach
>Cc: sip List; Dean Willis
>Subject: RE: [Sip] INFO: A recap, sense of consensus and a=20
>proposal fordirection.
>
>
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>> Sent: Tuesday, October 30, 2007 2:13 PM
>> To: Adam Roach
>> Cc: Hadriel Kaplan; sip List; Dean Willis
>> Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal=20
>> for direction.
>>
>> The obvious first case to consider is DTMF. The problem of course is=20
>> that we already have two standard methods for transfering DTMF=20
>> (telephone-events in RTP, and KPML subscriptions.) So standardizing=20
>> use of INFO for this would mean standardizing a *different*=20
>way than KPML.
>> And most likely it would be different than the non-standard=20
>way(s?) of=20
>> using INFO for DTMF in the wild. Is that going to do anybody=20
>any good,=20
>> or just give people more heartburn? Perhaps we should either bless=20
>> what is being used or else continue to treat it with benign neglect.
>
>My vote would be to re-use the most common one, which I think=20
>is the application/dtmf-relay one.  If for no other reason=20
>than to make it as easy as possible, for as many non-standard=20
>implementations as possible, to implement the negotiation and=20
>follow a standard.
>
>KPML is orthogonal to info-dtmf.  It has its own use cases, if=20
>people want to use it.
I think KPML is more suitable for things like dial-plan match etc. and
not for OOB dtmf signaling.

>
>The sticky part in my mind has always been what to do if both=20
>info-dtmf were negotiated and 2833/4733 was offered/answered.
A UA can have configured preferences, if more than one mechanism is
offered. So if it is configured for both info-dtmf and 2833/4733, based
on preference it can choose one or the other and provide that in answer
response. I am not sure why would some implementation choose info-dtmf
over 2833/4733 mechanism.
 =20
>Or even what to do with in-audio tones.
Based on negotiated mechanism, it can ignore the other mechanism. So if
info-dtmf is the negotiated mechanism and for a pstn gw, it can instruct
the DSP to drop in-band dtmf packets.

Thanks.

>I *think* the answer is info-dtmf should trump 2833 - i.e., if you
negotiated=20
>info-dtmf only do that, for a variety of reasons; but with=20
>delayed SDP offers that would mean you'd always end up using=20
>info-dtmf when you could have done 2833 instead.  And I can=20
>see the argument for "do both", and that's what kpml did=20
>except it has the suppression/
 concept, but I assumed=20
>that was due to pattern matching being inconsistent with=20
>in-band event sending one-at-a-time.  But I still think=20
>info-dtmf trumping would be right, because the tones will get=20
>to the far end if they should.
>
>-hadriel
>
>
>
>_______________________________________________
>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
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 10:32:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InEbM-0008AG-P8; Wed, 31 Oct 2007 10:31:24 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InEbL-00083f-5l
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:31:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InEbK-00083X-SZ
	for sip@ietf.org; Wed, 31 Oct 2007 10:31:22 -0400
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InEbE-0000KU-NJ
	for sip@ietf.org; Wed, 31 Oct 2007 10:31:22 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l9VEUKLw003690
	for ; Wed, 31 Oct 2007 09:31:03 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 09:30:52 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 15:30:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 Oct 2007 15:29:47 +0100
Message-ID: <5D1A7985295922448D5550C94DE2918001886640@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC for draft-ietf-sip-rph-new-namespaces-00
Thread-Index: Acgbyn0mN8XRdTV1TPqUGz/ZmHlO+A==
From: "DRAGE, Keith \(Keith\)" 
To: "IETF SIP List" 
X-OriginalArrivalTime: 31 Oct 2007 14:30:49.0719 (UTC)
	FILETIME=[A21CA870:01C81BCA]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
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: ,
	
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

Keeping up the pressure on you people out there doing the reviewing.

This is to announce a WGLC for=20

"IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Header Namespaces"

Contained in=20

http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00
.txt

The Working group last call is for two weeks until close of business on
Wednesday 14th November 2007.

Please submit any comments to the SIP list and to the editor.

I have solicited a number of independent reviews in parallel to this,
for which some have already been provided. These will be taken into
account in the WGLC.

Regards

Keith


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



From sip-bounces@ietf.org Wed Oct 31 10:55:58 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InEwy-0006Qo-3s; Wed, 31 Oct 2007 10:53:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InEww-0006Pg-Tz
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:53:42 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InEww-0006MY-IG
	for sip@ietf.org; Wed, 31 Oct 2007 10:53:42 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InEww-0000NI-65
	for sip@ietf.org; Wed, 31 Oct 2007 10:53:42 -0400
Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.14.1/8.14.1) with ESMTP id l9VErdpv009072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2007 09:53:40 -0500 (CDT)
	(envelope-from adam@nostrum.com)
Message-ID: <472896FC.4090708@nostrum.com>
Date: Wed, 31 Oct 2007 09:53:48 -0500
From: Adam Roach 
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan 
Subject: Re: [Sip] INFO: A recap,
	sense of consensus and a proposal for	direction.
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Virus-Scanned: ClamAV 0.91.2/4648/Wed Oct 31 09:11:06 2007 on
	shaman.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: sip List , Francois Audet 
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: ,
	
Errors-To: sip-bounces@ietf.org

On 10/30/07 10:25 PM, Hadriel Kaplan wrote:
> It was my understanding the Call-Info header was to give a URI to go fetch stuff from, usually an HTTP URI (if one could use the term "usually" for the Call-Info header ;).  That is highly unlikely I think, since it is highly unlikely a SIP UA has a web-server to provide such, or one globally reachable (like, good luck if it's behind a NAT/FW).  I guess you could put in a SIP URI and tell it to Subscribe for a jpeg photo-id package, and stick some cookie in the uri so the serving UA can correlate the subscribe request to the call (i.e., which call is asking for this info?).  Yeah that's a lot more reasonable than just using the Invite dialog to send it in an INFO.
>   

Hey, I've always been a fan of putting data URLs (RFC 2397) in 
Alert-Info and Call-Info header fields. I think it's much cleaner than 
any of the approaches you mention.


Alert-Info: 


Of course, if you don't like long headers, you can get a very similar 
effect with multipart MIME bodies and CID URIs (RFC 2392).

/a


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



From sip-bounces@ietf.org Wed Oct 31 11:28:41 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InFQu-0004sn-Fp; Wed, 31 Oct 2007 11:24:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InFQt-0004sh-Au
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:24:39 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InFQs-0004rP-V7
	for sip@ietf.org; Wed, 31 Oct 2007 11:24:39 -0400
Received: from mail146.messagelabs.com ([216.82.245.131])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InFQn-0001tQ-KI
	for sip@ietf.org; Wed, 31 Oct 2007 11:24:33 -0400
X-VirusChecked: Checked
X-Env-Sender: mdolly@att.com
X-Msg-Ref: server-2.tower-146.messagelabs.com!1193844267!1713775!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 5865 invoked from network); 31 Oct 2007 15:24:27 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com)
	(144.160.20.54)
	by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Oct 2007 15:24:27 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	l9VFORLt015104 for ; Wed, 31 Oct 2007 11:24:27 -0400
Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13])
	by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id
	l9VFOMVa015048 for ; Wed, 31 Oct 2007 11:24:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] WGLC for draft-ietf-sip-rph-new-namespaces-00
Date: Wed, 31 Oct 2007 10:24:21 -0500
Message-ID: <28F05913385EAC43AF019413F674A0171246E561@OCCLUST04EVS1.ugd.att.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001886640@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
Thread-Index: Acgbyn0mN8XRdTV1TPqUGz/ZmHlO+AAByzlQ
References: <5D1A7985295922448D5550C94DE2918001886640@DEEXC1U01.de.lucent.com>
From: "DOLLY, MARTIN C, ATTLABS" 
To: "DRAGE, Keith (Keith)" ,
	"IETF SIP List" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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: ,
	
Errors-To: sip-bounces@ietf.org

We support this.=20

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
Sent: Wednesday, October 31, 2007 10:30 AM
To: IETF SIP List
Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

(As SIP WG chair)

Keeping up the pressure on you people out there doing the reviewing.

This is to announce a WGLC for=20

"IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Header Namespaces"

Contained in=20

http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00
.txt

The Working group last call is for two weeks until close of business on
Wednesday 14th November 2007.

Please submit any comments to the SIP list and to the editor.

I have solicited a number of independent reviews in parallel to this,
for which some have already been provided. These will be taken into
account in the WGLC.

Regards

Keith


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


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 11:57:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InFtz-0008AQ-Ng; Wed, 31 Oct 2007 11:54:43 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InFty-00082a-HQ
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:54:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InFty-0007yb-3y
	for sip@ietf.org; Wed, 31 Oct 2007 11:54:42 -0400
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 1InFtw-0004mI-Sy for sip@ietf.org; Wed, 31 Oct 2007 11:54:42 -0400
X-IronPort-AV: E=Sophos;i="4.21,351,1188802800"; d="scan'208";a="541760616"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 31 Oct 2007 08:54:40 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VFse1Z016949; 
	Wed, 31 Oct 2007 08:54:40 -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 l9VFs5nm026640;
	Wed, 31 Oct 2007 15:54:39 GMT
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.1830); 
	Wed, 31 Oct 2007 11:54:33 -0400
Received: from [161.44.174.216] ([161.44.174.216]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 11:54:33 -0400
Message-ID: <4728A53A.5080208@cisco.com>
Date: Wed, 31 Oct 2007 11:54:34 -0400
From: Paul Kyzivat 
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Adam Roach 
Subject: Re: [Sip] INFO: A recap,
	sense of consensus and a proposal for	direction.
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>		<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>	<472505F8.5090401@nostrum.com>	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>	<47255D1A.30206@nostrum.com>		<1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com>	
	<472896FC.4090708@nostrum.com>
In-Reply-To: <472896FC.4090708@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Oct 2007 15:54:33.0535 (UTC)
	FILETIME=[548A24F0:01C81BD6]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002
X-TM-AS-Result: No--16.677700-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1955; t=1193846080;
	x=1194710080; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20
	|Subject:=20Re=3A=20[Sip]=20INFO=3A=20A=20recap,
	=09sense=20of=20consensus
	=20and=20a=20proposal=20for=09direction. |Sender:=20;
	bh=hqhhpJF8tBfiZbFJFfBfZKmciCFOE28dO+prujG99u8=;
	b=s6+qxMy/YiJZNG/rnViWbvjT5nCbcMZGAsDAG7Az4dznVs6JkBJohT/zkhOcdzrabStFqI6m
	wpz+zQzAzU+elFW0rRwQMLKCDhuFfLFtdGp3W7C6o76uXNNId+6/h7bG;
Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: sip List , Francois Audet 
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: ,
	
Errors-To: sip-bounces@ietf.org

Adam beat me to it re the CID URI. The data URI works too. (I hadn't 
thought of it in that context.)

	Paul

Adam Roach wrote:
> On 10/30/07 10:25 PM, Hadriel Kaplan wrote:
>> It was my understanding the Call-Info header was to give a URI to go 
>> fetch stuff from, usually an HTTP URI (if one could use the term 
>> "usually" for the Call-Info header ;).  That is highly unlikely I 
>> think, since it is highly unlikely a SIP UA has a web-server to 
>> provide such, or one globally reachable (like, good luck if it's 
>> behind a NAT/FW).  I guess you could put in a SIP URI and tell it to 
>> Subscribe for a jpeg photo-id package, and stick some cookie in the 
>> uri so the serving UA can correlate the subscribe request to the call 
>> (i.e., which call is asking for this info?).  Yeah that's a 
>> lot more reasonable than just using the Invite dialog to send it in an 
>> INFO.
>>   
> 
> Hey, I've always been a fan of putting data URLs (RFC 2397) in 
> Alert-Info and Call-Info header fields. I think it's much cleaner than 
> any of the approaches you mention.
> 
> 
> Alert-Info: 
>  
> 
> 
> Of course, if you don't like long headers, you can get a very similar 
> effect with multipart MIME bodies and CID URIs (RFC 2392).
> 
> /a
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


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



From sip-bounces@ietf.org Wed Oct 31 12:11:25 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InG6H-0004tu-II; Wed, 31 Oct 2007 12:07:25 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InG6G-0004ta-0i
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:07:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InG6F-0004qm-Kr
	for sip@ietf.org; Wed, 31 Oct 2007 12:07:23 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InG6A-0005Nw-EN
	for sip@ietf.org; Wed, 31 Oct 2007 12:07:23 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l9VG72E11253; Wed, 31 Oct 2007 16:07:02 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] INFO: A recap,
	sense of consensus and a proposal for direction.
Date: Wed, 31 Oct 2007 11:06:45 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF12E08742@zrc2hxm0.corp.nortel.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] INFO: A recap,
	sense of consensus and a proposal for direction.
Thread-Index: AcgZ4f0oFGEJX/3ETNKOPXHaseUphQAWeoZQAEVYTjAABmqkMAAbN+8Q
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>
	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>
	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>
	
	<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>
	<472505F8.5090401@nostrum.com>
	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>
	<47255D1A.30206@nostrum.com>
	
	<1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com>
	
From: "Francois Audet" 
To: "Hadriel Kaplan" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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: ,
	
Errors-To: sip-bounces@ietf.org

Well, the photo can be on some web server:

Call-info: 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20
> Sent: Tuesday, October 30, 2007 20:26
> To: Audet, Francois (SC100:3055)
> Cc: sip List
> Subject: RE: [Sip] INFO: A recap, sense of consensus and a=20
> proposal for direction.
>=20
>=20
>=20
> > -----Original Message-----
> > From: Francois Audet [mailto:audet@nortel.com]
> >
> > > Or a package
> > > for sending vcard info to the caller/called.  Or a package for=20
> > > giving out a jpeg for photo-id, or for call screen display.
> >
> > Isn't that what the Call-info header is exactly for (RFC 3261/20.9)?
>=20
> It was my understanding the Call-Info header was to give a=20
> URI to go fetch stuff from, usually an HTTP URI (if one could=20
> use the term "usually" for the Call-Info header ;).  That is=20
> highly unlikely I think, since it is highly unlikely a SIP UA=20
> has a web-server to provide such, or one globally reachable=20
> (like, good luck if it's behind a NAT/FW).  I guess you could=20
> put in a SIP URI and tell it to Subscribe for a jpeg photo-id=20
> package, and stick some cookie in the uri so the serving UA=20
> can correlate the subscribe request to the call (i.e., which=20
> call is asking for this info?).  Yeah that's a lot=20
> more reasonable than just using the Invite dialog to send it=20
> in an INFO.
>=20
> -hadriel
>=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 Wed Oct 31 12:59:12 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InGqF-0007Tu-PC; Wed, 31 Oct 2007 12:54:55 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InGqE-0007TU-A0
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:54:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InGqE-0007Q2-0S
	for sip@ietf.org; Wed, 31 Oct 2007 12:54:54 -0400
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGq2-0007jP-Ss
	for sip@ietf.org; Wed, 31 Oct 2007 12:54:48 -0400
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0;
	Wed, 31 Oct 2007 12:54:25 -0400
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 31 Oct 2007 12:54:25 -0400
From: Hadriel Kaplan 
To: Paul Kyzivat , Adam Roach 
Date: Wed, 31 Oct 2007 12:54:22 -0400
Subject: RE: [Sip] INFO: A recap,	sense of consensus and a proposal for
	direction.
Thread-Topic: [Sip] INFO: A recap,	sense of consensus and a proposal for
	direction.
Thread-Index: Acgb1llPdpWkhc93QUeKwIFgBQk18AABsUGw
Message-ID: 
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com>
	<63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com>
	<9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com>
	
	<20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com>
	<472505F8.5090401@nostrum.com>
	<8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com>
	<47255D1A.30206@nostrum.com>
	
	<1ECE0EB50388174790F9694F77522CCF12DC4A0F@zrc2hxm0.corp.nortel.com>
	
	<472896FC.4090708@nostrum.com> <4728A53A.5080208@cisco.com>
In-Reply-To: <4728A53A.5080208@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: sip List , Francois Audet 
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: ,
	
Errors-To: sip-bounces@ietf.org



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, October 31, 2007 11:55 AM
> To: Adam Roach
> Cc: Hadriel Kaplan; sip List; Francois Audet
> Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for
> direction.
>
> Adam beat me to it re the CID URI. The data URI works too. (I hadn't
> thought of it in that context.)

Me neither.  I wonder how many implementers had thought of it - i.e., how m=
any phones would it actually work for. :)  Someone should probably write a =
sipping draft for that someday.
But anyway it was just an example.  And to continue the example the beauty =
of sending a vcard in an Info is it lets the user trigger the action.  So f=
or example once I call you I can ask you for someone else's contact info an=
d you can send someone else's vcard.  Or at least wait to hear who's callin=
g me before sending them my vcard.

-hadriel


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 14:05:37 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InHtc-0003hq-Bf; Wed, 31 Oct 2007 14:02:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InHta-0003fC-A2
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:02:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InHtZ-0003cv-W9
	for sip@ietf.org; Wed, 31 Oct 2007 14:02:25 -0400
Received: from mail86.messagelabs.com ([216.82.244.115])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InHtO-0002Yq-NP
	for sip@ietf.org; Wed, 31 Oct 2007 14:02:20 -0400
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-12.tower-86.messagelabs.com!1193853713!53665743!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.52.151]
Received: (qmail 4113 invoked from network); 31 Oct 2007 18:01:53 -0000
Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151)
	by server-12.tower-86.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Oct 2007 18:01:53 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	l9VI20Q5013666
	for ; Wed, 31 Oct 2007 14:02:01 -0400 (EDT)
In-Reply-To: <28F05913385EAC43AF019413F674A0171246E561@OCCLUST04EVS1.ugd.att.com>
To: "DOLLY, MARTIN C, ATTLABS" 
Subject: RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Wed, 31 Oct 2007 14:01:33 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 10/31/2007 02:00:06 PM,
	Serialize complete at 10/31/2007 02:00:06 PM
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" 
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="===============1185697863=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1185697863==
Content-Type: multipart/alternative;
	boundary="=_alternative 0063040985257385_="

This is a multipart message in MIME format.
--=_alternative 0063040985257385_=
Content-Type: text/plain; charset="US-ASCII"

I also support this, but I have some minor questions/nits.

 I am assuming that the second part of the namespaces (- 000009, -00000A, 
-00000B, etc.) are to be interpreted as "character strings" and not as 
hexadecimal numbers.  But at first glance they LOOK like hex numbers, so 
it might help future readers by pointing it out.

In the first full text paragraph of section 2, it says:
"A namespace from the above list will not be considered for 
   preferential treatment over another namespace unless local policy 
   has configured a SIP entity processing two messages (each with 
   different namespaces) as being equivalent (see section 8 of RFC 4412
   [RFC4412] for this detailed)."

I don't think this should be restricted to "a namespace from the above 
list".  This applies to  ANY namespace (whether one of the currently 
registered ones, one of the ones defined in this ID, or one to be 
standardized in the future).

And then the part that starts "The reality of this is..." would be clearer 
if it said  something like "For the case where they have not been defined 
as equivalent, the reality is..." (Otherwise, a reader might think that 
the antecedent for "this" was  "local policy has configured a SIP entity 
processing two messages (each with  different namespaces) as being 
equivalent".)

The rest of the paragraph talks about a message or call with dsn-000001.8 
not having preferential treatment over a message with dsn-000010.0.  I 
think it would be useful to state (rather than waiting for the reader to 
deduce) that  the call associated with the dsn-000010.0 RPH cannot be 
preempted by, nor can it preempt,  the call associated with the 
dsn-000001.8 namespace.

The next paragraph says:
"The dash '-' character is just like any other character, and is not 
   to be considered a delimiter in any official way within any 
   namespace here.  This MAY change in future efforts."

This use of "MAY" does not seem to be consistent with RFC 2119, so it 
should probably be "may" instead of "MAY". But even with a small "may" it 
is not clear what this means.  If this ID becomes an RFC, and then someone 
wants to register the namespace "A-B-C", what, if any impact will the 
statement "This may change in future efforts" have on the ability to 
register "A-B-C"?

Janet




"DOLLY, MARTIN C, ATTLABS"  
10/31/2007 11:24 AM

To
"DRAGE, Keith (Keith)" , "IETF SIP List" 

cc

Subject
RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00






We support this. 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] 
Sent: Wednesday, October 31, 2007 10:30 AM
To: IETF SIP List
Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

(As SIP WG chair)

Keeping up the pressure on you people out there doing the reviewing.

This is to announce a WGLC for 

"IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Header Namespaces"

Contained in 

http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00
.txt

The Working group last call is for two weeks until close of business on
Wednesday 14th November 2007.

Please submit any comments to the SIP list and to the editor.

I have solicited a number of independent reviews in parallel to this,
for which some have already been provided. These will be taken into
account in the WGLC.

Regards

Keith


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


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 0063040985257385_=
Content-Type: text/html; charset="US-ASCII"





I also support this, but I have some minor questions/nits.



 I am assuming that the second
part of the namespaces (- 000009, -00000A, -00000B, etc.) are to be interpreted
as "character strings" and not as hexadecimal numbers.  But
at first glance they LOOK like hex numbers, so it might help future readers
by pointing it out.



In the first full text paragraph of
section 2, it says:

"A namespace from the above list
will not be considered for 

   preferential treatment
over another namespace unless local policy 

   has configured a SIP entity
processing two messages (each with 

   different namespaces) as
being equivalent (see section 8 of RFC 4412

   [RFC4412] for this detailed)."



I don't think this should be restricted
to "a namespace from the above list".  This applies to  ANY
namespace (whether one of the currently registered ones, one of the ones
defined in this ID, or one to be standardized in the future).



And then the part that starts "The
reality of this is..." would be clearer if it said  something
like "For the case where they have not been defined as equivalent,
the reality is..." (Otherwise, a reader might think that the antecedent
for "this" was  "local policy has configured a SIP
entity processing two messages (each with  different namespaces) as
being equivalent".)



The rest of the paragraph talks about
a message or call with dsn-000001.8 not having preferential treatment over
a message with dsn-000010.0.  I think it would be useful to state
(rather than waiting for the reader to deduce) that  the call associated
with the dsn-000010.0 RPH cannot be preempted by, nor can it preempt,  the
call associated with the dsn-000001.8 namespace.



The next paragraph says:

"The dash '-' character is just
like any other character, and is not 

   to be considered a delimiter
in any official way within any 

   namespace here.  This
MAY change in future efforts."



This use of "MAY" does not
seem to be consistent with RFC 2119, so it should probably be "may"
instead of "MAY". But even with a small "may" it is
not clear what this means.  If this ID becomes an RFC, and then someone
wants to register the namespace "A-B-C", what, if any impact
will the statement "This may change in future efforts" have on
the ability to register "A-B-C"?



Janet












"DOLLY, MARTIN C,
ATTLABS" <mdolly@att.com> 

10/31/2007 11:24 AM








To

"DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>,
"IETF SIP List" <sip@ietf.org>




cc






Subject

RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

















We support this. 



-----Original Message-----

From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] 

Sent: Wednesday, October 31, 2007 10:30 AM

To: IETF SIP List

Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00



(As SIP WG chair)



Keeping up the pressure on you people out there doing the reviewing.



This is to announce a WGLC for 



"IANA Registration of New Session Initiation Protocol (SIP)

Resource-Priority Header Namespaces"



Contained in 



http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00

.txt



The Working group last call is for two weeks until close of business on

Wednesday 14th November 2007.



Please submit any comments to the SIP list and to the editor.



I have solicited a number of independent reviews in parallel to this,

for which some have already been provided. These will be taken into

account in the WGLC.



Regards



Keith





_______________________________________________

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol

Use sip-implementors@cs.columbia.edu for questions on current sip

Use sipping@ietf.org for new developments on the application of sip





_______________________________________________

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP 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 0063040985257385_=--



--===============1185697863==
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
--===============1185697863==--





From sip-bounces@ietf.org Wed Oct 31 14:27:51 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InIFv-000825-Ky; Wed, 31 Oct 2007 14:25:31 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InIFu-000820-G8
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:25:30 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InIFu-00081s-4f
	for sip@ietf.org; Wed, 31 Oct 2007 14:25:30 -0400
Received: from mail145.messagelabs.com ([216.82.245.115])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InIFt-0000xs-Dv
	for sip@ietf.org; Wed, 31 Oct 2007 14:25:30 -0400
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-4.tower-145.messagelabs.com!1193855127!8366462!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.52.151]
Received: (qmail 3444 invoked from network); 31 Oct 2007 18:25:28 -0000
Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151)
	by server-4.tower-145.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Oct 2007 18:25:28 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	l9VIPpEk011498
	for ; Wed, 31 Oct 2007 14:25:51 -0400 (EDT)
In-Reply-To: 
To: Henning Schulzrinne 
Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn 
Message-ID: 
Date: Wed, 31 Oct 2007 14:25:23 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF180|March 29, 2007) at 10/31/2007 02:23:56 PM,
	Serialize complete at 10/31/2007 02:23:56 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
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: ,
	
Content-Type: multipart/mixed; boundary="===============1389500502=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============1389500502==
Content-Type: multipart/alternative;
	boundary="=_alternative 0065328485257385_="

This is a multipart message in MIME format.
--=_alternative 0065328485257385_=
Content-Type: text/plain; charset="US-ASCII"

In line


Henning Schulzrinne  wrote on 10/25/2007 11:01:40 PM:

> Keith asked me to review the draft; here are a few quick comments:
 
> Why priority values that are even only?

Priority values are completely arbitrary.  If you wanted to, you could 
have priority values

YP17
42
-Pi
i
e


> 
> The wording is somewhat redundant, with the same information repeated 
> three times, but in slightly different ways. In particular, the 
> notion of non-preemption across namespaces seems to be couched in 
> caveats. It seems that preemption across namespaces is sometimes 
> permitted and sometimes not, which makes it rather difficult to build 
> an implementation for the namespace without either a lot of 
> configuration options or special software versions for each policy. 
> We have seen in other areas that excessive configurability leads to 
> interoperability problems and code complexity. I have a hard time 
> picturing how to build such a configurable system without a monster 
> language and all kinds of strange interactions. What happens if 
> namespace 30 can preempt namespace 28, and vice versa? What about 
> circular preemption chains (30 -> 17 -> 10)? In those cases, do 
> namespaces have absolute priority, i.e., any priority in 30 beats any 
> priority in 28? You'd have to create a matrix with 250 by 250 entries
>

I guess I am reading it somewhat differently from you.

I read nothing that suggests that one namespace (as a whole)can preempt 
another namespace.  In fact that is explicitly forbidden.

What is discussed as a possibility (consistent with RFC 4412)is making two 
or more namespaces "equivalent".   For instance, if you make dsn-000001 
and dsn-00000A "equivalent" then dsn-000001.0 and dsn-00000A.0 would be 
completely equal in priority. 

Similarly dsn-000001.8 and dsn-00000A.8 would be completely equivalent in 
priority.

In this case dsn-000001.0 could neither preempt, not be preempted by, 
dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER dsn-000001.8 
OR by dsn-00000A.8.

And dsn-000001.8  neither preempt, not be preempted by, dsn-00000A.8.  But 
dsn-000001.8 could preempt EITHER dsn-000001.0 OR dsn-00000A.0

Janet

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

--=_alternative 0065328485257385_=
Content-Type: text/html; charset="US-ASCII"





In line





Henning Schulzrinne <hgs@cs.columbia.edu> wrote
on 10/25/2007 11:01:40 PM:



> Keith asked me to review the draft; here are a few quick comments:

  

> Why priority values that are even only?



Priority values are completely arbitrary.  If
you wanted to, you could have priority values



YP17

42

-Pi

i

e





> 

> The wording is somewhat redundant, with the same information repeated
 

> three times, but in slightly different ways. In particular, the  

> notion of non-preemption across namespaces seems to be couched in
 

> caveats. It seems that preemption across namespaces is sometimes  

> permitted and sometimes not, which makes it rather difficult to build
 

> an implementation for the namespace without either a lot of  

> configuration options or special software versions for each policy.
 

> We have seen in other areas that excessive configurability leads to
 

> interoperability problems and code complexity. I have a hard time
 

> picturing how to build such a configurable system without a monster
 

> language and all kinds of strange interactions. What happens if  

> namespace 30 can preempt namespace 28, and vice versa? What about
 

> circular preemption chains (30 -> 17 -> 10)? In those cases,
do  

> namespaces have absolute priority, i.e., any priority in 30 beats
any  

> priority in 28? You'd have to create a matrix with 250 by 250 entries

>



I guess I am reading it somewhat differently
from you.



I read nothing that suggests that one namespace (as
a whole)can preempt another namespace.  In fact that is explicitly
forbidden.



What is discussed as a possibility (consistent with
RFC 4412)is making two or more namespaces "equivalent".  
For instance, if you make dsn-000001 and dsn-00000A "equivalent"
then dsn-000001.0 and dsn-00000A.0 would be completely equal in priority.




Similarly dsn-000001.8 and dsn-00000A.8 would be completely
equivalent in  priority.



In this case dsn-000001.0 could neither preempt, not
be preempted by, dsn-00000A.0.  But dsn-000001.0 could be preempted
by EITHER dsn-000001.8 OR by dsn-00000A.8.



And dsn-000001.8  neither preempt, not be preempted
by, dsn-00000A.8.  But dsn-000001.8 could preempt EITHER dsn-000001.0
OR dsn-00000A.0



Janet



> 

> 

> Henning

> 

> 

> _______________________________________________

> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

> This list is for NEW development of the core SIP Protocol

> Use sip-implementors@cs.columbia.edu for questions on current sip

> Use sipping@ietf.org for new developments on the application of sip


--=_alternative 0065328485257385_=--



--===============1389500502==
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
--===============1389500502==--





From sip-bounces@ietf.org Wed Oct 31 17:31:38 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InL5q-0001bF-64; Wed, 31 Oct 2007 17:27:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InL5p-0001Z0-4j
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 17:27:17 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InL5o-0001Y3-P8
	for sip@ietf.org; Wed, 31 Oct 2007 17:27:16 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InL5n-000176-RO
	for sip@ietf.org; Wed, 31 Oct 2007 17:27:16 -0400
X-IronPort-AV: E=Sophos;i="4.21,352,1188802800"; d="scan'208";a="29028794"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-1.cisco.com with ESMTP; 31 Oct 2007 14:27:17 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VLRD7m022205; 
	Wed, 31 Oct 2007 14:27:13 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9VLQxZs023572;
	Wed, 31 Oct 2007 21:27:13 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 14:27:08 -0700
Received: from jmpolk-wxp.cisco.com ([10.89.16.29]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 14:27:07 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 31 Oct 2007 16:27:05 -0500
To: Janet P Gunn , "DOLLY, MARTIN C, ATTLABS" 
From: "James M. Polk" 
Subject: RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
In-Reply-To: 
References: <28F05913385EAC43AF019413F674A0171246E561@OCCLUST04EVS1.ugd.att.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 31 Oct 2007 21:27:07.0915 (UTC)
	FILETIME=[CA46E5B0:01C81C04]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5618; t=1193866033;
	x=1194730033; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20RE=3A=20[Sip]=20WGLC=20for=20draft-ietf-sip-rph-new-namespace
	s-00 |Sender:=20;
	bh=eBGxqUnNkYkGYtwAzN89IzltW0pbT1ASLck79kSiWmQ=;
	b=MxpzxODO7JnvHNK8Eth35JZD5GrxsdDd3wL+v+RbITCtFDto5NoCY1YrA1W4t4aCcn5sTOxM
	INIY60yOTgF+7+QMUlo5L6fX1CQ1QxZjzHD69xB4sUJTnPrEzjIcBAVb;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Cc: IETF SIP List , "DRAGE,
	Keith \(Keith\)" 
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: ,
	
Errors-To: sip-bounces@ietf.org

Janet

Comments in-line

At 01:01 PM 10/31/2007, Janet P Gunn wrote:


>I also support this, but I have some minor questions/nits.
>
>  I am assuming that the second part of the namespaces (- 000009, 
> -00000A, -00000B, etc.) are to be interpreted as "character 
> strings" and not as hexadecimal numbers.  But at first glance they 
> LOOK like hex numbers, so it might help future readers by pointing it out.

from your examples above, all of
         "dsn-000009" and "dsn-00000A" and "dsn-00000B"

are singular, wholly separate and complete RPH namespaces.

The ' - ' is not a delimiter character, but is a character, as are 
the 0s and As and Bs.


>In the first full text paragraph of section 2, it says:
>"A namespace from the above list will not be considered for
>    preferential treatment over another namespace unless local policy
>    has configured a SIP entity processing two messages (each with
>    different namespaces) as being equivalent (see section 8 of RFC 4412
>    [RFC4412] for this detailed)."
>
>I don't think this should be restricted to "a namespace from the 
>above list".  This applies to  ANY namespace (whether one of the 
>currently registered ones, one of the ones defined in this ID, or 
>one to be standardized in the future).

this is a fair comment, and I will change the text to mean what you state here.


>And then the part that starts "The reality of this is..." would be 
>clearer if it said  something like "For the case where they have not 
>been defined as equivalent, the reality is..." (Otherwise, a reader 
>might think that the antecedent for "this" was  "local policy has 
>configured a SIP entity processing two messages (each 
>with  different namespaces) as being equivalent".)

I will make this clearer


>The rest of the paragraph talks about a message or call with 
>dsn-000001.8 not having preferential treatment over a message with 
>dsn-000010.0.  I think it would be useful to state (rather than 
>waiting for the reader to deduce) that  the call associated with the 
>dsn-000010.0 RPH cannot be preempted by, nor can it preempt,  the 
>call associated with the dsn-000001.8 namespace.

...unless local policy states this is the case (according to section 
8 of RFC 4412).

I will clean this up too


>The next paragraph says:
>"The dash '-' character is just like any other character, and is not
>    to be considered a delimiter in any official way within any
>    namespace here.  This MAY change in future efforts."
>
>This use of "MAY" does not seem to be consistent with RFC 2119, so 
>it should probably be "may" instead of "MAY".

no, I used "MAY" here to mean that there can be an update of this 
document in the future changing this statement (from the ' - ' not 
being a delimiter, to becoming a delimiter). This MAY is to let 
implementors know a future RFC can change this.

>But even with a small "may" it is not clear what this means.  If 
>this ID becomes an RFC, and then someone wants to register the 
>namespace "A-B-C", what, if any impact will the statement "This may 
>change in future efforts" have on the ability to register "A-B-C"?

For now, the  ' - ' (dash character) is just a normal character, and 
shouldn't be considered a delimiter, unless this future document 
changes this rule in such a way that reverse compatibility can be 
addressed successfully.

Does this help?


>Janet
>
>
>
>"DOLLY, MARTIN C, ATTLABS" 
>
>10/31/2007 11:24 AM
>To
>"DRAGE, Keith (Keith)" , "IETF SIP List" 
>
>cc
>Subject
>RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
>
>
>
>
>We support this.
>
>-----Original Message-----
>From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>Sent: Wednesday, October 31, 2007 10:30 AM
>To: IETF SIP List
>Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
>
>(As SIP WG chair)
>
>Keeping up the pressure on you people out there doing the reviewing.
>
>This is to announce a WGLC for
>
>"IANA Registration of New Session Initiation Protocol (SIP)
>Resource-Priority Header Namespaces"
>
>Contained in
>
>http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00
>.txt
>
>The Working group last call is for two weeks until close of business on
>Wednesday 14th November 2007.
>
>Please submit any comments to the SIP list and to the editor.
>
>I have solicited a number of independent reviews in parallel to this,
>for which some have already been provided. These will be taken into
>account in the WGLC.
>
>Regards
>
>Keith
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 17:52:36 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InLRj-00007A-Uu; Wed, 31 Oct 2007 17:49:55 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InLRi-000067-5E
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 17:49:54 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InLRh-0008W6-Ow
	for sip@ietf.org; Wed, 31 Oct 2007 17:49:53 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InLRh-0001pi-FL
	for sip@ietf.org; Wed, 31 Oct 2007 17:49:53 -0400
X-IronPort-AV: E=Sophos;i="4.21,353,1188792000"; d="scan'208";a="135937525"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 31 Oct 2007 17:49:53 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9VLnrQM015814; 
	Wed, 31 Oct 2007 17:49:53 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9VLnif3004756; 
	Wed, 31 Oct 2007 21:49:53 GMT
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.1830); 
	Wed, 31 Oct 2007 17:49:49 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.29]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 17:49:48 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 31 Oct 2007 16:49:47 -0500
To: Janet P Gunn , Henning Schulzrinne 
From: "James M. Polk" 
Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces
In-Reply-To: 
References: 
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 31 Oct 2007 21:49:48.0820 (UTC)
	FILETIME=[F5708540:01C81C07]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15516.002
X-TM-AS-Result: No--12.997200-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=340; t=1193867393;
	x=1194731393; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-rph-new-namespaces
	|Sender:=20 |To:=20Janet=20P=20Gunn=20,
	=20Henning=20Schulzrinne=20;
	bh=RqmC86sCixoGbZsKUWL2956EjwLnorCRML354JG+MIM=;
	b=liM5QVLlZyp8V6IoBBAfNZTAFa++JP0F0ljMTziEIcRwkl/ZJLU7mhtdXxDC+TWyLoIf/+zg
	gFnrqcJ893SN4JSEUhMXiVQFifuPZb2XY28w5VaGXLowuG6ILmKwOlT7;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
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: ,
	
Errors-To: sip-bounces@ietf.org


>Henning Schulzrinne  wrote on 10/25/2007 11:01:40 PM:
>
> > Keith asked me to review the draft; here are a few quick comments:
>
> > Why priority values that are even only?

I am changing the priority-value range to be 0-9, so all currently 
envisioned priority-values are in this doc, for these namespaces.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 17:59:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InLZY-0004Fm-5A; Wed, 31 Oct 2007 17:58:00 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InLZW-0004C9-CQ
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 17:57:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InLZV-0004Bw-SV
	for sip@ietf.org; Wed, 31 Oct 2007 17:57:58 -0400
Received: from jalapeno.cc.columbia.edu ([128.59.29.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLZP-0006oo-OT
	for sip@ietf.org; Wed, 31 Oct 2007 17:57:57 -0400
Received: from [172.16.139.45] (sjcc176x121.sjccnet.com [216.1.176.121])
	(user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id
	l9VLvXpI028514
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 31 Oct 2007 17:57:34 -0400 (EDT)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces
Date: Wed, 31 Oct 2007 17:57:32 -0400
To: Janet P Gunn 
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
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: ,
	
Errors-To: sip-bounces@ietf.org


On Oct 31, 2007, at 2:25 PM, Janet P Gunn wrote:
>
>
> > Why priority values that are even only?
>
> Priority values are completely arbitrary.  If you wanted to, you  
> could have priority values
>
> YP17
> 42
> -Pi
> i
> e
>

I'm not concerned about the specific labels; it is hard to review a  
draft when one has no idea *why* things are being done. Why 10 levels  
as opposed to 5 or 7?

>
> I read nothing that suggests that one namespace (as a whole)can  
> preempt another namespace.  In fact that is explicitly forbidden.
>

The draft talks a lot about local policy.

> What is discussed as a possibility (consistent with RFC 4412)is  
> making two or more namespaces "equivalent".   For instance, if you  
> make dsn-000001 and dsn-00000A "equivalent" then dsn-000001.0 and  
> dsn-00000A.0 would be completely equal in priority.
>

I didn't find this in the draft, so maybe it should be called out  
more visibly.


> Similarly dsn-000001.8 and dsn-00000A.8 would be completely  
> equivalent in  priority.
>
> In this case dsn-000001.0 could neither preempt, not be preempted  
> by, dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER  
> dsn-000001.8 OR by dsn-00000A.8.
>
> And dsn-000001.8  neither preempt, not be preempted by, dsn-00000A. 
> 8.  But dsn-000001.8 could preempt EITHER dsn-000001.0 OR dsn-00000A.0
>

Again, without any notion of what all this is supposed to accomplish  
it's hard to do more than a syntax review and spell checking.

Henning




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



From sip-bounces@ietf.org Wed Oct 31 18:46:45 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InMGr-0001Ob-0a; Wed, 31 Oct 2007 18:42:45 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InMGp-0001O8-J4
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 18:42:43 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InMGo-0001NO-R0
	for sip@ietf.org; Wed, 31 Oct 2007 18:42:42 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMGo-0004Dv-9C
	for sip@ietf.org; Wed, 31 Oct 2007 18:42:42 -0400
X-IronPort-AV: E=Sophos;i="4.21,353,1188802800"; d="scan'208";a="29047928"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-1.cisco.com with ESMTP; 31 Oct 2007 15:42:41 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9VMgf1W022946; 
	Wed, 31 Oct 2007 15:42:41 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9VMgYZi001074;
	Wed, 31 Oct 2007 22:42:41 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 15:42:31 -0700
Received: from jmpolk-wxp.cisco.com ([10.89.16.29]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Oct 2007 15:42:31 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 31 Oct 2007 17:42:28 -0500
To: Henning Schulzrinne , Janet P Gunn 
From: "James M. Polk" 
Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces
In-Reply-To: 
References: 
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: 
X-OriginalArrivalTime: 31 Oct 2007 22:42:31.0231 (UTC)
	FILETIME=[526224F0:01C81C0F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3262; t=1193870561;
	x=1194734561; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20
	|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-rph-new-namespaces
	|Sender:=20; bh=DVI7xH++kFtquchck+5SnZ6NAX9ks2Gv7IeBucW1PSI=;
	b=Cyb8dRtCkF/HwZpUG6c/U52IhadJzT82+eTefCt/k/yznw3YK+uOZMjS0jUKyD24fEfYI9Az
	Prd/oIzvkA4H9UmJre0Fc5CcPgIDQcnFsemaws1BXtJ6OiaXZm76P6IP;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
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: ,
	
Errors-To: sip-bounces@ietf.org

Henning

DISA wants to have 50 new namespaces within their network. It seems 
the 2 we had in RFC 4412 weren't enough for their plans. Don't ask me 
why we didn't know about this long ago, but some within that 
organization had this planned many years ago.

In a nutshell, they want to be able to assign different RPH 
namespaces to different branches of service (army, navy, air force, 
marines) as well as have temporary assignments to individual units 
(say, one task force, which is separate than the branch of 
service).  They came up with 50 as a good number to have at their disposal.

They have also upped the number of priority-values needed, with each 
namespace having the same number (0 through 9).  The even numbers 
were there because those are the only ones they plan on using for the 
next several years. The old numbers are for future use.  This draft 
should account for all that is known to be planned.

I've tried to remove any new usage rules from this draft, but leave 
in a few reminders about section 8 of 4412, so someone just looking 
at this wouldn't see those rules not mentioned.

I have a -01 available that calls out (more clearly) the equivalency 
rules within section 8 of 4412.  This new version also reduces the 
reminders of this to within one section of the draft.

Does this help?

James

At 04:57 PM 10/31/2007, Henning Schulzrinne wrote:

>On Oct 31, 2007, at 2:25 PM, Janet P Gunn wrote:
>>
>>
>> > Why priority values that are even only?
>>
>>Priority values are completely arbitrary.  If you wanted to, you
>>could have priority values
>>
>>YP17
>>42
>>-Pi
>>i
>>e
>
>I'm not concerned about the specific labels; it is hard to review a
>draft when one has no idea *why* things are being done. Why 10 levels
>as opposed to 5 or 7?
>
>>
>>I read nothing that suggests that one namespace (as a whole)can
>>preempt another namespace.  In fact that is explicitly forbidden.
>
>The draft talks a lot about local policy.
>
>>What is discussed as a possibility (consistent with RFC 4412)is
>>making two or more namespaces "equivalent".   For instance, if you
>>make dsn-000001 and dsn-00000A "equivalent" then dsn-000001.0 and
>>dsn-00000A.0 would be completely equal in priority.
>
>I didn't find this in the draft, so maybe it should be called out
>more visibly.
>
>
>>Similarly dsn-000001.8 and dsn-00000A.8 would be completely
>>equivalent in  priority.
>>
>>In this case dsn-000001.0 could neither preempt, not be preempted
>>by, dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER
>>dsn-000001.8 OR by dsn-00000A.8.
>>
>>And dsn-000001.8  neither preempt, not be preempted by, dsn-00000A. 
>>8.  But dsn-000001.8 could preempt EITHER dsn-000001.0 OR dsn-00000A.0
>
>Again, without any notion of what all this is supposed to accomplish
>it's hard to do more than a syntax review and spell checking.
>
>Henning
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
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 31 20:09:31 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InNXm-0001ob-Ae; Wed, 31 Oct 2007 20:04:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1InNXj-0001mO-Tb
	for sip-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 20:04:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InNXj-0001es-Il
	for sip@ietf.org; Wed, 31 Oct 2007 20:04:15 -0400
Received: from jalapeno.cc.columbia.edu ([128.59.29.5])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InNXe-0007ux-16
	for sip@ietf.org; Wed, 31 Oct 2007 20:04:10 -0400
Received: from [172.16.139.45] (sjcc176x121.sjccnet.com [216.1.176.121])
	(user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id
	lA1045LS018879
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 31 Oct 2007 20:04:06 -0400 (EDT)
In-Reply-To: 
References: 
	
	
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0E385FBE-D61A-4DE5-A780-EF7402F5DE29@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces
Date: Wed, 31 Oct 2007 20:04:03 -0400
To: "James M. Polk" 
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: IETF SIP List , Janet P Gunn 
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: ,
	
Errors-To: sip-bounces@ietf.org

James,

thanks for the explanation. I think it would be useful to identify  
who is asking for this and why, so that others can judge whether they  
can use the same namespace or not. I don't think we want some other  
draft in a year that has

foobar-00
through
foobar-49

Henning

On Oct 31, 2007, at 6:42 PM, James M. Polk wrote:

> Henning
>
> DISA wants to have 50 new namespaces within their network. It seems  
> the 2 we had in RFC 4412 weren't enough for their plans. Don't ask  
> me why we didn't know about this long ago, but some within that  
> organization had this planned many years ago.
>
> In a nutshell, they want to be able to assign different RPH  
> namespaces to different branches of service (army, navy, air force,  
> marines) as well as have temporary assignments to individual units  
> (say, one task force, which is separate than the branch of  
> service).  They came up with 50 as a good number to have at their  
> disposal.
>
> They have also upped the number of priority-values needed, with  
> each namespace having the same number (0 through 9).  The even  
> numbers were there because those are the only ones they plan on  
> using for the next several years. The old numbers are for future  
> use.  This draft should account for all that is known to be planned.
>
> I've tried to remove any new usage rules from this draft, but leave  
> in a few reminders about section 8 of 4412, so someone just looking  
> at this wouldn't see those rules not mentioned.
>
> I have a -01 available that calls out (more clearly) the  
> equivalency rules within section 8 of 4412.  This new version also  
> reduces the reminders of this to within one section of the draft.
>
> Does this help?
>
> James
>
> At 04:57 PM 10/31/2007, Henning Schulzrinne wrote:
>
>> On Oct 31, 2007, at 2:25 PM, Janet P Gunn wrote:
>>>
>>>
>>> > Why priority values that are even only?
>>>
>>> Priority values are completely arbitrary.  If you wanted to, you
>>> could have priority values
>>>
>>> YP17
>>> 42
>>> -Pi
>>> i
>>> e
>>
>> I'm not concerned about the specific labels; it is hard to review a
>> draft when one has no idea *why* things are being done. Why 10 levels
>> as opposed to 5 or 7?
>>
>>>
>>> I read nothing that suggests that one namespace (as a whole)can
>>> preempt another namespace.  In fact that is explicitly forbidden.
>>
>> The draft talks a lot about local policy.
>>
>>> What is discussed as a possibility (consistent with RFC 4412)is
>>> making two or more namespaces "equivalent".   For instance, if you
>>> make dsn-000001 and dsn-00000A "equivalent" then dsn-000001.0 and
>>> dsn-00000A.0 would be completely equal in priority.
>>
>> I didn't find this in the draft, so maybe it should be called out
>> more visibly.
>>
>>
>>> Similarly dsn-000001.8 and dsn-00000A.8 would be completely
>>> equivalent in  priority.
>>>
>>> In this case dsn-000001.0 could neither preempt, not be preempted
>>> by, dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER
>>> dsn-000001.8 OR by dsn-00000A.8.
>>>
>>> And dsn-000001.8  neither preempt, not be preempted by,  
>>> dsn-00000A. 8.  But dsn-000001.8 could preempt EITHER  
>>> dsn-000001.0 OR dsn-00000A.0
>>
>> Again, without any notion of what all this is supposed to accomplish
>> it's hard to do more than a syntax review and spell checking.
>>
>> Henning
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip



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