From pkyzivat@cisco.com Mon Nov 2 06:07:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D1C3A686D for ; Mon, 2 Nov 2009 06:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntBvnYWIDbyo for ; Mon, 2 Nov 2009 06:07:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D8F253A659B for ; Mon, 2 Nov 2009 06:07:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFN27kpAZnwN/2dsb2JhbADFGpZahDkE X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="scan'208";a="65967783" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2009 14:07:47 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA2E7lSp018638; Mon, 2 Nov 2009 14:07:47 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.3959); Mon, 2 Nov 2009 09:07:47 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 09:07:46 -0500 Message-ID: <4AEEE7B5.60301@cisco.com> Date: Mon, 02 Nov 2009 09:07:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AE9A6CD.80907@cisco.com> <4AEAFA5D.4080204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2009 14:07:46.0659 (UTC) FILETIME=[DA893330:01CA5BC5] Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:07:29 -0000 responses inline. Thanks, Paul Christer Holmberg wrote: > Hi, > >>> You would have to send an extra re-INVITE/UPDATE just because you >>> couldn't send the I-P list in the ACK. Or? >>> >>> And, if there are no rules one can of course send a list both in the >>> INVITE and the ACK. I don't know if that is likely to happen, but if >>> the ACK trigger the remote entity's list to change it would have to >>> trigger a request in order to change the list, since there is no >>> response to ACK. >> But this is not a negotiation, just a declaration. >> So what harm is there in changing between INVITE and ACK? >> (As unlikely as that seems.) > > Maybe it works. > > But, would it then also be allowed to send one list in a reliable 18x, > and then a new list in the next relaible 18x, and then a third list in > the 200 OK - all for the same transaction? What bad things happen if you do that? The worst thing I can see is that you might get sent an I-P you don't want to receive. Then you just ignore it, or send a 469, and go on about your business. Perhaps its more trouble on the sending side, though its hard to generalize. Consider the specific case of DTMF. A UA may be trying to decide how to set itself up to send DTMF, choosing from among the multitude of ways that are possible. If it gets a change - adding or removing a DTMF info package, then it may have to change other things as well, such as adding or removing telephone-events from its media types. But, that problem exists whether or not we we allow changes in R-I between responses, so its not a big deal. > OR, should we have a rule saying that a UA can send at most one list per > transaction? I could live with either way, but prefer not to impose arbitrary rules that are not strongly motivated. >>> So, maybe we should say that the I-P list can only be sent in INV OR >>> ACK, or that the I-P list must be identical if sent in both INV AND > ACK. >> I don't feel strongly about it. But every additional requirement is > something else to test. >>> However, as always, issues can arise from 3pcc. A UA may receive a >>> reinvite, and think nothing has changed, but in reality what is >>> changing is that it has a peer UA that is not aware of its R-I >>> settings. >>> So I think it should be recommended that R-I always be sent in >>> response to a reinvite. >> Of course, that would require that the R-I header has previously been >> used during the dialog. Otherwise the UAS won't even know whether the >> sender supports I-P. >> >> Which dialog? Since this is 3pcc, and the interesting case is a > transfer, there are *3* dialogs. >> It should never hurt to send an R-I in the context of a response to a > reinvite. > > The draft says that you don't send a list unless you know that the other > party - for that dialog - supports the mechanism. In 3pcc that can be a problem. You don't ever know if you are talking to the same party that you were last time. >> There may indeed be a problem in one case. Here's a picture to refer > to: >> A ----- B ----- C >> | >> --- D >> >> Initially A is connected, via B to C. Then B initiates a 3pcc transfer > by sending a reinvite to A. >> Now suppose that both A and C support I-P, but D does not. How will A > ever learn that D does not? It won't receive an R-I header from D, and > so will assume its unchanged from what it had from C. And when >> it sends INFOs with an I-P, D will think they are legacy. It will never > send a 469, so it won't quench the sending. > > I assume B has contected D before it sends the re-INVITE to A, right? There are lots of ways to do it, depending on the goals of the case. So maybe yes, maybe no. > So, if D does NOT support I-P, I guess B would have to include R-I:nil > in the re-INVITE to A. That means it won't work correctly unless B itself has an understanding of info packages. It would be better if that were not a requirement. > A will of course still think that D supports I-P, but that D is not > willing to receive any I-Ps. A good reason for ensuring that there is no functional difference between those two cases. >>>> Also, to cover the case where the two ends get out of sync for some > reason, I think it should be allowed, and suggested or required, to >>>> include R-I in a 469 response. >>> At the moment my intention is to require it. >> OK, that's good. I didn't even see it allowed in the 469 response in > Table 2 updates. > > It wasn't :) > > Regards, > > Christer > > From taisto.xx.qvist@ericsson.com Mon Nov 2 06:57:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0013628C14B for ; Mon, 2 Nov 2009 06:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux6MDdppWfsZ for ; Mon, 2 Nov 2009 06:57:26 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A9DE33A657C for ; Mon, 2 Nov 2009 06:57:25 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-44-4aeef3671510 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E7.61.24026.763FEEA4; Mon, 2 Nov 2009 15:57:44 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 15:57:43 +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: Mon, 2 Nov 2009 15:57:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing contact/remote target in target refresh response Thread-Index: AcpbzNPXgM3NSEsmR/yd22A8KLoJzA== From: "Taisto Qvist XX" To: X-OriginalArrivalTime: 02 Nov 2009 14:57:43.0870 (UTC) FILETIME=[D5034DE0:01CA5BCC] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:57:27 -0000 Hi folks,=20 =20 I am in a discussion with a firewall provider, regarding the "legality" for a UAS=20 to use different Contact: uri's in 1xx and 2xx for the same transaction/dialog. =20 I claim that you MUST use the same Contact in the 2xx as was sent the 1xx.=20 Unfortunately I cant give him an explicit reference, since there is none(afaik?) Instead I must indicate chapters that indicate that UAS must initialize dialog state=20 on reception of the 1xx, and that on reception of 2xx, the only thing that is recomputed,=20 is the routeset. The firewall provider is not convinced. =20 Also the text in 3261, 12.1.1 indicates(?) that the Contact should be the same in 2xx and 1xx. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 Now to my question, or sort of... Is a target refresh used by the UAC, and implicit target refresh possibility also for the UAS? In other words, is the response to a target refresh request, a "response target refresh"? Can the UAS add a new Contact in the 2xx response to a target refresh, and assume that the UAC=20 updates its remote target? I've read Gonzalo Camarillo's draft, but it doesnt really mention this scenario. If the UAS can change his Contact, then I've become puzzled on what I should add in the final 2xx=20 to an initial INVITE, if both sides(uas/uac) have updated their contacts during an UPDATE-target=20 refresh in the early dialog. The flow would be 1) INVITE from A -> B (contact:a1) 2) 18x from B -> A (contact:b1) + prack, early media, go figure... 3) UPDATE from A -> B (contact:a2) 4) 2xx(UPD) from B -> A (contact:b2) << "target refresh response" 5) 2xx(INV) from B -> A (contact......b2 or b1?) 6) ACK-time..remote target is b2... If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the answer, but at the same time,=20 the ACK must be sent to b2.... Any feedback you can give me would be much appreciated.=20 Regards Taisto Qvist IP-Solutions From BPenfield@acmepacket.com Mon Nov 2 06:59:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469D63A67D8 for ; Mon, 2 Nov 2009 06:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxoe4PENhiAp for ; Mon, 2 Nov 2009 06:59:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 331023A6A18 for ; Mon, 2 Nov 2009 06:59:49 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 2 Nov 2009 10:00:08 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Nov 2009 10:00:00 -0500 From: Bob Penfield To: Christer Holmberg , "sipcore@ietf.org" Date: Mon, 2 Nov 2009 09:59:39 -0500 Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info Thread-Index: AcpYbX5IWBYQjtn3QL6DGTrCTkFCngDW34jQ Message-ID: <429446390BA91242867940DBE798A06B740334DFF7@mail> 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 Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:59:50 -0000 1) REFER and SUBSCRIBE can be sent on a dialog that has an INVITE usage, bu= t they are associated with the subscription usage, not the INVITE usage. Th= erefore, Recv-Info should not be allowed on SUBSCRIBE, REFER, or NOTIFY. 2) I think being able to update Recv-Info in PRACK and ACK is useful (e.g. = 3pcc for ACK). 3) Recv-Info is not an offer/answer negotiation. In fact, it is really an a= dvertisement rather than a negotiation. The content of the Recv-Info affect= s what the far end can send, not what the near end (the Recv-Info sender) c= an send. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Thursday, October 29, 2009 3:58 AM To: sipcore@ietf.org Subject: [sipcore] Info Even Open Issue: Method types and offer/answer for = Recv-Info Hi, =20 I have got WGLC comments from different people regarding the request method= s in which we allow the Recv-Info header field.=20 =20 It IS related to something we have discussed before, but I want to point it= out, to make sure we can agree on a view. =20 1) REF and SUB ------------------------ =20 There has been some comments and question about whether we should allow the= R-I header field in REF and SUB. =20 Now, both REF and SUB are target refresh requests, and CAN be sent within a= n invite dialog usage. However, I assume the dialog-usage RFC recommends ag= ainst doing so. =20 =20 2) ACK and PRA ------------------------- =20 Keith suggested we shouldn't allow the header in ACK and PRA either. =20 Personally I would not like to make that restriction at this point, unless = there is a good technical reason, but I would like to hear what other peopl= e think. =20 =20 3) "offer/answer" ----------------------- =20 The draft currently does not define o/a type-of rules when UAs are to indic= ate their Info Package set (using the Recv-Info header field). =20 Personally I don't think we need to define a "o/a" rules for Recv-Info. We = only need to indicate in which message the header field is allowed. =20 We could say that, when a UA receives the I-P set from the remote user, it = is recommend that it sends back its own set as soon as possible - if the se= t has changed. =20 Because, if the set hasn't changed I don't think the UA needs to send back = anything, which means that whatever set it has sent before within that dial= og is still valid. That is the biggest difference compared to o/a, which al= ways requires the receiver to send its SDP back - even if nothing has chang= ed. =20 =20 Regards, =20 Christer =20 =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Nov 2 12:22:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FFA3A691E for ; Mon, 2 Nov 2009 12:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+P0sSZrB2n6 for ; Mon, 2 Nov 2009 12:22:37 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1683C3A68C7 for ; Mon, 2 Nov 2009 12:22:36 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-77-4aef3f9f3e1c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 90.79.04191.F9F3FEA4; Mon, 2 Nov 2009 21:22:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:22:12 +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: Mon, 2 Nov 2009 21:21:17 +0100 Message-ID: In-Reply-To: <429446390BA91242867940DBE798A06B740334DFF7@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: AcpYbX5IWBYQjtn3QL6DGTrCTkFCngDW34jQAAwvaAA= References: <429446390BA91242867940DBE798A06B740334DFF7@mail> From: "Christer Holmberg" To: "Bob Penfield" , X-OriginalArrivalTime: 02 Nov 2009 20:22:12.0332 (UTC) FILETIME=[291EDAC0:01CA5BFA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:22:38 -0000 Hi,=20 >1) REFER and SUBSCRIBE can be sent on a dialog that has an INVITE usage, but they are associated with the subscription usage, not the INVITE usage. Therefore, Recv-Info should not be allowed on=20 >SUBSCRIBE, REFER, or NOTIFY. Yes. I have removed it for SUB, REF and NOT. >2) I think being able to update Recv-Info in PRACK and ACK is useful (e.g. 3pcc for ACK). I haven't heard any real objections to that, so I think we can continue based on that. >3) Recv-Info is not an offer/answer negotiation. In fact, it is really an advertisement rather than a negotiation. The content of the Recv-Info affects what the far end can send, not what the near end=20 >(the Recv-Info sender) can send. Yes. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, October 29, 2009 3:58 AM To: sipcore@ietf.org Subject: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info Hi, =20 I have got WGLC comments from different people regarding the request methods in which we allow the Recv-Info header field.=20 =20 It IS related to something we have discussed before, but I want to point it out, to make sure we can agree on a view. =20 1) REF and SUB ------------------------ =20 There has been some comments and question about whether we should allow the R-I header field in REF and SUB. =20 Now, both REF and SUB are target refresh requests, and CAN be sent within an invite dialog usage. However, I assume the dialog-usage RFC recommends against doing so. =20 =20 2) ACK and PRA ------------------------- =20 Keith suggested we shouldn't allow the header in ACK and PRA either. =20 Personally I would not like to make that restriction at this point, unless there is a good technical reason, but I would like to hear what other people think. =20 =20 3) "offer/answer" ----------------------- =20 The draft currently does not define o/a type-of rules when UAs are to indicate their Info Package set (using the Recv-Info header field). =20 Personally I don't think we need to define a "o/a" rules for Recv-Info. We only need to indicate in which message the header field is allowed. =20 We could say that, when a UA receives the I-P set from the remote user, it is recommend that it sends back its own set as soon as possible - if the set has changed. =20 Because, if the set hasn't changed I don't think the UA needs to send back anything, which means that whatever set it has sent before within that dialog is still valid. That is the biggest difference compared to o/a, which always requires the receiver to send its SDP back - even if nothing has changed. =20 =20 Regards, =20 Christer =20 =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Nov 2 12:33:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA653A6802 for ; Mon, 2 Nov 2009 12:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx5ZhqXXkORG for ; Mon, 2 Nov 2009 12:33:20 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4A3A03A6919 for ; Mon, 2 Nov 2009 12:33:19 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-1c-4aef4222c374 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D7.27.31706.2224FEA4; Mon, 2 Nov 2009 21:33:38 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:32:16 +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: Mon, 2 Nov 2009 21:32:05 +0100 Message-ID: In-Reply-To: <4AEEE7B5.60301@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: AcpbxdyHPh7aIVANRHGyreVG/iED+QANC8mw References: <4AE9A6CD.80907@cisco.com> <4AEAFA5D.4080204@cisco.com> <4AEEE7B5.60301@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Nov 2009 20:32:16.0176 (UTC) FILETIME=[910A2300:01CA5BFB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:33:21 -0000 Hi,=20 >>>> You would have to send an extra re-INVITE/UPDATE just because you=20 >>>> couldn't send the I-P list in the ACK. Or? >>>> >>>> And, if there are no rules one can of course send a list both in the=20 >>>> INVITE and the ACK. I don't know if that is likely to happen, but if=20 >>>> the ACK trigger the remote entity's list to change it would have to >>>> trigger a request in order to change the list, since there is no=20 >>>> response to ACK. >>> But this is not a negotiation, just a declaration. >>> So what harm is there in changing between INVITE and ACK? >>> (As unlikely as that seems.) >>=20 >> Maybe it works. >>=20 >> But, would it then also be allowed to send one list in a reliable 18x,=20 >> and then a new list in the next relaible 18x, and then a third list in=20 >> the 200 OK - all for the same transaction? > >What bad things happen if you do that? Maybe nothing. I just wanted to make sure you were ok with it :) >The worst thing I can see is that you might get sent an I-P you don't want to receive. Then you just ignore it, or send a 469, and go on about your business. > >Perhaps its more trouble on the sending side, though its hard to generalize. Consider the specific case of DTMF. A UA may be trying to decide how to set itself up to send DTMF, choosing from among the=20 >multitude of ways that are possible. If it gets a change - adding or removing a DTMF info package, then it may have to change other things as well, such as adding or removing telephone-events from its=20 >media types. > >But, that problem exists whether or not we we allow changes in R-I between responses, so its not a big deal. Maybe we could recommend against updating the list more than once per transaction, especially if the list could have impacts on other exchanged information (SDP etc). -------------------------- >>>Which dialog? Since this is 3pcc, and the interesting case is a transfer, there are *3* dialogs. >>>It should never hurt to send an R-I in the context of a response to a reinvite. >>=20 >>The draft says that you don't send a list unless you know that the=20 >>other party - for that dialog - supports the mechanism. > >In 3pcc that can be a problem. You don't ever know if you are talking to the same party that you were last time. > >>>There may indeed be a problem in one case. Here's a picture to refer >>> to: >>> A ----- B ----- C >>> | >>> --- D >>> >>>Initially A is connected, via B to C. Then B initiates a 3pcc transfer >>>by sending a reinvite to A. >>>Now suppose that both A and C support I-P, but D does not. How will A >>>ever learn that D does not? It won't receive an R-I header from D, and=20 >>>so will assume its unchanged from what it had from C. And when >>>it sends INFOs with an I-P, D will think they are legacy. It will never >>>send a 469, so it won't quench the sending. >>>=20 >>I assume B has contected D before it sends the re-INVITE to A, right? > >There are lots of ways to do it, depending on the goals of the case. So maybe yes, maybe no. > >>So, if D does NOT support I-P, I guess B would have to include R-I:nil in the re-INVITE to A. > >That means it won't work correctly unless B itself has an understanding of info packages. It would be better if that were not a requirement. But, how is this different from any other extension/capability (non-SDP) that A and C may previously have agreed upon, and D doesn't support? Regards, Christer From jbemmel@zonnet.nl Mon Nov 2 13:36:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8003A63EB for ; Mon, 2 Nov 2009 13:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r63lNMvoyzAP for ; Mon, 2 Nov 2009 13:36:05 -0800 (PST) Received: from smtp4.versatel.nl (smtp4.versatel.nl [62.58.50.91]) by core3.amsl.com (Postfix) with ESMTP id 097F63A6A88 for ; Mon, 2 Nov 2009 13:36:04 -0800 (PST) Received: (qmail 12947 invoked by uid 0); 2 Nov 2009 21:36:17 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Nov 2009 21:36:17 -0000 Message-ID: <4AEF50D0.8010907@zonnet.nl> Date: Mon, 02 Nov 2009 22:36:16 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Taisto Qvist XX References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:36:06 -0000 Hi Taisto, My question would be: what is the purpose of using different values in the Contact header like this? It certainly complicates things, and does not help interoperability. Given your reference to a "firewall provider", I'm guessing it has something to do with security? What is changing between Contact values, the IP address? port? some 'magic' tag? Contact is optional in 1xx responses (except in case of 100rel), and in practice I believe you will find that most UAS use the same value in 1xx and 2xx responses to a given INVITE. There's no law against using different values AFAIK, so in your step 5 the UAS could even use "b3" as a value. The UAC should simply send its ACK to the contact from the 2xx response to INVITE. Regards, Jeroen Taisto Qvist XX wrote: > Hi folks, > > I am in a discussion with a firewall provider, regarding the "legality" > for a UAS > to use different Contact: uri's in 1xx and 2xx for the same > transaction/dialog. > > I claim that you MUST use the same Contact in the 2xx as was sent the > 1xx. > Unfortunately I cant give him an explicit reference, since there is > none(afaik?) > > Instead I must indicate chapters that indicate that UAS must initialize > dialog state > on reception of the 1xx, and that on reception of 2xx, the only thing > that is recomputed, > is the routeset. The firewall provider is not convinced. > > Also the text in 3261, 12.1.1 indicates(?) that the Contact should be > the same in 2xx and 1xx. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > order of those values. The UAS MUST add a Contact header field to > the response. The Contact header field contains an address where the > UAS would like to be contacted for subsequent requests in the dialog > (which includes the ACK for a 2xx response in the case of an INVITE). > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Now to my question, or sort of... > > Is a target refresh used by the UAC, and implicit target refresh > possibility also for the UAS? > In other words, is the response to a target refresh request, a "response > target refresh"? > > Can the UAS add a new Contact in the 2xx response to a target refresh, > and assume that the UAC > updates its remote target? I've read Gonzalo Camarillo's draft, but it > doesnt really mention > this scenario. > > If the UAS can change his Contact, then I've become puzzled on what I > should add in the final 2xx > to an initial INVITE, if both sides(uas/uac) have updated their contacts > during an UPDATE-target > refresh in the early dialog. > > The flow would be > 1) INVITE from A -> B (contact:a1) > > 2) 18x from B -> A (contact:b1) > + prack, early media, go figure... > > 3) UPDATE from A -> B (contact:a2) > > 4) 2xx(UPD) from B -> A (contact:b2) << "target refresh > response" > > 5) 2xx(INV) from B -> A (contact......b2 or b1?) > > 6) ACK-time..remote target is b2... > > If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the answer, > but at the same time, > the ACK must be sent to b2.... > > Any feedback you can give me would be much appreciated. > > Regards > Taisto Qvist > IP-Solutions > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From taisto.xx.qvist@ericsson.com Tue Nov 3 00:49:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275D328C155 for ; Tue, 3 Nov 2009 00:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMcgtTLcdnDI for ; Tue, 3 Nov 2009 00:49:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 41AC83A680F for ; Tue, 3 Nov 2009 00:49:40 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-b6-4aefeeb7542a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3A.04.04191.7BEEFEA4; Tue, 3 Nov 2009 09:49:59 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:49:38 +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: Tue, 3 Nov 2009 09:49:37 +0100 Message-ID: In-Reply-To: <4AEF50D0.8010907@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changing contact/remote target in target refresh response Thread-Index: AcpcBIOnTE3TdWJRTeOv7gz3vJVF/QAXEnUA References: <4AEF50D0.8010907@zonnet.nl> From: "Taisto Qvist XX" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 03 Nov 2009 08:49:38.0535 (UTC) FILETIME=[938A5F70:01CA5C62] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 08:49:43 -0000 Hi Jeroen,=20 I know the scenario is a bit weird, but thats we I need more experts telling the firewall guys that they cant behave like this. My scenario-description is a bit simplified, but think of it as a bad fw-alg that manages to do nat-traversal logic for the contact in 2xx, but forgets to do so on the 1xx. Despite the scenarios possible...weirdess, I really need a clarification to wether a target refresh request is really just for refreshing the UAC's Contact, or if it allowes the UAS to do the same. One thing puzzles me...you're saying that the Contact is NOT mandatory?? My reading of the rfc says that it IS mandatory, even though the "MUST" is spread over three different places. First we have: 8.2.6.2 in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present).=20 So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's optional. Secondly: 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. =20 and then finally: 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and 3) that means I MUST add Contact.=20 Is that not a correct interpretation, for INVITE?? The final reference is also the place where, at least with a little imagination,=20 you could interpret the text in third paranthesis as to say "you must put the=20 same contact in 1xx as in 2xx, since it should be used for ACK". Regards Taisto Qvist -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: den 2 november 2009 22:36 To: Taisto Qvist XX Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in target refresh response Hi Taisto, My question would be: what is the purpose of using different values in the Contact header like this? It certainly complicates things, and does not help interoperability. Given your reference to a "firewall provider", I'm guessing it has something to do with security? What is changing between Contact values, the IP address? port? some 'magic' tag? Contact is optional in 1xx responses (except in case of 100rel), and in practice I believe you will find that most UAS use the same value in 1xx and 2xx responses to a given INVITE. There's no law against using different values AFAIK, so in your step 5 the UAS could even use "b3" as a value. The UAC should simply send its ACK to the contact from the 2xx response to INVITE. Regards, Jeroen Taisto Qvist XX wrote: > Hi folks, > =20 > I am in a discussion with a firewall provider, regarding the "legality" > for a UAS > to use different Contact: uri's in 1xx and 2xx for the same=20 > transaction/dialog. > =20 > I claim that you MUST use the same Contact in the 2xx as was sent the=20 > 1xx. > Unfortunately I cant give him an explicit reference, since there is > none(afaik?) > > Instead I must indicate chapters that indicate that UAS must=20 > initialize dialog state on reception of the 1xx, and that on reception > of 2xx, the only thing that is recomputed, is the routeset. The=20 > firewall provider is not convinced. > =20 > Also the text in 3261, 12.1.1 indicates(?) that the Contact should be=20 > the same in 2xx and 1xx. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 > order of those values. The UAS MUST add a Contact header field to the > response. The Contact header field contains an address where the UAS=20 > would like to be contacted for subsequent requests in the dialog=20 > (which includes the ACK for a 2xx response in the case of an INVITE). > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 > Now to my question, or sort of... > > Is a target refresh used by the UAC, and implicit target refresh=20 > possibility also for the UAS? > In other words, is the response to a target refresh request, a=20 > "response target refresh"? > > Can the UAS add a new Contact in the 2xx response to a target refresh, > and assume that the UAC updates its remote target? I've read Gonzalo=20 > Camarillo's draft, but it doesnt really mention this scenario. > > If the UAS can change his Contact, then I've become puzzled on what I=20 > should add in the final 2xx to an initial INVITE, if both=20 > sides(uas/uac) have updated their contacts during an UPDATE-target=20 > refresh in the early dialog. > > The flow would be > 1) INVITE from A -> B (contact:a1) > > 2) 18x from B -> A (contact:b1) > + prack, early media, go figure... > > 3) UPDATE from A -> B (contact:a2) > > 4) 2xx(UPD) from B -> A (contact:b2) << "target refresh > response" > > 5) 2xx(INV) from B -> A (contact......b2 or b1?) > > 6) ACK-time..remote target is b2... > > If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the=20 > answer, but at the same time, the ACK must be sent to b2.... > > Any feedback you can give me would be much appreciated.=20 > > Regards > Taisto Qvist > IP-Solutions > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From john.elwell@siemens-enterprise.com Tue Nov 3 05:40:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BB03A6923 for ; Tue, 3 Nov 2009 05:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRVG2cVa2MHK for ; Tue, 3 Nov 2009 05:40:06 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 83C933A67B1 for ; Tue, 3 Nov 2009 05:40:06 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3DePm4024377 for ; Tue, 3 Nov 2009 14:40:25 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3DeOAo031533 for ; Tue, 3 Nov 2009 14:40:25 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Tue, 3 Nov 2009 14:40:24 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Tue, 3 Nov 2009 14:40:23 +0100 Thread-Topic: Info-events and Request-Disposition etc. Thread-Index: AcpcizE09U9GSb4FSWyJ/5rBw/0M+g== Message-ID: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:40:08 -0000 The info-events draft does not mention the Request-Disposition header field= . However, in RFC 3841, Request-Disposition is indicated as optional in INF= O requests. Similarly for Accept-Contact and Reject-Contact. So there is an= apparent contradiction, which we should try to put right. I fail to see the purpose of these header fields in an INFO Request, which = can occur only on an INVITE-initiated dialog. Therefore I think the info-ev= ents draft is correct. Does this therefore mean that the draft updates RFC = 3841, and if so do we need to make explicit mention of the fact that RFC 38= 41 is updated by removing the option of these header fields in an INFO requ= est? John= From pkyzivat@cisco.com Tue Nov 3 06:58:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAC33A67E4 for ; Tue, 3 Nov 2009 06:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zYxTZPi8KLh for ; Tue, 3 Nov 2009 06:58:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BAF9C3A659B for ; Tue, 3 Nov 2009 06:58:24 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMbT70pAZnwM/2dsb2JhbADGZ5gChD0E X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="66166285" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2009 14:58:44 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3EwjnW000327; Tue, 3 Nov 2009 14:58: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.3959); Tue, 3 Nov 2009 09:58:44 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 09:58:44 -0500 Message-ID: <4AF044FA.6060203@cisco.com> Date: Tue, 03 Nov 2009 09:58:02 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AE9A6CD.80907@cisco.com> <4AEAFA5D.4080204@cisco.com> <4AEEE7B5.60301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 14:58:44.0405 (UTC) FILETIME=[2381F650:01CA5C96] Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:58:26 -0000 Christer Holmberg wrote: >>> But, would it then also be allowed to send one list in a reliable 18x, >>> and then a new list in the next relaible 18x, and then a third list in >>> the 200 OK - all for the same transaction? >> What bad things happen if you do that? > > Maybe nothing. I just wanted to make sure you were ok with it :) Yes, I'm ok with it. It doesn't need to be forbidden just because its weird. >> The worst thing I can see is that you might get sent an I-P you don't > want to receive. Then you just ignore it, or send a 469, and go on about > your business. >> Perhaps its more trouble on the sending side, though its hard to > generalize. Consider the specific case of DTMF. A UA may be trying to > decide how to set itself up to send DTMF, choosing from among the >> multitude of ways that are possible. If it gets a change - adding or > removing a DTMF info package, then it may have to change other things as > well, such as adding or removing telephone-events from its >> media types. >> >> But, that problem exists whether or not we we allow changes in R-I > between responses, so its not a big deal. > > Maybe we could recommend against updating the list more than once per > transaction, especially if the list could have impacts on other > exchanged information (SDP etc). I guess I don't have a problem with recommendations. >>>> Which dialog? Since this is 3pcc, and the interesting case is a > transfer, there are *3* dialogs. >>>> It should never hurt to send an R-I in the context of a response to a > reinvite. >>> The draft says that you don't send a list unless you know that the >>> other party - for that dialog - supports the mechanism. >> In 3pcc that can be a problem. You don't ever know if you are talking > to the same party that you were last time. >>>> There may indeed be a problem in one case. Here's a picture to refer >>>> to: >>>> A ----- B ----- C >>>> | >>>> --- D >>>> >>>> Initially A is connected, via B to C. Then B initiates a 3pcc > transfer >>>> by sending a reinvite to A. >>>> Now suppose that both A and C support I-P, but D does not. How will A >>>> ever learn that D does not? It won't receive an R-I header from D, > and >>>> so will assume its unchanged from what it had from C. And when >>>> it sends INFOs with an I-P, D will think they are legacy. It will > never >>>> send a 469, so it won't quench the sending. >>>> >>> I assume B has contected D before it sends the re-INVITE to A, right? >> There are lots of ways to do it, depending on the goals of the case. So > maybe yes, maybe no. >>> So, if D does NOT support I-P, I guess B would have to include R-I:nil > in the re-INVITE to A. >> That means it won't work correctly unless B itself has an understanding > of info packages. It would be better if that were not a requirement. > > But, how is this different from any other extension/capability (non-SDP) > that A and C may previously have agreed upon, and D doesn't support? The same issues can arise. But a 3pcc controller can try to be lenient in its processing of messages, only messing with things it understands, and relaying headers it doesn't understand. We raise the bar if we require the 3pcc controller to do something *active* in order to make things work in this case. If we don't make it so that simply relaying the headers is enough, then perhaps there needs to be a whole section of B2BUA behavior, in addition to that for UAC and UAS. Thanks, Paul From pkyzivat@cisco.com Tue Nov 3 08:17:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501753A6A1E for ; Tue, 3 Nov 2009 08:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4yE6IDYchQH for ; Tue, 3 Nov 2009 08:17:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 54ED93A6A15 for ; Tue, 3 Nov 2009 08:17:07 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMLm70pAZnwN/2dsb2JhbADHIJgHhD0E X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="66224285" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2009 16:17:27 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA3GHRqB001253; Tue, 3 Nov 2009 16:17:27 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.3959); Tue, 3 Nov 2009 11:17:27 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 11:17:27 -0500 Message-ID: <4AF05761.1040202@cisco.com> Date: Tue, 03 Nov 2009 11:16:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 16:17:27.0172 (UTC) FILETIME=[227F0440:01CA5CA1] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:17:08 -0000 Elwell, John wrote: > The info-events draft does not mention the Request-Disposition header field. However, in RFC 3841, Request-Disposition is indicated as optional in INFO requests. Similarly for Accept-Contact and Reject-Contact. So there is an apparent contradiction, which we should try to put right. > > I fail to see the purpose of these header fields in an INFO Request, which can occur only on an INVITE-initiated dialog. Therefore I think the info-events draft is correct. Does this therefore mean that the draft updates RFC 3841, and if so do we need to make explicit mention of the fact that RFC 3841 is updated by removing the option of these header fields in an INFO request? Well, IMO the Request-Disposition was very underspecified. Also, the possibility of 3xx responses to in-dialog requests is underspecified. *If* its possible to get a 3xx response to an INFO request, then the Request-Disposition might be desired to control how a proxy deals with it. It would be nice to clarify all of that, but this isn't the place to do it. So I would recommend that this draft *not* update 3841. I would try to avoid addressing the subject at all. Thanks, Paul From john.elwell@siemens-enterprise.com Tue Nov 3 08:33:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43ACD3A681C for ; Tue, 3 Nov 2009 08:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpSH14RXtpxp for ; Tue, 3 Nov 2009 08:33:20 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id A42FA3A68E3 for ; Tue, 3 Nov 2009 08:33:18 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3GXVZO016120; Tue, 3 Nov 2009 17:33:31 +0100 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3GXVZS003598; Tue, 3 Nov 2009 17:33:31 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Tue, 3 Nov 2009 17:33:30 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 3 Nov 2009 17:33:29 +0100 Thread-Topic: [sipcore] Info-events and Request-Disposition etc. Thread-Index: AcpcoSNPpjDLJ5OYSFqoFQLzqRt7mwAAXVRg Message-ID: <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net> <4AF05761.1040202@cisco.com> In-Reply-To: <4AF05761.1040202@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:33:21 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 03 November 2009 16:17 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 >=20 > Elwell, John wrote: > > The info-events draft does not mention the=20 > Request-Disposition header field. However, in RFC 3841,=20 > Request-Disposition is indicated as optional in INFO=20 > requests. Similarly for Accept-Contact and Reject-Contact. So=20 > there is an apparent contradiction, which we should try to put right. > >=20 > > I fail to see the purpose of these header fields in an INFO=20 > Request, which can occur only on an INVITE-initiated dialog.=20 > Therefore I think the info-events draft is correct. Does this=20 > therefore mean that the draft updates RFC 3841, and if so do=20 > we need to make explicit mention of the fact that RFC 3841 is=20 > updated by removing the option of these header fields in an=20 > INFO request? >=20 > Well, IMO the Request-Disposition was very underspecified. > Also, the possibility of 3xx responses to in-dialog requests is=20 > underspecified. >=20 > *If* its possible to get a 3xx response to an INFO request, then the=20 > Request-Disposition might be desired to control how a proxy=20 > deals with it. >=20 > It would be nice to clarify all of that, but this isn't the=20 > place to do it. >=20 > So I would recommend that this draft *not* update 3841. > I would try to avoid addressing the subject at all. [JRE] That would be fine with me, as long as it is understood that there ar= e issues with RFC 3841 that we will not attempt to address in this draft. T= he question arose from some discussions involving ETSI TISPAN and 3GPP CT1,= where 3841 seems to be taken as evidence these header fields can be used i= n INFO. John >=20 > Thanks, > Paul > = From rjsparks@nostrum.com Tue Nov 3 08:46:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2A03A68A8 for ; Tue, 3 Nov 2009 08:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptPBliXB9mL5 for ; Tue, 3 Nov 2009 08:46:05 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DA6263A6832 for ; Tue, 3 Nov 2009 08:46:04 -0800 (PST) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA3Gk4VR014866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 10:46:04 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 10:46:04 -0600 References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:46:06 -0000 Wading through the long list of mail on this looking for loose ends: I don't think we've established agreement that you have to wait for an ACK (or PRACK) to arrive before sending an INFO. If I'm wrong, the draft needs to say that very explicitly - things will send media immediately after the 183 or a 200 without waiting for the associated PRACK or ACK and I rather expect they think the dialog (early or otherwise) has been established when they do that. Can you point to some existing RFC text that says otherwise? I suspect if there are every any packages for INFO, one of them might expect to be able to send them as soon as they start sending media. RjS On Oct 17, 2009, at 12:22 PM, Christer Holmberg wrote: > > Hi, > >> One thing that didn't survive the rewrite that I think we should work > back in is a note to implementors that an INFO might arrive from a > peer > even before the first end-to-end provisional (because it >> might win a race with an immediate 200 OK) and this is not an error. > > You gave this comment to me earlier, in your previous comments. I > replied, but you never got back to me :) > > The idea is that the UAS can start sending INFOs once the dialog > (early > or final) has been established from the UAS's perpective. If I > remember > corretly, that occurs when the UAS receives an acknolwedgement > (PRACK or > ACK) to the response which established the dialog. In that case there > could be no race condition, because the UAS knows that the UAC has > received the 18x/200 response. > > Regards, > > Christer > > > > From adam@estacado.net Tue Nov 3 09:27:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5705C28C119 for ; Tue, 3 Nov 2009 09:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LansM7qzkXq4 for ; Tue, 3 Nov 2009 09:27:42 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2112328C114 for ; Tue, 3 Nov 2009 09:27:41 -0800 (PST) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA3HRwIa018295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 11:27:58 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4AF0681E.4020901@estacado.net> Date: Tue, 03 Nov 2009 11:27:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Robert Sparks References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> In-Reply-To: <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:27:43 -0000 On 11/3/09 10:46, Nov 3, Robert Sparks wrote: > Wading through the long list of mail on this looking for loose ends: > > I don't think we've established agreement that you have to wait for an > ACK (or PRACK) to arrive before sending an INFO. > > If I'm wrong, the draft needs to say that very explicitly - things > will send > media immediately after the 183 or a 200 without waiting for the > associated > PRACK or ACK and I rather expect they think the dialog (early or > otherwise) has > been established when they do that. Can you point to some existing RFC > text that > says otherwise? > > I suspect if there are every any packages for INFO, one of them might > expect to be able to send them > as soon as they start sending media. Think, in particular, of the DTMF transit case. As much as I dislike that particular use of INFO, it seems to be the dominant deployed use case. If you have a mismatch between when you can send RTP and when you can send INFO, you can end up with some unfortunate consequences. /a From christer.holmberg@ericsson.com Tue Nov 3 10:04:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F1B28C148 for ; Tue, 3 Nov 2009 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK222Ru43KC4 for ; Tue, 3 Nov 2009 10:04:35 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2E01328C139 for ; Tue, 3 Nov 2009 10:04:35 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-04-4af070c6ad55 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1D.6B.31706.6C070FA4; Tue, 3 Nov 2009 19:04:54 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 19:04:43 +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: Tue, 3 Nov 2009 19:04:08 +0100 Message-ID: In-Reply-To: <4AF0681E.4020901@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (was Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? thread-index: Acpcqv+qcV0IZy2xTf2NLz8eZzsTlQABFK8g References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> <4AF0681E.4020901@estacado.net> From: "Christer Holmberg" To: "Adam Roach" , "Robert Sparks" X-OriginalArrivalTime: 03 Nov 2009 18:04:43.0150 (UTC) FILETIME=[1EA352E0:01CA5CB0] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:04:36 -0000 Hi,=20 >>Wading through the long list of mail on this looking for loose ends: >> >>I don't think we've established agreement that you have to wait for an >>ACK (or PRACK) to arrive before sending an INFO. >> >>If I'm wrong, the draft needs to say that very explicitly - things=20 >>will send media immediately after the 183 or a 200 without waiting for >>the associated PRACK or ACK and I rather expect they think the dialog=20 >>(early or otherwise) has >>been established when they do that. Can you point to some existing RFC >>text that says otherwise? >> >>I suspect if there are every any packages for INFO, one of them might=20 >>expect to be able to send them as soon as they start sending media. > >Think, in particular, of the DTMF transit case. As much as I dislike that particular use of INFO, it seems to be the dominant deployed use case. If you have a mismatch between when you can send RTP and=20 >when you can send INFO, you can end up with some unfortunate consequences. I am not arguing against the potential need to be able to start sending. However, as far as I understand a UAS is not allowed to send a SIP request (INFO, or whatever other request, except NOTIFY) in the UAS-to-UAC direction until it has received an acknowledgement (PRACK or ACK) that the early dialog has been established. If I'm wrong I will add text as suggested by Robert. Regards, Christer From christer.holmberg@ericsson.com Tue Nov 3 10:10:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E733A6994 for ; Tue, 3 Nov 2009 10:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51MMmkExUwh0 for ; Tue, 3 Nov 2009 10:10:56 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CD6823A6828 for ; Tue, 3 Nov 2009 10:10:55 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b6-4af07243884f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B0.9A.24026.34270FA4; Tue, 3 Nov 2009 19:11:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 19:09:44 +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: Tue, 3 Nov 2009 19:09:43 +0100 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-events and Request-Disposition etc. thread-index: AcpcoSNPpjDLJ5OYSFqoFQLzqRt7mwAAXVRgAAN4KiA= References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net><4AF05761.1040202@cisco.com> <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Nov 2009 18:09:44.0807 (UTC) FILETIME=[D2708770:01CA5CB0] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:10:57 -0000 Hi, Keith commented on the R-D header field in his comments, and the following will be added to the header field table: "Request-Disposition R o" Other than that I don't think we need to say anything, but we shall not deviate from 3841. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John Sent: 3. marraskuuta 2009 18:33 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Info-events and Request-Disposition etc. =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 03 November 2009 16:17 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 >=20 > Elwell, John wrote: > > The info-events draft does not mention the > Request-Disposition header field. However, in RFC 3841,=20 > Request-Disposition is indicated as optional in INFO requests.=20 > Similarly for Accept-Contact and Reject-Contact. So there is an=20 > apparent contradiction, which we should try to put right. > >=20 > > I fail to see the purpose of these header fields in an INFO > Request, which can occur only on an INVITE-initiated dialog.=20 > Therefore I think the info-events draft is correct. Does this=20 > therefore mean that the draft updates RFC 3841, and if so do we need=20 > to make explicit mention of the fact that RFC 3841 is updated by=20 > removing the option of these header fields in an INFO request? >=20 > Well, IMO the Request-Disposition was very underspecified. > Also, the possibility of 3xx responses to in-dialog requests is=20 > underspecified. >=20 > *If* its possible to get a 3xx response to an INFO request, then the=20 > Request-Disposition might be desired to control how a proxy deals with > it. >=20 > It would be nice to clarify all of that, but this isn't the place to=20 > do it. >=20 > So I would recommend that this draft *not* update 3841. > I would try to avoid addressing the subject at all. [JRE] That would be fine with me, as long as it is understood that there are issues with RFC 3841 that we will not attempt to address in this draft. The question arose from some discussions involving ETSI TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these header fields can be used in INFO. John >=20 > Thanks, > Paul >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Nov 3 10:32:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E026B28C174 for ; Tue, 3 Nov 2009 10:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFWfoG51U9bA for ; Tue, 3 Nov 2009 10:32:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CFA6528C166 for ; Tue, 3 Nov 2009 10:32:01 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO4F8EpAZnwN/2dsb2JhbADHBJgYhD0E X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="200884471" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-3.cisco.com with ESMTP; 03 Nov 2009 18:32:22 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA3IWMZo000999; Tue, 3 Nov 2009 18:32: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.3959); Tue, 3 Nov 2009 13:32:22 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:32:21 -0500 Message-ID: <4AF076ED.8080303@cisco.com> Date: Tue, 03 Nov 2009 13:31:09 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net> <4AF05761.1040202@cisco.com> <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 18:32:21.0909 (UTC) FILETIME=[FB55DC50:01CA5CB3] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:32:03 -0000 Elwell, John wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 03 November 2009 16:17 >> To: Elwell, John >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Info-events and Request-Disposition etc. >> >> >> >> Elwell, John wrote: >>> The info-events draft does not mention the >> Request-Disposition header field. However, in RFC 3841, >> Request-Disposition is indicated as optional in INFO >> requests. Similarly for Accept-Contact and Reject-Contact. So >> there is an apparent contradiction, which we should try to put right. >>> I fail to see the purpose of these header fields in an INFO >> Request, which can occur only on an INVITE-initiated dialog. >> Therefore I think the info-events draft is correct. Does this >> therefore mean that the draft updates RFC 3841, and if so do >> we need to make explicit mention of the fact that RFC 3841 is >> updated by removing the option of these header fields in an >> INFO request? >> >> Well, IMO the Request-Disposition was very underspecified. >> Also, the possibility of 3xx responses to in-dialog requests is >> underspecified. >> >> *If* its possible to get a 3xx response to an INFO request, then the >> Request-Disposition might be desired to control how a proxy >> deals with it. >> >> It would be nice to clarify all of that, but this isn't the >> place to do it. >> >> So I would recommend that this draft *not* update 3841. >> I would try to avoid addressing the subject at all. > [JRE] That would be fine with me, as long as it is understood that there are issues with RFC 3841 that we will not attempt to address in this draft. The question arose from some discussions involving ETSI TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these header fields can be used in INFO. IMO it would be ok to include something in this doc that says its not trying to address any issues with R-D. I just think trying to solve that here is a rat hole. Thanks, Paul From christer.holmberg@ericsson.com Tue Nov 3 10:34:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C913A3A690C for ; Tue, 3 Nov 2009 10:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U5xd5XMIZFR for ; Tue, 3 Nov 2009 10:34:34 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 539F33A6892 for ; Tue, 3 Nov 2009 10:34:34 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-9b-4af077cde910 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DD.F4.04191.DC770FA4; Tue, 3 Nov 2009 19:34:53 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 19:34:53 +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: Tue, 3 Nov 2009 19:34:20 +0100 Message-ID: In-Reply-To: <4AF076ED.8080303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-events and Request-Disposition etc. thread-index: AcpctAAYoXXxL3PjSQm9rixe1tyWFQAABASw References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net><4AF05761.1040202@cisco.com><7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> <4AF076ED.8080303@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 03 Nov 2009 18:34:53.0143 (UTC) FILETIME=[557A5670:01CA5CB4] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:34:35 -0000 Hi, There are lots of headers we don't say anything about.=20 But, I think the header table shall be as complete as possible, and alligned with the RFCs which specify the headers. Otherwise the table is useless, and just messes things up for people using it for comformance testing etc. Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 3. marraskuuta 2009 20:31 To: Elwell, John Cc: sipcore@ietf.org Subject: Re: [sipcore] Info-events and Request-Disposition etc. Elwell, John wrote: > =20 >=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 03 November 2009 16:17 >> To: Elwell, John >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Info-events and Request-Disposition etc. >> >> >> >> Elwell, John wrote: >>> The info-events draft does not mention the >> Request-Disposition header field. However, in RFC 3841,=20 >> Request-Disposition is indicated as optional in INFO requests.=20 >> Similarly for Accept-Contact and Reject-Contact. So there is an=20 >> apparent contradiction, which we should try to put right. >>> I fail to see the purpose of these header fields in an INFO >> Request, which can occur only on an INVITE-initiated dialog.=20 >> Therefore I think the info-events draft is correct. Does this=20 >> therefore mean that the draft updates RFC 3841, and if so do we need=20 >> to make explicit mention of the fact that RFC 3841 is updated by=20 >> removing the option of these header fields in an INFO request? >> >> Well, IMO the Request-Disposition was very underspecified. >> Also, the possibility of 3xx responses to in-dialog requests is=20 >> underspecified. >> >> *If* its possible to get a 3xx response to an INFO request, then the=20 >> Request-Disposition might be desired to control how a proxy deals=20 >> with it. >> >> It would be nice to clarify all of that, but this isn't the place to=20 >> do it. >> >> So I would recommend that this draft *not* update 3841. >> I would try to avoid addressing the subject at all. > [JRE] That would be fine with me, as long as it is understood that there are issues with RFC 3841 that we will not attempt to address in this draft. The question arose from some discussions involving ETSI TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these header fields can be used in INFO. IMO it would be ok to include something in this doc that says its not trying to address any issues with R-D. I just think trying to solve that here is a rat hole. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Nov 3 10:35:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8542F28C178 for ; Tue, 3 Nov 2009 10:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vcWVc+t6E-K for ; Tue, 3 Nov 2009 10:35:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 83DE83A6909 for ; Tue, 3 Nov 2009 10:35:29 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFcH8EpAZnwM/2dsb2JhbADHBZgZhD0E X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="66203272" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2009 18:35:49 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3IZn3d008268; Tue, 3 Nov 2009 18:35:50 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.3959); Tue, 3 Nov 2009 13:35:49 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:35:49 -0500 Message-ID: <4AF077BD.2050002@cisco.com> Date: Tue, 03 Nov 2009 13:34:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> In-Reply-To: <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 18:35:49.0545 (UTC) FILETIME=[77189990:01CA5CB4] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:35:30 -0000 I agree that there will be some that will start sending INFO as soon as they have a place to send it. And I think that is ok. You don't really need the PRACK for that. Thanks, Paul Robert Sparks wrote: > Wading through the long list of mail on this looking for loose ends: > > I don't think we've established agreement that you have to wait for an > ACK (or PRACK) to arrive before sending an INFO. > If I'm wrong, the draft needs to say that very explicitly - things will > send > media immediately after the 183 or a 200 without waiting for the associated > PRACK or ACK and I rather expect they think the dialog (early or > otherwise) has > been established when they do that. Can you point to some existing RFC > text that > says otherwise? > > I suspect if there are every any packages for INFO, one of them might > expect to be able to send them > as soon as they start sending media. > > RjS > > On Oct 17, 2009, at 12:22 PM, Christer Holmberg wrote: > >> >> Hi, >> >>> One thing that didn't survive the rewrite that I think we should work >> back in is a note to implementors that an INFO might arrive from a peer >> even before the first end-to-end provisional (because it >>> might win a race with an immediate 200 OK) and this is not an error. >> >> You gave this comment to me earlier, in your previous comments. I >> replied, but you never got back to me :) >> >> The idea is that the UAS can start sending INFOs once the dialog (early >> or final) has been established from the UAS's perpective. If I remember >> corretly, that occurs when the UAS receives an acknolwedgement (PRACK or >> ACK) to the response which established the dialog. In that case there >> could be no race condition, because the UAS knows that the UAC has >> received the 18x/200 response. >> >> Regards, >> >> Christer >> >> >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Tue Nov 3 10:36:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F723A6909 for ; Tue, 3 Nov 2009 10:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lxu915Y-p1F for ; Tue, 3 Nov 2009 10:36:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 80FA63A6892 for ; Tue, 3 Nov 2009 10:36:47 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJMH8EpAZnwN/2dsb2JhbADHCZgZhD0E X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="220792167" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2009 18:37:08 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA3Ib7mF003459; Tue, 3 Nov 2009 18:37: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.3959); Tue, 3 Nov 2009 13:37:07 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:37:07 -0500 Message-ID: <4AF0780A.6020406@cisco.com> Date: Tue, 03 Nov 2009 13:35:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> <4AF0681E.4020901@estacado.net> In-Reply-To: <4AF0681E.4020901@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 18:37:07.0497 (UTC) FILETIME=[A58F2190:01CA5CB4] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:36:48 -0000 Adam Roach wrote: > Think, in particular, of the DTMF transit case. As much as I dislike > that particular use of INFO, it seems to be the dominant deployed use > case. If you have a mismatch between when you can send RTP and when you > can send INFO, you can end up with some unfortunate consequences. That may be true. But that seems like something for the individual I-P spec to address. Thanks, Paul From adam@estacado.net Tue Nov 3 10:38:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C257428C18B for ; Tue, 3 Nov 2009 10:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZyPnkm+jpTN for ; Tue, 3 Nov 2009 10:38:26 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A1DFC28C184 for ; Tue, 3 Nov 2009 10:38:25 -0800 (PST) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA3IcfvE024877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 12:38:41 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4AF078B1.10607@estacado.net> Date: Tue, 03 Nov 2009 12:38:41 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Kyzivat References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> <4AF0681E.4020901@estacado.net> <4AF0780A.6020406@cisco.com> In-Reply-To: <4AF0780A.6020406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:38:26 -0000 On 11/3/09 12:35, Nov 3, Paul Kyzivat wrote: > > > Adam Roach wrote: > >> Think, in particular, of the DTMF transit case. As much as I dislike >> that particular use of INFO, it seems to be the dominant deployed use >> case. If you have a mismatch between when you can send RTP and when >> you can send INFO, you can end up with some unfortunate consequences. > > That may be true. But that seems like something for the individual I-P > spec to address. I agree. But you don't want it to have to contravene normative language in the base INFO spec to do so. /a From pkyzivat@cisco.com Tue Nov 3 10:41:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487A828C181 for ; Tue, 3 Nov 2009 10:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syHtAs2LMTDf for ; Tue, 3 Nov 2009 10:41:31 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B366B28C15D for ; Tue, 3 Nov 2009 10:41:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIYI8EpAZnwN/2dsb2JhbADHBZgahD0E X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="66204030" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2009 18:41:51 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA3Ifptm005370; Tue, 3 Nov 2009 18:41:51 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.3959); Tue, 3 Nov 2009 13:41:51 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 13:41:50 -0500 Message-ID: <4AF07925.6030706@cisco.com> Date: Tue, 03 Nov 2009 13:40:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> <4AF0681E.4020901@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 18:41:50.0663 (UTC) FILETIME=[4E56D570:01CA5CB5] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:41:32 -0000 Christer Holmberg wrote: > I am not arguing against the potential need to be able to start sending. > > However, as far as I understand a UAS is not allowed to send a SIP > request (INFO, or whatever other request, except NOTIFY) in the > UAS-to-UAC direction until it has received an acknowledgement (PRACK or > ACK) that the early dialog has been established. If I'm wrong I will add > text as suggested by Robert. You are not allowed to send until there is at least an early dialog. For the UAC that is when it receives a response with a to-tag. It need not be reliable, or if it is, you don't need to wait for the PRACK and response. For the UAS, its as soon as it receives the initial request with from-tag. For instance, without 100rel, you can send an UPDATE as soon as you have received a 1xx with a to-tag. The same should apply to INFO. Thanks, Paul From christer.holmberg@ericsson.com Tue Nov 3 11:07:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625833A67B3 for ; Tue, 3 Nov 2009 11:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74mju4A8BZ4c for ; Tue, 3 Nov 2009 11:07:09 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2D14C3A63D3 for ; Tue, 3 Nov 2009 11:07:08 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-6b-4af07f70d554 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 23.DC.31706.07F70FA4; Tue, 3 Nov 2009 20:07:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 20:07:05 +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: Tue, 3 Nov 2009 20:06:42 +0100 Message-ID: In-Reply-To: <4AF07925.6030706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? thread-index: AcpctVBWTKTdLV8CRyCBgvQ0ReNYVwAArV8w References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <88DF0AF0-87A7-4585-9BAA-FA1B1DD84E9E@nostrum.com> <4AF0681E.4020901@estacado.net> <4AF07925.6030706@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 03 Nov 2009 19:07:05.0244 (UTC) FILETIME=[D5198DC0:01CA5CB8] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:07:10 -0000 Hi,=20 >> I am not arguing against the potential need to be able to start sending. >>=20 >> However, as far as I understand a UAS is not allowed to send a SIP=20 >> request (INFO, or whatever other request, except NOTIFY) in the=20 >> UAS-to-UAC direction until it has received an acknowledgement (PRACK=20 >> or >> ACK) that the early dialog has been established. If I'm wrong I will=20 >> add text as suggested by Robert. > >You are not allowed to send until there is at least an early dialog. For the UAC that is when it receives a response with a to-tag. It need not be reliable, or if it is, you don't need to wait for the=20 >PRACK and response. Agree. >For the UAS, its as soon as it receives the initial request with from-tag. Where is that specified? We normally refer to the rules for BYE when we define new mid-dialog requests, but are you really allowed to send a BYE at that point? The UAC could still be re-transmitting the INVITE, and if the UAC receives the INFO before a 18x the INFO would create the early dialog at the UAC side. I thought we only allowed that for NOTIFY... >For instance, without 100rel, you can send an UPDATE as soon as you have received a 1xx with a to-tag. > >The same should apply to INFO. Yes, the UAC can do that, but my issue is the UAS. Regards, Christer From john.elwell@siemens-enterprise.com Tue Nov 3 12:14:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869A53A6925 for ; Tue, 3 Nov 2009 12:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVSMJGyjueMr for ; Tue, 3 Nov 2009 12:14:33 -0800 (PST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 7745F3A6910 for ; Tue, 3 Nov 2009 12:14:31 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3KEisv004655; Tue, 3 Nov 2009 21:14:45 +0100 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA3KEiV2005580; Tue, 3 Nov 2009 21:14:44 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.3.83]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Tue, 3 Nov 2009 21:14:43 +0100 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat Date: Tue, 3 Nov 2009 21:14:39 +0100 Thread-Topic: [sipcore] Info-events and Request-Disposition etc. Thread-Index: AcpcoSNPpjDLJ5OYSFqoFQLzqRt7mwAAXVRgAAN4KiAABFKrIA== Message-ID: <7402509E63C5A145A6095D46C179A5B7058468FAF9@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net><4AF05761.1040202@cisco.com> <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:14:34 -0000 If we just stay in line with RFC 3841 and specify that these header fields = are allowed in an INFO request, even though they appear to be meaningless, = then if, at some point in the future, we update RFC 3841, aren't we going t= o go round in a circle and say we don't want to contradict the info-events = RFC? We have to bite the bullet at some stage. Or do you believe that these= header fields do serve some purpose in INFO, and that a future version of = RFC 3841 would clarify their use? John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 03 November 2009 18:10 > To: Elwell, John; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 > Hi, >=20 > Keith commented on the R-D header field in his comments, and the > following will be added to the header field table: >=20 > "Request-Disposition R o" >=20 > Other than that I don't think we need to say anything, but we=20 > shall not > deviate from 3841. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: 3. marraskuuta 2009 18:33 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 03 November 2009 16:17 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Info-events and Request-Disposition etc. > >=20 > >=20 > >=20 > > Elwell, John wrote: > > > The info-events draft does not mention the > > Request-Disposition header field. However, in RFC 3841,=20 > > Request-Disposition is indicated as optional in INFO requests.=20 > > Similarly for Accept-Contact and Reject-Contact. So there is an=20 > > apparent contradiction, which we should try to put right. > > >=20 > > > I fail to see the purpose of these header fields in an INFO > > Request, which can occur only on an INVITE-initiated dialog.=20 > > Therefore I think the info-events draft is correct. Does this=20 > > therefore mean that the draft updates RFC 3841, and if so=20 > do we need=20 > > to make explicit mention of the fact that RFC 3841 is updated by=20 > > removing the option of these header fields in an INFO request? > >=20 > > Well, IMO the Request-Disposition was very underspecified. > > Also, the possibility of 3xx responses to in-dialog requests is=20 > > underspecified. > >=20 > > *If* its possible to get a 3xx response to an INFO request,=20 > then the=20 > > Request-Disposition might be desired to control how a proxy=20 > deals with >=20 > > it. > >=20 > > It would be nice to clarify all of that, but this isn't the=20 > place to=20 > > do it. > >=20 > > So I would recommend that this draft *not* update 3841. > > I would try to avoid addressing the subject at all. > [JRE] That would be fine with me, as long as it is understood=20 > that there > are issues with RFC 3841 that we will not attempt to address in this > draft. The question arose from some discussions involving ETSI TISPAN > and 3GPP CT1, where 3841 seems to be taken as evidence these header > fields can be used in INFO. >=20 > John >=20 >=20 > >=20 > > Thanks, > > Paul > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From jbemmel@zonnet.nl Tue Nov 3 12:22:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D743A68AB for ; Tue, 3 Nov 2009 12:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax+CoY7k39XW for ; Tue, 3 Nov 2009 12:22:41 -0800 (PST) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id 858053A6898 for ; Tue, 3 Nov 2009 12:22:40 -0800 (PST) Received: (qmail 17991 invoked by uid 0); 3 Nov 2009 20:22:57 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 Nov 2009 20:22:57 -0000 Message-ID: <4AF0911F.8080503@zonnet.nl> Date: Tue, 03 Nov 2009 21:22:55 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Taisto Qvist XX References: <4AEF50D0.8010907@zonnet.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:22:42 -0000 Hi Taisto, Refer to table 2 in RFC3261 (section 20.1), where it says "o" for Contact in 1xx responses. I guess the reasoning is that the 1xx is unreliable and will always be followed by a 2xx response anyway, such that it is sufficient to include the Contact only in the 2xx. Obviously a 100rel scenario is an exception to this rule. Some other relevant references: 12.2.1.1: "A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog." 12.2.1.2 "When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present." In other words: the UAS can refresh its target too (but like for the UAC, even if RFC3261 doesn't spell it out, it SHOULD use the same URI unless there is a need to change it) Regards, Jeroen Taisto Qvist XX wrote: > Hi Jeroen, > > I know the scenario is a bit weird, but thats we I need more experts > telling the > firewall guys that they cant behave like this. My scenario-description > is a bit > simplified, but think of it as a bad fw-alg that manages to do > nat-traversal > logic for the contact in 2xx, but forgets to do so on the 1xx. > > Despite the scenarios possible...weirdess, I really need a clarification > to > wether a target refresh request is really just for refreshing the UAC's > Contact, or if it allowes the UAS to do the same. > > One thing puzzles me...you're saying that the Contact is NOT mandatory?? > > My reading of the rfc says that it IS mandatory, even though the "MUST" > is > spread over three different places. > > First we have: > > 8.2.6.2 > > in the response MUST equal that of the request. However, if the To > header field in the request did not contain a tag, the URI in the To > header field in the response MUST equal the URI in the To header > field; additionally, the UAS MUST add a tag to the To header field in > the response (with the exception of the 100 (Trying) response, in > which a tag MAY be present). > > So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's > optional. > > Secondly: > 12.1 Creation of a Dialog > > Dialogs are created through the generation of non-failure responses > to requests with specific methods. Within this specification, only > 2xx and 101-199 responses with a To tag, where the request was > INVITE, will establish a dialog. A dialog established by a non-final > response to a request is in the "early" state and it is called an > early dialog. > > and then finally: > > 12.1.1 UAS behavior > > When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > header field values from the request into the response (including the > URIs, URI parameters, and any Record-Route header field parameters, > whether they are known or unknown to the UAS) and MUST maintain the > order of those values. The UAS MUST add a Contact header field to > the response. The Contact header field contains an address where the > UAS would like to be contacted for subsequent requests in the dialog > (which includes the ACK for a 2xx response in the case of an INVITE). > > So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and > 3) that means I MUST add Contact. > > Is that not a correct interpretation, for INVITE?? > > The final reference is also the place where, at least with a little > imagination, > you could interpret the text in third paranthesis as to say "you must > put the > same contact in 1xx as in 2xx, since it should be used for ACK". > > Regards > Taisto Qvist > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: den 2 november 2009 22:36 > To: Taisto Qvist XX > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Changing contact/remote target in target refresh > response > > Hi Taisto, > > My question would be: what is the purpose of using different values in > the Contact header like this? It certainly complicates things, and does > not help interoperability. > Given your reference to a "firewall provider", I'm guessing it has > something to do with security? > > What is changing between Contact values, the IP address? port? some > 'magic' tag? > > Contact is optional in 1xx responses (except in case of 100rel), and in > practice I believe you will find that most UAS use the same value in 1xx > and 2xx responses to a given INVITE. There's no law against using > different values AFAIK, so in your step 5 the UAS could even use "b3" as > a value. The UAC should simply send its ACK to the contact from the 2xx > response to INVITE. > > Regards, > Jeroen > > Taisto Qvist XX wrote: > >> Hi folks, >> >> I am in a discussion with a firewall provider, regarding the >> > "legality" > >> for a UAS >> to use different Contact: uri's in 1xx and 2xx for the same >> transaction/dialog. >> >> I claim that you MUST use the same Contact in the 2xx as was sent the >> 1xx. >> Unfortunately I cant give him an explicit reference, since there is >> none(afaik?) >> >> Instead I must indicate chapters that indicate that UAS must >> initialize dialog state on reception of the 1xx, and that on reception >> > > >> of 2xx, the only thing that is recomputed, is the routeset. The >> firewall provider is not convinced. >> >> Also the text in 3261, 12.1.1 indicates(?) that the Contact should be >> the same in 2xx and 1xx. >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> order of those values. The UAS MUST add a Contact header field to the >> > > >> response. The Contact header field contains an address where the UAS >> would like to be contacted for subsequent requests in the dialog >> (which includes the ACK for a 2xx response in the case of an INVITE). >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> Now to my question, or sort of... >> >> Is a target refresh used by the UAC, and implicit target refresh >> possibility also for the UAS? >> In other words, is the response to a target refresh request, a >> "response target refresh"? >> >> Can the UAS add a new Contact in the 2xx response to a target refresh, >> > > >> and assume that the UAC updates its remote target? I've read Gonzalo >> Camarillo's draft, but it doesnt really mention this scenario. >> >> If the UAS can change his Contact, then I've become puzzled on what I >> should add in the final 2xx to an initial INVITE, if both >> sides(uas/uac) have updated their contacts during an UPDATE-target >> refresh in the early dialog. >> >> The flow would be >> 1) INVITE from A -> B (contact:a1) >> >> 2) 18x from B -> A (contact:b1) >> + prack, early media, go figure... >> >> 3) UPDATE from A -> B (contact:a2) >> >> 4) 2xx(UPD) from B -> A (contact:b2) << "target refresh >> response" >> >> 5) 2xx(INV) from B -> A (contact......b2 or b1?) >> >> 6) ACK-time..remote target is b2... >> >> If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the >> answer, but at the same time, the ACK must be sent to b2.... >> >> Any feedback you can give me would be much appreciated. >> >> Regards >> Taisto Qvist >> IP-Solutions >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From pkyzivat@cisco.com Tue Nov 3 12:27:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45193A6814 for ; Tue, 3 Nov 2009 12:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.576 X-Spam-Level: X-Spam-Status: No, score=-7.576 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9cDyhbUopTW for ; Tue, 3 Nov 2009 12:27:58 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4CB073A67D3 for ; Tue, 3 Nov 2009 12:27:58 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB8h8EpAZnwM/2dsb2JhbADHIJgYhD0E X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="66220725" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Nov 2009 20:28:18 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3KSLlv001484; Tue, 3 Nov 2009 20:28: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.3959); Tue, 3 Nov 2009 15:28:18 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 15:28:18 -0500 Message-ID: <4AF0920A.7040102@cisco.com> Date: Tue, 03 Nov 2009 15:26:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net><4AF05761.1040202@cisco.com> <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7058468FAF9@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7058468FAF9@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 20:28:18.0427 (UTC) FILETIME=[2DBE44B0:01CA5CC4] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:27:59 -0000 Elwell, John wrote: > If we just stay in line with RFC 3841 and specify that these header fields are allowed in an INFO request, even though they appear to be meaningless, then if, at some point in the future, we update RFC 3841, aren't we going to go round in a circle and say we don't want to contradict the info-events RFC? We have to bite the bullet at some stage. Or do you believe that these header fields do serve some purpose in INFO, and that a future version of RFC 3841 would clarify their use? Its possible (though unlikely). I think there may be some obscure cases where forking may occur mid-dialog. And its always been an open issue what happens if you get a 3xx response to a mid-dialog request. It isn't excluded but also isn't defined. In cases like those, there may be a role for a proxy to use the R-D header to decide how to handle the forking, etc. Its far fetched. But I see no advantage to making a gratuitous change to 3841 at this point without having considered any of those issues. I think it does less harm to leave well enough alone. Thanks, Paul On an unrelated note, do you notice how we all use notations like R-D, I-P, C-T, C-D, etc.? It would have been much nicer if sip had made provision for that sort of short form header names rather than the single letter forms. Of course they still aren't unique, but close enough for most purposes. > John > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 03 November 2009 18:10 >> To: Elwell, John; Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: RE: [sipcore] Info-events and Request-Disposition etc. >> >> >> Hi, >> >> Keith commented on the R-D header field in his comments, and the >> following will be added to the header field table: >> >> "Request-Disposition R o" >> >> Other than that I don't think we need to say anything, but we >> shall not >> deviate from 3841. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Elwell, John >> Sent: 3. marraskuuta 2009 18:33 >> To: Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Info-events and Request-Disposition etc. >> >> >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 03 November 2009 16:17 >>> To: Elwell, John >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Info-events and Request-Disposition etc. >>> >>> >>> >>> Elwell, John wrote: >>>> The info-events draft does not mention the >>> Request-Disposition header field. However, in RFC 3841, >>> Request-Disposition is indicated as optional in INFO requests. >>> Similarly for Accept-Contact and Reject-Contact. So there is an >>> apparent contradiction, which we should try to put right. >>>> I fail to see the purpose of these header fields in an INFO >>> Request, which can occur only on an INVITE-initiated dialog. >>> Therefore I think the info-events draft is correct. Does this >>> therefore mean that the draft updates RFC 3841, and if so >> do we need >>> to make explicit mention of the fact that RFC 3841 is updated by >>> removing the option of these header fields in an INFO request? >>> >>> Well, IMO the Request-Disposition was very underspecified. >>> Also, the possibility of 3xx responses to in-dialog requests is >>> underspecified. >>> >>> *If* its possible to get a 3xx response to an INFO request, >> then the >>> Request-Disposition might be desired to control how a proxy >> deals with >> >>> it. >>> >>> It would be nice to clarify all of that, but this isn't the >> place to >>> do it. >>> >>> So I would recommend that this draft *not* update 3841. >>> I would try to avoid addressing the subject at all. >> [JRE] That would be fine with me, as long as it is understood >> that there >> are issues with RFC 3841 that we will not attempt to address in this >> draft. The question arose from some discussions involving ETSI TISPAN >> and 3GPP CT1, where 3841 seems to be taken as evidence these header >> fields can be used in INFO. >> >> John >> >> >>> Thanks, >>> Paul >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From christer.holmberg@ericsson.com Tue Nov 3 12:58:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBBB3A68B3 for ; Tue, 3 Nov 2009 12:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoQQlYZuVCmO for ; Tue, 3 Nov 2009 12:58:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 99E0E3A6802 for ; Tue, 3 Nov 2009 12:58:27 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-aa-4af09987aab1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7D.AD.24026.78990FA4; Tue, 3 Nov 2009 21:58:47 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 21:58:47 +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: Tue, 3 Nov 2009 21:58:20 +0100 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7058468FAF9@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-events and Request-Disposition etc. thread-index: AcpcoSNPpjDLJ5OYSFqoFQLzqRt7mwAAXVRgAAN4KiAABFKrIAABkn+g References: <7402509E63C5A145A6095D46C179A5B7058468F9D5@DEMCHP99E35MSX.ww902.siemens.net><4AF05761.1040202@cisco.com> <7402509E63C5A145A6095D46C179A5B7058468FA9F@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7058468FAF9@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Nov 2009 20:58:47.0080 (UTC) FILETIME=[6FB49280:01CA5CC8] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info-events and Request-Disposition etc. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:58:30 -0000 Hi, If we in future update 3841, then we have to take the consequences. But, that can then be done in a more controlled manner than starting to "update" 3841 in different drafts all over. If the header has no purpose in INFO, then nobody is going to use it. It is optional to use. Regards, Christer=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 3. marraskuuta 2009 22:15 To: Christer Holmberg; Paul Kyzivat Cc: sipcore@ietf.org Subject: RE: [sipcore] Info-events and Request-Disposition etc. If we just stay in line with RFC 3841 and specify that these header fields are allowed in an INFO request, even though they appear to be meaningless, then if, at some point in the future, we update RFC 3841, aren't we going to go round in a circle and say we don't want to contradict the info-events RFC? We have to bite the bullet at some stage. Or do you believe that these header fields do serve some purpose in INFO, and that a future version of RFC 3841 would clarify their use? John=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 03 November 2009 18:10 > To: Elwell, John; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 > Hi, >=20 > Keith commented on the R-D header field in his comments, and the=20 > following will be added to the header field table: >=20 > "Request-Disposition R o" >=20 > Other than that I don't think we need to say anything, but we shall=20 > not deviate from 3841. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: 3. marraskuuta 2009 18:33 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Info-events and Request-Disposition etc. >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 03 November 2009 16:17 > > To: Elwell, John > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Info-events and Request-Disposition etc. > >=20 > >=20 > >=20 > > Elwell, John wrote: > > > The info-events draft does not mention the > > Request-Disposition header field. However, in RFC 3841,=20 > > Request-Disposition is indicated as optional in INFO requests. > > Similarly for Accept-Contact and Reject-Contact. So there is an=20 > > apparent contradiction, which we should try to put right. > > >=20 > > > I fail to see the purpose of these header fields in an INFO > > Request, which can occur only on an INVITE-initiated dialog.=20 > > Therefore I think the info-events draft is correct. Does this=20 > > therefore mean that the draft updates RFC 3841, and if so > do we need > > to make explicit mention of the fact that RFC 3841 is updated by=20 > > removing the option of these header fields in an INFO request? > >=20 > > Well, IMO the Request-Disposition was very underspecified. > > Also, the possibility of 3xx responses to in-dialog requests is=20 > > underspecified. > >=20 > > *If* its possible to get a 3xx response to an INFO request, > then the > > Request-Disposition might be desired to control how a proxy > deals with >=20 > > it. > >=20 > > It would be nice to clarify all of that, but this isn't the > place to > > do it. > >=20 > > So I would recommend that this draft *not* update 3841. > > I would try to avoid addressing the subject at all. > [JRE] That would be fine with me, as long as it is understood that=20 > there are issues with RFC 3841 that we will not attempt to address in=20 > this draft. The question arose from some discussions involving ETSI=20 > TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these=20 > header fields can be used in INFO. >=20 > John >=20 >=20 > >=20 > > Thanks, > > Paul > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Tue Nov 3 14:20:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B6528C0CE for ; Tue, 3 Nov 2009 14:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu5sgXQ88ZUV for ; Tue, 3 Nov 2009 14:20:37 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EDB0A3A6927 for ; Tue, 3 Nov 2009 14:20:36 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-a0-4af0acc8f494 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 2D.30.31706.8CCA0FA4; Tue, 3 Nov 2009 23:20:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 23:20: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 Date: Tue, 3 Nov 2009 23:19:03 +0100 Message-ID: In-Reply-To: <4AF044FA.6060203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: Acpclicu93Ynmyb3SgqD2v7Jh4p7jQAOzsXg References: <4AE9A6CD.80907@cisco.com> <4AEAFA5D.4080204@cisco.com> <4AEEE7B5.60301@cisco.com> <4AF044FA.6060203@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 03 Nov 2009 22:20:56.0426 (UTC) FILETIME=[E9D314A0:01CA5CD3] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:20:38 -0000 =20 Hi, >>>> But, would it then also be allowed to send one list in a reliable=20 >>>> 18x, and then a new list in the next relaible 18x, and then a third >>>> list in the 200 OK - all for the same transaction? >>> What bad things happen if you do that? >>=20 >>Maybe nothing. I just wanted to make sure you were ok with it :) > >Yes, I'm ok with it. It doesn't need to be forbidden just because its weird. In that case lots of things we do would be forbidden :) >>>The worst thing I can see is that you might get sent an I-P you don't >>>want to receive. Then you just ignore it, or send a 469, and go on=20 >>>about your business. >>>Perhaps its more trouble on the sending side, though its hard to >>>generalize. Consider the specific case of DTMF. A UA may be trying to >>>decide how to set itself up to send DTMF, choosing from among the >>>multitude of ways that are possible. If it gets a change - adding or >>>removing a DTMF info package, then it may have to change other things >>>as well, such as adding or removing telephone-events from its >>>media types. >>> >>>But, that problem exists whether or not we we allow changes in R-I >>between responses, so its not a big deal. >>=20 >>Maybe we could recommend against updating the list more than once per=20 >>transaction, especially if the list could have impacts on other=20 >>exchanged information (SDP etc). > >I guess I don't have a problem with recommendations. I rewrote section 3.2. The 2nd paragraph deals with this specific issue. NOTE: The text does NOT yet cover the 3pcc issue discussed further down. ----
A UA which supports the Info Package mechanism MUST indicate, using the Revc-Info header field, the=20 set of Info Packages for which it is willing to receive INFO requests. A UA can list multiple Info Packages=20 in a single Recv-Info header field, and the UA can use multiple Recv-Info header fields. The indication of Info Packages can take place during the dialog establishment, and later as part of a target refresh.=20 A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods=20 (and their responses) listed in . There are no "offer/answer" rules for Info Package indication.=20 For example, a UA can include a set of Info Packages in the INVITE request, and a new set in the ACK request. Likewise, a UA can included a set of Info Packages in a reliable response, and a new set in another reliable response for the same transaction. However, in order to avoid race conditions, and due to the fact that UAs might indicate other=20 capablities based on the Info Package set, it is RECOMMENDED that UAs do not not sent a list of Info Packages more than once per SIP transaction. If a UA is not willing to receive INFO requests for any Info Packages, during dialog establishment or later during the invite dialog usage,=20 the UA MUST indicate this by including a Recv-Info header field with a 'nil' value. This informs other UAs that the UA still supports the Info Package mechanism. Example: If a UA has previously indicated Info Packages 'foo' and 'bar', and the UA during the lifetime of the invite dialog usage wants to indicate=20 that it does not want to receive INFO requests for any Info Packages anymore, the UA sends a target refresh request with a Recv-Info header field=20 with a header value of 'nil'. =09 Once a UA has sent a list of Info Packages, the list is valid until the UA sends a new list, or a Recv-Info header field with a 'nil' value. Once a UA has indicated that it is willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST be prepared to receive INFO request associated with that Info Package. For a specific dialog, a UA MUST NOT send an INFO request associated with an Info Package until it has=20 received an indication that the remote UA is willing to receive INFO requests for that Info Package. If a UA indicates multiple Info Packages, which provide similar functionality, it is not possible to indicate=20 a priority order of the Info Packages, or that that the UA wishes to only receive INFO request for one of the Info Packages.=20 It is up to the application logic associated with the Info Packages, and specific Info Package specifications, to describe=20 application behavior in such cases. For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to=20 enable legacy INFO usages . This document does not define a SIP option tag for the Info Package mechanism. However, an=20 Info Package specification can define an option-tag associated with the specific Info Package, as described=20 in . For backward compatibility, if a UA indicates support of the INFO method using the Allow header=20 field , it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv-Info header field to indicate that it supports the Info Package mechanism, in addition=20 the UA still indicates support of the INFO method using the Allow header.
---- >>>>>Which dialog? Since this is 3pcc, and the interesting case is a >>>>>transfer, there are *3* dialogs. >>>>>It should never hurt to send an R-I in the context of a response to a reinvite. >>>>The draft says that you don't send a list unless you know that the other party -=20 >>>>for that dialog - supports the mechanism. >>>In 3pcc that can be a problem. You don't ever know if you are talking >>>to the same party that you were last time. >>>>There may indeed be a problem in one case. Here's a picture to=20 >>>>refer >>>>to: >>>>A ----- B ----- C >>>> | >>>> --- D >>>> >>>>Initially A is connected, via B to C. Then B initiates a 3pcc >>>>transfer by sending a reinvite to A. >>>>Now suppose that both A and C support I-P, but D does not. How will=20 >>>>A ever learn that D does not? It won't receive an R-I header from D, >>>>and so will assume its unchanged from what it had from C. And when it=20 >>>>sends INFOs with an I-P, D will think they are legacy. It will never >>>>send a 469, so it won't quench the sending. >>>> >>>I assume B has contected D before it sends the re-INVITE to A, right? >>>There are lots of ways to do it, depending on the goals of the case.=20 >>>So maybe yes, maybe no. >>>So, if D does NOT support I-P, I guess B would have to include=20 >>>R-I:nil in the re-INVITE to A. >>That means it won't work correctly unless B itself has an=20 >>understanding of info packages. It would be better if that were not a requirement. >>=20 >>But, how is this different from any other extension/capability=20 >>(non-SDP) that A and C may previously have agreed upon, and D doesn't support? > >The same issues can arise. But a 3pcc controller can try to be lenient in its processing of messages, only messing=20 >with things it understands, and relaying headers it doesn't understand. Sure, but how do you know that D is going to indicate all its capabilities (option-tags etc) in the re-INVITE response, so that A finds out about them? >We raise the bar if we require the 3pcc controller to do something *active* in order to make things work in this case. > >If we don't make it so that simply relaying the headers is enough, then perhaps there needs to be a whole section of B2BUA behavior, in addition to that for UAC and UAS. It just looks strange that we would mandate Recv-Info in re-INVITE responses, but otherwise there are no rules. And, wouldn't we then also need to mandate A to send his list in the ACK? How will D otherwise know what A is willing to receive? I am not against making sure it works for 3pcc, but to me it starts to look more and more like offer/answer :) Regards, Christer From taisto.xx.qvist@ericsson.com Wed Nov 4 00:52:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB63A3A699A for ; Wed, 4 Nov 2009 00:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXCGUnawVkEb for ; Wed, 4 Nov 2009 00:52:52 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 23D6F3A68BA for ; Wed, 4 Nov 2009 00:52:51 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-d4-4af140f7ab03 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0D.33.04191.7F041FA4; Wed, 4 Nov 2009 09:53:12 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 09:53:11 +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, 4 Nov 2009 09:53:05 +0100 Message-ID: In-Reply-To: <4AF0911F.8080503@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changing contact/remote target in targetrefresh response Thread-Index: AcpdLDliKot2AVXLS56+VZJz5ovTDA== References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> From: "Taisto Qvist XX" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 04 Nov 2009 08:53:11.0791 (UTC) FILETIME=[3D1067F0:01CA5D2C] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 08:52:54 -0000 Hi,=20 Regarding the table you refer to, I see that as generic rules for headers,=20 and that additional rules apply in some scenarios.=20 Anyway, it still doesnt change the three MUSTs i referred to.=20 They clearly say that IF I create a dialog, I MUST, without doubt,=20 add Contact, RR, etc. And since I MUST add the tag in all 1xx, I also create a dialog, etc, etc.=20 I dont see how those three rules can be disregarded, and I would really like more people to comment on this. The reference in 12.2.1.2 had slipped my mind, and thats annoying. It clearly says parts of what I wanted. A target-refresh is..."bi-directional", both sides can change their contact. But neither reference is actually valid in the scenario i described, since it=20 is NOT an indialog request.=20 I am referring to the 1xx and 2xx responses of an _initial_ INVITE. Even if it=20 would be as you say, that the contact is not mandatory in 1xx, it IS legal to send it, and there is no clear text saying that I cant, or MUST NOT change it when I send a 2xx. (apart from the description that UAC should only update route-set on reception of 2xx) The UAS will initialize its state on receiving the first dialog-creating response,=20 so if they get the 1xx, that's the remote-target that will be used on the ACK,=20 unless we add additional target-refreshes indialog with UPDATE. So what I am after is a simple rule describing what the Contact should be in 2xx,=20 for an initial when we dont have any target-refreshes complicating the issue.=20 I think that it should be more clearly stated that it MUST be the same as in the 1xx,=20 if you sent a contact in 1xx(if we accept that its not mandatory, which I think it is). For a scenario WITH target-refresh of the b-side with UPDATE during the early dialog,=20 it wouldnt hurt with some SHOULD's, or other explanatory text. I know these are cornercases, but they will, and ARE already creating interop-problems so I think its not really interesting why we'd like to do this, but wether it is allowed,=20 and how. Regards Taisto Qvist -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: den 3 november 2009 21:23 To: Taisto Qvist XX Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response Hi Taisto, Refer to table 2 in RFC3261 (section 20.1), where it says "o" for Contact in 1xx responses. I guess the reasoning is that the 1xx is unreliable and will always be followed by a 2xx response anyway, such that it is sufficient to include the Contact only in the 2xx. Obviously a 100rel scenario is an exception to this rule. Some other relevant references: 12.2.1.1: "A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog." 12.2.1.2 "When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present." In other words: the UAS can refresh its target too (but like for the UAC, even if RFC3261 doesn't spell it out, it SHOULD use the same URI unless there is a need to change it) Regards, Jeroen Taisto Qvist XX wrote: > Hi Jeroen, > > I know the scenario is a bit weird, but thats we I need more experts=20 > telling the firewall guys that they cant behave like this. My=20 > scenario-description is a bit simplified, but think of it as a bad=20 > fw-alg that manages to do nat-traversal logic for the contact in 2xx,=20 > but forgets to do so on the 1xx. > > Despite the scenarios possible...weirdess, I really need a=20 > clarification to wether a target refresh request is really just for=20 > refreshing the UAC's Contact, or if it allowes the UAS to do the same. > > One thing puzzles me...you're saying that the Contact is NOT mandatory?? > > My reading of the rfc says that it IS mandatory, even though the "MUST" > is > spread over three different places. > > First we have: > > 8.2.6.2 > > in the response MUST equal that of the request. However, if the To > header field in the request did not contain a tag, the URI in the To > header field in the response MUST equal the URI in the To header > field; additionally, the UAS MUST add a tag to the To header field in > the response (with the exception of the 100 (Trying) response, in > which a tag MAY be present).=20 > > So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's=20 > optional. > > Secondly: > 12.1 Creation of a Dialog > > Dialogs are created through the generation of non-failure responses > to requests with specific methods. Within this specification, only > 2xx and 101-199 responses with a To tag, where the request was > INVITE, will establish a dialog. A dialog established by a non-final > response to a request is in the "early" state and it is called an > early dialog. =20 > > and then finally: > > 12.1.1 UAS behavior > > When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > header field values from the request into the response (including the > URIs, URI parameters, and any Record-Route header field parameters, > whether they are known or unknown to the UAS) and MUST maintain the > order of those values. The UAS MUST add a Contact header field to > the response. The Contact header field contains an address where the > UAS would like to be contacted for subsequent requests in the dialog > (which includes the ACK for a 2xx response in the case of an INVITE). > > So this means that 1) I MUST add a to-tag, 2) This creates a dialog,=20 > and > 3) that means I MUST add Contact.=20 > > Is that not a correct interpretation, for INVITE?? > > The final reference is also the place where, at least with a little=20 > imagination, you could interpret the text in third paranthesis as to=20 > say "you must put the same contact in 1xx as in 2xx, since it should=20 > be used for ACK". > > Regards > Taisto Qvist > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: den 2 november 2009 22:36 > To: Taisto Qvist XX > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Changing contact/remote target in target=20 > refresh response > > Hi Taisto, > > My question would be: what is the purpose of using different values in > the Contact header like this? It certainly complicates things, and=20 > does not help interoperability. > Given your reference to a "firewall provider", I'm guessing it has=20 > something to do with security? > > What is changing between Contact values, the IP address? port? some=20 > 'magic' tag? > > Contact is optional in 1xx responses (except in case of 100rel), and=20 > in practice I believe you will find that most UAS use the same value=20 > in 1xx and 2xx responses to a given INVITE. There's no law against=20 > using different values AFAIK, so in your step 5 the UAS could even use > "b3" as a value. The UAC should simply send its ACK to the contact=20 > from the 2xx response to INVITE. > > Regards, > Jeroen > > Taisto Qvist XX wrote: > =20 >> Hi folks, >> =20 >> I am in a discussion with a firewall provider, regarding the >> =20 > "legality" > =20 >> for a UAS >> to use different Contact: uri's in 1xx and 2xx for the same=20 >> transaction/dialog. >> =20 >> I claim that you MUST use the same Contact in the 2xx as was sent the >> 1xx. >> Unfortunately I cant give him an explicit reference, since there is >> none(afaik?) >> >> Instead I must indicate chapters that indicate that UAS must=20 >> initialize dialog state on reception of the 1xx, and that on=20 >> reception >> =20 > > =20 >> of 2xx, the only thing that is recomputed, is the routeset. The=20 >> firewall provider is not convinced. >> =20 >> Also the text in 3261, 12.1.1 indicates(?) that the Contact should be >> the same in 2xx and 1xx. >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> order of those values. The UAS MUST add a Contact header field to=20 >> the >> =20 > > =20 >> response. The Contact header field contains an address where the UAS >> would like to be contacted for subsequent requests in the dialog=20 >> (which includes the ACK for a 2xx response in the case of an INVITE). >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> Now to my question, or sort of... >> >> Is a target refresh used by the UAC, and implicit target refresh=20 >> possibility also for the UAS? >> In other words, is the response to a target refresh request, a=20 >> "response target refresh"? >> >> Can the UAS add a new Contact in the 2xx response to a target=20 >> refresh, >> =20 > > =20 >> and assume that the UAC updates its remote target? I've read Gonzalo=20 >> Camarillo's draft, but it doesnt really mention this scenario. >> >> If the UAS can change his Contact, then I've become puzzled on what I >> should add in the final 2xx to an initial INVITE, if both >> sides(uas/uac) have updated their contacts during an UPDATE-target=20 >> refresh in the early dialog. >> >> The flow would be >> 1) INVITE from A -> B (contact:a1) >> >> 2) 18x from B -> A (contact:b1) >> + prack, early media, go figure... >> >> 3) UPDATE from A -> B (contact:a2) >> >> 4) 2xx(UPD) from B -> A (contact:b2) << "target refresh >> response" >> >> 5) 2xx(INV) from B -> A (contact......b2 or b1?) >> >> 6) ACK-time..remote target is b2... >> >> If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the=20 >> answer, but at the same time, the ACK must be sent to b2.... >> >> Any feedback you can give me would be much appreciated.=20 >> >> Regards >> Taisto Qvist >> IP-Solutions >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> =20 >> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From christer.holmberg@ericsson.com Wed Nov 4 23:54:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C096C3A684A for ; Wed, 4 Nov 2009 23:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l6KwiwPh-4Z for ; Wed, 4 Nov 2009 23:54:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5337428C121 for ; Wed, 4 Nov 2009 23:54:20 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b1-4af284c0c74d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 01.CB.24026.0C482FA4; Thu, 5 Nov 2009 08:54:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 08:53:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5DED.1C4EC57D" Date: Thu, 5 Nov 2009 08:53:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft-ietf-sipcore-info-events: pre-03 version thread-index: Acpd7Rw9zEQPJP3gSgOXgGXo0jHXlg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 05 Nov 2009 07:53:50.0207 (UTC) FILETIME=[1C9B90F0:01CA5DED] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft-ietf-sipcore-info-events: pre-03 version X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 07:54:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5DED.1C4EC57D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have put together a new, pre-03, version of the info-events draft. Again, based on WGLC comments and discussions there has been a number of re-writes and clarifications. Since we are in the no-draft-submission period, the draft is only an "unofficial draft" of the next version, and based on comments etc it may change before the "real" -03 version is submitted.=20 It can be downloaded from: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-03 pre.txt There are a few open issues I would like people to pay attention to: 1. When one registers an Info Package, do we require a reference to the implementation details of the Info Package? There could be people who don't want to provide those details (at least not openly to "anyone"), but may still want to register the Info Package. Allowing that would at least prevent someone else from registering a package with the same name. 2. Currently there are no strict rules on when UAs need to insert Recv-Info (ie there is nothing similar to offer-answer). The draft only indicates in which messages a UA is ALLOWED to do so. However, in order to support 3pcc it has been commented that we would need to require a UA to insert Recv-Info at least in a re-INVITE response, and probably also in the associated ACK. Regards, Christer ------_=_NextPart_001_01CA5DED.1C4EC57D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Draft-ietf-sipcore-info-events: pre-03 version

Hi,

I have put = together a new, pre-03, version of the info-events draft. Again, based = on WGLC comments and discussions there has been a number of re-writes = and clarifications.

Since we are in = the no-draft-submission period, the draft is only an "unofficial = draft" of the next version, and based on comments etc it may change = before the "real" -03 version is submitted.

It can be = downloaded from:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-= info-events-03pre.txt


There are a few = open issues I would like people to pay attention to:

1.      When one registers an = Info Package, do we require a reference to the implementation details of = the Info Package? There could be people who don't want to provide those = details (at least not openly to "anyone"), but may still want = to register the Info Package. Allowing that would at least prevent = someone else from registering a package with the same = name.

2.      Currently there are no = strict rules on when UAs need to insert Recv-Info (ie there is nothing = similar to offer-answer). The draft only indicates in which messages a = UA is ALLOWED to do so. However, in order to support 3pcc it has been = commented that we would need to require a UA to insert Recv-Info at = least in a re-INVITE response, and probably also in the associated = ACK.

Regards,

Christer


------_=_NextPart_001_01CA5DED.1C4EC57D-- From shida@ntt-at.com Thu Nov 5 05:37:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984BF3A68DA for ; Thu, 5 Nov 2009 05:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l07q0kkgUa+t for ; Thu, 5 Nov 2009 05:37:29 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.35.10]) by core3.amsl.com (Postfix) with SMTP id CFF9E3A683E for ; Thu, 5 Nov 2009 05:37:28 -0800 (PST) Received: (qmail 590 invoked from network); 5 Nov 2009 13:52:19 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 5 Nov 2009 13:52:19 -0000 Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:49741 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1N62X5-0002Fc-E9 for sipcore@ietf.org; Thu, 05 Nov 2009 07:37:47 -0600 From: Shida Schubert Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 5 Nov 2009 22:37:47 +0900 Message-Id: <5168B9C6-58DF-4B58-84DB-D0BCBB480866@ntt-at.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Subject: [sipcore] Revised 4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:37:29 -0000 All, I forgot to mention this but we have updated the 4244bis and made the following changes. http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-03 1. Removed 'cc', 'rt' and 'aor' tag so we now only have two tags, 'rc' for when the retargeting is a translation to a registered contact and 'mp' for when target user addressed in R-URI changes. 2. Added index to 'mp' to show which URI resulted in changing of the target. 3. Changed the call-flow to reflect the changes. 4. Added use-cases from target-uri draft and composed a call-flow for each of the use-cases to show how 4244bis can be used to address them. I think the mechanism is easier to understand and much more deterministic. Regards Shida From shida@ntt-at.com Thu Nov 5 05:53:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD3F3A6AC2 for ; Thu, 5 Nov 2009 05:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IzIyyBltfGd for ; Thu, 5 Nov 2009 05:53:57 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.195.10]) by core3.amsl.com (Postfix) with SMTP id 4AEA73A6AA7 for ; Thu, 5 Nov 2009 05:53:57 -0800 (PST) Received: (qmail 14940 invoked from network); 5 Nov 2009 14:06:46 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway13.websitewelcome.com with SMTP; 5 Nov 2009 14:06:46 -0000 Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:49747 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1N62n1-0007rH-Lk; Thu, 05 Nov 2009 07:54:17 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: Date: Thu, 5 Nov 2009 22:54:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> To: Ian Elz X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:53:58 -0000 One of the co-author (Hans Eric) actually pointed out that toll-free number can be addressed with the current spec. According to 4244bis, 'mp' is added when the target user changes. With toll-free, after the call is routed to a toll-free any =20 retargeting after that should indeed be targeted towards the same user so the target user isn't really changing even if the R-URI is rewritten, unless of course call is diverted to a completely different user. So with this in mind let's look at the example John had previously mentioned on the list. - Example 1: Call from A to B, which is forwarded to freephone =20 number C, which resolves to D, which resolves to contact E. This would look like the followings. H-I: B; index=3D1 H-I: C; index=3D1.1;mp=3D1 H-I: D; index=3D1.1.1 H-I: E; index=3D1.1.1.1; rc C and D represents the same user so, E can simply look at the last 'mp' tagged entry to see if the call was made to its toll-free alias. - Example 2: Call from A to freephone number B, which resolves to C, =20 which is then forwarded to D, which resolves to contact E. H-I: B; index=3D1 H-I: C; index=3D1.1; H-I: D; index=3D1.1.1; H-I: E; index=3D1.1.1.1;rc Here if C and D are both expecting a call via toll-free number(b), say office in Dallas and office in NY representing the same company, then they are both the same user toll-free is trying to contact, so there is no 'mp' tag and E looks at the first H-I entry. To identify whether the call came in via the service number, one would look for the last 'mp' tagged entry OR if there is none look at the first 'hi-entry'. Any comments? Regards Shida On Oct 26, 2009, at 7:36 PM, Ian Elz wrote: > All, > > Paul is correct in the name to name translation. > > As well as the basic translation that Paul identified it is also =20 > common to translate from one 'freephone type' number to another. =20 > This occurs where a call answering service has multiple answering =20 > locations and the specific answering location is determined based =20 > upon identity of the caller, date/day/time etc. > > When the call answering service is required to handle calls from =20 > multiple different 'freephone' numbers then it is often easier to =20 > have one number which defines the answering location and another =20 > which is the 'dialed' number which translates to the number, or =20 > numbers, which define the call handling. In effect a hierarchy can =20 > be using these numbers which translate to each other. > > I use the term 'freephone type' as freephone relates to one charging =20= > scenario where there are other charging scenarios defined in =20 > different regulatory regimes, local call rate, national call rate =20 > and a plethora of different premium rates. All of these are =20 > logically handled in a similar fashion. > > The ISUP PSTN network allows the provision 2 different numbers to =20 > the called party, original called party number and redirecting =20 > number. The redirecting number is the last identity which performed =20= > a diversion of redirection. The original called party number is the =20= > number dialed by the caller ( as modified by the network to make is =20= > a standard format, e.g. national or international number). > > For H-I we need to be able to replicate at least the ability to =20 > identify the original number/identity called and the last identity =20 > which diverted/redirected the call. > > The intermediate information which is not available in ISUP is also =20= > useful, particularly when some data is incorrect, as it allow =20 > tracing of how a call was handled. > > Ian Elz > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 20 October 2009 00:33 > To: Elwell, John > Cc: Jonathan Lennox; Fran=E7ois AUDET; sipcore@ietf.org; Hadriel =20 > Kaplan; Dean Willis; ELWELL John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > Elwell, John wrote: >> But in actual fact, any E.164 number is a name, so the tag would =20 >> apply to any E.164 to SIP URI translation. Is this helpful? > > Yes, any E.164 number is a name, even if it is embedded in a SIP uri =20= > containing a domain name. (Its quite likely the domain name doesn't =20= > reflect the "owner" of the E.164 number, just a convenient server =20 > that will hopefully figure out what to do next based on the number.) > > Of course, once upon a time phone numbers *were* addresses, and were =20= > routed digit by digit. But that time is over. Similarly, the domain =20= > names in SIP URIs are *name*s, not addresses. And the IP addresses =20 > are actually names too, ... What's a name and what's an address is a =20= > matter of perspective and layering. > > So, to go this will will require careful definition of the =20 > distinction in this context. > > Also, Shida said: > >> In deployment, name to name translation never happens > > That's not really true is it? IIUC, its pretty normal for a "name" =20 > like > 1-800-666-1111 to be translated to another name,like 1-212-555-1234, =20= > which then must be routed to a responsible server. > > Thanks, > Paul > > >> John >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET >>> Sent: 18 October 2009 15:37 >>> To: Shida Schubert >>> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; >>> ELWELL John; Keith Drage >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>> >>> This is quite an interesting idea. Probably wider in scope than >>> History-Info, but it sounds like a good way to tackle the problem. >>> >>> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: >>> >>>> The reason why current use of "mp" tag is not semantically correct >>>> for freephone, is because Service-URN and free-phone is a "name" =20= >>>> and >>>> not an "address" based on the definition in the target-uri draft. >>>> >>>> I believe we need to define another tag for "name" to "address" >>>> translation. >>>> >>>> ## Definition of address/name in the target-uri draft ## >>>> >>>> A name is a moniker for an entity which refers to it in a >>> way which >>>> reveals nothing about where it is in a network. In SIP, tel URI >>>> which doesn't represent the location of the entity is a name. >>>> >>>> An address is an identifier for an entity which describes >>> it by its >>>> location on the network. In SIP, the SIP URI itself is a form of >>>> address because the host part of the URI, the only >>> mandatory part of >>>> the URI besides the scheme itself, indicates the location of a SIP >>>> server that can be used to handle the request. >>>> >>>> ## -- ## >>>> >>>> In deployment, name to name translation never happens and generally >>>> "name" to "address" translation is very deterministic that entity >>>> doing the mapping/translation can tag the entry with confidence. >>>> >>>> For example, If one sends a request to PSAP using 911, directory >>>> assistance using 411, name(411,911 or service-URN) is translated to >>>> an address. That address may be translated numerous times to =20 >>>> another >>>> address (PSAP in NYC to PSAP in NJ) but will never be translated >>>> again to another name(911 to 411). >>>> >>>> Furthermore, entity/organization that is expecting to be reached by >>>> name usually knows what name it will be reached by, so having the >>>> ability to distinguish one service to another is probably not >>>> necessary but having the ability to tag "name" to "address" >>>> translation, I believe is very helpful. >>>> >>>> Any thoughts? >>>> >>>> Regards >>>> Shida >>>> >>>> >>>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: >>>> >>>>> Other idea? >>>>> >>>>> (I really don't care personally about "freephone"...) >>>>> >>>>>> -----Original Message----- >>>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>>>> Sent: Thursday, September 24, 2009 11:48 >>>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert; >>>>>> Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; >>>>>> Elwell, John; Keith Drage >>>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>>>>> >>>>>> Yes got that, but that does not justify a service specific tag in >>>>>> 4244bis. >>>>>> /hans erik >>>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Thu Nov 5 07:56:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B29828C1D3 for ; Thu, 5 Nov 2009 07:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.783 X-Spam-Level: X-Spam-Status: No, score=-5.783 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lLIX-iqbKCW for ; Thu, 5 Nov 2009 07:56:31 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 6F8C73A67EB for ; Thu, 5 Nov 2009 07:56:30 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nA5FudeF024050; Thu, 5 Nov 2009 16:56:39 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA5Fucbm029386; Thu, 5 Nov 2009 16:56:38 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.156]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 5 Nov 2009 16:56:37 +0100 From: "Elwell, John" To: Shida Schubert , Ian Elz Date: Thu, 5 Nov 2009 16:56:02 +0100 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcpeH3oF9TXTuZkvRNGhrW9/LN3y0gACRWcA Message-ID: <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 15:56:32 -0000 =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 05 November 2009 13:54 > To: Ian Elz > Cc: Paul Kyzivat; Elwell, John; Fran=E7ois AUDET; SIPCORE;=20 > Hadriel Kaplan; Dean Willis; ELWELL John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 > One of the co-author (Hans Eric) actually pointed out > that toll-free number can be addressed with the current spec. >=20 > According to 4244bis, 'mp' is added when the target user > changes. >=20 > With toll-free, after the call is routed to a toll-free any =20 > retargeting > after that should indeed be targeted towards the same user > so the target user isn't really changing even if the R-URI is > rewritten, unless of course call is diverted to a completely > different user. >=20 > So with this in mind let's look at the example John had > previously mentioned on the list. >=20 > - Example 1: Call from A to B, which is forwarded to freephone =20 > number C, which resolves to D, which resolves to contact E. >=20 > This would look like the followings. >=20 > H-I: B; index=3D1 > H-I: C; index=3D1.1;mp=3D1 > H-I: D; index=3D1.1.1 > H-I: E; index=3D1.1.1.1; rc >=20 > C and D represents the same user so, E can simply look > at the last 'mp' tagged entry to see if the call was made to its > toll-free alias. >=20 > - Example 2: Call from A to freephone number B, which resolves to C, =20 > which is then forwarded to D, which resolves to contact E. >=20 > H-I: B; index=3D1 > H-I: C; index=3D1.1; > H-I: D; index=3D1.1.1; [JRE] I think this should have an mp tag, because the entity doing the forw= arding would normally apply the mp tag when forwarding. The fact that earli= er the request had been targeted at a freephone number is unlikely to influ= ence forwarding behaviour (and indeed might not be known to the entity doin= g the forwarding), so the mp tag would be added. John > H-I: E; index=3D1.1.1.1;rc >=20 > Here if C and D are both expecting a call via > toll-free number(b), say office in Dallas and > office in NY representing the same company, > then they are both the same user toll-free is > trying to contact, so there is no 'mp' tag and E > looks at the first H-I entry. >=20 > To identify whether the call came in via the service number, > one would look for the last 'mp' tagged entry OR if there is > none look at the first 'hi-entry'. >=20 > Any comments? >=20 > Regards > Shida >=20 > On Oct 26, 2009, at 7:36 PM, Ian Elz wrote: >=20 > > All, > > > > Paul is correct in the name to name translation. > > > > As well as the basic translation that Paul identified it is also =20 > > common to translate from one 'freephone type' number to another. =20 > > This occurs where a call answering service has multiple answering =20 > > locations and the specific answering location is determined based =20 > > upon identity of the caller, date/day/time etc. > > > > When the call answering service is required to handle calls from =20 > > multiple different 'freephone' numbers then it is often easier to =20 > > have one number which defines the answering location and another =20 > > which is the 'dialed' number which translates to the number, or =20 > > numbers, which define the call handling. In effect a hierarchy can =20 > > be using these numbers which translate to each other. > > > > I use the term 'freephone type' as freephone relates to one=20 > charging =20 > > scenario where there are other charging scenarios defined in =20 > > different regulatory regimes, local call rate, national call rate =20 > > and a plethora of different premium rates. All of these are =20 > > logically handled in a similar fashion. > > > > The ISUP PSTN network allows the provision 2 different numbers to =20 > > the called party, original called party number and redirecting =20 > > number. The redirecting number is the last identity which=20 > performed =20 > > a diversion of redirection. The original called party=20 > number is the =20 > > number dialed by the caller ( as modified by the network to=20 > make is =20 > > a standard format, e.g. national or international number). > > > > For H-I we need to be able to replicate at least the ability to =20 > > identify the original number/identity called and the last identity =20 > > which diverted/redirected the call. > > > > The intermediate information which is not available in ISUP=20 > is also =20 > > useful, particularly when some data is incorrect, as it allow =20 > > tracing of how a call was handled. > > > > Ian Elz > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 20 October 2009 00:33 > > To: Elwell, John > > Cc: Jonathan Lennox; Fran=E7ois AUDET; sipcore@ietf.org; Hadriel =20 > > Kaplan; Dean Willis; ELWELL John; Keith Drage > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > Elwell, John wrote: > >> But in actual fact, any E.164 number is a name, so the tag would =20 > >> apply to any E.164 to SIP URI translation. Is this helpful? > > > > Yes, any E.164 number is a name, even if it is embedded in=20 > a SIP uri =20 > > containing a domain name. (Its quite likely the domain name=20 > doesn't =20 > > reflect the "owner" of the E.164 number, just a convenient server =20 > > that will hopefully figure out what to do next based on the number.) > > > > Of course, once upon a time phone numbers *were* addresses,=20 > and were =20 > > routed digit by digit. But that time is over. Similarly,=20 > the domain =20 > > names in SIP URIs are *name*s, not addresses. And the IP addresses =20 > > are actually names too, ... What's a name and what's an=20 > address is a =20 > > matter of perspective and layering. > > > > So, to go this will will require careful definition of the =20 > > distinction in this context. > > > > Also, Shida said: > > > >> In deployment, name to name translation never happens > > > > That's not really true is it? IIUC, its pretty normal for a "name" =20 > > like > > 1-800-666-1111 to be translated to another name,like=20 > 1-212-555-1234, =20 > > which then must be routed to a responsible server. > > > > Thanks, > > Paul > > > > > >> John > >> > >>> -----Original Message----- > >>> From: sipcore-bounces@ietf.org > >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET > >>> Sent: 18 October 2009 15:37 > >>> To: Shida Schubert > >>> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan;=20 > Dean Willis; > >>> ELWELL John; Keith Drage > >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >>> > >>> This is quite an interesting idea. Probably wider in scope than > >>> History-Info, but it sounds like a good way to tackle the problem. > >>> > >>> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: > >>> > >>>> The reason why current use of "mp" tag is not=20 > semantically correct > >>>> for freephone, is because Service-URN and free-phone is=20 > a "name" =20 > >>>> and > >>>> not an "address" based on the definition in the target-uri draft. > >>>> > >>>> I believe we need to define another tag for "name" to "address" > >>>> translation. > >>>> > >>>> ## Definition of address/name in the target-uri draft ## > >>>> > >>>> A name is a moniker for an entity which refers to it in a > >>> way which > >>>> reveals nothing about where it is in a network. In SIP, tel URI > >>>> which doesn't represent the location of the entity is a name. > >>>> > >>>> An address is an identifier for an entity which describes > >>> it by its > >>>> location on the network. In SIP, the SIP URI itself is=20 > a form of > >>>> address because the host part of the URI, the only > >>> mandatory part of > >>>> the URI besides the scheme itself, indicates the=20 > location of a SIP > >>>> server that can be used to handle the request. > >>>> > >>>> ## -- ## > >>>> > >>>> In deployment, name to name translation never happens=20 > and generally > >>>> "name" to "address" translation is very deterministic that entity > >>>> doing the mapping/translation can tag the entry with confidence. > >>>> > >>>> For example, If one sends a request to PSAP using 911, directory > >>>> assistance using 411, name(411,911 or service-URN) is=20 > translated to > >>>> an address. That address may be translated numerous times to =20 > >>>> another > >>>> address (PSAP in NYC to PSAP in NJ) but will never be translated > >>>> again to another name(911 to 411). > >>>> > >>>> Furthermore, entity/organization that is expecting to be=20 > reached by > >>>> name usually knows what name it will be reached by, so having the > >>>> ability to distinguish one service to another is probably not > >>>> necessary but having the ability to tag "name" to "address" > >>>> translation, I believe is very helpful. > >>>> > >>>> Any thoughts? > >>>> > >>>> Regards > >>>> Shida > >>>> > >>>> > >>>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: > >>>> > >>>>> Other idea? > >>>>> > >>>>> (I really don't care personally about "freephone"...) > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > >>>>>> Sent: Thursday, September 24, 2009 11:48 > >>>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert; > >>>>>> Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; > >>>>>> Elwell, John; Keith Drage > >>>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >>>>>> > >>>>>> Yes got that, but that does not justify a service=20 > specific tag in > >>>>>> 4244bis. > >>>>>> /hans erik > >>>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > = From ian.elz@ericsson.com Thu Nov 5 08:51:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3113A6AE1 for ; Thu, 5 Nov 2009 08:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXnoaAoMqHQd for ; Thu, 5 Nov 2009 08:51:09 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 46C693A6B2B for ; Thu, 5 Nov 2009 08:51:08 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-13-4af302913ff0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 98.BE.04191.19203FA4; Thu, 5 Nov 2009 17:51:29 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 17:50:14 +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 Date: Thu, 5 Nov 2009 17:50:12 +0100 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcpeH3oF9TXTuZkvRNGhrW9/LN3y0gACRWcAAAN0YZA= References: <4A5FAF4E.4030901@cisco.com><1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com><8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com><1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com><7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net><1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com><7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net><1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com><9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com><9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com><1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com><5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com><03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> From: "Ian Elz" To: "Elwell, John" , "Shida Schubert" X-OriginalArrivalTime: 05 Nov 2009 16:50:14.0041 (UTC) FILETIME=[0BAAE890:01CA5E38] X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:51:10 -0000 Schilda, John, I agree with John that in the second case the mp tag should be added = when the forwarding occurs. The first example shows an interesting case as the original number is = not the freephone number. In this case the answering system would need = to look through the H-I entries to find a number which it recognizes. I am unsure whether the translation from the freephone number to the new = identity should be considered to be the same user. At the time that the = particular INVITE occurs then freephone number is a 'proxy identity' for = the translated identity. [I know that this is not a very good term.] The = next INVITE to the same freephone number could translate to a totally = different number but that is largely irrelevant. If we take the approach that when a freephone number translates it does = not include an mp tag then we need to ensure that this will not result = in other issues; e.g. counting of number or times the INVITE has been = forwarded. I don't think that this will be an issue. The alternative is to have = another tag which distinguishes translations from mapping. Not sure that = this will help though as you may end up with many different tags. I will look back through the draft to refresh my memory as to the = initial issues. Ian -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 05 November 2009 15:56 To: Shida Schubert; Ian Elz Cc: Paul Kyzivat; Fran=E7ois AUDET; SIPCORE; Hadriel Kaplan; Dean = Willis; ELWELL John; Keith Drage Subject: RE: [sipcore] rfc4244bis: what is an AoR? =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: 05 November 2009 13:54 > To: Ian Elz > Cc: Paul Kyzivat; Elwell, John; Fran=E7ois AUDET; SIPCORE; Hadriel=20 > Kaplan; Dean Willis; ELWELL John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 > One of the co-author (Hans Eric) actually pointed out that toll-free = > number can be addressed with the current spec. >=20 > According to 4244bis, 'mp' is added when the target user changes. >=20 > With toll-free, after the call is routed to a toll-free any=20 > retargeting after that should indeed be targeted towards the same user = > so the target user isn't really changing even if the R-URI is=20 > rewritten, unless of course call is diverted to a completely different = > user. >=20 > So with this in mind let's look at the example John had previously=20 > mentioned on the list. >=20 > - Example 1: Call from A to B, which is forwarded to freephone=20 > number C, which resolves to D, which resolves to contact E. >=20 > This would look like the followings. >=20 > H-I: B; index=3D1 > H-I: C; index=3D1.1;mp=3D1 > H-I: D; index=3D1.1.1 > H-I: E; index=3D1.1.1.1; rc >=20 > C and D represents the same user so, E can simply look at the last=20 > 'mp' tagged entry to see if the call was made to its toll-free alias. >=20 > - Example 2: Call from A to freephone number B, which resolves to C,=20 > which is then forwarded to D, which resolves to contact E. >=20 > H-I: B; index=3D1 > H-I: C; index=3D1.1; > H-I: D; index=3D1.1.1; [JRE] I think this should have an mp tag, because the entity doing the = forwarding would normally apply the mp tag when forwarding. The fact = that earlier the request had been targeted at a freephone number is = unlikely to influence forwarding behaviour (and indeed might not be = known to the entity doing the forwarding), so the mp tag would be added. John > H-I: E; index=3D1.1.1.1;rc >=20 > Here if C and D are both expecting a call via toll-free number(b),=20 > say office in Dallas and office in NY representing the same company, > then they are both the same user toll-free is trying to contact, so=20 > there is no 'mp' tag and E looks at the first H-I entry. >=20 > To identify whether the call came in via the service number, one=20 > would look for the last 'mp' tagged entry OR if there is none look at=20 > the first 'hi-entry'. >=20 > Any comments? >=20 > Regards > Shida >=20 > On Oct 26, 2009, at 7:36 PM, Ian Elz wrote: >=20 > > All, > > > > Paul is correct in the name to name translation. > > > > As well as the basic translation that Paul identified it is also=20 > > common to translate from one 'freephone type' number to another. > > This occurs where a call answering service has multiple answering=20 > > locations and the specific answering location is determined based=20 > > upon identity of the caller, date/day/time etc. > > > > When the call answering service is required to handle calls from=20 > > multiple different 'freephone' numbers then it is often easier to=20 > > have one number which defines the answering location and another=20 > > which is the 'dialed' number which translates to the number, or=20 > > numbers, which define the call handling. In effect a hierarchy can=20 > > be using these numbers which translate to each other. > > > > I use the term 'freephone type' as freephone relates to one > charging > > scenario where there are other charging scenarios defined in=20 > > different regulatory regimes, local call rate, national call rate=20 > > and a plethora of different premium rates. All of these are=20 > > logically handled in a similar fashion. > > > > The ISUP PSTN network allows the provision 2 different numbers to=20 > > the called party, original called party number and redirecting=20 > > number. The redirecting number is the last identity which > performed > > a diversion of redirection. The original called party > number is the > > number dialed by the caller ( as modified by the network to > make is > > a standard format, e.g. national or international number). > > > > For H-I we need to be able to replicate at least the ability to=20 > > identify the original number/identity called and the last identity=20 > > which diverted/redirected the call. > > > > The intermediate information which is not available in ISUP > is also > > useful, particularly when some data is incorrect, as it allow=20 > > tracing of how a call was handled. > > > > Ian Elz > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 20 October 2009 00:33 > > To: Elwell, John > > Cc: Jonathan Lennox; Fran=E7ois AUDET; sipcore@ietf.org; Hadriel=20 > > Kaplan; Dean Willis; ELWELL John; Keith Drage > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > Elwell, John wrote: > >> But in actual fact, any E.164 number is a name, so the tag would=20 > >> apply to any E.164 to SIP URI translation. Is this helpful? > > > > Yes, any E.164 number is a name, even if it is embedded in > a SIP uri > > containing a domain name. (Its quite likely the domain name > doesn't > > reflect the "owner" of the E.164 number, just a convenient server=20 > > that will hopefully figure out what to do next based on the number.) > > > > Of course, once upon a time phone numbers *were* addresses, > and were > > routed digit by digit. But that time is over. Similarly, > the domain > > names in SIP URIs are *name*s, not addresses. And the IP addresses=20 > > are actually names too, ... What's a name and what's an > address is a > > matter of perspective and layering. > > > > So, to go this will will require careful definition of the=20 > > distinction in this context. > > > > Also, Shida said: > > > >> In deployment, name to name translation never happens > > > > That's not really true is it? IIUC, its pretty normal for a "name" =20 > > like > > 1-800-666-1111 to be translated to another name,like > 1-212-555-1234, > > which then must be routed to a responsible server. > > > > Thanks, > > Paul > > > > > >> John > >> > >>> -----Original Message----- > >>> From: sipcore-bounces@ietf.org > >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET > >>> Sent: 18 October 2009 15:37 > >>> To: Shida Schubert > >>> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > Dean Willis; > >>> ELWELL John; Keith Drage > >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >>> > >>> This is quite an interesting idea. Probably wider in scope than=20 > >>> History-Info, but it sounds like a good way to tackle the problem. > >>> > >>> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: > >>> > >>>> The reason why current use of "mp" tag is not > semantically correct > >>>> for freephone, is because Service-URN and free-phone is > a "name" =20 > >>>> and > >>>> not an "address" based on the definition in the target-uri draft. > >>>> > >>>> I believe we need to define another tag for "name" to "address" > >>>> translation. > >>>> > >>>> ## Definition of address/name in the target-uri draft ## > >>>> > >>>> A name is a moniker for an entity which refers to it in a > >>> way which > >>>> reveals nothing about where it is in a network. In SIP, tel URI = =20 > >>>> which doesn't represent the location of the entity is a name. > >>>> > >>>> An address is an identifier for an entity which describes > >>> it by its > >>>> location on the network. In SIP, the SIP URI itself is > a form of > >>>> address because the host part of the URI, the only > >>> mandatory part of > >>>> the URI besides the scheme itself, indicates the > location of a SIP > >>>> server that can be used to handle the request. > >>>> > >>>> ## -- ## > >>>> > >>>> In deployment, name to name translation never happens > and generally > >>>> "name" to "address" translation is very deterministic that entity = > >>>> doing the mapping/translation can tag the entry with confidence. > >>>> > >>>> For example, If one sends a request to PSAP using 911, directory=20 > >>>> assistance using 411, name(411,911 or service-URN) is > translated to > >>>> an address. That address may be translated numerous times to=20 > >>>> another address (PSAP in NYC to PSAP in NJ) but will never be=20 > >>>> translated again to another name(911 to 411). > >>>> > >>>> Furthermore, entity/organization that is expecting to be > reached by > >>>> name usually knows what name it will be reached by, so having the = > >>>> ability to distinguish one service to another is probably not=20 > >>>> necessary but having the ability to tag "name" to "address" > >>>> translation, I believe is very helpful. > >>>> > >>>> Any thoughts? > >>>> > >>>> Regards > >>>> Shida > >>>> > >>>> > >>>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: > >>>> > >>>>> Other idea? > >>>>> > >>>>> (I really don't care personally about "freephone"...) > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > >>>>>> Sent: Thursday, September 24, 2009 11:48 > >>>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert; = > >>>>>> Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; = > >>>>>> Elwell, John; Keith Drage > >>>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >>>>>> > >>>>>> Yes got that, but that does not justify a service > specific tag in > >>>>>> 4244bis. > >>>>>> /hans erik > >>>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From brett@broadsoft.com Thu Nov 5 09:16:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823273A6875 for ; Thu, 5 Nov 2009 09:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQAm6GXRsM0s for ; Thu, 5 Nov 2009 09:16:27 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 85BEB3A6768 for ; Thu, 5 Nov 2009 09:16:27 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 5 Nov 2009 09:16:49 -0800 From: Brett Tate To: Taisto Qvist XX , "sipcore@ietf.org" Date: Thu, 5 Nov 2009 09:16:41 -0800 Thread-Topic: [sipcore] Changing contact/remote target in targetrefresh response Thread-Index: AcpdLDliKot2AVXLS56+VZJz5ovTDABCz11w Message-ID: <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@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 Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:16:28 -0000 Hi Taisto, I agree that the rfc3261 text is ambiguous and has some conflicting stateme= nts. The following thread discusses some of the ambiguities: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020127= .html In my opinion, a strict interpretation of rfc3261 does not allow INVITE 1xx= /2xx's Contact to update the target during call set-up after the dialog has= been created. I'm not sure if the authors actually intended such a restri= ction; I not aware of vendors actually enforcing such a restriction. The following is some questions/text from above thread in case someone want= s to answer the questions. Should the remote target be updated per INVITE 2xx's Contact? If not, then why is section 13.2.2.4 pointing to section 12.2.1.2? When I posted my question, I had thought that it was trying to indicate to adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. Is the following what rfc3261 is attempting to communicate? 1) Dialog forming INVITE 1xx/2xx creates route set based upon record-route and sets remote target per Contact. 2) Original INVITE's subsequent 101-199 has no impact upon a known dialog's route set and remote target. 3) Original INVITE's 2xx resets route set per received/missing record-route and does not set (or update) per Contact. 4) Retargeting (excluding original INVITE) request's 2xx within dialog allow the remote target to be updated. From jbemmel@zonnet.nl Thu Nov 5 15:15:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB363A6836 for ; Thu, 5 Nov 2009 15:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H-InDQa1Qgn for ; Thu, 5 Nov 2009 15:15:55 -0800 (PST) Received: from smtp5.versatel.nl (smtp5.versatel.nl [62.58.50.96]) by core3.amsl.com (Postfix) with ESMTP id 159383A67E2 for ; Thu, 5 Nov 2009 15:15:53 -0800 (PST) Received: (qmail 27646 invoked by uid 0); 5 Nov 2009 23:16:13 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp5.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Nov 2009 23:16:13 -0000 Message-ID: <4AF35CB9.1000803@zonnet.nl> Date: Fri, 06 Nov 2009 00:16:09 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Taisto Qvist XX , "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:15:56 -0000 Brett, Even if it's not clearly defined, to me the rule should be simple: always update the remote target whenever a valid target refresh request/response (1xx or 2xx) containing a Contact header is received (with "valid" meaning syntactically correct and in proper dialog sequence, matching an existing transaction for responses, and no retransmission) It must be assumed that the peer is communicating its most up-to-date value for its Contact address, I see no reason to ignore such updates (and I do see how ignoring an updated Contact can cause failures, the peer may have obtained a new IP address for example, during the time interval it was ringing - e.g. some handset being picked up from a docking station with a fixed LAN cable, switching to WiFi) Regards, Jeroen Brett Tate wrote: > Hi Taisto, > > I agree that the rfc3261 text is ambiguous and has some conflicting statements. > > The following thread discusses some of the ambiguities: > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020127.html > > In my opinion, a strict interpretation of rfc3261 does not allow INVITE 1xx/2xx's Contact to update the target during call set-up after the dialog has been created. I'm not sure if the authors actually intended such a restriction; I not aware of vendors actually enforcing such a restriction. > > The following is some questions/text from above thread in case someone wants to answer the questions. > > Should the remote target be updated per INVITE 2xx's Contact? If not, > then why is section 13.2.2.4 pointing to section 12.2.1.2? When I > posted my question, I had thought that it was trying to indicate to > adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. > > Is the following what rfc3261 is attempting to communicate? > > 1) Dialog forming INVITE 1xx/2xx creates route set based upon > record-route and sets remote target per Contact. > > 2) Original INVITE's subsequent 101-199 has no impact upon a known > dialog's route set and remote target. > > 3) Original INVITE's 2xx resets route set per received/missing > record-route and does not set (or update) per Contact. > > 4) Retargeting (excluding original INVITE) request's 2xx within dialog > allow the remote target to be updated. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From pkyzivat@cisco.com Thu Nov 5 15:43:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C6428C128 for ; Thu, 5 Nov 2009 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuFgRPrl2DRy for ; Thu, 5 Nov 2009 15:43:34 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2088D28C0CF for ; Thu, 5 Nov 2009 15:43:34 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA/y8kpAZnwM/2dsb2JhbADJFZd2hD0EhQ0 X-IronPort-AV: E=Sophos;i="4.44,688,1249257600"; d="scan'208";a="66675287" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2009 23:43:56 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA5Nhugn006140; Thu, 5 Nov 2009 23:43:56 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.3959); Thu, 5 Nov 2009 18:43:56 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 18:43:55 -0500 Message-ID: <4AF36339.5080600@cisco.com> Date: Thu, 05 Nov 2009 18:43:53 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeroen van Bemmel References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> In-Reply-To: <4AF35CB9.1000803@zonnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2009 23:43:55.0988 (UTC) FILETIME=[D6B37140:01CA5E71] Cc: Taisto Qvist XX , "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:43:35 -0000 I agree with Jeroen Jeroen van Bemmel wrote: > Brett, > > Even if it's not clearly defined, to me the rule should be simple: > always update the remote target whenever a valid target refresh > request/response (1xx or 2xx) containing a Contact header is received > (with "valid" meaning syntactically correct and in proper dialog > sequence, matching an existing transaction for responses, and no > retransmission) > > It must be assumed that the peer is communicating its most up-to-date > value for its Contact address, I see no reason to ignore such updates > (and I do see how ignoring an updated Contact can cause failures, the > peer may have obtained a new IP address for example, during the time > interval it was ringing - e.g. some handset being picked up from a > docking station with a fixed LAN cable, switching to WiFi) > > Regards, > Jeroen > > Brett Tate wrote: >> Hi Taisto, >> >> I agree that the rfc3261 text is ambiguous and has some conflicting >> statements. >> >> The following thread discusses some of the ambiguities: >> >> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020127.html >> >> >> In my opinion, a strict interpretation of rfc3261 does not allow >> INVITE 1xx/2xx's Contact to update the target during call set-up after >> the dialog has been created. I'm not sure if the authors actually >> intended such a restriction; I not aware of vendors actually enforcing >> such a restriction. >> >> The following is some questions/text from above thread in case someone >> wants to answer the questions. >> >> Should the remote target be updated per INVITE 2xx's Contact? If not, >> then why is section 13.2.2.4 pointing to section 12.2.1.2? When I >> posted my question, I had thought that it was trying to indicate to >> adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. >> >> Is the following what rfc3261 is attempting to communicate? >> >> 1) Dialog forming INVITE 1xx/2xx creates route set based upon >> record-route and sets remote target per Contact. >> >> 2) Original INVITE's subsequent 101-199 has no impact upon a known >> dialog's route set and remote target. >> >> 3) Original INVITE's 2xx resets route set per received/missing >> record-route and does not set (or update) per Contact. >> >> 4) Retargeting (excluding original INVITE) request's 2xx within dialog >> allow the remote target to be updated. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Thu Nov 5 23:01:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1E63A6B50 for ; Thu, 5 Nov 2009 23:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW7yvueulct6 for ; Thu, 5 Nov 2009 23:01:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 260353A6A4A for ; Thu, 5 Nov 2009 23:01:42 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-a2-4af3c9e7eefb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2A.60.24026.7E9C3FA4; Fri, 6 Nov 2009 08:01:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 08:00: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Nov 2009 08:00:44 +0100 Message-ID: In-Reply-To: <4AF35CB9.1000803@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changing contact/remotetarget in targetrefresh response thread-index: Acpebf5XkYj+CPQlQzydeVQ4I2B52gAQJsIQ References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "Brett Tate" X-OriginalArrivalTime: 06 Nov 2009 07:00:45.0883 (UTC) FILETIME=[DD0408B0:01CA5EAE] X-Brightmail-Tracker: AAAAAA== Cc: Taisto Qvist XX , sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remotetarget in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 07:01:44 -0000 Hi,=20 >It must be assumed that the peer is communicating its most=20 >up-to-date value for its Contact address, I see no reason to=20 >ignore such updates (and I do see how ignoring an updated=20 >Contact can cause failures, the peer may have obtained a new=20 >IP address for example, during the time interval it was=20 >ringing - e.g. some handset being picked up from a docking=20 >station with a fixed LAN cable, switching to WiFi) If you get a new IP address, in most cases I doubt sending a new Contact header is the only thing you need to do. You probably need to update the SDP also, and for that we have more strict rules. In addtion, in order to receive incomming calls, the UE will have to register the new IP address. Regards, Christer >=20 > Regards, > Jeroen >=20 > Brett Tate wrote: > > Hi Taisto, > > > > I agree that the rfc3261 text is ambiguous and has some=20 > conflicting statements. > > > > The following thread discusses some of the ambiguities: > > > >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/0 > > 20127.html > > > > In my opinion, a strict interpretation of rfc3261 does not=20 > allow INVITE 1xx/2xx's Contact to update the target during=20 > call set-up after the dialog has been created. I'm not sure=20 > if the authors actually intended such a restriction; I not=20 > aware of vendors actually enforcing such a restriction. > > > > The following is some questions/text from above thread in=20 > case someone wants to answer the questions. > > > > Should the remote target be updated per INVITE 2xx's=20 > Contact? If not,=20 > > then why is section 13.2.2.4 pointing to section 12.2.1.2? When I=20 > > posted my question, I had thought that it was trying to indicate to=20 > > adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. > > > > Is the following what rfc3261 is attempting to communicate? > > > > 1) Dialog forming INVITE 1xx/2xx creates route set based upon=20 > > record-route and sets remote target per Contact. > > > > 2) Original INVITE's subsequent 101-199 has no impact upon a known=20 > > dialog's route set and remote target. > > > > 3) Original INVITE's 2xx resets route set per received/missing=20 > > record-route and does not set (or update) per Contact. > > > > 4) Retargeting (excluding original INVITE) request's 2xx=20 > within dialog=20 > > allow the remote target to be updated. > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From taisto.xx.qvist@ericsson.com Fri Nov 6 02:22:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904313A6954 for ; Fri, 6 Nov 2009 02:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt31FDhN5ENr for ; Fri, 6 Nov 2009 02:22:27 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E0B763A69A6 for ; Fri, 6 Nov 2009 02:22:25 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-d5-4af3f8f73681 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id EE.35.04191.7F8F3FA4; Fri, 6 Nov 2009 11:22:47 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:22:47 +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: Fri, 6 Nov 2009 11:22:46 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changing contact/remotetarget in targetrefrese response Thread-Index: Acpebf5XkYj+CPQlQzydeVQ4I2B52gAQJsIQAAaleHA= References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> From: "Taisto Qvist XX" To: "Christer Holmberg" , "Jeroen van Bemmel" , "Brett Tate" X-OriginalArrivalTime: 06 Nov 2009 10:22:47.0668 (UTC) FILETIME=[1629A340:01CA5ECB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changing contact/remotetarget in targetrefrese response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 10:22:28 -0000 Hi,=20 Thats why I added/imagined a scenario with both sides sending UPDATEs=20 refreshing targets as well as the possibility of sdp-updates. But thats when I started wondering what on earth should be _required_ by the UAS to add as a Contact in the real 2xx to the original, initial INVITE. Since the rfc says that as UAC you must NOT update remote target on 2xx to initial invite, the Contact in 2xx becomes somewhat useless, but it feels like it should be more clearly indicated what it should or must be. On a side note, Im getting the feeling that its a bit fuzzy that when sending an inital invite, I update/store the remote target on the first 1xx, but on target refresh with invite, on dont update until I get 2xx, right?=20 In other words, the Contact in 1xx to a target-refresh is disregarded. It might not cause any problems but it seems like its a possibility for confusion. I'll add the scenario I first described, since its gotten lost in the history. 1) INVITE from A -> B (contact:a1) 2) 18x from B -> A (contact:b1) + prack, early media, go figure... 3) UPDATE from A -> B (contact:a2) 4) 2xx(UPD) from B -> A (contact:b2) // "or uas sending its own UPDATE" 5) 2xx(INV) from B -> A (contact: b2? b1?) 6) ACK-time..remote target is b2... ..and my question was wether the Contact in (5) according to 3261, "MUST" be b1 or b2,=20 since my initial feeling was that it MUST be the same in 1xx and 2xx, for initial=20 INVITE. Regards Taisto Qvist -----Original Message----- From: Christer Holmberg=20 Sent: den 6 november 2009 08:01 To: Jeroen van Bemmel; Brett Tate Cc: Taisto Qvist XX; sipcore@ietf.org Subject: RE: [sipcore] Changing contact/remotetarget in targetrefresh response Hi,=20 >It must be assumed that the peer is communicating its most up-to-date=20 >value for its Contact address, I see no reason to ignore such updates=20 >(and I do see how ignoring an updated Contact can cause failures, the=20 >peer may have obtained a new IP address for example, during the time=20 >interval it was ringing - e.g. some handset being picked up from a=20 >docking station with a fixed LAN cable, switching to WiFi) If you get a new IP address, in most cases I doubt sending a new Contact header is the only thing you need to do. You probably need to update the SDP also, and for that we have more strict rules. In addtion, in order to receive incomming calls, the UE will have to register the new IP address. Regards, Christer >=20 > Regards, > Jeroen >=20 > Brett Tate wrote: > > Hi Taisto, > > > > I agree that the rfc3261 text is ambiguous and has some > conflicting statements. > > > > The following thread discusses some of the ambiguities: > > > >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/0 > > 20127.html > > > > In my opinion, a strict interpretation of rfc3261 does not > allow INVITE 1xx/2xx's Contact to update the target during call set-up > after the dialog has been created. I'm not sure if the authors=20 > actually intended such a restriction; I not aware of vendors actually=20 > enforcing such a restriction. > > > > The following is some questions/text from above thread in > case someone wants to answer the questions. > > > > Should the remote target be updated per INVITE 2xx's > Contact? If not, > > then why is section 13.2.2.4 pointing to section 12.2.1.2? When I=20 > > posted my question, I had thought that it was trying to indicate to=20 > > adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. > > > > Is the following what rfc3261 is attempting to communicate? > > > > 1) Dialog forming INVITE 1xx/2xx creates route set based upon=20 > > record-route and sets remote target per Contact. > > > > 2) Original INVITE's subsequent 101-199 has no impact upon a known=20 > > dialog's route set and remote target. > > > > 3) Original INVITE's 2xx resets route set per received/missing=20 > > record-route and does not set (or update) per Contact. > > > > 4) Retargeting (excluding original INVITE) request's 2xx > within dialog > > allow the remote target to be updated. > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From brett@broadsoft.com Fri Nov 6 03:40:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0363A68C6 for ; Fri, 6 Nov 2009 03:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+b0hTU2ViuM for ; Fri, 6 Nov 2009 03:40:39 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D56D13A683B for ; Fri, 6 Nov 2009 03:40:39 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 6 Nov 2009 03:41:03 -0800 From: Brett Tate To: Paul Kyzivat , Jeroen van Bemmel , Taisto Qvist XX , "sipcore@ietf.org" Date: Fri, 6 Nov 2009 03:40:52 -0800 Thread-Topic: [sipcore] Changing contact/remote target in targetrefresh response Thread-Index: AcpecdgXlzIjdq48R4ioRgxLGtXZfwAYkF9g Message-ID: <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> In-Reply-To: <4AF36339.5080600@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 Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 11:40:43 -0000 I don't disagree with the rule that Jeroen indicated. BroadSoft may soon n= eed our partners to follow such a rule. Unfortunately there is nothing wit= hin rfc3261 which indicates they MUST, SHOULD, or even MAY behave that way. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, November 05, 2009 6:44 PM > To: Jeroen van Bemmel > Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org > Subject: Re: [sipcore] Changing contact/remote target in targetrefresh > response >=20 > I agree with Jeroen >=20 > Jeroen van Bemmel wrote: > > Brett, > > > > Even if it's not clearly defined, to me the rule should be simple: > > always update the remote target whenever a valid target refresh > > request/response (1xx or 2xx) containing a Contact header is received > > (with "valid" meaning syntactically correct and in proper dialog > > sequence, matching an existing transaction for responses, and no > > retransmission) > > > > It must be assumed that the peer is communicating its most up-to-date > > value for its Contact address, I see no reason to ignore such updates > > (and I do see how ignoring an updated Contact can cause failures, the > > peer may have obtained a new IP address for example, during the time > > interval it was ringing - e.g. some handset being picked up from a > > docking station with a fixed LAN cable, switching to WiFi) > > > > Regards, > > Jeroen From taisto.xx.qvist@ericsson.com Fri Nov 6 03:43:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4790B3A68C6 for ; Fri, 6 Nov 2009 03:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+99ej4o2O3F for ; Fri, 6 Nov 2009 03:43:52 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0B9593A6956 for ; Fri, 6 Nov 2009 03:43:51 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-99-4af40c0e3d85 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F6.0B.04191.E0C04FA4; Fri, 6 Nov 2009 12:44:14 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 12:44:14 +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: Fri, 6 Nov 2009 12:44:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is Contact mandatory in 1xx responses to INVITE? Thread-Index: Acpe1nZL/wxPVjujQ6makE4mXpJoOw== From: "Taisto Qvist XX" To: X-OriginalArrivalTime: 06 Nov 2009 11:44:14.0075 (UTC) FILETIME=[76B02CB0:01CA5ED6] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] is Contact mandatory in 1xx responses to INVITE? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 11:43:53 -0000 In a post regarding a different issue, one email response from Jeroen,=20 indicated that he interpreted that the Contact is NOT mandatory in=20 1xx responses for initial INVITE. (but not for re-invite...?) Instead of trying to answer several different questions as once, I'll put this question here, in a separate email. My reading of 3261 says that it IS mandatory to add Contact in 1xx(!100),=20 even though the "MUST" is spread over three different places. First we have: 8.2.6.2 in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present).=20 So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's optional. Secondly: 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. =20 and then finally: 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and 3) that means I MUST add Contact.=20 Is that not a correct interpretation, for INVITE? Regards=20 Taisto Qvist IP-Solutions From brett@broadsoft.com Fri Nov 6 04:25:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554DC3A672E for ; Fri, 6 Nov 2009 04:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nsql+ObyVTeC for ; Fri, 6 Nov 2009 04:25:11 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 9BB553A68D4 for ; Fri, 6 Nov 2009 04:25:11 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 6 Nov 2009 04:25:35 -0800 From: Brett Tate To: Taisto Qvist XX , "sipcore@ietf.org" Date: Fri, 6 Nov 2009 04:25:27 -0800 Thread-Topic: is Contact mandatory in 1xx responses to INVITE? Thread-Index: Acpe1nZL/wxPVjujQ6makE4mXpJoOwAAeZkA Message-ID: <747A6506A991724FB09B129B79D5FEB613FBC3677B@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] is Contact mandatory in 1xx responses to INVITE? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:25:12 -0000 > So this means that 1) I MUST add a to-tag,=20 > 2) This creates a dialog, and > 3) that means I MUST add Contact. >=20 > Is that not a correct interpretation, for INVITE? Yes; it is a correct interpretation. However, there is nothing requiring t= he Contact within subsequent INVITE 1xx's within the dialog. Even though i= t tends to cause interoperability problems, some vendors don't add the Cont= act since rfc3261 doesn't require it. =20 Proxies generating 181 and 199 within another's dialog (i.e. they didn't ge= nerate the To tag) adds to the confusion of the appropriateness to update r= oute set and target within the dialog. If proxy doesn't add a Contact to t= he 1xx, it is malformed (per rfc3261) if the UAC did not see the prior 1xx = which would have created the dialog. From sanjsinh@cisco.com Fri Nov 6 04:30:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7A83A676A for ; Fri, 6 Nov 2009 04:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ1Vc1iCWI3A for ; Fri, 6 Nov 2009 04:30:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EC0523A672E for ; Fri, 6 Nov 2009 04:30:50 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEum80pAZnwM/2dsb2JhbADFKJd9hD0E X-IronPort-AV: E=Sophos;i="4.44,692,1249257600"; d="scan'208";a="66698812" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Nov 2009 12:31:13 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6CVDT0000699; Fri, 6 Nov 2009 12:31:13 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 06:31:13 -0600 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, 6 Nov 2009 06:31:12 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA100874@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] is Contact mandatory in 1xx responses to INVITE? Thread-Index: Acpe1nZL/wxPVjujQ6makE4mXpJoOwABkPuQ References: From: "Sanjay Sinha (sanjsinh)" To: "Taisto Qvist XX" , X-OriginalArrivalTime: 06 Nov 2009 12:31:13.0612 (UTC) FILETIME=[074360C0:01CA5EDD] Subject: Re: [sipcore] is Contact mandatory in 1xx responses to INVITE? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:30:52 -0000 If 1xx is not sent reliably, that is PRACK is not enabled, it is highly recommended to add Contact header to it. If 1xx is sent reliably, then UAS must add a Contact header. Sanjay -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Taisto Qvist XX Sent: Friday, November 06, 2009 5:14 PM To: sipcore@ietf.org Subject: [sipcore] is Contact mandatory in 1xx responses to INVITE? In a post regarding a different issue, one email response from Jeroen,=20 indicated that he interpreted that the Contact is NOT mandatory in=20 1xx responses for initial INVITE. (but not for re-invite...?) Instead of trying to answer several different questions as once, I'll put this question here, in a separate email. My reading of 3261 says that it IS mandatory to add Contact in 1xx(!100),=20 even though the "MUST" is spread over three different places. First we have: 8.2.6.2 in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present).=20 So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's optional. Secondly: 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. =20 and then finally: 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and 3) that means I MUST add Contact.=20 Is that not a correct interpretation, for INVITE? Regards=20 Taisto Qvist IP-Solutions _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Fri Nov 6 04:50:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335773A6983 for ; Fri, 6 Nov 2009 04:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwrgMk16DxTU for ; Fri, 6 Nov 2009 04:50:01 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E313B3A6826 for ; Fri, 6 Nov 2009 04:50:00 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b3-4af41b8ea472 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 53.61.24026.E8B14FA4; Fri, 6 Nov 2009 13:50:22 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:48:44 +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: Fri, 6 Nov 2009 13:48:42 +0100 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changingcontact/remote target in target refresh response thread-index: AcpecdgXlzIjdq48R4ioRgxLGtXZfwAYkF9gAALHyuA= References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Paul Kyzivat" , "Jeroen van Bemmel" , "Taisto Qvist XX" , X-OriginalArrivalTime: 06 Nov 2009 12:48:44.0086 (UTC) FILETIME=[7964FD60:01CA5EDF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:50:02 -0000 Hi, Unfortunately this is not the first time we are having this discussion. I am not sure what (if any) the outcome has been in previous discussion, but it may be worthwile taking a look in the archieves. Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: 6. marraskuuta 2009 13:41 > To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; sipcore@ietf.org > Subject: Re: [sipcore] Changingcontact/remote target in=20 > targetrefresh response >=20 > I don't disagree with the rule that Jeroen indicated. =20 > BroadSoft may soon need our partners to follow such a rule. =20 > Unfortunately there is nothing within rfc3261 which indicates=20 > they MUST, SHOULD, or even MAY behave that way. >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, November 05, 2009 6:44 PM > > To: Jeroen van Bemmel > > Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org > > Subject: Re: [sipcore] Changing contact/remote target in=20 > targetrefresh=20 > > response > >=20 > > I agree with Jeroen > >=20 > > Jeroen van Bemmel wrote: > > > Brett, > > > > > > Even if it's not clearly defined, to me the rule should be simple: > > > always update the remote target whenever a valid target refresh=20 > > > request/response (1xx or 2xx) containing a Contact header is=20 > > > received (with "valid" meaning syntactically correct and=20 > in proper=20 > > > dialog sequence, matching an existing transaction for=20 > responses, and=20 > > > no > > > retransmission) > > > > > > It must be assumed that the peer is communicating its most=20 > > > up-to-date value for its Contact address, I see no reason=20 > to ignore=20 > > > such updates (and I do see how ignoring an updated=20 > Contact can cause=20 > > > failures, the peer may have obtained a new IP address for=20 > example,=20 > > > during the time interval it was ringing - e.g. some handset being=20 > > > picked up from a docking station with a fixed LAN cable,=20 > switching=20 > > > to WiFi) > > > > > > Regards, > > > Jeroen >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Fri Nov 6 04:53:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E5E3A6A85 for ; Fri, 6 Nov 2009 04:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWd7hP94GQhD for ; Fri, 6 Nov 2009 04:53:49 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1E99A3A6983 for ; Fri, 6 Nov 2009 04:53:48 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-41-4af41c73996c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FB.D5.31706.37C14FA4; Fri, 6 Nov 2009 13:54:11 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:54:11 +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: Fri, 6 Nov 2009 13:54:09 +0100 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FBC3677B@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] is Contact mandatory in 1xx responses to INVITE? thread-index: Acpe1nZL/wxPVjujQ6makE4mXpJoOwAAeZkAAAHm1iA= References: <747A6506A991724FB09B129B79D5FEB613FBC3677B@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Taisto Qvist XX" , X-OriginalArrivalTime: 06 Nov 2009 12:54:11.0161 (UTC) FILETIME=[3C58AC90:01CA5EE0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] is Contact mandatory in 1xx responses to INVITE? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:53:50 -0000 =20 >>So this means that 1) I MUST add a to-tag, >>2) This creates a dialog, and >>3) that means I MUST add Contact. >>=20 >>Is that not a correct interpretation, for INVITE? > >Yes; it is a correct interpretation. However, there is=20 >nothing requiring the Contact within subsequent INVITE 1xx's=20 >within the dialog. Even though it tends to cause=20 >interoperability problems, some vendors don't add the Contact=20 >since rfc3261 doesn't require it. =20 The world would be a much better place if implementors asked themsleves: "Ok, now, if I do NOT receive this header in this resposne, does something actually go wrong?". Remember the SIP rule: "Be prepared to receive any crap, but try not to send so much crap." Regards, Christer From brett@broadsoft.com Fri Nov 6 05:09:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06B9C3A6A7C for ; Fri, 6 Nov 2009 05:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbDAJhalDPbM for ; Fri, 6 Nov 2009 05:09:10 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 2B0CD3A698F for ; Fri, 6 Nov 2009 05:09:10 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 6 Nov 2009 05:09:33 -0800 From: Brett Tate To: Christer Holmberg , "sipcore@ietf.org" Date: Fri, 6 Nov 2009 05:09:26 -0800 Thread-Topic: [sipcore] Changingcontact/remote target in target refresh response Thread-Index: AcpecdgXlzIjdq48R4ioRgxLGtXZfwAYkF9gAALHyuAAAG5G4A== Message-ID: <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> 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 Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 13:09:11 -0000 Hi Christer, Yes; there have been discussions. Unfortunately non have actually led to a= n update to rfc3261. As you know, there are some drafts concerning updates/rollbacks related to = re-INVITE and UPDATE failure. However I don't recall if there are any non = expired drafts actually discussing the topic within this thread. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, November 06, 2009 7:49 AM > To: Brett Tate; Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; > sipcore@ietf.org > Subject: RE: [sipcore] Changingcontact/remote target in target refresh > response >=20 >=20 > Hi, >=20 > Unfortunately this is not the first time we are having this discussion. > I am not sure what (if any) the outcome has been in previous > discussion, > but it may be worthwile taking a look in the archieves. >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > > Sent: 6. marraskuuta 2009 13:41 > > To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; > sipcore@ietf.org > > Subject: Re: [sipcore] Changingcontact/remote target in > > targetrefresh response > > > > I don't disagree with the rule that Jeroen indicated. > > BroadSoft may soon need our partners to follow such a rule. > > Unfortunately there is nothing within rfc3261 which indicates > > they MUST, SHOULD, or even MAY behave that way. > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Thursday, November 05, 2009 6:44 PM > > > To: Jeroen van Bemmel > > > Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org > > > Subject: Re: [sipcore] Changing contact/remote target in > > targetrefresh > > > response > > > > > > I agree with Jeroen > > > > > > Jeroen van Bemmel wrote: > > > > Brett, > > > > > > > > Even if it's not clearly defined, to me the rule should be > simple: > > > > always update the remote target whenever a valid target refresh > > > > request/response (1xx or 2xx) containing a Contact header is > > > > received (with "valid" meaning syntactically correct and > > in proper > > > > dialog sequence, matching an existing transaction for > > responses, and > > > > no > > > > retransmission) > > > > > > > > It must be assumed that the peer is communicating its most > > > > up-to-date value for its Contact address, I see no reason > > to ignore > > > > such updates (and I do see how ignoring an updated > > Contact can cause > > > > failures, the peer may have obtained a new IP address for > > example, > > > > during the time interval it was ringing - e.g. some handset being > > > > picked up from a docking station with a fixed LAN cable, > > switching > > > > to WiFi) > > > > > > > > Regards, > > > > Jeroen > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Fri Nov 6 05:14:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE32E3A6A87 for ; Fri, 6 Nov 2009 05:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvElFzZV6gr7 for ; Fri, 6 Nov 2009 05:14:56 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0BC183A6843 for ; Fri, 6 Nov 2009 05:14:22 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-a4-4af421418429 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 70.42.04191.14124FA4; Fri, 6 Nov 2009 14:14:41 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 14:14: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 Date: Fri, 6 Nov 2009 14:14:35 +0100 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changingcontact/remote target in target refresh response thread-index: AcpecdgXlzIjdq48R4ioRgxLGtXZfwAYkF9gAALHyuAAAG5G4AAAe8kA References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , X-OriginalArrivalTime: 06 Nov 2009 13:14:36.0586 (UTC) FILETIME=[16C1B0A0:01CA5EE3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 13:14:57 -0000 Hi, >Yes; there have been discussions. Unfortunately non have=20 >actually led to an update to rfc3261. > >=20 >As you know, there are some drafts concerning=20 >updates/rollbacks related to re-INVITE and UPDATE failure. =20 >However I don't recall if there are any non expired drafts=20 >actually discussing the topic within this thread. No, I don't think so. The drafts are more related to what happens to confirmed changes (e.g. in a 18x response) if a re-INVITE fails. Regards, Christer >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, November 06, 2009 7:49 AM > > To: Brett Tate; Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] Changingcontact/remote target in=20 > target refresh=20 > > response > >=20 > >=20 > > Hi, > >=20 > > Unfortunately this is not the first time we are having this=20 > discussion. > > I am not sure what (if any) the outcome has been in previous=20 > > discussion, but it may be worthwile taking a look in the archieves. > >=20 > > Regards, > >=20 > > Christer > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > > > Sent: 6. marraskuuta 2009 13:41 > > > To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; > > sipcore@ietf.org > > > Subject: Re: [sipcore] Changingcontact/remote target in=20 > > > targetrefresh response > > > > > > I don't disagree with the rule that Jeroen indicated. > > > BroadSoft may soon need our partners to follow such a rule. > > > Unfortunately there is nothing within rfc3261 which=20 > indicates they=20 > > > MUST, SHOULD, or even MAY behave that way. > > > > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Thursday, November 05, 2009 6:44 PM > > > > To: Jeroen van Bemmel > > > > Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org > > > > Subject: Re: [sipcore] Changing contact/remote target in > > > targetrefresh > > > > response > > > > > > > > I agree with Jeroen > > > > > > > > Jeroen van Bemmel wrote: > > > > > Brett, > > > > > > > > > > Even if it's not clearly defined, to me the rule should be > > simple: > > > > > always update the remote target whenever a valid=20 > target refresh=20 > > > > > request/response (1xx or 2xx) containing a Contact header is=20 > > > > > received (with "valid" meaning syntactically correct and > > > in proper > > > > > dialog sequence, matching an existing transaction for > > > responses, and > > > > > no > > > > > retransmission) > > > > > > > > > > It must be assumed that the peer is communicating its most=20 > > > > > up-to-date value for its Contact address, I see no reason > > > to ignore > > > > > such updates (and I do see how ignoring an updated > > > Contact can cause > > > > > failures, the peer may have obtained a new IP address for > > > example, > > > > > during the time interval it was ringing - e.g. some handset=20 > > > > > being picked up from a docking station with a fixed LAN cable, > > > switching > > > > > to WiFi) > > > > > > > > > > Regards, > > > > > Jeroen > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 From adam@nostrum.com Fri Nov 6 06:14:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283913A6825 for ; Fri, 6 Nov 2009 06:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZpmJSlUgeEy for ; Fri, 6 Nov 2009 06:14:51 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D3BF33A6A3E for ; Fri, 6 Nov 2009 06:14:50 -0800 (PST) Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EF7W0091021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 08:15:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF34588.9010408@nostrum.com> Date: Fri, 06 Nov 2009 06:37:12 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060904000802090209000507" Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:14:52 -0000 This is a multi-part message in MIME format. --------------060904000802090209000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/29/09 6:48 AM, Christer Holmberg wrote: > > Hi, > > Another issue which came to my mind when going through Keith's comment. > > Currently we say that Info Package parameters can only be used with > the package for which it was defined. > > But, what if another Info Package needs a parameter with exactly the > same semantics? Even if that other Info Package would use the same > parameter name, it would still have to re-define the parameter. > This has never been a problem for 3265, which already has a fair number of event packages defined. Note that there are other, non-package-specific parameters (cf event-rate-contol) as well. If parameters have applicability beyond an event package, they probably shouldn't be defined as part of that package -- they should probably defined in a new document that isn't specific to any info package. /a --------------060904000802090209000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/29/09 6:48 AM, Christer Holmberg wrote:
Info-Event Open Issue: Header field parameter re-use

Hi,

Another issue which came to my mind when going through Keith's comment.

Currently we say that Info Package parameters can only be used with the package for which it was defined.

But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the parameter.


This has never been a problem for 3265, which already has a fair number of event packages defined. Note that there are other, non-package-specific parameters (cf event-rate-contol) as well. If parameters have applicability beyond an event package, they probably shouldn't be defined as part of that package -- they should probably defined in a new document that isn't specific to any info package.

/a
--------------060904000802090209000507-- From adam@nostrum.com Fri Nov 6 06:15:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065A23A6A99 for ; Fri, 6 Nov 2009 06:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joiuMBAilqWC for ; Fri, 6 Nov 2009 06:15:06 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 003B33A69FD for ; Fri, 6 Nov 2009 06:15:05 -0800 (PST) Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EFBK0091025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 08:15:23 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF3471B.9060409@nostrum.com> Date: Fri, 06 Nov 2009 06:43:55 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" References: <4AE8B942.1090506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:15:07 -0000 [as an individual] On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote: > If the INFO transaction fails, then let the application decide whether > it wants to continue with the dialog or not? > That's functionally equivalent to asking "why don't we leave it to the application to decide whether a BYE terminates an invite usage?" When an error occurs, both sides need to know the resulting state. If you sent me a 469, and your application decided that this terminated the dialog but mine decided it only terminated the transaction, the result would be unexpected and decidedly unfortunate behavior. That's why we bothered to publish RFC 5057 at all. /a From pkyzivat@cisco.com Fri Nov 6 06:24:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532563A69FD for ; Fri, 6 Nov 2009 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaVBp7hqRVzQ for ; Fri, 6 Nov 2009 06:24:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2BACA3A6A3E for ; Fri, 6 Nov 2009 06:24:30 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIvA80qrR7H+/2dsb2JhbADGApd9hD0E X-IronPort-AV: E=Sophos;i="4.44,693,1249257600"; d="scan'208";a="426394193" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2009 14:24:53 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA6EOrdS020058; Fri, 6 Nov 2009 14:24:53 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.3959); Fri, 6 Nov 2009 09:24:53 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 09:24:52 -0500 Message-ID: <4AF431B4.6020201@cisco.com> Date: Fri, 06 Nov 2009 09:24:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4AE8B942.1090506@cisco.com> <4AF3471B.9060409@nostrum.com> In-Reply-To: <4AF3471B.9060409@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2009 14:24:52.0718 (UTC) FILETIME=[E7C460E0:01CA5EEC] Cc: "Sanjay Sinha \(sanjsinh\)" , SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:24:48 -0000 Adam, I think Sanjay was responding to an earlier comment by me. I had said that INFO failures should only affect the transaction, and that if such an error was more profound to the application then the application has the option of taking down the session (using BYE). So I think we are all in agreement. Thanks, Paul Adam Roach wrote: > [as an individual] > > On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote: >> If the INFO transaction fails, then let the application decide whether >> it wants to continue with the dialog or not? >> > > That's functionally equivalent to asking "why don't we leave it to the > application to decide whether a BYE terminates an invite usage?" > > When an error occurs, both sides need to know the resulting state. If > you sent me a 469, and your application decided that this terminated the > dialog but mine decided it only terminated the transaction, the result > would be unexpected and decidedly unfortunate behavior. > > That's why we bothered to publish RFC 5057 at all. > > /a > From christer.holmberg@ericsson.com Fri Nov 6 06:34:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5293A69AF for ; Fri, 6 Nov 2009 06:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fpiZrLfwKv5 for ; Fri, 6 Nov 2009 06:34:01 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9B1BB28C174 for ; Fri, 6 Nov 2009 06:34:01 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-1d-4af433ef57f6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 83.58.04191.FE334FA4; Fri, 6 Nov 2009 15:34:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 15:33:53 +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: Fri, 6 Nov 2009 15:33:52 +0100 Message-ID: In-Reply-To: <4AF34588.9010408@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Header field parameter re-use thread-index: Acpe65AAgBx2SNfYRxigoVMEwqw7RwAAlv6Q References: <4AF34588.9010408@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 06 Nov 2009 14:33:53.0522 (UTC) FILETIME=[2A1C8520:01CA5EEE] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:34:02 -0000 Hi, >>Another issue which came to my mind when going through Keith's comment.=20 >> >>Currently we say that Info Package parameters can only be used with the package for which it was defined.=20 >> >>But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the=20 >>parameter. > >This has never been a problem for 3265, which already has a fair number of event packages defined. Note that there are other, non-package-specific parameters (cf event-rate-contol) as well. If=20 >parameters have applicability beyond an event package, they probably shouldn't be defined as part of that package -- they should probably defined in a new document that isn't specific to any=20 >info package. Good point. So, I will modify the text, so that it not only talks about parameter defined in other Info Package specifications. Anyone objects? Regards, Christer =09 From christer.holmberg@ericsson.com Fri Nov 6 06:35:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42293A6403 for ; Fri, 6 Nov 2009 06:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6yTwIp3WgCr for ; Fri, 6 Nov 2009 06:35:44 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 19B623A6AA4 for ; Fri, 6 Nov 2009 06:35:43 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-e3-4af434553a64 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 02.BA.24026.55434FA4; Fri, 6 Nov 2009 15:36:06 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 15:35:48 +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: Fri, 6 Nov 2009 15:35:46 +0100 Message-ID: In-Reply-To: <4AF3471B.9060409@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: Acpe65kZxHju2o1jTbW3Gh4C4lBnlAAAqkVA References: <4AE8B942.1090506@cisco.com> <4AF3471B.9060409@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Sanjay Sinha (sanjsinh)" X-OriginalArrivalTime: 06 Nov 2009 14:35:48.0258 (UTC) FILETIME=[6E7FD820:01CA5EEE] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:35:48 -0000 Hi, I agree with Adam, and based on feeback I got from Robert, a 469 should NEVER terminate the dialog usage, and individual Info Packages shall not change that. Anyone objects to that? Regards, Christer =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 5. marraskuuta 2009 23:44 > To: Sanjay Sinha (sanjsinh) > Cc: Paul Kyzivat (pkyzivat); Christer Holmberg; SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > [as an individual] >=20 > On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote: > > If the INFO transaction fails, then let the application=20 > decide whether=20 > > it wants to continue with the dialog or not? > > =20 >=20 > That's functionally equivalent to asking "why don't we leave=20 > it to the application to decide whether a BYE terminates an=20 > invite usage?" >=20 > When an error occurs, both sides need to know the resulting=20 > state. If you sent me a 469, and your application decided=20 > that this terminated the dialog but mine decided it only=20 > terminated the transaction, the result would be unexpected=20 > and decidedly unfortunate behavior. >=20 > That's why we bothered to publish RFC 5057 at all. >=20 > /a >=20 From christer.holmberg@ericsson.com Fri Nov 6 06:39:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290E13A69AE for ; Fri, 6 Nov 2009 06:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8RyY520LxAk for ; Fri, 6 Nov 2009 06:39:46 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2DD6B3A6825 for ; Fri, 6 Nov 2009 06:39:28 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-50-4af43535e067 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 60.3B.24026.53534FA4; Fri, 6 Nov 2009 15:39:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 15:38:42 +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: Fri, 6 Nov 2009 15:38:40 +0100 Message-ID: In-Reply-To: <4AF431B4.6020201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: Acpe7OzreTu2TQunQCKmHJCzXSCq4wAAdUyA References: <4AE8B942.1090506@cisco.com> <4AF3471B.9060409@nostrum.com> <4AF431B4.6020201@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 06 Nov 2009 14:38:42.0056 (UTC) FILETIME=[D6175080:01CA5EEE] X-Brightmail-Tracker: AAAAAA== Cc: "Sanjay Sinha \(sanjsinh\)" , SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:39:47 -0000 Hi,=20 >I think Sanjay was responding to an earlier comment by me. >=20 >I had said that INFO failures should only affect the=20 >transaction, and that if such an error was more profound to=20 >the application then the application has the option of taking=20 >down the session (using BYE). >=20 >So I think we are all in agreement. Bueno. That is also what the pre-03 version says. Regards, Christer From pkyzivat@cisco.com Fri Nov 6 08:03:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E5D3A6972 for ; Fri, 6 Nov 2009 08:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0XHBG3Yh7RN for ; Fri, 6 Nov 2009 08:03:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 96BC73A686D for ; Fri, 6 Nov 2009 08:03:54 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL7X80pAZnwM/2dsb2JhbADFUZgCgmkBgVMEhRM X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="66777400" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Nov 2009 16:04:17 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6G4HCR006206; Fri, 6 Nov 2009 16:04: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.3959); Fri, 6 Nov 2009 11:04:17 -0500 Received: from [161.44.182.250] ([161.44.182.250]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 11:04:17 -0500 Message-ID: <4AF44901.5050909@cisco.com> Date: Fri, 06 Nov 2009 11:04:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2009 16:04:17.0264 (UTC) FILETIME=[CAE9DF00:01CA5EFA] Cc: Taisto Qvist XX , sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] Changing contact/remotetarget in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:03:55 -0000 Christer Holmberg wrote: > Hi, > >> It must be assumed that the peer is communicating its most >> up-to-date value for its Contact address, I see no reason to >> ignore such updates (and I do see how ignoring an updated >> Contact can cause failures, the peer may have obtained a new >> IP address for example, during the time interval it was >> ringing - e.g. some handset being picked up from a docking >> station with a fixed LAN cable, switching to WiFi) > > If you get a new IP address, in most cases I doubt sending a new Contact > header is the only thing you need to do. You probably need to update the > SDP also, and for that we have more strict rules. > > In addtion, in order to receive incomming calls, the UE will have to > register the new IP address. > > Regards, > > Christer While what you say is true, it doesn't mean Jeroen is wrong. In this situation, if you want to preserve the call, then the first thing you must do is change your contact address. Once that is done, you can deal with the other things. Maybe you will lose your media for a bit, until you can legally do an o/a to fix it, but at least you will still have your call. And of course you can also then reregister. Thanks, Paul >> Regards, >> Jeroen >> >> Brett Tate wrote: >>> Hi Taisto, >>> >>> I agree that the rfc3261 text is ambiguous and has some >> conflicting statements. >>> The following thread discusses some of the ambiguities: >>> >>> >> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/0 >>> 20127.html >>> >>> In my opinion, a strict interpretation of rfc3261 does not >> allow INVITE 1xx/2xx's Contact to update the target during >> call set-up after the dialog has been created. I'm not sure >> if the authors actually intended such a restriction; I not >> aware of vendors actually enforcing such a restriction. >>> The following is some questions/text from above thread in >> case someone wants to answer the questions. >>> Should the remote target be updated per INVITE 2xx's >> Contact? If not, >>> then why is section 13.2.2.4 pointing to section 12.2.1.2? When I >>> posted my question, I had thought that it was trying to indicate to >>> adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. >>> >>> Is the following what rfc3261 is attempting to communicate? >>> >>> 1) Dialog forming INVITE 1xx/2xx creates route set based upon >>> record-route and sets remote target per Contact. >>> >>> 2) Original INVITE's subsequent 101-199 has no impact upon a known >>> dialog's route set and remote target. >>> >>> 3) Original INVITE's 2xx resets route set per received/missing >>> record-route and does not set (or update) per Contact. >>> >>> 4) Retargeting (excluding original INVITE) request's 2xx >> within dialog >>> allow the remote target to be updated. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Nov 6 12:56:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B153A6823 for ; Fri, 6 Nov 2009 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8GV-AEJ6Azl for ; Fri, 6 Nov 2009 12:56:56 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 63C7D28C1BE for ; Fri, 6 Nov 2009 12:56:55 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-02-4af48dadd02d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 65.96.24026.DAD84FA4; Fri, 6 Nov 2009 21:57:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 21:56: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Nov 2009 21:56:44 +0100 Message-ID: In-Reply-To: <4AF44901.5050909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changing contact/remotetarget in targetrefresh response thread-index: Acpe+s84Z/ECpRs9Ry+8PAaRwsvOXgAJxZTQ References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF44901.5050909@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 06 Nov 2009 20:56:45.0197 (UTC) FILETIME=[A64BF3D0:01CA5F23] X-Brightmail-Tracker: AAAAAA== Cc: Taisto Qvist XX , sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] Changing contact/remotetarget in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:56:57 -0000 Hi,=20 >>>It must be assumed that the peer is communicating its most up-to-date >>>value for its Contact address, I see no reason to ignore such updates >>>(and I do see how ignoring an updated Contact can cause failures, the >>>peer may have obtained a new IP address for example, during the time=20 >>>interval it was ringing - e.g. some handset being picked up from a=20 >>>docking station with a fixed LAN cable, switching to WiFi) >>=20 >>If you get a new IP address, in most cases I doubt sending a new=20 >>Contact header is the only thing you need to do. You probably need to=20 >>update the SDP also, and for that we have more strict rules. >>=20 >>In addtion, in order to receive incomming calls, the UE will have to=20 >>register the new IP address. > >While what you say is true, it doesn't mean Jeroen is wrong. I didn't say he was :) >In this situation, if you want to preserve the call, then the first thing you must do is change your contact address. > >Once that is done, you can deal with the other things. Maybe you will lose your media for a bit, until you can legally do=20 >an o/a to fix it, but at least you will still have your call. And of course you can also then reregister. Sure. But, keep in mind that afaik a new Contact will not have impact on posible re-transmissions, based on the old contact, that the UA may have ongoing, so things can go wrong there also. And you will most likely have issues with NAT traversal. But, you may of course have the same issues if you send an UPDATE with the new Contact. Regards, Christer=20 >> Regards, >> Jeroen >> >> Brett Tate wrote: >>> Hi Taisto, >>> >>> I agree that the rfc3261 text is ambiguous and has some >> conflicting statements. >>> The following thread discusses some of the ambiguities: >>> >>> >> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/ >> 0 >>> 20127.html >>> >>> In my opinion, a strict interpretation of rfc3261 does not >> allow INVITE 1xx/2xx's Contact to update the target during call=20 >> set-up after the dialog has been created. I'm not sure if the=20 >> authors actually intended such a restriction; I not aware of vendors=20 >> actually enforcing such a restriction. >>> The following is some questions/text from above thread in >> case someone wants to answer the questions. >>> Should the remote target be updated per INVITE 2xx's >> Contact? If not, >>> then why is section 13.2.2.4 pointing to section 12.2.1.2? When I=20 >>> posted my question, I had thought that it was trying to indicate to=20 >>> adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. >>> >>> Is the following what rfc3261 is attempting to communicate? >>> >>> 1) Dialog forming INVITE 1xx/2xx creates route set based upon=20 >>> record-route and sets remote target per Contact. >>> >>> 2) Original INVITE's subsequent 101-199 has no impact upon a known=20 >>> dialog's route set and remote target. >>> >>> 3) Original INVITE's 2xx resets route set per received/missing=20 >>> record-route and does not set (or update) per Contact. >>> >>> 4) Retargeting (excluding original INVITE) request's 2xx >> within dialog >>> allow the remote target to be updated. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From krisztian.kiss@nokia.com Sat Nov 7 04:28:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0153A68AD for ; Sat, 7 Nov 2009 04:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACokjyAawlmZ for ; Sat, 7 Nov 2009 04:28:27 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BBE203A67E9 for ; Sat, 7 Nov 2009 04:28:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA7CSlTf002357; Sat, 7 Nov 2009 14:28:48 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 14:28:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 14:28:42 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Sat, 7 Nov 2009 13:28:41 +0100 From: To: Date: Sat, 7 Nov 2009 13:28:41 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-event-rate-control-01 Thread-Index: AcpaGBbkfpolGnFiSZeNHLt0hZxM2wCMHSng Message-ID: References: <4AEC16A5.6050809@zonnet.nl> In-Reply-To: <4AEC16A5.6050809@zonnet.nl> 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-OriginalArrivalTime: 07 Nov 2009 12:28:42.0306 (UTC) FILETIME=[D77DAA20:01CA5FA5] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-event-rate-control-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 12:28:28 -0000 Hi Jeroen, IMHO "controlling" publications is an interesting but distinct problem from= the mechanisms presented in draft-ietf-sipcore-event-rate-control-01, it's= mostly useful to control the volume of unnecessary publications taking int= o account the needs of the subscribers/watchers sitting on the other side o= f the notifier. Are you suggesting to extend the winfo package with rate co= ntrol information in order to control the rate of publications?=20 Cheers, Krisztian -----Original Message----- From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Saturday, October 31, 2009 03:51 To: Kiss Krisztian (Nokia-CIC/MtView) Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-event-rate-control-01 Krisztian, As input for discussion: - some years ago we submitted a similar draft, but focused on rate control = for publications:=20 http://tools.ietf.org/html/draft-brok-simple-regulate-publish-02 - did you consider passing on the rate control information in watcher info?= (i.e. extend the winfo package of RFC3857) Regards, Jeroen krisztian.kiss@nokia.com wrote: > All, > > An updated version of the event-rate-control draft was recently=20 > submitted (after the IETF76 deadline). Until it appears in the I-D=20 > repository, you can fetch a copy from=20 > http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt > > The changes include: > - All rate control parameters can now be updated in 200-class responses t= o a NOTIFY request (in addition to setting the parameters in the SUBSCRIBE = request). See related discussion in GEOPRIV: http://www.ietf.org/mail-archi= ve/web/geopriv/current/msg07766.html. This change also requires mandating t= he Event header field in 200-class responses to a NOTIFY request. > - Emphasized that rate control parameters can be changed at any time by t= he notifier based on local policy or implementation-determined constraints. > - In minimum rate mechanism, the NOTIFY request may contain partial or fu= ll state depending on what the event package specifies. Previously, a NOTIF= Y with full state was always pushed to the subscriber when the max-interval= indicated, even if nothing has changed from the previous NOTIFY. > - other minor wordsmithing changes. > > Cheers, > Krisztian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From shida@ntt-at.com Sat Nov 7 05:00:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3015F3A6839 for ; Sat, 7 Nov 2009 05:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLpsCJj-MK0b for ; Sat, 7 Nov 2009 05:00:02 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.81.23]) by core3.amsl.com (Postfix) with SMTP id CCED03A6835 for ; Sat, 7 Nov 2009 04:59:57 -0800 (PST) Received: (qmail 6102 invoked from network); 7 Nov 2009 13:12:39 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 7 Nov 2009 13:12:39 -0000 Received: from d242111.ppp.asahi-net.or.jp ([210.253.242.111]:53263 helo=[172.17.2.12]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1N6ktu-0006gx-Jz; Sat, 07 Nov 2009 07:00:19 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> Date: Sat, 7 Nov 2009 22:00:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <14085347-6A13-43EC-B0D2-0B25554EAFEC@ntt-at.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> To: "Elwell, John" X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , Ian Elz , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 13:00:03 -0000 John; My comments inline... >> >> >> - Example 2: Call from A to freephone number B, which resolves to C, >> which is then forwarded to D, which resolves to contact E. >> >> H-I: B; index=3D1 >> H-I: C; index=3D1.1; >> H-I: D; index=3D1.1.1; > [JRE] I think this should have an mp tag, because the entity doing =20 > the forwarding would normally apply the mp tag when forwarding. The =20= > fact that earlier the request had been targeted at a freephone =20 > number is unlikely to influence forwarding behaviour (and indeed =20 > might not be known to the entity doing the forwarding), so the mp =20 > tag would be added. > > John If C and D represents a different user I would agree with you but if it represents for example two different office location from the same company which have freephone number B as their alias, I think it really represents the same user so 'mp' tag shouldn't be added. Regards Shida > >> H-I: E; index=3D1.1.1.1;rc >> >> Here if C and D are both expecting a call via >> toll-free number(b), say office in Dallas and >> office in NY representing the same company, >> then they are both the same user toll-free is >> trying to contact, so there is no 'mp' tag and E >> looks at the first H-I entry. >> >> To identify whether the call came in via the service number, >> one would look for the last 'mp' tagged entry OR if there is >> none look at the first 'hi-entry'. >> >> Any comments? >> >> Regards >> Shida >> >> On Oct 26, 2009, at 7:36 PM, Ian Elz wrote: >> >>> All, >>> >>> Paul is correct in the name to name translation. >>> >>> As well as the basic translation that Paul identified it is also >>> common to translate from one 'freephone type' number to another. >>> This occurs where a call answering service has multiple answering >>> locations and the specific answering location is determined based >>> upon identity of the caller, date/day/time etc. >>> >>> When the call answering service is required to handle calls from >>> multiple different 'freephone' numbers then it is often easier to >>> have one number which defines the answering location and another >>> which is the 'dialed' number which translates to the number, or >>> numbers, which define the call handling. In effect a hierarchy can >>> be using these numbers which translate to each other. >>> >>> I use the term 'freephone type' as freephone relates to one >> charging >>> scenario where there are other charging scenarios defined in >>> different regulatory regimes, local call rate, national call rate >>> and a plethora of different premium rates. All of these are >>> logically handled in a similar fashion. >>> >>> The ISUP PSTN network allows the provision 2 different numbers to >>> the called party, original called party number and redirecting >>> number. The redirecting number is the last identity which >> performed >>> a diversion of redirection. The original called party >> number is the >>> number dialed by the caller ( as modified by the network to >> make is >>> a standard format, e.g. national or international number). >>> >>> For H-I we need to be able to replicate at least the ability to >>> identify the original number/identity called and the last identity >>> which diverted/redirected the call. >>> >>> The intermediate information which is not available in ISUP >> is also >>> useful, particularly when some data is incorrect, as it allow >>> tracing of how a call was handled. >>> >>> Ian Elz >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 20 October 2009 00:33 >>> To: Elwell, John >>> Cc: Jonathan Lennox; Fran=E7ois AUDET; sipcore@ietf.org; Hadriel >>> Kaplan; Dean Willis; ELWELL John; Keith Drage >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>> >>> >>> >>> Elwell, John wrote: >>>> But in actual fact, any E.164 number is a name, so the tag would >>>> apply to any E.164 to SIP URI translation. Is this helpful? >>> >>> Yes, any E.164 number is a name, even if it is embedded in >> a SIP uri >>> containing a domain name. (Its quite likely the domain name >> doesn't >>> reflect the "owner" of the E.164 number, just a convenient server >>> that will hopefully figure out what to do next based on the number.) >>> >>> Of course, once upon a time phone numbers *were* addresses, >> and were >>> routed digit by digit. But that time is over. Similarly, >> the domain >>> names in SIP URIs are *name*s, not addresses. And the IP addresses >>> are actually names too, ... What's a name and what's an >> address is a >>> matter of perspective and layering. >>> >>> So, to go this will will require careful definition of the >>> distinction in this context. >>> >>> Also, Shida said: >>> >>>> In deployment, name to name translation never happens >>> >>> That's not really true is it? IIUC, its pretty normal for a "name" >>> like >>> 1-800-666-1111 to be translated to another name,like >> 1-212-555-1234, >>> which then must be routed to a responsible server. >>> >>> Thanks, >>> Paul >>> >>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET >>>>> Sent: 18 October 2009 15:37 >>>>> To: Shida Schubert >>>>> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; >>>>> ELWELL John; Keith Drage >>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>>>> >>>>> This is quite an interesting idea. Probably wider in scope than >>>>> History-Info, but it sounds like a good way to tackle the problem. >>>>> >>>>> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: >>>>> >>>>>> The reason why current use of "mp" tag is not >> semantically correct >>>>>> for freephone, is because Service-URN and free-phone is >> a "name" >>>>>> and >>>>>> not an "address" based on the definition in the target-uri draft. >>>>>> >>>>>> I believe we need to define another tag for "name" to "address" >>>>>> translation. >>>>>> >>>>>> ## Definition of address/name in the target-uri draft ## >>>>>> >>>>>> A name is a moniker for an entity which refers to it in a >>>>> way which >>>>>> reveals nothing about where it is in a network. In SIP, tel URI >>>>>> which doesn't represent the location of the entity is a name. >>>>>> >>>>>> An address is an identifier for an entity which describes >>>>> it by its >>>>>> location on the network. In SIP, the SIP URI itself is >> a form of >>>>>> address because the host part of the URI, the only >>>>> mandatory part of >>>>>> the URI besides the scheme itself, indicates the >> location of a SIP >>>>>> server that can be used to handle the request. >>>>>> >>>>>> ## -- ## >>>>>> >>>>>> In deployment, name to name translation never happens >> and generally >>>>>> "name" to "address" translation is very deterministic that entity >>>>>> doing the mapping/translation can tag the entry with confidence. >>>>>> >>>>>> For example, If one sends a request to PSAP using 911, directory >>>>>> assistance using 411, name(411,911 or service-URN) is >> translated to >>>>>> an address. That address may be translated numerous times to >>>>>> another >>>>>> address (PSAP in NYC to PSAP in NJ) but will never be translated >>>>>> again to another name(911 to 411). >>>>>> >>>>>> Furthermore, entity/organization that is expecting to be >> reached by >>>>>> name usually knows what name it will be reached by, so having the >>>>>> ability to distinguish one service to another is probably not >>>>>> necessary but having the ability to tag "name" to "address" >>>>>> translation, I believe is very helpful. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Regards >>>>>> Shida >>>>>> >>>>>> >>>>>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: >>>>>> >>>>>>> Other idea? >>>>>>> >>>>>>> (I really don't care personally about "freephone"...) >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>>>>>> Sent: Thursday, September 24, 2009 11:48 >>>>>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert; >>>>>>>> Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis; >>>>>>>> Elwell, John; Keith Drage >>>>>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>>>>>>> >>>>>>>> Yes got that, but that does not justify a service >> specific tag in >>>>>>>> 4244bis. >>>>>>>> /hans erik >>>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> From drage@alcatel-lucent.com Sat Nov 7 06:34:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21713A67B4 for ; Sat, 7 Nov 2009 06:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DSjcyfjW0VB for ; Sat, 7 Nov 2009 06:34:11 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id D48063A635F for ; Sat, 7 Nov 2009 06:34:09 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA7EYWKM031251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Nov 2009 15:34:32 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 7 Nov 2009 15:34:32 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , SIPCORE Date: Sat, 7 Nov 2009 15:34:31 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: Acpe65kZxHju2o1jTbW3Gh4C4lBnlAAAqkVAADEmM/A= Message-ID: References: <4AE8B942.1090506@cisco.com> <4AF3471B.9060409@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 14:34:12 -0000 I am fine with the text we now have in -03pre which says: If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad INFO Package) response (see Section 11.6). In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure. Based on [RFC5057] the response represents a Transaction Only failure, and does not terminate the invite dialog usage. except that we now seem to be saying it twice. Can we combine this into a s= ingle sentence. I note that we have covered the dialog usage of other responses to INFO in = 3.2.2 as follows: The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx), in accordance with the error handling procedures in [RFC5057]. except that surely we need a parallel paragraph to this in section 3.2.1 to= say that reception of such responses is handled as defined in RFC 5057. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, November 06, 2009 2:36 PM > To: Adam Roach; Sanjay Sinha (sanjsinh) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I agree with Adam, and based on feeback I got from Robert, a=20 > 469 should NEVER terminate the dialog usage, and individual=20 > Info Packages shall not change that. >=20 > Anyone objects to that? >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 5. marraskuuta 2009 23:44 > > To: Sanjay Sinha (sanjsinh) > > Cc: Paul Kyzivat (pkyzivat); Christer Holmberg; SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > [as an individual] > >=20 > > On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote: > > > If the INFO transaction fails, then let the application > > decide whether > > > it wants to continue with the dialog or not? > > > =20 > >=20 > > That's functionally equivalent to asking "why don't we=20 > leave it to the=20 > > application to decide whether a BYE terminates an invite usage?" > >=20 > > When an error occurs, both sides need to know the resulting=20 > state. If=20 > > you sent me a 469, and your application decided that this=20 > terminated=20 > > the dialog but mine decided it only terminated the transaction, the=20 > > result would be unexpected and decidedly unfortunate behavior. > >=20 > > That's why we bothered to publish RFC 5057 at all. > >=20 > > /a > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From drage@alcatel-lucent.com Sat Nov 7 06:36:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807503A6863 for ; Sat, 7 Nov 2009 06:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnNAMfue0UoC for ; Sat, 7 Nov 2009 06:36:51 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 0BE673A635F for ; Sat, 7 Nov 2009 06:36:50 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA7EbDxh026817 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 7 Nov 2009 15:37:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 7 Nov 2009 15:37:13 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg Date: Sat, 7 Nov 2009 15:37:12 +0100 Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info Thread-Index: AcpbxdyHPh7aIVANRHGyreVG/iED+QANC8mwAO7ZQeA= Message-ID: References: <4AE9A6CD.80907@cisco.com> <4AEAFA5D.4080204@cisco.com> <4AEEE7B5.60301@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 14:36:52 -0000 I am fine with the text we now have on this in -03pre with the following ex= ceptions. For REGISTER, I guess I can live with this, but the text now specifying it = is tantamount to saying using it this way is pretty useless and there are o= ther mechanisms that should be used. Is anybody trying to defend an existin= g usage, or can we just take it out. For ACK and PRACK, I'd like to understand the 3PCC issue better. Does anyon= e have a message flow with the use of the Recv-Info header field shown.=20 What I seem to be seeing is an indication that the ACK is needed to return = a Recv-Info if one gets a new indication in the 200 (OK) to a reinvite.=20 But what I currently read from the text is that once I have indicated a set= of Info Packages in a Recv-Info header field, I do not need to do it again= unless I wish to change that set. There is no presumption that the indicat= ion from a remote user means I should send my set sagain. Does the 3pcc discussion mean that I should now have text in the document t= hat says if I receive a new set of Info-Package names in a Recv-Info header= within a dialog, I SHOULD return a new set of Recv-Info values even if the= y have not changed, as the remote user may no longer be the same remote use= r. Otherwise I see no justification in the document for the ACK usage (or the = PRACK usage) based on the current requirement text. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, November 02, 2009 8:32 PM > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Info Even Open Issue: Method types and=20 > offer/answer for Recv-Info >=20 >=20 > Hi,=20 >=20 > >>>> You would have to send an extra re-INVITE/UPDATE just=20 > because you=20 > >>>> couldn't send the I-P list in the ACK. Or? > >>>> > >>>> And, if there are no rules one can of course send a list both in > the=20 > >>>> INVITE and the ACK. I don't know if that is likely to happen, but > if=20 > >>>> the ACK trigger the remote entity's list to change it=20 > would have to >=20 > >>>> trigger a request in order to change the list, since there is no=20 > >>>> response to ACK. > >>> But this is not a negotiation, just a declaration. > >>> So what harm is there in changing between INVITE and ACK? > >>> (As unlikely as that seems.) > >>=20 > >> Maybe it works. > >>=20 > >> But, would it then also be allowed to send one list in a reliable > 18x,=20 > >> and then a new list in the next relaible 18x, and then a third list > in=20 > >> the 200 OK - all for the same transaction? > > > >What bad things happen if you do that? >=20 > Maybe nothing. I just wanted to make sure you were ok with it :) >=20 > >The worst thing I can see is that you might get sent an I-P you don't > want to receive. Then you just ignore it, or send a 469, and=20 > go on about your business. > > > >Perhaps its more trouble on the sending side, though its hard to > generalize. Consider the specific case of DTMF. A UA may be=20 > trying to decide how to set itself up to send DTMF, choosing=20 > from among the=20 > >multitude of ways that are possible. If it gets a change - adding or > removing a DTMF info package, then it may have to change=20 > other things as well, such as adding or removing=20 > telephone-events from its=20 > >media types. > > > >But, that problem exists whether or not we we allow changes in R-I > between responses, so its not a big deal. >=20 > Maybe we could recommend against updating the list more than=20 > once per transaction, especially if the list could have=20 > impacts on other exchanged information (SDP etc). >=20 > -------------------------- >=20 > >>>Which dialog? Since this is 3pcc, and the interesting case is a > transfer, there are *3* dialogs. > >>>It should never hurt to send an R-I in the context of a=20 > response to a > reinvite. > >>=20 > >>The draft says that you don't send a list unless you know that the=20 > >>other party - for that dialog - supports the mechanism. > > > >In 3pcc that can be a problem. You don't ever know if you are talking > to the same party that you were last time. > > > >>>There may indeed be a problem in one case. Here's a=20 > picture to refer > >>> to: > >>> A ----- B ----- C > >>> | > >>> --- D > >>> > >>>Initially A is connected, via B to C. Then B initiates a 3pcc > transfer > >>>by sending a reinvite to A. > >>>Now suppose that both A and C support I-P, but D does not.=20 > How will A=20 > >>>ever learn that D does not? It won't receive an R-I header from D, > and=20 > >>>so will assume its unchanged from what it had from C. And when it=20 > >>>sends INFOs with an I-P, D will think they are legacy. It will > never > >>>send a 469, so it won't quench the sending. > >>>=20 > >>I assume B has contected D before it sends the re-INVITE to=20 > A, right? > > > >There are lots of ways to do it, depending on the goals of=20 > the case. So > maybe yes, maybe no. > > > >>So, if D does NOT support I-P, I guess B would have to=20 > include R-I:nil > in the re-INVITE to A. > > > >That means it won't work correctly unless B itself has an=20 > understanding > of info packages. It would be better if that were not a requirement. >=20 > But, how is this different from any other=20 > extension/capability (non-SDP) that A and C may previously=20 > have agreed upon, and D doesn't support? >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gonzalo.camarillo@ericsson.com Sat Nov 7 19:55:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D82F3A6837 for ; Sat, 7 Nov 2009 19:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91MWKZNkEkIR for ; Sat, 7 Nov 2009 19:55:11 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B177B3A67CF for ; Sat, 7 Nov 2009 19:55:10 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-86-4af641362174 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7A.79.24026.63146FA4; Sun, 8 Nov 2009 04:55:34 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 04:55:34 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 04:55:33 +0100 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 37E6C24F7; Sun, 8 Nov 2009 05:55:30 +0200 (EET) Message-ID: <4AF64130.1040003@ericsson.com> Date: Sun, 08 Nov 2009 12:55:28 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> In-Reply-To: <4AF36339.5080600@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2009 03:55:33.0456 (UTC) FILETIME=[5251BD00:01CA6027] X-Brightmail-Tracker: AAAAAA== Cc: Taisto Qvist XX , "sipcore@ietf.org" , Jeroen van Bemmel Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 03:55:12 -0000 Hi, this is the approach we have followed when writing the following section of the re-INVITE handling draft: http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite-01#section-12 Cheers, Gonzalo Paul Kyzivat wrote: > I agree with Jeroen > > Jeroen van Bemmel wrote: >> Brett, >> >> Even if it's not clearly defined, to me the rule should be simple: >> always update the remote target whenever a valid target refresh >> request/response (1xx or 2xx) containing a Contact header is received >> (with "valid" meaning syntactically correct and in proper dialog >> sequence, matching an existing transaction for responses, and no >> retransmission) >> >> It must be assumed that the peer is communicating its most up-to-date >> value for its Contact address, I see no reason to ignore such updates >> (and I do see how ignoring an updated Contact can cause failures, the >> peer may have obtained a new IP address for example, during the time >> interval it was ringing - e.g. some handset being picked up from a >> docking station with a fixed LAN cable, switching to WiFi) >> >> Regards, >> Jeroen >> >> Brett Tate wrote: >>> Hi Taisto, >>> >>> I agree that the rfc3261 text is ambiguous and has some conflicting >>> statements. >>> >>> The following thread discusses some of the ambiguities: >>> >>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020127.html >>> >>> >>> In my opinion, a strict interpretation of rfc3261 does not allow >>> INVITE 1xx/2xx's Contact to update the target during call set-up >>> after the dialog has been created. I'm not sure if the authors >>> actually intended such a restriction; I not aware of vendors actually >>> enforcing such a restriction. >>> >>> The following is some questions/text from above thread in case >>> someone wants to answer the questions. >>> >>> Should the remote target be updated per INVITE 2xx's Contact? If not, >>> then why is section 13.2.2.4 pointing to section 12.2.1.2? When I >>> posted my question, I had thought that it was trying to indicate to >>> adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx. >>> >>> Is the following what rfc3261 is attempting to communicate? >>> >>> 1) Dialog forming INVITE 1xx/2xx creates route set based upon >>> record-route and sets remote target per Contact. >>> >>> 2) Original INVITE's subsequent 101-199 has no impact upon a known >>> dialog's route set and remote target. >>> >>> 3) Original INVITE's 2xx resets route set per received/missing >>> record-route and does not set (or update) per Contact. >>> >>> 4) Retargeting (excluding original INVITE) request's 2xx within dialog >>> allow the remote target to be updated. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Sat Nov 7 19:58:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0302F3A6914 for ; Sat, 7 Nov 2009 19:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nv2SSkC0W2P for ; Sat, 7 Nov 2009 19:58:33 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9FB0A3A6837 for ; Sat, 7 Nov 2009 19:58:32 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-79-4af64200cca4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.87.04191.00246FA4; Sun, 8 Nov 2009 04:58:56 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 04:58:56 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 04:58:55 +0100 Received: from [131.160.126.187] (rvi2-126-187.lmf.ericsson.se [131.160.126.187]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C92BA24F7; Sun, 8 Nov 2009 05:58:53 +0200 (EET) Message-ID: <4AF641FC.70606@ericsson.com> Date: Sun, 08 Nov 2009 12:58:52 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2009 03:58:55.0670 (UTC) FILETIME=[CAD92560:01CA6027] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 03:58:34 -0000 Hi, note that the following draft deals with target refreshes as well, not only with SDP stuff: http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite Cheers, Gonzalo Christer Holmberg wrote: > Hi, > >> Yes; there have been discussions. Unfortunately non have >> actually led to an update to rfc3261. >> >> >> As you know, there are some drafts concerning >> updates/rollbacks related to re-INVITE and UPDATE failure. >> However I don't recall if there are any non expired drafts >> actually discussing the topic within this thread. > > No, I don't think so. > > The drafts are more related to what happens to confirmed changes (e.g. > in a 18x response) if a re-INVITE fails. > > Regards, > > Christer > > > >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Friday, November 06, 2009 7:49 AM >>> To: Brett Tate; Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; >>> sipcore@ietf.org >>> Subject: RE: [sipcore] Changingcontact/remote target in >> target refresh >>> response >>> >>> >>> Hi, >>> >>> Unfortunately this is not the first time we are having this >> discussion. >>> I am not sure what (if any) the outcome has been in previous >>> discussion, but it may be worthwile taking a look in the archieves. >>> >>> Regards, >>> >>> Christer >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate >>>> Sent: 6. marraskuuta 2009 13:41 >>>> To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; >>> sipcore@ietf.org >>>> Subject: Re: [sipcore] Changingcontact/remote target in >>>> targetrefresh response >>>> >>>> I don't disagree with the rule that Jeroen indicated. >>>> BroadSoft may soon need our partners to follow such a rule. >>>> Unfortunately there is nothing within rfc3261 which >> indicates they >>>> MUST, SHOULD, or even MAY behave that way. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Thursday, November 05, 2009 6:44 PM >>>>> To: Jeroen van Bemmel >>>>> Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org >>>>> Subject: Re: [sipcore] Changing contact/remote target in >>>> targetrefresh >>>>> response >>>>> >>>>> I agree with Jeroen >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Brett, >>>>>> >>>>>> Even if it's not clearly defined, to me the rule should be >>> simple: >>>>>> always update the remote target whenever a valid >> target refresh >>>>>> request/response (1xx or 2xx) containing a Contact header is >>>>>> received (with "valid" meaning syntactically correct and >>>> in proper >>>>>> dialog sequence, matching an existing transaction for >>>> responses, and >>>>>> no >>>>>> retransmission) >>>>>> >>>>>> It must be assumed that the peer is communicating its most >>>>>> up-to-date value for its Contact address, I see no reason >>>> to ignore >>>>>> such updates (and I do see how ignoring an updated >>>> Contact can cause >>>>>> failures, the peer may have obtained a new IP address for >>>> example, >>>>>> during the time interval it was ringing - e.g. some handset >>>>>> being picked up from a docking station with a fixed LAN cable, >>>> switching >>>>>> to WiFi) >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Sun Nov 8 10:53:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5B43A6A32 for ; Sun, 8 Nov 2009 10:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPz7BCFHOnux for ; Sun, 8 Nov 2009 10:53:26 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 93EA13A6851 for ; Sun, 8 Nov 2009 10:53:26 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 8 Nov 2009 10:53:51 -0800 From: Brett Tate To: Gonzalo Camarillo , Christer Holmberg , "sipcore@ietf.org" Date: Sun, 8 Nov 2009 10:53:39 -0800 Thread-Topic: [sipcore] Changingcontact/remote target in target refresh response Thread-Index: AcpgJ8zQky39Nr5/QHyacp13QcGA3QAd3kQw Message-ID: <747A6506A991724FB09B129B79D5FEB613FCD794F9@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> <4AF641FC.70606@ericsson.com> In-Reply-To: <4AF641FC.70606@ericsson.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 Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 18:53:27 -0000 Hi Gonzalo, For meeting the SIPCORE "Invite Transaction Handling Correction" milestone,= I propose that draft-camarillo-sipcore-reinvite be updated to also address= the topic within this thread. More specifically, I propose that the draft= clearly also discuss INVITE instead of only re-INVITE (and other target-re= fresh requests) when discussing impacts of 1xx/2xx responses containing an = updated Contact (and Record-Route). Since the milestone currently indicates "Done", is "Invite Transaction Hand= ling Correction" intended for something like draft-camarillo-sipcore-reinvi= te? Or was the milestone for something like draft-sparks-sipcore-invfix? Thanks, Brett > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Saturday, November 07, 2009 10:59 PM > To: Christer Holmberg > Cc: Brett Tate; sipcore@ietf.org > Subject: Re: [sipcore] Changingcontact/remote target in target refresh > response >=20 > Hi, >=20 > note that the following draft deals with target refreshes as well, not > only with SDP stuff: >=20 > http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite >=20 > Cheers, >=20 > Gonzalo >=20 > Christer Holmberg wrote: > > Hi, > > > >> Yes; there have been discussions. Unfortunately non have > >> actually led to an update to rfc3261. > >> > >> > >> As you know, there are some drafts concerning > >> updates/rollbacks related to re-INVITE and UPDATE failure. > >> However I don't recall if there are any non expired drafts > >> actually discussing the topic within this thread. > > > > No, I don't think so. > > > > The drafts are more related to what happens to confirmed changes > (e.g. > > in a 18x response) if a re-INVITE fails. > > > > Regards, > > > > Christer From brett@broadsoft.com Sun Nov 8 11:13:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8193A6A2B for ; Sun, 8 Nov 2009 11:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ6xymBoR+9Q for ; Sun, 8 Nov 2009 11:13:23 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 9BBD63A697D for ; Sun, 8 Nov 2009 11:13:23 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 8 Nov 2009 11:13:49 -0800 From: Brett Tate To: Gonzalo Camarillo , "sipcore@ietf.org" Date: Sun, 8 Nov 2009 11:13:39 -0800 Thread-Topic: [sipcore] Changing contact/remote target in targetrefresh response Thread-Index: AcpgJ1ZNHrCbkqa1QMuKK835BYdu0QAfaVcw Message-ID: <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> In-Reply-To: <4AF64130.1040003@ericsson.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 Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 19:13:35 -0000 Hi Gonzalo, In case it matters, draft-camarillo-sipcore-reinvite-01 section 12 only par= tially follows the indicated approach. Section 12 currently requires the 1= xx response to be reliable for the Contact to be updated. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Saturday, November 07, 2009 10:55 PM > To: Paul Kyzivat > Cc: Taisto Qvist XX; sipcore@ietf.org; Jeroen van Bemmel > Subject: Re: [sipcore] Changing contact/remote target in targetrefresh > response >=20 > Hi, >=20 > this is the approach we have followed when writing the following > section > of the re-INVITE handling draft: >=20 > http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite-01#section- > 12 >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > Paul Kyzivat wrote: > > I agree with Jeroen > > > > Jeroen van Bemmel wrote: > >> Brett, > >> > >> Even if it's not clearly defined, to me the rule should be simple: > >> always update the remote target whenever a valid target refresh > >> request/response (1xx or 2xx) containing a Contact header is > received > >> (with "valid" meaning syntactically correct and in proper dialog > >> sequence, matching an existing transaction for responses, and no > >> retransmission) > >> > >> It must be assumed that the peer is communicating its most up-to- > date > >> value for its Contact address, I see no reason to ignore such > updates > >> (and I do see how ignoring an updated Contact can cause failures, > the > >> peer may have obtained a new IP address for example, during the time > >> interval it was ringing - e.g. some handset being picked up from a > >> docking station with a fixed LAN cable, switching to WiFi) > >> > >> Regards, > >> Jeroen From john.elwell@siemens-enterprise.com Sun Nov 8 14:22:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D5828C0DE for ; Sun, 8 Nov 2009 14:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HS0sJBaEqxP for ; Sun, 8 Nov 2009 14:21:59 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 4F5BB3A6358 for ; Sun, 8 Nov 2009 14:21:59 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nA8M86FE003641; Sun, 8 Nov 2009 23:08:06 +0100 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA8M85AT026552; Sun, 8 Nov 2009 23:08:06 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Sun, 8 Nov 2009 23:08:04 +0100 From: "Elwell, John" To: Shida Schubert Date: Sun, 8 Nov 2009 23:08:04 +0100 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcpfqkvqZBObUIdkR4OSp2jarCLB0QAx3xTg Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA0238@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> <14085347-6A13-43EC-B0D2-0B25554EAFEC@ntt-at.com> In-Reply-To: <14085347-6A13-43EC-B0D2-0B25554EAFEC@ntt-at.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , Ian Elz , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 22:22:00 -0000 =20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 07 November 2009 13:00 > To: Elwell, John > Cc: Ian Elz; Paul Kyzivat; Fran=E7ois AUDET; SIPCORE; Hadriel=20 > Kaplan; Dean Willis; ELWELL John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 > John; >=20 > My comments inline... >=20 > >> > >> > >> - Example 2: Call from A to freephone number B, which=20 > resolves to C, > >> which is then forwarded to D, which resolves to contact E. > >> > >> H-I: B; index=3D1 > >> H-I: C; index=3D1.1; > >> H-I: D; index=3D1.1.1; > > [JRE] I think this should have an mp tag, because the entity doing =20 > > the forwarding would normally apply the mp tag when=20 > forwarding. The =20 > > fact that earlier the request had been targeted at a freephone =20 > > number is unlikely to influence forwarding behaviour (and indeed =20 > > might not be known to the entity doing the forwarding), so the mp =20 > > tag would be added. > > > > John >=20 > If C and D represents a different user I would agree with you > but if it represents for example two different office location from > the same company which have freephone number B as their > alias, I think it really represents the same user so 'mp' tag > shouldn't be added. [JRE] I agree. In the case where it is the same user, ideally the two phone= s would have the same AoR, so there would be no mapping. However, in practi= ce they are often different AoRs, so the situation can arise that there wou= ld be mapping from one AoR to another AoR, both representing the same "user= ". The question is, whether the entity doing the forwarding is aware that t= he two AoRs represent the same user, in order to suppress the 'mp' tag in t= his case. As I explained to you face-to-face this evening, I think the present propos= al is better than earlier proposals, and that with careful wording we can d= efine the conditions for inserting the two tags reasonably precisely such t= hat different implementations will use them correctly. However, I am convin= ced there will be some cases (perhaps relatively uncommon) where interpreta= tion of the received HI as described in the draft (e.g., to find the freeph= one number) will not work quite as expected. Maybe the answer is to search = the HI looking for a URI that you recognise as a freephone number - but you= don't need to enhance HI to do that. John From christer.holmberg@ericsson.com Sun Nov 8 17:47:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305F63A686D for ; Sun, 8 Nov 2009 17:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt5bLpO5wJ3g for ; Sun, 8 Nov 2009 17:47:28 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CAEDA3A6823 for ; Sun, 8 Nov 2009 17:47:27 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-b3-4af774c845d6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4D.88.04191.8C477FA4; Mon, 9 Nov 2009 02:47:52 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 02:47:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA60DE.A5A8C78F" Date: Mon, 9 Nov 2009 02:47:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO-EVENT: DTMF Package thread-index: Acpg3qWeL+g3ib1bQ4O79qBxg8+qiA== From: "Christer Holmberg" To: X-OriginalArrivalTime: 09 Nov 2009 01:47:51.0969 (UTC) FILETIME=[A6215910:01CA60DE] X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan Subject: [sipcore] INFO-EVENT: DTMF Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:47:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA60DE.A5A8C78F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Below is a link to the now expired DTMF Info Package draft: http://ietfreport.isoc.org/all-ids/draft-kaplan-sipping-dtmf-package-00. txt It WAS submitted to IETF 12th november 2007, but not much happened to it after that. As I said, my intention is to submit a new version as soon as the procedures ar clear. Regards, Christer ------_=_NextPart_001_01CA60DE.A5A8C78F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable INFO-EVENT: DTMF Package

Hi,

Below is a link to the now expired DTMF = Info Package draft:

http://ietfreport.isoc.org/all-ids/draft-kaplan-sipping-dt= mf-package-00.txt

It WAS submitted to IETF 12th november = 2007, but not much happened to it after that.

As I said, my intention is to submit a = new version as soon as the procedures ar clear.

Regards,

Christer

------_=_NextPart_001_01CA60DE.A5A8C78F-- From christer.holmberg@ericsson.com Sun Nov 8 19:17:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249DC3A68DB for ; Sun, 8 Nov 2009 19:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP2i+iCEnZAu for ; Sun, 8 Nov 2009 19:17:50 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A0A313A6767 for ; Sun, 8 Nov 2009 19:17:49 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-87-4af789e4bb7e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3B.8B.04191.4E987FA4; Mon, 9 Nov 2009 04:17:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 04:17:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA60EB.3AFBA675" Date: Mon, 9 Nov 2009 04:17:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: Acpg6zrsK1B9zdQfShCPxuE52V05UQ== From: "Christer Holmberg" To: X-OriginalArrivalTime: 09 Nov 2009 03:17:56.0165 (UTC) FILETIME=[3B483750:01CA60EB] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:17:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA60EB.3AFBA675 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Based on the 3pcc issue raised by Paul, at the SIPCORE session we discussed whether we should mandate to include Recv-Info in re-INVITE responses. The outcome of the discussion was that EVERY SIP messages where Recv-Info is allowed MUST contain Recv-Info, NO MATTER if the set of Info Packages has changed or not.=20 Based on the -03pre version of the draft the following messages would be affected: INVITE + 18x + 200 Re-INVITE + 18x + 200 ACK UPDATE + 200 PRACK + 200 That is a change from previous versions of the draft, which says that the Recv-Info header only needs to be inserted if the set of Info Packages changes. So, unless people have issues with that, my intention is to implement the change in the next version of the draft. Regards, Christer ------_=_NextPart_001_01CA60EB.3AFBA675 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable INFO EVENT @ IETF#76: When to insert Recv-Info header

Hi,

Based on the 3pcc issue raised by Paul, = at the SIPCORE session we discussed whether we should mandate to include = Recv-Info in re-INVITE responses.

The outcome of the discussion was that = EVERY SIP messages where Recv-Info is allowed MUST contain Recv-Info, NO = MATTER if the set of Info Packages has changed or not.

Based on the -03pre version of the = draft the following messages would be affected:

INVITE + 18x + 200
Re-INVITE + 18x + 200
ACK
UPDATE + 200
PRACK + 200

That is a change from previous versions = of the draft, which says that the Recv-Info header only needs to be = inserted if the set of Info Packages changes.

So, unless people have issues with = that, my intention is to implement the change in the next version of the = draft.

Regards,

Christer

------_=_NextPart_001_01CA60EB.3AFBA675-- From Martin.Thomson@andrew.com Sun Nov 8 19:51:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF2B3A691E for ; Sun, 8 Nov 2009 19:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyXCpIokJ1T3 for ; Sun, 8 Nov 2009 19:51:00 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id BF41E3A67DD for ; Sun, 8 Nov 2009 19:51:00 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:50528 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S5034186AbZKIDv0 (ORCPT ); Sun, 8 Nov 2009 21:51:26 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 8 Nov 2009 21:51:26 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 9 Nov 2009 11:51:23 +0800 From: "Thomson, Martin" To: "sipcore@ietf.org" Date: Mon, 9 Nov 2009 11:51:52 +0800 Thread-Topic: Event rate control and GEOPRIV requirements Thread-Index: Acpg7/kNDsVv86+gTDudkXe/VuYsbQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:51:01 -0000 SXMgdGhlIC0wMCB2ZXJzaW9uIHRoZSBsYXRlc3QgaXNzdWUgb2YgdGhpcyBkcmFmdD8gIEkgZXhw ZWN0ZWQgYSAtMDEgYW5kIHNvIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHdlIHdlcmUg ZGlzY3Vzc2lvbiBjaGFuZ2VzIGFscmVhZHkgbWFkZS4NCg0KVGhlIGZvbGxvd2luZyB0d28gbWlu b3IgY2hhbmdlcyB3ZXJlIHJlcXVlc3RlZCBvdXQgb2YgdGhlIEdFT1BSSVYgdXNlIGNhc2VzOg0K DQogLSBub3RlIHRoYXQgdGhlIHJhdGUgY29udHJvbCBwYXJhbWV0ZXJzIGNhbiBiZSB1cGRhdGVk IGluIHJlc3BvbnNlIG1lc3NhZ2VzIChpLmUuIHRoZSAyMDAgcmVzcG9uc2UgdG8gYW4gaW5pdGlh bCBOT1RJRlkpOyB0aGUgbm90aWZpZXIgdGhlbiBpbmRpY2F0ZXMgdGhlIGFncmVlZCAoYW5kIHBv c3NpYmlsaXR5IG1vZGlmaWVkKSB2YWx1ZXMgaW4gc3Vic2VxdWVudCBOT1RJRllzDQoNCiAtIG5v dGUgdGhhdCByYXRlIGNvbnRyb2wgcGFyYW1ldGVycyBjYW4gYmUgY2hhbmdlZCBhdCBhbnkgdGlt ZSBieSB0aGUgbm90aWZpZXIsIGJhc2VkIG9uIHBvbGljeS0gb3IgaW1wbGVtZW50YXRpb24tZGV0 ZXJtaW5lZCBjb25zdHJhaW50cw0KDQpUaGlzIGlzIHdoYXQgd2UgZGlzY3Vzc2VkIGluIHRoZSBt ZWV0aW5nLg0KDQpJIHRoaW5rIHRoYXQgdGhlIHNlY29uZCBvbmUgaXMgT0sgaW4gdGhlIHZlcnNp b24gLTAwIGRyYWZ0LiAgSSBjb3VsZCBub3QgZmluZCBhbnl3aGVyZSB0aGF0IG1lbnRpb25lZCB1 cGRhdGluZyBldmVudCBwYXJhbWV0ZXJzIGluIGEgcmVzcG9uc2UgbWVzc2FnZS4NCg0KLS1NYXJ0 aW4NCg0K From pkyzivat@cisco.com Sun Nov 8 20:14:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD19728C0E5 for ; Sun, 8 Nov 2009 20:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJVoVUq8I7kd for ; Sun, 8 Nov 2009 20:14:37 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 749DA3A67F1 for ; Sun, 8 Nov 2009 20:14:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKAl90pAZnwM/2dsb2JhbADDS5Y/hD4E X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208";a="66961737" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2009 04:14:58 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA94EvY3020282; Mon, 9 Nov 2009 04:14:58 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.3959); Sun, 8 Nov 2009 23:14:57 -0500 Received: from [10.86.252.50] ([10.86.252.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 23:14:57 -0500 Message-ID: <4AF79740.8020707@cisco.com> Date: Sun, 08 Nov 2009 23:14:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 04:14:57.0307 (UTC) FILETIME=[32710EB0:01CA60F3] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:14:45 -0000 That works for me, and it is sufficiently simple that everybody should be able to implement it correctly. :-) Thanks, Paul Christer Holmberg wrote: > > Hi, > > Based on the 3pcc issue raised by Paul, at the SIPCORE session we > discussed whether we should mandate to include Recv-Info in re-INVITE > responses. > > The outcome of the discussion was that EVERY SIP messages where > Recv-Info is allowed MUST contain Recv-Info, NO MATTER if the set of > Info Packages has changed or not. > > Based on the -03pre version of the draft the following messages would be > affected: > > INVITE + 18x + 200 > Re-INVITE + 18x + 200 > ACK > UPDATE + 200 > PRACK + 200 > > That is a change from previous versions of the draft, which says that > the Recv-Info header only needs to be inserted if the set of Info > Packages changes. > > So, unless people have issues with that, my intention is to implement > the change in the next version of the draft. > > Regards, > > Christer > From drage@alcatel-lucent.com Sun Nov 8 20:38:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3B528C144 for ; Sun, 8 Nov 2009 20:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCAoJpBkZXKO for ; Sun, 8 Nov 2009 20:38:37 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 0683C28C135 for ; Sun, 8 Nov 2009 20:38:36 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nA94ccXG009757 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Nov 2009 05:38:38 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 9 Nov 2009 05:38:38 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Christer Holmberg Date: Mon, 9 Nov 2009 05:38:37 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: Acpg80LKRPxE+7B5RcqYWl5mvQxqzgAAvwzw Message-ID: References: <4AF79740.8020707@cisco.com> In-Reply-To: <4AF79740.8020707@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:38:38 -0000 This works, but it seems overkill to me. Firstly can I ensure that this does not include REGISTER, which could also = be understood from the paraphrase of the SIPCORE discussion. Secondly can I still have more detail (arrow diagram) on the scenario we ar= e trying to solve for 3pcc. I can't see if there is a simple solution if th= e problem is insufficiently clear. Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, November 09, 2009 4:15 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 > That works for me, and it is sufficiently simple that=20 > everybody should be able to implement it correctly. :-) >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > >=20 > > Hi, > >=20 > > Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 > > discussed whether we should mandate to include Recv-Info in=20 > re-INVITE=20 > > responses. > >=20 > > The outcome of the discussion was that EVERY SIP messages where=20 > > Recv-Info is allowed MUST contain Recv-Info, NO MATTER if=20 > the set of=20 > > Info Packages has changed or not. > >=20 > > Based on the -03pre version of the draft the following=20 > messages would=20 > > be > > affected: > >=20 > > INVITE + 18x + 200 > > Re-INVITE + 18x + 200 > > ACK > > UPDATE + 200 > > PRACK + 200 > >=20 > > That is a change from previous versions of the draft, which=20 > says that=20 > > the Recv-Info header only needs to be inserted if the set of Info=20 > > Packages changes. > >=20 > > So, unless people have issues with that, my intention is to=20 > implement=20 > > the change in the next version of the draft. > >=20 > > Regards, > >=20 > > Christer > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From kpfleming@digium.com Sun Nov 8 20:50:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222C428C11F for ; Sun, 8 Nov 2009 20:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.359 X-Spam-Level: X-Spam-Status: No, score=-105.359 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVSjJJY+nn-4 for ; Sun, 8 Nov 2009 20:50:38 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 3ECEE28C0DF for ; Sun, 8 Nov 2009 20:50:38 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N7MDX-0008Qr-St for sipcore@ietf.org; Sun, 08 Nov 2009 22:51:03 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id C9998DFC828 for ; Sun, 8 Nov 2009 22:51:03 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T94kcGMM8XRf for ; Sun, 8 Nov 2009 22:51:03 -0600 (CST) Received: from [133.93.24.160] (host-24-160.meeting.ietf.org [133.93.24.160]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 071C1DFC827 for ; Sun, 8 Nov 2009 22:51:02 -0600 (CST) Message-ID: <4AF79FB4.6070902@digium.com> Date: Mon, 09 Nov 2009 13:51:00 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: "sipcore@ietf.org" References: <4AF79740.8020707@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:50:39 -0000 DRAGE, Keith (Keith) wrote: > This works, but it seems overkill to me. > > Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion. I could be wrong, but I believe this discussion was entirely within the context of an INVITE-created dialog and its subsequent transactions. That particular part of the discussion revolved around re-INVITEs and target refreshes. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From shida@ntt-at.com Sun Nov 8 21:14:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2196828C14F for ; Sun, 8 Nov 2009 21:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiQuEIYi6yYU for ; Sun, 8 Nov 2009 21:14:11 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.21]) by core3.amsl.com (Postfix) with SMTP id 0B2BE3A6932 for ; Sun, 8 Nov 2009 21:14:10 -0800 (PST) Received: (qmail 31591 invoked from network); 9 Nov 2009 05:26:36 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 9 Nov 2009 05:26:36 -0000 Received: from host-18-151.meeting.ietf.org ([133.93.18.151]:65495) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1N7Ma5-0003TH-Np; Sun, 08 Nov 2009 23:14:22 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA0238@DEMCHP99E35MSX.ww902.siemens.net> Date: Mon, 9 Nov 2009 14:14:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> <7402509E63C5A145A6095D46C179A5B70585B42022@DEMCHP99E35MSX.ww902.siemens.net> <14085347-6A13-43EC-B0D2-0B25554EAFEC@ntt-at.com> <7402509E63C5A145A6095D46C179A5B70725DA0238@DEMCHP99E35MSX.ww902.siemens.net> To: "Elwell, John" X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , SIPCORE , Hadriel Kaplan , Dean Willis , Ian Elz , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:14:12 -0000 My comments inline.. On Nov 9, 2009, at 7:08 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: 07 November 2009 13:00 >> To: Elwell, John >> Cc: Ian Elz; Paul Kyzivat; Fran=E7ois AUDET; SIPCORE; Hadriel >> Kaplan; Dean Willis; ELWELL John; Keith Drage >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> John; >> >> My comments inline... >> >>>> >>>> >>>> - Example 2: Call from A to freephone number B, which >> resolves to C, >>>> which is then forwarded to D, which resolves to contact E. >>>> >>>> H-I: B; index=3D1 >>>> H-I: C; index=3D1.1; >>>> H-I: D; index=3D1.1.1; >>> [JRE] I think this should have an mp tag, because the entity doing >>> the forwarding would normally apply the mp tag when >> forwarding. The >>> fact that earlier the request had been targeted at a freephone >>> number is unlikely to influence forwarding behaviour (and indeed >>> might not be known to the entity doing the forwarding), so the mp >>> tag would be added. >>> >>> John >> >> If C and D represents a different user I would agree with you >> but if it represents for example two different office location from >> the same company which have freephone number B as their >> alias, I think it really represents the same user so 'mp' tag >> shouldn't be added. > [JRE] I agree. In the case where it is the same user, ideally the =20 > two phones would have the same AoR, so there would be no mapping. =20 > However, in practice they are often different AoRs, so the situation =20= > can arise that there would be mapping from one AoR to another AoR, =20 > both representing the same "user". The question is, whether the =20 > entity doing the forwarding is aware that the two AoRs represent the =20= > same user, in order to suppress the 'mp' tag in this case. > > As I explained to you face-to-face this evening, I think the present =20= > proposal is better than earlier proposals, and that with careful =20 > wording we can define the conditions for inserting the two tags =20 > reasonably precisely such that different implementations will use =20 > them correctly. However, I am convinced there will be some cases =20 > (perhaps relatively uncommon) where interpretation of the received =20 > HI as described in the draft (e.g., to find the freephone number) =20 > will not work quite as expected. Maybe the answer is to search the =20 > HI looking for a URI that you recognise as a freephone number - but =20= > you don't need to enhance HI to do that. Sure this is one can do without the enhancement, but enhancement makes it easier to find the hi-entry that is of concern and addresses =20= most of the scenarios surrounding service number. Generally there are multiple AoRs mapped to a service number and it is unlikely that call to a service number forwarded to an AoR will get =20= forwarded farther but there is always a corner case. For example, a call may get routed to a closest call-center/=20 operation center based on geographical location, if the destination is busy as all the =20= operator is on call, a call may get routed to a different location where call =20 can be handled right away but generally I think the call gets in the queue =20= instead. Anyhow, we can add a descriptive text showing that "mp" tag will =20 make the search of service number more efficient and suggest that UAS will search for the service number in other "mp" tag entry in case it's not in the =20= last "mp" entry to catch the corner cases you described above. Regards Shida > > John From Hannes.Tschofenig@gmx.net Sun Nov 8 21:20:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFC928C0E5 for ; Sun, 8 Nov 2009 21:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=1.392, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEmgkse8yoF3 for ; Sun, 8 Nov 2009 21:20:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6EFFB3A68C4 for ; Sun, 8 Nov 2009 21:20:29 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2009 05:20:54 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp046) with SMTP; 09 Nov 2009 06:20:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19okRNwja5o7fTRdfaCbJOUJpsj49egE13Vw4mXNN PrXKtELqScGvpO From: "Hannes Tschofenig" To: "'Thomson, Martin'" , References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> Date: Mon, 9 Nov 2009 14:24:06 +0900 Message-ID: <055701ca60fc$df4274e0$4a3e000a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpg7/kNDsVv86+gTDudkXe/VuYsbQACf1RQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:20:31 -0000 I also assumed that a new version would become available by the draft submission deadline. I have just re-submitted the location filters draft (draft-ietf-geopriv-loc-filters-08.txt) and it has a normative dependency on draft-ietf-sipcore-event-rate-control. Ciao Hannes >-----Original Message----- >From: sipcore-bounces@ietf.org >[mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin >Sent: 09 November, 2009 12:52 >To: sipcore@ietf.org >Subject: [sipcore] Event rate control and GEOPRIV requirements > >Is the -00 version the latest issue of this draft? I expected >a -01 and so was under the impression that we were discussion >changes already made. > >The following two minor changes were requested out of the >GEOPRIV use cases: > > - note that the rate control parameters can be updated in >response messages (i.e. the 200 response to an initial >NOTIFY); the notifier then indicates the agreed (and >possibility modified) values in subsequent NOTIFYs > > - note that rate control parameters can be changed at any >time by the notifier, based on policy- or >implementation-determined constraints > >This is what we discussed in the meeting. > >I think that the second one is OK in the version -00 draft. I >could not find anywhere that mentioned updating event >parameters in a response message. > >--Martin > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From salvatore.loreto@ericsson.com Sun Nov 8 21:24:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C543A6820 for ; Sun, 8 Nov 2009 21:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZvrm95VC8xQ for ; Sun, 8 Nov 2009 21:24:53 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CACAF3A67DA for ; Sun, 8 Nov 2009 21:24:52 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-46-4af7a7ba9217 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8B.A0.04191.AB7A7FA4; Mon, 9 Nov 2009 06:25:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:25:14 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:25:14 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F166824F7; Mon, 9 Nov 2009 07:25:13 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ABD1F21A2A; Mon, 9 Nov 2009 07:25:13 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 88D1A219B8; Mon, 9 Nov 2009 07:25:12 +0200 (EET) Message-ID: <4AF7A7B7.8050806@ericsson.com> Date: Mon, 09 Nov 2009 07:25:11 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Nov 2009 05:25:14.0169 (UTC) FILETIME=[03E32290:01CA60FD] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:24:54 -0000 Hi Martin, an updated version of the event-rate-control draft was submitted two days after the IETF76 deadline, for this reason it is not yet on the I-D repository, however it will be available soon for the time being you can fetch a copy from http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt /Sal Thomson, Martin wrote: > Is the -00 version the latest issue of this draft? I expected a -01 and so was under the impression that we were discussion changes already made. > > The following two minor changes were requested out of the GEOPRIV use cases: > > - note that the rate control parameters can be updated in response messages (i.e. the 200 response to an initial NOTIFY); the notifier then indicates the agreed (and possibility modified) values in subsequent NOTIFYs > > - note that rate control parameters can be changed at any time by the notifier, based on policy- or implementation-determined constraints > > This is what we discussed in the meeting. > > I think that the second one is OK in the version -00 draft. I could not find anywhere that mentioned updating event parameters in a response message. > > --Martin > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From sanjsinh@cisco.com Sun Nov 8 21:26:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147B528C0F5 for ; Sun, 8 Nov 2009 21:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnGz9gf5IRRP for ; Sun, 8 Nov 2009 21:26:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F1DA83A6936 for ; Sun, 8 Nov 2009 21:26:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHo290qtJV2Y/2dsb2JhbADDOpZDhD4E X-IronPort-AV: E=Sophos;i="4.44,705,1249257600"; d="scan'208";a="67016327" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2009 05:26:56 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nA95Qu3l024740; Mon, 9 Nov 2009 05:26:56 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 23:26:55 -0600 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: Sun, 8 Nov 2009 23:26:53 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA18396D@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: Acpg80LKRPxE+7B5RcqYWl5mvQxqzgAAvwzwAAGikBA= References: <4AF79740.8020707@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "DRAGE, Keith (Keith)" , "Paul Kyzivat (pkyzivat)" , "Christer Holmberg" X-OriginalArrivalTime: 09 Nov 2009 05:26:55.0972 (UTC) FILETIME=[40910A40:01CA60FD] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:26:32 -0000 I will also like to see call flows in next version of the draft for scenarios this covers. Sanjay -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Monday, November 09, 2009 10:09 AM To: Paul Kyzivat (pkyzivat); Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header This works, but it seems overkill to me. Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion. Secondly can I still have more detail (arrow diagram) on the scenario we are trying to solve for 3pcc. I can't see if there is a simple solution if the problem is insufficiently clear. Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, November 09, 2009 4:15 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 > That works for me, and it is sufficiently simple that=20 > everybody should be able to implement it correctly. :-) >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > >=20 > > Hi, > >=20 > > Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 > > discussed whether we should mandate to include Recv-Info in=20 > re-INVITE=20 > > responses. > >=20 > > The outcome of the discussion was that EVERY SIP messages where=20 > > Recv-Info is allowed MUST contain Recv-Info, NO MATTER if=20 > the set of=20 > > Info Packages has changed or not. > >=20 > > Based on the -03pre version of the draft the following=20 > messages would=20 > > be > > affected: > >=20 > > INVITE + 18x + 200 > > Re-INVITE + 18x + 200 > > ACK > > UPDATE + 200 > > PRACK + 200 > >=20 > > That is a change from previous versions of the draft, which=20 > says that=20 > > the Recv-Info header only needs to be inserted if the set of Info=20 > > Packages changes. > >=20 > > So, unless people have issues with that, my intention is to=20 > implement=20 > > the change in the next version of the draft. > >=20 > > Regards, > >=20 > > Christer > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Sun Nov 8 21:33:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14B33A6ABF for ; Sun, 8 Nov 2009 21:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhqrqBGUtKjN for ; Sun, 8 Nov 2009 21:33:47 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id ACA253A68C4 for ; Sun, 8 Nov 2009 21:33:47 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:32488 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5035025AbZKIFeN (ORCPT ); Sun, 8 Nov 2009 23:34:13 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 8 Nov 2009 23:34:13 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 9 Nov 2009 13:34:05 +0800 From: "Thomson, Martin" To: Salvatore Loreto Date: Mon, 9 Nov 2009 13:34:35 +0800 Thread-Topic: [sipcore] Event rate control and GEOPRIV requirements Thread-Index: Acpg/Qi7RiPncEJvQFiDtWQfoc5SEgAAGakQ Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> In-Reply-To: <4AF7A7B7.8050806@ericsson.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:33:48 -0000 SGkgU2FsLA0KDQpUaGFua3MgZm9yIHRoZSBwb2ludGVyLg0KDQpSZWdhcmRpbmcgc2VjdGlvbiA4 LjMsIHdoaWNoIGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnQgaW4gcXVlc3Rpb246DQoNCkknbSBu b3Qgc3VyZSB3aHkgeW91IHdvdWxkIG1ha2UgdGhlIEV2ZW50IGhlYWRlciBtYW5kYXRvcnkgaW4g dGhlIDJ4eCByZXNwb25zZXMuICBPcHRpb25hbCBzZWVtcyB0byBtYWtlIG1vcmUgc2Vuc2UgdG8g bWUuICBFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgZG8gdGhpcywgYWZ0ZXIgYWxsLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNhbHZhdG9yZSBMb3JldG8g W21haWx0bzpzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbV0NCj4gU2VudDogTW9uZGF5LCA5 IE5vdmVtYmVyIDIwMDkgMjoyNSBQTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluDQo+IENjOiBzaXBj b3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRXZlbnQgcmF0ZSBjb250cm9s IGFuZCBHRU9QUklWIHJlcXVpcmVtZW50cw0KPiANCj4gSGkgTWFydGluLA0KPiANCj4gYW4gdXBk YXRlZCB2ZXJzaW9uIG9mIHRoZSBldmVudC1yYXRlLWNvbnRyb2wgZHJhZnQgd2FzIHN1Ym1pdHRl ZCB0d28NCj4gZGF5cyBhZnRlciB0aGUgSUVURjc2IGRlYWRsaW5lLA0KPiBmb3IgdGhpcyByZWFz b24gaXQgaXMgbm90IHlldCBvbiB0aGUgSS1EIHJlcG9zaXRvcnksIGhvd2V2ZXIgaXQgd2lsbCBi ZQ0KPiBhdmFpbGFibGUgc29vbg0KPiANCj4gZm9yIHRoZSB0aW1lIGJlaW5nIHlvdSBjYW4gZmV0 Y2ggYSBjb3B5IGZyb20NCj4gaHR0cDovL2tya2lzcy5sZXRvbHQuaW5mby9kcmFmdC1pZXRmLXNp cGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTAxLnR4dA0KPiANCj4gL1NhbA0KPiANCj4gVGhvbXNv biwgTWFydGluIHdyb3RlOg0KPiA+IElzIHRoZSAtMDAgdmVyc2lvbiB0aGUgbGF0ZXN0IGlzc3Vl IG9mIHRoaXMgZHJhZnQ/ICBJIGV4cGVjdGVkIGEgLTAxDQo+IGFuZCBzbyB3YXMgdW5kZXIgdGhl IGltcHJlc3Npb24gdGhhdCB3ZSB3ZXJlIGRpc2N1c3Npb24gY2hhbmdlcyBhbHJlYWR5DQo+IG1h ZGUuDQo+ID4NCj4gPiBUaGUgZm9sbG93aW5nIHR3byBtaW5vciBjaGFuZ2VzIHdlcmUgcmVxdWVz dGVkIG91dCBvZiB0aGUgR0VPUFJJViB1c2UNCj4gY2FzZXM6DQo+ID4NCj4gPiAgLSBub3RlIHRo YXQgdGhlIHJhdGUgY29udHJvbCBwYXJhbWV0ZXJzIGNhbiBiZSB1cGRhdGVkIGluIHJlc3BvbnNl DQo+IG1lc3NhZ2VzIChpLmUuIHRoZSAyMDAgcmVzcG9uc2UgdG8gYW4gaW5pdGlhbCBOT1RJRlkp OyB0aGUgbm90aWZpZXINCj4gdGhlbiBpbmRpY2F0ZXMgdGhlIGFncmVlZCAoYW5kIHBvc3NpYmls aXR5IG1vZGlmaWVkKSB2YWx1ZXMgaW4NCj4gc3Vic2VxdWVudCBOT1RJRllzDQo+ID4NCj4gPiAg LSBub3RlIHRoYXQgcmF0ZSBjb250cm9sIHBhcmFtZXRlcnMgY2FuIGJlIGNoYW5nZWQgYXQgYW55 IHRpbWUgYnkNCj4gdGhlIG5vdGlmaWVyLCBiYXNlZCBvbiBwb2xpY3ktIG9yIGltcGxlbWVudGF0 aW9uLWRldGVybWluZWQgY29uc3RyYWludHMNCj4gPg0KPiA+IFRoaXMgaXMgd2hhdCB3ZSBkaXNj dXNzZWQgaW4gdGhlIG1lZXRpbmcuDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgdGhlIHNlY29uZCBv bmUgaXMgT0sgaW4gdGhlIHZlcnNpb24gLTAwIGRyYWZ0LiAgSSBjb3VsZA0KPiBub3QgZmluZCBh bnl3aGVyZSB0aGF0IG1lbnRpb25lZCB1cGRhdGluZyBldmVudCBwYXJhbWV0ZXJzIGluIGENCj4g cmVzcG9uc2UgbWVzc2FnZS4NCj4gPg0KPiA+IC0tTWFydGluDQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNpcGNvcmUgbWFpbGlu ZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+DQo+IA0KDQo= From salvatore.loreto@ericsson.com Sun Nov 8 21:48:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D1928C129 for ; Sun, 8 Nov 2009 21:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty86A-htaMVs for ; Sun, 8 Nov 2009 21:48:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9E4A128C0E5 for ; Sun, 8 Nov 2009 21:48:53 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-61-4af7ad5de6c7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 98.D4.24026.D5DA7FA4; Mon, 9 Nov 2009 06:49:18 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:49:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:49:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1B86724F7; Mon, 9 Nov 2009 07:49:17 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D297821A2A; Mon, 9 Nov 2009 07:49:16 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A12C9219B8; Mon, 9 Nov 2009 07:49:15 +0200 (EET) Message-ID: <4AF7AD5A.3010305@ericsson.com> Date: Mon, 09 Nov 2009 07:49:14 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Nov 2009 05:49:17.0091 (UTC) FILETIME=[5FEF8F30:01CA6100] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:48:55 -0000 Hi Martin, good point, I think we can relax it to optional . /Sal Thomson, Martin wrote: > Hi Sal, > > Thanks for the pointer. > > Regarding section 8.3, which addresses the requirement in question: > > I'm not sure why you would make the Event header mandatory in the 2xx responses. Optional seems to make more sense to me. Existing implementations don't do this, after all. > > >> -----Original Message----- >> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] >> Sent: Monday, 9 November 2009 2:25 PM >> To: Thomson, Martin >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements >> >> Hi Martin, >> >> an updated version of the event-rate-control draft was submitted two >> days after the IETF76 deadline, >> for this reason it is not yet on the I-D repository, however it will be >> available soon >> >> for the time being you can fetch a copy from >> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt >> >> /Sal >> >> Thomson, Martin wrote: >> >>> Is the -00 version the latest issue of this draft? I expected a -01 >>> >> and so was under the impression that we were discussion changes already >> made. >> >>> The following two minor changes were requested out of the GEOPRIV use >>> >> cases: >> >>> - note that the rate control parameters can be updated in response >>> >> messages (i.e. the 200 response to an initial NOTIFY); the notifier >> then indicates the agreed (and possibility modified) values in >> subsequent NOTIFYs >> >>> - note that rate control parameters can be changed at any time by >>> >> the notifier, based on policy- or implementation-determined constraints >> >>> This is what we discussed in the meeting. >>> >>> I think that the second one is OK in the version -00 draft. I could >>> >> not find anywhere that mentioned updating event parameters in a >> response message. >> >>> --Martin >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> > > From tianlinyi@huawei.com Sun Nov 8 22:22:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330163A6AF4 for ; Sun, 8 Nov 2009 22:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id regjwhMqqE7w for ; Sun, 8 Nov 2009 22:22:35 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 753993A6867 for ; Sun, 8 Nov 2009 22:22:34 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST005KTWE1E3@szxga02-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 14:22:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KST00AYXWE18U@szxga02-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 14:22:49 +0800 (CST) Received: from t34932n ([10.168.86.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KST00AR0WE1M6@szxml04-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 14:22:49 +0800 (CST) Date: Mon, 09 Nov 2009 14:22:48 +0800 From: Linyi TIAN In-reply-to: To: 'Christer Holmberg' , sipcore@ietf.org Message-id: <014c01ca6105$0f51a4a0$2df4ede0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yU6O18CWUxHWX82W7VyO2Q)" Content-language: zh-cn Thread-index: Acpg6zrsK1B9zdQfShCPxuE52V05UQAGMgxg References: Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:22:40 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_yU6O18CWUxHWX82W7VyO2Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Does it mean the following case: 1. Initial set : Info package A and B 2. During the session we can use Re-invite/Update to change it to package A only We can use Update/Re-invite to remove the willingness to receive for a particular Info Package which was required before, right? It is not clear to me what "UA wishes to only receive INFO request for one of the Packages" means. ---------------------------------------------------------------------------- ---------------------------------------- 3.2 User Agent Behavior If a UA indicates multiple Info Packages, which provide similar functionality, it is not possible to indicate a priority order of the Info Packages, or that that the UA wishes to only receive INFO request for one of the Info Packages. It is up to the application logic associated with the Info Packages, and specific Info Package descriptions to describe application behavior in such cases. So the new set does not necessary means addition and it may also means removal, right? ---------------------------------------------------------------------------- ---------------------------------------- Section 1.1 Introduction A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set during the lifetime of the invite dialog usage. Can these be clarified in the draft? From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Monday, November 09, 2009 11:18 AM To: sipcore@ietf.org Subject: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Hi, Based on the 3pcc issue raised by Paul, at the SIPCORE session we discussed whether we should mandate to include Recv-Info in re-INVITE responses. The outcome of the discussion was that EVERY SIP messages where Recv-Info is allowed MUST contain Recv-Info, NO MATTER if the set of Info Packages has changed or not. Based on the -03pre version of the draft the following messages would be affected: INVITE + 18x + 200 Re-INVITE + 18x + 200 ACK UPDATE + 200 PRACK + 200 That is a change from previous versions of the draft, which says that the Recv-Info header only needs to be inserted if the set of Info Packages changes. So, unless people have issues with that, my intention is to implement the change in the next version of the draft. Regards, Christer --Boundary_(ID_yU6O18CWUxHWX82W7VyO2Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable INFO EVENT @ IETF#76: When to insert Recv-Info header

Does it mean the following case:

1.     Initial set : Info = package A and B

2.     During the session we = can use Re-invite/Update to change it to package A only

We can use Update/Re-invite to remove the willingness to = receive for a particular Info Package which was required before, = right?

 

It is not clear to me what “UA wishes to only = receive INFO request for one of the Packages” means.

----------------------------------------------------------= ----------------------------------------------------------

3.2 User Agent Behavior

If a UA indicates multiple Info Packages, which provide = similar

   functionality, it is not possible to = indicate a priority order of the

   Info Packages, or that that the UA wishes to = only receive INFO

   request for one of the Info Packages.  = It is up to the application

   logic associated with the Info Packages, and specific Info Package

   descriptions to describe application = behavior in such cases.

 

So the new set does not necessary means addition and it = may also means removal, right?

----------------------------------------------------------= ----------------------------------------------------------

Section 1.1 Introduction

A UA uses the Recv-Info header field, on a per-dialog = basis, to

   indicate for which Info Packages it is = willing to receive INFO

   requests.  A UA can indicate an initial = set of Info Packages during

   dialog establishment and can indicate a new = set during the lifetime

   of the invite dialog = usage.

 

Can these be clarified in the = draft?

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer = Holmberg
Sent: Monday, November 09, 2009 11:18 AM
To: sipcore@ietf.org
Subject: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info = header

 

 

Hi,

Based on the 3pcc issue raised by Paul, at the SIPCORE session we discussed = whether we should mandate to include Recv-Info in re-INVITE = responses.

The outcome of the discussion was that EVERY SIP messages where Recv-Info is allowed MUST contain Recv-Info, NO MATTER if the set of Info Packages = has changed or not.

Based on the -03pre version of the draft the following messages would be = affected:

INVITE + 18x + 200
Re-INVITE + 18x + 200
ACK
UPDATE + 200
PRACK + 200

That is a change from previous versions of the draft, which says that the = Recv-Info header only needs to be inserted if the set of Info Packages = changes.

So, unless people have issues with that, my intention is to implement the = change in the next version of the draft. =

Regards,

Christer

--Boundary_(ID_yU6O18CWUxHWX82W7VyO2Q)-- From christer.holmberg@ericsson.com Sun Nov 8 22:38:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606A33A68CF for ; Sun, 8 Nov 2009 22:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN8xe8Fxj81Q for ; Sun, 8 Nov 2009 22:38:31 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0F2F23A6889 for ; Sun, 8 Nov 2009 22:38:30 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-b3-4af7b8ff3760 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 49.B3.04191.FF8B7FA4; Mon, 9 Nov 2009 07:38:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:38:25 +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: Mon, 9 Nov 2009 07:38:24 +0100 Message-ID: In-Reply-To: <014c01ca6105$0f51a4a0$2df4ede0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: Acpg6zrsK1B9zdQfShCPxuE52V05UQAGMgxgAAB8yyA= References: <014c01ca6105$0f51a4a0$2df4ede0$@com> From: "Christer Holmberg" To: "Linyi TIAN" , X-OriginalArrivalTime: 09 Nov 2009 06:38:25.0155 (UTC) FILETIME=[3D1E6D30:01CA6107] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:38:32 -0000 Hi,=20 >Does it mean the following case: > >1. Initial set : Info package A and B > >2. During the session we can use Re-invite/Update to change it to package A only No, you can change it to whatever you want. The change is that you will have to indicate A and B during the session even if you don't change it. >We can use Update/Re-invite to remove the willingness to receive for a particular Info Package which was required before,=20 >right? Yes. You can still send Recv-Info:nil >It is not clear to me what "UA wishes to only receive INFO request for one of the Packages" means.=20 It means that the Info Package mechanism does not provide a mechanism where you can say "Here are two packages, but please use only one of them". >So the new set does not necessary means addition and it may also means removal, right? Yes. >----------------------------------------------------------------------- --------------------------------------------- > >Section 1.1 Introduction > >A UA uses the Recv-Info header field, on a per-dialog basis, to >indicate for which Info Packages it is willing to receive INFO >requests. A UA can indicate an initial set of Info Packages during >dialog establishment and can indicate a new set during the lifetime >of the invite dialog usage. > >Can these be clarified in the draft? So, what is it that you want clarified? That one can remove packages from the set? Regards, Christer =20 From christer.holmberg@ericsson.com Sun Nov 8 22:46:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E825E3A6AEF for ; Sun, 8 Nov 2009 22:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La7lIkRRkfan for ; Sun, 8 Nov 2009 22:46:43 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9FCC03A6AF2 for ; Sun, 8 Nov 2009 22:46:42 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-cf-4af7baebd461 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 34.77.24026.BEAB7FA4; Mon, 9 Nov 2009 07:47:07 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 07:45:43 +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: Mon, 9 Nov 2009 07:45:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: Acpg80LKRPxE+7B5RcqYWl5mvQxqzgAAvwzwAARMmAA= References: <4AF79740.8020707@cisco.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Paul Kyzivat" X-OriginalArrivalTime: 09 Nov 2009 06:45:43.0624 (UTC) FILETIME=[42777C80:01CA6108] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:46:44 -0000 Hi, I guess Paul can provide more details, but I am not sure whether the proxy doing the 3pcc would always be able to include Recv-Info in the re-INVITE request. Regards, Christer =20 =20 -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: 9. marraskuuta 2009 7:39 To: Paul Kyzivat; Christer Holmberg Cc: sipcore@ietf.org Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header This works, but it seems overkill to me. Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion. Secondly can I still have more detail (arrow diagram) on the scenario we are trying to solve for 3pcc. I can't see if there is a simple solution if the problem is insufficiently clear. Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, November 09, 2009 4:15 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header >=20 > That works for me, and it is sufficiently simple that everybody should > be able to implement it correctly. :-) >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > >=20 > > Hi, > >=20 > > Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 > > discussed whether we should mandate to include Recv-Info in > re-INVITE > > responses. > >=20 > > The outcome of the discussion was that EVERY SIP messages where=20 > > Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > the set of > > Info Packages has changed or not. > >=20 > > Based on the -03pre version of the draft the following > messages would > > be > > affected: > >=20 > > INVITE + 18x + 200 > > Re-INVITE + 18x + 200 > > ACK > > UPDATE + 200 > > PRACK + 200 > >=20 > > That is a change from previous versions of the draft, which > says that > > the Recv-Info header only needs to be inserted if the set of Info=20 > > Packages changes. > >=20 > > So, unless people have issues with that, my intention is to > implement > > the change in the next version of the draft. > >=20 > > Regards, > >=20 > > Christer > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From krisztian.kiss@nokia.com Sun Nov 8 22:50:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049FA3A68CB for ; Sun, 8 Nov 2009 22:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEhxzam5a+bw for ; Sun, 8 Nov 2009 22:50:38 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A92A13A6882 for ; Sun, 8 Nov 2009 22:50:37 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA96oal3009228; Mon, 9 Nov 2009 08:50:56 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:49:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:49:50 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 9 Nov 2009 07:49:49 +0100 From: To: , Date: Mon, 9 Nov 2009 07:49:48 +0100 Thread-Topic: [sipcore] Event rate control and GEOPRIV requirements Thread-Index: AcphAGYaGdq7Oj2RSviJrBA5EKKkdAAAvIGw Message-ID: References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> <4AF7AD5A.3010305@ericsson.com> In-Reply-To: <4AF7AD5A.3010305@ericsson.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-OriginalArrivalTime: 09 Nov 2009 06:49:50.0256 (UTC) FILETIME=[D5788B00:01CA6108] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:50:40 -0000 Hi, Making it optional may create a conflict with the following statement: A subscriber that wishes to remove the minimum rate control from notifications MUST indicate so by not including a "max-interval" Event header field parameter in a subsequent SUBSCRIBE request or a 200-class response to the NOTIFY request. An Event header field without the "max-interval" parameter means that the s= ubscriber is deleting the "max-interval" feature from notifications. Should= we now allocate a special meaning for the case when no Event header field = exists in the 2xx response to the NOTIFY? Does that mean the "max-interval"= parameter is not touched from the previous value? Or something else? I'd p= refer the same behavior as for the SUBSCRIBE request, i.e. the "max-interva= l" parameter is always present reflecting the current value and the lack of= the parameter means that the feature is deleted from notifications. Existing implementations do not support Event header field in the 2xx respo= nses to NOTIFY, however new implementations adding the rate-control feature= to notifications will support adding the rate control parameters to the Ev= ent header field in SUBSCRIBE and 2xx to NOTIFY as well as the Subscription= -State header field in NOTIFYs. As RFC 3265 did not define the Event header= field to 2xx to NOTIFY, draft-ietf-sipcore-event-rate-control has to do th= is in order to have a placeholder for the new parameter. Cheers, Krisztian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Salvatore Loreto Sent: Sunday, November 08, 2009 9:49 PM To: Thomson, Martin Cc: sipcore@ietf.org Subject: Re: [sipcore] Event rate control and GEOPRIV requirements Hi Martin, good point, I think we can relax it to optional . /Sal Thomson, Martin wrote: > Hi Sal, > > Thanks for the pointer. > > Regarding section 8.3, which addresses the requirement in question: > > I'm not sure why you would make the Event header mandatory in the 2xx res= ponses. Optional seems to make more sense to me. Existing implementations= don't do this, after all. > > =20 >> -----Original Message----- >> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] >> Sent: Monday, 9 November 2009 2:25 PM >> To: Thomson, Martin >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements >> >> Hi Martin, >> >> an updated version of the event-rate-control draft was submitted two=20 >> days after the IETF76 deadline, for this reason it is not yet on the=20 >> I-D repository, however it will be available soon >> >> for the time being you can fetch a copy from=20 >> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.tx >> t >> >> /Sal >> >> Thomson, Martin wrote: >> =20 >>> Is the -00 version the latest issue of this draft? I expected a -01 >>> =20 >> and so was under the impression that we were discussion changes=20 >> already made. >> =20 >>> The following two minor changes were requested out of the GEOPRIV=20 >>> use >>> =20 >> cases: >> =20 >>> - note that the rate control parameters can be updated in response >>> =20 >> messages (i.e. the 200 response to an initial NOTIFY); the notifier=20 >> then indicates the agreed (and possibility modified) values in=20 >> subsequent NOTIFYs >> =20 >>> - note that rate control parameters can be changed at any time by >>> =20 >> the notifier, based on policy- or implementation-determined=20 >> constraints >> =20 >>> This is what we discussed in the meeting. >>> >>> I think that the second one is OK in the version -00 draft. I could >>> =20 >> not find anywhere that mentioned updating event parameters in a=20 >> response message. >> =20 >>> --Martin >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 > > =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Sun Nov 8 22:57:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907D63A6915 for ; Sun, 8 Nov 2009 22:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyr-Vu7bT2Wa for ; Sun, 8 Nov 2009 22:57:44 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 475783A69A5 for ; Sun, 8 Nov 2009 22:57:44 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:58190 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S5035882AbZKIG6K (ORCPT ); Mon, 9 Nov 2009 00:58:10 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 9 Nov 2009 00:58:10 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 9 Nov 2009 14:58:07 +0800 From: "Thomson, Martin" To: "krisztian.kiss@nokia.com" , "salvatore.loreto@ericsson.com" Date: Mon, 9 Nov 2009 14:58:36 +0800 Thread-Topic: [sipcore] Event rate control and GEOPRIV requirements Thread-Index: AcphAGYaGdq7Oj2RSviJrBA5EKKkdAAAvIGwAAGE3IA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2E4E97@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0F2E4DDB@SISPE7MB1.commscope.com> <4AF7A7B7.8050806@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F2E4E3D@SISPE7MB1.commscope.com> <4AF7AD5A.3010305@ericsson.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Event rate control and GEOPRIV requirements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:57:45 -0000 SSBkb24ndCB0aGluayB0aGF0IHRoZXJlIGlzIGEgY29uZmxpY3QuDQoNCklmIHRoZSBzdWJzY3Jp YmVyIHdpc2hlcyB0byBjaGFuZ2UgZGV0YWlscywgdGhlbiB0aGV5IGNhbiBwcm92aWRlIHRoZSBo ZWFkZXIuICBJZiB0aGV5IGRvIG5vdCBwcm92aWRlIHRoZSBoZWFkZXIgLSBhcyBpcyB0aGUgZXhp c3RpbmcgYmVoYXZpb3VyIC0gdGhlIHZhbHVlcyBkbyBub3QgY2hhbmdlLg0KDQpPZiBjb3Vyc2Us IGlmIHRoZSBfaGVhZGVyXyBpcyBwcmVzZW50LCB0aGVuIHRoZSBwYXJhbWV0ZXIgbXVzdCBiZSwg YnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50IHNheXMuDQoNCk1h a2luZyB0aGlzIG1hbmRhdG9yeSBhbHNvIG1ha2VzIGl0IG1hbmRhdG9yeSBmb3IgdGhvc2Ugd2hv IGltcGxlbWVudCB0aGlzIGZlYXR1cmUgYnV0IGRvbid0IGludGVuZCB0byB1c2UgaXQuICBMZXQn cyBub3QgYnJlYWsgZXhpc3RpbmcgZXZlbnQgcGFja2FnZSBpbXBsZW1lbnRhdGlvbnMuDQoNCi0t TWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbToga3Jpc3p0aWFu Lmtpc3NAbm9raWEuY29tIFttYWlsdG86a3Jpc3p0aWFuLmtpc3NAbm9raWEuY29tXQ0KPiBTZW50 OiBNb25kYXksIDkgTm92ZW1iZXIgMjAwOSAzOjUwIFBNDQo+IFRvOiBzYWx2YXRvcmUubG9yZXRv QGVyaWNzc29uLmNvbTsgVGhvbXNvbiwgTWFydGluDQo+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJFOiBbc2lwY29yZV0gRXZlbnQgcmF0ZSBjb250cm9sIGFuZCBHRU9QUklWIHJl cXVpcmVtZW50cw0KPiANCj4gSGksDQo+IA0KPiBNYWtpbmcgaXQgb3B0aW9uYWwgbWF5IGNyZWF0 ZSBhIGNvbmZsaWN0IHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQo+IA0KPiAgICBBIHN1 YnNjcmliZXIgdGhhdCB3aXNoZXMgdG8gcmVtb3ZlIHRoZSBtaW5pbXVtIHJhdGUgY29udHJvbCBm cm9tDQo+ICAgIG5vdGlmaWNhdGlvbnMgTVVTVCBpbmRpY2F0ZSBzbyBieSBub3QgaW5jbHVkaW5n IGEgIm1heC1pbnRlcnZhbCINCj4gICAgRXZlbnQgaGVhZGVyIGZpZWxkIHBhcmFtZXRlciBpbiBh IHN1YnNlcXVlbnQgU1VCU0NSSUJFIHJlcXVlc3Qgb3IgYQ0KPiAgICAyMDAtY2xhc3MgcmVzcG9u c2UgdG8gdGhlIE5PVElGWSByZXF1ZXN0Lg0KPiANCj4gQW4gRXZlbnQgaGVhZGVyIGZpZWxkIHdp dGhvdXQgdGhlICJtYXgtaW50ZXJ2YWwiIHBhcmFtZXRlciBtZWFucyB0aGF0DQo+IHRoZSBzdWJz Y3JpYmVyIGlzIGRlbGV0aW5nIHRoZSAibWF4LWludGVydmFsIiBmZWF0dXJlIGZyb20NCj4gbm90 aWZpY2F0aW9ucy4gU2hvdWxkIHdlIG5vdyBhbGxvY2F0ZSBhIHNwZWNpYWwgbWVhbmluZyBmb3Ig dGhlIGNhc2UNCj4gd2hlbiBubyBFdmVudCBoZWFkZXIgZmllbGQgZXhpc3RzIGluIHRoZSAyeHgg cmVzcG9uc2UgdG8gdGhlIE5PVElGWT8NCj4gRG9lcyB0aGF0IG1lYW4gdGhlICJtYXgtaW50ZXJ2 YWwiIHBhcmFtZXRlciBpcyBub3QgdG91Y2hlZCBmcm9tIHRoZQ0KPiBwcmV2aW91cyB2YWx1ZT8g T3Igc29tZXRoaW5nIGVsc2U/IEknZCBwcmVmZXIgdGhlIHNhbWUgYmVoYXZpb3IgYXMgZm9yDQo+ IHRoZSBTVUJTQ1JJQkUgcmVxdWVzdCwgaS5lLiB0aGUgIm1heC1pbnRlcnZhbCIgcGFyYW1ldGVy IGlzIGFsd2F5cw0KPiBwcmVzZW50IHJlZmxlY3RpbmcgdGhlIGN1cnJlbnQgdmFsdWUgYW5kIHRo ZSBsYWNrIG9mIHRoZSBwYXJhbWV0ZXINCj4gbWVhbnMgdGhhdCB0aGUgZmVhdHVyZSBpcyBkZWxl dGVkIGZyb20gbm90aWZpY2F0aW9ucy4NCj4gDQo+IEV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBk byBub3Qgc3VwcG9ydCBFdmVudCBoZWFkZXIgZmllbGQgaW4gdGhlIDJ4eA0KPiByZXNwb25zZXMg dG8gTk9USUZZLCBob3dldmVyIG5ldyBpbXBsZW1lbnRhdGlvbnMgYWRkaW5nIHRoZSByYXRlLQ0K PiBjb250cm9sIGZlYXR1cmUgdG8gbm90aWZpY2F0aW9ucyB3aWxsIHN1cHBvcnQgYWRkaW5nIHRo ZSByYXRlIGNvbnRyb2wNCj4gcGFyYW1ldGVycyB0byB0aGUgRXZlbnQgaGVhZGVyIGZpZWxkIGlu IFNVQlNDUklCRSBhbmQgMnh4IHRvIE5PVElGWSBhcw0KPiB3ZWxsIGFzIHRoZSBTdWJzY3JpcHRp b24tU3RhdGUgaGVhZGVyIGZpZWxkIGluIE5PVElGWXMuIEFzIFJGQyAzMjY1IGRpZA0KPiBub3Qg ZGVmaW5lIHRoZSBFdmVudCBoZWFkZXIgZmllbGQgdG8gMnh4IHRvIE5PVElGWSwgZHJhZnQtaWV0 Zi1zaXBjb3JlLQ0KPiBldmVudC1yYXRlLWNvbnRyb2wgaGFzIHRvIGRvIHRoaXMgaW4gb3JkZXIg dG8gaGF2ZSBhIHBsYWNlaG9sZGVyIGZvcg0KPiB0aGUgbmV3IHBhcmFtZXRlci4NCj4gDQo+IENo ZWVycywNCj4gS3Jpc3p0aWFuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBleHQgU2FsdmF0b3JlIExvcmV0bw0KPiBTZW50OiBTdW5k YXksIE5vdmVtYmVyIDA4LCAyMDA5IDk6NDkgUE0NCj4gVG86IFRob21zb24sIE1hcnRpbg0KPiBD Yzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEV2ZW50IHJhdGUg Y29udHJvbCBhbmQgR0VPUFJJViByZXF1aXJlbWVudHMNCj4gDQo+IEhpIE1hcnRpbiwNCj4gDQo+ IGdvb2QgcG9pbnQsIEkgdGhpbmsgd2UgY2FuIHJlbGF4IGl0IHRvIG9wdGlvbmFsIC4NCj4gDQo+ IC9TYWwNCj4gDQo+IFRob21zb24sIE1hcnRpbiB3cm90ZToNCj4gPiBIaSBTYWwsDQo+ID4NCj4g PiBUaGFua3MgZm9yIHRoZSBwb2ludGVyLg0KPiA+DQo+ID4gUmVnYXJkaW5nIHNlY3Rpb24gOC4z LCB3aGljaCBhZGRyZXNzZXMgdGhlIHJlcXVpcmVtZW50IGluIHF1ZXN0aW9uOg0KPiA+DQo+ID4g SSdtIG5vdCBzdXJlIHdoeSB5b3Ugd291bGQgbWFrZSB0aGUgRXZlbnQgaGVhZGVyIG1hbmRhdG9y eSBpbiB0aGUgMnh4DQo+IHJlc3BvbnNlcy4gIE9wdGlvbmFsIHNlZW1zIHRvIG1ha2UgbW9yZSBz ZW5zZSB0byBtZS4gIEV4aXN0aW5nDQo+IGltcGxlbWVudGF0aW9ucyBkb24ndCBkbyB0aGlzLCBh ZnRlciBhbGwuDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiBGcm9tOiBTYWx2YXRvcmUgTG9yZXRvIFttYWlsdG86c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nv bi5jb21dDQo+ID4+IFNlbnQ6IE1vbmRheSwgOSBOb3ZlbWJlciAyMDA5IDI6MjUgUE0NCj4gPj4g VG86IFRob21zb24sIE1hcnRpbg0KPiA+PiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIEV2ZW50IHJhdGUgY29udHJvbCBhbmQgR0VPUFJJViByZXF1aXJl bWVudHMNCj4gPj4NCj4gPj4gSGkgTWFydGluLA0KPiA+Pg0KPiA+PiBhbiB1cGRhdGVkIHZlcnNp b24gb2YgdGhlIGV2ZW50LXJhdGUtY29udHJvbCBkcmFmdCB3YXMgc3VibWl0dGVkIHR3bw0KPiA+ PiBkYXlzIGFmdGVyIHRoZSBJRVRGNzYgZGVhZGxpbmUsIGZvciB0aGlzIHJlYXNvbiBpdCBpcyBu b3QgeWV0IG9uIHRoZQ0KPiA+PiBJLUQgcmVwb3NpdG9yeSwgaG93ZXZlciBpdCB3aWxsIGJlIGF2 YWlsYWJsZSBzb29uDQo+ID4+DQo+ID4+IGZvciB0aGUgdGltZSBiZWluZyB5b3UgY2FuIGZldGNo IGEgY29weSBmcm9tDQo+ID4+IGh0dHA6Ly9rcmtpc3MubGV0b2x0LmluZm8vZHJhZnQtaWV0Zi1z aXBjb3JlLWV2ZW50LXJhdGUtY29udHJvbC0NCj4gMDEudHgNCj4gPj4gdA0KPiA+Pg0KPiA+PiAv U2FsDQo+ID4+DQo+ID4+IFRob21zb24sIE1hcnRpbiB3cm90ZToNCj4gPj4NCj4gPj4+IElzIHRo ZSAtMDAgdmVyc2lvbiB0aGUgbGF0ZXN0IGlzc3VlIG9mIHRoaXMgZHJhZnQ/ICBJIGV4cGVjdGVk IGEgLQ0KPiAwMQ0KPiA+Pj4NCj4gPj4gYW5kIHNvIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0 aGF0IHdlIHdlcmUgZGlzY3Vzc2lvbiBjaGFuZ2VzDQo+ID4+IGFscmVhZHkgbWFkZS4NCj4gPj4N Cj4gPj4+IFRoZSBmb2xsb3dpbmcgdHdvIG1pbm9yIGNoYW5nZXMgd2VyZSByZXF1ZXN0ZWQgb3V0 IG9mIHRoZSBHRU9QUklWDQo+ID4+PiB1c2UNCj4gPj4+DQo+ID4+IGNhc2VzOg0KPiA+Pg0KPiA+ Pj4gIC0gbm90ZSB0aGF0IHRoZSByYXRlIGNvbnRyb2wgcGFyYW1ldGVycyBjYW4gYmUgdXBkYXRl ZCBpbiByZXNwb25zZQ0KPiA+Pj4NCj4gPj4gbWVzc2FnZXMgKGkuZS4gdGhlIDIwMCByZXNwb25z ZSB0byBhbiBpbml0aWFsIE5PVElGWSk7IHRoZSBub3RpZmllcg0KPiA+PiB0aGVuIGluZGljYXRl cyB0aGUgYWdyZWVkIChhbmQgcG9zc2liaWxpdHkgbW9kaWZpZWQpIHZhbHVlcyBpbg0KPiA+PiBz dWJzZXF1ZW50IE5PVElGWXMNCj4gPj4NCj4gPj4+ICAtIG5vdGUgdGhhdCByYXRlIGNvbnRyb2wg cGFyYW1ldGVycyBjYW4gYmUgY2hhbmdlZCBhdCBhbnkgdGltZSBieQ0KPiA+Pj4NCj4gPj4gdGhl IG5vdGlmaWVyLCBiYXNlZCBvbiBwb2xpY3ktIG9yIGltcGxlbWVudGF0aW9uLWRldGVybWluZWQN Cj4gPj4gY29uc3RyYWludHMNCj4gPj4NCj4gPj4+IFRoaXMgaXMgd2hhdCB3ZSBkaXNjdXNzZWQg aW4gdGhlIG1lZXRpbmcuDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB0aGF0IHRoZSBzZWNvbmQgb25l IGlzIE9LIGluIHRoZSB2ZXJzaW9uIC0wMCBkcmFmdC4gIEkNCj4gY291bGQNCj4gPj4+DQo+ID4+ IG5vdCBmaW5kIGFueXdoZXJlIHRoYXQgbWVudGlvbmVkIHVwZGF0aW5nIGV2ZW50IHBhcmFtZXRl cnMgaW4gYQ0KPiA+PiByZXNwb25zZSBtZXNzYWdlLg0KPiA+Pg0KPiA+Pj4gLS1NYXJ0aW4NCj4g Pj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4g Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+Pj4N Cj4gPj4+DQo+ID4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From root@core3.amsl.com Sun Nov 8 23:30:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A81763A688C; Sun, 8 Nov 2009 23:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109073001.A81763A688C@core3.amsl.com> Date: Sun, 8 Nov 2009 23:30:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-event-rate-control-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:30:01 -0000 --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 Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, K. Kiss, S. Loreto Filename : draft-ietf-sipcore-event-rate-control-01.txt Pages : 24 Date : 2009-11-8 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-event-rate-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-8232113.I-D@ietf.org> --NextPart-- From jbemmel@zonnet.nl Sun Nov 8 23:36:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8767128C1B9 for ; Sun, 8 Nov 2009 23:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3EALWtP2Dq0 for ; Sun, 8 Nov 2009 23:36:45 -0800 (PST) Received: from smtp4.versatel.nl (smtp4.versatel.nl [62.58.50.91]) by core3.amsl.com (Postfix) with ESMTP id 5E17128C1B7 for ; Sun, 8 Nov 2009 23:36:45 -0800 (PST) Received: (qmail 24185 invoked by uid 0); 9 Nov 2009 07:37:08 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Nov 2009 07:37:08 -0000 Message-ID: <4AF7C69D.6040804@zonnet.nl> Date: Mon, 09 Nov 2009 08:37:01 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4AF79740.8020707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:36:46 -0000 I also think it's overkill. Furthermore, I don't see a real world use case for changing the set of supported INFO packages mid-dialog. Surely the UAS can simply reply with a 403 response when it receives an INFO request which it doesn't want to process anymore? To me, INFO packages should be like the Dialog's route set: learn the supported set from the initial INVITE and 1xx-2xx responses, after that don't change it anymore Regards, Jeroen PS The usage of 'nil' to denote no supported packages is not consistent with conventions used today, e.g. for Supported (suggest to simply use an empty value instead) DRAGE, Keith (Keith) wrote: > This works, but it seems overkill to me. > > Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion. > > Secondly can I still have more detail (arrow diagram) on the scenario we are trying to solve for 3pcc. I can't see if there is a simple solution if the problem is insufficiently clear. > > Keith > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, November 09, 2009 4:15 AM >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info header >> >> That works for me, and it is sufficiently simple that >> everybody should be able to implement it correctly. :-) >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >> >>> Hi, >>> >>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>> discussed whether we should mandate to include Recv-Info in >>> >> re-INVITE >> >>> responses. >>> >>> The outcome of the discussion was that EVERY SIP messages where >>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>> >> the set of >> >>> Info Packages has changed or not. >>> >>> Based on the -03pre version of the draft the following >>> >> messages would >> >>> be >>> affected: >>> >>> INVITE + 18x + 200 >>> Re-INVITE + 18x + 200 >>> ACK >>> UPDATE + 200 >>> PRACK + 200 >>> >>> That is a change from previous versions of the draft, which >>> >> says that >> >>> the Recv-Info header only needs to be inserted if the set of Info >>> Packages changes. >>> >>> So, unless people have issues with that, my intention is to >>> >> implement >> >>> the change in the next version of the draft. >>> >>> Regards, >>> >>> Christer >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Sun Nov 8 23:38:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB3F28C1BD for ; Sun, 8 Nov 2009 23:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBUtYn8ISWTq for ; Sun, 8 Nov 2009 23:38:32 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 76D6A28C129 for ; Sun, 8 Nov 2009 23:38:32 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-ee-4af7c711b662 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 92.1B.24026.117C7FA4; Mon, 9 Nov 2009 08:38:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:37:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA610F.8B5ED555" Date: Mon, 9 Nov 2009 08:37:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO EVENT @ IETF#76: What is required to register an Info Package thread-index: AcphD4tERyKue+hcTBG6hDyZCr6kKg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 09 Nov 2009 07:37:52.0530 (UTC) FILETIME=[8B70A720:01CA610F] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:38:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA610F.8B5ED555 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, At the SIPCORE session the issue about what is required to register an Info Package. The outcome was that a specification (not necessarily not an IETF document) is needed. Regards, Christer ------_=_NextPart_001_01CA610F.8B5ED555 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable INFO EVENT @ IETF#76: What is required to register an Info = Package

Hi,

At the SIPCORE session the issue about = what is required to register an Info Package.

The outcome was that a specification = (not necessarily not an IETF document) is needed.

Regards,

Christer

------_=_NextPart_001_01CA610F.8B5ED555-- From christer.holmberg@ericsson.com Sun Nov 8 23:56:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B7B28C129 for ; Sun, 8 Nov 2009 23:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYfP43JHRGMe for ; Sun, 8 Nov 2009 23:56:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0555A3A69AD for ; Sun, 8 Nov 2009 23:56:15 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b8-4af7cb3863e6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 31.BC.24026.83BC7FA4; Mon, 9 Nov 2009 08:56:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:55:17 +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: Mon, 9 Nov 2009 08:55:16 +0100 Message-ID: In-Reply-To: <4AF7C69D.6040804@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphD3Kg2+4rKJejRNa+AXr0ywC4RgAAIx8Q References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 09 Nov 2009 07:55:17.0452 (UTC) FILETIME=[FA4318C0:01CA6111] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:56:17 -0000 Hi,=20 >I also think it's overkill. Furthermore, I don't see a real world use case for changing the set of supported INFO=20 >packages mid-dialog. Surely the UAS can simply reply with a 403 response when it receives an INFO request which it=20 >doesn't want to process anymore? > >To me, INFO packages should be like the Dialog's route set: learn the supported set from the initial INVITE and 1xx-2xx=20 >responses, after that don't change it anymore I think Adam made the same comment in the SIPCORE session. Personally I think there could be cases where one wants to add a package during a dialog. For example, assume I call you. Then, during the dialog we decide to start using application X which uses an Info Package, so our phones send Recv-Info:X to each other. Application X may not even be running when we initiate the dialog. However, if we are going to require the header in a lot of messages, maybe we should remove PRACK from the list of allowed messages. Would people have problems with that? But, I would like Paul to comment whether mandating the header in every message would actually solve his 3pcc use-case. >PS The usage of 'nil' to denote no supported packages is not consistent with conventions used today, e.g. for Supported=20 >(suggest to simply use an empty value instead) I think there was some WGLC comment(s) asking about the same thing. Personally I have no problem to use an empty header instead of 'nil'. However, I want to ensure that nobody objects to such change before I implement it. Regards, Christer DRAGE, Keith (Keith) wrote: > This works, but it seems overkill to me. > > Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion. > > Secondly can I still have more detail (arrow diagram) on the scenario we are trying to solve for 3pcc. I can't see if there is a simple solution if the problem is insufficiently clear. > > Keith > > =20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, November 09, 2009 4:15 AM >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> That works for me, and it is sufficiently simple that everybody=20 >> should be able to implement it correctly. :-) >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >> =20 >>> Hi, >>> >>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>> discussed whether we should mandate to include Recv-Info in >>> =20 >> re-INVITE >> =20 >>> responses. >>> >>> The outcome of the discussion was that EVERY SIP messages where=20 >>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>> =20 >> the set of >> =20 >>> Info Packages has changed or not. >>> >>> Based on the -03pre version of the draft the following >>> =20 >> messages would >> =20 >>> be >>> affected: >>> >>> INVITE + 18x + 200 >>> Re-INVITE + 18x + 200 >>> ACK >>> UPDATE + 200 >>> PRACK + 200 >>> >>> That is a change from previous versions of the draft, which >>> =20 >> says that >> =20 >>> the Recv-Info header only needs to be inserted if the set of Info=20 >>> Packages changes. >>> >>> So, unless people have issues with that, my intention is to >>> =20 >> implement >> =20 >>> the change in the next version of the draft. >>> >>> Regards, >>> >>> Christer >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From jbemmel@zonnet.nl Mon Nov 9 00:07:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEC63A6A0F for ; Mon, 9 Nov 2009 00:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srpwL1yM4fLR for ; Mon, 9 Nov 2009 00:07:29 -0800 (PST) Received: from smtp5.versatel.nl (smtp5.versatel.nl [62.58.50.96]) by core3.amsl.com (Postfix) with ESMTP id F02CC3A69F0 for ; Mon, 9 Nov 2009 00:07:28 -0800 (PST) Received: (qmail 24614 invoked by uid 0); 9 Nov 2009 08:07:52 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp5.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Nov 2009 08:07:52 -0000 Message-ID: <4AF7CDD0.308@zonnet.nl> Date: Mon, 09 Nov 2009 09:07:44 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:07:30 -0000 Christer, Given the registration requirement (i.e. there needs to be some sort of spec) the set of INFO packages will be limited. UAs can easily list those packages they support up front. Therefore the "fully dynamic" case you sketch below seems unlikely to me. The only case I could imagine would be in case of long running dialogs, where the software of one of the peers gets upgraded mid-dialog to support some new INFO package. However, also that seems highly unlikely to me. To me, we should keep it simple - "learn INFO packages whenever you learn the Route set for a Dialog" should be simple enough for developers to get right Regards, Jeroen Christer Holmberg wrote: > Hi, > > >> I also think it's overkill. Furthermore, I don't see a real world use >> > case for changing the set of supported INFO > >> packages mid-dialog. Surely the UAS can simply reply with a 403 >> > response when it receives an INFO request which it > >> doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the >> > supported set from the initial INVITE and 1xx-2xx > >> responses, after that don't change it anymore >> > > I think Adam made the same comment in the SIPCORE session. > > Personally I think there could be cases where one wants to add a package > during a dialog. For example, assume I call you. Then, during the dialog > we decide to start using application X which uses an Info Package, so > our phones send Recv-Info:X to each other. Application X may not even be > running when we initiate the dialog. > > However, if we are going to require the header in a lot of messages, > maybe we should remove PRACK from the list of allowed messages. Would > people have problems with that? > > But, I would like Paul to comment whether mandating the header in every > message would actually solve his 3pcc use-case. > > >> PS The usage of 'nil' to denote no supported packages is not consistent >> > with conventions used today, e.g. for Supported > >> (suggest to simply use an empty value instead) >> > > I think there was some WGLC comment(s) asking about the same thing. > Personally I have no problem to use an empty header instead of 'nil'. > However, I want to ensure that nobody objects to such change before I > implement it. > > Regards, > > Christer > > > > > DRAGE, Keith (Keith) wrote: > >> This works, but it seems overkill to me. >> >> Firstly can I ensure that this does not include REGISTER, which could >> > also be understood from the paraphrase of the SIPCORE discussion. > >> Secondly can I still have more detail (arrow diagram) on the scenario >> > we are trying to solve for 3pcc. I can't see if there is a simple > solution if the problem is insufficiently clear. > >> Keith >> >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Monday, November 09, 2009 4:15 AM >>> To: Christer Holmberg >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >>> > > >>> header >>> >>> That works for me, and it is sufficiently simple that everybody >>> should be able to implement it correctly. :-) >>> >>> Thanks, >>> Paul >>> >>> Christer Holmberg wrote: >>> >>> >>>> Hi, >>>> >>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>> discussed whether we should mandate to include Recv-Info in >>>> >>>> >>> re-INVITE >>> >>> >>>> responses. >>>> >>>> The outcome of the discussion was that EVERY SIP messages where >>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>> >>>> >>> the set of >>> >>> >>>> Info Packages has changed or not. >>>> >>>> Based on the -03pre version of the draft the following >>>> >>>> >>> messages would >>> >>> >>>> be >>>> affected: >>>> >>>> INVITE + 18x + 200 >>>> Re-INVITE + 18x + 200 >>>> ACK >>>> UPDATE + 200 >>>> PRACK + 200 >>>> >>>> That is a change from previous versions of the draft, which >>>> >>>> >>> says that >>> >>> >>>> the Recv-Info header only needs to be inserted if the set of Info >>>> Packages changes. >>>> >>>> So, unless people have issues with that, my intention is to >>>> >>>> >>> implement >>> >>> >>>> the change in the next version of the draft. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Mon Nov 9 00:24:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC08F3A687C for ; Mon, 9 Nov 2009 00:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvkkhvMPVXmj for ; Mon, 9 Nov 2009 00:24:25 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2363B3A6B06 for ; Mon, 9 Nov 2009 00:24:24 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-07-4af7d1d11b7f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0F.CB.04191.1D1D7FA4; Mon, 9 Nov 2009 09:24:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 09:24: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: Mon, 9 Nov 2009 09:24:48 +0100 Message-ID: In-Reply-To: <4AF7CDD0.308@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphE793RqrAZcb8S0OfytJIZvPh3QAAHKwQ References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" X-OriginalArrivalTime: 09 Nov 2009 08:24:49.0172 (UTC) FILETIME=[1A4A1D40:01CA6116] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:24:26 -0000 Hi,=20 >Given the registration requirement (i.e. there needs to be some sort of >spec) the set of INFO packages will be limited. UAs can easily list those packages they support up front. Therefore the=20 >"fully dynamic" case you sketch below seems unlikely to me. I guess time will show how many packages get registered, but that is not the main point. I think it is very "un-dynamic" having to list stuff which you don't know that you are going to use in the first place. >The only case I could imagine would be in case of long running dialogs, where the software of one of the peers gets=20 >upgraded mid-dialog to support some new INFO package. However, also that seems highly unlikely to me. Well, maybe there in the not-so-distant future will be some kind of integrated web applications where you can "click on a link" to add an application to an ongoing dialog. I don't think we should prevent such things. Likewise, you would not always negotiate video codecs when you establish a call, even if you support video. You could add them when you actually decide to use them. >To me, we should keep it simple - "learn INFO# packages whenever you learn the Route set for a Dialog" should be simple=20 >enough for developers to get right One step to make it easier would be to further restrict the messages where it is allowed, for example by removing PRACK. I don't think that allowing mid-dialog changes makes things complicated. However, since 3pcc seems to be the only reason we would do the include-it-everywhere, maybe we should only mandate it re-INVITEs. Regards, Christer Christer Holmberg wrote: > Hi, > > =20 >> I also think it's overkill. Furthermore, I don't see a real world use >> =20 > case for changing the set of supported INFO > =20 >> packages mid-dialog. Surely the UAS can simply reply with a 403 >> =20 > response when it receives an INFO request which it > =20 >> doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the >> =20 > supported set from the initial INVITE and 1xx-2xx > =20 >> responses, after that don't change it anymore >> =20 > > I think Adam made the same comment in the SIPCORE session. > > Personally I think there could be cases where one wants to add a=20 > package during a dialog. For example, assume I call you. Then, during=20 > the dialog we decide to start using application X which uses an Info=20 > Package, so our phones send Recv-Info:X to each other. Application X=20 > may not even be running when we initiate the dialog. > > However, if we are going to require the header in a lot of messages,=20 > maybe we should remove PRACK from the list of allowed messages. Would=20 > people have problems with that? > > But, I would like Paul to comment whether mandating the header in=20 > every message would actually solve his 3pcc use-case. > > =20 >> PS The usage of 'nil' to denote no supported packages is not=20 >> consistent >> =20 > with conventions used today, e.g. for Supported > =20 >> (suggest to simply use an empty value instead) >> =20 > > I think there was some WGLC comment(s) asking about the same thing. > Personally I have no problem to use an empty header instead of 'nil'. > However, I want to ensure that nobody objects to such change before I=20 > implement it. > > Regards, > > Christer > > > > > DRAGE, Keith (Keith) wrote: > =20 >> This works, but it seems overkill to me. >> >> Firstly can I ensure that this does not include REGISTER, which could >> =20 > also be understood from the paraphrase of the SIPCORE discussion. > =20 >> Secondly can I still have more detail (arrow diagram) on the scenario >> =20 > we are trying to solve for 3pcc. I can't see if there is a simple=20 > solution if the problem is insufficiently clear. > =20 >> Keith >> >> =20 >> =20 >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Monday, November 09, 2009 4:15 AM >>> To: Christer Holmberg >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>> Recv-Info >>> =20 > > =20 >>> header >>> >>> That works for me, and it is sufficiently simple that everybody=20 >>> should be able to implement it correctly. :-) >>> >>> Thanks, >>> Paul >>> >>> Christer Holmberg wrote: >>> =20 >>> =20 >>>> Hi, >>>> >>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>>> discussed whether we should mandate to include Recv-Info in >>>> =20 >>>> =20 >>> re-INVITE >>> =20 >>> =20 >>>> responses. >>>> >>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>> =20 >>>> =20 >>> the set of >>> =20 >>> =20 >>>> Info Packages has changed or not. >>>> >>>> Based on the -03pre version of the draft the following >>>> =20 >>>> =20 >>> messages would >>> =20 >>> =20 >>>> be >>>> affected: >>>> >>>> INVITE + 18x + 200 >>>> Re-INVITE + 18x + 200 >>>> ACK >>>> UPDATE + 200 >>>> PRACK + 200 >>>> >>>> That is a change from previous versions of the draft, which >>>> =20 >>>> =20 >>> says that >>> =20 >>> =20 >>>> the Recv-Info header only needs to be inserted if the set of Info=20 >>>> Packages changes. >>>> >>>> So, unless people have issues with that, my intention is to >>>> =20 >>>> =20 >>> implement >>> =20 >>> =20 >>>> the change in the next version of the draft. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> =20 >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> =20 >> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From kpfleming@digium.com Mon Nov 9 00:30:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83343A68D3 for ; Mon, 9 Nov 2009 00:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.352 X-Spam-Level: X-Spam-Status: No, score=-105.352 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk+nr9Gn307H for ; Mon, 9 Nov 2009 00:30:29 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id C70243A67A4 for ; Mon, 9 Nov 2009 00:30:29 -0800 (PST) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1N7PeJ-0001k5-DV for sipcore@ietf.org; Mon, 09 Nov 2009 02:30:55 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 60FBCDFC828 for ; Mon, 9 Nov 2009 02:30:55 -0600 (CST) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLPhYRJITPTY for ; Mon, 9 Nov 2009 02:30:55 -0600 (CST) Received: from [133.93.144.178] (host-144-178.meeting.ietf.org [133.93.144.178]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 86354DFC827 for ; Mon, 9 Nov 2009 02:30:54 -0600 (CST) Message-ID: <4AF7D33C.4010906@digium.com> Date: Mon, 09 Nov 2009 17:30:52 +0900 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: sipcore@ietf.org References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:30:31 -0000 Christer Holmberg wrote: > Well, maybe there in the not-so-distant future will be some kind of > integrated web applications where you can "click on a link" to add an > application to an ongoing dialog. I don't think we should prevent such > things. I don't think is very far off at all; many hardphones from various manufacturers are already supporting additional applications, and it's completely conceivable that a user of the phone might press a button to activate an application during an existing call. It would have been inappropriate for the phone to have offered to receive the related INFO packages during the call setup, but once the application is running they should be accepted (and in fact the act of starting the application may directly result in a re-INVITE for no other purpose than to update the Recv-Info package list the phone will accept). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From tianlinyi@huawei.com Mon Nov 9 00:42:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9283A68B9 for ; Mon, 9 Nov 2009 00:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu7nxebae5uB for ; Mon, 9 Nov 2009 00:42:15 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C933028C1D3 for ; Mon, 9 Nov 2009 00:42:14 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSU0061W2UPIK@szxga03-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 16:42:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSU005QP2UPM4@szxga03-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 16:42:25 +0800 (CST) Received: from t34932n ([10.168.86.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSU00LVZ2UOQK@szxml04-in.huawei.com> for sipcore@ietf.org; Mon, 09 Nov 2009 16:42:25 +0800 (CST) Date: Mon, 09 Nov 2009 16:42:24 +0800 From: Linyi TIAN In-reply-to: <4AF7C69D.6040804@zonnet.nl> To: 'Jeroen van Bemmel' , "'DRAGE, Keith (Keith)'" Message-id: <01ba01ca6118$8f995320$aecbf960$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcphD7Ong2Ae3J/QR4O/+Smn4lWD9QACIcYQ References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:42:16 -0000 This looks more reasonable and simple. If we don't see real use cases for changing set during the dialog we'd better not have a technical solution for it. Or even there is limited use case, it is no harm to use status code to ignore the INFO. This will reduce the protocol impact and simply the implementation. So for the time being I support Jeroen's approach unless something new is introduced. Cheers, Linyi > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of > Jeroen van Bemmel > Sent: Monday, November 09, 2009 3:37 PM > To: DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header > > I also think it's overkill. Furthermore, I don't see a real world use > case for changing the set of supported INFO packages mid-dialog. Surely > the UAS can simply reply with a 403 response when it receives an INFO > request which it doesn't want to process anymore? > > To me, INFO packages should be like the Dialog's route set: learn the > supported set from the initial INVITE and 1xx-2xx responses, after that > don't change it anymore > > Regards, > Jeroen > > PS The usage of 'nil' to denote no supported packages is not consistent > with conventions used today, e.g. for Supported (suggest to simply use > an empty value instead) > > DRAGE, Keith (Keith) wrote: > > This works, but it seems overkill to me. > > > > Firstly can I ensure that this does not include REGISTER, which could also be > understood from the paraphrase of the SIPCORE discussion. > > > > Secondly can I still have more detail (arrow diagram) on the scenario we are trying > to solve for 3pcc. I can't see if there is a simple solution if the problem is > insufficiently clear. > > > > Keith > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Monday, November 09, 2009 4:15 AM > >> To: Christer Holmberg > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert > >> Recv-Info header > >> > >> That works for me, and it is sufficiently simple that > >> everybody should be able to implement it correctly. :-) > >> > >> Thanks, > >> Paul > >> > >> Christer Holmberg wrote: > >> > >>> Hi, > >>> > >>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we > >>> discussed whether we should mandate to include Recv-Info in > >>> > >> re-INVITE > >> > >>> responses. > >>> > >>> The outcome of the discussion was that EVERY SIP messages where > >>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>> > >> the set of > >> > >>> Info Packages has changed or not. > >>> > >>> Based on the -03pre version of the draft the following > >>> > >> messages would > >> > >>> be > >>> affected: > >>> > >>> INVITE + 18x + 200 > >>> Re-INVITE + 18x + 200 > >>> ACK > >>> UPDATE + 200 > >>> PRACK + 200 > >>> > >>> That is a change from previous versions of the draft, which > >>> > >> says that > >> > >>> the Recv-Info header only needs to be inserted if the set of Info > >>> Packages changes. > >>> > >>> So, unless people have issues with that, my intention is to > >>> > >> implement > >> > >>> the change in the next version of the draft. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Mon Nov 9 01:17:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E41328C1CF for ; Mon, 9 Nov 2009 01:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I+SqgRJXAm3 for ; Mon, 9 Nov 2009 01:17:36 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 473E428C1CC for ; Mon, 9 Nov 2009 01:17:36 -0800 (PST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA99Hv4p021766; Mon, 9 Nov 2009 10:17:57 +0100 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nA99HvWF032367; Mon, 9 Nov 2009 10:17:57 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Mon, 9 Nov 2009 10:17:56 +0100 From: "Elwell, John" To: Christer Holmberg , Jeroen van Bemmel , "DRAGE, Keith (Keith)" Date: Mon, 9 Nov 2009 10:17:56 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphD3Kg2+4rKJejRNa+AXr0ywC4RgAAIx8QAANULfA= Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3541@DEMCHP99E35MSX.ww902.siemens.net> References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:17:37 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 09 November 2009 07:55 > To: Jeroen van Bemmel; DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 >=20 > Hi,=20 >=20 > >I also think it's overkill. Furthermore, I don't see a real world use > case for changing the set of supported INFO=20 > >packages mid-dialog. Surely the UAS can simply reply with a 403 > response when it receives an INFO request which it=20 > >doesn't want to process anymore? > > > >To me, INFO packages should be like the Dialog's route set: learn the > supported set from the initial INVITE and 1xx-2xx=20 > >responses, after that don't change it anymore >=20 > I think Adam made the same comment in the SIPCORE session. >=20 > Personally I think there could be cases where one wants to=20 > add a package > during a dialog. For example, assume I call you. Then, during=20 > the dialog > we decide to start using application X which uses an Info Package, so > our phones send Recv-Info:X to each other. Application X may=20 > not even be > running when we initiate the dialog. >=20 > However, if we are going to require the header in a lot of messages, > maybe we should remove PRACK from the list of allowed messages. Would > people have problems with that? >=20 > But, I would like Paul to comment whether mandating the=20 > header in every > message would actually solve his 3pcc use-case. >=20 > >PS The usage of 'nil' to denote no supported packages is not=20 > consistent > with conventions used today, e.g. for Supported=20 > >(suggest to simply use an empty value instead) >=20 > I think there was some WGLC comment(s) asking about the same thing. > Personally I have no problem to use an empty header instead of 'nil'. > However, I want to ensure that nobody objects to such change before I > implement it. [JRE] I made that comment during WGLC, but received no support at the time.= I would still prefer to follow normal conventions. John From Carol-Lyn.Taylor@dhs.gov Mon Nov 9 01:51:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A723A6903 for ; Mon, 9 Nov 2009 01:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV-f4HTvV0BE for ; Mon, 9 Nov 2009 01:51:26 -0800 (PST) Received: from mta1.dhs.gov (mta1.dhs.gov [152.121.181.36]) by core3.amsl.com (Postfix) with ESMTP id 08B643A6876 for ; Mon, 9 Nov 2009 01:51:26 -0800 (PST) Received: from dhsmail3.dhs.gov (dhsmail3.dhs.gov [161.214.63.41]) by mta1.dhs.gov with ESMTP; Mon, 9 Nov 2009 04:51:52 -0500 Received: from dhsmail3.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F08B920B8; Mon, 9 Nov 2009 04:51:51 -0500 (EST) Received: from ZAS1UG-0360.DHSNET.DS1.DHS (unknown [10.79.65.245]) by dhsmail3.dhs.gov (Postfix) with ESMTP id D6C90210F; Mon, 9 Nov 2009 04:51:51 -0500 (EST) Received: from ZAU1UG-0312.DHSNET.DS1.DHS ([10.79.65.214]) by ZAS1UG-0360.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Nov 2009 04:51:51 -0500 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: base64 Date: Mon, 9 Nov 2009 04:51:50 -0500 Message-Id: <2EFDDC0BA4C4F444BB342D0B6BEF4AD63E472A@ZAU1UG-0312.DHSNET.DS1.DHS> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphD3Kg2+4rKJejRNa+AXr0ywC4RgAAIx8QAANULfAAATy/Xg== From: "Taylor, Carol-Lyn D" To: , , , X-OriginalArrivalTime: 09 Nov 2009 09:51:51.0352 (UTC) FILETIME=[42F38B80:01CA6122] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:51:27 -0000 TGVhdmluZyBGcmFua2Z1cnQgbm93IDQ6NTBhbSB5b3VyIHRpbWUgLSA5aHIgZmxpZ2h0DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2VudCB1c2luZyBCbGFja0JlcnJ5DQoNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIDxz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IEplcm9lbiB2YW4gQmVtbWVsIDxqYmVtbWVsQHpvbm5l dC5ubD47IERSQUdFLCBLZWl0aCAoS2VpdGgpIDxkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+DQpD Yzogc2lwY29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IE1vbiBOb3YgMDkg MDQ6MTc6NTYgMjAwOQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBJTkZPIEVWRU5UIEAgSUVURiM3 NjogV2hlbiB0byBpbnNlcnQgUmVjdi1JbmZvIGhlYWRlcg0KDQogDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIA0KPiBbbWFp bHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1i ZXJnDQo+IFNlbnQ6IDA5IE5vdmVtYmVyIDIwMDkgMDc6NTUNCj4gVG86IEplcm9lbiB2YW4gQmVt bWVsOyBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KPiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIElORk8gRVZFTlQgQCBJRVRGIzc2OiBXaGVuIHRvIGluc2VydCAN Cj4gUmVjdi1JbmZvIGhlYWRlcg0KPiANCj4gDQo+IEhpLCANCj4gDQo+ID5JIGFsc28gdGhpbmsg aXQncyBvdmVya2lsbC4gRnVydGhlcm1vcmUsIEkgZG9uJ3Qgc2VlIGEgcmVhbCB3b3JsZCB1c2UN Cj4gY2FzZSBmb3IgY2hhbmdpbmcgdGhlIHNldCBvZiBzdXBwb3J0ZWQgSU5GTyANCj4gPnBhY2th Z2VzIG1pZC1kaWFsb2cuIFN1cmVseSB0aGUgVUFTIGNhbiBzaW1wbHkgcmVwbHkgd2l0aCBhIDQw Mw0KPiByZXNwb25zZSB3aGVuIGl0IHJlY2VpdmVzIGFuIElORk8gcmVxdWVzdCB3aGljaCBpdCAN Cj4gPmRvZXNuJ3Qgd2FudCB0byBwcm9jZXNzIGFueW1vcmU/DQo+ID4NCj4gPlRvIG1lLCBJTkZP IHBhY2thZ2VzIHNob3VsZCBiZSBsaWtlIHRoZSBEaWFsb2cncyByb3V0ZSBzZXQ6IGxlYXJuIHRo ZQ0KPiBzdXBwb3J0ZWQgc2V0IGZyb20gdGhlIGluaXRpYWwgSU5WSVRFIGFuZCAxeHgtMnh4IA0K PiA+cmVzcG9uc2VzLCBhZnRlciB0aGF0IGRvbid0IGNoYW5nZSBpdCBhbnltb3JlDQo+IA0KPiBJ IHRoaW5rIEFkYW0gbWFkZSB0aGUgc2FtZSBjb21tZW50IGluIHRoZSBTSVBDT1JFIHNlc3Npb24u DQo+IA0KPiBQZXJzb25hbGx5IEkgdGhpbmsgdGhlcmUgY291bGQgYmUgY2FzZXMgd2hlcmUgb25l IHdhbnRzIHRvIA0KPiBhZGQgYSBwYWNrYWdlDQo+IGR1cmluZyBhIGRpYWxvZy4gRm9yIGV4YW1w bGUsIGFzc3VtZSBJIGNhbGwgeW91LiBUaGVuLCBkdXJpbmcgDQo+IHRoZSBkaWFsb2cNCj4gd2Ug ZGVjaWRlIHRvIHN0YXJ0IHVzaW5nIGFwcGxpY2F0aW9uIFggd2hpY2ggdXNlcyBhbiBJbmZvIFBh Y2thZ2UsIHNvDQo+IG91ciBwaG9uZXMgc2VuZCBSZWN2LUluZm86WCB0byBlYWNoIG90aGVyLiBB cHBsaWNhdGlvbiBYIG1heSANCj4gbm90IGV2ZW4gYmUNCj4gcnVubmluZyB3aGVuIHdlIGluaXRp YXRlIHRoZSBkaWFsb2cuDQo+IA0KPiBIb3dldmVyLCBpZiB3ZSBhcmUgZ29pbmcgdG8gcmVxdWly ZSB0aGUgaGVhZGVyIGluIGEgbG90IG9mIG1lc3NhZ2VzLA0KPiBtYXliZSB3ZSBzaG91bGQgcmVt b3ZlIFBSQUNLIGZyb20gdGhlIGxpc3Qgb2YgYWxsb3dlZCBtZXNzYWdlcy4gV291bGQNCj4gcGVv cGxlIGhhdmUgcHJvYmxlbXMgd2l0aCB0aGF0Pw0KPiANCj4gQnV0LCBJIHdvdWxkIGxpa2UgUGF1 bCB0byBjb21tZW50IHdoZXRoZXIgbWFuZGF0aW5nIHRoZSANCj4gaGVhZGVyIGluIGV2ZXJ5DQo+ IG1lc3NhZ2Ugd291bGQgYWN0dWFsbHkgc29sdmUgaGlzIDNwY2MgdXNlLWNhc2UuDQo+IA0KPiA+ UFMgVGhlIHVzYWdlIG9mICduaWwnIHRvIGRlbm90ZSBubyBzdXBwb3J0ZWQgcGFja2FnZXMgaXMg bm90IA0KPiBjb25zaXN0ZW50DQo+IHdpdGggY29udmVudGlvbnMgdXNlZCB0b2RheSwgZS5nLiBm b3IgU3VwcG9ydGVkIA0KPiA+KHN1Z2dlc3QgdG8gc2ltcGx5IHVzZSBhbiBlbXB0eSB2YWx1ZSBp bnN0ZWFkKQ0KPiANCj4gSSB0aGluayB0aGVyZSB3YXMgc29tZSBXR0xDIGNvbW1lbnQocykgYXNr aW5nIGFib3V0IHRoZSBzYW1lIHRoaW5nLg0KPiBQZXJzb25hbGx5IEkgaGF2ZSBubyBwcm9ibGVt IHRvIHVzZSBhbiBlbXB0eSBoZWFkZXIgaW5zdGVhZCBvZiAnbmlsJy4NCj4gSG93ZXZlciwgSSB3 YW50IHRvIGVuc3VyZSB0aGF0IG5vYm9keSBvYmplY3RzIHRvIHN1Y2ggY2hhbmdlIGJlZm9yZSBJ DQo+IGltcGxlbWVudCBpdC4NCltKUkVdIEkgbWFkZSB0aGF0IGNvbW1lbnQgZHVyaW5nIFdHTEMs IGJ1dCByZWNlaXZlZCBubyBzdXBwb3J0IGF0IHRoZSB0aW1lLiBJIHdvdWxkIHN0aWxsIHByZWZl ciB0byBmb2xsb3cgbm9ybWFsIGNvbnZlbnRpb25zLg0KDQpKb2huDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0K c2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQo= From jbemmel@zonnet.nl Mon Nov 9 09:32:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBACB3A67E9 for ; Mon, 9 Nov 2009 09:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e26nr04Jp912 for ; Mon, 9 Nov 2009 09:32:22 -0800 (PST) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id B70B73A6403 for ; Mon, 9 Nov 2009 09:32:20 -0800 (PST) Received: (qmail 334 invoked by uid 0); 9 Nov 2009 17:32:45 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Nov 2009 17:32:45 -0000 Message-ID: <4AF8523C.8010400@zonnet.nl> Date: Mon, 09 Nov 2009 18:32:44 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF7D33C.4010906@digium.com> In-Reply-To: <4AF7D33C.4010906@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:32:26 -0000 Sure, but "application" in the sense of an INFO Package isn't the same as "application" in the sense of a program that a user decides to start mid-call. A sample application for INFO Package is the sending of DTMF digits. Another might be the sharing of Geo location data mid-call ( "Where are you? I'm here!" , a mobile phone pops up a map with the designated location highlighted; some IVR voicemail application might instead record the location and show it on a web page). These are applications in the sense of "ways of using INFO packages", not "computer programs" General (web) programs that send arbitrary data via the SIP signaling path is something I thought we were trying to avoid. We need a limited set of well defined applications (in the INFO package sense), such that different applications (in the program sense) from various vendors can use them interoperably. And interoperability is better when things are kept simple. Indicating support for some INFO package does not mean that the receiver must automatically accept INFO requests carrying that package. One can still implement dynamic policies that e.g. only accept DTMF at the beginning of a call, e.g. until the proper authorization code has been entered. I just don't see the need to then "disable" DTMF by sending a target-refresh request that no longer lists DTMF as supported Info package. Regards, Jeroen Kevin P. Fleming wrote: > Christer Holmberg wrote: > > >> Well, maybe there in the not-so-distant future will be some kind of >> integrated web applications where you can "click on a link" to add an >> application to an ongoing dialog. I don't think we should prevent such >> things. >> > > I don't think is very far off at all; many hardphones from various > manufacturers are already supporting additional applications, and it's > completely conceivable that a user of the phone might press a button to > activate an application during an existing call. It would have been > inappropriate for the phone to have offered to receive the related INFO > packages during the call setup, but once the application is running they > should be accepted (and in fact the act of starting the application may > directly result in a re-INVITE for no other purpose than to update the > Recv-Info package list the phone will accept). > > From george.foti@ericsson.com Mon Nov 9 11:11:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C63E3A67EA for ; Mon, 9 Nov 2009 11:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08RtD0VRxWTO for ; Mon, 9 Nov 2009 11:11:09 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id C27CB3A69D5 for ; Mon, 9 Nov 2009 11:11:07 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nA9JBPk5032064; Mon, 9 Nov 2009 13:11:29 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:11:23 -0600 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:11:22 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Nov 2009 14:11:21 -0500 From: George Foti To: Linyi TIAN , "'Jeroen van Bemmel'" , "'DRAGE, Keith (Keith)'" , Christer Holmberg Date: Mon, 9 Nov 2009 14:11:20 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphD7Ong2Ae3J/QR4O/+Smn4lWD9QACIcYQABWd0uA= Message-ID: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> In-Reply-To: <01ba01ca6118$8f995320$aecbf960$@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-OriginalArrivalTime: 09 Nov 2009 19:11:22.0504 (UTC) FILETIME=[6CEAD080:01CA6170] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:11:10 -0000 The ability for a SIP device to remove support for the reception of an info= -package mid-dialog is necessary and not an option. Some applications will not use SIP INFO any more if this feature is taken o= ut If we take the IPTV application, where we have an info package to allow STB= s and TV devices to tell the network the content currently being watched (w= hat the device is tuned to) The network must be able to stop TV devices from reporting the programs th= ey are tuned when it so desires. Given that reporting occurs after end users start and stop zapping, and giv= en that zapping occurs after TV ads start showing up, and that typically al= l IPTV users start zapping at that time, the network can be crippled with a= ll devices reporting at the same time if it cant stop them at will. Just ignoring the SIP INFO as suggested by some does not make sense as the = congestion that this produces from devices re-attempting to send etc, will = cause even more harm. As such, comparing info-packages negotiated at dialog start-up to dialog ro= ute is not appropriate and pre-judges how applications work, which is quite= dangerous. Certainly removing this flexibility will limit the ability to use the SIP I= NFO and is a step backward and makes the use of legacy SIP INFO more attrac= tive without the overhead as the result of rejection is the same Thanks George -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Linyi TIAN Sent: Monday, November 09, 2009 3:42 AM To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r This looks more reasonable and simple. If we don't see real use cases for c= hanging set during the dialog we'd better not have a technical solution for= it. Or even there is limited use case, it is no harm to use status code to= ignore the INFO. This will reduce the protocol impact and simply the imple= mentation. So for the time being I support Jeroen's approach unless something new is i= ntroduced. Cheers, Linyi > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of > Jeroen van Bemmel > Sent: Monday, November 09, 2009 3:37 PM > To: DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header >=20 > I also think it's overkill. Furthermore, I don't see a real world use=20 > case for changing the set of supported INFO packages mid-dialog.=20 > Surely the UAS can simply reply with a 403 response when it receives=20 > an INFO request which it doesn't want to process anymore? >=20 > To me, INFO packages should be like the Dialog's route set: learn the=20 > supported set from the initial INVITE and 1xx-2xx responses, after=20 > that don't change it anymore >=20 > Regards, > Jeroen >=20 > PS The usage of 'nil' to denote no supported packages is not=20 > consistent with conventions used today, e.g. for Supported (suggest to=20 > simply use an empty value instead) >=20 > DRAGE, Keith (Keith) wrote: > > This works, but it seems overkill to me. > > > > Firstly can I ensure that this does not include REGISTER, which=20 > > could also be > understood from the paraphrase of the SIPCORE discussion. > > > > Secondly can I still have more detail (arrow diagram) on the=20 > > scenario we are trying > to solve for 3pcc. I can't see if there is a simple solution if the problem is > insufficiently clear. > > > > Keith > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Monday, November 09, 2009 4:15 AM > >> To: Christer Holmberg > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >> Recv-Info header > >> > >> That works for me, and it is sufficiently simple that everybody=20 > >> should be able to implement it correctly. :-) > >> > >> Thanks, > >> Paul > >> > >> Christer Holmberg wrote: > >> > >>> Hi, > >>> > >>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 > >>> discussed whether we should mandate to include Recv-Info in > >>> > >> re-INVITE > >> > >>> responses. > >>> > >>> The outcome of the discussion was that EVERY SIP messages where=20 > >>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>> > >> the set of > >> > >>> Info Packages has changed or not. > >>> > >>> Based on the -03pre version of the draft the following > >>> > >> messages would > >> > >>> be > >>> affected: > >>> > >>> INVITE + 18x + 200 > >>> Re-INVITE + 18x + 200 > >>> ACK > >>> UPDATE + 200 > >>> PRACK + 200 > >>> > >>> That is a change from previous versions of the draft, which > >>> > >> says that > >> > >>> the Recv-Info header only needs to be inserted if the set of Info=20 > >>> Packages changes. > >>> > >>> So, unless people have issues with that, my intention is to > >>> > >> implement > >> > >>> the change in the next version of the draft. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From george.foti@ericsson.com Mon Nov 9 11:20:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03983A6B6C for ; Mon, 9 Nov 2009 11:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIhIo-K9vG-A for ; Mon, 9 Nov 2009 11:20:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 030EF3A6808 for ; Mon, 9 Nov 2009 11:20:23 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nA9JKlrn022647; Mon, 9 Nov 2009 13:20:49 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:20:05 -0600 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 13:20:05 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 Nov 2009 14:20:04 -0500 From: George Foti To: Jeroen van Bemmel , "Kevin P. Fleming" Date: Mon, 9 Nov 2009 14:20:03 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphYuvZRIDQjMKHTVuDCT4ZTKG28gADhk2g Message-ID: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF7D33C.4010906@digium.com> <4AF8523C.8010400@zonnet.nl> In-Reply-To: <4AF8523C.8010400@zonnet.nl> 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-OriginalArrivalTime: 09 Nov 2009 19:20:05.0594 (UTC) FILETIME=[A4B403A0:01CA6171] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:20:25 -0000 Lets not pre-judge how applications will work. Changing the list of supported Info-packages mid-dialog is essential. I don't want neither the links to be congested nor the server to waste load= to process things that it does not plan to accept and I want the other end= to *COMPLY* to that by telling it so. Thanks George -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Jeroen van Bemmel Sent: Monday, November 09, 2009 12:33 PM To: Kevin P. Fleming Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r Sure, but "application" in the sense of an INFO Package isn't the same as "= application" in the sense of a program that a user decides to start mid-cal= l. A sample application for INFO Package is the sending of DTMF digits.=20 Another might be the sharing of Geo location data mid-call ( "Where are you= ? I'm here!" , a mobile ph= one pops up a map with the designated location highlighted; some IVR voicem= ail application might instead record the location and show it on a web page= ). These are applications in the sense of "ways of using INFO packages", no= t "computer programs" General (web) programs that send arbitrary data via the SIP signaling path = is something I thought we were trying to avoid. We need a limited set of we= ll defined applications (in the INFO package sense), such that different ap= plications (in the program sense) from various vendors can use them interop= erably. And interoperability is better when things are kept simple. Indicating support for some INFO package does not mean that the receiver mu= st automatically accept INFO requests carrying that package. One can still = implement dynamic policies that e.g. only accept DTMF at the beginning of a= call, e.g. until the proper authorization code has been entered. I just do= n't see the need to then "disable" DTMF by sending a target-refresh request= that no longer lists DTMF as supported Info package. Regards, Jeroen Kevin P. Fleming wrote: > Christer Holmberg wrote: > > =20 >> Well, maybe there in the not-so-distant future will be some kind of=20 >> integrated web applications where you can "click on a link" to add an=20 >> application to an ongoing dialog. I don't think we should prevent=20 >> such things. >> =20 > > I don't think is very far off at all; many hardphones from various=20 > manufacturers are already supporting additional applications, and it's=20 > completely conceivable that a user of the phone might press a button=20 > to activate an application during an existing call. It would have been=20 > inappropriate for the phone to have offered to receive the related=20 > INFO packages during the call setup, but once the application is=20 > running they should be accepted (and in fact the act of starting the=20 > application may directly result in a re-INVITE for no other purpose=20 > than to update the Recv-Info package list the phone will accept). > > =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From radhika.r.roy@us.army.mil Mon Nov 9 12:02:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0655E3A689C for ; Mon, 9 Nov 2009 12:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXyNzpR-x9aU for ; Mon, 9 Nov 2009 12:02:51 -0800 (PST) Received: from mxoutdr1.us.army.mil (mxoutdr1.us.army.mil [143.69.242.38]) by core3.amsl.com (Postfix) with ESMTP id 6B9343A68EA for ; Mon, 9 Nov 2009 12:02:45 -0800 (PST) DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=bdBJ+r8NmM1V0fTTmT9i/gYta8eh9c6GkzrX+k70HfD/Rj/3ugKb2q4i C5vW150bFNFcJ+vEAHPOP9wr2zertw==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us.army.mil; i=radhika.r.roy@us.army.mil; q=dns/txt; s=akodkim; t=1257796992; x=1289332992; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy,=20Radhika=20R=20CTR=20USA=20USAMC"=20|Subject:=20Re:=20[sipcore]=20INFO =20EVENT=20@=20IETF#76:=20When=20to=20insert=20Recv-Info =0D=0A=20header|Date:=20Mon,=2009=20Nov=202009=2015:03:11 =20-0500|Message-ID:=20|To:=20George=20Foti=20|Cc:=20 Jeroen=20van=20Bemmel=20,"Kevin=20P. =20Fleming"=0D=0A=20,"sipcore@ietf. org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20=20<4AF79740.8020 707@cisco.com>=0D=0A=20=20<4AF7C6 9D.6040804@zonnet.nl>=0D=0A=20=20<4AF7CDD0. 308@zonnet.nl>=0D=0A=20=20<4AF7D33C.4010906 @digium.com>=20<4AF8523C.8010400@zonnet.nl>=0D=0A=20; bh=JBr6+LSDO6B+pmfX4hqMN70YZ7MN7mNHSIgA9EN0Xw8=; b=No95EBZkMOuYMnXkontTHgdlxCgmipgInWcfaDG4nOdl5OtVC1fiPsQB L1bdRzeifwPUL7XWfrgHmOyvlRrGpd1OQnIM7JTlTsKDoNfZcqGbIjjyu lJFAxiqnRHXMz6vAJ66XjW4lnWn8PTkdZI8AVz4sclnLHlB+MHSW4ci0E k=; From: "Roy, Radhika R CTR USA USAMC" X-AKO: 96448479:10.240.36.115:09 Nov 2009 20:03:11 +0000:$Webmail:None X-IronPort-AV: E=Sophos;i="4.44,711,1249257600"; d="scan'208";a="96448479" Received: from mailstore13.int.dr1.us.army.mil (HELO us.army.mil) ([10.240.36.115]) by mxoutdr1.us.army.mil with ESMTP; 09 Nov 2009 20:03:11 +0000 Received: from [10.240.32.178] (Forwarded-For: 134.80.13.193, [10.240.32.178]) by mail13.int.dr1.us.army.mil (mshttpd); Mon, 09 Nov 2009 15:03:11 -0500 To: George Foti Message-ID: Date: Mon, 09 Nov 2009 15:03:11 -0500 X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.01 (built Dec 5 2007; 32bit) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF7D33C.4010906@digium.com> <4AF8523C.8010400@zonnet.nl> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: "Kevin P. Fleming" , "sipcore@ietf.org" , Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:02:53 -0000 Hi, George: We have never talked about the use of SIP-INFO package for IPTV. I appreciate for bringing this topic here (although I might have missed many emails on this - sorry for this as I am nor following the threads so closely these days since joining CERDEC). Could you please more ideas like this for use of SIP for the IPTV not necessarily limiting to the SIP-INFO package? Best regards, Radhika ----- Original Message ----- From: George Foti Date: Monday, November 9, 2009 14:26 Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header To: Jeroen van Bemmel , "Kevin P. Fleming" Cc: "sipcore@ietf.org" > Lets not pre-judge how applications will work. > Changing the list of supported Info-packages mid-dialog is essential. > > I don't want neither the links to be congested nor the server to > waste load to process things that it does not plan to accept and I > want the other end to *COMPLY* to that by telling it so. > > > Thanks > George > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > On Behalf Of Jeroen van Bemmel > Sent: Monday, November 09, 2009 12:33 PM > To: Kevin P. Fleming > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv- > Info header > > Sure, but "application" in the sense of an INFO Package isn't the > same as "application" in the sense of a program that a user > decides to start mid-call. > > A sample application for INFO Package is the sending of DTMF > digits. > Another might be the sharing of Geo location data mid-call ( > "Where are you? I'm here!" <, a mobile phone pops up a map with the designated location highlighted; some IVR voicemail application might instead record the location and show it on a web page). These are applications in the sense of "ways of using INFO packages", not "computer programs" > > General (web) programs that send arbitrary data via the SIP signaling path is something I thought we were trying to avoid. We need a limited set of well defined applications (in the INFO package sense), such that different applications (in the program sense) from various vendors can use them interoperably. And interoperability is better when things are kept simple. > > Indicating support for some INFO package does not mean that the receiver must automatically accept INFO requests carrying that package. One can still implement dynamic policies that e.g. only accept DTMF at the beginning of a call, e.g. until the proper authorization code has been entered. I just don't see the need to then "disable" DTMF by sending a target-refresh request that no longer lists DTMF as supported Info package. > > Regards, > Jeroen > > Kevin P. Fleming wrote: > > Christer Holmberg wrote: > > > > > >> Well, maybe there in the not-so-distant future will be some kind of > >> integrated web applications where you can "click on a link" to add an > >> application to an ongoing dialog. I don't think we should prevent > >> such things. > >> > > > > I don't think is very far off at all; many hardphones from various > > manufacturers are already supporting additional applications, and it's > > completely conceivable that a user of the phone might press a button > > to activate an application during an existing call. It would have been > > inappropriate for the phone to have offered to receive the related > > INFO packages during the call setup, but once the application is > > running they should be accepted (and in fact the act of starting the > > application may directly result in a re-INVITE for no other purpose > > than to update the Recv-Info package list the phone will accept). > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From george.foti@ericsson.com Mon Nov 9 12:21:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8182428C201 for ; Mon, 9 Nov 2009 12:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWSsnz5GIzDO for ; Mon, 9 Nov 2009 12:21:05 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 741713A68F2 for ; Mon, 9 Nov 2009 12:21:05 -0800 (PST) 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 nA9KKs2o026715; Mon, 9 Nov 2009 14:20:59 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:19:54 -0600 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 14:19:54 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 Nov 2009 15:19:53 -0500 From: George Foti To: "Roy, Radhika R CTR USA USAMC" Date: Mon, 9 Nov 2009 15:19:51 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: Acphd8aYYUUOczdfT8ij4uoxZOLrbwAAWO6Q Message-ID: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF7D33C.4010906@digium.com> <4AF8523C.8010400@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-OriginalArrivalTime: 09 Nov 2009 20:19:54.0174 (UTC) FILETIME=[FFA9DDE0:01CA6179] Cc: Jeroen van Bemmel , "sipcore@ietf.org" , "Kevin P. Fleming" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:21:06 -0000 Hi, SIP is used by 3GPP, ATIS, and many other SDOs for session control in IPTV. I was listing this just to highlight that mid-dialog changes for supported = Info packages is something that can happen frequently in there. Reporting by STBs the channel they are tuned to is one case where the netwo= rk must ensure that it can control those STBs from reporting the TV channel= they are tuned to (whenever the channel changes), and must ensure through = specifications that the STBs comply to. =20 Thanks George -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Roy, Radhika R CTR USA USAMC Sent: Monday, November 09, 2009 3:03 PM To: George Foti Cc: Kevin P. Fleming; sipcore@ietf.org; Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r Hi, George: We have never talked about the use of SIP-INFO package for IPTV. I apprecia= te for bringing this topic here (although I might have missed many emails o= n this - sorry for this as I am nor following the threads so closely these = days since joining CERDEC). Could you please more ideas like this for use of SIP for the IPTV not neces= sarily limiting to the SIP-INFO package? Best regards, Radhika ----- Original Message ----- From: George Foti Date: Monday, November 9, 2009 14:26 Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r To: Jeroen van Bemmel , "Kevin P. Fleming" Cc: "sipcore@ietf.org" > Lets not pre-judge how applications will work. > Changing the list of supported Info-packages mid-dialog is essential. >=20 > I don't want neither the links to be congested nor the server to waste=20 > load to process things that it does not plan to accept and I want the=20 > other end to *COMPLY* to that by telling it so. >=20 >=20 > Thanks > George >=20 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Jeroen van Bemmel > Sent: Monday, November 09, 2009 12:33 PM > To: Kevin P. Fleming > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv- Info=20 > header >=20 > Sure, but "application" in the sense of an INFO Package isn't the same=20 > as "application" in the sense of a program that a user decides to=20 > start mid-call. >=20 > A sample application for INFO Package is the sending of DTMF digits. > Another might be the sharing of Geo location data mid-call ( "Where=20 > are you? I'm here!" <, a mobile phone pops up a map with the designated l= ocation highlighted; some IVR voicemail application might instead record th= e location and show it on a web page). These are applications in the sense = of "ways of using INFO packages", not "computer programs" >=20 > General (web) programs that send arbitrary data via the SIP signaling pat= h is something I thought we were trying to avoid. We need a limited set of = well defined applications (in the INFO package sense), such that different = applications (in the program sense) from various vendors can use them inter= operably. And interoperability is better when things are kept simple. >=20 > Indicating support for some INFO package does not mean that the receiver = must automatically accept INFO requests carrying that package. One can stil= l implement dynamic policies that e.g. only accept DTMF at the beginning of= a call, e.g. until the proper authorization code has been entered. I just = don't see the need to then "disable" DTMF by sending a target-refresh reque= st that no longer lists DTMF as supported Info package. >=20 > Regards, > Jeroen >=20 > Kevin P. Fleming wrote: > > Christer Holmberg wrote: > > > >=20 > >> Well, maybe there in the not-so-distant future will be some kind of=20 > >> integrated web applications where you can "click on a link" to add=20 > >> an application to an ongoing dialog. I don't think we should=20 > >> prevent such things. > >>=20 > > > > I don't think is very far off at all; many hardphones from various=20 > > manufacturers are already supporting additional applications, and=20 > > it's completely conceivable that a user of the phone might press a=20 > > button to activate an application during an existing call. It would=20 > > have been inappropriate for the phone to have offered to receive the=20 > > related INFO packages during the call setup, but once the=20 > > application is running they should be accepted (and in fact the act=20 > > of starting the application may directly result in a re-INVITE for=20 > > no other purpose than to update the Recv-Info package list the phone wi= ll accept). > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From jbemmel@zonnet.nl Mon Nov 9 13:03:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9963A6B78 for ; Mon, 9 Nov 2009 13:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDNi+jadDuxn for ; Mon, 9 Nov 2009 13:03:35 -0800 (PST) Received: from smtp5.versatel.nl (smtp5.versatel.nl [62.58.50.96]) by core3.amsl.com (Postfix) with ESMTP id 560693A682B for ; Mon, 9 Nov 2009 13:03:34 -0800 (PST) Received: (qmail 3990 invoked by uid 0); 9 Nov 2009 21:03:59 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp5.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Nov 2009 21:03:59 -0000 Message-ID: <4AF883BE.5000408@zonnet.nl> Date: Mon, 09 Nov 2009 22:03:58 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: George Foti References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , Linyi TIAN Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:03:37 -0000 George, OK, now we're getting somewhere - my point was to get the requirements being designed for explicitly on the table, and to not make things harder than they need to be I don't know if there was ever an explicit list of requirements being addressed by Info Event - if people agree that your use case below (i.e. mid-dialog changes to the set of INFO packages a UA is willing to accept INFO requests for, for congestion avoidance purposes) is valid, in scope of this draft and desirable, then I suppose we could add the mechanism. I'd suggest that the editor add a separate section discussing such mid-dialog changes to the set, its intended purpose, and the required UA behavior (under section 4.2 perhaps) Regards, Jeroen George Foti wrote: > The ability for a SIP device to remove support for the reception of an info-package mid-dialog is necessary and not an option. > Some applications will not use SIP INFO any more if this feature is taken out > > If we take the IPTV application, where we have an info package to allow STBs and TV devices to tell the network the content currently being watched (what the device is tuned to) > > The network must be able to stop TV devices from reporting the programs they are tuned when it so desires. > Given that reporting occurs after end users start and stop zapping, and given that zapping occurs after TV ads start showing up, and that typically all IPTV users start zapping at that time, the network can be crippled with all devices reporting at the same time if it cant stop them at will. > > Just ignoring the SIP INFO as suggested by some does not make sense as the congestion that this produces from devices re-attempting to send etc, will cause even more harm. > > As such, comparing info-packages negotiated at dialog start-up to dialog route is not appropriate and pre-judges how applications work, which is quite dangerous. > > Certainly removing this flexibility will limit the ability to use the SIP INFO and is a step backward and makes the use of legacy SIP INFO more attractive without the overhead as the result of rejection is the same > > Thanks > George > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Linyi TIAN > Sent: Monday, November 09, 2009 3:42 AM > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header > > This looks more reasonable and simple. If we don't see real use cases for changing set during the dialog we'd better not have a technical solution for it. Or even there is limited use case, it is no harm to use status code to ignore the INFO. This will reduce the protocol impact and simply the implementation. > > So for the time being I support Jeroen's approach unless something new is introduced. > > Cheers, > Linyi > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf >> > Of > >> Jeroen van Bemmel >> Sent: Monday, November 09, 2009 3:37 PM >> To: DRAGE, Keith (Keith) >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> > header > >> I also think it's overkill. Furthermore, I don't see a real world use >> case for changing the set of supported INFO packages mid-dialog. >> Surely the UAS can simply reply with a 403 response when it receives >> an INFO request which it doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the >> supported set from the initial INVITE and 1xx-2xx responses, after >> that don't change it anymore >> >> Regards, >> Jeroen >> >> PS The usage of 'nil' to denote no supported packages is not >> consistent with conventions used today, e.g. for Supported (suggest to >> simply use an empty value instead) >> >> DRAGE, Keith (Keith) wrote: >> >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which >>> could >>> > also be > >> understood from the paraphrase of the SIPCORE discussion. >> >>> Secondly can I still have more detail (arrow diagram) on the >>> scenario we >>> > are trying > >> to solve for 3pcc. I can't see if there is a simple solution if the >> > problem is > >> insufficiently clear. >> >>> Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info header >>>> >>>> That works for me, and it is sufficiently simple that everybody >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>>> discussed whether we should mandate to include Recv-Info in >>>>> >>>>> >>>> re-INVITE >>>> >>>> >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> >>>>> >>>> the set of >>>> >>>> >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> >>>>> >>>> messages would >>>> >>>> >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> >>>>> >>>> says that >>>> >>>> >>>>> the Recv-Info header only needs to be inserted if the set of Info >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> >>>>> >>>> implement >>>> >>>> >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Mon Nov 9 15:36:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063A33A6828 for ; Mon, 9 Nov 2009 15:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRnkqniI+qZb for ; Mon, 9 Nov 2009 15:36:51 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2F77E3A6826 for ; Mon, 9 Nov 2009 15:36:50 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-0b-4af8a7ac17c0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 63.D0.31706.CA7A8FA4; Tue, 10 Nov 2009 00:37:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:36:01 +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: Tue, 10 Nov 2009 00:36:01 +0100 Message-ID: In-Reply-To: <4AF883BE.5000408@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rww References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "George Foti" X-OriginalArrivalTime: 09 Nov 2009 23:36:01.0571 (UTC) FILETIME=[65942730:01CA6195] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Linyi TIAN Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:36:53 -0000 Hi all, I appretiate the input you have all provided.=20 I am also glad that George provided some more details on the IPTV usage, since I wasn't able to do that myself during the SIPCORE session. But, I think that shows that there is an interest for this framework. I still strgonly believe that mid-call changes are needed, and that forbidding them may prevent future usages - or usage people are working on at the moment. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 10. marraskuuta 2009 0:04 To: George Foti Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header George, OK, now we're getting somewhere - my point was to get the requirements being designed for explicitly on the table, and to not make things harder than they need to be I don't know if there was ever an explicit list of requirements being addressed by Info Event - if people agree that your use case below (i.e. mid-dialog changes to the set of INFO packages a UA is willing to accept INFO requests for, for congestion avoidance purposes) is valid, in scope of this draft and desirable, then I suppose we could add the mechanism.=20 I'd suggest that the editor add a separate section discussing such mid-dialog changes to the set, its intended purpose, and the required UA behavior (under section 4.2 perhaps) Regards, Jeroen George Foti wrote: > The ability for a SIP device to remove support for the reception of an info-package mid-dialog is necessary and not an option. > Some applications will not use SIP INFO any more if this feature is=20 > taken out > > If we take the IPTV application, where we have an info package to=20 > allow STBs and TV devices to tell the network the content currently=20 > being watched (what the device is tuned to) > > The network must be able to stop TV devices from reporting the programs they are tuned when it so desires. > Given that reporting occurs after end users start and stop zapping, and given that zapping occurs after TV ads start showing up, and that typically all IPTV users start zapping at that time, the network can be crippled with all devices reporting at the same time if it cant stop them at will. > > Just ignoring the SIP INFO as suggested by some does not make sense as the congestion that this produces from devices re-attempting to send etc, will cause even more harm. > > As such, comparing info-packages negotiated at dialog start-up to dialog route is not appropriate and pre-judges how applications work, which is quite dangerous. > > Certainly removing this flexibility will limit the ability to use the=20 > SIP INFO and is a step backward and makes the use of legacy SIP INFO=20 > more attractive without the overhead as the result of rejection is the > same > > Thanks > George > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Linyi TIAN > Sent: Monday, November 09, 2009 3:42 AM > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header > > This looks more reasonable and simple. If we don't see real use cases for changing set during the dialog we'd better not have a technical solution for it. Or even there is limited use case, it is no harm to use status code to ignore the INFO. This will reduce the protocol impact and simply the implementation. > > So for the time being I support Jeroen's approach unless something new is introduced. > > Cheers, > Linyi > > =20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf >> =20 > Of > =20 >> Jeroen van Bemmel >> Sent: Monday, November 09, 2009 3:37 PM >> To: DRAGE, Keith (Keith) >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> =20 > header > =20 >> I also think it's overkill. Furthermore, I don't see a real world use >> case for changing the set of supported INFO packages mid-dialog. >> Surely the UAS can simply reply with a 403 response when it receives=20 >> an INFO request which it doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the >> supported set from the initial INVITE and 1xx-2xx responses, after=20 >> that don't change it anymore >> >> Regards, >> Jeroen >> >> PS The usage of 'nil' to denote no supported packages is not=20 >> consistent with conventions used today, e.g. for Supported (suggest=20 >> to simply use an empty value instead) >> >> DRAGE, Keith (Keith) wrote: >> =20 >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which=20 >>> could >>> =20 > also be > =20 >> understood from the paraphrase of the SIPCORE discussion. >> =20 >>> Secondly can I still have more detail (arrow diagram) on the=20 >>> scenario we >>> =20 > are trying > =20 >> to solve for 3pcc. I can't see if there is a simple solution if the >> =20 > problem is > =20 >> insufficiently clear. >> =20 >>> Keith >>> >>> >>> =20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info header >>>> >>>> That works for me, and it is sufficiently simple that everybody=20 >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> >>>> =20 >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>>>> discussed whether we should mandate to include Recv-Info in >>>>> >>>>> =20 >>>> re-INVITE >>>> >>>> =20 >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> >>>>> =20 >>>> the set of >>>> >>>> =20 >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> >>>>> =20 >>>> messages would >>>> >>>> =20 >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> >>>>> =20 >>>> says that >>>> >>>> =20 >>>>> the Recv-Info header only needs to be inserted if the set of Info=20 >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> >>>>> =20 >>>> implement >>>> >>>> =20 >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> =20 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From christer.holmberg@ericsson.com Mon Nov 9 15:43:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D43A6828 for ; Mon, 9 Nov 2009 15:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcoNVRiBEUKL for ; Mon, 9 Nov 2009 15:43:51 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 104A03A67B6 for ; Mon, 9 Nov 2009 15:43:50 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-ff-4af8a94fcc8a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3D.8F.04191.F49A8FA4; Tue, 10 Nov 2009 00:44:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:44:15 +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: Tue, 10 Nov 2009 00:44:15 +0100 Message-ID: In-Reply-To: <4AF883BE.5000408@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAFdpBQ References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , "George Foti" X-OriginalArrivalTime: 09 Nov 2009 23:44:15.0899 (UTC) FILETIME=[8C389EB0:01CA6196] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Linyi TIAN Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:43:52 -0000 Hi,=20 >I don't know if there was ever an explicit list of requirements being addressed by Info Event - if people agree that your=20 >use case below (i.e. mid-dialog changes to the set of INFO packages a UA is willing to accept INFO requests for, for=20 >congestion avoidance purposes) is valid, in scope of this draft and desirable, then I suppose we could add the mechanism.=20 Just to clarify: the possibility to add/remove packages has been in the draft for a long time. That as such was not the original issue of this thread :) >I'd suggest that the editor add a separate section discussing such mid-dialog changes to the set, its intended purpose,=20 >and the required UA behavior (under section 4.2 perhaps) I can take a look, to see whether it can be further clarified. Did you look at the -03pre version? Regards, Christer George Foti wrote: > The ability for a SIP device to remove support for the reception of an info-package mid-dialog is necessary and not an option. > Some applications will not use SIP INFO any more if this feature is=20 > taken out > > If we take the IPTV application, where we have an info package to=20 > allow STBs and TV devices to tell the network the content currently=20 > being watched (what the device is tuned to) > > The network must be able to stop TV devices from reporting the programs they are tuned when it so desires. > Given that reporting occurs after end users start and stop zapping, and given that zapping occurs after TV ads start showing up, and that typically all IPTV users start zapping at that time, the network can be crippled with all devices reporting at the same time if it cant stop them at will. > > Just ignoring the SIP INFO as suggested by some does not make sense as the congestion that this produces from devices re-attempting to send etc, will cause even more harm. > > As such, comparing info-packages negotiated at dialog start-up to dialog route is not appropriate and pre-judges how applications work, which is quite dangerous. > > Certainly removing this flexibility will limit the ability to use the=20 > SIP INFO and is a step backward and makes the use of legacy SIP INFO=20 > more attractive without the overhead as the result of rejection is the > same > > Thanks > George > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Linyi TIAN > Sent: Monday, November 09, 2009 3:42 AM > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header > > This looks more reasonable and simple. If we don't see real use cases for changing set during the dialog we'd better not have a technical solution for it. Or even there is limited use case, it is no harm to use status code to ignore the INFO. This will reduce the protocol impact and simply the implementation. > > So for the time being I support Jeroen's approach unless something new is introduced. > > Cheers, > Linyi > > =20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf >> =20 > Of > =20 >> Jeroen van Bemmel >> Sent: Monday, November 09, 2009 3:37 PM >> To: DRAGE, Keith (Keith) >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> =20 > header > =20 >> I also think it's overkill. Furthermore, I don't see a real world use >> case for changing the set of supported INFO packages mid-dialog. >> Surely the UAS can simply reply with a 403 response when it receives=20 >> an INFO request which it doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the >> supported set from the initial INVITE and 1xx-2xx responses, after=20 >> that don't change it anymore >> >> Regards, >> Jeroen >> >> PS The usage of 'nil' to denote no supported packages is not=20 >> consistent with conventions used today, e.g. for Supported (suggest=20 >> to simply use an empty value instead) >> >> DRAGE, Keith (Keith) wrote: >> =20 >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which=20 >>> could >>> =20 > also be > =20 >> understood from the paraphrase of the SIPCORE discussion. >> =20 >>> Secondly can I still have more detail (arrow diagram) on the=20 >>> scenario we >>> =20 > are trying > =20 >> to solve for 3pcc. I can't see if there is a simple solution if the >> =20 > problem is > =20 >> insufficiently clear. >> =20 >>> Keith >>> >>> >>> =20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info header >>>> >>>> That works for me, and it is sufficiently simple that everybody=20 >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> >>>> =20 >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>>>> discussed whether we should mandate to include Recv-Info in >>>>> >>>>> =20 >>>> re-INVITE >>>> >>>> =20 >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> >>>>> =20 >>>> the set of >>>> >>>> =20 >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> >>>>> =20 >>>> messages would >>>> >>>> =20 >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> >>>>> =20 >>>> says that >>>> >>>> =20 >>>>> the Recv-Info header only needs to be inserted if the set of Info=20 >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> >>>>> =20 >>>> implement >>>> >>>> =20 >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> =20 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From adam@nostrum.com Mon Nov 9 16:36:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F4B3A68A0 for ; Mon, 9 Nov 2009 16:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXAOlcwH8JDa for ; Mon, 9 Nov 2009 16:36:30 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3AE6E3A689C for ; Mon, 9 Nov 2009 16:36:29 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAA0arx8074116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Nov 2009 18:36:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF8B5A4.3040500@nostrum.com> Date: Tue, 10 Nov 2009 09:36:52 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Subject: [sipcore] IETF 76 SIPCORE Minutes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:36:31 -0000 [as chair] A draft version of the minutes from our face-to-face meeting in Hiroshima has been posted. Please review, and provide any comments you may have to the chairs: http://www.ietf.org/proceedings/09nov/minutes/sipcore.html Note that I will be on vacation and out of contact next week. Any comments received after Friday noon (Japanese Standard Time) will be processed on or shortly after November 21st. /a From george.foti@ericsson.com Mon Nov 9 16:39:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320413A6955 for ; Mon, 9 Nov 2009 16:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOIlj63VasGu for ; Mon, 9 Nov 2009 16:39:39 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 203D33A68A5 for ; Mon, 9 Nov 2009 16:39:35 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAA0dvjI019530; Mon, 9 Nov 2009 18:39:58 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 18:38:40 -0600 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 18:38:40 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 9 Nov 2009 19:38:39 -0500 From: George Foti To: Christer Holmberg , Jeroen van Bemmel Date: Mon, 9 Nov 2009 19:38:36 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rwwAAJyZEA= Message-ID: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@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-OriginalArrivalTime: 10 Nov 2009 00:38:40.0096 (UTC) FILETIME=[25D58E00:01CA619E] Cc: "sipcore@ietf.org" , Linyi TIAN Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:39:40 -0000 I would second Christer on the absolute need to support mid-dialog changes = as mandatory and not optional. The whole idea of Recv-Info is to say what U are *WILLING* to *receive*. If I cant change that capability mid-dialog to stop reception that I no lon= ger desire, then why bother with the framework. This in effect would be almost equivalent to legacy SIP INFO and where I ha= ve no control, and where I can reject what I don't want to receive. Recv-Info MUST allow me to get away from that, i.e receive and reject. Hope that helps. George =20 -----Original Message----- From: Christer Holmberg=20 Sent: Monday, November 09, 2009 6:36 PM To: Jeroen van Bemmel; George Foti Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r Hi all, I appretiate the input you have all provided.=20 I am also glad that George provided some more details on the IPTV usage, si= nce I wasn't able to do that myself during the SIPCORE session. But, I thin= k that shows that there is an interest for this framework. I still strgonly believe that mid-call changes are needed, and that forbidd= ing them may prevent future usages - or usage people are working on at the= moment. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 10. marraskuuta 2009 0:04 To: George Foti Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r George, OK, now we're getting somewhere - my point was to get the requirements bein= g designed for explicitly on the table, and to not make things harder than = they need to be I don't know if there was ever an explicit list of requirements being addre= ssed by Info Event - if people agree that your use case below (i.e.=20 mid-dialog changes to the set of INFO packages a UA is willing to accept IN= FO requests for, for congestion avoidance purposes) is valid, in scope of t= his draft and desirable, then I suppose we could add the mechanism.=20 I'd suggest that the editor add a separate section discussing such mid-dial= og changes to the set, its intended purpose, and the required UA behavior (= under section 4.2 perhaps) Regards, Jeroen George Foti wrote: > The ability for a SIP device to remove support for the reception of an in= fo-package mid-dialog is necessary and not an option. > Some applications will not use SIP INFO any more if this feature is=20 > taken out > > If we take the IPTV application, where we have an info package to=20 > allow STBs and TV devices to tell the network the content currently=20 > being watched (what the device is tuned to) > > The network must be able to stop TV devices from reporting the programs = they are tuned when it so desires. > Given that reporting occurs after end users start and stop zapping, and g= iven that zapping occurs after TV ads start showing up, and that typically = all IPTV users start zapping at that time, the network can be crippled with= all devices reporting at the same time if it cant stop them at will. > > Just ignoring the SIP INFO as suggested by some does not make sense as th= e congestion that this produces from devices re-attempting to send etc, wil= l cause even more harm. > > As such, comparing info-packages negotiated at dialog start-up to dialog = route is not appropriate and pre-judges how applications work, which is qui= te dangerous. > > Certainly removing this flexibility will limit the ability to use the=20 > SIP INFO and is a step backward and makes the use of legacy SIP INFO=20 > more attractive without the overhead as the result of rejection is the=20 > same > > Thanks > George > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Linyi TIAN > Sent: Monday, November 09, 2009 3:42 AM > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header > > This looks more reasonable and simple. If we don't see real use cases for= changing set during the dialog we'd better not have a technical solution f= or it. Or even there is limited use case, it is no harm to use status code = to ignore the INFO. This will reduce the protocol impact and simply the imp= lementation. > > So for the time being I support Jeroen's approach unless something new is= introduced. > > Cheers, > Linyi > > =20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf >> =20 > Of > =20 >> Jeroen van Bemmel >> Sent: Monday, November 09, 2009 3:37 PM >> To: DRAGE, Keith (Keith) >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> =20 > header > =20 >> I also think it's overkill. Furthermore, I don't see a real world use=20 >> case for changing the set of supported INFO packages mid-dialog. >> Surely the UAS can simply reply with a 403 response when it receives=20 >> an INFO request which it doesn't want to process anymore? >> >> To me, INFO packages should be like the Dialog's route set: learn the=20 >> supported set from the initial INVITE and 1xx-2xx responses, after=20 >> that don't change it anymore >> >> Regards, >> Jeroen >> >> PS The usage of 'nil' to denote no supported packages is not=20 >> consistent with conventions used today, e.g. for Supported (suggest=20 >> to simply use an empty value instead) >> >> DRAGE, Keith (Keith) wrote: >> =20 >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which=20 >>> could >>> =20 > also be > =20 >> understood from the paraphrase of the SIPCORE discussion. >> =20 >>> Secondly can I still have more detail (arrow diagram) on the=20 >>> scenario we >>> =20 > are trying > =20 >> to solve for 3pcc. I can't see if there is a simple solution if the >> =20 > problem is > =20 >> insufficiently clear. >> =20 >>> Keith >>> >>> >>> =20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info header >>>> >>>> That works for me, and it is sufficiently simple that everybody=20 >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> >>>> =20 >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>>>> discussed whether we should mandate to include Recv-Info in >>>>> >>>>> =20 >>>> re-INVITE >>>> >>>> =20 >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> >>>>> =20 >>>> the set of >>>> >>>> =20 >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> >>>>> =20 >>>> messages would >>>> >>>> =20 >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> >>>>> =20 >>>> says that >>>> >>>> =20 >>>>> the Recv-Info header only needs to be inserted if the set of Info=20 >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> >>>>> =20 >>>> implement >>>> >>>> =20 >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> =20 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > =20 From christer.holmberg@ericsson.com Mon Nov 9 16:47:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB73A3A6839 for ; Mon, 9 Nov 2009 16:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ+WBX8e6yBF for ; Mon, 9 Nov 2009 16:47:37 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B61D83A63EB for ; Mon, 9 Nov 2009 16:47:36 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-5d-4af8b842ab14 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 31.12.31706.248B8FA4; Tue, 10 Nov 2009 01:48:02 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 01:48:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA619F.74D1CFAF" Date: Tue, 10 Nov 2009 01:48:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO EVENTS: Empty header vs 'nil' thread-index: Acphn3S/zxdA8Ff+TwW7CM/kQLVh8A== From: "Christer Holmberg" To: X-OriginalArrivalTime: 10 Nov 2009 00:48:02.0209 (UTC) FILETIME=[74E13110:01CA619F] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] INFO EVENTS: Empty header vs 'nil' X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:47:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA619F.74D1CFAF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, As part of the WGLC comments, and other e-mail discussions, some people have requested to use an empty Recv-Info header, instead of a header with a 'nil' value, to indicate no Info Packages. The main reason is that it is more alligned with other SIP headers. Would someone object to such change? Regards, Christer ------_=_NextPart_001_01CA619F.74D1CFAF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable INFO EVENTS: Empty header vs 'nil'

Hi,

As part of the WGLC comments, and other = e-mail discussions, some people have requested to use an empty Recv-Info = header, instead of a header with a 'nil' value, to indicate no Info = Packages. The main reason is that it is more alligned with other SIP = headers.

Would someone object to such = change?

Regards,

Christer

------_=_NextPart_001_01CA619F.74D1CFAF-- From eburger@standardstrack.com Mon Nov 9 17:03:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DA73A69EF for ; Mon, 9 Nov 2009 17:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Aw4N2QXjRJ for ; Mon, 9 Nov 2009 17:03:43 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 5B4113A6959 for ; Mon, 9 Nov 2009 17:03:43 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N7f9O-0003Aj-J6; Mon, 09 Nov 2009 17:04:02 -0800 Message-Id: From: Eric Burger To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 10:04:06 +0900 References: X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:03:44 -0000 Specifically, "Specification Required" as described in BCP 26 / RFC 5226. On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > > Hi, > > At the SIPCORE session the issue about what is required to register > an Info Package. > > The outcome was that a specification (not necessarily not an IETF > document) is needed. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From drage@alcatel-lucent.com Mon Nov 9 17:10:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE9B3A69FA for ; Mon, 9 Nov 2009 17:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.431 X-Spam-Level: X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3jnj7fBr0mc for ; Mon, 9 Nov 2009 17:09:59 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 4C7A33A68C2 for ; Mon, 9 Nov 2009 17:09:59 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA1AL6Z012399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Nov 2009 02:10:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 10 Nov 2009 02:10:21 +0100 From: "DRAGE, Keith (Keith)" To: Eric Burger , Christer Holmberg Date: Tue, 10 Nov 2009 02:10:18 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package Thread-Index: AcphoblDozngXc3SQRmMixi8ORASiQAAMA/w 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:10:00 -0000 If you want to refer to RFC 5226 please define what you expect the expert r= eview to review. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Tuesday, November 10, 2009 1:04 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required=20 > to register an Info Package >=20 > Specifically, "Specification Required" as described in BCP 26=20 > / RFC 5226. >=20 > On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > At the SIPCORE session the issue about what is required to=20 > register an=20 > > Info Package. > > > > The outcome was that a specification (not necessarily not an IETF > > document) is needed. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Mon Nov 9 17:15:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ABC3A68C2 for ; Mon, 9 Nov 2009 17:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qLxwZbKS3ZY for ; Mon, 9 Nov 2009 17:14:48 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3DE143A6809 for ; Mon, 9 Nov 2009 17:14:21 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-af-4af8be86d621 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F3.B2.31706.68EB8FA4; Tue, 10 Nov 2009 02:14:46 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 02:14:05 +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: Tue, 10 Nov 2009 02:14:04 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package thread-index: AcphoblDozngXc3SQRmMixi8ORASiQAAMA/wAAAb+4A= References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Eric Burger" X-OriginalArrivalTime: 10 Nov 2009 01:14:05.0235 (UTC) FILETIME=[18840830:01CA61A3] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:15:01 -0000 Hi,=20 >If you want to refer to RFC 5226 please define what you expect the expert review to review. Yes. I will discuss with the chairs, Robert etc, in order to get the wording clear and correct. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Tuesday, November 10, 2009 1:04 AM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > register an Info Package >=20 > Specifically, "Specification Required" as described in BCP 26 / RFC=20 > 5226. >=20 > On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: >=20 > > > > Hi, > > > > At the SIPCORE session the issue about what is required to > register an > Info Package. > > > > The outcome was that a specification (not necessarily not an IETF > > document) is needed. > > > > Regards, > > > > Christer > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From drage@alcatel-lucent.com Mon Nov 9 17:24:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43783A6A18 for ; Mon, 9 Nov 2009 17:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHM-PJ8bjTWq for ; Mon, 9 Nov 2009 17:24:52 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id B65F13A6809 for ; Mon, 9 Nov 2009 17:24:51 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA1PFPm021094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Nov 2009 02:25:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 10 Nov 2009 02:25:14 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Eric Burger Date: Tue, 10 Nov 2009 02:25:13 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package Thread-Index: AcphoblDozngXc3SQRmMixi8ORASiQAAMA/wAAAb+4AAAGvk4A== 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:24:52 -0000 Does your response mean that you are proposing this should include expert r= eview. Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, November 10, 2009 1:14 AM > To: DRAGE, Keith (Keith); Eric Burger > Cc: sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: What is required=20 > to register anInfo Package >=20 >=20 > Hi,=20 >=20 > >If you want to refer to RFC 5226 please define what you expect the > expert review to review. >=20 > Yes. I will discuss with the chairs, Robert etc, in order to=20 > get the wording clear and correct. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > > Sent: Tuesday, November 10, 2009 1:04 AM > > To: Christer Holmberg > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > > register an Info Package > >=20 > > Specifically, "Specification Required" as described in BCP 26 / RFC=20 > > 5226. > >=20 > > On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > >=20 > > > > > > Hi, > > > > > > At the SIPCORE session the issue about what is required to > > register an > > Info Package. > > > > > > The outcome was that a specification (not necessarily not an IETF > > > document) is needed. > > > > > > Regards, > > > > > > Christer > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From christer.holmberg@ericsson.com Mon Nov 9 17:33:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3D13A6A3F for ; Mon, 9 Nov 2009 17:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZwydbbBKPcD for ; Mon, 9 Nov 2009 17:33:23 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B35E63A6A18 for ; Mon, 9 Nov 2009 17:33:22 -0800 (PST) X-AuditID: c1b4fb3e-b7bf6ae000005dda-a8-4af8c2fcd62a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 36.37.24026.CF2C8FA4; Tue, 10 Nov 2009 02:33:48 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 02:33:46 +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: Tue, 10 Nov 2009 02:33:46 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package thread-index: AcphoblDozngXc3SQRmMixi8ORASiQAAMA/wAAAb+4AAAGvk4AAANMEg References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Eric Burger" X-OriginalArrivalTime: 10 Nov 2009 01:33:46.0579 (UTC) FILETIME=[D8A6D230:01CA61A5] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:33:24 -0000 Hi,=20 >Does your response mean that you are proposing this should include expert review. That is my understanding, yes. IANA is supposed to request someone to review the package. But, the intention is not to have technical discussions about the mechanism as such. But, this is what I will need to get help from the chairs and Robert on - to make sure we have a clear understanding :) Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, November 10, 2009 1:14 AM > To: DRAGE, Keith (Keith); Eric Burger > Cc: sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > register anInfo Package >=20 >=20 > Hi, >=20 > >If you want to refer to RFC 5226 please define what you expect the > expert review to review. >=20 > Yes. I will discuss with the chairs, Robert etc, in order to get the=20 > wording clear and correct. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > > Sent: Tuesday, November 10, 2009 1:04 AM > > To: Christer Holmberg > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > > register an Info Package > >=20 > > Specifically, "Specification Required" as described in BCP 26 / RFC=20 > > 5226. > >=20 > > On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > >=20 > > > > > > Hi, > > > > > > At the SIPCORE session the issue about what is required to > > register an > > Info Package. > > > > > > The outcome was that a specification (not necessarily not an IETF > > > document) is needed. > > > > > > Regards, > > > > > > Christer > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From tianlinyi@huawei.com Mon Nov 9 17:41:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5762C28C291 for ; Mon, 9 Nov 2009 17:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrMY6gZzimdD for ; Mon, 9 Nov 2009 17:41:27 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7CF5C28C294 for ; Mon, 9 Nov 2009 17:41:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV00FWOE1RQ3@szxga04-in.huawei.com> for sipcore@ietf.org; Tue, 10 Nov 2009 09:41:51 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV003PME1RAK@szxga04-in.huawei.com> for sipcore@ietf.org; Tue, 10 Nov 2009 09:41:51 +0800 (CST) Received: from t34932n ([10.168.86.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV00DJEE1Q0Z@szxml06-in.huawei.com> for sipcore@ietf.org; Tue, 10 Nov 2009 09:41:51 +0800 (CST) Date: Tue, 10 Nov 2009 09:41:50 +0800 From: Linyi TIAN In-reply-to: To: 'George Foti' , 'Christer Holmberg' , 'Jeroen van Bemmel' Message-id: <010a01ca61a6$f9739f10$ec5add30$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rwwAAJyZEAAAdjsEA== References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:41:28 -0000 Hi, All The issue is that what use case we need to specify more than 2 Info Packages and in the middle we want to stop sending one of them. Even the case George mentioned it only needs one Info Package to be sent. In this case the UAS can simply use Recv-Info='nil' to stop sending the packages. We need a use case to justify this. I agree have mid-dialog negotiation is flexible but if no application requires this why not make it simple? Cheers, Linyi > -----Original Message----- > From: George Foti [mailto:george.foti@ericsson.com] > Sent: Tuesday, November 10, 2009 8:39 AM > To: Christer Holmberg; Jeroen van Bemmel > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header > > I would second Christer on the absolute need to support mid-dialog changes as > mandatory and not optional. > The whole idea of Recv-Info is to say what U are *WILLING* to *receive*. > If I cant change that capability mid-dialog to stop reception that I no longer desire, > then why bother with the framework. > > This in effect would be almost equivalent to legacy SIP INFO and where I have no > control, and where I can reject what I don't want to receive. > Recv-Info MUST allow me to get away from that, i.e receive and reject. > > Hope that helps. > George > > > > -----Original Message----- > From: Christer Holmberg > Sent: Monday, November 09, 2009 6:36 PM > To: Jeroen van Bemmel; George Foti > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header > > > Hi all, > > I appretiate the input you have all provided. > > I am also glad that George provided some more details on the IPTV usage, since I > wasn't able to do that myself during the SIPCORE session. But, I think that shows > that there is an interest for this framework. > > I still strgonly believe that mid-call changes are needed, and that forbidding them > may prevent future usages - or usage people are working on at the moment. > > > Regards, > > Christer > > > > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 10. marraskuuta 2009 0:04 > To: George Foti > Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header > > George, > > OK, now we're getting somewhere - my point was to get the requirements being > designed for explicitly on the table, and to not make things harder than they need to > be > > I don't know if there was ever an explicit list of requirements being addressed by Info > Event - if people agree that your use case below (i.e. > mid-dialog changes to the set of INFO packages a UA is willing to accept INFO > requests for, for congestion avoidance purposes) is valid, in scope of this draft and > desirable, then I suppose we could add the mechanism. > I'd suggest that the editor add a separate section discussing such mid-dialog > changes to the set, its intended purpose, and the required UA behavior (under > section 4.2 perhaps) > > Regards, > Jeroen > > George Foti wrote: > > The ability for a SIP device to remove support for the reception of an info-package > mid-dialog is necessary and not an option. > > Some applications will not use SIP INFO any more if this feature is > > taken out > > > > If we take the IPTV application, where we have an info package to > > allow STBs and TV devices to tell the network the content currently > > being watched (what the device is tuned to) > > > > The network must be able to stop TV devices from reporting the programs they > are tuned when it so desires. > > Given that reporting occurs after end users start and stop zapping, and given that > zapping occurs after TV ads start showing up, and that typically all IPTV users start > zapping at that time, the network can be crippled with all devices reporting at the > same time if it cant stop them at will. > > > > Just ignoring the SIP INFO as suggested by some does not make sense as the > congestion that this produces from devices re-attempting to send etc, will cause > even more harm. > > > > As such, comparing info-packages negotiated at dialog start-up to dialog route is > not appropriate and pre-judges how applications work, which is quite dangerous. > > > > Certainly removing this flexibility will limit the ability to use the > > SIP INFO and is a step backward and makes the use of legacy SIP INFO > > more attractive without the overhead as the result of rejection is the > > same > > > > Thanks > > George > > > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Linyi TIAN > > Sent: Monday, November 09, 2009 3:42 AM > > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > > header > > > > This looks more reasonable and simple. If we don't see real use cases for changing > set during the dialog we'd better not have a technical solution for it. Or even there is > limited use case, it is no harm to use status code to ignore the INFO. This will reduce > the protocol impact and simply the implementation. > > > > So for the time being I support Jeroen's approach unless something new is > introduced. > > > > Cheers, > > Linyi > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf > >> > > Of > > > >> Jeroen van Bemmel > >> Sent: Monday, November 09, 2009 3:37 PM > >> To: DRAGE, Keith (Keith) > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > >> > > header > > > >> I also think it's overkill. Furthermore, I don't see a real world use > >> case for changing the set of supported INFO packages mid-dialog. > >> Surely the UAS can simply reply with a 403 response when it receives > >> an INFO request which it doesn't want to process anymore? > >> > >> To me, INFO packages should be like the Dialog's route set: learn the > >> supported set from the initial INVITE and 1xx-2xx responses, after > >> that don't change it anymore > >> > >> Regards, > >> Jeroen > >> > >> PS The usage of 'nil' to denote no supported packages is not > >> consistent with conventions used today, e.g. for Supported (suggest > >> to simply use an empty value instead) > >> > >> DRAGE, Keith (Keith) wrote: > >> > >>> This works, but it seems overkill to me. > >>> > >>> Firstly can I ensure that this does not include REGISTER, which > >>> could > >>> > > also be > > > >> understood from the paraphrase of the SIPCORE discussion. > >> > >>> Secondly can I still have more detail (arrow diagram) on the > >>> scenario we > >>> > > are trying > > > >> to solve for 3pcc. I can't see if there is a simple solution if the > >> > > problem is > > > >> insufficiently clear. > >> > >>> Keith > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: Monday, November 09, 2009 4:15 AM > >>>> To: Christer Holmberg > >>>> Cc: sipcore@ietf.org > >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert > >>>> Recv-Info header > >>>> > >>>> That works for me, and it is sufficiently simple that everybody > >>>> should be able to implement it correctly. :-) > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Christer Holmberg wrote: > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we > >>>>> discussed whether we should mandate to include Recv-Info in > >>>>> > >>>>> > >>>> re-INVITE > >>>> > >>>> > >>>>> responses. > >>>>> > >>>>> The outcome of the discussion was that EVERY SIP messages where > >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>>>> > >>>>> > >>>> the set of > >>>> > >>>> > >>>>> Info Packages has changed or not. > >>>>> > >>>>> Based on the -03pre version of the draft the following > >>>>> > >>>>> > >>>> messages would > >>>> > >>>> > >>>>> be > >>>>> affected: > >>>>> > >>>>> INVITE + 18x + 200 > >>>>> Re-INVITE + 18x + 200 > >>>>> ACK > >>>>> UPDATE + 200 > >>>>> PRACK + 200 > >>>>> > >>>>> That is a change from previous versions of the draft, which > >>>>> > >>>>> > >>>> says that > >>>> > >>>> > >>>>> the Recv-Info header only needs to be inserted if the set of Info > >>>>> Packages changes. > >>>>> > >>>>> So, unless people have issues with that, my intention is to > >>>>> > >>>>> > >>>> implement > >>>> > >>>> > >>>>> the change in the next version of the draft. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > From drage@alcatel-lucent.com Mon Nov 9 17:53:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27B528C167 for ; Mon, 9 Nov 2009 17:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tglqB4N-0BoF for ; Mon, 9 Nov 2009 17:53:38 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A6E5F28C12D for ; Mon, 9 Nov 2009 17:53:37 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA1s2pK025960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Nov 2009 02:54:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 10 Nov 2009 02:54:02 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Eric Burger Date: Tue, 10 Nov 2009 02:54:00 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package Thread-Index: AcphoblDozngXc3SQRmMixi8ORASiQAAMA/wAAAb+4AAAGvk4AAANMEgAADFtQA= 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:53:39 -0000 In my view the only part that is expert reviewable is the bit that constitu= tes the IANA registration. I see no reason for performing an expert review of the Info package specifi= cation itself. regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, November 10, 2009 1:34 AM > To: DRAGE, Keith (Keith); Eric Burger > Cc: sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: What is required=20 > to register anInfo Package >=20 >=20 > Hi,=20 >=20 > >Does your response mean that you are proposing this should include > expert review. >=20 > That is my understanding, yes. IANA is supposed to request=20 > someone to review the package. But, the intention is not to=20 > have technical discussions about the mechanism as such. >=20 > But, this is what I will need to get help from the chairs and=20 > Robert on > - to make sure we have a clear understanding :) >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, November 10, 2009 1:14 AM > > To: DRAGE, Keith (Keith); Eric Burger > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > > register anInfo Package > >=20 > >=20 > > Hi, > >=20 > > >If you want to refer to RFC 5226 please define what you expect the > > expert review to review. > >=20 > > Yes. I will discuss with the chairs, Robert etc, in order=20 > to get the=20 > > wording clear and correct. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > > > Sent: Tuesday, November 10, 2009 1:04 AM > > > To: Christer Holmberg > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > > > register an Info Package > > >=20 > > > Specifically, "Specification Required" as described in=20 > BCP 26 / RFC=20 > > > 5226. > > >=20 > > > On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > > >=20 > > > > > > > > Hi, > > > > > > > > At the SIPCORE session the issue about what is required to > > > register an > > > Info Package. > > > > > > > > The outcome was that a specification (not necessarily=20 > not an IETF > > > > document) is needed. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > >=20 > = From christer.holmberg@ericsson.com Mon Nov 9 17:55:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77B128C1CE for ; Mon, 9 Nov 2009 17:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LFCShM3O33J for ; Mon, 9 Nov 2009 17:55:40 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CD1593A6A34 for ; Mon, 9 Nov 2009 17:55:24 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-72-4af8c8255ac5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E0.22.04191.528C8FA4; Tue, 10 Nov 2009 02:55:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 02:54:28 +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: Tue, 10 Nov 2009 02:54:27 +0100 Message-ID: In-Reply-To: <010a01ca61a6$f9739f10$ec5add30$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rwwAAJyZEAAAdjsEAAAnRug References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> <010a01ca61a6$f9739f10$ec5add30$@com> From: "Christer Holmberg" To: "Linyi TIAN" , "George Foti" , "Jeroen van Bemmel" X-OriginalArrivalTime: 10 Nov 2009 01:54:28.0298 (UTC) FILETIME=[BCC61AA0:01CA61A8] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:55:42 -0000 Hi,=20 >The issue is that what use case we need to specify more than 2 Info Packages and in the middle we want to stop sending=20 >one of them. Even the case George mentioned it only needs one Info Package to be sent. In this case the UAS can simply=20 >use Recv-Info=3D'nil' to stop sending the packages. Changing from 'Recv-Info:x' to 'Recv-Info:nil' *IS* a mid-call notification. >We need a use case to justify this. I agree have mid-dialog negotiation is flexible but if no application requires this=20 >why not make it simple?=20 The modfication parts has been in the draft for a long time, and we are now in WGLC (our 2nd WGLC, actually). And, we don't know about what applications will come. We should not again restrict something just because we don't have a use-case at this moment, if we can make it work. If there are use-cases which need this it will simply lead to that people continue using legacy INFO. Regards, Christer > -----Original Message----- > From: George Foti [mailto:george.foti@ericsson.com] > Sent: Tuesday, November 10, 2009 8:39 AM > To: Christer Holmberg; Jeroen van Bemmel > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header >=20 > I would second Christer on the absolute need to support mid-dialog=20 > changes as > mandatory and not optional. > The whole idea of Recv-Info is to say what U are *WILLING* to *receive*. > If I cant change that capability mid-dialog to stop reception that I=20 > no longer desire, > then why bother with the framework. >=20 > This in effect would be almost equivalent to legacy SIP INFO and where > I have no > control, and where I can reject what I don't want to receive. > Recv-Info MUST allow me to get away from that, i.e receive and reject. >=20 > Hope that helps. > George >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Monday, November 09, 2009 6:36 PM > To: Jeroen van Bemmel; George Foti > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header >=20 >=20 > Hi all, >=20 > I appretiate the input you have all provided. >=20 > I am also glad that George provided some more details on the IPTV=20 > usage, since I > wasn't able to do that myself during the SIPCORE session. But, I think that shows > that there is an interest for this framework. >=20 > I still strgonly believe that mid-call changes are needed, and that forbidding them > may prevent future usages - or usage people are working on at the moment. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 10. marraskuuta 2009 0:04 > To: George Foti > Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header >=20 > George, >=20 > OK, now we're getting somewhere - my point was to get the requirements being > designed for explicitly on the table, and to not make things harder=20 > than they need to > be >=20 > I don't know if there was ever an explicit list of requirements being addressed by Info > Event - if people agree that your use case below (i.e. > mid-dialog changes to the set of INFO packages a UA is willing to=20 > accept INFO > requests for, for congestion avoidance purposes) is valid, in scope of this draft and > desirable, then I suppose we could add the mechanism. > I'd suggest that the editor add a separate section discussing such mid-dialog > changes to the set, its intended purpose, and the required UA behavior (under > section 4.2 perhaps) >=20 > Regards, > Jeroen >=20 > George Foti wrote: > > The ability for a SIP device to remove support for the reception of=20 > > an info-package > mid-dialog is necessary and not an option. > > Some applications will not use SIP INFO any more if this feature is=20 > > taken out > > > > If we take the IPTV application, where we have an info package to=20 > > allow STBs and TV devices to tell the network the content currently=20 > > being watched (what the device is tuned to) > > > > The network must be able to stop TV devices from reporting the=20 > > programs they > are tuned when it so desires. > > Given that reporting occurs after end users start and stop zapping,=20 > > and given that > zapping occurs after TV ads start showing up, and that typically all=20 > IPTV users start > zapping at that time, the network can be crippled with all devices reporting at the > same time if it cant stop them at will. > > > > Just ignoring the SIP INFO as suggested by some does not make sense=20 > > as the > congestion that this produces from devices re-attempting to send etc,=20 > will cause > even more harm. > > > > As such, comparing info-packages negotiated at dialog start-up to=20 > > dialog route is > not appropriate and pre-judges how applications work, which is quite dangerous. > > > > Certainly removing this flexibility will limit the ability to use=20 > > the SIP INFO and is a step backward and makes the use of legacy SIP=20 > > INFO more attractive without the overhead as the result of rejection > > is the same > > > > Thanks > > George > > > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Linyi TIAN > > Sent: Monday, November 09, 2009 3:42 AM > > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > Recv-Info header > > > > This looks more reasonable and simple. If we don't see real use=20 > > cases for changing > set during the dialog we'd better not have a technical solution for=20 > it. Or even there is > limited use case, it is no harm to use status code to ignore the INFO. This will reduce > the protocol impact and simply the implementation. > > > > So for the time being I support Jeroen's approach unless something=20 > > new is > introduced. > > > > Cheers, > > Linyi > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf > >> > > Of > > > >> Jeroen van Bemmel > >> Sent: Monday, November 09, 2009 3:37 PM > >> To: DRAGE, Keith (Keith) > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >> Recv-Info > >> > > header > > > >> I also think it's overkill. Furthermore, I don't see a real world=20 > >> use case for changing the set of supported INFO packages mid-dialog. > >> Surely the UAS can simply reply with a 403 response when it=20 > >> receives an INFO request which it doesn't want to process anymore? > >> > >> To me, INFO packages should be like the Dialog's route set: learn=20 > >> the supported set from the initial INVITE and 1xx-2xx responses,=20 > >> after that don't change it anymore > >> > >> Regards, > >> Jeroen > >> > >> PS The usage of 'nil' to denote no supported packages is not=20 > >> consistent with conventions used today, e.g. for Supported (suggest > >> to simply use an empty value instead) > >> > >> DRAGE, Keith (Keith) wrote: > >> > >>> This works, but it seems overkill to me. > >>> > >>> Firstly can I ensure that this does not include REGISTER, which=20 > >>> could > >>> > > also be > > > >> understood from the paraphrase of the SIPCORE discussion. > >> > >>> Secondly can I still have more detail (arrow diagram) on the=20 > >>> scenario we > >>> > > are trying > > > >> to solve for 3pcc. I can't see if there is a simple solution if the > >> > > problem is > > > >> insufficiently clear. > >> > >>> Keith > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: Monday, November 09, 2009 4:15 AM > >>>> To: Christer Holmberg > >>>> Cc: sipcore@ietf.org > >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >>>> Recv-Info header > >>>> > >>>> That works for me, and it is sufficiently simple that everybody=20 > >>>> should be able to implement it correctly. :-) > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Christer Holmberg wrote: > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session=20 > >>>>> we discussed whether we should mandate to include Recv-Info in > >>>>> > >>>>> > >>>> re-INVITE > >>>> > >>>> > >>>>> responses. > >>>>> > >>>>> The outcome of the discussion was that EVERY SIP messages where=20 > >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>>>> > >>>>> > >>>> the set of > >>>> > >>>> > >>>>> Info Packages has changed or not. > >>>>> > >>>>> Based on the -03pre version of the draft the following > >>>>> > >>>>> > >>>> messages would > >>>> > >>>> > >>>>> be > >>>>> affected: > >>>>> > >>>>> INVITE + 18x + 200 > >>>>> Re-INVITE + 18x + 200 > >>>>> ACK > >>>>> UPDATE + 200 > >>>>> PRACK + 200 > >>>>> > >>>>> That is a change from previous versions of the draft, which > >>>>> > >>>>> > >>>> says that > >>>> > >>>> > >>>>> the Recv-Info header only needs to be inserted if the set of=20 > >>>>> Info Packages changes. > >>>>> > >>>>> So, unless people have issues with that, my intention is to > >>>>> > >>>>> > >>>> implement > >>>> > >>>> > >>>>> the change in the next version of the draft. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> > >>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > From adam@nostrum.com Mon Nov 9 17:59:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC78A3A69E2 for ; Mon, 9 Nov 2009 17:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QIWeMVf2Zsc for ; Mon, 9 Nov 2009 17:59:57 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 930483A68B1 for ; Mon, 9 Nov 2009 17:59:56 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAA20FTx080800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 20:00:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AF8C92E.1080806@nostrum.com> Date: Tue, 10 Nov 2009 11:00:14 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:59:57 -0000 [as an individual] Jon Peterson actually explained this pretty well during the session -- RFC 5226 only requires: "[The] use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations." And that is *all* they do. They evaluate whether it is clear enough to allow interoperability. Not whether it's a good idea, not whether it's secure -- merely that it is a specification that allows interoperability. /a On 11/10/09 10:10 AM, DRAGE, Keith (Keith) wrote: > If you want to refer to RFC 5226 please define what you expect the expert review to review. > > regards > > Keith > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger >> Sent: Tuesday, November 10, 2009 1:04 AM >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required >> to register an Info Package >> >> Specifically, "Specification Required" as described in BCP 26 >> / RFC 5226. >> >> On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: >> >> >>> Hi, >>> >>> At the SIPCORE session the issue about what is required to >>> >> register an >> >>> Info Package. >>> >>> The outcome was that a specification (not necessarily not an IETF >>> document) is needed. >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From drage@alcatel-lucent.com Mon Nov 9 18:09:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C039F3A6855 for ; Mon, 9 Nov 2009 18:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0uXPuxosblr for ; Mon, 9 Nov 2009 18:09:35 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 4874D3A68A9 for ; Mon, 9 Nov 2009 18:09:19 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA29h7j024725 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Nov 2009 03:09:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 10 Nov 2009 03:09:43 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Tue, 10 Nov 2009 03:09:41 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package Thread-Index: AcphqZCpazic1kQvQC66qH0OCFDLEwAADliw Message-ID: References: <4AF8C92E.1080806@nostrum.com> In-Reply-To: <4AF8C92E.1080806@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:09:35 -0000 And I think we are therefore into the problem. The package is a means of transporting an application. We cannot set ourselves up as gods to review the application, which could w= ell be part of the specification. I also believe it is beyond the scope of = IETF to even think about that. It is like IETF insisting on reviewing all p= ort number usage for interoperability. So what remains to be reviewed of the Info-Package. Not a lot that helps in= teroperability I would content. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Tuesday, November 10, 2009 2:00 AM > To: DRAGE, Keith (Keith) > Cc: Eric Burger; Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required=20 > to register an Info Package >=20 > [as an individual] >=20 > Jon Peterson actually explained this pretty well during the=20 > session -- RFC 5226 only requires: >=20 > "[The] use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations." >=20 > And that is *all* they do. They evaluate whether it is clear=20 > enough to allow interoperability. Not whether it's a good=20 > idea, not whether it's secure -- merely that it is a=20 > specification that allows interoperability. >=20 > /a >=20 > On 11/10/09 10:10 AM, DRAGE, Keith (Keith) wrote: > > If you want to refer to RFC 5226 please define what you=20 > expect the expert review to review. > > > > regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > >> Sent: Tuesday, November 10, 2009 1:04 AM > >> To: Christer Holmberg > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > >> register an Info Package > >> > >> Specifically, "Specification Required" as described in BCP=20 > 26 / RFC=20 > >> 5226. > >> > >> On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > >> > >> =20 > >>> Hi, > >>> > >>> At the SIPCORE session the issue about what is required to > >>> =20 > >> register an > >> =20 > >>> Info Package. > >>> > >>> The outcome was that a specification (not necessarily not an IETF > >>> document) is needed. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> =20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 >=20 > = From drage@alcatel-lucent.com Mon Nov 9 20:00:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539D28C132 for ; Mon, 9 Nov 2009 20:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.403 X-Spam-Level: X-Spam-Status: No, score=-5.403 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S69AML4BGN4A for ; Mon, 9 Nov 2009 20:00:12 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 532423A6822 for ; Mon, 9 Nov 2009 20:00:11 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAA3xVSG031480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Nov 2009 04:59:31 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 10 Nov 2009 04:59:31 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Linyi TIAN , George Foti , Jeroen van Bemmel Date: Tue, 10 Nov 2009 04:59:27 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rwwAAJyZEAAAdjsEAAAnRugAARwaHA= Message-ID: References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> <010a01ca61a6$f9739f10$ec5add30$@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:00:13 -0000 We seem to have drifted off the original issue. My understanding was that we need to provide for the new endpoints learning= the info packages supported after a redirection of transfer. That means usage within a reINVITE is in some of these cases at least neede= d. My concern is that I want to understand still which methods need to exchang= e this, and to do that I still need to see the flows justifying anything el= se other than the reINVITE.=20 And I am still concerned about having to repeat in all and anything; I stil= l want to see if it is possible to define a scheme where it is included onl= y if it changes. regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, November 10, 2009 1:54 AM > To: Linyi TIAN; George Foti; Jeroen van Bemmel > Cc: DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 >=20 > Hi,=20 >=20 > >The issue is that what use case we need to specify more than 2 Info > Packages and in the middle we want to stop sending=20 > >one of them. Even the case George mentioned it only needs one Info > Package to be sent. In this case the UAS can simply=20 > >use Recv-Info=3D'nil' to stop sending the packages. >=20 > Changing from 'Recv-Info:x' to 'Recv-Info:nil' *IS* a=20 > mid-call notification. >=20 > >We need a use case to justify this. I agree have mid-dialog=20 > negotiation > is flexible but if no application requires this=20 > >why not make it simple?=20 >=20 > The modfication parts has been in the draft for a long time,=20 > and we are now in WGLC (our 2nd WGLC, actually). >=20 > And, we don't know about what applications will come. We=20 > should not again restrict something just because we don't=20 > have a use-case at this moment, if we can make it work. If=20 > there are use-cases which need this it will simply lead to=20 > that people continue using legacy INFO. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: George Foti [mailto:george.foti@ericsson.com] > > Sent: Tuesday, November 10, 2009 8:39 AM > > To: Christer Holmberg; Jeroen van Bemmel > > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > > I would second Christer on the absolute need to support mid-dialog=20 > > changes > as > > mandatory and not optional. > > The whole idea of Recv-Info is to say what U are *WILLING* to > *receive*. > > If I cant change that capability mid-dialog to stop=20 > reception that I=20 > > no > longer desire, > > then why bother with the framework. > >=20 > > This in effect would be almost equivalent to legacy SIP=20 > INFO and where >=20 > > I > have no > > control, and where I can reject what I don't want to receive. > > Recv-Info MUST allow me to get away from that, i.e receive=20 > and reject. > >=20 > > Hope that helps. > > George > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Monday, November 09, 2009 6:36 PM > > To: Jeroen van Bemmel; George Foti > > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > >=20 > > Hi all, > >=20 > > I appretiate the input you have all provided. > >=20 > > I am also glad that George provided some more details on the IPTV=20 > > usage, > since I > > wasn't able to do that myself during the SIPCORE session.=20 > But, I think > that shows > > that there is an interest for this framework. > >=20 > > I still strgonly believe that mid-call changes are needed, and that > forbidding them > > may prevent future usages - or usage people are working on at the > moment. > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: 10. marraskuuta 2009 0:04 > > To: George Foti > > Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; > sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > > George, > >=20 > > OK, now we're getting somewhere - my point was to get the=20 > requirements > being > > designed for explicitly on the table, and to not make things harder=20 > > than > they need to > > be > >=20 > > I don't know if there was ever an explicit list of=20 > requirements being > addressed by Info > > Event - if people agree that your use case below (i.e. > > mid-dialog changes to the set of INFO packages a UA is willing to=20 > > accept > INFO > > requests for, for congestion avoidance purposes) is valid,=20 > in scope of > this draft and > > desirable, then I suppose we could add the mechanism. > > I'd suggest that the editor add a separate section discussing such > mid-dialog > > changes to the set, its intended purpose, and the required=20 > UA behavior > (under > > section 4.2 perhaps) > >=20 > > Regards, > > Jeroen > >=20 > > George Foti wrote: > > > The ability for a SIP device to remove support for the=20 > reception of=20 > > > an > info-package > > mid-dialog is necessary and not an option. > > > Some applications will not use SIP INFO any more if this=20 > feature is=20 > > > taken out > > > > > > If we take the IPTV application, where we have an info package to=20 > > > allow STBs and TV devices to tell the network the content=20 > currently=20 > > > being watched (what the device is tuned to) > > > > > > The network must be able to stop TV devices from reporting the=20 > > > programs > they > > are tuned when it so desires. > > > Given that reporting occurs after end users start and=20 > stop zapping,=20 > > > and > given that > > zapping occurs after TV ads start showing up, and that=20 > typically all=20 > > IPTV > users start > > zapping at that time, the network can be crippled with all devices > reporting at the > > same time if it cant stop them at will. > > > > > > Just ignoring the SIP INFO as suggested by some does not=20 > make sense=20 > > > as > the > > congestion that this produces from devices re-attempting to=20 > send etc,=20 > > will > cause > > even more harm. > > > > > > As such, comparing info-packages negotiated at dialog start-up to=20 > > > dialog > route is > > not appropriate and pre-judges how applications work, which is quite > dangerous. > > > > > > Certainly removing this flexibility will limit the ability to use=20 > > > the SIP INFO and is a step backward and makes the use of=20 > legacy SIP=20 > > > INFO more attractive without the overhead as the result=20 > of rejection >=20 > > > is the same > > > > > > Thanks > > > George > > > > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > > > Behalf Of Linyi TIAN > > > Sent: Monday, November 09, 2009 3:42 AM > > > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > > Recv-Info header > > > > > > This looks more reasonable and simple. If we don't see real use=20 > > > cases > for changing > > set during the dialog we'd better not have a technical solution for=20 > > it. Or > even there is > > limited use case, it is no harm to use status code to=20 > ignore the INFO. > This will reduce > > the protocol impact and simply the implementation. > > > > > > So for the time being I support Jeroen's approach unless=20 > something=20 > > > new > is > > introduced. > > > > > > Cheers, > > > Linyi > > > > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On >=20 > > >> Behalf > > >> > > > Of > > > > > >> Jeroen van Bemmel > > >> Sent: Monday, November 09, 2009 3:37 PM > > >> To: DRAGE, Keith (Keith) > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > >> Recv-Info > > >> > > > header > > > > > >> I also think it's overkill. Furthermore, I don't see a=20 > real world=20 > > >> use case for changing the set of supported INFO packages > mid-dialog. > > >> Surely the UAS can simply reply with a 403 response when it=20 > > >> receives an INFO request which it doesn't want to=20 > process anymore? > > >> > > >> To me, INFO packages should be like the Dialog's route=20 > set: learn=20 > > >> the supported set from the initial INVITE and 1xx-2xx responses,=20 > > >> after that don't change it anymore > > >> > > >> Regards, > > >> Jeroen > > >> > > >> PS The usage of 'nil' to denote no supported packages is not=20 > > >> consistent with conventions used today, e.g. for=20 > Supported (suggest >=20 > > >> to simply use an empty value instead) > > >> > > >> DRAGE, Keith (Keith) wrote: > > >> > > >>> This works, but it seems overkill to me. > > >>> > > >>> Firstly can I ensure that this does not include REGISTER, which=20 > > >>> could > > >>> > > > also be > > > > > >> understood from the paraphrase of the SIPCORE discussion. > > >> > > >>> Secondly can I still have more detail (arrow diagram) on the=20 > > >>> scenario we > > >>> > > > are trying > > > > > >> to solve for 3pcc. I can't see if there is a simple=20 > solution if the > > >> > > > problem is > > > > > >> insufficiently clear. > > >> > > >>> Keith > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: sipcore-bounces@ietf.org > > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >>>> Sent: Monday, November 09, 2009 4:15 AM > > >>>> To: Christer Holmberg > > >>>> Cc: sipcore@ietf.org > > >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > >>>> Recv-Info header > > >>>> > > >>>> That works for me, and it is sufficiently simple that=20 > everybody=20 > > >>>> should be able to implement it correctly. :-) > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>> Christer Holmberg wrote: > > >>>> > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> Based on the 3pcc issue raised by Paul, at the=20 > SIPCORE session=20 > > >>>>> we discussed whether we should mandate to include Recv-Info in > > >>>>> > > >>>>> > > >>>> re-INVITE > > >>>> > > >>>> > > >>>>> responses. > > >>>>> > > >>>>> The outcome of the discussion was that EVERY SIP=20 > messages where=20 > > >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > > >>>>> > > >>>>> > > >>>> the set of > > >>>> > > >>>> > > >>>>> Info Packages has changed or not. > > >>>>> > > >>>>> Based on the -03pre version of the draft the following > > >>>>> > > >>>>> > > >>>> messages would > > >>>> > > >>>> > > >>>>> be > > >>>>> affected: > > >>>>> > > >>>>> INVITE + 18x + 200 > > >>>>> Re-INVITE + 18x + 200 > > >>>>> ACK > > >>>>> UPDATE + 200 > > >>>>> PRACK + 200 > > >>>>> > > >>>>> That is a change from previous versions of the draft, which > > >>>>> > > >>>>> > > >>>> says that > > >>>> > > >>>> > > >>>>> the Recv-Info header only needs to be inserted if the set of=20 > > >>>>> Info Packages changes. > > >>>>> > > >>>>> So, unless people have issues with that, my intention is to > > >>>>> > > >>>>> > > >>>> implement > > >>>> > > >>>> > > >>>>> the change in the next version of the draft. > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Christer > > >>>>> > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> sipcore mailing list > > >>>> sipcore@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> sipcore mailing list > > >>> sipcore@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sipcore > > >>> > > >>> > > >>> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >=20 > = From christer.holmberg@ericsson.com Mon Nov 9 20:25:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB713A6916 for ; Mon, 9 Nov 2009 20:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4OXNZsjT98k for ; Mon, 9 Nov 2009 20:25:26 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 40CFB3A6910 for ; Mon, 9 Nov 2009 20:25:25 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-64-4af8eb4ecbcb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A9.57.04191.E4BE8FA4; Tue, 10 Nov 2009 05:25:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 05:24: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 05:20:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register an Info Package thread-index: AcphqZCpazic1kQvQC66qH0OCFDLEwAADliwAATX8Cs= References: <4AF8C92E.1080806@nostrum.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Adam Roach" X-OriginalArrivalTime: 10 Nov 2009 04:24:56.0657 (UTC) FILETIME=[C2185C10:01CA61BD] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:25:27 -0000 Hi, I guess the expert reviewer CAN make sure that the Info Package does not = specify things which break the core I-P mechanism (ie that a 469 should = terminate the whole dialog etc), or put other requirements on the SIP = protocol. However, as Keith indicated (unless I missunderstood), in order to = figure out whether the CONTENT of the I-P causes any interop issues, one = would need to have detailed knowledge of the applications using the I-P. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] L=E4hetetty: ti 10.11.2009 3:09 Vastaanottaja: Adam Roach Kopio: Eric Burger; Christer Holmberg; sipcore@ietf.org Aihe: RE: [sipcore] INFO EVENT @ IETF#76: What is required to register = anInfo Package =20 And I think we are therefore into the problem. The package is a means of transporting an application. We cannot set ourselves up as gods to review the application, which = could well be part of the specification. I also believe it is beyond the = scope of IETF to even think about that. It is like IETF insisting on = reviewing all port number usage for interoperability. So what remains to be reviewed of the Info-Package. Not a lot that helps = interoperability I would content. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Tuesday, November 10, 2009 2:00 AM > To: DRAGE, Keith (Keith) > Cc: Eric Burger; Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required=20 > to register an Info Package >=20 > [as an individual] >=20 > Jon Peterson actually explained this pretty well during the=20 > session -- RFC 5226 only requires: >=20 > "[The] use of a Designated > Expert, who will review the public specification and > evaluate whether it is sufficiently clear to allow > interoperable implementations." >=20 > And that is *all* they do. They evaluate whether it is clear=20 > enough to allow interoperability. Not whether it's a good=20 > idea, not whether it's secure -- merely that it is a=20 > specification that allows interoperability. >=20 > /a >=20 > On 11/10/09 10:10 AM, DRAGE, Keith (Keith) wrote: > > If you want to refer to RFC 5226 please define what you=20 > expect the expert review to review. > > > > regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > >> Sent: Tuesday, November 10, 2009 1:04 AM > >> To: Christer Holmberg > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to=20 > >> register an Info Package > >> > >> Specifically, "Specification Required" as described in BCP=20 > 26 / RFC=20 > >> 5226. > >> > >> On Nov 9, 2009, at 4:37 PM, Christer Holmberg wrote: > >> > >> =20 > >>> Hi, > >>> > >>> At the SIPCORE session the issue about what is required to > >>> =20 > >> register an > >> =20 > >>> Info Package. > >>> > >>> The outcome was that a specification (not necessarily not an IETF > >>> document) is needed. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> =20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 >=20 >=20 From christer.holmberg@ericsson.com Mon Nov 9 20:29:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFFC3A6915 for ; Mon, 9 Nov 2009 20:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvG7tnTE2G3c for ; Mon, 9 Nov 2009 20:29:55 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id CB53D3A698E for ; Mon, 9 Nov 2009 20:29:54 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-eb-4af8ec5c7029 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 02.09.31706.C5CE8FA4; Tue, 10 Nov 2009 05:30:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 05:30:20 +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 Date: Tue, 10 Nov 2009 05:26:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcphgClUlMGYlaZfQwCs57Ox13kGjAAE2rwwAAJyZEAAAdjsEAAAnRugAARwaHAAAT2l+Q== References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <01ba01ca6118$8f995320$aecbf960$@com> <4AF883BE.5000408@zonnet.nl> <010a01ca61a6$f9739f10$ec5add30$@com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Linyi TIAN" , "George Foti" , "Jeroen van Bemmel" X-OriginalArrivalTime: 10 Nov 2009 04:30:20.0319 (UTC) FILETIME=[830342F0:01CA61BE] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:29:57 -0000 Hi, >My understanding was that we need to provide for the new endpoints = learning the info packages supported=20 >after a redirection of transfer. > >My concern is that I want to understand still which methods need to = exchange this, and to do that I still=20 >need to see the flows justifying anything else other than the reINVITE. = My suggestion is that we, within a dialog, allow Recv-Info in = (re-)INVITE and UPDATE. UPDATE is useful if you want to change the set = within a "normal" UE-to-UE dialog. >And I am still concerned about having to repeat in all and anything; I = still want to see if it is possible=20 >to define a scheme where it is included only if it changes. I agree. And, again, I am not even sure that mandating it in every message would = actually solve Paul's issue. But, I hope Paul will comment on that. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, November 10, 2009 1:54 AM > To: Linyi TIAN; George Foti; Jeroen van Bemmel > Cc: DRAGE, Keith (Keith); sipcore@ietf.org > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 >=20 > Hi,=20 >=20 > >The issue is that what use case we need to specify more than 2 Info > Packages and in the middle we want to stop sending=20 > >one of them. Even the case George mentioned it only needs one Info > Package to be sent. In this case the UAS can simply=20 > >use Recv-Info=3D'nil' to stop sending the packages. >=20 > Changing from 'Recv-Info:x' to 'Recv-Info:nil' *IS* a=20 > mid-call notification. >=20 > >We need a use case to justify this. I agree have mid-dialog=20 > negotiation > is flexible but if no application requires this=20 > >why not make it simple?=20 >=20 > The modfication parts has been in the draft for a long time,=20 > and we are now in WGLC (our 2nd WGLC, actually). >=20 > And, we don't know about what applications will come. We=20 > should not again restrict something just because we don't=20 > have a use-case at this moment, if we can make it work. If=20 > there are use-cases which need this it will simply lead to=20 > that people continue using legacy INFO. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: George Foti [mailto:george.foti@ericsson.com] > > Sent: Tuesday, November 10, 2009 8:39 AM > > To: Christer Holmberg; Jeroen van Bemmel > > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > > I would second Christer on the absolute need to support mid-dialog=20 > > changes > as > > mandatory and not optional. > > The whole idea of Recv-Info is to say what U are *WILLING* to > *receive*. > > If I cant change that capability mid-dialog to stop=20 > reception that I=20 > > no > longer desire, > > then why bother with the framework. > >=20 > > This in effect would be almost equivalent to legacy SIP=20 > INFO and where >=20 > > I > have no > > control, and where I can reject what I don't want to receive. > > Recv-Info MUST allow me to get away from that, i.e receive=20 > and reject. > >=20 > > Hope that helps. > > George > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Monday, November 09, 2009 6:36 PM > > To: Jeroen van Bemmel; George Foti > > Cc: Linyi TIAN; DRAGE, Keith (Keith); sipcore@ietf.org > > Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > >=20 > > Hi all, > >=20 > > I appretiate the input you have all provided. > >=20 > > I am also glad that George provided some more details on the IPTV=20 > > usage, > since I > > wasn't able to do that myself during the SIPCORE session.=20 > But, I think > that shows > > that there is an interest for this framework. > >=20 > > I still strgonly believe that mid-call changes are needed, and that > forbidding them > > may prevent future usages - or usage people are working on at the > moment. > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: 10. marraskuuta 2009 0:04 > > To: George Foti > > Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; > sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info > header > >=20 > > George, > >=20 > > OK, now we're getting somewhere - my point was to get the=20 > requirements > being > > designed for explicitly on the table, and to not make things harder=20 > > than > they need to > > be > >=20 > > I don't know if there was ever an explicit list of=20 > requirements being > addressed by Info > > Event - if people agree that your use case below (i.e. > > mid-dialog changes to the set of INFO packages a UA is willing to=20 > > accept > INFO > > requests for, for congestion avoidance purposes) is valid,=20 > in scope of > this draft and > > desirable, then I suppose we could add the mechanism. > > I'd suggest that the editor add a separate section discussing such > mid-dialog > > changes to the set, its intended purpose, and the required=20 > UA behavior > (under > > section 4.2 perhaps) > >=20 > > Regards, > > Jeroen > >=20 > > George Foti wrote: > > > The ability for a SIP device to remove support for the=20 > reception of=20 > > > an > info-package > > mid-dialog is necessary and not an option. > > > Some applications will not use SIP INFO any more if this=20 > feature is=20 > > > taken out > > > > > > If we take the IPTV application, where we have an info package to=20 > > > allow STBs and TV devices to tell the network the content=20 > currently=20 > > > being watched (what the device is tuned to) > > > > > > The network must be able to stop TV devices from reporting the=20 > > > programs > they > > are tuned when it so desires. > > > Given that reporting occurs after end users start and=20 > stop zapping,=20 > > > and > given that > > zapping occurs after TV ads start showing up, and that=20 > typically all=20 > > IPTV > users start > > zapping at that time, the network can be crippled with all devices > reporting at the > > same time if it cant stop them at will. > > > > > > Just ignoring the SIP INFO as suggested by some does not=20 > make sense=20 > > > as > the > > congestion that this produces from devices re-attempting to=20 > send etc,=20 > > will > cause > > even more harm. > > > > > > As such, comparing info-packages negotiated at dialog start-up to=20 > > > dialog > route is > > not appropriate and pre-judges how applications work, which is quite > dangerous. > > > > > > Certainly removing this flexibility will limit the ability to use=20 > > > the SIP INFO and is a step backward and makes the use of=20 > legacy SIP=20 > > > INFO more attractive without the overhead as the result=20 > of rejection >=20 > > > is the same > > > > > > Thanks > > > George > > > > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > > > Behalf Of Linyi TIAN > > > Sent: Monday, November 09, 2009 3:42 AM > > > To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)' > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > > Recv-Info header > > > > > > This looks more reasonable and simple. If we don't see real use=20 > > > cases > for changing > > set during the dialog we'd better not have a technical solution for=20 > > it. Or > even there is > > limited use case, it is no harm to use status code to=20 > ignore the INFO. > This will reduce > > the protocol impact and simply the implementation. > > > > > > So for the time being I support Jeroen's approach unless=20 > something=20 > > > new > is > > introduced. > > > > > > Cheers, > > > Linyi > > > > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On >=20 > > >> Behalf > > >> > > > Of > > > > > >> Jeroen van Bemmel > > >> Sent: Monday, November 09, 2009 3:37 PM > > >> To: DRAGE, Keith (Keith) > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > >> Recv-Info > > >> > > > header > > > > > >> I also think it's overkill. Furthermore, I don't see a=20 > real world=20 > > >> use case for changing the set of supported INFO packages > mid-dialog. > > >> Surely the UAS can simply reply with a 403 response when it=20 > > >> receives an INFO request which it doesn't want to=20 > process anymore? > > >> > > >> To me, INFO packages should be like the Dialog's route=20 > set: learn=20 > > >> the supported set from the initial INVITE and 1xx-2xx responses,=20 > > >> after that don't change it anymore > > >> > > >> Regards, > > >> Jeroen > > >> > > >> PS The usage of 'nil' to denote no supported packages is not=20 > > >> consistent with conventions used today, e.g. for=20 > Supported (suggest >=20 > > >> to simply use an empty value instead) > > >> > > >> DRAGE, Keith (Keith) wrote: > > >> > > >>> This works, but it seems overkill to me. > > >>> > > >>> Firstly can I ensure that this does not include REGISTER, which=20 > > >>> could > > >>> > > > also be > > > > > >> understood from the paraphrase of the SIPCORE discussion. > > >> > > >>> Secondly can I still have more detail (arrow diagram) on the=20 > > >>> scenario we > > >>> > > > are trying > > > > > >> to solve for 3pcc. I can't see if there is a simple=20 > solution if the > > >> > > > problem is > > > > > >> insufficiently clear. > > >> > > >>> Keith > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: sipcore-bounces@ietf.org > > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >>>> Sent: Monday, November 09, 2009 4:15 AM > > >>>> To: Christer Holmberg > > >>>> Cc: sipcore@ietf.org > > >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > > >>>> Recv-Info header > > >>>> > > >>>> That works for me, and it is sufficiently simple that=20 > everybody=20 > > >>>> should be able to implement it correctly. :-) > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>> Christer Holmberg wrote: > > >>>> > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> Based on the 3pcc issue raised by Paul, at the=20 > SIPCORE session=20 > > >>>>> we discussed whether we should mandate to include Recv-Info in > > >>>>> > > >>>>> > > >>>> re-INVITE > > >>>> > > >>>> > > >>>>> responses. > > >>>>> > > >>>>> The outcome of the discussion was that EVERY SIP=20 > messages where=20 > > >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > > >>>>> > > >>>>> > > >>>> the set of > > >>>> > > >>>> > > >>>>> Info Packages has changed or not. > > >>>>> > > >>>>> Based on the -03pre version of the draft the following > > >>>>> > > >>>>> > > >>>> messages would > > >>>> > > >>>> > > >>>>> be > > >>>>> affected: > > >>>>> > > >>>>> INVITE + 18x + 200 > > >>>>> Re-INVITE + 18x + 200 > > >>>>> ACK > > >>>>> UPDATE + 200 > > >>>>> PRACK + 200 > > >>>>> > > >>>>> That is a change from previous versions of the draft, which > > >>>>> > > >>>>> > > >>>> says that > > >>>> > > >>>> > > >>>>> the Recv-Info header only needs to be inserted if the set of=20 > > >>>>> Info Packages changes. > > >>>>> > > >>>>> So, unless people have issues with that, my intention is to > > >>>>> > > >>>>> > > >>>> implement > > >>>> > > >>>> > > >>>>> the change in the next version of the draft. > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>>> Christer > > >>>>> > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> sipcore mailing list > > >>>> sipcore@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sipcore > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> sipcore mailing list > > >>> sipcore@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sipcore > > >>> > > >>> > > >>> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >=20 >=20 From eburger@standardstrack.com Mon Nov 9 22:39:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9683A6867 for ; Mon, 9 Nov 2009 22:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ2-qxI2Al9M for ; Mon, 9 Nov 2009 22:39:34 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 971913A6905 for ; Mon, 9 Nov 2009 22:39:34 -0800 (PST) Received: from host-40-25.meeting.ietf.org ([133.93.40.25]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N7kOL-0005bo-Vy; Mon, 09 Nov 2009 22:39:50 -0800 Message-Id: From: Eric Burger To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 15:39:56 +0900 References: X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENTS: Empty header vs 'nil' X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:39:37 -0000 There were two reasons for the initial drafts using 'nil.' The first reason was that we were saying (which we very much have decided NOT to do) that if you received a Recv-Info header in the past, and then saw no Recv-Info header, the Info Package Set that was active is still active. This is an obsolete reason because the work group decided we will always say what we mean. The second reason was to ensure forward compatibility in case we wanted to do something special with a naked 'Recv-Info'. However, I think this idea has gone by the wayside, as well. So, I would offer a naked Recv-Info header means, "I understand Info Packages, but I am not willing to accept any at this time." On Nov 10, 2009, at 9:48 AM, Christer Holmberg wrote: > > Hi, > > As part of the WGLC comments, and other e-mail discussions, some > people have requested to use an empty Recv-Info header, instead of a > header with a 'nil' value, to indicate no Info Packages. The main > reason is that it is more alligned with other SIP headers. > > Would someone object to such change? > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Nov 10 12:17:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64963A68EA for ; Tue, 10 Nov 2009 12:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NsjIjD2YMhJ for ; Tue, 10 Nov 2009 12:17:21 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BE7E53A68E0 for ; Tue, 10 Nov 2009 12:17:21 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAINZ+UqrR7Ht/2dsb2JhbADGfJg4hD4E X-IronPort-AV: E=Sophos;i="4.44,718,1249257600"; d="scan'208";a="222953242" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2009 20:17:49 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAAKHmag004317; Tue, 10 Nov 2009 20:17: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.3959); Tue, 10 Nov 2009 15:17:48 -0500 Received: from [161.44.182.192] ([161.44.182.192]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:17:48 -0500 Message-ID: <4AF9CA6B.5080109@cisco.com> Date: Tue, 10 Nov 2009 15:17:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeroen van Bemmel References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> In-Reply-To: <4AF7CDD0.308@zonnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2009 20:17:48.0367 (UTC) FILETIME=[DF16FDF0:01CA6242] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:17:23 -0000 The most straightforward 3pcc case to explain is: A --------- B ---------- C | |----------- D Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. Later B decides to transfer the call from C to D. So it establishes a new dialog B-D and reinvites A to splice it in. I'm hand waving over the details, because there are many options and they don't matter here. The key point is that A was, for all intents and purposes, initially connected to C, and after a reinvite finds itself connected to D. Now D may not be able to support the same Info Packages that C did. To make things work, the R-I values from D must be presented to A, and it needs to honor them. Conversely, D needs to be informed of the info packages that A is willing to receive. While it is possible that B could have remembered them, and could thus insert them in the initial invite to D, its better if B doesn't have to get involved in that. Many new features run into essentially the same problem with 3pcc. You just cannot assume state negotiated e2e will survive a reinvite. And this is quite a bit different than the stability of route sets, because the route set distinct in each dialog. It doesn't go e2e through the B2BUA. Thanks, Paul Jeroen van Bemmel wrote: > Christer, > > Given the registration requirement (i.e. there needs to be some sort of > spec) the set of INFO packages will be limited. UAs can easily list > those packages they support up front. Therefore the "fully dynamic" case > you sketch below seems unlikely to me. > > The only case I could imagine would be in case of long running dialogs, > where the software of one of the peers gets upgraded mid-dialog to > support some new INFO package. However, also that seems highly unlikely > to me. > > To me, we should keep it simple - "learn INFO packages whenever you > learn the Route set for a Dialog" should be simple enough for developers > to get right > > Regards, > Jeroen > > Christer Holmberg wrote: >> Hi, >> >>> I also think it's overkill. Furthermore, I don't see a real world use >>> >> case for changing the set of supported INFO >>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>> >> response when it receives an INFO request which it >>> doesn't want to process anymore? >>> >>> To me, INFO packages should be like the Dialog's route set: learn the >>> >> supported set from the initial INVITE and 1xx-2xx >>> responses, after that don't change it anymore >>> >> >> I think Adam made the same comment in the SIPCORE session. >> >> Personally I think there could be cases where one wants to add a package >> during a dialog. For example, assume I call you. Then, during the dialog >> we decide to start using application X which uses an Info Package, so >> our phones send Recv-Info:X to each other. Application X may not even be >> running when we initiate the dialog. >> >> However, if we are going to require the header in a lot of messages, >> maybe we should remove PRACK from the list of allowed messages. Would >> people have problems with that? >> >> But, I would like Paul to comment whether mandating the header in every >> message would actually solve his 3pcc use-case. >> >> >>> PS The usage of 'nil' to denote no supported packages is not consistent >>> >> with conventions used today, e.g. for Supported >>> (suggest to simply use an empty value instead) >>> >> >> I think there was some WGLC comment(s) asking about the same thing. >> Personally I have no problem to use an empty header instead of 'nil'. >> However, I want to ensure that nobody objects to such change before I >> implement it. >> >> Regards, >> >> Christer >> >> >> >> >> DRAGE, Keith (Keith) wrote: >> >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which could >>> >> also be understood from the paraphrase of the SIPCORE discussion. >> >>> Secondly can I still have more detail (arrow diagram) on the scenario >>> >> we are trying to solve for 3pcc. I can't see if there is a simple >> solution if the problem is insufficiently clear. >> >>> Keith >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >>>> >> >> >>>> header >>>> >>>> That works for me, and it is sufficiently simple that everybody >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>>> discussed whether we should mandate to include Recv-Info in >>>>> >>>> re-INVITE >>>> >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> >>>> the set of >>>> >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> >>>> messages would >>>> >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> >>>> says that >>>> >>>>> the Recv-Info header only needs to be inserted if the set of Info >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> >>>> implement >>>> >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Nov 10 15:27:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C383A69A3 for ; Tue, 10 Nov 2009 15:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twHXzvYuP06g for ; Tue, 10 Nov 2009 15:27:48 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4887B3A6887 for ; Tue, 10 Nov 2009 15:27:47 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-bf-4af9f70de65b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 84.EB.31706.D07F9FA4; Wed, 11 Nov 2009 00:28:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:27:37 +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, 11 Nov 2009 00:27:36 +0100 Message-ID: In-Reply-To: <4AF9CA6B.5080109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpiQuPyfxTU+IcrTJ2XP+a+BsOn4gAGQztQ References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Jeroen van Bemmel" X-OriginalArrivalTime: 10 Nov 2009 23:27:37.0313 (UTC) FILETIME=[636E3D10:01CA625D] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:27:50 -0000 Hi Paul, Thanks for the description! Now, assuming that B2BUA B does NOT support I-P (if B does support I-P, there should be no issue), it would not insert Recv-Info (not even an empty header) in the initial INVITE requests sent to A and C. In addition, B would most likely not insert Recv-Info in the re-INVITE request to D. So, mandating Recv-Info in every message would not solve the issue. (Not allowing mid-call changes would not solve the issue either, since C and D can support a different set of Info Packages) Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 10. marraskuuta 2009 23:18 To: Jeroen van Bemmel Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header The most straightforward 3pcc case to explain is: A --------- B ---------- C | |----------- D Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. Later B decides to transfer the call from C to D. So it establishes a new dialog B-D and reinvites A to splice it in. I'm hand waving over the details, because there are many options and they don't matter here. The key point is that A was, for all intents and purposes, initially connected to C, and after a reinvite finds itself connected to D. Now D may not be able to support the same Info Packages that C did. To make things work, the R-I values from D must be presented to A, and it needs to honor them. Conversely, D needs to be informed of the info packages that A is willing to receive. While it is possible that B could have remembered them, and could thus insert them in the initial invite to D, its better if B doesn't have to get involved in that. Many new features run into essentially the same problem with 3pcc. You just cannot assume state negotiated e2e will survive a reinvite. And this is quite a bit different than the stability of route sets, because the route set distinct in each dialog. It doesn't go e2e through the B2BUA. Thanks, Paul Jeroen van Bemmel wrote: > Christer, >=20 > Given the registration requirement (i.e. there needs to be some sort=20 > of > spec) the set of INFO packages will be limited. UAs can easily list=20 > those packages they support up front. Therefore the "fully dynamic"=20 > case you sketch below seems unlikely to me. >=20 > The only case I could imagine would be in case of long running=20 > dialogs, where the software of one of the peers gets upgraded=20 > mid-dialog to support some new INFO package. However, also that seems=20 > highly unlikely to me. >=20 > To me, we should keep it simple - "learn INFO packages whenever you=20 > learn the Route set for a Dialog" should be simple enough for=20 > developers to get right >=20 > Regards, > Jeroen >=20 > Christer Holmberg wrote: >> Hi, >> =20 >>> I also think it's overkill. Furthermore, I don't see a real world=20 >>> use >>> =20 >> case for changing the set of supported INFO >>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>> =20 >> response when it receives an INFO request which it >>> doesn't want to process anymore? >>> >>> To me, INFO packages should be like the Dialog's route set: learn=20 >>> the >>> =20 >> supported set from the initial INVITE and 1xx-2xx >>> responses, after that don't change it anymore >>> =20 >> >> I think Adam made the same comment in the SIPCORE session. >> >> Personally I think there could be cases where one wants to add a=20 >> package during a dialog. For example, assume I call you. Then, during >> the dialog we decide to start using application X which uses an Info=20 >> Package, so our phones send Recv-Info:X to each other. Application X=20 >> may not even be running when we initiate the dialog. >> >> However, if we are going to require the header in a lot of messages,=20 >> maybe we should remove PRACK from the list of allowed messages. Would >> people have problems with that? >> >> But, I would like Paul to comment whether mandating the header in=20 >> every message would actually solve his 3pcc use-case. >> >> =20 >>> PS The usage of 'nil' to denote no supported packages is not=20 >>> consistent >>> =20 >> with conventions used today, e.g. for Supported >>> (suggest to simply use an empty value instead) >>> =20 >> >> I think there was some WGLC comment(s) asking about the same thing. >> Personally I have no problem to use an empty header instead of 'nil'. >> However, I want to ensure that nobody objects to such change before I >> implement it. >> >> Regards, >> >> Christer >> >> >> >> >> DRAGE, Keith (Keith) wrote: >> =20 >>> This works, but it seems overkill to me. >>> >>> Firstly can I ensure that this does not include REGISTER, which=20 >>> could >>> =20 >> also be understood from the paraphrase of the SIPCORE discussion. >> =20 >>> Secondly can I still have more detail (arrow diagram) on the=20 >>> scenario >>> =20 >> we are trying to solve for 3pcc. I can't see if there is a simple=20 >> solution if the problem is insufficiently clear. >> =20 >>> Keith >>> >>> =20 >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, November 09, 2009 4:15 AM >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info >>>> =20 >> >> =20 >>>> header >>>> >>>> That works for me, and it is sufficiently simple that everybody=20 >>>> should be able to implement it correctly. :-) >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>> =20 >>>>> Hi, >>>>> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we=20 >>>>> discussed whether we should mandate to include Recv-Info in >>>>> =20 >>>> re-INVITE >>>> =20 >>>>> responses. >>>>> >>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>> =20 >>>> the set of >>>> =20 >>>>> Info Packages has changed or not. >>>>> >>>>> Based on the -03pre version of the draft the following >>>>> =20 >>>> messages would >>>> =20 >>>>> be >>>>> affected: >>>>> >>>>> INVITE + 18x + 200 >>>>> Re-INVITE + 18x + 200 >>>>> ACK >>>>> UPDATE + 200 >>>>> PRACK + 200 >>>>> >>>>> That is a change from previous versions of the draft, which >>>>> =20 >>>> says that >>>> =20 >>>>> the Recv-Info header only needs to be inserted if the set of Info=20 >>>>> Packages changes. >>>>> >>>>> So, unless people have issues with that, my intention is to >>>>> =20 >>>> implement >>>> =20 >>>>> the change in the next version of the draft. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From gonzalo.camarillo@ericsson.com Tue Nov 10 17:55:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118743A6BD1 for ; Tue, 10 Nov 2009 17:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHkSkj78HtbV for ; Tue, 10 Nov 2009 17:55:41 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C0BF53A6BCC for ; Tue, 10 Nov 2009 17:55:40 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-41-4afa19b6bdd3 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 83.BE.31706.6B91AFA4; Wed, 11 Nov 2009 02:56:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 02:56:06 +0100 Received: from [150.236.158.229] ([150.236.158.229]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 02:56:05 +0100 Message-ID: <4AFA19AC.8030303@ericsson.com> Date: Wed, 11 Nov 2009 10:55:56 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 01:56:05.0776 (UTC) FILETIME=[2149D100:01CA6272] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:55:42 -0000 Hi, yes, that was the agreement we reached: only reliable provisional responses would refresh the target. The reason why unreliable provisional responses cannot refresh the target is that the UAC could receive them in a different order. The UAS does not know when or even if the UAC has received it. Cheers, Gonzalo Brett Tate wrote: > Hi Gonzalo, > > In case it matters, draft-camarillo-sipcore-reinvite-01 section 12 only partially follows the indicated approach. Section 12 currently requires the 1xx response to be reliable for the Contact to be updated. > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: Saturday, November 07, 2009 10:55 PM >> To: Paul Kyzivat >> Cc: Taisto Qvist XX; sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] Changing contact/remote target in targetrefresh >> response >> >> Hi, >> >> this is the approach we have followed when writing the following >> section >> of the re-INVITE handling draft: >> >> http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite-01#section- >> 12 >> >> Cheers, >> >> Gonzalo >> >> >> Paul Kyzivat wrote: >>> I agree with Jeroen >>> >>> Jeroen van Bemmel wrote: >>>> Brett, >>>> >>>> Even if it's not clearly defined, to me the rule should be simple: >>>> always update the remote target whenever a valid target refresh >>>> request/response (1xx or 2xx) containing a Contact header is >> received >>>> (with "valid" meaning syntactically correct and in proper dialog >>>> sequence, matching an existing transaction for responses, and no >>>> retransmission) >>>> >>>> It must be assumed that the peer is communicating its most up-to- >> date >>>> value for its Contact address, I see no reason to ignore such >> updates >>>> (and I do see how ignoring an updated Contact can cause failures, >> the >>>> peer may have obtained a new IP address for example, during the time >>>> interval it was ringing - e.g. some handset being picked up from a >>>> docking station with a fixed LAN cable, switching to WiFi) >>>> >>>> Regards, >>>> Jeroen > From gonzalo.camarillo@ericsson.com Tue Nov 10 17:57:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BBB3A6BD1 for ; Tue, 10 Nov 2009 17:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZzN8Mxww69B for ; Tue, 10 Nov 2009 17:57:41 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 08DE73A6A3D for ; Tue, 10 Nov 2009 17:57:40 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-b5-4afa1a2f7840 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 36.58.04191.F2A1AFA4; Wed, 11 Nov 2009 02:58:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 02:57:12 +0100 Received: from [150.236.158.229] ([150.236.158.229]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 02:57:11 +0100 Message-ID: <4AFA19F5.9040301@ericsson.com> Date: Wed, 11 Nov 2009 10:57:09 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> <4AF641FC.70606@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794F9@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FCD794F9@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 01:57:12.0079 (UTC) FILETIME=[48CED9F0:01CA6272] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:57:42 -0000 Hi, yes, as Adam pointed our in the meeting, the re-INVITE draft is also intended to meet that milestone. I will make sure the next version of the draft covers explicitly initial INVITEs as well. Thanks, Gonzalo Brett Tate wrote: > Hi Gonzalo, > > For meeting the SIPCORE "Invite Transaction Handling Correction" milestone, I propose that draft-camarillo-sipcore-reinvite be updated to also address the topic within this thread. More specifically, I propose that the draft clearly also discuss INVITE instead of only re-INVITE (and other target-refresh requests) when discussing impacts of 1xx/2xx responses containing an updated Contact (and Record-Route). > > Since the milestone currently indicates "Done", is "Invite Transaction Handling Correction" intended for something like draft-camarillo-sipcore-reinvite? Or was the milestone for something like draft-sparks-sipcore-invfix? > > Thanks, > Brett > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Saturday, November 07, 2009 10:59 PM >> To: Christer Holmberg >> Cc: Brett Tate; sipcore@ietf.org >> Subject: Re: [sipcore] Changingcontact/remote target in target refresh >> response >> >> Hi, >> >> note that the following draft deals with target refreshes as well, not >> only with SDP stuff: >> >> http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite >> >> Cheers, >> >> Gonzalo >> >> Christer Holmberg wrote: >>> Hi, >>> >>>> Yes; there have been discussions. Unfortunately non have >>>> actually led to an update to rfc3261. >>>> >>>> >>>> As you know, there are some drafts concerning >>>> updates/rollbacks related to re-INVITE and UPDATE failure. >>>> However I don't recall if there are any non expired drafts >>>> actually discussing the topic within this thread. >>> No, I don't think so. >>> >>> The drafts are more related to what happens to confirmed changes >> (e.g. >>> in a 18x response) if a re-INVITE fails. >>> >>> Regards, >>> >>> Christer > From pkyzivat@cisco.com Tue Nov 10 18:32:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236CA3A6BEA for ; Tue, 10 Nov 2009 18:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cjpkiBFasuh for ; Tue, 10 Nov 2009 18:32:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 42EA63A6BD4 for ; Tue, 10 Nov 2009 18:32:27 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKKx+UpAZnwM/2dsb2JhbADFY5hFhDwE X-IronPort-AV: E=Sophos;i="4.44,720,1249257600"; d="scan'208";a="67399819" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 02:32:54 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB2Wsed024612; Wed, 11 Nov 2009 02:32:54 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.3959); Tue, 10 Nov 2009 21:32:54 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:32:54 -0500 Message-ID: <4AFA2253.2040401@cisco.com> Date: Tue, 10 Nov 2009 21:32:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 02:32:54.0072 (UTC) FILETIME=[45890B80:01CA6277] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENTS: Empty header vs 'nil' X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:32:29 -0000 I always found the use of 'nil' weird, but not worth fighting over. But since somebody has already picked the fight, yes, I prefer Empty over nil. Thanks, Paul Christer Holmberg wrote: > > Hi, > > As part of the WGLC comments, and other e-mail discussions, some people > have requested to use an empty Recv-Info header, instead of a header > with a 'nil' value, to indicate no Info Packages. The main reason is > that it is more alligned with other SIP headers. > > Would someone object to such change? > > Regards, > > Christer > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Nov 10 18:54:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FD13A684C for ; Tue, 10 Nov 2009 18:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UEDYQ0bryw2 for ; Tue, 10 Nov 2009 18:54:53 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B75CF3A67F3 for ; Tue, 10 Nov 2009 18:54:52 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABe2+UpAZnwM/2dsb2JhbADFSJhIhDwE X-IronPort-AV: E=Sophos;i="4.44,720,1249257600"; d="scan'208";a="67350826" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2009 02:55:19 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB2tJ2j000565; Wed, 11 Nov 2009 02:55:19 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.3959); Tue, 10 Nov 2009 21:55:19 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:55:19 -0500 Message-ID: <4AFA2795.5040606@cisco.com> Date: Tue, 10 Nov 2009 21:55:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 02:55:19.0595 (UTC) FILETIME=[67878FB0:01CA627A] Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:54:54 -0000 Christer Holmberg wrote: > Hi Paul, > > Thanks for the description! > > Now, assuming that B2BUA B does NOT support I-P (if B does support I-P, > there should be no issue), it would not insert Recv-Info (not even an > empty header) in the initial INVITE requests sent to A and C. > > In addition, B would most likely not insert Recv-Info in the re-INVITE > request to D. > > So, mandating Recv-Info in every message would not solve the issue. If Recv-Info is mandated in every message, then doesn't the absence of Recv-Info mean that it doesn't support Info packages at all, at least momentarily? (Until it sends a R-I.) > (Not allowing mid-call changes would not solve the issue either, since C > and D can support a different set of Info Packages) Yes, Definitely! Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10. marraskuuta 2009 23:18 > To: Jeroen van Bemmel > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > header > > The most straightforward 3pcc case to explain is: > > A --------- B ---------- C > | > |----------- D > > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. > Later B decides to transfer the call from C to D. So it establishes a > new dialog B-D and reinvites A to splice it in. I'm hand waving over the > details, because there are many options and they don't matter here. > > The key point is that A was, for all intents and purposes, initially > connected to C, and after a reinvite finds itself connected to D. > > Now D may not be able to support the same Info Packages that C did. > To make things work, the R-I values from D must be presented to A, and > it needs to honor them. > > Conversely, D needs to be informed of the info packages that A is > willing to receive. While it is possible that B could have remembered > them, and could thus insert them in the initial invite to D, its better > if B doesn't have to get involved in that. > > Many new features run into essentially the same problem with 3pcc. You > just cannot assume state negotiated e2e will survive a reinvite. > > And this is quite a bit different than the stability of route sets, > because the route set distinct in each dialog. It doesn't go e2e through > the B2BUA. > > Thanks, > Paul > > Jeroen van Bemmel wrote: >> Christer, >> >> Given the registration requirement (i.e. there needs to be some sort >> of >> spec) the set of INFO packages will be limited. UAs can easily list >> those packages they support up front. Therefore the "fully dynamic" >> case you sketch below seems unlikely to me. >> >> The only case I could imagine would be in case of long running >> dialogs, where the software of one of the peers gets upgraded >> mid-dialog to support some new INFO package. However, also that seems >> highly unlikely to me. >> >> To me, we should keep it simple - "learn INFO packages whenever you >> learn the Route set for a Dialog" should be simple enough for >> developers to get right >> >> Regards, >> Jeroen >> >> Christer Holmberg wrote: >>> Hi, >>> >>>> I also think it's overkill. Furthermore, I don't see a real world >>>> use >>>> >>> case for changing the set of supported INFO >>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>> >>> response when it receives an INFO request which it >>>> doesn't want to process anymore? >>>> >>>> To me, INFO packages should be like the Dialog's route set: learn >>>> the >>>> >>> supported set from the initial INVITE and 1xx-2xx >>>> responses, after that don't change it anymore >>>> >>> I think Adam made the same comment in the SIPCORE session. >>> >>> Personally I think there could be cases where one wants to add a >>> package during a dialog. For example, assume I call you. Then, during > >>> the dialog we decide to start using application X which uses an Info >>> Package, so our phones send Recv-Info:X to each other. Application X >>> may not even be running when we initiate the dialog. >>> >>> However, if we are going to require the header in a lot of messages, >>> maybe we should remove PRACK from the list of allowed messages. Would > >>> people have problems with that? >>> >>> But, I would like Paul to comment whether mandating the header in >>> every message would actually solve his 3pcc use-case. >>> >>> >>>> PS The usage of 'nil' to denote no supported packages is not >>>> consistent >>>> >>> with conventions used today, e.g. for Supported >>>> (suggest to simply use an empty value instead) >>>> >>> I think there was some WGLC comment(s) asking about the same thing. >>> Personally I have no problem to use an empty header instead of 'nil'. >>> However, I want to ensure that nobody objects to such change before I > >>> implement it. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> DRAGE, Keith (Keith) wrote: >>> >>>> This works, but it seems overkill to me. >>>> >>>> Firstly can I ensure that this does not include REGISTER, which >>>> could >>>> >>> also be understood from the paraphrase of the SIPCORE discussion. >>> >>>> Secondly can I still have more detail (arrow diagram) on the >>>> scenario >>>> >>> we are trying to solve for 3pcc. I can't see if there is a simple >>> solution if the problem is insufficiently clear. >>> >>>> Keith >>>> >>>> >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>>> Recv-Info >>>>> >>> >>>>> header >>>>> >>>>> That works for me, and it is sufficiently simple that everybody >>>>> should be able to implement it correctly. :-) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Christer Holmberg wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>>>> discussed whether we should mandate to include Recv-Info in >>>>>> >>>>> re-INVITE >>>>> >>>>>> responses. >>>>>> >>>>>> The outcome of the discussion was that EVERY SIP messages where >>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>> >>>>> the set of >>>>> >>>>>> Info Packages has changed or not. >>>>>> >>>>>> Based on the -03pre version of the draft the following >>>>>> >>>>> messages would >>>>> >>>>>> be >>>>>> affected: >>>>>> >>>>>> INVITE + 18x + 200 >>>>>> Re-INVITE + 18x + 200 >>>>>> ACK >>>>>> UPDATE + 200 >>>>>> PRACK + 200 >>>>>> >>>>>> That is a change from previous versions of the draft, which >>>>>> >>>>> says that >>>>> >>>>>> the Recv-Info header only needs to be inserted if the set of Info >>>>>> Packages changes. >>>>>> >>>>>> So, unless people have issues with that, my intention is to >>>>>> >>>>> implement >>>>> >>>>>> the change in the next version of the draft. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From gonzalo.camarillo@ericsson.com Tue Nov 10 20:31:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD18B3A6BFF for ; Tue, 10 Nov 2009 20:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMomni-t1ECx for ; Tue, 10 Nov 2009 20:31:00 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 52D623A6B05 for ; Tue, 10 Nov 2009 20:31:00 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-7c-4afa3e1e7c47 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 72.EA.16818.E1E3AFA4; Wed, 11 Nov 2009 05:31:26 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 05:31:26 +0100 Received: from [150.236.158.229] ([150.236.158.229]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 05:31:25 +0100 Message-ID: <4AFA3E1A.8060204@ericsson.com> Date: Wed, 11 Nov 2009 13:31:22 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 04:31:25.0897 (UTC) FILETIME=[D4836B90:01CA6287] X-Brightmail-Tracker: AAAAAA== Cc: Brian Hibbard Subject: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:31:02 -0000 Folks, as you know, we have asked for volunteers to review the sec-flows draft many times. We got a couple of reviews but we would like to get at least one dedicated review more. If you want to volunteer, please send your review to the list. Additionally, the reviews we got pointed out at issues that require WG consensus (as opposed to the editor simply going off and implementing them). As next steps, the draft's editor (Brian) will be submitting a new revision of the draft because the current one has expired. Then, he will be sending a set of emails to the list so that we can reach consensus on the issues that need discussion. Thanks, Gonzalo SIPCORE co-chair From dean.willis@softarmor.com Tue Nov 10 22:49:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A803A6919 for ; Tue, 10 Nov 2009 22:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzZAhU3ts4-j for ; Tue, 10 Nov 2009 22:49:48 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9D6E53A68F3 for ; Tue, 10 Nov 2009 22:49:45 -0800 (PST) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAB6o7Pl025199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Nov 2009 00:50:08 -0600 Message-ID: <4AFA5E99.2090204@softarmor.com> Date: Wed, 11 Nov 2009 00:50:01 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:49:49 -0000 DRAGE, Keith (Keith) wrote: > In my view the only part that is expert reviewable is the bit that constitutes the IANA registration. > > I see no reason for performing an expert review of the Info package specification itself. > question for the reviewer: is the referenced specification credible as a specification? that is, is it available and likely to stay that way and does it actually describe the info-package? note that we do not ask "does the specification make sense as an application for INFO or is INFO a reasonable solution to the problem? -- dean From dean.willis@softarmor.com Tue Nov 10 22:53:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119933A6919 for ; Tue, 10 Nov 2009 22:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeCy0P7YEcTe for ; Tue, 10 Nov 2009 22:52:59 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 34D383A698E for ; Tue, 10 Nov 2009 22:52:59 -0800 (PST) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAB6rN3c025227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Nov 2009 00:53:24 -0600 Message-ID: <4AFA5F5E.1010302@softarmor.com> Date: Wed, 11 Nov 2009 00:53:18 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> In-Reply-To: <4AF9CA6B.5080109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:53:00 -0000 Paul Kyzivat wrote: > The most straightforward 3pcc case to explain is: > > A --------- B ---------- C > | > |----------- D > > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. > Later B decides to transfer the call from C to D. So it establishes a > new dialog B-D and reinvites A to splice it in. I'm hand waving over the > details, because there are many options and they don't matter here. > > The key point is that A was, for all intents and purposes, initially > connected to C, and after a reinvite finds itself connected to D. > > Now D may not be able to support the same Info Packages that C did. > To make things work, the R-I values from D must be presented to A, and > it needs to honor them. > > Conversely, D needs to be informed of the info packages that A is > willing to receive. While it is possible that B could have remembered > them, and could thus insert them in the initial invite to D, its better > if B doesn't have to get involved in that. > > Many new features run into essentially the same problem with 3pcc. You > just cannot assume state negotiated e2e will survive a reinvite. > > And this is quite a bit different than the stability of route sets, > because the route set distinct in each dialog. It doesn't go e2e through > the B2BUA. my read: B needs to initiate a reINVITE on A-B to inform A of the new info capability presented on B-D. -- dean From christer.holmberg@ericsson.com Wed Nov 11 00:36:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA843A67F7 for ; Wed, 11 Nov 2009 00:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCXU44DASB35 for ; Wed, 11 Nov 2009 00:36:37 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A5A333A67DD for ; Wed, 11 Nov 2009 00:36:36 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-33-4afa771e0bc1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 38.BA.16818.E177AFA4; Wed, 11 Nov 2009 09:34:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:34:35 +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, 11 Nov 2009 09:34:35 +0100 Message-ID: In-Reply-To: <4AFA2795.5040606@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpiemluaF+KBLlrRoekTr7GRQHOdQALgaUA References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> <4AFA2795.5040606@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Nov 2009 08:34:35.0527 (UTC) FILETIME=[CC9C4970:01CA62A9] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:36:38 -0000 Hi,=20 >>Thanks for the description! >>=20 >>Now, assuming that B2BUA B does NOT support I-P (if B does support=20 >>I-P, there should be no issue), it would not insert Recv-Info (not=20 >>even an empty header) in the initial INVITE requests sent to A and C. >>=20 >>In addition, B would most likely not insert Recv-Info in the re-INVITE >>request to D. >>=20 >>So, mandating Recv-Info in every message would not solve the issue. > >If Recv-Info is mandated in every message, then doesn't the absence of Recv-Info mean that it doesn't support Info=20 >packages at all, at least momentarily? (Until it sends a R-I.) Exactly, so if B doesn't support Info Packages then A, C and D will all think that the other entity won't support Info-Packages, so that doesn't solve the issue either. But, one alternative to solve the case when B does support I-P (or, at least is configured to insert Recv-Info) would be de define a specific "audit" value for Recv-Info, which means "Please send your list of I-P packages even if it hasn't changed". Then, when B sends the re-INVITE to D it would include something like Recv-Info:* (or whatever value we use for audit). "*" could also be used with other listed packages, so when B sends D's list to A it can ensure that A sends its list back so that D will get it. In my opinion that is far more nicer than mandating Revc-Info in every message, and it actually solves some of the 3pcc use-cases :) Would people be ok with that?=20 Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10. marraskuuta 2009 23:18 > To: Jeroen van Bemmel > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header >=20 > The most straightforward 3pcc case to explain is: >=20 > A --------- B ---------- C > | > |----------- D >=20 > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. > Later B decides to transfer the call from C to D. So it establishes a=20 > new dialog B-D and reinvites A to splice it in. I'm hand waving over=20 > the details, because there are many options and they don't matter here. >=20 > The key point is that A was, for all intents and purposes, initially=20 > connected to C, and after a reinvite finds itself connected to D. >=20 > Now D may not be able to support the same Info Packages that C did. > To make things work, the R-I values from D must be presented to A, and > it needs to honor them. >=20 > Conversely, D needs to be informed of the info packages that A is=20 > willing to receive. While it is possible that B could have remembered=20 > them, and could thus insert them in the initial invite to D, its=20 > better if B doesn't have to get involved in that. >=20 > Many new features run into essentially the same problem with 3pcc. You > just cannot assume state negotiated e2e will survive a reinvite. >=20 > And this is quite a bit different than the stability of route sets,=20 > because the route set distinct in each dialog. It doesn't go e2e=20 > through the B2BUA. >=20 > Thanks, > Paul >=20 > Jeroen van Bemmel wrote: >> Christer, >> >> Given the registration requirement (i.e. there needs to be some sort=20 >> of >> spec) the set of INFO packages will be limited. UAs can easily list=20 >> those packages they support up front. Therefore the "fully dynamic" >> case you sketch below seems unlikely to me. >> >> The only case I could imagine would be in case of long running=20 >> dialogs, where the software of one of the peers gets upgraded=20 >> mid-dialog to support some new INFO package. However, also that seems >> highly unlikely to me. >> >> To me, we should keep it simple - "learn INFO packages whenever you=20 >> learn the Route set for a Dialog" should be simple enough for=20 >> developers to get right >> >> Regards, >> Jeroen >> >> Christer Holmberg wrote: >>> Hi, >>> =20 >>>> I also think it's overkill. Furthermore, I don't see a real world=20 >>>> use >>>> =20 >>> case for changing the set of supported INFO >>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>> =20 >>> response when it receives an INFO request which it >>>> doesn't want to process anymore? >>>> >>>> To me, INFO packages should be like the Dialog's route set: learn=20 >>>> the >>>> =20 >>> supported set from the initial INVITE and 1xx-2xx >>>> responses, after that don't change it anymore >>>> =20 >>> I think Adam made the same comment in the SIPCORE session. >>> >>> Personally I think there could be cases where one wants to add a=20 >>> package during a dialog. For example, assume I call you. Then,=20 >>> during >=20 >>> the dialog we decide to start using application X which uses an Info >>> Package, so our phones send Recv-Info:X to each other. Application X >>> may not even be running when we initiate the dialog. >>> >>> However, if we are going to require the header in a lot of messages, >>> maybe we should remove PRACK from the list of allowed messages.=20 >>> Would >=20 >>> people have problems with that? >>> >>> But, I would like Paul to comment whether mandating the header in=20 >>> every message would actually solve his 3pcc use-case. >>> >>> =20 >>>> PS The usage of 'nil' to denote no supported packages is not=20 >>>> consistent >>>> =20 >>> with conventions used today, e.g. for Supported >>>> (suggest to simply use an empty value instead) >>>> =20 >>> I think there was some WGLC comment(s) asking about the same thing. >>> Personally I have no problem to use an empty header instead of 'nil'. >>> However, I want to ensure that nobody objects to such change before=20 >>> I >=20 >>> implement it. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> DRAGE, Keith (Keith) wrote: >>> =20 >>>> This works, but it seems overkill to me. >>>> >>>> Firstly can I ensure that this does not include REGISTER, which=20 >>>> could >>>> =20 >>> also be understood from the paraphrase of the SIPCORE discussion. >>> =20 >>>> Secondly can I still have more detail (arrow diagram) on the=20 >>>> scenario >>>> =20 >>> we are trying to solve for 3pcc. I can't see if there is a simple=20 >>> solution if the problem is insufficiently clear. >>> =20 >>>> Keith >>>> >>>> =20 >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>>> Recv-Info >>>>> =20 >>> =20 >>>>> header >>>>> >>>>> That works for me, and it is sufficiently simple that everybody=20 >>>>> should be able to implement it correctly. :-) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Christer Holmberg wrote: >>>>> =20 >>>>>> Hi, >>>>>> >>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>>>> discussed whether we should mandate to include Recv-Info in >>>>>> =20 >>>>> re-INVITE >>>>> =20 >>>>>> responses. >>>>>> >>>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>> =20 >>>>> the set of >>>>> =20 >>>>>> Info Packages has changed or not. >>>>>> >>>>>> Based on the -03pre version of the draft the following >>>>>> =20 >>>>> messages would >>>>> =20 >>>>>> be >>>>>> affected: >>>>>> >>>>>> INVITE + 18x + 200 >>>>>> Re-INVITE + 18x + 200 >>>>>> ACK >>>>>> UPDATE + 200 >>>>>> PRACK + 200 >>>>>> >>>>>> That is a change from previous versions of the draft, which >>>>>> =20 >>>>> says that >>>>> =20 >>>>>> the Recv-Info header only needs to be inserted if the set of Info >>>>>> Packages changes. >>>>>> >>>>>> So, unless people have issues with that, my intention is to >>>>>> =20 >>>>> implement >>>>> =20 >>>>>> the change in the next version of the draft. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> =20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 From christer.holmberg@ericsson.com Wed Nov 11 00:49:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF5B3A69DC for ; Wed, 11 Nov 2009 00:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4cMpHwmQ3OO for ; Wed, 11 Nov 2009 00:49:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 107463A6A85 for ; Wed, 11 Nov 2009 00:48:31 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-7d-4afa7a7af618 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B8.3C.04191.A7A7AFA4; Wed, 11 Nov 2009 09:48:58 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:48:58 +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, 11 Nov 2009 09:48:57 +0100 Message-ID: In-Reply-To: <4AFA5F5E.1010302@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: Acpim66j21OSszFQSKmrhT3TkXjPQQADwrkQ References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com> <4AFA5F5E.1010302@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 11 Nov 2009 08:48:58.0157 (UTC) FILETIME=[CEC72DD0:01CA62AB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:49:36 -0000 Hi,=20 > The most straightforward 3pcc case to explain is: >=20 > A --------- B ---------- C > | > |----------- D >=20 > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. > Later B decides to transfer the call from C to D. So it establishes a=20 > new dialog B-D and reinvites A to splice it in. I'm hand waving over=20 > the details, because there are many options and they don't matter here. >=20 > The key point is that A was, for all intents and purposes, initially=20 > connected to C, and after a reinvite finds itself connected to D. >=20 > Now D may not be able to support the same Info Packages that C did. > To make things work, the R-I values from D must be presented to A, and > it needs to honor them. >=20 > Conversely, D needs to be informed of the info packages that A is=20 > willing to receive. While it is possible that B could have remembered=20 > them, and could thus insert them in the initial invite to D, its=20 > better if B doesn't have to get involved in that. >=20 > Many new features run into essentially the same problem with 3pcc. You > just cannot assume state negotiated e2e will survive a reinvite. >=20 > And this is quite a bit different than the stability of route sets,=20 > because the route set distinct in each dialog. It doesn't go e2e=20 > through the B2BUA. > >my read: > >B needs to initiate a reINVITE on A-B to inform A of the new info capability presented on B-D. D, when it receives the INVITE, will most likely return Recv-Info, since it hasn't done it yet.=20 But, unless B has stored the list of A, we need to make sure that A returns its list in the re-INVITE response, so that D gets it. I am not sure whether we should make things more complex just to support the case when B does not support I-P. B is a B2BUA, so it could store the Info Package list of the participants, and then we don't have a problem. Regards, Christer From christer.holmberg@ericsson.com Wed Nov 11 00:52:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFCB3A69AD for ; Wed, 11 Nov 2009 00:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLTOwiXh-xOa for ; Wed, 11 Nov 2009 00:52:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 122903A67F6 for ; Wed, 11 Nov 2009 00:52:41 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-14-4afa7b7419be Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C0.FC.04191.47B7AFA4; Wed, 11 Nov 2009 09:53:08 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:53:04 +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, 11 Nov 2009 09:53:03 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpiemluaF+KBLlrRoekTr7GRQHOdQALgaUAAADkjuA= References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Paul Kyzivat" X-OriginalArrivalTime: 11 Nov 2009 08:53:04.0413 (UTC) FILETIME=[618EDCD0:01CA62AC] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:52:44 -0000 Hi, Please forget the audit proposal until we decide on whether we could agree on assuming that B supports Info Packages in order to make sure it works between A and D. That would be even esier - we don't need to mandate Recv-Info in every message, and we don't need to define the audit :) Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 11. marraskuuta 2009 11:35 To: Paul Kyzivat Cc: sipcore@ietf.org; Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Hi,=20 >>Thanks for the description! >>=20 >>Now, assuming that B2BUA B does NOT support I-P (if B does support=20 >>I-P, there should be no issue), it would not insert Recv-Info (not=20 >>even an empty header) in the initial INVITE requests sent to A and C. >>=20 >>In addition, B would most likely not insert Recv-Info in the re-INVITE >>request to D. >>=20 >>So, mandating Recv-Info in every message would not solve the issue. > >If Recv-Info is mandated in every message, then doesn't the absence of Recv-Info mean that it doesn't support Info=20 >packages at all, at least momentarily? (Until it sends a R-I.) Exactly, so if B doesn't support Info Packages then A, C and D will all think that the other entity won't support Info-Packages, so that doesn't solve the issue either. But, one alternative to solve the case when B does support I-P (or, at least is configured to insert Recv-Info) would be de define a specific "audit" value for Recv-Info, which means "Please send your list of I-P packages even if it hasn't changed". Then, when B sends the re-INVITE to D it would include something like Recv-Info:* (or whatever value we use for audit). "*" could also be used with other listed packages, so when B sends D's list to A it can ensure that A sends its list back so that D will get it. In my opinion that is far more nicer than mandating Revc-Info in every message, and it actually solves some of the 3pcc use-cases :) Would people be ok with that?=20 Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10. marraskuuta 2009 23:18 > To: Jeroen van Bemmel > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header >=20 > The most straightforward 3pcc case to explain is: >=20 > A --------- B ---------- C > | > |----------- D >=20 > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. > Later B decides to transfer the call from C to D. So it establishes a=20 > new dialog B-D and reinvites A to splice it in. I'm hand waving over=20 > the details, because there are many options and they don't matter here. >=20 > The key point is that A was, for all intents and purposes, initially=20 > connected to C, and after a reinvite finds itself connected to D. >=20 > Now D may not be able to support the same Info Packages that C did. > To make things work, the R-I values from D must be presented to A, and > it needs to honor them. >=20 > Conversely, D needs to be informed of the info packages that A is=20 > willing to receive. While it is possible that B could have remembered=20 > them, and could thus insert them in the initial invite to D, its=20 > better if B doesn't have to get involved in that. >=20 > Many new features run into essentially the same problem with 3pcc. You > just cannot assume state negotiated e2e will survive a reinvite. >=20 > And this is quite a bit different than the stability of route sets,=20 > because the route set distinct in each dialog. It doesn't go e2e=20 > through the B2BUA. >=20 > Thanks, > Paul >=20 > Jeroen van Bemmel wrote: >> Christer, >> >> Given the registration requirement (i.e. there needs to be some sort=20 >> of >> spec) the set of INFO packages will be limited. UAs can easily list=20 >> those packages they support up front. Therefore the "fully dynamic" >> case you sketch below seems unlikely to me. >> >> The only case I could imagine would be in case of long running=20 >> dialogs, where the software of one of the peers gets upgraded=20 >> mid-dialog to support some new INFO package. However, also that seems >> highly unlikely to me. >> >> To me, we should keep it simple - "learn INFO packages whenever you=20 >> learn the Route set for a Dialog" should be simple enough for=20 >> developers to get right >> >> Regards, >> Jeroen >> >> Christer Holmberg wrote: >>> Hi, >>> =20 >>>> I also think it's overkill. Furthermore, I don't see a real world=20 >>>> use >>>> =20 >>> case for changing the set of supported INFO >>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>> =20 >>> response when it receives an INFO request which it >>>> doesn't want to process anymore? >>>> >>>> To me, INFO packages should be like the Dialog's route set: learn=20 >>>> the >>>> =20 >>> supported set from the initial INVITE and 1xx-2xx >>>> responses, after that don't change it anymore >>>> =20 >>> I think Adam made the same comment in the SIPCORE session. >>> >>> Personally I think there could be cases where one wants to add a=20 >>> package during a dialog. For example, assume I call you. Then,=20 >>> during >=20 >>> the dialog we decide to start using application X which uses an Info >>> Package, so our phones send Recv-Info:X to each other. Application X >>> may not even be running when we initiate the dialog. >>> >>> However, if we are going to require the header in a lot of messages, >>> maybe we should remove PRACK from the list of allowed messages.=20 >>> Would >=20 >>> people have problems with that? >>> >>> But, I would like Paul to comment whether mandating the header in=20 >>> every message would actually solve his 3pcc use-case. >>> >>> =20 >>>> PS The usage of 'nil' to denote no supported packages is not=20 >>>> consistent >>>> =20 >>> with conventions used today, e.g. for Supported >>>> (suggest to simply use an empty value instead) >>>> =20 >>> I think there was some WGLC comment(s) asking about the same thing. >>> Personally I have no problem to use an empty header instead of 'nil'. >>> However, I want to ensure that nobody objects to such change before=20 >>> I >=20 >>> implement it. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> DRAGE, Keith (Keith) wrote: >>> =20 >>>> This works, but it seems overkill to me. >>>> >>>> Firstly can I ensure that this does not include REGISTER, which=20 >>>> could >>>> =20 >>> also be understood from the paraphrase of the SIPCORE discussion. >>> =20 >>>> Secondly can I still have more detail (arrow diagram) on the=20 >>>> scenario >>>> =20 >>> we are trying to solve for 3pcc. I can't see if there is a simple=20 >>> solution if the problem is insufficiently clear. >>> =20 >>>> Keith >>>> >>>> =20 >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>>> Recv-Info >>>>> =20 >>> =20 >>>>> header >>>>> >>>>> That works for me, and it is sufficiently simple that everybody=20 >>>>> should be able to implement it correctly. :-) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Christer Holmberg wrote: >>>>> =20 >>>>>> Hi, >>>>>> >>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session we >>>>>> discussed whether we should mandate to include Recv-Info in >>>>>> =20 >>>>> re-INVITE >>>>> =20 >>>>>> responses. >>>>>> >>>>>> The outcome of the discussion was that EVERY SIP messages where=20 >>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>> =20 >>>>> the set of >>>>> =20 >>>>>> Info Packages has changed or not. >>>>>> >>>>>> Based on the -03pre version of the draft the following >>>>>> =20 >>>>> messages would >>>>> =20 >>>>>> be >>>>>> affected: >>>>>> >>>>>> INVITE + 18x + 200 >>>>>> Re-INVITE + 18x + 200 >>>>>> ACK >>>>>> UPDATE + 200 >>>>>> PRACK + 200 >>>>>> >>>>>> That is a change from previous versions of the draft, which >>>>>> =20 >>>>> says that >>>>> =20 >>>>>> the Recv-Info header only needs to be inserted if the set of Info >>>>>> Packages changes. >>>>>> >>>>>> So, unless people have issues with that, my intention is to >>>>>> =20 >>>>> implement >>>>> =20 >>>>>> the change in the next version of the draft. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> =20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Nov 11 01:14:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5583A6BE6 for ; Wed, 11 Nov 2009 01:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjUXeCAaaH0m for ; Wed, 11 Nov 2009 01:14:10 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6729128C0E9 for ; Wed, 11 Nov 2009 01:13:36 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-2d-4afa805bf7aa Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 6C.F4.31706.B508AFA4; Wed, 11 Nov 2009 10:14:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 10:13:18 +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, 11 Nov 2009 10:13:18 +0100 Message-ID: In-Reply-To: <4AF641FC.70606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changingcontact/remote target in target refresh response thread-index: AcpgJ8shwoV0bkUcSv6yVYl7a0KDLwChXqcg References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> <4AF641FC.70606@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 11 Nov 2009 09:13:18.0444 (UTC) FILETIME=[352D4AC0:01CA62AF] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 09:14:12 -0000 Hi Gonzalo, The draft does talk about target refreshes, but I am not sure whether it deals with the issue raised in this thread. Section 12 (UAC) says: "If the UAC receives a reliable provisional response or a 2xx response to the target-refresh request, the UAC MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present." ...and section 13 (UAS) says: "If the UAS receives a target-refresh request that has been properly authenticated, the UAS SHOULD generate a reliable provisional response or a 2xx response to the target-refresh request." But, I don't think that draft indicates whether it is allowed to update the target from one response to another, as part of the samee transaction. Eg. 18x Contact:x1 18x Contact:x2 200 Contact:x3 I did look at section 14, but I don't think it's directly covered there either. So, once the issue is solved I think we should make sure it is covered in the draft (unless it's there and I've missed it). SECOND, if the draft is supposed to also cover initial INVITEs, we need to remember that an unreliable provisional response can contain the target, and it does create an early dialog. Regards, Christer =20 -----Original Message----- From: Gonzalo Camarillo=20 Sent: 8. marraskuuta 2009 6:59 To: Christer Holmberg Cc: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in target refresh response Hi, note that the following draft deals with target refreshes as well, not only with SDP stuff: http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite Cheers, Gonzalo Christer Holmberg wrote: > Hi, >=20 >> Yes; there have been discussions. Unfortunately non have actually=20 >> led to an update to rfc3261. >> >> >> As you know, there are some drafts concerning updates/rollbacks=20 >> related to re-INVITE and UPDATE failure. >> However I don't recall if there are any non expired drafts actually=20 >> discussing the topic within this thread. >=20 > No, I don't think so. >=20 > The drafts are more related to what happens to confirmed changes (e.g. > in a 18x response) if a re-INVITE fails. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Friday, November 06, 2009 7:49 AM >>> To: Brett Tate; Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX;=20 >>> sipcore@ietf.org >>> Subject: RE: [sipcore] Changingcontact/remote target in >> target refresh >>> response >>> >>> >>> Hi, >>> >>> Unfortunately this is not the first time we are having this >> discussion. >>> I am not sure what (if any) the outcome has been in previous=20 >>> discussion, but it may be worthwile taking a look in the archieves. >>> >>> Regards, >>> >>> Christer >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate >>>> Sent: 6. marraskuuta 2009 13:41 >>>> To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; >>> sipcore@ietf.org >>>> Subject: Re: [sipcore] Changingcontact/remote target in=20 >>>> targetrefresh response >>>> >>>> I don't disagree with the rule that Jeroen indicated. >>>> BroadSoft may soon need our partners to follow such a rule. >>>> Unfortunately there is nothing within rfc3261 which >> indicates they >>>> MUST, SHOULD, or even MAY behave that way. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Thursday, November 05, 2009 6:44 PM >>>>> To: Jeroen van Bemmel >>>>> Cc: Brett Tate; Taisto Qvist XX; sipcore@ietf.org >>>>> Subject: Re: [sipcore] Changing contact/remote target in >>>> targetrefresh >>>>> response >>>>> >>>>> I agree with Jeroen >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Brett, >>>>>> >>>>>> Even if it's not clearly defined, to me the rule should be >>> simple: >>>>>> always update the remote target whenever a valid >> target refresh >>>>>> request/response (1xx or 2xx) containing a Contact header is=20 >>>>>> received (with "valid" meaning syntactically correct and >>>> in proper >>>>>> dialog sequence, matching an existing transaction for >>>> responses, and >>>>>> no >>>>>> retransmission) >>>>>> >>>>>> It must be assumed that the peer is communicating its most=20 >>>>>> up-to-date value for its Contact address, I see no reason >>>> to ignore >>>>>> such updates (and I do see how ignoring an updated >>>> Contact can cause >>>>>> failures, the peer may have obtained a new IP address for >>>> example, >>>>>> during the time interval it was ringing - e.g. some handset being >>>>>> picked up from a docking station with a fixed LAN cable, >>>> switching >>>>>> to WiFi) >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From taisto.xx.qvist@ericsson.com Wed Nov 11 02:07:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3D43A6A42 for ; Wed, 11 Nov 2009 02:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FpLpdCbQiMm for ; Wed, 11 Nov 2009 02:07:03 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4211B3A69E1 for ; Wed, 11 Nov 2009 02:07:03 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-69-4afa8ce2dbd4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C1.C9.31706.2EC8AFA4; Wed, 11 Nov 2009 11:07:30 +0100 (CET) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:07:30 +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, 11 Nov 2009 11:07:29 +0100 Message-ID: In-Reply-To: <4AFA19F5.9040301@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Changingcontact/remote target in targetrefresh response Thread-Index: AcpiraCavLgmKV2NQTqMowP3+IwWiQ== References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local><4AF641FC.70606@ericsson.com><747A6506A991724FB09B129B79D5FEB613FCD794F9@EXMBXCLUS01.citservers.local> <4AFA19F5.9040301@ericsson.com> From: "Taisto Qvist XX" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 11 Nov 2009 10:07:30.0003 (UTC) FILETIME=[C741D230:01CA62B6] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:07:04 -0000 Hi, Superb! This is even more than I hoped for!=20 I've been going over the responses everyone been writing(being of a somewhat impatient nature)=20 trying to dig out out the answer to my intial question, (which was a lot more simple than the=20 larger picture we've been painting here, but I cant find it), so I hope its OK that I'll restate it. In a simple 3261 scenario, *without* update/prack etc, is it legal for a UAS to send a 2xx with=20 a different Contact than in the initial 1xx? Since it should be ignored by the UAC, should it not be illegal? Its(the new contact) useless anyway,=20 but thats not the same. Sorry for the persistence, and if this still needs to be discussed more I'll accept that, but since=20 I'm trying hard to show a clear picture to the firewall designer I'm having problems with,=20 I have to try :-) Thanks for all your input. Regards Taisto Qvist -----Original Message----- From: Gonzalo Camarillo=20 Sent: den 11 november 2009 02:57 To: Brett Tate Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in targetrefresh response Hi, yes, as Adam pointed our in the meeting, the re-INVITE draft is also intended to meet that milestone. I will make sure the next version of the draft covers explicitly initial INVITEs as well. Thanks, Gonzalo Brett Tate wrote: > Hi Gonzalo, >=20 > For meeting the SIPCORE "Invite Transaction Handling Correction" milestone, I propose that draft-camarillo-sipcore-reinvite be updated to also address the topic within this thread. More specifically, I propose that the draft clearly also discuss INVITE instead of only re-INVITE (and other target-refresh requests) when discussing impacts of 1xx/2xx responses containing an updated Contact (and Record-Route). >=20 > Since the milestone currently indicates "Done", is "Invite Transaction Handling Correction" intended for something like draft-camarillo-sipcore-reinvite? Or was the milestone for something like draft-sparks-sipcore-invfix? >=20 > Thanks, > Brett >=20 From gonzalo.camarillo@ericsson.com Wed Nov 11 04:03:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B074028C18A for ; Wed, 11 Nov 2009 04:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VevI2tutxQuY for ; Wed, 11 Nov 2009 04:03:22 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 77D8F3A6961 for ; Wed, 11 Nov 2009 04:03:21 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-e7-4afaa823ce6c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DD.50.16818.328AAFA4; Wed, 11 Nov 2009 13:03:48 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:02:17 +0100 Received: from [150.236.158.155] ([150.236.158.155]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:02:16 +0100 Message-ID: <4AFAA7C5.3000502@ericsson.com> Date: Wed, 11 Nov 2009 21:02:13 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local> <4AF641FC.70606@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 12:02:16.0899 (UTC) FILETIME=[D02AC130:01CA62C6] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:03:22 -0000 Hi Christer, inline: Christer Holmberg wrote: > Hi Gonzalo, > > The draft does talk about target refreshes, but I am not sure whether it > deals with the issue raised in this thread. > > Section 12 (UAC) says: > > "If the UAC receives a reliable provisional response or a 2xx response > to the target-refresh request, the UAC MUST replace the dialog's > remote target URI with the URI from the Contact header field in that > response, if present." > > ...and section 13 (UAS) says: > > "If the UAS receives a target-refresh request that has been properly > authenticated, the UAS SHOULD generate a reliable provisional > response or a 2xx response to the target-refresh request." > > But, I don't think that draft indicates whether it is allowed to update > the target from one response to another, as part of the samee > transaction. > > Eg. 18x Contact:x1 > 18x Contact:x2 > 200 Contact:x3 the rules above allow it. We can state that this is allowed explicitly, but nowhere in the rules this is forbidden. > I did look at section 14, but I don't think it's directly covered there > either. That section will need to forbid refreshes in certain situations to avoid race conditions. > So, once the issue is solved I think we should make sure it is covered > in the draft (unless it's there and I've missed it). > > > SECOND, if the draft is supposed to also cover initial INVITEs, we need > to remember that an unreliable provisional response can contain the > target, and it does create an early dialog. Yes, we will need to cover that. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Wed Nov 11 04:05:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61BB3A6A96 for ; Wed, 11 Nov 2009 04:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW-tUhfslFJO for ; Wed, 11 Nov 2009 04:05:56 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id CD19B3A6A98 for ; Wed, 11 Nov 2009 04:05:55 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-cd-4afaa8be1147 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 7E.74.31706.EB8AAFA4; Wed, 11 Nov 2009 13:06:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:06:22 +0100 Received: from [150.236.158.155] ([150.236.158.155]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:06:21 +0100 Message-ID: <4AFAA8BB.2020906@ericsson.com> Date: Wed, 11 Nov 2009 21:06:19 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Taisto Qvist XX References: <4AEF50D0.8010907@zonnet.nl><4AF0911F.8080503@zonnet.nl><747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local><4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <747A6506A991724FB09B129B79D5FEB613FBC3676B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613FBC36793@EXMBXCLUS01.citservers.local><4AF641FC.70606@ericsson.com><747A6506A991724FB09B129B79D5FEB613FCD794F9@EXMBXCLUS01.citservers.local> <4AFA19F5.9040301@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 12:06:22.0196 (UTC) FILETIME=[62601B40:01CA62C7] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Changingcontact/remote target in targetrefresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:05:56 -0000 Hi, > In a simple 3261 scenario, *without* update/prack etc, is it legal for a > UAS to send a 2xx with > a different Contact than in the initial 1xx? you still have not found the answer to this question because we have agreed to discuss it and to include the conclusion in the draft. Cheers, Gonzalo From brett@broadsoft.com Wed Nov 11 04:44:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B112128C17E for ; Wed, 11 Nov 2009 04:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv5LsWi9-yda for ; Wed, 11 Nov 2009 04:44:22 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id AF8EE28C251 for ; Wed, 11 Nov 2009 04:44:22 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 11 Nov 2009 04:44:50 -0800 From: Brett Tate To: Christer Holmberg , "sipcore@ietf.org" Date: Wed, 11 Nov 2009 04:44:41 -0800 Thread-Topic: [sipcore] INFO EVENTS: Empty header vs 'nil' Thread-Index: Acpid0k97oOEN55LTXe3azxaQMjmoQAU+O7g Message-ID: <747A6506A991724FB09B129B79D5FEB613FE0B9980@EXMBXCLUS01.citservers.local> References: <4AFA2253.2040401@cisco.com> In-Reply-To: <4AFA2253.2040401@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 Subject: Re: [sipcore] INFO EVENTS: Empty header vs 'nil' X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:44:23 -0000 I also prefer empty header over using nil. I had given up on the issue in = March; thus I didn't raise the issue again during the recent WGLC. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, November 10, 2009 9:33 PM > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENTS: Empty header vs 'nil' >=20 > I always found the use of 'nil' weird, but not worth fighting over. > But since somebody has already picked the fight, yes, I prefer Empty > over nil. >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > > > > Hi, > > > > As part of the WGLC comments, and other e-mail discussions, some > people > > have requested to use an empty Recv-Info header, instead of a header > > with a 'nil' value, to indicate no Info Packages. The main reason is > > that it is more alligned with other SIP headers. > > > > Would someone object to such change? > > > > Regards, > > > > Christer > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Wed Nov 11 05:12:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F8928C323 for ; Wed, 11 Nov 2009 05:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeipQQ4wUDkU for ; Wed, 11 Nov 2009 05:12:09 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 749A728C327 for ; Wed, 11 Nov 2009 05:12:09 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 11 Nov 2009 05:12:34 -0800 From: Brett Tate To: Gonzalo Camarillo , "sipcore@ietf.org" Date: Wed, 11 Nov 2009 05:12:25 -0800 Thread-Topic: [sipcore] Changing contact/remote target in target refresh response Thread-Index: AcpiciOIt5TejzV4TayG5RH6FdGZfAAW3m8Q Message-ID: <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> In-Reply-To: <4AFA19AC.8030303@ericsson.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 Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:12:10 -0000 Thanks for the response. I agree with the reasoning; however the receiver of the INVITE does not alw= ays have the option to use (or wait to use) the reliable/best option. For example during call setup, the caller does not indicate support for UPD= ATE or 100rel. The restriction and lack of alternatives means the called p= arty cannot refresh the target until sending INVITE 2xx. =20 Is it really better to prevent the called party from refreshing the target = instead of allowing a non reliable INVITE 1xx's Contact to update the targe= t? > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, November 10, 2009 8:56 PM > To: Brett Tate > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Changing contact/remote target in targetrefresh > response >=20 > Hi, >=20 > yes, that was the agreement we reached: only reliable provisional > responses would refresh the target. The reason why unreliable > provisional responses cannot refresh the target is that the UAC could > receive them in a different order. The UAS does not know when or even > if > the UAC has received it. >=20 > Cheers, >=20 > Gonzalo >=20 > Brett Tate wrote: > > Hi Gonzalo, > > > > In case it matters, draft-camarillo-sipcore-reinvite-01 section 12 > only partially follows the indicated approach. Section 12 currently > requires the 1xx response to be reliable for the Contact to be updated. From pkyzivat@cisco.com Wed Nov 11 05:53:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2103A6AA6 for ; Wed, 11 Nov 2009 05:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mkdVgkJPaXL for ; Wed, 11 Nov 2009 05:53:18 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AECD83A69E4 for ; Wed, 11 Nov 2009 05:53:18 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAJR+kqrR7H+/2dsb2JhbADEXpgehDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="429980322" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 13:53:44 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABDrhML000431; Wed, 11 Nov 2009 13:53:43 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.3959); Wed, 11 Nov 2009 08:53:43 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 08:53:43 -0500 Message-ID: <4AFAC1F4.3030404@cisco.com> Date: Wed, 11 Nov 2009 08:53:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> <4AFA5F5E.1010302@softarmor.com> In-Reply-To: <4AFA5F5E.1010302@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 13:53:43.0200 (UTC) FILETIME=[61835200:01CA62D6] Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:53:19 -0000 at end... Dean Willis wrote: > Paul Kyzivat wrote: >> The most straightforward 3pcc case to explain is: >> >> A --------- B ---------- C >> | >> |----------- D >> >> Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C. >> Later B decides to transfer the call from C to D. So it establishes a >> new dialog B-D and reinvites A to splice it in. I'm hand waving over the >> details, because there are many options and they don't matter here. >> >> The key point is that A was, for all intents and purposes, initially >> connected to C, and after a reinvite finds itself connected to D. >> >> Now D may not be able to support the same Info Packages that C did. >> To make things work, the R-I values from D must be presented to A, and >> it needs to honor them. >> >> Conversely, D needs to be informed of the info packages that A is >> willing to receive. While it is possible that B could have remembered >> them, and could thus insert them in the initial invite to D, its better >> if B doesn't have to get involved in that. >> >> Many new features run into essentially the same problem with 3pcc. You >> just cannot assume state negotiated e2e will survive a reinvite. >> >> And this is quite a bit different than the stability of route sets, >> because the route set distinct in each dialog. It doesn't go e2e through >> the B2BUA. > > my read: > > B needs to initiate a reINVITE on A-B to inform A of the new info > capability presented on B-D. This has come up because of questioning whether mid-call changes need be supported at all. What you say of course requires them. Thanks, Paul From jbemmel@zonnet.nl Wed Nov 11 06:04:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C33A28C19A for ; Wed, 11 Nov 2009 06:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mArF9p9+k4Qq for ; Wed, 11 Nov 2009 06:04:24 -0800 (PST) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id AB6E128C192 for ; Wed, 11 Nov 2009 06:04:23 -0800 (PST) Received: (qmail 13930 invoked by uid 0); 11 Nov 2009 13:58:12 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Nov 2009 13:58:12 -0000 Message-ID: <4AFAC2F2.2090001@zonnet.nl> Date: Wed, 11 Nov 2009 14:58:10 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:04:24 -0000 Has it been considered to extend RFC3840/RFC3841 with a parameter for INFO Packages? Regards, Jeroen From pkyzivat@cisco.com Wed Nov 11 06:15:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB97D3A6AAF for ; Wed, 11 Nov 2009 06:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.62 X-Spam-Level: X-Spam-Status: No, score=-6.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wtS2nvWBc-a for ; Wed, 11 Nov 2009 06:15:26 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BAC293A6860 for ; Wed, 11 Nov 2009 06:15:25 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHdV+kqtJV2b/2dsb2JhbADEYZgfhDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="67479017" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 14:15:53 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id nABEFqvL029894; Wed, 11 Nov 2009 14:15: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.3959); Wed, 11 Nov 2009 09:15:52 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:15:52 -0500 Message-ID: <4AFAC728.3000008@cisco.com> Date: Wed, 11 Nov 2009 09:16:08 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:15:52.0504 (UTC) FILETIME=[79D70380:01CA62D9] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:15:28 -0000 I agree with Brett here. We are generally talking about an emergency situation, and on the balance I think allowing works better than not allowing. Also, Consider the following: A ---> B INVITE A <--- B 1xx, contact b1 A <--- B UPDATE, contact b2 A ---> B 200 (UPDATE) A <--- B 1xx, contact (b1 or b2?) A <--- B 200 (INVITE), contact (b1 or b2?) I think the questionable ones should be b2. Thanks, Paul Brett Tate wrote: > Thanks for the response. > > I agree with the reasoning; however the receiver of the INVITE does not always have the option to use (or wait to use) the reliable/best option. > > For example during call setup, the caller does not indicate support for UPDATE or 100rel. The restriction and lack of alternatives means the called party cannot refresh the target until sending INVITE 2xx. > > Is it really better to prevent the called party from refreshing the target instead of allowing a non reliable INVITE 1xx's Contact to update the target? > > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Tuesday, November 10, 2009 8:56 PM >> To: Brett Tate >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Changing contact/remote target in targetrefresh >> response >> >> Hi, >> >> yes, that was the agreement we reached: only reliable provisional >> responses would refresh the target. The reason why unreliable >> provisional responses cannot refresh the target is that the UAC could >> receive them in a different order. The UAS does not know when or even >> if >> the UAC has received it. >> >> Cheers, >> >> Gonzalo >> >> Brett Tate wrote: >>> Hi Gonzalo, >>> >>> In case it matters, draft-camarillo-sipcore-reinvite-01 section 12 >> only partially follows the indicated approach. Section 12 currently >> requires the 1xx response to be reliable for the Contact to be updated. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed Nov 11 06:18:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496ED3A69EA for ; Wed, 11 Nov 2009 06:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB6HBIoCiubd for ; Wed, 11 Nov 2009 06:18:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 477CD3A6A0D for ; Wed, 11 Nov 2009 06:18:41 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKNW+kqrR7H+/2dsb2JhbADEapgfhDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="269493204" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 14:19:09 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABEJ9gw022642; Wed, 11 Nov 2009 14:19:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 06:19:09 -0800 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 06:19:09 -0800 Message-ID: <4AFAC7ED.3070409@cisco.com> Date: Wed, 11 Nov 2009 09:19:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeroen van Bemmel References: <4AFAC2F2.2090001@zonnet.nl> In-Reply-To: <4AFAC2F2.2090001@zonnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:19:09.0125 (UTC) FILETIME=[EF08FF50:01CA62D9] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:18:44 -0000 Can anyone imagine a case where you would choose one potential UAS over another based on support for Info Packages? Thanks, Paul Jeroen van Bemmel wrote: > Has it been considered to extend RFC3840/RFC3841 with a parameter for > INFO Packages? > > Regards, > Jeroen > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Wed Nov 11 06:18:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E19C3A6860 for ; Wed, 11 Nov 2009 06:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lbatARLuDzP for ; Wed, 11 Nov 2009 06:18:57 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 620A13A67E3 for ; Wed, 11 Nov 2009 06:18:55 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-b7-4afac7eaa35a Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 16.D8.04191.AE7CAFA4; Wed, 11 Nov 2009 15:19:22 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:19:21 +0100 Received: from [150.236.158.155] ([150.236.158.155]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:19:21 +0100 Message-ID: <4AFAC7E6.6070304@ericsson.com> Date: Wed, 11 Nov 2009 23:19:18 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:19:21.0815 (UTC) FILETIME=[F6995670:01CA62D9] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:18:58 -0000 Hi, > Is it really better to prevent the called party from refreshing the > target instead of allowing a non reliable INVITE 1xx's Contact to > update the target? the UAS wants to refresh the target in order to release its old address and start using the new one. However, even if it returns unreliable provisional responses with its new address, it cannot be sure that the UAC got them. Therefore, it cannot release the old address because it is not sure whether or not the UAC refreshed the target. In any case, the draft will explain the different use cases so that they are clear for implementers. If the UAC could send requests to the UAS (e.g., UPDATE), it may make sense to allow unreliable responses to refresh targets after all... I will need to think about the corner cases... Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Wed Nov 11 06:23:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985153A6840 for ; Wed, 11 Nov 2009 06:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srz6P4dBmq1d for ; Wed, 11 Nov 2009 06:23:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6568D3A692B for ; Wed, 11 Nov 2009 06:23:24 -0800 (PST) X-AuditID: c1b4fb3e-b7be0ae0000041b2-58-4afac8f78c76 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F8.0D.16818.7F8CAFA4; Wed, 11 Nov 2009 15:23:51 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:23:50 +0100 Received: from [150.236.158.155] ([150.236.158.155]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 15:23:50 +0100 Message-ID: <4AFAC8F3.1040509@ericsson.com> Date: Wed, 11 Nov 2009 23:23:47 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> <4AFAC728.3000008@cisco.com> In-Reply-To: <4AFAC728.3000008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:23:50.0635 (UTC) FILETIME=[96D403B0:01CA62DA] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:23:29 -0000 Hi Paul, > Also, Consider the following: > > A ---> B INVITE > A <--- B 1xx, contact b1 > A <--- B UPDATE, contact b2 > A ---> B 200 (UPDATE) > A <--- B 1xx, contact (b1 or b2?) > A <--- B 200 (INVITE), contact (b1 or b2?) your example works with the current rules. The first 1xx sets the target to b1. The UPDATE refreshes the target to b2. Since the target is b2 now, that is what the following 1xx says, and the same for the 200 OK to the INVITE. The interesting case is when the UAS does not support 100rel or UPDATE but the UAC supports UPDATE. If we allowed unreliable responses to refresh targets, the UAS could use one such response to refresh the target and the UAC could confirm the refresh by sending an UPDATE request. What we need to think about is whether or not it is worthwhile adding a few more rules (i.e., adding complexity) to cover these types of cases. Cheers, Gonzalo From drage@alcatel-lucent.com Wed Nov 11 06:27:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439EF3A69EA for ; Wed, 11 Nov 2009 06:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC1JySPN1Mwu for ; Wed, 11 Nov 2009 06:27:14 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7A2D23A6840 for ; Wed, 11 Nov 2009 06:27:13 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nABERbKq012951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Nov 2009 15:27:37 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 11 Nov 2009 15:27:37 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Jeroen van Bemmel Date: Wed, 11 Nov 2009 15:27:33 +0100 Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event Thread-Index: Acpi2frMAlI8HV2BS5qQuwjneeVC4AAAL0uQ Message-ID: References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> In-Reply-To: <4AFAC7ED.3070409@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:27:15 -0000 I assume you mean the extension in general, rather than specific Info packa= ges.=20 I could imagine that one might define a feature tag in parallel with a spec= ific Info package. That of course is outside the scope of draft-ietf-sipcore-info-event, but i= t is a reason why we don't need to put Recv-Info into the REGISTER method.= =20 regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, November 11, 2009 2:19 PM > To: Jeroen van Bemmel > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >=20 > Can anyone imagine a case where you would choose one=20 > potential UAS over another based on support for Info Packages? >=20 > Thanks, > Paul >=20 > Jeroen van Bemmel wrote: > > Has it been considered to extend RFC3840/RFC3841 with a=20 > parameter for=20 > > INFO Packages? > >=20 > > Regards, > > Jeroen > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Wed Nov 11 06:51:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BB828C0E5 for ; Wed, 11 Nov 2009 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bDyGsmDJpx1 for ; Wed, 11 Nov 2009 06:51:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2D39A28C0E0 for ; Wed, 11 Nov 2009 06:51:53 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANZe+kqrRN+K/2dsb2JhbADFEpgegmcBgVQE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="202362872" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2009 14:52:18 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nABEqIap007811; Wed, 11 Nov 2009 14:52:18 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.3959); Wed, 11 Nov 2009 09:52:18 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:52:17 -0500 Message-ID: <4AFACFB2.8080609@cisco.com> Date: Wed, 11 Nov 2009 09:52:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> <4AFAC7E6.6070304@ericsson.com> In-Reply-To: <4AFAC7E6.6070304@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:52:17.0896 (UTC) FILETIME=[906F5E80:01CA62DE] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:51:54 -0000 There may be an important distinction here, between the following cases: 1) where there is discretion about when the old address may be released, 2)where there is no discretion - the address will go away (or already has) regardless of what the UA does. We can make up whatever rules we want about case (1). But for case (2) either you send the new address in whatever message you can when you must, or your call simply fails. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > >> Is it really better to prevent the called party from refreshing the >> target instead of allowing a non reliable INVITE 1xx's Contact to >> update the target? > > the UAS wants to refresh the target in order to release its old address > and start using the new one. However, even if it returns unreliable > provisional responses with its new address, it cannot be sure that the > UAC got them. Therefore, it cannot release the old address because it is > not sure whether or not the UAC refreshed the target. > > In any case, the draft will explain the different use cases so that they > are clear for implementers. If the UAC could send requests to the UAS > (e.g., UPDATE), it may make sense to allow unreliable responses to > refresh targets after all... I will need to think about the corner cases... > > Thanks, > > Gonzalo > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed Nov 11 06:56:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D4B3A6877 for ; Wed, 11 Nov 2009 06:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bbr1BKe3SbB for ; Wed, 11 Nov 2009 06:56:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 85DE63A6960 for ; Wed, 11 Nov 2009 06:56:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABJf+kqtJV2Y/2dsb2JhbADFEpgehDwE X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="67486075" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 14:56:51 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nABEuoP6014998; Wed, 11 Nov 2009 14:56:50 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.3959); Wed, 11 Nov 2009 09:56:50 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 09:56:50 -0500 Message-ID: <4AFAD0B8.4060502@cisco.com> Date: Wed, 11 Nov 2009 09:56:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> <4AFAC728.3000008@cisco.com> <4AFAC8F3.1040509@ericsson.com> In-Reply-To: <4AFAC8F3.1040509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 14:56:50.0070 (UTC) FILETIME=[32A9D360:01CA62DF] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:56:24 -0000 Gonzalo Camarillo wrote: > Hi Paul, > >> Also, Consider the following: >> >> A ---> B INVITE >> A <--- B 1xx, contact b1 >> A <--- B UPDATE, contact b2 >> A ---> B 200 (UPDATE) >> A <--- B 1xx, contact (b1 or b2?) >> A <--- B 200 (INVITE), contact (b1 or b2?) > > your example works with the current rules. The first 1xx sets the target > to b1. The UPDATE refreshes the target to b2. Since the target is b2 > now, that is what the following 1xx says, and the same for the 200 OK to > the INVITE. OK. Sorry. > The interesting case is when the UAS does not support 100rel or UPDATE > but the UAC supports UPDATE. If we allowed unreliable responses to > refresh targets, the UAS could use one such response to refresh the > target and the UAC could confirm the refresh by sending an UPDATE request. Is that really an interesting case? How many UAs support *receiving* UPDATE but not *sending* it? > What we need to think about is whether or not it is worthwhile adding a > few more rules (i.e., adding complexity) to cover these types of cases. I do think there is risk of adding complexity, but not enough to actually solve any added problems. I think an interesting use case is the one where a UA suddenly can no longer use its old address, but would like to salvage the call. What all is required to make that possible? What we are discussing would, I think, be necessary but insufficient to solve that problem. Thanks, Paul From gonzalo.camarillo@ericsson.com Wed Nov 11 15:25:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA4E3A6890 for ; Wed, 11 Nov 2009 15:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl7zSpyKT0HR for ; Wed, 11 Nov 2009 15:25:30 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AD6F23A67D9 for ; Wed, 11 Nov 2009 15:25:29 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-9c-4afb4803771f Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 75.50.31706.3084BFA4; Thu, 12 Nov 2009 00:25:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 00:25:55 +0100 Received: from [150.236.158.131] ([150.236.158.131]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 00:25:55 +0100 Message-ID: <4AFB4800.50208@ericsson.com> Date: Thu, 12 Nov 2009 08:25:52 +0900 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Kyzivat References: <4AEF50D0.8010907@zonnet.nl> <4AF0911F.8080503@zonnet.nl> <747A6506A991724FB09B129B79D5FEB613FBC36362@EXMBXCLUS01.citservers.local> <4AF35CB9.1000803@zonnet.nl> <4AF36339.5080600@cisco.com> <4AF64130.1040003@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FCD794FD@EXMBXCLUS01.citservers.local> <4AFA19AC.8030303@ericsson.com> <747A6506A991724FB09B129B79D5FEB613FE0B999C@EXMBXCLUS01.citservers.local> <4AFAC728.3000008@cisco.com> <4AFAC8F3.1040509@ericsson.com> <4AFAD0B8.4060502@cisco.com> In-Reply-To: <4AFAD0B8.4060502@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2009 23:25:55.0662 (UTC) FILETIME=[514146E0:01CA6326] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Changing contact/remote target in target refresh response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:25:30 -0000 Hi Paul, > Is that really an interesting case? How many UAs support *receiving* > UPDATE but not *sending* it? that is what I meant when I said we need to analyze whether or not we should add more complexity to address weird corner cases. If the UAs support UPDATE, they can refresh the target using UPDATE requests. We do not have any problem in that case. > I think an interesting use case is the one where a UA suddenly can no > longer use its old address, but would like to salvage the call. What all > is required to make that possible? What we are discussing would, I > think, be necessary but insufficient to solve that problem. yes, this is the analysis we have to make. We should try and keep things as simple as possible. If adding complexity servers a purpose, we can consider doing that. However, we should avoid adding complexity that would not bring any benefit. Thanks, Gonzalo From christer.holmberg@ericsson.com Wed Nov 11 19:29:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4272B3A682A for ; Wed, 11 Nov 2009 19:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s63aXHP-JBr7 for ; Wed, 11 Nov 2009 19:29:18 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1FB2728C1B7 for ; Wed, 11 Nov 2009 19:28:49 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-3d-4afb810d693a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 83.3A.24094.D018BFA4; Thu, 12 Nov 2009 04:29:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 04:29:13 +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: Thu, 12 Nov 2009 04:29:13 +0100 Message-ID: In-Reply-To: <4AFAC2F2.2090001@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event thread-index: Acpi1/Xn7l/jssJjRsW3vwhBMuaYWAAcCIig References: <4AFAC2F2.2090001@zonnet.nl> From: "Christer Holmberg" To: "Jeroen van Bemmel" , X-OriginalArrivalTime: 12 Nov 2009 03:29:13.0936 (UTC) FILETIME=[4E811D00:01CA6348] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:29:19 -0000 Hi, We discussed that a while ago, when we dicussed the meaning of Recv-Info in REGISTER. Adam suggested that we do that in a separate draft (since we are in WGLC). Regards, Chritser=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Jeroen van Bemmel Sent: 11. marraskuuta 2009 16:58 To: sipcore@ietf.org Subject: [sipcore] Caller prefs / callee caps for INFO Event Has it been considered to extend RFC3840/RFC3841 with a parameter for INFO Packages? Regards, Jeroen _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Nov 11 19:32:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761B33A676A for ; Wed, 11 Nov 2009 19:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvVTmSr31Cr8 for ; Wed, 11 Nov 2009 19:32:30 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 330123A684C for ; Wed, 11 Nov 2009 19:32:29 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-86-4afb81e9248b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 10.46.31706.9E18BFA4; Thu, 12 Nov 2009 04:32:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 04:32:57 +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: Thu, 12 Nov 2009 04:32:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event thread-index: Acpi2frMAlI8HV2BS5qQuwjneeVC4AAAL0uQABtmt/A= References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Paul Kyzivat" , "Jeroen van Bemmel" X-OriginalArrivalTime: 12 Nov 2009 03:32:57.0277 (UTC) FILETIME=[D3A03ED0:01CA6348] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:32:31 -0000 Hi Keith, There was not much discussion on this, since we should concentrate on getting the core spec done, but one idea was that specific Info Packages COULD define values. The details (whether we would use a namespace etc) would of course have to be discussed. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 11. marraskuuta 2009 17:28 To: Paul Kyzivat; Jeroen van Bemmel Cc: sipcore@ietf.org Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event I assume you mean the extension in general, rather than specific Info packages.=20 I could imagine that one might define a feature tag in parallel with a specific Info package. That of course is outside the scope of draft-ietf-sipcore-info-event, but it is a reason why we don't need to put Recv-Info into the REGISTER method.=20 regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, November 11, 2009 2:19 PM > To: Jeroen van Bemmel > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >=20 > Can anyone imagine a case where you would choose one potential UAS=20 > over another based on support for Info Packages? >=20 > Thanks, > Paul >=20 > Jeroen van Bemmel wrote: > > Has it been considered to extend RFC3840/RFC3841 with a > parameter for > > INFO Packages? > >=20 > > Regards, > > Jeroen > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From jbemmel@zonnet.nl Thu Nov 12 04:55:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861CE28C168 for ; Thu, 12 Nov 2009 04:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmc8VIKoZHTX for ; Thu, 12 Nov 2009 04:55:51 -0800 (PST) Received: from smtp5.versatel.nl (smtp5.versatel.nl [62.58.50.96]) by core3.amsl.com (Postfix) with ESMTP id 669FE3A6A9B for ; Thu, 12 Nov 2009 04:55:50 -0800 (PST) Received: (qmail 26095 invoked by uid 0); 12 Nov 2009 12:56:16 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp5.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 12 Nov 2009 12:56:16 -0000 Message-ID: <4AFC05EC.9050800@zonnet.nl> Date: Thu, 12 Nov 2009 13:56:12 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 12:55:52 -0000 I mean something similar to events="!presence,message-summary" (RFC3840) so maybe +sip.info-packages="foo,!bar" The point would be to standardize the tag name that is used. This will enable a UA to announce the Info packages it supports in REGISTER, and enables routing based on that information. The use case for this is the same as for event packages, it's mostly for sake of completeness / consistency I don't see why it would hurt to add this item to the draft, seems overkill to write a separate RFC just for this Regards, Jeroen DRAGE, Keith (Keith) wrote: > I assume you mean the extension in general, rather than specific Info packages. > > I could imagine that one might define a feature tag in parallel with a specific Info package. > > That of course is outside the scope of draft-ietf-sipcore-info-event, but it is a reason why we don't need to put Recv-Info into the REGISTER method. > > regards > > Keith > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, November 11, 2009 2:19 PM >> To: Jeroen van Bemmel >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >> >> Can anyone imagine a case where you would choose one >> potential UAS over another based on support for Info Packages? >> >> Thanks, >> Paul >> >> Jeroen van Bemmel wrote: >> >>> Has it been considered to extend RFC3840/RFC3841 with a >>> >> parameter for >> >>> INFO Packages? >>> >>> Regards, >>> Jeroen >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From john.elwell@siemens-enterprise.com Thu Nov 12 14:00:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748483A67E4 for ; Thu, 12 Nov 2009 14:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jeI9jekR62H for ; Thu, 12 Nov 2009 14:00:05 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 733A028C105 for ; Thu, 12 Nov 2009 14:00:04 -0800 (PST) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nACM0Sm3020756; Thu, 12 Nov 2009 23:00:28 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nACM0S9t012766; Thu, 12 Nov 2009 23:00:28 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 12 Nov 2009 23:00:26 +0100 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat Date: Thu, 12 Nov 2009 23:00:24 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcpiemluaF+KBLlrRoekTr7GRQHOdQALgaUAAADkjuAATazYIA== Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:00:06 -0000 I am not sure we need to specify how B (the B2BUA) handles the Recv-Info he= ader field in 3PCC situations. We just need to specify use of the header fi= eld in such a way that leaves at least one possible solution for B2BUAs. If= this means B2BUAs need to store the latest Recv-Info contents from each UA= , so that it can forward them when required, that would be a sufficient sol= ution. The principle of mandating Recv-Info in each (re-)INVITE request and= its 2xx response seems to permit a B2BUA to manage things appropriately. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 11 November 2009 08:53 > To: Christer Holmberg; Paul Kyzivat > Cc: sipcore@ietf.org; Jeroen van Bemmel > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 >=20 > Hi, >=20 > Please forget the audit proposal until we decide on whether we could > agree on assuming that B supports Info Packages in order to=20 > make sure it > works between A and D. That would be even esier - we don't need to > mandate Recv-Info in every message, and we don't need to define the > audit :) >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 11. marraskuuta 2009 11:35 > To: Paul Kyzivat > Cc: sipcore@ietf.org; Jeroen van Bemmel > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > header >=20 >=20 > Hi,=20 >=20 > >>Thanks for the description! > >>=20 > >>Now, assuming that B2BUA B does NOT support I-P (if B does support=20 > >>I-P, there should be no issue), it would not insert Recv-Info (not=20 > >>even an empty header) in the initial INVITE requests sent=20 > to A and C. > >>=20 > >>In addition, B would most likely not insert Recv-Info in=20 > the re-INVITE >=20 > >>request to D. > >>=20 > >>So, mandating Recv-Info in every message would not solve the issue. > > > >If Recv-Info is mandated in every message, then doesn't the=20 > absence of > Recv-Info mean that it doesn't support Info=20 > >packages at all, at least momentarily? (Until it sends a R-I.) >=20 > Exactly, so if B doesn't support Info Packages then A, C and=20 > D will all > think that the other entity won't support Info-Packages, so=20 > that doesn't > solve the issue either. >=20 > But, one alternative to solve the case when B does support I-P (or, at > least is configured to insert Recv-Info) would be de define a specific > "audit" value for Recv-Info, which means "Please send your list of I-P > packages even if it hasn't changed". >=20 > Then, when B sends the re-INVITE to D it would include something like > Recv-Info:* (or whatever value we use for audit). >=20 > "*" could also be used with other listed packages, so when B sends D's > list to A it can ensure that A sends its list back so that D will get > it. >=20 > In my opinion that is far more nicer than mandating Revc-Info in every > message, and it actually solves some of the 3pcc use-cases :) >=20 > Would people be ok with that?=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 10. marraskuuta 2009 23:18 > > To: Jeroen van Bemmel > > Cc: Christer Holmberg; sipcore@ietf.org > > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info=20 > > header > >=20 > > The most straightforward 3pcc case to explain is: > >=20 > > A --------- B ---------- C > > | > > |----------- D > >=20 > > Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and > B-C. > > Later B decides to transfer the call from C to D. So it=20 > establishes a=20 > > new dialog B-D and reinvites A to splice it in. I'm hand=20 > waving over=20 > > the details, because there are many options and they don't matter > here. > >=20 > > The key point is that A was, for all intents and purposes,=20 > initially=20 > > connected to C, and after a reinvite finds itself connected to D. > >=20 > > Now D may not be able to support the same Info Packages that C did. > > To make things work, the R-I values from D must be=20 > presented to A, and >=20 > > it needs to honor them. > >=20 > > Conversely, D needs to be informed of the info packages that A is=20 > > willing to receive. While it is possible that B could have=20 > remembered=20 > > them, and could thus insert them in the initial invite to D, its=20 > > better if B doesn't have to get involved in that. > >=20 > > Many new features run into essentially the same problem=20 > with 3pcc. You >=20 > > just cannot assume state negotiated e2e will survive a reinvite. > >=20 > > And this is quite a bit different than the stability of route sets,=20 > > because the route set distinct in each dialog. It doesn't go e2e=20 > > through the B2BUA. > >=20 > > Thanks, > > Paul > >=20 > > Jeroen van Bemmel wrote: > >> Christer, > >> > >> Given the registration requirement (i.e. there needs to be=20 > some sort=20 > >> of > >> spec) the set of INFO packages will be limited. UAs can=20 > easily list=20 > >> those packages they support up front. Therefore the "fully dynamic" > >> case you sketch below seems unlikely to me. > >> > >> The only case I could imagine would be in case of long running=20 > >> dialogs, where the software of one of the peers gets upgraded=20 > >> mid-dialog to support some new INFO package. However, also=20 > that seems >=20 > >> highly unlikely to me. > >> > >> To me, we should keep it simple - "learn INFO packages=20 > whenever you=20 > >> learn the Route set for a Dialog" should be simple enough for=20 > >> developers to get right > >> > >> Regards, > >> Jeroen > >> > >> Christer Holmberg wrote: > >>> Hi, > >>> =20 > >>>> I also think it's overkill. Furthermore, I don't see a=20 > real world=20 > >>>> use > >>>> =20 > >>> case for changing the set of supported INFO > >>>> packages mid-dialog. Surely the UAS can simply reply with a 403 > >>>> =20 > >>> response when it receives an INFO request which it > >>>> doesn't want to process anymore? > >>>> > >>>> To me, INFO packages should be like the Dialog's route=20 > set: learn=20 > >>>> the > >>>> =20 > >>> supported set from the initial INVITE and 1xx-2xx > >>>> responses, after that don't change it anymore > >>>> =20 > >>> I think Adam made the same comment in the SIPCORE session. > >>> > >>> Personally I think there could be cases where one wants to add a=20 > >>> package during a dialog. For example, assume I call you. Then,=20 > >>> during > >=20 > >>> the dialog we decide to start using application X which=20 > uses an Info >=20 > >>> Package, so our phones send Recv-Info:X to each other.=20 > Application X >=20 > >>> may not even be running when we initiate the dialog. > >>> > >>> However, if we are going to require the header in a lot=20 > of messages, >=20 > >>> maybe we should remove PRACK from the list of allowed messages.=20 > >>> Would > >=20 > >>> people have problems with that? > >>> > >>> But, I would like Paul to comment whether mandating the header in=20 > >>> every message would actually solve his 3pcc use-case. > >>> > >>> =20 > >>>> PS The usage of 'nil' to denote no supported packages is not=20 > >>>> consistent > >>>> =20 > >>> with conventions used today, e.g. for Supported > >>>> (suggest to simply use an empty value instead) > >>>> =20 > >>> I think there was some WGLC comment(s) asking about the=20 > same thing. > >>> Personally I have no problem to use an empty header instead of > 'nil'. > >>> However, I want to ensure that nobody objects to such=20 > change before=20 > >>> I > >=20 > >>> implement it. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> DRAGE, Keith (Keith) wrote: > >>> =20 > >>>> This works, but it seems overkill to me. > >>>> > >>>> Firstly can I ensure that this does not include REGISTER, which=20 > >>>> could > >>>> =20 > >>> also be understood from the paraphrase of the SIPCORE discussion. > >>> =20 > >>>> Secondly can I still have more detail (arrow diagram) on the=20 > >>>> scenario > >>>> =20 > >>> we are trying to solve for 3pcc. I can't see if there is a simple=20 > >>> solution if the problem is insufficiently clear. > >>> =20 > >>>> Keith > >>>> > >>>> =20 > >>>>> -----Original Message----- > >>>>> From: sipcore-bounces@ietf.org > >>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>>> Sent: Monday, November 09, 2009 4:15 AM > >>>>> To: Christer Holmberg > >>>>> Cc: sipcore@ietf.org > >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >>>>> Recv-Info > >>>>> =20 > >>> =20 > >>>>> header > >>>>> > >>>>> That works for me, and it is sufficiently simple that everybody=20 > >>>>> should be able to implement it correctly. :-) > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> Christer Holmberg wrote: > >>>>> =20 > >>>>>> Hi, > >>>>>> > >>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE=20 > session we >=20 > >>>>>> discussed whether we should mandate to include Recv-Info in > >>>>>> =20 > >>>>> re-INVITE > >>>>> =20 > >>>>>> responses. > >>>>>> > >>>>>> The outcome of the discussion was that EVERY SIP=20 > messages where=20 > >>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>>>>> =20 > >>>>> the set of > >>>>> =20 > >>>>>> Info Packages has changed or not. > >>>>>> > >>>>>> Based on the -03pre version of the draft the following > >>>>>> =20 > >>>>> messages would > >>>>> =20 > >>>>>> be > >>>>>> affected: > >>>>>> > >>>>>> INVITE + 18x + 200 > >>>>>> Re-INVITE + 18x + 200 > >>>>>> ACK > >>>>>> UPDATE + 200 > >>>>>> PRACK + 200 > >>>>>> > >>>>>> That is a change from previous versions of the draft, which > >>>>>> =20 > >>>>> says that > >>>>> =20 > >>>>>> the Recv-Info header only needs to be inserted if the=20 > set of Info >=20 > >>>>>> Packages changes. > >>>>>> > >>>>>> So, unless people have issues with that, my intention is to > >>>>>> =20 > >>>>> implement > >>>>> =20 > >>>>>> the change in the next version of the draft. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> > >>>>>> =20 > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> =20 > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>>> =20 > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> =20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From eburger@standardstrack.com Thu Nov 12 14:19:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A583A6831 for ; Thu, 12 Nov 2009 14:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCMb71zu4E6W for ; Thu, 12 Nov 2009 14:19:03 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id E7D793A6784 for ; Thu, 12 Nov 2009 14:19:02 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8i0k-0006Hy-Mk for sipcore@ietf.org; Thu, 12 Nov 2009 14:19:27 -0800 Message-Id: <6E6C3691-08C4-41D9-B6C1-FBA6BCF9925B@standardstrack.com> From: Eric Burger To: SIPCORE In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 13 Nov 2009 07:19:28 +0900 References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:19:04 -0000 Said differently, "live by the B2BUA, die by the B2BUA." When you sign up to build a B2BUA, you are signing up to remember a ton of state. Adding the Info-Package set for each remote UAC is trivial compared to the state (and risk you take by putting state in the network) you have to keep to keep the SIP session alive. On Nov 13, 2009, at 7:00 AM, Elwell, John wrote: > I am not sure we need to specify how B (the B2BUA) handles the Recv- > Info header field in 3PCC situations. We just need to specify use of > the header field in such a way that leaves at least one possible > solution for B2BUAs. If this means B2BUAs need to store the latest > Recv-Info contents from each UA, so that it can forward them when > required, that would be a sufficient solution. The principle of > mandating Recv-Info in each (re-)INVITE request and its 2xx response > seems to permit a B2BUA to manage things appropriately. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 11 November 2009 08:53 >> To: Christer Holmberg; Paul Kyzivat >> Cc: sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info header >> >> >> Hi, >> >> Please forget the audit proposal until we decide on whether we could >> agree on assuming that B supports Info Packages in order to >> make sure it >> works between A and D. That would be even esier - we don't need to >> mandate Recv-Info in every message, and we don't need to define the >> audit :) >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 11. marraskuuta 2009 11:35 >> To: Paul Kyzivat >> Cc: sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> >> Hi, >> >>>> Thanks for the description! >>>> >>>> Now, assuming that B2BUA B does NOT support I-P (if B does support >>>> I-P, there should be no issue), it would not insert Recv-Info (not >>>> even an empty header) in the initial INVITE requests sent >> to A and C. >>>> >>>> In addition, B would most likely not insert Recv-Info in >> the re-INVITE >> >>>> request to D. >>>> >>>> So, mandating Recv-Info in every message would not solve the issue. >>> >>> If Recv-Info is mandated in every message, then doesn't the >> absence of >> Recv-Info mean that it doesn't support Info >>> packages at all, at least momentarily? (Until it sends a R-I.) >> >> Exactly, so if B doesn't support Info Packages then A, C and >> D will all >> think that the other entity won't support Info-Packages, so >> that doesn't >> solve the issue either. >> >> But, one alternative to solve the case when B does support I-P (or, >> at >> least is configured to insert Recv-Info) would be de define a >> specific >> "audit" value for Recv-Info, which means "Please send your list of >> I-P >> packages even if it hasn't changed". >> >> Then, when B sends the re-INVITE to D it would include something like >> Recv-Info:* (or whatever value we use for audit). >> >> "*" could also be used with other listed packages, so when B sends >> D's >> list to A it can ensure that A sends its list back so that D will get >> it. >> >> In my opinion that is far more nicer than mandating Revc-Info in >> every >> message, and it actually solves some of the 3pcc use-cases :) >> >> Would people be ok with that? >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 10. marraskuuta 2009 23:18 >>> To: Jeroen van Bemmel >>> Cc: Christer Holmberg; sipcore@ietf.org >>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info >>> header >>> >>> The most straightforward 3pcc case to explain is: >>> >>> A --------- B ---------- C >>> | >>> |----------- D >>> >>> Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and >> B-C. >>> Later B decides to transfer the call from C to D. So it >> establishes a >>> new dialog B-D and reinvites A to splice it in. I'm hand >> waving over >>> the details, because there are many options and they don't matter >> here. >>> >>> The key point is that A was, for all intents and purposes, >> initially >>> connected to C, and after a reinvite finds itself connected to D. >>> >>> Now D may not be able to support the same Info Packages that C did. >>> To make things work, the R-I values from D must be >> presented to A, and >> >>> it needs to honor them. >>> >>> Conversely, D needs to be informed of the info packages that A is >>> willing to receive. While it is possible that B could have >> remembered >>> them, and could thus insert them in the initial invite to D, its >>> better if B doesn't have to get involved in that. >>> >>> Many new features run into essentially the same problem >> with 3pcc. You >> >>> just cannot assume state negotiated e2e will survive a reinvite. >>> >>> And this is quite a bit different than the stability of route sets, >>> because the route set distinct in each dialog. It doesn't go e2e >>> through the B2BUA. >>> >>> Thanks, >>> Paul >>> >>> Jeroen van Bemmel wrote: >>>> Christer, >>>> >>>> Given the registration requirement (i.e. there needs to be >> some sort >>>> of >>>> spec) the set of INFO packages will be limited. UAs can >> easily list >>>> those packages they support up front. Therefore the "fully dynamic" >>>> case you sketch below seems unlikely to me. >>>> >>>> The only case I could imagine would be in case of long running >>>> dialogs, where the software of one of the peers gets upgraded >>>> mid-dialog to support some new INFO package. However, also >> that seems >> >>>> highly unlikely to me. >>>> >>>> To me, we should keep it simple - "learn INFO packages >> whenever you >>>> learn the Route set for a Dialog" should be simple enough for >>>> developers to get right >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>> I also think it's overkill. Furthermore, I don't see a >> real world >>>>>> use >>>>>> >>>>> case for changing the set of supported INFO >>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>> >>>>> response when it receives an INFO request which it >>>>>> doesn't want to process anymore? >>>>>> >>>>>> To me, INFO packages should be like the Dialog's route >> set: learn >>>>>> the >>>>>> >>>>> supported set from the initial INVITE and 1xx-2xx >>>>>> responses, after that don't change it anymore >>>>>> >>>>> I think Adam made the same comment in the SIPCORE session. >>>>> >>>>> Personally I think there could be cases where one wants to add a >>>>> package during a dialog. For example, assume I call you. Then, >>>>> during >>> >>>>> the dialog we decide to start using application X which >> uses an Info >> >>>>> Package, so our phones send Recv-Info:X to each other. >> Application X >> >>>>> may not even be running when we initiate the dialog. >>>>> >>>>> However, if we are going to require the header in a lot >> of messages, >> >>>>> maybe we should remove PRACK from the list of allowed messages. >>>>> Would >>> >>>>> people have problems with that? >>>>> >>>>> But, I would like Paul to comment whether mandating the header in >>>>> every message would actually solve his 3pcc use-case. >>>>> >>>>> >>>>>> PS The usage of 'nil' to denote no supported packages is not >>>>>> consistent >>>>>> >>>>> with conventions used today, e.g. for Supported >>>>>> (suggest to simply use an empty value instead) >>>>>> >>>>> I think there was some WGLC comment(s) asking about the >> same thing. >>>>> Personally I have no problem to use an empty header instead of >> 'nil'. >>>>> However, I want to ensure that nobody objects to such >> change before >>>>> I >>> >>>>> implement it. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> DRAGE, Keith (Keith) wrote: >>>>> >>>>>> This works, but it seems overkill to me. >>>>>> >>>>>> Firstly can I ensure that this does not include REGISTER, which >>>>>> could >>>>>> >>>>> also be understood from the paraphrase of the SIPCORE discussion. >>>>> >>>>>> Secondly can I still have more detail (arrow diagram) on the >>>>>> scenario >>>>>> >>>>> we are trying to solve for 3pcc. I can't see if there is a simple >>>>> solution if the problem is insufficiently clear. >>>>> >>>>>> Keith >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sipcore-bounces@ietf.org >>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>> To: Christer Holmberg >>>>>>> Cc: sipcore@ietf.org >>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>>>>> Recv-Info >>>>>>> >>>>> >>>>>>> header >>>>>>> >>>>>>> That works for me, and it is sufficiently simple that everybody >>>>>>> should be able to implement it correctly. :-) >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> Christer Holmberg wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE >> session we >> >>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>> >>>>>>> re-INVITE >>>>>>> >>>>>>>> responses. >>>>>>>> >>>>>>>> The outcome of the discussion was that EVERY SIP >> messages where >>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>> >>>>>>> the set of >>>>>>> >>>>>>>> Info Packages has changed or not. >>>>>>>> >>>>>>>> Based on the -03pre version of the draft the following >>>>>>>> >>>>>>> messages would >>>>>>> >>>>>>>> be >>>>>>>> affected: >>>>>>>> >>>>>>>> INVITE + 18x + 200 >>>>>>>> Re-INVITE + 18x + 200 >>>>>>>> ACK >>>>>>>> UPDATE + 200 >>>>>>>> PRACK + 200 >>>>>>>> >>>>>>>> That is a change from previous versions of the draft, which >>>>>>>> >>>>>>> says that >>>>>>> >>>>>>>> the Recv-Info header only needs to be inserted if the >> set of Info >> >>>>>>>> Packages changes. >>>>>>>> >>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>> >>>>>>> implement >>>>>>> >>>>>>>> the change in the next version of the draft. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From eburger@standardstrack.com Thu Nov 12 14:21:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8E63A6928 for ; Thu, 12 Nov 2009 14:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC7W5ZR8PSel for ; Thu, 12 Nov 2009 14:21:12 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id A0D283A6847 for ; Thu, 12 Nov 2009 14:21:12 -0800 (PST) Received: from host-113-35.meeting.ietf.org ([133.93.113.35]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N8i2o-0006hR-IJ; Thu, 12 Nov 2009 14:21:34 -0800 Message-Id: From: Eric Burger To: Jeroen van Bemmel In-Reply-To: <4AFC05EC.9050800@zonnet.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 13 Nov 2009 07:21:36 +0900 References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> <4AFC05EC.9050800@zonnet.nl> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:21:13 -0000 How about, "We have been working on this for two years." We are getting beyond perfection. Look, if you do not want a standard, interoperable version of INFO, let us just say so and kill it off now. On Nov 12, 2009, at 9:56 PM, Jeroen van Bemmel wrote: > I mean something similar to > > events="!presence,message-summary" (RFC3840) > > so maybe > +sip.info-packages="foo,!bar" > > The point would be to standardize the tag name that is used. This > will enable a UA to announce the Info packages it supports in > REGISTER, and enables routing based on that information. > The use case for this is the same as for event packages, it's mostly > for sake of completeness / consistency > > I don't see why it would hurt to add this item to the draft, seems > overkill to write a separate RFC just for this > > Regards, > Jeroen > > > > DRAGE, Keith (Keith) wrote: >> I assume you mean the extension in general, rather than specific >> Info packages. >> I could imagine that one might define a feature tag in parallel >> with a specific Info package. >> >> That of course is outside the scope of draft-ietf-sipcore-info- >> event, but it is a reason why we don't need to put Recv-Info into >> the REGISTER method. >> regards >> >> Keith >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] >>> On Behalf Of Paul Kyzivat >>> Sent: Wednesday, November 11, 2009 2:19 PM >>> To: Jeroen van Bemmel >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >>> >>> Can anyone imagine a case where you would choose one potential UAS >>> over another based on support for Info Packages? >>> >>> Thanks, >>> Paul >>> >>> Jeroen van Bemmel wrote: >>> >>>> Has it been considered to extend RFC3840/RFC3841 with a >>> parameter for >>>> INFO Packages? >>>> >>>> Regards, >>>> Jeroen >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Thu Nov 12 15:22:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951D53A67F0 for ; Thu, 12 Nov 2009 15:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDjAyiK6faOD for ; Thu, 12 Nov 2009 15:22:58 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 72B3A3A6AEF for ; Thu, 12 Nov 2009 15:22:58 -0800 (PST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nACNNNdX000986; Fri, 13 Nov 2009 00:23:23 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nACNNNuI023276; Fri, 13 Nov 2009 00:23:23 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Fri, 13 Nov 2009 00:23:22 +0100 From: "Elwell, John" To: Jeroen van Bemmel , "DRAGE, Keith (Keith)" Date: Fri, 13 Nov 2009 00:23:19 +0100 Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event Thread-Index: Acpjl5akDmMV393lSQGha/F/Qd+v+gAV212Q Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3C6D@DEMCHP99E35MSX.ww902.siemens.net> References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> <4AFC05EC.9050800@zonnet.nl> In-Reply-To: <4AFC05EC.9050800@zonnet.nl> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 23:22:59 -0000 We should not add this new functionality following WGLC. Let's just finish = what we have. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jeroen van Bemmel > Sent: 12 November 2009 12:56 > To: DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >=20 > I mean something similar to >=20 > events=3D"!presence,message-summary" (RFC3840) >=20 > so maybe=20 >=20 > +sip.info-packages=3D"foo,!bar" >=20 > The point would be to standardize the tag name that is used.=20 > This will enable a UA to announce the Info packages it=20 > supports in REGISTER, and enables routing based on that information. > The use case for this is the same as for event packages, it's=20 > mostly for sake of completeness / consistency >=20 > I don't see why it would hurt to add this item to the draft,=20 > seems overkill to write a separate RFC just for this >=20 > Regards, > Jeroen >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > I assume you mean the extension in general, rather than=20 > specific Info packages.=20 > > > > I could imagine that one might define a feature tag in=20 > parallel with a specific Info package. > > > > That of course is outside the scope of=20 > draft-ietf-sipcore-info-event, but it is a reason why we=20 > don't need to put Recv-Info into the REGISTER method.=20 > > > > regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org=20 > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Wednesday, November 11, 2009 2:19 PM > >> To: Jeroen van Bemmel > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event > >> > >> Can anyone imagine a case where you would choose one=20 > >> potential UAS over another based on support for Info Packages? > >> > >> Thanks, > >> Paul > >> > >> Jeroen van Bemmel wrote: > >> =20 > >>> Has it been considered to extend RFC3840/RFC3841 with a=20 > >>> =20 > >> parameter for=20 > >> =20 > >>> INFO Packages? > >>> > >>> Regards, > >>> Jeroen > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>> =20 > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From george.foti@ericsson.com Thu Nov 12 16:00:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31603A6784 for ; Thu, 12 Nov 2009 16:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlNKow-fRJLZ for ; Thu, 12 Nov 2009 16:00:31 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C3D103A681A for ; Thu, 12 Nov 2009 16:00:31 -0800 (PST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nAD00uBH018387; Thu, 12 Nov 2009 18:01:00 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:59:41 -0600 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:59:41 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 12 Nov 2009 18:59:40 -0500 From: George Foti To: Eric Burger , Jeroen van Bemmel Date: Thu, 12 Nov 2009 18:59:38 -0500 Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event Thread-Index: Acpj5otIyOv/m6YnT+ODHqixYEyAkgADYJ1g Message-ID: References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> <4AFC05EC.9050800@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-OriginalArrivalTime: 12 Nov 2009 23:59:41.0075 (UTC) FILETIME=[32E88630:01CA63F4] Cc: SIPCORE Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:00:32 -0000 Well said. We need this out NOW. No value added anymore with all this tinkering Thanks George =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Eric Burger Sent: Thursday, November 12, 2009 5:22 PM To: Jeroen van Bemmel Cc: SIPCORE Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event How about, "We have been working on this for two years." We are getting be= yond perfection. Look, if you do not want a standard, interoperable versio= n of INFO, let us just say so and kill it off now. On Nov 12, 2009, at 9:56 PM, Jeroen van Bemmel wrote: > I mean something similar to > > events=3D"!presence,message-summary" (RFC3840) > > so maybe > +sip.info-packages=3D"foo,!bar" > > The point would be to standardize the tag name that is used. This will=20 > enable a UA to announce the Info packages it supports in REGISTER, and=20 > enables routing based on that information. > The use case for this is the same as for event packages, it's mostly=20 > for sake of completeness / consistency > > I don't see why it would hurt to add this item to the draft, seems=20 > overkill to write a separate RFC just for this > > Regards, > Jeroen > > > > DRAGE, Keith (Keith) wrote: >> I assume you mean the extension in general, rather than specific Info=20 >> packages. >> I could imagine that one might define a feature tag in parallel with=20 >> a specific Info package. >> >> That of course is outside the scope of draft-ietf-sipcore-info-=20 >> event, but it is a reason why we don't need to put Recv-Info into the=20 >> REGISTER method. >> regards >> >> Keith >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Wednesday, November 11, 2009 2:19 PM >>> To: Jeroen van Bemmel >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event >>> >>> Can anyone imagine a case where you would choose one potential UAS=20 >>> over another based on support for Info Packages? >>> >>> Thanks, >>> Paul >>> >>> Jeroen van Bemmel wrote: >>> >>>> Has it been considered to extend RFC3840/RFC3841 with a >>> parameter for >>>> INFO Packages? >>>> >>>> Regards, >>>> Jeroen >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Thu Nov 12 16:07:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2233A68EE for ; Thu, 12 Nov 2009 16:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUOq-vewEIZA for ; Thu, 12 Nov 2009 16:07:10 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 37BA43A6784 for ; Thu, 12 Nov 2009 16:07:10 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAD8x/EqrR7Ht/2dsb2JhbAC9S5gihDwE X-IronPort-AV: E=Sophos;i="4.44,731,1249257600"; d="scan'208";a="103817620" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2009 00:07:40 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAD07dhr017987; Fri, 13 Nov 2009 00:07: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.3959); Thu, 12 Nov 2009 19:07:39 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 19:07:38 -0500 Message-ID: <4AFCA34E.20200@cisco.com> Date: Thu, 12 Nov 2009 19:07:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2009 00:07:38.0728 (UTC) FILETIME=[4F9C9680:01CA63F5] Cc: Jeroen van Bemmel , "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:07:11 -0000 Elwell, John wrote: > I am not sure we need to specify how B (the B2BUA) handles the Recv-Info header field in 3PCC situations. We just need to specify use of the header field in such a way that leaves at least one possible solution for B2BUAs. If this means B2BUAs need to store the latest Recv-Info contents from each UA, so that it can forward them when required, that would be a sufficient solution. The principle of mandating Recv-Info in each (re-)INVITE request and its 2xx response seems to permit a B2BUA to manage things appropriately. I think that works for me. I've lost track - is R-I still ok in UPDATE, ACK, PRACK? When a 3pcc controlling is initiating a call from the middle, it starts out not knowing anything about what either side can do. So it can't properly declare R-I in the INVITE. It will learn the capabilities of each side in the response to the INVITE. It would then like to reflect them to the "other side" asap, which means in one of the above. As long as it can do that, I think its ok. Thanks, Paul > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 11 November 2009 08:53 >> To: Christer Holmberg; Paul Kyzivat >> Cc: sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info header >> >> >> Hi, >> >> Please forget the audit proposal until we decide on whether we could >> agree on assuming that B supports Info Packages in order to >> make sure it >> works between A and D. That would be even esier - we don't need to >> mandate Recv-Info in every message, and we don't need to define the >> audit :) >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 11. marraskuuta 2009 11:35 >> To: Paul Kyzivat >> Cc: sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> >> Hi, >> >>>> Thanks for the description! >>>> >>>> Now, assuming that B2BUA B does NOT support I-P (if B does support >>>> I-P, there should be no issue), it would not insert Recv-Info (not >>>> even an empty header) in the initial INVITE requests sent >> to A and C. >>>> In addition, B would most likely not insert Recv-Info in >> the re-INVITE >> >>>> request to D. >>>> >>>> So, mandating Recv-Info in every message would not solve the issue. >>> If Recv-Info is mandated in every message, then doesn't the >> absence of >> Recv-Info mean that it doesn't support Info >>> packages at all, at least momentarily? (Until it sends a R-I.) >> Exactly, so if B doesn't support Info Packages then A, C and >> D will all >> think that the other entity won't support Info-Packages, so >> that doesn't >> solve the issue either. >> >> But, one alternative to solve the case when B does support I-P (or, at >> least is configured to insert Recv-Info) would be de define a specific >> "audit" value for Recv-Info, which means "Please send your list of I-P >> packages even if it hasn't changed". >> >> Then, when B sends the re-INVITE to D it would include something like >> Recv-Info:* (or whatever value we use for audit). >> >> "*" could also be used with other listed packages, so when B sends D's >> list to A it can ensure that A sends its list back so that D will get >> it. >> >> In my opinion that is far more nicer than mandating Revc-Info in every >> message, and it actually solves some of the 3pcc use-cases :) >> >> Would people be ok with that? >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 10. marraskuuta 2009 23:18 >>> To: Jeroen van Bemmel >>> Cc: Christer Holmberg; sipcore@ietf.org >>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info >>> header >>> >>> The most straightforward 3pcc case to explain is: >>> >>> A --------- B ---------- C >>> | >>> |----------- D >>> >>> Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and >> B-C. >>> Later B decides to transfer the call from C to D. So it >> establishes a >>> new dialog B-D and reinvites A to splice it in. I'm hand >> waving over >>> the details, because there are many options and they don't matter >> here. >>> The key point is that A was, for all intents and purposes, >> initially >>> connected to C, and after a reinvite finds itself connected to D. >>> >>> Now D may not be able to support the same Info Packages that C did. >>> To make things work, the R-I values from D must be >> presented to A, and >> >>> it needs to honor them. >>> >>> Conversely, D needs to be informed of the info packages that A is >>> willing to receive. While it is possible that B could have >> remembered >>> them, and could thus insert them in the initial invite to D, its >>> better if B doesn't have to get involved in that. >>> >>> Many new features run into essentially the same problem >> with 3pcc. You >> >>> just cannot assume state negotiated e2e will survive a reinvite. >>> >>> And this is quite a bit different than the stability of route sets, >>> because the route set distinct in each dialog. It doesn't go e2e >>> through the B2BUA. >>> >>> Thanks, >>> Paul >>> >>> Jeroen van Bemmel wrote: >>>> Christer, >>>> >>>> Given the registration requirement (i.e. there needs to be >> some sort >>>> of >>>> spec) the set of INFO packages will be limited. UAs can >> easily list >>>> those packages they support up front. Therefore the "fully dynamic" >>>> case you sketch below seems unlikely to me. >>>> >>>> The only case I could imagine would be in case of long running >>>> dialogs, where the software of one of the peers gets upgraded >>>> mid-dialog to support some new INFO package. However, also >> that seems >> >>>> highly unlikely to me. >>>> >>>> To me, we should keep it simple - "learn INFO packages >> whenever you >>>> learn the Route set for a Dialog" should be simple enough for >>>> developers to get right >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>> I also think it's overkill. Furthermore, I don't see a >> real world >>>>>> use >>>>>> >>>>> case for changing the set of supported INFO >>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>> >>>>> response when it receives an INFO request which it >>>>>> doesn't want to process anymore? >>>>>> >>>>>> To me, INFO packages should be like the Dialog's route >> set: learn >>>>>> the >>>>>> >>>>> supported set from the initial INVITE and 1xx-2xx >>>>>> responses, after that don't change it anymore >>>>>> >>>>> I think Adam made the same comment in the SIPCORE session. >>>>> >>>>> Personally I think there could be cases where one wants to add a >>>>> package during a dialog. For example, assume I call you. Then, >>>>> during >>>>> the dialog we decide to start using application X which >> uses an Info >> >>>>> Package, so our phones send Recv-Info:X to each other. >> Application X >> >>>>> may not even be running when we initiate the dialog. >>>>> >>>>> However, if we are going to require the header in a lot >> of messages, >> >>>>> maybe we should remove PRACK from the list of allowed messages. >>>>> Would >>>>> people have problems with that? >>>>> >>>>> But, I would like Paul to comment whether mandating the header in >>>>> every message would actually solve his 3pcc use-case. >>>>> >>>>> >>>>>> PS The usage of 'nil' to denote no supported packages is not >>>>>> consistent >>>>>> >>>>> with conventions used today, e.g. for Supported >>>>>> (suggest to simply use an empty value instead) >>>>>> >>>>> I think there was some WGLC comment(s) asking about the >> same thing. >>>>> Personally I have no problem to use an empty header instead of >> 'nil'. >>>>> However, I want to ensure that nobody objects to such >> change before >>>>> I >>>>> implement it. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> DRAGE, Keith (Keith) wrote: >>>>> >>>>>> This works, but it seems overkill to me. >>>>>> >>>>>> Firstly can I ensure that this does not include REGISTER, which >>>>>> could >>>>>> >>>>> also be understood from the paraphrase of the SIPCORE discussion. >>>>> >>>>>> Secondly can I still have more detail (arrow diagram) on the >>>>>> scenario >>>>>> >>>>> we are trying to solve for 3pcc. I can't see if there is a simple >>>>> solution if the problem is insufficiently clear. >>>>> >>>>>> Keith >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sipcore-bounces@ietf.org >>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>> To: Christer Holmberg >>>>>>> Cc: sipcore@ietf.org >>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>>>>> Recv-Info >>>>>>> >>>>> >>>>>>> header >>>>>>> >>>>>>> That works for me, and it is sufficiently simple that everybody >>>>>>> should be able to implement it correctly. :-) >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> Christer Holmberg wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE >> session we >> >>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>> >>>>>>> re-INVITE >>>>>>> >>>>>>>> responses. >>>>>>>> >>>>>>>> The outcome of the discussion was that EVERY SIP >> messages where >>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>> >>>>>>> the set of >>>>>>> >>>>>>>> Info Packages has changed or not. >>>>>>>> >>>>>>>> Based on the -03pre version of the draft the following >>>>>>>> >>>>>>> messages would >>>>>>> >>>>>>>> be >>>>>>>> affected: >>>>>>>> >>>>>>>> INVITE + 18x + 200 >>>>>>>> Re-INVITE + 18x + 200 >>>>>>>> ACK >>>>>>>> UPDATE + 200 >>>>>>>> PRACK + 200 >>>>>>>> >>>>>>>> That is a change from previous versions of the draft, which >>>>>>>> >>>>>>> says that >>>>>>> >>>>>>>> the Recv-Info header only needs to be inserted if the >> set of Info >> >>>>>>>> Packages changes. >>>>>>>> >>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>> >>>>>>> implement >>>>>>> >>>>>>>> the change in the next version of the draft. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From john.elwell@siemens-enterprise.com Thu Nov 12 17:59:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8083A698F for ; Thu, 12 Nov 2009 17:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WeBx4RekNE6 for ; Thu, 12 Nov 2009 17:59:50 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 617BF3A683D for ; Thu, 12 Nov 2009 17:59:49 -0800 (PST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id nAD1xmBd016302; Fri, 13 Nov 2009 02:59:48 +0100 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id nAD1xm9H000600; Fri, 13 Nov 2009 02:59:48 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.110]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Fri, 13 Nov 2009 02:59:47 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Fri, 13 Nov 2009 02:59:42 +0100 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: Acpj9VIe4uDhHMKXQ62mD72506QY7wACdtdQ Message-ID: <7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net> References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> <4AFCA34E.20200@cisco.com> In-Reply-To: <4AFCA34E.20200@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jeroen van Bemmel , "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:59:51 -0000 Perhaps what I should have said is that mandating Recv-Info in all request = types for which it is defined (e.g., INVITE, ACK, UPDATE, PRACK) and their = 2xx responses should be sufficient to permit a B2BUA to behave appropriatel= y. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 13 November 2009 00:08 > To: Elwell, John > Cc: Christer Holmberg; sipcore@ietf.org; Jeroen van Bemmel > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > Recv-Info header >=20 >=20 >=20 > Elwell, John wrote: > > I am not sure we need to specify how B (the B2BUA) handles=20 > the Recv-Info header field in 3PCC situations. We just need=20 > to specify use of the header field in such a way that leaves=20 > at least one possible solution for B2BUAs. If this means=20 > B2BUAs need to store the latest Recv-Info contents from each=20 > UA, so that it can forward them when required, that would be=20 > a sufficient solution. The principle of mandating Recv-Info=20 > in each (re-)INVITE request and its 2xx response seems to=20 > permit a B2BUA to manage things appropriately. >=20 > I think that works for me. > I've lost track - is R-I still ok in UPDATE, ACK, PRACK? >=20 > When a 3pcc controlling is initiating a call from the middle,=20 > it starts=20 > out not knowing anything about what either side can do. So it can't=20 > properly declare R-I in the INVITE. It will learn the capabilities of=20 > each side in the response to the INVITE. It would then like=20 > to reflect=20 > them to the "other side" asap, which means in one of the=20 > above. As long=20 > as it can do that, I think its ok. >=20 > Thanks, > Paul >=20 > > John > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org=20 > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > >> Sent: 11 November 2009 08:53 > >> To: Christer Holmberg; Paul Kyzivat > >> Cc: sipcore@ietf.org; Jeroen van Bemmel > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >> Recv-Info header > >> > >> > >> Hi, > >> > >> Please forget the audit proposal until we decide on=20 > whether we could > >> agree on assuming that B supports Info Packages in order to=20 > >> make sure it > >> works between A and D. That would be even esier - we don't need to > >> mandate Recv-Info in every message, and we don't need to define the > >> audit :) > >> > >> Regards, > >> > >> Christer > >> > >> =20 > >> > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Christer Holmberg > >> Sent: 11. marraskuuta 2009 11:35 > >> To: Paul Kyzivat > >> Cc: sipcore@ietf.org; Jeroen van Bemmel > >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to=20 > insert Recv-Info > >> header > >> > >> > >> Hi,=20 > >> > >>>> Thanks for the description! > >>>> > >>>> Now, assuming that B2BUA B does NOT support I-P (if B=20 > does support=20 > >>>> I-P, there should be no issue), it would not insert=20 > Recv-Info (not=20 > >>>> even an empty header) in the initial INVITE requests sent=20 > >> to A and C. > >>>> In addition, B would most likely not insert Recv-Info in=20 > >> the re-INVITE > >> > >>>> request to D. > >>>> > >>>> So, mandating Recv-Info in every message would not solve=20 > the issue. > >>> If Recv-Info is mandated in every message, then doesn't the=20 > >> absence of > >> Recv-Info mean that it doesn't support Info=20 > >>> packages at all, at least momentarily? (Until it sends a R-I.) > >> Exactly, so if B doesn't support Info Packages then A, C and=20 > >> D will all > >> think that the other entity won't support Info-Packages, so=20 > >> that doesn't > >> solve the issue either. > >> > >> But, one alternative to solve the case when B does support=20 > I-P (or, at > >> least is configured to insert Recv-Info) would be de=20 > define a specific > >> "audit" value for Recv-Info, which means "Please send your=20 > list of I-P > >> packages even if it hasn't changed". > >> > >> Then, when B sends the re-INVITE to D it would include=20 > something like > >> Recv-Info:* (or whatever value we use for audit). > >> > >> "*" could also be used with other listed packages, so when=20 > B sends D's > >> list to A it can ensure that A sends its list back so that=20 > D will get > >> it. > >> > >> In my opinion that is far more nicer than mandating=20 > Revc-Info in every > >> message, and it actually solves some of the 3pcc use-cases :) > >> > >> Would people be ok with that?=20 > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 10. marraskuuta 2009 23:18 > >>> To: Jeroen van Bemmel > >>> Cc: Christer Holmberg; sipcore@ietf.org > >>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >> Recv-Info=20 > >>> header > >>> > >>> The most straightforward 3pcc case to explain is: > >>> > >>> A --------- B ---------- C > >>> | > >>> |----------- D > >>> > >>> Initially, the 3pcc B2BUA B establishes coordinated=20 > dialogs A-B and > >> B-C. > >>> Later B decides to transfer the call from C to D. So it=20 > >> establishes a=20 > >>> new dialog B-D and reinvites A to splice it in. I'm hand=20 > >> waving over=20 > >>> the details, because there are many options and they don't matter > >> here. > >>> The key point is that A was, for all intents and purposes,=20 > >> initially=20 > >>> connected to C, and after a reinvite finds itself connected to D. > >>> > >>> Now D may not be able to support the same Info Packages=20 > that C did. > >>> To make things work, the R-I values from D must be=20 > >> presented to A, and > >> > >>> it needs to honor them. > >>> > >>> Conversely, D needs to be informed of the info packages that A is=20 > >>> willing to receive. While it is possible that B could have=20 > >> remembered=20 > >>> them, and could thus insert them in the initial invite to D, its=20 > >>> better if B doesn't have to get involved in that. > >>> > >>> Many new features run into essentially the same problem=20 > >> with 3pcc. You > >> > >>> just cannot assume state negotiated e2e will survive a reinvite. > >>> > >>> And this is quite a bit different than the stability of=20 > route sets,=20 > >>> because the route set distinct in each dialog. It doesn't go e2e=20 > >>> through the B2BUA. > >>> > >>> Thanks, > >>> Paul > >>> > >>> Jeroen van Bemmel wrote: > >>>> Christer, > >>>> > >>>> Given the registration requirement (i.e. there needs to be=20 > >> some sort=20 > >>>> of > >>>> spec) the set of INFO packages will be limited. UAs can=20 > >> easily list=20 > >>>> those packages they support up front. Therefore the=20 > "fully dynamic" > >>>> case you sketch below seems unlikely to me. > >>>> > >>>> The only case I could imagine would be in case of long running=20 > >>>> dialogs, where the software of one of the peers gets upgraded=20 > >>>> mid-dialog to support some new INFO package. However, also=20 > >> that seems > >> > >>>> highly unlikely to me. > >>>> > >>>> To me, we should keep it simple - "learn INFO packages=20 > >> whenever you=20 > >>>> learn the Route set for a Dialog" should be simple enough for=20 > >>>> developers to get right > >>>> > >>>> Regards, > >>>> Jeroen > >>>> > >>>> Christer Holmberg wrote: > >>>>> Hi, > >>>>> =20 > >>>>>> I also think it's overkill. Furthermore, I don't see a=20 > >> real world=20 > >>>>>> use > >>>>>> =20 > >>>>> case for changing the set of supported INFO > >>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 > >>>>>> =20 > >>>>> response when it receives an INFO request which it > >>>>>> doesn't want to process anymore? > >>>>>> > >>>>>> To me, INFO packages should be like the Dialog's route=20 > >> set: learn=20 > >>>>>> the > >>>>>> =20 > >>>>> supported set from the initial INVITE and 1xx-2xx > >>>>>> responses, after that don't change it anymore > >>>>>> =20 > >>>>> I think Adam made the same comment in the SIPCORE session. > >>>>> > >>>>> Personally I think there could be cases where one wants=20 > to add a=20 > >>>>> package during a dialog. For example, assume I call you. Then,=20 > >>>>> during > >>>>> the dialog we decide to start using application X which=20 > >> uses an Info > >> > >>>>> Package, so our phones send Recv-Info:X to each other.=20 > >> Application X > >> > >>>>> may not even be running when we initiate the dialog. > >>>>> > >>>>> However, if we are going to require the header in a lot=20 > >> of messages, > >> > >>>>> maybe we should remove PRACK from the list of allowed messages.=20 > >>>>> Would > >>>>> people have problems with that? > >>>>> > >>>>> But, I would like Paul to comment whether mandating the=20 > header in=20 > >>>>> every message would actually solve his 3pcc use-case. > >>>>> > >>>>> =20 > >>>>>> PS The usage of 'nil' to denote no supported packages is not=20 > >>>>>> consistent > >>>>>> =20 > >>>>> with conventions used today, e.g. for Supported > >>>>>> (suggest to simply use an empty value instead) > >>>>>> =20 > >>>>> I think there was some WGLC comment(s) asking about the=20 > >> same thing. > >>>>> Personally I have no problem to use an empty header instead of > >> 'nil'. > >>>>> However, I want to ensure that nobody objects to such=20 > >> change before=20 > >>>>> I > >>>>> implement it. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> DRAGE, Keith (Keith) wrote: > >>>>> =20 > >>>>>> This works, but it seems overkill to me. > >>>>>> > >>>>>> Firstly can I ensure that this does not include=20 > REGISTER, which=20 > >>>>>> could > >>>>>> =20 > >>>>> also be understood from the paraphrase of the SIPCORE=20 > discussion. > >>>>> =20 > >>>>>> Secondly can I still have more detail (arrow diagram) on the=20 > >>>>>> scenario > >>>>>> =20 > >>>>> we are trying to solve for 3pcc. I can't see if there=20 > is a simple=20 > >>>>> solution if the problem is insufficiently clear. > >>>>> =20 > >>>>>> Keith > >>>>>> > >>>>>> =20 > >>>>>>> -----Original Message----- > >>>>>>> From: sipcore-bounces@ietf.org > >>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>>>>> Sent: Monday, November 09, 2009 4:15 AM > >>>>>>> To: Christer Holmberg > >>>>>>> Cc: sipcore@ietf.org > >>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 > >>>>>>> Recv-Info > >>>>>>> =20 > >>>>> =20 > >>>>>>> header > >>>>>>> > >>>>>>> That works for me, and it is sufficiently simple that=20 > everybody=20 > >>>>>>> should be able to implement it correctly. :-) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>> Christer Holmberg wrote: > >>>>>>> =20 > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE=20 > >> session we > >> > >>>>>>>> discussed whether we should mandate to include Recv-Info in > >>>>>>>> =20 > >>>>>>> re-INVITE > >>>>>>> =20 > >>>>>>>> responses. > >>>>>>>> > >>>>>>>> The outcome of the discussion was that EVERY SIP=20 > >> messages where=20 > >>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if > >>>>>>>> =20 > >>>>>>> the set of > >>>>>>> =20 > >>>>>>>> Info Packages has changed or not. > >>>>>>>> > >>>>>>>> Based on the -03pre version of the draft the following > >>>>>>>> =20 > >>>>>>> messages would > >>>>>>> =20 > >>>>>>>> be > >>>>>>>> affected: > >>>>>>>> > >>>>>>>> INVITE + 18x + 200 > >>>>>>>> Re-INVITE + 18x + 200 > >>>>>>>> ACK > >>>>>>>> UPDATE + 200 > >>>>>>>> PRACK + 200 > >>>>>>>> > >>>>>>>> That is a change from previous versions of the draft, which > >>>>>>>> =20 > >>>>>>> says that > >>>>>>> =20 > >>>>>>>> the Recv-Info header only needs to be inserted if the=20 > >> set of Info > >> > >>>>>>>> Packages changes. > >>>>>>>> > >>>>>>>> So, unless people have issues with that, my intention is to > >>>>>>>> =20 > >>>>>>> implement > >>>>>>> =20 > >>>>>>>> the change in the next version of the draft. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Christer > >>>>>>>> > >>>>>>>> =20 > >>>>>>> _______________________________________________ > >>>>>>> sipcore mailing list > >>>>>>> sipcore@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>>> > >>>>>>> =20 > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> sipcore@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>>> > >>>>>> =20 > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>> =20 > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > = From drage@alcatel-lucent.com Thu Nov 12 23:14:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C8C3A688E for ; Thu, 12 Nov 2009 23:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooP1sOHXRl98 for ; Thu, 12 Nov 2009 23:14:50 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 363E63A686C for ; Thu, 12 Nov 2009 23:14:49 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAD7FGM7006105 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Nov 2009 08:15:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 13 Nov 2009 08:15:16 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Jeroen van Bemmel Date: Fri, 13 Nov 2009 08:15:15 +0100 Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event Thread-Index: Acpjl5akDmMV393lSQGha/F/Qd+v+gAV212QAAXkb3A= Message-ID: References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com> <4AFC05EC.9050800@zonnet.nl> <7402509E63C5A145A6095D46C179A5B70725DA3C6D@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA3C6D@DEMCHP99E35MSX.ww902.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 07:14:51 -0000 To add to this, there could well be many solutions that use an info-package= as only part of the solution. We would want the feature tag on the whole s= olution, not just on the info-package. Therefore I don't see much point in having a standardised format of media f= eature tags. regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, November 12, 2009 11:23 PM > To: Jeroen van Bemmel; DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Caller prefs / callee caps for INFO Event >=20 > We should not add this new functionality following WGLC.=20 > Let's just finish what we have. >=20 > John=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jeroen van Bemmel > > Sent: 12 November 2009 12:56 > > To: DRAGE, Keith (Keith) > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event > >=20 > > I mean something similar to > >=20 > > events=3D"!presence,message-summary" (RFC3840) > >=20 > > so maybe > >=20 > > +sip.info-packages=3D"foo,!bar" > >=20 > > The point would be to standardize the tag name that is used.=20 > > This will enable a UA to announce the Info packages it supports in=20 > > REGISTER, and enables routing based on that information. > > The use case for this is the same as for event packages,=20 > it's mostly=20 > > for sake of completeness / consistency > >=20 > > I don't see why it would hurt to add this item to the draft, seems=20 > > overkill to write a separate RFC just for this > >=20 > > Regards, > > Jeroen > >=20 > >=20 > >=20 > > DRAGE, Keith (Keith) wrote: > > > I assume you mean the extension in general, rather than > > specific Info packages.=20 > > > > > > I could imagine that one might define a feature tag in > > parallel with a specific Info package. > > > > > > That of course is outside the scope of > > draft-ietf-sipcore-info-event, but it is a reason why we=20 > don't need to=20 > > put Recv-Info into the REGISTER method. > > > > > > regards > > > > > > Keith > > > > > > =20 > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: Wednesday, November 11, 2009 2:19 PM > > >> To: Jeroen van Bemmel > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event > > >> > > >> Can anyone imagine a case where you would choose one=20 > potential UAS=20 > > >> over another based on support for Info Packages? > > >> > > >> Thanks, > > >> Paul > > >> > > >> Jeroen van Bemmel wrote: > > >> =20 > > >>> Has it been considered to extend RFC3840/RFC3841 with a > > >>> =20 > > >> parameter for > > >> =20 > > >>> INFO Packages? > > >>> > > >>> Regards, > > >>> Jeroen > > >>> _______________________________________________ > > >>> sipcore mailing list > > >>> sipcore@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sipcore > > >>> > > >>> =20 > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > >> =20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From pkyzivat@cisco.com Fri Nov 13 05:52:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B73328C0DD for ; Fri, 13 Nov 2009 05:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQgs53C6P9z6 for ; Fri, 13 Nov 2009 05:52:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8660E3A687B for ; Fri, 13 Nov 2009 05:52:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA70/EpAZnwN/2dsb2JhbAC9E5gwhDwE X-IronPort-AV: E=Sophos;i="4.44,737,1249257600"; d="scan'208";a="67948328" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2009 13:53:24 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nADDrOHZ010892; Fri, 13 Nov 2009 13:53:24 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.3959); Fri, 13 Nov 2009 08:53:24 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 08:53:24 -0500 Message-ID: <4AFD64D2.7070605@cisco.com> Date: Fri, 13 Nov 2009 08:53:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> <4AFCA34E.20200@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2009 13:53:24.0126 (UTC) FILETIME=[AAF85BE0:01CA6468] Cc: Jeroen van Bemmel , "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 13:52:57 -0000 Elwell, John wrote: > Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE, ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a B2BUA to behave appropriately. Mandating is sufficient, but probably more than necessary. Christer has been complaining about mandating. Its probably sufficient to say that each *end* MUST *send* it at least once in each INVITE "cycle". Here I mean The INVITE request and the associated, provisional and final responses, PRACK and responses, UPDATE and response within the INVITE, and ACK. And perhaps in each "stand-alone" UPDATE transaction (outside of INVITE) as well. Its an open question in my mind whether its worth the complexity of that definition, vs. just mandating it in all places, to avoid sending it so often. Thanks, Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 13 November 2009 00:08 >> To: Elwell, John >> Cc: Christer Holmberg; sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >> Recv-Info header >> >> >> >> Elwell, John wrote: >>> I am not sure we need to specify how B (the B2BUA) handles >> the Recv-Info header field in 3PCC situations. We just need >> to specify use of the header field in such a way that leaves >> at least one possible solution for B2BUAs. If this means >> B2BUAs need to store the latest Recv-Info contents from each >> UA, so that it can forward them when required, that would be >> a sufficient solution. The principle of mandating Recv-Info >> in each (re-)INVITE request and its 2xx response seems to >> permit a B2BUA to manage things appropriately. >> >> I think that works for me. >> I've lost track - is R-I still ok in UPDATE, ACK, PRACK? >> >> When a 3pcc controlling is initiating a call from the middle, >> it starts >> out not knowing anything about what either side can do. So it can't >> properly declare R-I in the INVITE. It will learn the capabilities of >> each side in the response to the INVITE. It would then like >> to reflect >> them to the "other side" asap, which means in one of the >> above. As long >> as it can do that, I think its ok. >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 11 November 2009 08:53 >>>> To: Christer Holmberg; Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info header >>>> >>>> >>>> Hi, >>>> >>>> Please forget the audit proposal until we decide on >> whether we could >>>> agree on assuming that B supports Info Packages in order to >>>> make sure it >>>> works between A and D. That would be even esier - we don't need to >>>> mandate Recv-Info in every message, and we don't need to define the >>>> audit :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 11. marraskuuta 2009 11:35 >>>> To: Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to >> insert Recv-Info >>>> header >>>> >>>> >>>> Hi, >>>> >>>>>> Thanks for the description! >>>>>> >>>>>> Now, assuming that B2BUA B does NOT support I-P (if B >> does support >>>>>> I-P, there should be no issue), it would not insert >> Recv-Info (not >>>>>> even an empty header) in the initial INVITE requests sent >>>> to A and C. >>>>>> In addition, B would most likely not insert Recv-Info in >>>> the re-INVITE >>>> >>>>>> request to D. >>>>>> >>>>>> So, mandating Recv-Info in every message would not solve >> the issue. >>>>> If Recv-Info is mandated in every message, then doesn't the >>>> absence of >>>> Recv-Info mean that it doesn't support Info >>>>> packages at all, at least momentarily? (Until it sends a R-I.) >>>> Exactly, so if B doesn't support Info Packages then A, C and >>>> D will all >>>> think that the other entity won't support Info-Packages, so >>>> that doesn't >>>> solve the issue either. >>>> >>>> But, one alternative to solve the case when B does support >> I-P (or, at >>>> least is configured to insert Recv-Info) would be de >> define a specific >>>> "audit" value for Recv-Info, which means "Please send your >> list of I-P >>>> packages even if it hasn't changed". >>>> >>>> Then, when B sends the re-INVITE to D it would include >> something like >>>> Recv-Info:* (or whatever value we use for audit). >>>> >>>> "*" could also be used with other listed packages, so when >> B sends D's >>>> list to A it can ensure that A sends its list back so that >> D will get >>>> it. >>>> >>>> In my opinion that is far more nicer than mandating >> Revc-Info in every >>>> message, and it actually solves some of the 3pcc use-cases :) >>>> >>>> Would people be ok with that? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 10. marraskuuta 2009 23:18 >>>>> To: Jeroen van Bemmel >>>>> Cc: Christer Holmberg; sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info >>>>> header >>>>> >>>>> The most straightforward 3pcc case to explain is: >>>>> >>>>> A --------- B ---------- C >>>>> | >>>>> |----------- D >>>>> >>>>> Initially, the 3pcc B2BUA B establishes coordinated >> dialogs A-B and >>>> B-C. >>>>> Later B decides to transfer the call from C to D. So it >>>> establishes a >>>>> new dialog B-D and reinvites A to splice it in. I'm hand >>>> waving over >>>>> the details, because there are many options and they don't matter >>>> here. >>>>> The key point is that A was, for all intents and purposes, >>>> initially >>>>> connected to C, and after a reinvite finds itself connected to D. >>>>> >>>>> Now D may not be able to support the same Info Packages >> that C did. >>>>> To make things work, the R-I values from D must be >>>> presented to A, and >>>> >>>>> it needs to honor them. >>>>> >>>>> Conversely, D needs to be informed of the info packages that A is >>>>> willing to receive. While it is possible that B could have >>>> remembered >>>>> them, and could thus insert them in the initial invite to D, its >>>>> better if B doesn't have to get involved in that. >>>>> >>>>> Many new features run into essentially the same problem >>>> with 3pcc. You >>>> >>>>> just cannot assume state negotiated e2e will survive a reinvite. >>>>> >>>>> And this is quite a bit different than the stability of >> route sets, >>>>> because the route set distinct in each dialog. It doesn't go e2e >>>>> through the B2BUA. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Christer, >>>>>> >>>>>> Given the registration requirement (i.e. there needs to be >>>> some sort >>>>>> of >>>>>> spec) the set of INFO packages will be limited. UAs can >>>> easily list >>>>>> those packages they support up front. Therefore the >> "fully dynamic" >>>>>> case you sketch below seems unlikely to me. >>>>>> >>>>>> The only case I could imagine would be in case of long running >>>>>> dialogs, where the software of one of the peers gets upgraded >>>>>> mid-dialog to support some new INFO package. However, also >>>> that seems >>>> >>>>>> highly unlikely to me. >>>>>> >>>>>> To me, we should keep it simple - "learn INFO packages >>>> whenever you >>>>>> learn the Route set for a Dialog" should be simple enough for >>>>>> developers to get right >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> I also think it's overkill. Furthermore, I don't see a >>>> real world >>>>>>>> use >>>>>>>> >>>>>>> case for changing the set of supported INFO >>>>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>>>> >>>>>>> response when it receives an INFO request which it >>>>>>>> doesn't want to process anymore? >>>>>>>> >>>>>>>> To me, INFO packages should be like the Dialog's route >>>> set: learn >>>>>>>> the >>>>>>>> >>>>>>> supported set from the initial INVITE and 1xx-2xx >>>>>>>> responses, after that don't change it anymore >>>>>>>> >>>>>>> I think Adam made the same comment in the SIPCORE session. >>>>>>> >>>>>>> Personally I think there could be cases where one wants >> to add a >>>>>>> package during a dialog. For example, assume I call you. Then, >>>>>>> during >>>>>>> the dialog we decide to start using application X which >>>> uses an Info >>>> >>>>>>> Package, so our phones send Recv-Info:X to each other. >>>> Application X >>>> >>>>>>> may not even be running when we initiate the dialog. >>>>>>> >>>>>>> However, if we are going to require the header in a lot >>>> of messages, >>>> >>>>>>> maybe we should remove PRACK from the list of allowed messages. >>>>>>> Would >>>>>>> people have problems with that? >>>>>>> >>>>>>> But, I would like Paul to comment whether mandating the >> header in >>>>>>> every message would actually solve his 3pcc use-case. >>>>>>> >>>>>>> >>>>>>>> PS The usage of 'nil' to denote no supported packages is not >>>>>>>> consistent >>>>>>>> >>>>>>> with conventions used today, e.g. for Supported >>>>>>>> (suggest to simply use an empty value instead) >>>>>>>> >>>>>>> I think there was some WGLC comment(s) asking about the >>>> same thing. >>>>>>> Personally I have no problem to use an empty header instead of >>>> 'nil'. >>>>>>> However, I want to ensure that nobody objects to such >>>> change before >>>>>>> I >>>>>>> implement it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> DRAGE, Keith (Keith) wrote: >>>>>>> >>>>>>>> This works, but it seems overkill to me. >>>>>>>> >>>>>>>> Firstly can I ensure that this does not include >> REGISTER, which >>>>>>>> could >>>>>>>> >>>>>>> also be understood from the paraphrase of the SIPCORE >> discussion. >>>>>>> >>>>>>>> Secondly can I still have more detail (arrow diagram) on the >>>>>>>> scenario >>>>>>>> >>>>>>> we are trying to solve for 3pcc. I can't see if there >> is a simple >>>>>>> solution if the problem is insufficiently clear. >>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: sipcore-bounces@ietf.org >>>>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>>>> To: Christer Holmberg >>>>>>>>> Cc: sipcore@ietf.org >>>>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>>>>>>> Recv-Info >>>>>>>>> >>>>>>> >>>>>>>>> header >>>>>>>>> >>>>>>>>> That works for me, and it is sufficiently simple that >> everybody >>>>>>>>> should be able to implement it correctly. :-) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Christer Holmberg wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE >>>> session we >>>> >>>>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>>>> >>>>>>>>> re-INVITE >>>>>>>>> >>>>>>>>>> responses. >>>>>>>>>> >>>>>>>>>> The outcome of the discussion was that EVERY SIP >>>> messages where >>>>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>>>> >>>>>>>>> the set of >>>>>>>>> >>>>>>>>>> Info Packages has changed or not. >>>>>>>>>> >>>>>>>>>> Based on the -03pre version of the draft the following >>>>>>>>>> >>>>>>>>> messages would >>>>>>>>> >>>>>>>>>> be >>>>>>>>>> affected: >>>>>>>>>> >>>>>>>>>> INVITE + 18x + 200 >>>>>>>>>> Re-INVITE + 18x + 200 >>>>>>>>>> ACK >>>>>>>>>> UPDATE + 200 >>>>>>>>>> PRACK + 200 >>>>>>>>>> >>>>>>>>>> That is a change from previous versions of the draft, which >>>>>>>>>> >>>>>>>>> says that >>>>>>>>> >>>>>>>>>> the Recv-Info header only needs to be inserted if the >>>> set of Info >>>> >>>>>>>>>> Packages changes. >>>>>>>>>> >>>>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>>>> >>>>>>>>> implement >>>>>>>>> >>>>>>>>>> the change in the next version of the draft. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sipcore mailing list >>>>>>>>> sipcore@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sipcore mailing list >>>>>>>> sipcore@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> From christer.holmberg@ericsson.com Fri Nov 13 07:25:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FE93A6A0A for ; Fri, 13 Nov 2009 07:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAwtnY2QJU+0 for ; Fri, 13 Nov 2009 07:25:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 667FA3A685C for ; Fri, 13 Nov 2009 07:25:42 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-85-4afd7a928ae5 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EF.EE.24094.29A7DFA4; Fri, 13 Nov 2009 16:26:10 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 16:26:10 +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: Fri, 13 Nov 2009 16:26:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Caller prefs / callee caps for INFO Event thread-index: Acpjl5akDmMV393lSQGha/F/Qd+v+gAV212QAAXkb3AAG6NqEA== References: <4AFAC2F2.2090001@zonnet.nl> <4AFAC7ED.3070409@cisco.com><4AFC05EC.9050800@zonnet.nl><7402509E63C5A145A6095D46C179A5B70725DA3C6D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Elwell, John" , "Jeroen van Bemmel" X-OriginalArrivalTime: 13 Nov 2009 15:26:10.0308 (UTC) FILETIME=[A0AC5440:01CA6475] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 15:25:43 -0000 Hi,=20 >To add to this, there could well be many solutions that use an info-package as only part of the solution. We would want=20 >the feature tag on the whole solution, not just on the info-package. A service identifier, you mean? ;) >Therefore I don't see much point in having a standardised format of media feature tags. One does not preclude the other.=20 We have standardized feature tags which can be used to indicate individual SIP methods, individual SIP exensions etc, so I see no reason why we couldn't have to possibility to indicate individual Info Packages. And, if a specific application requires an Info Package, the feature tag could identify the who application.=20 Regards, Christer > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, November 12, 2009 11:23 PM > To: Jeroen van Bemmel; DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Caller prefs / callee caps for INFO Event >=20 > We should not add this new functionality following WGLC.=20 > Let's just finish what we have. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jeroen van Bemmel > > Sent: 12 November 2009 12:56 > > To: DRAGE, Keith (Keith) > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event > >=20 > > I mean something similar to > >=20 > > events=3D"!presence,message-summary" (RFC3840) > >=20 > > so maybe > >=20 > > +sip.info-packages=3D"foo,!bar" > >=20 > > The point would be to standardize the tag name that is used.=20 > > This will enable a UA to announce the Info packages it supports in=20 > > REGISTER, and enables routing based on that information. > > The use case for this is the same as for event packages, > it's mostly > > for sake of completeness / consistency > >=20 > > I don't see why it would hurt to add this item to the draft, seems=20 > > overkill to write a separate RFC just for this > >=20 > > Regards, > > Jeroen > >=20 > >=20 > >=20 > > DRAGE, Keith (Keith) wrote: > > > I assume you mean the extension in general, rather than > > specific Info packages.=20 > > > > > > I could imagine that one might define a feature tag in > > parallel with a specific Info package. > > > > > > That of course is outside the scope of > > draft-ietf-sipcore-info-event, but it is a reason why we > don't need to > > put Recv-Info into the REGISTER method. > > > > > > regards > > > > > > Keith > > > > > > =20 > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: Wednesday, November 11, 2009 2:19 PM > > >> To: Jeroen van Bemmel > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] Caller prefs / callee caps for INFO Event > > >> > > >> Can anyone imagine a case where you would choose one > potential UAS > > >> over another based on support for Info Packages? > > >> > > >> Thanks, > > >> Paul > > >> > > >> Jeroen van Bemmel wrote: > > >> =20 > > >>> Has it been considered to extend RFC3840/RFC3841 with a > > >>> =20 > > >> parameter for > > >> =20 > > >>> INFO Packages? > > >>> > > >>> Regards, > > >>> Jeroen > > >>> _______________________________________________ > > >>> sipcore mailing list > > >>> sipcore@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sipcore > > >>> > > >>> =20 > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > >> =20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Fri Nov 13 07:42:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88CDE3A695A for ; Fri, 13 Nov 2009 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NUz5vI68Hh9 for ; Fri, 13 Nov 2009 07:42:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 36A4F3A6933 for ; Fri, 13 Nov 2009 07:42:27 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-97-4afd7e7f9083 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 68.FF.24094.F7E7DFA4; Fri, 13 Nov 2009 16:42:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 16:42:51 +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: Fri, 13 Nov 2009 16:42:50 +0100 Message-ID: In-Reply-To: <4AFD64D2.7070605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCg References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> <4AFCA34E.20200@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net> <4AFD64D2.7070605@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 13 Nov 2009 15:42:51.0083 (UTC) FILETIME=[F52E79B0:01CA6477] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 15:42:29 -0000 Hi,=20 First, in case you have missed it, I have proposed to remove PRACK from the list of allowed methods. Please indicate if you have a problem with that. Now, to the issue... >>Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE,=20 >>ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a B2BUA to behave appropriately. > >Mandating is sufficient, but probably more than necessary. >Christer has been complaining about mandating. I think there were others (Keith, at least) who didn't like it. >Its probably sufficient to say that each *end* MUST *send* it at least once in each INVITE "cycle". Here I mean The=20 >INVITE request and the associated, provisional and final responses, PRACK and responses, UPDATE and response within the=20 >INVITE, and ACK. And perhaps in each "stand-alone" UPDATE transaction (outside of INVITE) as well. Wouldn't it be enough to say once per INVITE/ACK transaction only? I don't think we would need to mandate it for UPDATE (no matter whether it is "inside" the re-INVITE or not). >Its an open question in my mind whether its worth the complexity of that definition, vs. just mandating it in all places,=20 >to avoid sending it so often. Just because it may be "simple" documentation wise, it does create extra work for parsers, when they have to compare the list, to see whether something has changed. Regards, Christer >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 13 November 2009 00:08 >> To: Elwell, John >> Cc: Christer Holmberg; sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> >> >> Elwell, John wrote: >>> I am not sure we need to specify how B (the B2BUA) handles >> the Recv-Info header field in 3PCC situations. We just need to=20 >> specify use of the header field in such a way that leaves at least=20 >> one possible solution for B2BUAs. If this means B2BUAs need to store=20 >> the latest Recv-Info contents from each UA, so that it can forward=20 >> them when required, that would be a sufficient solution. The=20 >> principle of mandating Recv-Info in each (re-)INVITE request and its=20 >> 2xx response seems to permit a B2BUA to manage things appropriately. >> >> I think that works for me. >> I've lost track - is R-I still ok in UPDATE, ACK, PRACK? >> >> When a 3pcc controlling is initiating a call from the middle, it=20 >> starts out not knowing anything about what either side can do. So it=20 >> can't properly declare R-I in the INVITE. It will learn the=20 >> capabilities of each side in the response to the INVITE. It would=20 >> then like to reflect them to the "other side" asap, which means in=20 >> one of the above. As long as it can do that, I think its ok. >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org=20 >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 11 November 2009 08:53 >>>> To: Christer Holmberg; Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info header >>>> >>>> >>>> Hi, >>>> >>>> Please forget the audit proposal until we decide on=20 >> whether we could >>>> agree on assuming that B supports Info Packages in order to=20 >>>> make sure it >>>> works between A and D. That would be even esier - we don't need to >>>> mandate Recv-Info in every message, and we don't need to define the >>>> audit :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> =20 >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 11. marraskuuta 2009 11:35 >>>> To: Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to=20 >> insert Recv-Info >>>> header >>>> >>>> >>>> Hi,=20 >>>> >>>>>> Thanks for the description! >>>>>> >>>>>> Now, assuming that B2BUA B does NOT support I-P (if B=20 >> does support=20 >>>>>> I-P, there should be no issue), it would not insert=20 >> Recv-Info (not=20 >>>>>> even an empty header) in the initial INVITE requests sent=20 >>>> to A and C. >>>>>> In addition, B would most likely not insert Recv-Info in=20 >>>> the re-INVITE >>>> >>>>>> request to D. >>>>>> >>>>>> So, mandating Recv-Info in every message would not solve=20 >> the issue. >>>>> If Recv-Info is mandated in every message, then doesn't the=20 >>>> absence of >>>> Recv-Info mean that it doesn't support Info=20 >>>>> packages at all, at least momentarily? (Until it sends a R-I.) >>>> Exactly, so if B doesn't support Info Packages then A, C and=20 >>>> D will all >>>> think that the other entity won't support Info-Packages, so=20 >>>> that doesn't >>>> solve the issue either. >>>> >>>> But, one alternative to solve the case when B does support=20 >> I-P (or, at >>>> least is configured to insert Recv-Info) would be de=20 >> define a specific >>>> "audit" value for Recv-Info, which means "Please send your=20 >> list of I-P >>>> packages even if it hasn't changed". >>>> >>>> Then, when B sends the re-INVITE to D it would include=20 >> something like >>>> Recv-Info:* (or whatever value we use for audit). >>>> >>>> "*" could also be used with other listed packages, so when=20 >> B sends D's >>>> list to A it can ensure that A sends its list back so that=20 >> D will get >>>> it. >>>> >>>> In my opinion that is far more nicer than mandating=20 >> Revc-Info in every >>>> message, and it actually solves some of the 3pcc use-cases :) >>>> >>>> Would people be ok with that?=20 >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 10. marraskuuta 2009 23:18 >>>>> To: Jeroen van Bemmel >>>>> Cc: Christer Holmberg; sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info=20 >>>>> header >>>>> >>>>> The most straightforward 3pcc case to explain is: >>>>> >>>>> A --------- B ---------- C >>>>> | >>>>> |----------- D >>>>> >>>>> Initially, the 3pcc B2BUA B establishes coordinated=20 >> dialogs A-B and >>>> B-C. >>>>> Later B decides to transfer the call from C to D. So it=20 >>>> establishes a=20 >>>>> new dialog B-D and reinvites A to splice it in. I'm hand=20 >>>> waving over=20 >>>>> the details, because there are many options and they don't matter >>>> here. >>>>> The key point is that A was, for all intents and purposes,=20 >>>> initially=20 >>>>> connected to C, and after a reinvite finds itself connected to D. >>>>> >>>>> Now D may not be able to support the same Info Packages=20 >> that C did. >>>>> To make things work, the R-I values from D must be=20 >>>> presented to A, and >>>> >>>>> it needs to honor them. >>>>> >>>>> Conversely, D needs to be informed of the info packages that A is=20 >>>>> willing to receive. While it is possible that B could have=20 >>>> remembered=20 >>>>> them, and could thus insert them in the initial invite to D, its=20 >>>>> better if B doesn't have to get involved in that. >>>>> >>>>> Many new features run into essentially the same problem=20 >>>> with 3pcc. You >>>> >>>>> just cannot assume state negotiated e2e will survive a reinvite. >>>>> >>>>> And this is quite a bit different than the stability of=20 >> route sets,=20 >>>>> because the route set distinct in each dialog. It doesn't go e2e=20 >>>>> through the B2BUA. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Christer, >>>>>> >>>>>> Given the registration requirement (i.e. there needs to be=20 >>>> some sort=20 >>>>>> of >>>>>> spec) the set of INFO packages will be limited. UAs can=20 >>>> easily list=20 >>>>>> those packages they support up front. Therefore the=20 >> "fully dynamic" >>>>>> case you sketch below seems unlikely to me. >>>>>> >>>>>> The only case I could imagine would be in case of long running=20 >>>>>> dialogs, where the software of one of the peers gets upgraded=20 >>>>>> mid-dialog to support some new INFO package. However, also=20 >>>> that seems >>>> >>>>>> highly unlikely to me. >>>>>> >>>>>> To me, we should keep it simple - "learn INFO packages=20 >>>> whenever you=20 >>>>>> learn the Route set for a Dialog" should be simple enough for=20 >>>>>> developers to get right >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> =20 >>>>>>>> I also think it's overkill. Furthermore, I don't see a=20 >>>> real world=20 >>>>>>>> use >>>>>>>> =20 >>>>>>> case for changing the set of supported INFO >>>>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>>>> =20 >>>>>>> response when it receives an INFO request which it >>>>>>>> doesn't want to process anymore? >>>>>>>> >>>>>>>> To me, INFO packages should be like the Dialog's route=20 >>>> set: learn=20 >>>>>>>> the >>>>>>>> =20 >>>>>>> supported set from the initial INVITE and 1xx-2xx >>>>>>>> responses, after that don't change it anymore >>>>>>>> =20 >>>>>>> I think Adam made the same comment in the SIPCORE session. >>>>>>> >>>>>>> Personally I think there could be cases where one wants=20 >> to add a=20 >>>>>>> package during a dialog. For example, assume I call you. Then,=20 >>>>>>> during >>>>>>> the dialog we decide to start using application X which=20 >>>> uses an Info >>>> >>>>>>> Package, so our phones send Recv-Info:X to each other.=20 >>>> Application X >>>> >>>>>>> may not even be running when we initiate the dialog. >>>>>>> >>>>>>> However, if we are going to require the header in a lot=20 >>>> of messages, >>>> >>>>>>> maybe we should remove PRACK from the list of allowed messages.=20 >>>>>>> Would >>>>>>> people have problems with that? >>>>>>> >>>>>>> But, I would like Paul to comment whether mandating the=20 >> header in=20 >>>>>>> every message would actually solve his 3pcc use-case. >>>>>>> >>>>>>> =20 >>>>>>>> PS The usage of 'nil' to denote no supported packages is not=20 >>>>>>>> consistent >>>>>>>> =20 >>>>>>> with conventions used today, e.g. for Supported >>>>>>>> (suggest to simply use an empty value instead) >>>>>>>> =20 >>>>>>> I think there was some WGLC comment(s) asking about the=20 >>>> same thing. >>>>>>> Personally I have no problem to use an empty header instead of >>>> 'nil'. >>>>>>> However, I want to ensure that nobody objects to such=20 >>>> change before=20 >>>>>>> I >>>>>>> implement it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> DRAGE, Keith (Keith) wrote: >>>>>>> =20 >>>>>>>> This works, but it seems overkill to me. >>>>>>>> >>>>>>>> Firstly can I ensure that this does not include=20 >> REGISTER, which=20 >>>>>>>> could >>>>>>>> =20 >>>>>>> also be understood from the paraphrase of the SIPCORE=20 >> discussion. >>>>>>> =20 >>>>>>>> Secondly can I still have more detail (arrow diagram) on the=20 >>>>>>>> scenario >>>>>>>> =20 >>>>>>> we are trying to solve for 3pcc. I can't see if there=20 >> is a simple=20 >>>>>>> solution if the problem is insufficiently clear. >>>>>>> =20 >>>>>>>> Keith >>>>>>>> >>>>>>>> =20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: sipcore-bounces@ietf.org >>>>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>>>> To: Christer Holmberg >>>>>>>>> Cc: sipcore@ietf.org >>>>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>>>>>>> Recv-Info >>>>>>>>> =20 >>>>>>> =20 >>>>>>>>> header >>>>>>>>> >>>>>>>>> That works for me, and it is sufficiently simple that=20 >> everybody=20 >>>>>>>>> should be able to implement it correctly. :-) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Christer Holmberg wrote: >>>>>>>>> =20 >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE=20 >>>> session we >>>> >>>>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>>>> =20 >>>>>>>>> re-INVITE >>>>>>>>> =20 >>>>>>>>>> responses. >>>>>>>>>> >>>>>>>>>> The outcome of the discussion was that EVERY SIP=20 >>>> messages where=20 >>>>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>>>> =20 >>>>>>>>> the set of >>>>>>>>> =20 >>>>>>>>>> Info Packages has changed or not. >>>>>>>>>> >>>>>>>>>> Based on the -03pre version of the draft the following >>>>>>>>>> =20 >>>>>>>>> messages would >>>>>>>>> =20 >>>>>>>>>> be >>>>>>>>>> affected: >>>>>>>>>> >>>>>>>>>> INVITE + 18x + 200 >>>>>>>>>> Re-INVITE + 18x + 200 >>>>>>>>>> ACK >>>>>>>>>> UPDATE + 200 >>>>>>>>>> PRACK + 200 >>>>>>>>>> >>>>>>>>>> That is a change from previous versions of the draft, which >>>>>>>>>> =20 >>>>>>>>> says that >>>>>>>>> =20 >>>>>>>>>> the Recv-Info header only needs to be inserted if the=20 >>>> set of Info >>>> >>>>>>>>>> Packages changes. >>>>>>>>>> >>>>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>>>> =20 >>>>>>>>> implement >>>>>>>>> =20 >>>>>>>>>> the change in the next version of the draft. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> sipcore mailing list >>>>>>>>> sipcore@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>> >>>>>>>>> =20 >>>>>>>> _______________________________________________ >>>>>>>> sipcore mailing list >>>>>>>> sipcore@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>> >>>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> =20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> From BPenfield@acmepacket.com Fri Nov 13 08:15:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74EEC28C0E3 for ; Fri, 13 Nov 2009 08:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfhYjlcN13s2 for ; Fri, 13 Nov 2009 08:15:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6A9B33A67D3 for ; Fri, 13 Nov 2009 08:15:05 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 13 Nov 2009 11:15:31 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 13 Nov 2009 11:15:31 -0500 From: Bob Penfield To: Christer Holmberg , Paul Kyzivat , "Elwell, John" Date: Fri, 13 Nov 2009 11:15:29 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rA= Message-ID: <429446390BA91242867940DBE798A06B740334E3E3@mail> References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net> <4AFCA34E.20200@cisco.com> <7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net> <4AFD64D2.7070605@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 Cc: "sipcore@ietf.org" , Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:15:07 -0000 Maybe I missed something, but why is there an issue with Recv-Info in a PRA= CK that would lead us to disallow it? I think it is very useful to be able to update the Recv-Info in a PRACK. We= allow INFO to be sent in an early dialog by the called UA after sending th= e 1xx response. However, if the 1xx is not sent reliable, it is possible th= at the 1xx would be lost and the called UA could receive an INFO for which = it does not have a dialog. Allowing Recv-Info would allow for preventing th= is case by sending "Recv-Info: nil" in the INVITE and then sending an updat= ed Recv-Info in the PRACK. It also would allow the UAC to choose Info-Packages based on the content of= the 1xx response. The selected I-Ps might be different for each UAS in a f= orking scenario. For example, if a UAC included telephone-event (for 2833/4733) in the SDP o= ffer in an INVITE and the SDP answer in the 1xx from the UAS did not includ= e telephone event, but the 1xx included a Recv-Info. The UAC could then inc= lude supported DTMF Info-Packages in a Recv-Info in the PRACK. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Friday, November 13, 2009 10:43 AM To: Paul Kyzivat; Elwell, John Cc: sipcore@ietf.org; Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r Hi, First, in case you have missed it, I have proposed to remove PRACK from the list of allowed methods. Please indicate if you have a problem with that. Now, to the issue... >>Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE, >>ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a B2BUA to behave appropriately. > >Mandating is sufficient, but probably more than necessary. >Christer has been complaining about mandating. I think there were others (Keith, at least) who didn't like it. >Its probably sufficient to say that each *end* MUST *send* it at least once in each INVITE "cycle". Here I mean The >INVITE request and the associated, provisional and final responses, PRACK and responses, UPDATE and response within the >INVITE, and ACK. And perhaps in each "stand-alone" UPDATE transaction (outside of INVITE) as well. Wouldn't it be enough to say once per INVITE/ACK transaction only? I don't think we would need to mandate it for UPDATE (no matter whether it is "inside" the re-INVITE or not). >Its an open question in my mind whether its worth the complexity of that definition, vs. just mandating it in all places, >to avoid sending it so often. Just because it may be "simple" documentation wise, it does create extra work for parsers, when they have to compare the list, to see whether something has changed. Regards, Christer >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 13 November 2009 00:08 >> To: Elwell, John >> Cc: Christer Holmberg; sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> >> >> Elwell, John wrote: >>> I am not sure we need to specify how B (the B2BUA) handles >> the Recv-Info header field in 3PCC situations. We just need to >> specify use of the header field in such a way that leaves at least >> one possible solution for B2BUAs. If this means B2BUAs need to store >> the latest Recv-Info contents from each UA, so that it can forward >> them when required, that would be a sufficient solution. The >> principle of mandating Recv-Info in each (re-)INVITE request and its >> 2xx response seems to permit a B2BUA to manage things appropriately. >> >> I think that works for me. >> I've lost track - is R-I still ok in UPDATE, ACK, PRACK? >> >> When a 3pcc controlling is initiating a call from the middle, it >> starts out not knowing anything about what either side can do. So it >> can't properly declare R-I in the INVITE. It will learn the >> capabilities of each side in the response to the INVITE. It would >> then like to reflect them to the "other side" asap, which means in >> one of the above. As long as it can do that, I think its ok. >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 11 November 2009 08:53 >>>> To: Christer Holmberg; Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info header >>>> >>>> >>>> Hi, >>>> >>>> Please forget the audit proposal until we decide on >> whether we could >>>> agree on assuming that B supports Info Packages in order to >>>> make sure it >>>> works between A and D. That would be even esier - we don't need to >>>> mandate Recv-Info in every message, and we don't need to define the >>>> audit :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 11. marraskuuta 2009 11:35 >>>> To: Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to >> insert Recv-Info >>>> header >>>> >>>> >>>> Hi, >>>> >>>>>> Thanks for the description! >>>>>> >>>>>> Now, assuming that B2BUA B does NOT support I-P (if B >> does support >>>>>> I-P, there should be no issue), it would not insert >> Recv-Info (not >>>>>> even an empty header) in the initial INVITE requests sent >>>> to A and C. >>>>>> In addition, B would most likely not insert Recv-Info in >>>> the re-INVITE >>>> >>>>>> request to D. >>>>>> >>>>>> So, mandating Recv-Info in every message would not solve >> the issue. >>>>> If Recv-Info is mandated in every message, then doesn't the >>>> absence of >>>> Recv-Info mean that it doesn't support Info >>>>> packages at all, at least momentarily? (Until it sends a R-I.) >>>> Exactly, so if B doesn't support Info Packages then A, C and >>>> D will all >>>> think that the other entity won't support Info-Packages, so >>>> that doesn't >>>> solve the issue either. >>>> >>>> But, one alternative to solve the case when B does support >> I-P (or, at >>>> least is configured to insert Recv-Info) would be de >> define a specific >>>> "audit" value for Recv-Info, which means "Please send your >> list of I-P >>>> packages even if it hasn't changed". >>>> >>>> Then, when B sends the re-INVITE to D it would include >> something like >>>> Recv-Info:* (or whatever value we use for audit). >>>> >>>> "*" could also be used with other listed packages, so when >> B sends D's >>>> list to A it can ensure that A sends its list back so that >> D will get >>>> it. >>>> >>>> In my opinion that is far more nicer than mandating >> Revc-Info in every >>>> message, and it actually solves some of the 3pcc use-cases :) >>>> >>>> Would people be ok with that? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 10. marraskuuta 2009 23:18 >>>>> To: Jeroen van Bemmel >>>>> Cc: Christer Holmberg; sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info >>>>> header >>>>> >>>>> The most straightforward 3pcc case to explain is: >>>>> >>>>> A --------- B ---------- C >>>>> | >>>>> |----------- D >>>>> >>>>> Initially, the 3pcc B2BUA B establishes coordinated >> dialogs A-B and >>>> B-C. >>>>> Later B decides to transfer the call from C to D. So it >>>> establishes a >>>>> new dialog B-D and reinvites A to splice it in. I'm hand >>>> waving over >>>>> the details, because there are many options and they don't matter >>>> here. >>>>> The key point is that A was, for all intents and purposes, >>>> initially >>>>> connected to C, and after a reinvite finds itself connected to D. >>>>> >>>>> Now D may not be able to support the same Info Packages >> that C did. >>>>> To make things work, the R-I values from D must be >>>> presented to A, and >>>> >>>>> it needs to honor them. >>>>> >>>>> Conversely, D needs to be informed of the info packages that A is >>>>> willing to receive. While it is possible that B could have >>>> remembered >>>>> them, and could thus insert them in the initial invite to D, its >>>>> better if B doesn't have to get involved in that. >>>>> >>>>> Many new features run into essentially the same problem >>>> with 3pcc. You >>>> >>>>> just cannot assume state negotiated e2e will survive a reinvite. >>>>> >>>>> And this is quite a bit different than the stability of >> route sets, >>>>> because the route set distinct in each dialog. It doesn't go e2e >>>>> through the B2BUA. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Christer, >>>>>> >>>>>> Given the registration requirement (i.e. there needs to be >>>> some sort >>>>>> of >>>>>> spec) the set of INFO packages will be limited. UAs can >>>> easily list >>>>>> those packages they support up front. Therefore the >> "fully dynamic" >>>>>> case you sketch below seems unlikely to me. >>>>>> >>>>>> The only case I could imagine would be in case of long running >>>>>> dialogs, where the software of one of the peers gets upgraded >>>>>> mid-dialog to support some new INFO package. However, also >>>> that seems >>>> >>>>>> highly unlikely to me. >>>>>> >>>>>> To me, we should keep it simple - "learn INFO packages >>>> whenever you >>>>>> learn the Route set for a Dialog" should be simple enough for >>>>>> developers to get right >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> I also think it's overkill. Furthermore, I don't see a >>>> real world >>>>>>>> use >>>>>>>> >>>>>>> case for changing the set of supported INFO >>>>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>>>> >>>>>>> response when it receives an INFO request which it >>>>>>>> doesn't want to process anymore? >>>>>>>> >>>>>>>> To me, INFO packages should be like the Dialog's route >>>> set: learn >>>>>>>> the >>>>>>>> >>>>>>> supported set from the initial INVITE and 1xx-2xx >>>>>>>> responses, after that don't change it anymore >>>>>>>> >>>>>>> I think Adam made the same comment in the SIPCORE session. >>>>>>> >>>>>>> Personally I think there could be cases where one wants >> to add a >>>>>>> package during a dialog. For example, assume I call you. Then, >>>>>>> during >>>>>>> the dialog we decide to start using application X which >>>> uses an Info >>>> >>>>>>> Package, so our phones send Recv-Info:X to each other. >>>> Application X >>>> >>>>>>> may not even be running when we initiate the dialog. >>>>>>> >>>>>>> However, if we are going to require the header in a lot >>>> of messages, >>>> >>>>>>> maybe we should remove PRACK from the list of allowed messages. >>>>>>> Would >>>>>>> people have problems with that? >>>>>>> >>>>>>> But, I would like Paul to comment whether mandating the >> header in >>>>>>> every message would actually solve his 3pcc use-case. >>>>>>> >>>>>>> >>>>>>>> PS The usage of 'nil' to denote no supported packages is not >>>>>>>> consistent >>>>>>>> >>>>>>> with conventions used today, e.g. for Supported >>>>>>>> (suggest to simply use an empty value instead) >>>>>>>> >>>>>>> I think there was some WGLC comment(s) asking about the >>>> same thing. >>>>>>> Personally I have no problem to use an empty header instead of >>>> 'nil'. >>>>>>> However, I want to ensure that nobody objects to such >>>> change before >>>>>>> I >>>>>>> implement it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> DRAGE, Keith (Keith) wrote: >>>>>>> >>>>>>>> This works, but it seems overkill to me. >>>>>>>> >>>>>>>> Firstly can I ensure that this does not include >> REGISTER, which >>>>>>>> could >>>>>>>> >>>>>>> also be understood from the paraphrase of the SIPCORE >> discussion. >>>>>>> >>>>>>>> Secondly can I still have more detail (arrow diagram) on the >>>>>>>> scenario >>>>>>>> >>>>>>> we are trying to solve for 3pcc. I can't see if there >> is a simple >>>>>>> solution if the problem is insufficiently clear. >>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: sipcore-bounces@ietf.org >>>>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>>>> To: Christer Holmberg >>>>>>>>> Cc: sipcore@ietf.org >>>>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>>>>>>> Recv-Info >>>>>>>>> >>>>>>> >>>>>>>>> header >>>>>>>>> >>>>>>>>> That works for me, and it is sufficiently simple that >> everybody >>>>>>>>> should be able to implement it correctly. :-) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Christer Holmberg wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE >>>> session we >>>> >>>>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>>>> >>>>>>>>> re-INVITE >>>>>>>>> >>>>>>>>>> responses. >>>>>>>>>> >>>>>>>>>> The outcome of the discussion was that EVERY SIP >>>> messages where >>>>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>>>> >>>>>>>>> the set of >>>>>>>>> >>>>>>>>>> Info Packages has changed or not. >>>>>>>>>> >>>>>>>>>> Based on the -03pre version of the draft the following >>>>>>>>>> >>>>>>>>> messages would >>>>>>>>> >>>>>>>>>> be >>>>>>>>>> affected: >>>>>>>>>> >>>>>>>>>> INVITE + 18x + 200 >>>>>>>>>> Re-INVITE + 18x + 200 >>>>>>>>>> ACK >>>>>>>>>> UPDATE + 200 >>>>>>>>>> PRACK + 200 >>>>>>>>>> >>>>>>>>>> That is a change from previous versions of the draft, which >>>>>>>>>> >>>>>>>>> says that >>>>>>>>> >>>>>>>>>> the Recv-Info header only needs to be inserted if the >>>> set of Info >>>> >>>>>>>>>> Packages changes. >>>>>>>>>> >>>>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>>>> >>>>>>>>> implement >>>>>>>>> >>>>>>>>>> the change in the next version of the draft. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sipcore mailing list >>>>>>>>> sipcore@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sipcore mailing list >>>>>>>> sipcore@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Fri Nov 13 08:39:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6476B3A6894 for ; Fri, 13 Nov 2009 08:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONQ-bPtQ8GsB for ; Fri, 13 Nov 2009 08:39:33 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DD8A83A67F4 for ; Fri, 13 Nov 2009 08:39:32 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-7d-4afd8be1c57e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BB.1E.04191.1EB8DFA4; Fri, 13 Nov 2009 17:40:01 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 17:40:01 +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: Fri, 13 Nov 2009 17:40:00 +0100 Message-ID: In-Reply-To: <429446390BA91242867940DBE798A06B740334E3E3@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIA== References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com> <429446390BA91242867940DBE798A06B740334E3E3@mail> From: "Christer Holmberg" To: "Bob Penfield" , "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 13 Nov 2009 16:40:01.0408 (UTC) FILETIME=[F1D08800:01CA647F] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:39:35 -0000 Hi,=20 >Maybe I missed something, but why is there an issue with Recv-Info in a PRACK that would lead us to disallow it? It came from the idea of mandating Recv-Info in EVERY message where it is allowed.=20 However, if we can agree on solution to not mandate R-I in every message, I am fine by allowing it in PRACK. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Friday, November 13, 2009 10:43 AM To: Paul Kyzivat; Elwell, John Cc: sipcore@ietf.org; Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Hi, First, in case you have missed it, I have proposed to remove PRACK from the list of allowed methods. Please indicate if you have a problem with that. Now, to the issue... >>Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE, >>ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a B2BUA to behave appropriately. > >Mandating is sufficient, but probably more than necessary. >Christer has been complaining about mandating. I think there were others (Keith, at least) who didn't like it. >Its probably sufficient to say that each *end* MUST *send* it at least once in each INVITE "cycle". Here I mean The >INVITE request and the associated, provisional and final responses, PRACK and responses, UPDATE and response within the >INVITE, and ACK. And perhaps in each "stand-alone" UPDATE transaction (outside of INVITE) as well. Wouldn't it be enough to say once per INVITE/ACK transaction only? I don't think we would need to mandate it for UPDATE (no matter whether it is "inside" the re-INVITE or not). >Its an open question in my mind whether its worth the complexity of that definition, vs. just mandating it in all places, >to avoid sending it so often. Just because it may be "simple" documentation wise, it does create extra work for parsers, when they have to compare the list, to see whether something has changed. Regards, Christer >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 13 November 2009 00:08 >> To: Elwell, John >> Cc: Christer Holmberg; sipcore@ietf.org; Jeroen van Bemmel >> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info >> header >> >> >> >> Elwell, John wrote: >>> I am not sure we need to specify how B (the B2BUA) handles >> the Recv-Info header field in 3PCC situations. We just need to=20 >> specify use of the header field in such a way that leaves at least=20 >> one possible solution for B2BUAs. If this means B2BUAs need to store=20 >> the latest Recv-Info contents from each UA, so that it can forward=20 >> them when required, that would be a sufficient solution. The=20 >> principle of mandating Recv-Info in each (re-)INVITE request and its=20 >> 2xx response seems to permit a B2BUA to manage things appropriately. >> >> I think that works for me. >> I've lost track - is R-I still ok in UPDATE, ACK, PRACK? >> >> When a 3pcc controlling is initiating a call from the middle, it=20 >> starts out not knowing anything about what either side can do. So it=20 >> can't properly declare R-I in the INVITE. It will learn the=20 >> capabilities of each side in the response to the INVITE. It would=20 >> then like to reflect them to the "other side" asap, which means in=20 >> one of the above. As long as it can do that, I think its ok. >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: 11 November 2009 08:53 >>>> To: Christer Holmberg; Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>> Recv-Info header >>>> >>>> >>>> Hi, >>>> >>>> Please forget the audit proposal until we decide on >> whether we could >>>> agree on assuming that B supports Info Packages in order to make=20 >>>> sure it works between A and D. That would be even esier - we don't=20 >>>> need to mandate Recv-Info in every message, and we don't need to=20 >>>> define the audit :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 11. marraskuuta 2009 11:35 >>>> To: Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jeroen van Bemmel >>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to >> insert Recv-Info >>>> header >>>> >>>> >>>> Hi, >>>> >>>>>> Thanks for the description! >>>>>> >>>>>> Now, assuming that B2BUA B does NOT support I-P (if B >> does support >>>>>> I-P, there should be no issue), it would not insert >> Recv-Info (not >>>>>> even an empty header) in the initial INVITE requests sent >>>> to A and C. >>>>>> In addition, B would most likely not insert Recv-Info in >>>> the re-INVITE >>>> >>>>>> request to D. >>>>>> >>>>>> So, mandating Recv-Info in every message would not solve >> the issue. >>>>> If Recv-Info is mandated in every message, then doesn't the >>>> absence of >>>> Recv-Info mean that it doesn't support Info >>>>> packages at all, at least momentarily? (Until it sends a R-I.) >>>> Exactly, so if B doesn't support Info Packages then A, C and D will >>>> all think that the other entity won't support Info-Packages, so=20 >>>> that doesn't solve the issue either. >>>> >>>> But, one alternative to solve the case when B does support >> I-P (or, at >>>> least is configured to insert Recv-Info) would be de >> define a specific >>>> "audit" value for Recv-Info, which means "Please send your >> list of I-P >>>> packages even if it hasn't changed". >>>> >>>> Then, when B sends the re-INVITE to D it would include >> something like >>>> Recv-Info:* (or whatever value we use for audit). >>>> >>>> "*" could also be used with other listed packages, so when >> B sends D's >>>> list to A it can ensure that A sends its list back so that >> D will get >>>> it. >>>> >>>> In my opinion that is far more nicer than mandating >> Revc-Info in every >>>> message, and it actually solves some of the 3pcc use-cases :) >>>> >>>> Would people be ok with that? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 10. marraskuuta 2009 23:18 >>>>> To: Jeroen van Bemmel >>>>> Cc: Christer Holmberg; sipcore@ietf.org >>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert >>>> Recv-Info >>>>> header >>>>> >>>>> The most straightforward 3pcc case to explain is: >>>>> >>>>> A --------- B ---------- C >>>>> | >>>>> |----------- D >>>>> >>>>> Initially, the 3pcc B2BUA B establishes coordinated >> dialogs A-B and >>>> B-C. >>>>> Later B decides to transfer the call from C to D. So it >>>> establishes a >>>>> new dialog B-D and reinvites A to splice it in. I'm hand >>>> waving over >>>>> the details, because there are many options and they don't matter >>>> here. >>>>> The key point is that A was, for all intents and purposes, >>>> initially >>>>> connected to C, and after a reinvite finds itself connected to D. >>>>> >>>>> Now D may not be able to support the same Info Packages >> that C did. >>>>> To make things work, the R-I values from D must be >>>> presented to A, and >>>> >>>>> it needs to honor them. >>>>> >>>>> Conversely, D needs to be informed of the info packages that A is=20 >>>>> willing to receive. While it is possible that B could have >>>> remembered >>>>> them, and could thus insert them in the initial invite to D, its=20 >>>>> better if B doesn't have to get involved in that. >>>>> >>>>> Many new features run into essentially the same problem >>>> with 3pcc. You >>>> >>>>> just cannot assume state negotiated e2e will survive a reinvite. >>>>> >>>>> And this is quite a bit different than the stability of >> route sets, >>>>> because the route set distinct in each dialog. It doesn't go e2e=20 >>>>> through the B2BUA. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Jeroen van Bemmel wrote: >>>>>> Christer, >>>>>> >>>>>> Given the registration requirement (i.e. there needs to be >>>> some sort >>>>>> of >>>>>> spec) the set of INFO packages will be limited. UAs can >>>> easily list >>>>>> those packages they support up front. Therefore the >> "fully dynamic" >>>>>> case you sketch below seems unlikely to me. >>>>>> >>>>>> The only case I could imagine would be in case of long running=20 >>>>>> dialogs, where the software of one of the peers gets upgraded=20 >>>>>> mid-dialog to support some new INFO package. However, also >>>> that seems >>>> >>>>>> highly unlikely to me. >>>>>> >>>>>> To me, we should keep it simple - "learn INFO packages >>>> whenever you >>>>>> learn the Route set for a Dialog" should be simple enough for=20 >>>>>> developers to get right >>>>>> >>>>>> Regards, >>>>>> Jeroen >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> I also think it's overkill. Furthermore, I don't see a >>>> real world >>>>>>>> use >>>>>>>> >>>>>>> case for changing the set of supported INFO >>>>>>>> packages mid-dialog. Surely the UAS can simply reply with a 403 >>>>>>>> >>>>>>> response when it receives an INFO request which it >>>>>>>> doesn't want to process anymore? >>>>>>>> >>>>>>>> To me, INFO packages should be like the Dialog's route >>>> set: learn >>>>>>>> the >>>>>>>> >>>>>>> supported set from the initial INVITE and 1xx-2xx >>>>>>>> responses, after that don't change it anymore >>>>>>>> >>>>>>> I think Adam made the same comment in the SIPCORE session. >>>>>>> >>>>>>> Personally I think there could be cases where one wants >> to add a >>>>>>> package during a dialog. For example, assume I call you. Then,=20 >>>>>>> during the dialog we decide to start using application X which >>>> uses an Info >>>> >>>>>>> Package, so our phones send Recv-Info:X to each other. >>>> Application X >>>> >>>>>>> may not even be running when we initiate the dialog. >>>>>>> >>>>>>> However, if we are going to require the header in a lot >>>> of messages, >>>> >>>>>>> maybe we should remove PRACK from the list of allowed messages. >>>>>>> Would >>>>>>> people have problems with that? >>>>>>> >>>>>>> But, I would like Paul to comment whether mandating the >> header in >>>>>>> every message would actually solve his 3pcc use-case. >>>>>>> >>>>>>> >>>>>>>> PS The usage of 'nil' to denote no supported packages is not=20 >>>>>>>> consistent >>>>>>>> >>>>>>> with conventions used today, e.g. for Supported >>>>>>>> (suggest to simply use an empty value instead) >>>>>>>> >>>>>>> I think there was some WGLC comment(s) asking about the >>>> same thing. >>>>>>> Personally I have no problem to use an empty header instead of >>>> 'nil'. >>>>>>> However, I want to ensure that nobody objects to such >>>> change before >>>>>>> I >>>>>>> implement it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> DRAGE, Keith (Keith) wrote: >>>>>>> >>>>>>>> This works, but it seems overkill to me. >>>>>>>> >>>>>>>> Firstly can I ensure that this does not include >> REGISTER, which >>>>>>>> could >>>>>>>> >>>>>>> also be understood from the paraphrase of the SIPCORE >> discussion. >>>>>>> >>>>>>>> Secondly can I still have more detail (arrow diagram) on the=20 >>>>>>>> scenario >>>>>>>> >>>>>>> we are trying to solve for 3pcc. I can't see if there >> is a simple >>>>>>> solution if the problem is insufficiently clear. >>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: sipcore-bounces@ietf.org=20 >>>>>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>>>> Sent: Monday, November 09, 2009 4:15 AM >>>>>>>>> To: Christer Holmberg >>>>>>>>> Cc: sipcore@ietf.org >>>>>>>>> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert=20 >>>>>>>>> Recv-Info >>>>>>>>> >>>>>>> >>>>>>>>> header >>>>>>>>> >>>>>>>>> That works for me, and it is sufficiently simple that >> everybody >>>>>>>>> should be able to implement it correctly. :-) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Christer Holmberg wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE >>>> session we >>>> >>>>>>>>>> discussed whether we should mandate to include Recv-Info in >>>>>>>>>> >>>>>>>>> re-INVITE >>>>>>>>> >>>>>>>>>> responses. >>>>>>>>>> >>>>>>>>>> The outcome of the discussion was that EVERY SIP >>>> messages where >>>>>>>>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if >>>>>>>>>> >>>>>>>>> the set of >>>>>>>>> >>>>>>>>>> Info Packages has changed or not. >>>>>>>>>> >>>>>>>>>> Based on the -03pre version of the draft the following >>>>>>>>>> >>>>>>>>> messages would >>>>>>>>> >>>>>>>>>> be >>>>>>>>>> affected: >>>>>>>>>> >>>>>>>>>> INVITE + 18x + 200 >>>>>>>>>> Re-INVITE + 18x + 200 >>>>>>>>>> ACK >>>>>>>>>> UPDATE + 200 >>>>>>>>>> PRACK + 200 >>>>>>>>>> >>>>>>>>>> That is a change from previous versions of the draft, which >>>>>>>>>> >>>>>>>>> says that >>>>>>>>> >>>>>>>>>> the Recv-Info header only needs to be inserted if the >>>> set of Info >>>> >>>>>>>>>> Packages changes. >>>>>>>>>> >>>>>>>>>> So, unless people have issues with that, my intention is to >>>>>>>>>> >>>>>>>>> implement >>>>>>>>> >>>>>>>>>> the change in the next version of the draft. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sipcore mailing list >>>>>>>>> sipcore@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sipcore mailing list >>>>>>>> sipcore@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Fri Nov 13 08:54:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283C03A68E2 for ; Fri, 13 Nov 2009 08:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB45-KQP93rq for ; Fri, 13 Nov 2009 08:54:15 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 630313A67F4 for ; Fri, 13 Nov 2009 08:54:15 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 13 Nov 2009 08:54:45 -0800 From: Brett Tate To: Christer Holmberg , Bob Penfield , "sipcore@ietf.org" Date: Fri, 13 Nov 2009 08:54:35 -0800 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtw Message-ID: <747A6506A991724FB09B129B79D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com> <429446390BA91242867940DBE798A06B740334E3E3@mail> 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 Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:54:16 -0000 >> Maybe I missed something, but why is there an issue with Recv-Info=20 >> in a PRACK that would lead us to disallow it? >=20 > It came from the idea of mandating Recv-Info in EVERY message where=20 > it is allowed. >=20 > However, if we can agree on solution to not mandate R-I in every > message, I am fine by allowing it in PRACK. My opinion concerning PRACK is same as earlier this year. The following is= some text from earlier thread. Because of race conditions, I prefer the header not be allowed. It has been awhile since I read RFC 3262 in depth. If UAS sends INVITE 2xx= while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon receipt= of PRACK? If acceptable to return PRACK 200 during the race condition, sh= ould the PRACK's Recv-Info be ignored if received before or after ACK? If = it returns PRACK 200 and UAS receives PRACK 200 after INVITE 200, should th= e UAC ignore PRACK 200's Recv-Info? http://www.ietf.org/mail-archive/web/sip/current/msg27037.html From br@brianrosen.net Fri Nov 13 11:28:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992AF3A688B for ; Fri, 13 Nov 2009 11:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URGBl-KfaKxw for ; Fri, 13 Nov 2009 11:28:32 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id CE6673A6A4A for ; Fri, 13 Nov 2009 11:28:32 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N91pF-00065E-GH for sipcore@ietf.org; Fri, 13 Nov 2009 13:28:53 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 13 Nov 2009 14:28:50 -0500 From: Brian Rosen To: Message-ID: Thread-Topic: Inequalities for filters Thread-Index: Acpkl4btAPPiBrnU80CBl2hS17JzFg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 19:28:33 -0000 The current filter specs allow "changed by" semantics, a delta on the last value. In location, we ran across the need to know when speed was exceeded by some value. This is not a delta, it's a comparison against a fixed quantity. What is the appetite of the work group to add a generalized inequality, based on the basic "changed by" syntax, that covers the obvious greater than, less than, equals, not equals, greater than or equal to...? You get a notify when the condition is met. This would be a short draft. Brian From jmpolk@cisco.com Fri Nov 13 12:10:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145413A67AC for ; Fri, 13 Nov 2009 12:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXnnWlRod-zW for ; Fri, 13 Nov 2009 12:10:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5BE4C3A6403 for ; Fri, 13 Nov 2009 12:10:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAC1M/UqrR7Ht/2dsb2JhbACIGrVKmBeEPAQ X-IronPort-AV: E=Sophos;i="4.44,739,1249257600"; d="scan'208";a="432110675" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 13 Nov 2009 20:10:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nADKAlGV020223; Fri, 13 Nov 2009 20:10:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 12:10:47 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.81.185]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 12:10:47 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Nov 2009 14:10:45 -0600 To: Brian Rosen , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Nov 2009 20:10:47.0163 (UTC) FILETIME=[63459CB0:01CA649D] Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 20:10:19 -0000 Along this topic, and what was discussed in my review of the loc-filters-07 ID, is what happens if a target moves by a fixed amount (i.e., it has changed locations by the preset number of meters). The example is if a target moves by 3 meters since the last notification, send a new notification of this movement. This lead to the idea of a target moving much more than 3m, but by, say, 100m. Does a notification now get sent at 3m. 6m, 9m, 12m ... 99m, but not the last 1m, because it hasn't reacted the threshold of 3m increments. This lead to the idea that perhaps this target is accelerating. Is this of value, and should this be determined by the target (which senses or is told which increment is has moved) or determined by calculation by the recipient that the target is moving at a faster or slower pace or speed. This is not exactly a slippery slope of new things to track, but it isn't a single value IMO either. James At 01:28 PM 11/13/2009, Brian Rosen wrote: >The current filter specs allow "changed by" semantics, a delta on the last >value. In location, we ran across the need to know when speed was exceeded >by some value. This is not a delta, it's a comparison against a fixed >quantity. > >What is the appetite of the work group to add a generalized inequality, >based on the basic "changed by" syntax, that covers the obvious greater >than, less than, equals, not equals, greater than or equal to...? You get a >notify when the condition is met. > >This would be a short draft. > >Brian > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From br@brianrosen.net Fri Nov 13 12:25:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C3C3A6A51 for ; Fri, 13 Nov 2009 12:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VHAqKTtspiT for ; Fri, 13 Nov 2009 12:25:53 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 30AE33A6783 for ; Fri, 13 Nov 2009 12:25:53 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N92ij-0001cw-Aa; Fri, 13 Nov 2009 14:26:13 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 13 Nov 2009 15:26:17 -0500 From: Brian Rosen To: James Polk , Message-ID: Thread-Topic: [sipcore] Inequalities for filters Thread-Index: Acpkn41/rIVlnm5wHEKv+jxXSUz3Nw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 20:25:54 -0000 I believe one has to be reasonable. If the target is moving slowly, and the filter doesn't get changed, then yes. If the mechanisms in the device don't react fast, and the target is moving quickly, you may not get intermediate reports. You certainly shouldn't get more than one outstanding NOTIFY over this kind of filter. The recipient can control the rate of notification with the rate control filters, so if it doesn't want to be inundated, it can control it. While we have speed, we don't have acceleration, and I'm not interested in adding it. Brian On 11/13/09 3:10 PM, "James Polk" wrote: > Along this topic, and what was discussed in my review of the > loc-filters-07 ID, is what happens if a target moves by a fixed > amount (i.e., it has changed locations by the preset number of > meters). The example is if a target moves by 3 meters since the last > notification, send a new notification of this movement. > > This lead to the idea of a target moving much more than 3m, but by, > say, 100m. Does a notification now get sent at 3m. 6m, 9m, 12m ... > 99m, but not the last 1m, because it hasn't reacted the threshold of > 3m increments. > > This lead to the idea that perhaps this target is accelerating. Is > this of value, and should this be determined by the target (which > senses or is told which increment is has moved) or determined by > calculation by the recipient that the target is moving at a faster or > slower pace or speed. > > This is not exactly a slippery slope of new things to track, but it > isn't a single value IMO either. > > James > > At 01:28 PM 11/13/2009, Brian Rosen wrote: >> The current filter specs allow "changed by" semantics, a delta on the last >> value. In location, we ran across the need to know when speed was exceeded >> by some value. This is not a delta, it's a comparison against a fixed >> quantity. >> >> What is the appetite of the work group to add a generalized inequality, >> based on the basic "changed by" syntax, that covers the obvious greater >> than, less than, equals, not equals, greater than or equal to...? You get a >> notify when the condition is met. >> >> This would be a short draft. >> >> Brian >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From br@brianrosen.net Fri Nov 13 13:27:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EC53A69B1 for ; Fri, 13 Nov 2009 13:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3qfMLPYUTQ2 for ; Fri, 13 Nov 2009 13:27:16 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 47A9C3A69A6 for ; Fri, 13 Nov 2009 13:27:16 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N93g7-00058R-Rn for sipcore@ietf.org; Fri, 13 Nov 2009 15:27:36 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 13 Nov 2009 16:27:43 -0500 From: Brian Rosen To: Message-ID: Thread-Topic: Does SIP Presence imply Geolocation? Thread-Index: AcpkqCKGCkIIyeu3HkGmfNuVdQy+bg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 21:27:17 -0000 In geopriv, there is a discussion of using Geolocation in the NOTIFY from the presence event package. James Polk thinks that in a presence NOTIFY, if the presence PIDF includes a PIDF-LO, then the NOTIFY MUST have a Geolocation header, with a cid pointing to the PIDF that comes as a result of the presence event package. I suggest that this is not correct, and that I think attempts to combine presence and geolocation would actually require TWO PIDFs, one for the presence event package response and the other for the Geolocation header. I don't think combining them makes much sense, but if you did, I think you would need two bodies and multipart. James doesn't agree and thinks the presence event return and the cid on the Geolocation header would be the same mime part. James asserts that ANY use of SIP with location requires Geolocation. I do not agree and claim presence is an independent use of SIP, with its own mechanisms. We would like sipcore's opinion of this. Brian From dean.willis@softarmor.com Fri Nov 13 15:54:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303633A672E for ; Fri, 13 Nov 2009 15:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLBJpEhERC0s for ; Fri, 13 Nov 2009 15:54:24 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 70D883A659C for ; Fri, 13 Nov 2009 15:54:24 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nADNspr6024356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Nov 2009 17:54:53 -0600 Message-Id: <7123E9DD-2CAF-465F-AE5C-6EBF8BC1C4D7@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4AFAC1F4.3030404@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 13 Nov 2009 17:54:45 -0600 References: <4AF79740.8020707@cisco.com> <4AF7C69D.6040804@zonnet.nl> <4AF7CDD0.308@zonnet.nl> <4AF9CA6B.5080109@cisco.com> <4AFA5F5E.1010302@softarmor.com> <4AFAC1F4.3030404@cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org, Jeroen van Bemmel Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 23:54:25 -0000 On Nov 11, 2009, at 7:53 AM, Paul Kyzivat wrote: > > Dean Willis wrote: >> >> B needs to initiate a reINVITE on A-B to inform A of the new info >> capability presented on B-D. > > This has come up because of questioning whether mid-call changes > need be supported at all. What you say of course requires them. > But not in "just any" transaction. Info capabilities negotiation is much the same as session description -- INVITE and UPDATE transactions. -- dean From sanjsinh@cisco.com Sat Nov 14 22:38:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C068F3A6893 for ; Sat, 14 Nov 2009 22:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRDx-eJVO8aw for ; Sat, 14 Nov 2009 22:38:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 920AF3A6767 for ; Sat, 14 Nov 2009 22:38:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA8x/0qtJV2c/2dsb2JhbAC7B5ZvhDwE X-IronPort-AV: E=Sophos;i="4.44,745,1249257600"; d="scan'208";a="68149791" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 15 Nov 2009 06:38:49 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id nAF6cnFm029139; Sun, 15 Nov 2009 06:38:49 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 00:38:49 -0600 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: Sun, 15 Nov 2009 00:38:44 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbA= References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B79D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> From: "Sanjay Sinha (sanjsinh)" To: "Brett Tate" , "Christer Holmberg" , "Bob Penfield" , X-OriginalArrivalTime: 15 Nov 2009 06:38:49.0108 (UTC) FILETIME=[49DFDD40:01CA65BE] Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 06:38:19 -0000 Pl. see inline .. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: Friday, November 13, 2009 10:25 PM > To: Christer Holmberg; Bob Penfield; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > header >=20 > >> Maybe I missed something, but why is there an issue with Recv-Info > >> in a PRACK that would lead us to disallow it? > > > > It came from the idea of mandating Recv-Info in EVERY message where > > it is allowed. > > > > However, if we can agree on solution to not mandate R-I in every > > message, I am fine by allowing it in PRACK. >=20 > My opinion concerning PRACK is same as earlier this year. The > following is some text from earlier thread. >=20 > Because of race conditions, I prefer the header not be allowed. >=20 > It has been awhile since I read RFC 3262 in depth. If UAS sends INVITE > 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon > receipt of PRACK?=20 [Sanjay Sinha (sanjsinh)] Here is text from RFC 3262 about this: The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. So the UAS is not allowed to send 200 to Invite if it is waiting for a Prack for a reliable response with a sdp. Also the last sentence from the rfc text above tells me that the response to Prack, if 200 to Invite has been sent, should be 200 OK and not 481. > If acceptable to return PRACK 200 during the race > condition, should the PRACK's Recv-Info be ignored if received before > or after ACK?=20 [Sanjay Sinha (sanjsinh)] It should be ignored if received after ACK, since ACK completes the Invite transaction. If it returns PRACK 200 and UAS receives PRACK 200 after > INVITE 200, should the UAC ignore PRACK 200's Recv-Info? [Sanjay Sinha (sanjsinh)] Yes, 200 OK to Invite is final response from UAS. Because of these race conditions, I think excluding RI from Prack will be a good idea. Sanjay >=20 >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg27037.html >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From sanjsinh@cisco.com Sun Nov 15 20:16:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B043A68AE for ; Sun, 15 Nov 2009 20:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3acX+xepgFP1 for ; Sun, 15 Nov 2009 20:16:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9475A3A690D for ; Sun, 15 Nov 2009 20:16:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFZgAEutJV2Y/2dsb2JhbAC9T5YchDwE X-IronPort-AV: E=Sophos;i="4.44,749,1249257600"; d="scan'208";a="68161314" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2009 04:16:41 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nAG4GfAw008740; Mon, 16 Nov 2009 04:16:41 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 22:16:40 -0600 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: Sun, 15 Nov 2009 22:16:39 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA2023E3@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: AcpkqCKGCkIIyeu3HkGmfNuVdQy+bgBwtHzA References: From: "Sanjay Sinha (sanjsinh)" To: "Brian Rosen" , X-OriginalArrivalTime: 16 Nov 2009 04:16:40.0875 (UTC) FILETIME=[991087B0:01CA6673] Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 04:16:43 -0000 I think Geolocation is part of rich presence information. In fact, there is a location element in RPID RFC 4480, and I think geolocation as adding more information to it in terms of civic location etc. Hence I also agree with James view that it should be in the same body as PIDF. Sanjay=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Brian Rosen > Sent: Saturday, November 14, 2009 2:58 AM > To: sipcore@ietf.org > Subject: [sipcore] Does SIP Presence imply Geolocation? >=20 > In geopriv, there is a discussion of using Geolocation in the NOTIFY > from > the presence event package. James Polk thinks that in a presence > NOTIFY, if > the presence PIDF includes a PIDF-LO, then the NOTIFY MUST have a > Geolocation header, with a cid pointing to the PIDF that comes as a > result > of the presence event package. >=20 > I suggest that this is not correct, and that I think attempts to > combine > presence and geolocation would actually require TWO PIDFs, one for the > presence event package response and the other for the Geolocation > header. I > don't think combining them makes much sense, but if you did, I think > you > would need two bodies and multipart. James doesn't agree and thinks > the > presence event return and the cid on the Geolocation header would be > the > same mime part. >=20 > James asserts that ANY use of SIP with location requires Geolocation. > I do > not agree and claim presence is an independent use of SIP, with its own > mechanisms. >=20 > We would like sipcore's opinion of this. >=20 > Brian >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From hannes.tschofenig@nsn.com Sun Nov 15 23:00:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E583A63EB for ; Sun, 15 Nov 2009 23:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m5nTbHHAIq1 for ; Sun, 15 Nov 2009 23:00:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AFE5E3A67F9 for ; Sun, 15 Nov 2009 23:00:05 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAG6xsRW017043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2009 07:59:54 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAG6xsjJ020192; Mon, 16 Nov 2009 07:59:54 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 07:59:54 +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: Mon, 16 Nov 2009 09:02:42 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: AcpkqCKGCkIIyeu3HkGmfNuVdQy+bgBSwnnA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , X-OriginalArrivalTime: 16 Nov 2009 06:59:54.0191 (UTC) FILETIME=[6655F5F0:01CA668A] Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:00:10 -0000 Hi Brian, =20 >In geopriv, there is a discussion of using Geolocation in the=20 >NOTIFY from the presence event package. James Polk thinks=20 >that in a presence NOTIFY, if the presence PIDF includes a=20 >PIDF-LO, then the NOTIFY MUST have a Geolocation header, with=20 >a cid pointing to the PIDF that comes as a result of the=20 >presence event package. If you extend this idea beyond location then with every extension one would have to define a new header field that indicates what extension is in the PIDF. =20 This clearly does not seem to be desirable.=20 >I suggest that this is not correct, and that I think attempts=20 >to combine presence and geolocation would actually require TWO=20 >PIDFs, one for the presence event package response and the=20 >other for the Geolocation header. I don't think combining=20 >them makes much sense, but if you did, I think you would need=20 >two bodies and multipart. James doesn't agree and thinks the=20 >presence event return and the cid on the Geolocation header=20 >would be the same mime part. Combining presence and geolocation makes a lot of sense. Wasn't this the core idea of reusing PIDF in the first place? See http://www.ietf.org/rfc/rfc4079.txt Why would one need two PIDFs? Why wouldn't you just put the location and presence information in a single PIDF? > >James asserts that ANY use of SIP with location requires=20 >Geolocation. I do not agree and claim presence is an=20 >independent use of SIP, with its own mechanisms. I agree with you here.=20 > >We would like sipcore's opinion of this. > Ciao Hannes >Brian > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Nov 16 05:17:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70913A67DD for ; Mon, 16 Nov 2009 05:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz4IomGb9pWS for ; Mon, 16 Nov 2009 05:17:25 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6588B3A6950 for ; Mon, 16 Nov 2009 05:17:25 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-f3-4b0150e3d39a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E4.92.06698.3E0510B4; Mon, 16 Nov 2009 14:17:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 14:16:04 +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: Mon, 16 Nov 2009 14:16:03 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: Acpe65kZxHju2o1jTbW3Gh4C4lBnlAAAqkVAADEmM/ABwrVlkA== References: <4AE8B942.1090506@cisco.com><4AF3471B.9060409@nostrum.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "SIPCORE" X-OriginalArrivalTime: 16 Nov 2009 13:16:04.0158 (UTC) FILETIME=[F3159DE0:01CA66BE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:17:26 -0000 Hi,=20 >I am fine with the text we now have in -03pre which says: > > If a UA receives an INFO request associated with an Info Package that > the UA has not indicated willingness to receive, the UA MUST send a > 469 (Bad INFO Package) response (see Section 11.6). In the > terminology of Multiple Dialog Usages [RFC5057], this represents a > Transaction Only failure. Based on [RFC5057] the response represents > a Transaction Only failure, and does not terminate the invite dialog > usage. > >except that we now seem to be saying it twice. Can we combine this into a single sentence. I changed it to: "If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad INFO Package) response (see Section 11.6). In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage." >I note that we have covered the dialog usage of other responses to INFO in 3.2.2 as follows: > > The UA MAY send other error responses, such as Request Failure (4xx), > Server Failure (5xx) and Global Failure (6xx), in accordance with the > error handling procedures in [RFC5057]. > >except that surely we need a parallel paragraph to this in section 3.2.1 to say that reception of such responses is=20 >handled as defined in RFC 5057. I am wondering whether the text should really refer to 5057. AFAIK 5057 does not specify what error code to send, only how they affect the dialog usage.=20 I would suggest that we refer to 3261 instead. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, November 06, 2009 2:36 PM > To: Adam Roach; Sanjay Sinha (sanjsinh) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I agree with Adam, and based on feeback I got from Robert, a > 469 should NEVER terminate the dialog usage, and individual Info=20 > Packages shall not change that. >=20 > Anyone objects to that? >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 5. marraskuuta 2009 23:44 > > To: Sanjay Sinha (sanjsinh) > > Cc: Paul Kyzivat (pkyzivat); Christer Holmberg; SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > [as an individual] > >=20 > > On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote: > > > If the INFO transaction fails, then let the application > > decide whether > > > it wants to continue with the dialog or not? > > > =20 > >=20 > > That's functionally equivalent to asking "why don't we > leave it to the > > application to decide whether a BYE terminates an invite usage?" > >=20 > > When an error occurs, both sides need to know the resulting > state. If > > you sent me a 469, and your application decided that this > terminated > > the dialog but mine decided it only terminated the transaction, the=20 > > result would be unexpected and decidedly unfortunate behavior. > >=20 > > That's why we bothered to publish RFC 5057 at all. > >=20 > > /a > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From br@brianrosen.net Mon Nov 16 06:48:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C9328C16E for ; Mon, 16 Nov 2009 06:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fTCr9ODKrPw for ; Mon, 16 Nov 2009 06:48:45 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0C4A428C158 for ; Mon, 16 Nov 2009 06:48:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NA2sc-0007l7-5q; Mon, 16 Nov 2009 08:48:34 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 16 Nov 2009 09:48:36 -0500 From: Brian Rosen To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Message-ID: Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: AcpkqCKGCkIIyeu3HkGmfNuVdQy+bgBSwnnAADYs9D8= In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:48:46 -0000 Just speculate that someone wanted to put a Geolocation header on the NOTIFY from a presence subscription. I'm not sure why you would want to do that, but let's say you did. Would you then expect there to be one PIDF or two? Would you expect that the location in the Geolocation header was always that of the presentity? I think if you combine Geolocation and the presence NOTIFY, that the uses are totally independent. You make no assumptions on the connection between the Geolocation header target and the presentity. Brian On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Hi Brian, > >> In geopriv, there is a discussion of using Geolocation in the >> NOTIFY from the presence event package. James Polk thinks >> that in a presence NOTIFY, if the presence PIDF includes a >> PIDF-LO, then the NOTIFY MUST have a Geolocation header, with >> a cid pointing to the PIDF that comes as a result of the >> presence event package. > > If you extend this idea beyond location then with every extension one > would have to define a new header field that indicates what extension is > in the PIDF. > > This clearly does not seem to be desirable. > > >> I suggest that this is not correct, and that I think attempts >> to combine presence and geolocation would actually require TWO >> PIDFs, one for the presence event package response and the >> other for the Geolocation header. I don't think combining >> them makes much sense, but if you did, I think you would need >> two bodies and multipart. James doesn't agree and thinks the >> presence event return and the cid on the Geolocation header >> would be the same mime part. > > Combining presence and geolocation makes a lot of sense. Wasn't this the > core idea of reusing PIDF in the first place? See > http://www.ietf.org/rfc/rfc4079.txt > > Why would one need two PIDFs? Why wouldn't you just put the location and > presence information in a single PIDF? > >> >> James asserts that ANY use of SIP with location requires >> Geolocation. I do not agree and claim presence is an >> independent use of SIP, with its own mechanisms. > > I agree with you here. > >> >> We would like sipcore's opinion of this. >> > > Ciao > Hannes > >> Brian >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From pkyzivat@cisco.com Mon Nov 16 07:02:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834A13A67FB for ; Mon, 16 Nov 2009 07:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UesKdRCj7cu for ; Mon, 16 Nov 2009 07:02:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7335A3A67A4 for ; Mon, 16 Nov 2009 07:02:45 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajk1AK74AEutJV2a/2dsb2JhbACZMqYcllaEPAQ X-IronPort-AV: E=Sophos;i="4.44,751,1249257600"; d="scan'208";a="68247140" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2009 15:02:43 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nAGF2hNO017894; Mon, 16 Nov 2009 15:02:43 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:02:43 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:02:42 -0500 Message-ID: <4B016997.3030302@cisco.com> Date: Mon, 16 Nov 2009 10:02:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Rosen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2009 15:02:42.0867 (UTC) FILETIME=[D9032030:01CA66CD] Cc: sipcore@ietf.org Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:02:46 -0000 Brian, Brian Rosen wrote: > Just speculate that someone wanted to put a Geolocation header on the NOTIFY > from a presence subscription. > > I'm not sure why you would want to do that, but let's say you did. > > Would you then expect there to be one PIDF or two? This is an interesting case. It is the first that exhibits a possibility I had considered when we were discussing the body handling draft - that one body part can serve two purposes. On one hand, the body of the notify is satisfying the subscribe request. OTOH, the body of the notify can be referenced from a Geolocation header. That would be the case if indeed you *wanted* the same body part for both. If not, then you you would need two body parts - one with C-D of 'render' for the NOTIFY content, and another, with C-D by-reference for the Geolocation. Paul > Would you expect that the location in the Geolocation header was always that > of the presentity? > > I think if you combine Geolocation and the presence NOTIFY, that the uses > are totally independent. You make no assumptions on the connection between > the Geolocation header target and the presentity. > > Brian > > > > On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" > wrote: > >> Hi Brian, >> >>> In geopriv, there is a discussion of using Geolocation in the >>> NOTIFY from the presence event package. James Polk thinks >>> that in a presence NOTIFY, if the presence PIDF includes a >>> PIDF-LO, then the NOTIFY MUST have a Geolocation header, with >>> a cid pointing to the PIDF that comes as a result of the >>> presence event package. >> If you extend this idea beyond location then with every extension one >> would have to define a new header field that indicates what extension is >> in the PIDF. >> >> This clearly does not seem to be desirable. >> >> >>> I suggest that this is not correct, and that I think attempts >>> to combine presence and geolocation would actually require TWO >>> PIDFs, one for the presence event package response and the >>> other for the Geolocation header. I don't think combining >>> them makes much sense, but if you did, I think you would need >>> two bodies and multipart. James doesn't agree and thinks the >>> presence event return and the cid on the Geolocation header >>> would be the same mime part. >> Combining presence and geolocation makes a lot of sense. Wasn't this the >> core idea of reusing PIDF in the first place? See >> http://www.ietf.org/rfc/rfc4079.txt >> >> Why would one need two PIDFs? Why wouldn't you just put the location and >> presence information in a single PIDF? >> >>> James asserts that ANY use of SIP with location requires >>> Geolocation. I do not agree and claim presence is an >>> independent use of SIP, with its own mechanisms. >> I agree with you here. >> >>> We would like sipcore's opinion of this. >>> >> Ciao >> Hannes >> >>> Brian >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From br@brianrosen.net Mon Nov 16 07:16:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6683A68DD for ; Mon, 16 Nov 2009 07:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNBpijVh43PH for ; Mon, 16 Nov 2009 07:16:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 1DC8F3A677E for ; Mon, 16 Nov 2009 07:16:37 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NA3Jb-000154-Qv; Mon, 16 Nov 2009 09:16:28 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 16 Nov 2009 10:16:29 -0500 From: Brian Rosen To: Paul Kyzivat Message-ID: Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: Acpmz8VtWlye0m5w2kmd2eJNV/anmg== In-Reply-To: <4B016997.3030302@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: sipcore@ietf.org Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:16:39 -0000 Yeah, I guess I would agree that if you WANTED them to be the same, there isn't any reason to force two body parts. This is strictly up to the notifier: there isn't any way to ask for that. Again, this seems to me to be a very weird and rare case: normally, there would be no reason to have a Geolocation header on a Presence NOTIFY. I gather you agree with me that Presence NOTIFY with PIDF-LO doesn't require a Geolocation header as James would assert. Brian On 11/16/09 10:02 AM, "Paul Kyzivat" wrote: > Brian, > > Brian Rosen wrote: >> Just speculate that someone wanted to put a Geolocation header on the NOTIFY >> from a presence subscription. >> >> I'm not sure why you would want to do that, but let's say you did. >> >> Would you then expect there to be one PIDF or two? > > This is an interesting case. It is the first that exhibits a possibility > I had considered when we were discussing the body handling draft - that > one body part can serve two purposes. > > On one hand, the body of the notify is satisfying the subscribe request. > OTOH, the body of the notify can be referenced from a Geolocation header. > > That would be the case if indeed you *wanted* the same body part for > both. If not, then you you would need two body parts - one with C-D of > 'render' for the NOTIFY content, and another, with C-D by-reference for > the Geolocation. > > Paul > >> Would you expect that the location in the Geolocation header was always that >> of the presentity? >> >> I think if you combine Geolocation and the presence NOTIFY, that the uses >> are totally independent. You make no assumptions on the connection between >> the Geolocation header target and the presentity. >> >> Brian >> >> >> >> On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >> wrote: >> >>> Hi Brian, >>> >>>> In geopriv, there is a discussion of using Geolocation in the >>>> NOTIFY from the presence event package. James Polk thinks >>>> that in a presence NOTIFY, if the presence PIDF includes a >>>> PIDF-LO, then the NOTIFY MUST have a Geolocation header, with >>>> a cid pointing to the PIDF that comes as a result of the >>>> presence event package. >>> If you extend this idea beyond location then with every extension one >>> would have to define a new header field that indicates what extension is >>> in the PIDF. >>> >>> This clearly does not seem to be desirable. >>> >>> >>>> I suggest that this is not correct, and that I think attempts >>>> to combine presence and geolocation would actually require TWO >>>> PIDFs, one for the presence event package response and the >>>> other for the Geolocation header. I don't think combining >>>> them makes much sense, but if you did, I think you would need >>>> two bodies and multipart. James doesn't agree and thinks the >>>> presence event return and the cid on the Geolocation header >>>> would be the same mime part. >>> Combining presence and geolocation makes a lot of sense. Wasn't this the >>> core idea of reusing PIDF in the first place? See >>> http://www.ietf.org/rfc/rfc4079.txt >>> >>> Why would one need two PIDFs? Why wouldn't you just put the location and >>> presence information in a single PIDF? >>> >>>> James asserts that ANY use of SIP with location requires >>>> Geolocation. I do not agree and claim presence is an >>>> independent use of SIP, with its own mechanisms. >>> I agree with you here. >>> >>>> We would like sipcore's opinion of this. >>>> >>> Ciao >>> Hannes >>> >>>> Brian >>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From pkyzivat@cisco.com Mon Nov 16 07:29:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087273A67FA for ; Mon, 16 Nov 2009 07:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLZ+VwtQiaeQ for ; Mon, 16 Nov 2009 07:29:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C9D753A68DD for ; Mon, 16 Nov 2009 07:29:22 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajk1AJX+AEtAZnwN/2dsb2JhbACZM6ZWllyEPAQ X-IronPort-AV: E=Sophos;i="4.44,751,1249257600"; d="scan'208";a="68251383" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2009 15:29:21 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAGFTLfc015201; Mon, 16 Nov 2009 15:29:21 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:29:21 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:29:21 -0500 Message-ID: <4B016FCF.1080108@cisco.com> Date: Mon, 16 Nov 2009 10:29:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Rosen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2009 15:29:21.0118 (UTC) FILETIME=[91A4DFE0:01CA66D1] Cc: sipcore@ietf.org Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:29:24 -0000 Brian Rosen wrote: > Yeah, I guess I would agree that if you WANTED them to be the same, there > isn't any reason to force two body parts. > > This is strictly up to the notifier: there isn't any way to ask for that. Right. This is effectively an optional optimization on the part of the notifier. > Again, this seems to me to be a very weird and rare case: normally, there > would be no reason to have a Geolocation header on a Presence NOTIFY. The question of when it would be appropriate to put a geolocation header in a presence notify at all, and especially referencing the presence body of the notify, is interesting. IIUC, doing so would assert that the location there is the location of *notifier*, not the presentity. Right? So sharing the body would only work if the notifier and the presentity are one and the same, or at least geographically collocated. > I gather you agree with me that Presence NOTIFY with PIDF-LO doesn't require > a Geolocation header as James would assert. I haven't been following the discussion closely. But the presence notify and the geolocation header have distinct purposes, so it should be possible to use them separately or together, and if together, referencing the same body part or different body parts. Thanks, Paul > Brian > > > On 11/16/09 10:02 AM, "Paul Kyzivat" wrote: > >> Brian, >> >> Brian Rosen wrote: >>> Just speculate that someone wanted to put a Geolocation header on the NOTIFY >>> from a presence subscription. >>> >>> I'm not sure why you would want to do that, but let's say you did. >>> >>> Would you then expect there to be one PIDF or two? >> This is an interesting case. It is the first that exhibits a possibility >> I had considered when we were discussing the body handling draft - that >> one body part can serve two purposes. >> >> On one hand, the body of the notify is satisfying the subscribe request. >> OTOH, the body of the notify can be referenced from a Geolocation header. >> >> That would be the case if indeed you *wanted* the same body part for >> both. If not, then you you would need two body parts - one with C-D of >> 'render' for the NOTIFY content, and another, with C-D by-reference for >> the Geolocation. >> >> Paul >> >>> Would you expect that the location in the Geolocation header was always that >>> of the presentity? >>> >>> I think if you combine Geolocation and the presence NOTIFY, that the uses >>> are totally independent. You make no assumptions on the connection between >>> the Geolocation header target and the presentity. >>> >>> Brian >>> >>> >>> >>> On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >>> wrote: >>> >>>> Hi Brian, >>>> >>>>> In geopriv, there is a discussion of using Geolocation in the >>>>> NOTIFY from the presence event package. James Polk thinks >>>>> that in a presence NOTIFY, if the presence PIDF includes a >>>>> PIDF-LO, then the NOTIFY MUST have a Geolocation header, with >>>>> a cid pointing to the PIDF that comes as a result of the >>>>> presence event package. >>>> If you extend this idea beyond location then with every extension one >>>> would have to define a new header field that indicates what extension is >>>> in the PIDF. >>>> >>>> This clearly does not seem to be desirable. >>>> >>>> >>>>> I suggest that this is not correct, and that I think attempts >>>>> to combine presence and geolocation would actually require TWO >>>>> PIDFs, one for the presence event package response and the >>>>> other for the Geolocation header. I don't think combining >>>>> them makes much sense, but if you did, I think you would need >>>>> two bodies and multipart. James doesn't agree and thinks the >>>>> presence event return and the cid on the Geolocation header >>>>> would be the same mime part. >>>> Combining presence and geolocation makes a lot of sense. Wasn't this the >>>> core idea of reusing PIDF in the first place? See >>>> http://www.ietf.org/rfc/rfc4079.txt >>>> >>>> Why would one need two PIDFs? Why wouldn't you just put the location and >>>> presence information in a single PIDF? >>>> >>>>> James asserts that ANY use of SIP with location requires >>>>> Geolocation. I do not agree and claim presence is an >>>>> independent use of SIP, with its own mechanisms. >>>> I agree with you here. >>>> >>>>> We would like sipcore's opinion of this. >>>>> >>>> Ciao >>>> Hannes >>>> >>>>> Brian >>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > > > From drage@alcatel-lucent.com Mon Nov 16 07:53:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EFD28C173 for ; Mon, 16 Nov 2009 07:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=3.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 547j07CpMDte for ; Mon, 16 Nov 2009 07:53:41 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AFF573A67D3 for ; Mon, 16 Nov 2009 07:53:40 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAGFrToq000628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Nov 2009 16:53:29 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 16 Nov 2009 16:53:29 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Brian Rosen Date: Mon, 16 Nov 2009 16:53:27 +0100 Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: Acpm0ZnGUFB0LoWVTBuEjn92zuMbHAAAwkVg Message-ID: References: <4B016FCF.1080108@cisco.com> In-Reply-To: <4B016FCF.1080108@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 15:53:42 -0000 Let's look at it from different direction. Does the location form part of the presence information or not. If the location forms part of the information being provided for presence, = then it belongs in the presence information, i.e. in the presence event pac= kage. If the location provision and usage is intended to be orthogonal to presenc= e, then a Geolocation header should be provided.=20 I agree in a NOTIFY for presence, it is likely to be presence related. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, November 16, 2009 3:29 PM > To: Brian Rosen > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Does SIP Presence imply Geolocation? >=20 >=20 >=20 > Brian Rosen wrote: > > Yeah, I guess I would agree that if you WANTED them to be the same,=20 > > there isn't any reason to force two body parts. > >=20 > > This is strictly up to the notifier: there isn't any way to=20 > ask for that. >=20 > Right. This is effectively an optional optimization on the=20 > part of the notifier. >=20 > > Again, this seems to me to be a very weird and rare case: normally,=20 > > there would be no reason to have a Geolocation header on a=20 > Presence NOTIFY. >=20 > The question of when it would be appropriate to put a=20 > geolocation header in a presence notify at all, and=20 > especially referencing the presence body of the notify, is=20 > interesting. IIUC, doing so would assert that the location=20 > there is the location of *notifier*, not the presentity. Right?=20 > So sharing the body would only work if the notifier and the=20 > presentity are one and the same, or at least geographically=20 > collocated. >=20 > > I gather you agree with me that Presence NOTIFY with=20 > PIDF-LO doesn't=20 > > require a Geolocation header as James would assert. >=20 > I haven't been following the discussion closely. > But the presence notify and the geolocation header have=20 > distinct purposes, so it should be possible to use them=20 > separately or together, and if together, referencing the same=20 > body part or different body parts. >=20 > Thanks, > Paul >=20 > > Brian > >=20 > >=20 > > On 11/16/09 10:02 AM, "Paul Kyzivat" wrote: > >=20 > >> Brian, > >> > >> Brian Rosen wrote: > >>> Just speculate that someone wanted to put a Geolocation header on=20 > >>> the NOTIFY from a presence subscription. > >>> > >>> I'm not sure why you would want to do that, but let's say you did. > >>> > >>> Would you then expect there to be one PIDF or two? > >> This is an interesting case. It is the first that exhibits a=20 > >> possibility I had considered when we were discussing the body=20 > >> handling draft - that one body part can serve two purposes. > >> > >> On one hand, the body of the notify is satisfying the=20 > subscribe request. > >> OTOH, the body of the notify can be referenced from a=20 > Geolocation header. > >> > >> That would be the case if indeed you *wanted* the same=20 > body part for=20 > >> both. If not, then you you would need two body parts - one=20 > with C-D=20 > >> of 'render' for the NOTIFY content, and another, with C-D=20 > >> by-reference for the Geolocation. > >> > >> Paul > >> > >>> Would you expect that the location in the Geolocation header was=20 > >>> always that of the presentity? > >>> > >>> I think if you combine Geolocation and the presence=20 > NOTIFY, that the=20 > >>> uses are totally independent. You make no assumptions on the=20 > >>> connection between the Geolocation header target and the=20 > presentity. > >>> > >>> Brian > >>> > >>> > >>> > >>> On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" > >>> wrote: > >>> > >>>> Hi Brian, > >>>> > >>>>> In geopriv, there is a discussion of using Geolocation in the=20 > >>>>> NOTIFY from the presence event package. James Polk=20 > thinks that in=20 > >>>>> a presence NOTIFY, if the presence PIDF includes a=20 > PIDF-LO, then=20 > >>>>> the NOTIFY MUST have a Geolocation header, with a cid=20 > pointing to=20 > >>>>> the PIDF that comes as a result of the presence event package. > >>>> If you extend this idea beyond location then with every=20 > extension=20 > >>>> one would have to define a new header field that indicates what=20 > >>>> extension is in the PIDF. > >>>> > >>>> This clearly does not seem to be desirable. > >>>> > >>>> > >>>>> I suggest that this is not correct, and that I think=20 > attempts to=20 > >>>>> combine presence and geolocation would actually require=20 > TWO PIDFs,=20 > >>>>> one for the presence event package response and the=20 > other for the=20 > >>>>> Geolocation header. I don't think combining them makes much=20 > >>>>> sense, but if you did, I think you would need two bodies and=20 > >>>>> multipart. James doesn't agree and thinks the presence event=20 > >>>>> return and the cid on the Geolocation header would be the same=20 > >>>>> mime part. > >>>> Combining presence and geolocation makes a lot of sense. Wasn't=20 > >>>> this the core idea of reusing PIDF in the first place? See=20 > >>>> http://www.ietf.org/rfc/rfc4079.txt > >>>> > >>>> Why would one need two PIDFs? Why wouldn't you just put the=20 > >>>> location and presence information in a single PIDF? > >>>> > >>>>> James asserts that ANY use of SIP with location requires=20 > >>>>> Geolocation. I do not agree and claim presence is an=20 > independent=20 > >>>>> use of SIP, with its own mechanisms. > >>>> I agree with you here. > >>>> > >>>>> We would like sipcore's opinion of this. > >>>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>>> Brian > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >=20 > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From br@brianrosen.net Mon Nov 16 08:14:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27723A69A0 for ; Mon, 16 Nov 2009 08:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxMQLtDG1tQP for ; Mon, 16 Nov 2009 08:14:27 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A65A93A6986 for ; Mon, 16 Nov 2009 08:14:19 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NA4DM-0004h9-O7; Mon, 16 Nov 2009 10:14:05 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 16 Nov 2009 11:14:06 -0500 From: Brian Rosen To: "DRAGE, Keith (Keith)" , Paul Kyzivat Message-ID: Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: Acpm0ZnGUFB0LoWVTBuEjn92zuMbHAAAwkVgAADLxqc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:14:33 -0000 I don't think that works. If I use Geolocation to pass you a location URI which is a SIP URI, then to dereference that, you need to subscribe to Presence to get the PIDF. That isn't directly related to presence. Brian On 11/16/09 10:53 AM, "DRAGE, Keith (Keith)" wrote: > Let's look at it from different direction. > > Does the location form part of the presence information or not. > > If the location forms part of the information being provided for presence, > then it belongs in the presence information, i.e. in the presence event > package. > > If the location provision and usage is intended to be orthogonal to presence, > then a Geolocation header should be provided. > > I agree in a NOTIFY for presence, it is likely to be presence related. > > regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, November 16, 2009 3:29 PM >> To: Brian Rosen >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Does SIP Presence imply Geolocation? >> >> >> >> Brian Rosen wrote: >>> Yeah, I guess I would agree that if you WANTED them to be the same, >>> there isn't any reason to force two body parts. >>> >>> This is strictly up to the notifier: there isn't any way to >> ask for that. >> >> Right. This is effectively an optional optimization on the >> part of the notifier. >> >>> Again, this seems to me to be a very weird and rare case: normally, >>> there would be no reason to have a Geolocation header on a >> Presence NOTIFY. >> >> The question of when it would be appropriate to put a >> geolocation header in a presence notify at all, and >> especially referencing the presence body of the notify, is >> interesting. IIUC, doing so would assert that the location >> there is the location of *notifier*, not the presentity. Right? >> So sharing the body would only work if the notifier and the >> presentity are one and the same, or at least geographically >> collocated. >> >>> I gather you agree with me that Presence NOTIFY with >> PIDF-LO doesn't >>> require a Geolocation header as James would assert. >> >> I haven't been following the discussion closely. >> But the presence notify and the geolocation header have >> distinct purposes, so it should be possible to use them >> separately or together, and if together, referencing the same >> body part or different body parts. >> >> Thanks, >> Paul >> >>> Brian >>> >>> >>> On 11/16/09 10:02 AM, "Paul Kyzivat" wrote: >>> >>>> Brian, >>>> >>>> Brian Rosen wrote: >>>>> Just speculate that someone wanted to put a Geolocation header on >>>>> the NOTIFY from a presence subscription. >>>>> >>>>> I'm not sure why you would want to do that, but let's say you did. >>>>> >>>>> Would you then expect there to be one PIDF or two? >>>> This is an interesting case. It is the first that exhibits a >>>> possibility I had considered when we were discussing the body >>>> handling draft - that one body part can serve two purposes. >>>> >>>> On one hand, the body of the notify is satisfying the >> subscribe request. >>>> OTOH, the body of the notify can be referenced from a >> Geolocation header. >>>> >>>> That would be the case if indeed you *wanted* the same >> body part for >>>> both. If not, then you you would need two body parts - one >> with C-D >>>> of 'render' for the NOTIFY content, and another, with C-D >>>> by-reference for the Geolocation. >>>> >>>> Paul >>>> >>>>> Would you expect that the location in the Geolocation header was >>>>> always that of the presentity? >>>>> >>>>> I think if you combine Geolocation and the presence >> NOTIFY, that the >>>>> uses are totally independent. You make no assumptions on the >>>>> connection between the Geolocation header target and the >> presentity. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>> On 11/16/09 2:02 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >>>>> wrote: >>>>> >>>>>> Hi Brian, >>>>>> >>>>>>> In geopriv, there is a discussion of using Geolocation in the >>>>>>> NOTIFY from the presence event package. James Polk >> thinks that in >>>>>>> a presence NOTIFY, if the presence PIDF includes a >> PIDF-LO, then >>>>>>> the NOTIFY MUST have a Geolocation header, with a cid >> pointing to >>>>>>> the PIDF that comes as a result of the presence event package. >>>>>> If you extend this idea beyond location then with every >> extension >>>>>> one would have to define a new header field that indicates what >>>>>> extension is in the PIDF. >>>>>> >>>>>> This clearly does not seem to be desirable. >>>>>> >>>>>> >>>>>>> I suggest that this is not correct, and that I think >> attempts to >>>>>>> combine presence and geolocation would actually require >> TWO PIDFs, >>>>>>> one for the presence event package response and the >> other for the >>>>>>> Geolocation header. I don't think combining them makes much >>>>>>> sense, but if you did, I think you would need two bodies and >>>>>>> multipart. James doesn't agree and thinks the presence event >>>>>>> return and the cid on the Geolocation header would be the same >>>>>>> mime part. >>>>>> Combining presence and geolocation makes a lot of sense. Wasn't >>>>>> this the core idea of reusing PIDF in the first place? See >>>>>> http://www.ietf.org/rfc/rfc4079.txt >>>>>> >>>>>> Why would one need two PIDFs? Why wouldn't you just put the >>>>>> location and presence information in a single PIDF? >>>>>> >>>>>>> James asserts that ANY use of SIP with location requires >>>>>>> Geolocation. I do not agree and claim presence is an >> independent >>>>>>> use of SIP, with its own mechanisms. >>>>>> I agree with you here. >>>>>> >>>>>>> We would like sipcore's opinion of this. >>>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>> >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From jmpolk@cisco.com Mon Nov 16 10:28:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5395528C1ED for ; Mon, 16 Nov 2009 10:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Ic7m5Gxraj for ; Mon, 16 Nov 2009 10:28:47 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7A52F28C1DE for ; Mon, 16 Nov 2009 10:28:47 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEADIpAUurRN+K/2dsb2JhbACIHLgDlwqEPAQ X-IronPort-AV: E=Sophos;i="4.44,752,1249257600"; d="scan'208";a="104718885" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2009 18:28:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAGIShCQ020370; Mon, 16 Nov 2009 18:28:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:28:43 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.91.180]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:28:43 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Nov 2009 12:28:41 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Brian Rosen" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-in tra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Nov 2009 18:28:43.0345 (UTC) FILETIME=[A06E6410:01CA66EA] Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 18:28:48 -0000 At 01:02 AM 11/16/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi Brian, > > >In geopriv, there is a discussion of using Geolocation in the > >NOTIFY from the presence event package. James Polk thinks > >that in a presence NOTIFY, if the presence PIDF includes a > >PIDF-LO, then the NOTIFY MUST have a Geolocation header, with > >a cid pointing to the PIDF that comes as a result of the > >presence event package. > >If you extend this idea beyond location then with every extension one >would have to define a new header field that indicates what extension is >in the PIDF. I don't really think that's the case, not unless there were already a document defining how to use presence event package in that way >This clearly does not seem to be desirable. this wouldn't make sense, but SIP Location Conveyance has called out using the Geolocation header value in a NOTIFY within a dereference transaction for a number of years *and* has mandated using the presence event package for each of these years to accomplish this. Brian admitted to me the dereference transaction is the primary purpose of the loc-filters draft (which doesn't include the Geolocation header value). > >I suggest that this is not correct, and that I think attempts > >to combine presence and geolocation would actually require TWO > >PIDFs, one for the presence event package response and the > >other for the Geolocation header. I don't think combining > >them makes much sense, but if you did, I think you would need > >two bodies and multipart. James doesn't agree and thinks the > >presence event return and the cid on the Geolocation header > >would be the same mime part. > >Combining presence and geolocation makes a lot of sense. Wasn't this the >core idea of reusing PIDF in the first place? See >http://www.ietf.org/rfc/rfc4079.txt > >Why would one need two PIDFs? Why wouldn't you just put the location and >presence information in a single PIDF? > > > > >James asserts that ANY use of SIP with location requires > >Geolocation. I do not agree and claim presence is an > >independent use of SIP, with its own mechanisms. > >I agree with you here. > > > > >We would like sipcore's opinion of this. > > > >Ciao >Hannes > > >Brian > > > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Nov 16 13:38:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A81A3A67B2 for ; Mon, 16 Nov 2009 13:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5qQKIta-5tm for ; Mon, 16 Nov 2009 13:38:41 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0B9D83A6875 for ; Mon, 16 Nov 2009 13:38:40 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-c1-4b01c65e12b9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 50.C9.06698.E56C10B4; Mon, 16 Nov 2009 22:38:38 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 22:37:58 +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: Mon, 16 Nov 2009 22:37:58 +0100 Message-ID: In-Reply-To: <4AFA5E99.2090204@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package thread-index: AcpimzhlRUI/XPeHQReheczGedlChQEaIwkA References: <4AFA5E99.2090204@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 16 Nov 2009 21:37:58.0908 (UTC) FILETIME=[10DFCBC0:01CA6705] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:38:42 -0000 What about the following text? "Please create a subregistry in the SIP Parameters registry for Info Packages. Based on , IANA assigns an expert = in order to review an Info Package which is to be registered. The Info Package specification is provided to the reviewer, who ensures that the Info Package is described=20 in a proper way. =20 The reviewer does not consider the applicability of the Info Package for the usage for which it is defined. The following data elements populate the Info Package Registry. Info Package Name: The Info Package Name is a case insensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. Reference: A reference to the specification which describes the Info Package." Regards, Christer -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 11. marraskuuta 2009 8:50 To: DRAGE, Keith (Keith) Cc: Christer Holmberg; Eric Burger; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package DRAGE, Keith (Keith) wrote: > In my view the only part that is expert reviewable is the bit that constitutes the IANA registration. >=20 > I see no reason for performing an expert review of the Info package specification itself. >=20 question for the reviewer: is the referenced specification credible as a specification? that is, is it available and likely to stay that way and does it actually describe the info-package? note that we do not ask "does the specification make sense as an application for INFO or is INFO a reasonable solution to the problem? -- dean From christer.holmberg@ericsson.com Mon Nov 16 13:55:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4219628C205 for ; Mon, 16 Nov 2009 13:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCrCmLcJJjLW for ; Mon, 16 Nov 2009 13:55:39 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DF65028C201 for ; Mon, 16 Nov 2009 13:55:38 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-e2-4b01ca581610 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A4.DC.24094.85AC10B4; Mon, 16 Nov 2009 22:55:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 22:54:51 +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: Mon, 16 Nov 2009 22:54:50 +0100 Message-ID: In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header thread-index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAUhgkUA== References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> From: "Christer Holmberg" To: "Sanjay Sinha (sanjsinh)" , "Brett Tate" , "Bob Penfield" , X-OriginalArrivalTime: 16 Nov 2009 21:54:51.0718 (UTC) FILETIME=[6C8E5660:01CA6707] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:55:40 -0000 Hi, I don't think the idea is that people start to update their I-P sets so often that these kind of race conditions occur. Regards, Christer =20 -----Original Message----- From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 Sent: 15. marraskuuta 2009 8:39 To: Brett Tate; Christer Holmberg; Bob Penfield; sipcore@ietf.org Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header Pl. see inline .. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Brett Tate > Sent: Friday, November 13, 2009 10:25 PM > To: Christer Holmberg; Bob Penfield; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info=20 > header >=20 > >> Maybe I missed something, but why is there an issue with Recv-Info=20 > >> in a PRACK that would lead us to disallow it? > > > > It came from the idea of mandating Recv-Info in EVERY message where=20 > > it is allowed. > > > > However, if we can agree on solution to not mandate R-I in every=20 > > message, I am fine by allowing it in PRACK. >=20 > My opinion concerning PRACK is same as earlier this year. The=20 > following is some text from earlier thread. >=20 > Because of race conditions, I prefer the header not be allowed. >=20 > It has been awhile since I read RFC 3262 in depth. If UAS sends INVITE > 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon > receipt of PRACK? [Sanjay Sinha (sanjsinh)] Here is text from RFC 3262 about this: The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. So the UAS is not allowed to send 200 to Invite if it is waiting for a Prack for a reliable response with a sdp. Also the last sentence from the rfc text above tells me that the response to Prack, if 200 to Invite has been sent, should be 200 OK and not 481. > If acceptable to return PRACK 200 during the race condition, should=20 > the PRACK's Recv-Info be ignored if received before or after ACK? [Sanjay Sinha (sanjsinh)] It should be ignored if received after ACK, since ACK completes the Invite transaction. If it returns PRACK 200 and UAS receives PRACK 200 after > INVITE 200, should the UAC ignore PRACK 200's Recv-Info? [Sanjay Sinha (sanjsinh)] Yes, 200 OK to Invite is final response from UAS. Because of these race conditions, I think excluding RI from Prack will be a good idea. Sanjay >=20 >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg27037.html >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From eburger@standardstrack.com Mon Nov 16 14:49:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA213A69FF for ; Mon, 16 Nov 2009 14:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WHRjxS9FV1e for ; Mon, 16 Nov 2009 14:49:12 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 861043A6A1D for ; Mon, 16 Nov 2009 14:49:12 -0800 (PST) Received: from [210.245.225.146] by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NAANc-0005Qh-Je; Mon, 16 Nov 2009 14:49:04 -0800 Message-Id: From: Eric Burger To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 06:49:06 +0800 References: <4AFA5E99.2090204@softarmor.com> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to register anInfo Package X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 22:49:13 -0000 WFM On Nov 17, 2009, at 5:37 AM, Christer Holmberg wrote: > > What about the following text? > > > "Please create a subregistry in the SIP Parameters > registry for Info Packages. > > Based on , IANA assigns an expert in > order to review an Info Package which is to > be registered. The Info Package specification is provided > to > the reviewer, who ensures that the Info Package is described > in a proper way. > > The reviewer does not consider the applicability of the > Info > Package for the usage for which it is defined. > > The following data elements populate the Info Package > Registry. > > Info Package Name: The Info Package Name is a > case insensitive > token. In addition, IANA shall not register > multiple Info Package > names that have identical case-insensitive > values. > > Reference: A reference to the specification > which describes the > Info Package." > > Regards, > > Christer > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 11. marraskuuta 2009 8:50 > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Eric Burger; sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: What is required to > register anInfo Package > > DRAGE, Keith (Keith) wrote: >> In my view the only part that is expert reviewable is the bit that > constitutes the IANA registration. >> >> I see no reason for performing an expert review of the Info package > specification itself. >> > > question for the reviewer: is the referenced specification credible > as a > specification? that is, is it available and likely to stay that way > and > does it actually describe the info-package? > > note that we do not ask "does the specification make sense as an > application for INFO or is INFO a reasonable solution to the problem? > > -- > dean From christer.holmberg@ericsson.com Tue Nov 17 00:59:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375653A691D for ; Tue, 17 Nov 2009 00:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZNkbdUgY5Zz for ; Tue, 17 Nov 2009 00:59:38 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7A1523A6887 for ; Tue, 17 Nov 2009 00:59:37 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-2e-4b0265f6f2a4 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 13.1A.04191.6F5620B4; Tue, 17 Nov 2009 09:59:34 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:58:16 +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: Tue, 17 Nov 2009 09:58:11 +0100 Message-ID: In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. thread-index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAaWErIA== References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 17 Nov 2009 08:58:16.0356 (UTC) FILETIME=[19F81640:01CA6764] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 08:59:39 -0000 Hi, Below is a modified version of the User Agent Behavior section. It does define some simple rules, which do not mandate UAs to insert Recv-Info "everywhere", and should also address Paul's 3pcc issue: NOTE 1: You can provide pure editorial comments later - for now I am only interested in whether people are ok with the concept. NOTE 2: The secttion below does not specify whether Recv-Info is allowed in PRACK or not. That is a separate issue. NOTE 3: There were support, and no objections, to replace 'nil' with empty R-I header, so I have implemented that also. However, if someone still has an issue with that, let's deal with it in another thread. ------------ A UA which supports the Info Package mechanism MUST indicate, using the Revc-Info header field, the set of Info Packages for which it is willing to receive INFO requests. A UA can list multiple Info Packages in a single Recv-Info header field, and the UA can use multiple Recv-Info header fields. A UA can an empty Recv-Info header field, ie=20 a header field without any header field values. A UA provides its set of Info Packages for which it is willing to receive=20 INFO requests during the dialog establishment. A UA can update the set of=20 Info Packages during the invite dialog usage. If a UA is not willing to receive INFO requests for any Info Packages, during=20 dialog establishment or later during the invite dialog usage, the UA MUST indicate=20 this by including an empty Recv-Info header field. This informs other UAs that the=20 UA still supports the Info Package mechanism. Example: If a UA has previously indicated Info Packages 'foo' and 'bar', and the UA during the lifetime of the invite dialog usage wants to indicate that it does not want to receive INFO requests for any Info Packages anymore, the UA sends a target refresh request with an empty Recv-Info header field. A UA can provide its set of Info Package by using the SIP methods (and their responses)=20 listed in Section 4.=20 Once a UA has sent a list of Info Packages, the list is valid until the UA sends a new list, or an empty Recv-Info header field. Once a UA has indicated that it is willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST be prepared to receive INFO request associated with that Info Package. For a specific dialog, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info Package. The rules below describe the situations when a UA is required to include=20 a Recv-Info header field, alternatively when a UA is not allowed to do it:=20 - The sender of an initial INVITE request MUST include a Recv-Info header=20 field in the initial INVITE request, even if the sender is not willing to=20 receive INFO requests asscoiated with any Info Package. - The receiver of an initial INVITE request MUST include a Recv-Info header=20 in a reliable response to the INVITE request, even if the INVITE request does=20 not contain a Recv-Info header field or the INVITE request contains an empty=20 Recv-Info header field. NOTE: The rule above is specified mainly in order to support 3pcc/transfer=20 use-cases, where one needs to ensure that a UA provides its set of Info Packages. - If a UA receives a request which contains a Recv-Info header field, the=20 UA MUST include a Recv-Info header in a reliable response to the request, even=20 if the set of Info Packages has not changed. - A UA MUST NOT update its set of Info Packages more than once per SIP transaction.=20 A UA MAY repeat the Recv-Info header field in multiple responses to a SIP request (for example, in 18x and 200 responses to an INVITE request). =20 - If a UA includes a Recv-Info header field in an INVITE/re-INVITE request, the=20 UA MUST NOT include a Recv-Info header field in the associated ACK request. =20 NOTE: If a UA receives a request which contains a set of Info Packages, the UA=20 is not restricted to generate its own set of Info Packages as a subset of the=20 received Info Package set.=20 If a UA indicates multiple Info Packages, which provide similar functionality, it is not possible to indicate a priority order of the Info Packages, or that that the UA wishes to only receive INFO request for one of the Info Packages. It is up to the application logic associated with the Info Packages, and specific Info Package specifications, to describe application behavior in such cases. For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO usages [Section 9]. This document does not define a SIP option tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can define an option-tag associated with the specific Info Package, as described in [Section 10.5]. For backward compatibility, if a UA indicates support of the INFO method using the Allow header field [RFC3261], it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv-Info header field to indicate that it supports the Info Package mechanism, in addition the UA still indicates support of the INFO method using the Allow header. ------------- Regards, Christer From victor.pascual.avila@gmail.com Tue Nov 17 01:56:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFA428C1C7 for ; Tue, 17 Nov 2009 01:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9AeFAnzdq77 for ; Tue, 17 Nov 2009 01:56:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 551D328C1C8 for ; Tue, 17 Nov 2009 01:56:28 -0800 (PST) Received: by bwz23 with SMTP id 23so6743667bwz.29 for ; Tue, 17 Nov 2009 01:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=7oD49dQs37t6gIlswwE0Pcesmhj0zZIQq/ly9fNpvVw=; b=Pu6040Fr0dPA97kEJkBLfao/WkeL7MVChh2dzpe17OYt4jutSj3YyVa78FjtgBwbYv 6Z8H9IqcygZT1na7Uhz5ILqqwgBwPc3gt8qwcY3y8US7yq8pj8wlGT9DCbRquPdmdUT0 8i1bYwDnAzuEyGNgYLWHUfHD8mWgP2gaOvRIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ck2tIojdn73b8EFclPSTrdxYbCcQgwTtLM1dR/RAh+Usc92MADMb3/HHWOQfOnu/S4 k2OCPLOyk9RI/Gv0DOL9Fz6IaLN+4h4dq69G7TRtfIw6grQpAwFsX9Hl1+DadmIGuo+H SOrObCWf7QwVU9Y39vUFOSHQ261XsJBU8O51k= MIME-Version: 1.0 Received: by 10.204.20.82 with SMTP id e18mr2690127bkb.168.1258451783672; Tue, 17 Nov 2009 01:56:23 -0800 (PST) Date: Tue, 17 Nov 2009 10:56:23 +0100 Message-ID: <618e24240911170156s215aff0at79882841e020f455@mail.gmail.com> From: Victor Pascual Avila To: SIPCORE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] publication of security exploits X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:56:29 -0000 Hi, Few months ago we submitted a document describing the SIP digest authentication relay attack [1]. We'd also like to describe how TCP-based SIP deployments might be vulnerable to the TCP RST attack [2]. We haven't nailed all the details down yet, but an attacker with spoofed source IP address could reset existing TCP connections. This attack is hard under normal circumstances because you need to know the IP addresses and port numbers. However, it is easy to get this information in SIP; for instance, you just need to send a SIP message to the UA and it will tell you its IP and port in Contact. Having this information in hand, the attacker could reset the TCP connection, rendering the UA unreachable until it realizes it (which can take minutes). In a sense it is similar to the digest security problem, the attack is well known and SIP makes it somewhat simpler to execute. I'd like to explicitly ask the group whether there is interest in publishing security exploits. [1] http://tools.ietf.org/html/draft-state-sip-relay-attack-00 [2] http://kerneltrap.org/node/3072 Cheers, --=20 Victor Pascual =C3=81vila From pkyzivat@cisco.com Tue Nov 17 06:27:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E544F3A6AB8 for ; Tue, 17 Nov 2009 06:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkqH+GjRhnS7 for ; Tue, 17 Nov 2009 06:27:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6393C3A6965 for ; Tue, 17 Nov 2009 06:27:25 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQKAEZBAktAZnwM/2dsb2JhbACZMKYKmCOEOwQ X-IronPort-AV: E=Sophos;i="4.44,758,1249257600"; d="scan'208";a="68516591" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Nov 2009 14:27:23 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAHERNaW004706; Tue, 17 Nov 2009 14:27:23 GMT Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:27:23 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 09:27:22 -0500 Message-ID: <4B02B2CB.6020300@cisco.com> Date: Tue, 17 Nov 2009 09:27:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2009 14:27:22.0976 (UTC) FILETIME=[13DF2E00:01CA6792] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 14:27:27 -0000 Christer, I've indicated a few places inline where I think added clarification is required. But otherwise this approach works for me. Thanks, Paul Christer Holmberg wrote: > Hi, > > Below is a modified version of the User Agent Behavior section. > > It does define some simple rules, which do not mandate UAs to insert > Recv-Info "everywhere", and should also address Paul's 3pcc issue: > > NOTE 1: You can provide pure editorial comments later - for now I am > only interested in whether people are ok with the concept. > > NOTE 2: The secttion below does not specify whether Recv-Info is allowed > in PRACK or not. That is a separate issue. > > NOTE 3: There were support, and no objections, to replace 'nil' with > empty R-I header, so I have implemented that also. However, if someone > still has an issue with that, let's deal with it in another thread. > > > ------------ > > A UA which supports the Info Package mechanism MUST indicate, using > the Revc-Info header field, the set of Info Packages for which it is > willing to receive INFO requests. A UA can list multiple Info > Packages in a single Recv-Info header field, and the UA can use > multiple Recv-Info header fields. A UA can an empty Recv-Info header > field, ie > a header field without any header field values. > > A UA provides its set of Info Packages for which it is willing to > receive > INFO requests during the dialog establishment. A UA can update the > set of > Info Packages during the invite dialog usage. > > If a UA is not willing to receive INFO requests for any Info > Packages, during > dialog establishment or later during the invite dialog usage, the UA > MUST indicate > this by including an empty Recv-Info header field. This informs other > UAs that the > UA still supports the Info Package mechanism. > > Example: If a UA has previously indicated Info Packages 'foo' and > 'bar', and the UA during the lifetime of the invite dialog usage > wants to indicate that it does not want to receive INFO requests for > any Info Packages anymore, the UA sends a target refresh request with > an empty Recv-Info header field. > > A UA can provide its set of Info Package by using the SIP methods > (and their responses) > listed in Section 4. > > Once a UA has sent a list of Info Packages, the list is valid until > the UA sends a new list, or an empty Recv-Info header field. > > Once a UA has indicated that it is willing to receive INFO requests > for a specific Info Package, and a dialog has been established, the > UA MUST be prepared to receive INFO request associated with that Info > Package. This may be an editorial comment, or maybe not... If the above sentence were strictly true then there would be no need for the 469 response. As long as there is the possibility of removing something from the list of packages one is willing to receive there is the possibility of a race condition, where one is no longer willing, but the package is still received. I think maybe there should be some words to that effect in this section. > For a specific dialog, a UA MUST NOT send an INFO request associated > with an Info Package until it has received an indication that the > remote UA is willing to receive INFO requests for that Info Package. Similarly, a comment here that one must cease sending info requests for a package after receiving a new indication revoking willingness to receive that package. > The rules below describe the situations when a UA is required to > include > a Recv-Info header field, alternatively when a UA is not allowed to > do it: > > - The sender of an initial INVITE request MUST include a Recv-Info > header > field in the initial INVITE request, even if the sender is not > willing to > receive INFO requests asscoiated with any Info Package. > > - The receiver of an initial INVITE request MUST include a Recv-Info > header > in a reliable response to the INVITE request, even if the INVITE > request does > not contain a Recv-Info header field or the INVITE request contains > an empty > Recv-Info header field. > > NOTE: The rule above is specified mainly in order to support > 3pcc/transfer > use-cases, where one needs to ensure that a UA provides its set of > Info Packages. > > - If a UA receives a request which contains a Recv-Info header field, > the > UA MUST include a Recv-Info header in a reliable response to the > request, even > if the set of Info Packages has not changed. > > - A UA MUST NOT update its set of Info Packages more than once per > SIP transaction. Is the above really what you mean? Namely that it may update it once - i.e. send it twice with two different values? I think you perhaps mean that a UA must not send two different values in the course of a single transaction. > A UA MAY repeat the Recv-Info header field in multiple responses to a > SIP request > (for example, in 18x and 200 responses to an INVITE request). > > - If a UA includes a Recv-Info header field in an INVITE/re-INVITE > request, the > UA MUST NOT include a Recv-Info header field in the associated ACK > request. > > NOTE: If a UA receives a request which contains a set of Info > Packages, the UA > is not restricted to generate its own set of Info Packages as a > subset of the > received Info Package set. > > If a UA indicates multiple Info Packages, which provide similar > functionality, it is not possible to indicate a priority order of the > Info Packages, or that that the UA wishes to only receive INFO > request for one of the Info Packages. It is up to the application > logic associated with the Info Packages, and specific Info Package > specifications, to describe application behavior in such cases. > > For backward compatibility purpose, even if a UA indicates support of > the Info Package mechanism, it is still allowed to enable legacy INFO > usages [Section 9]. > > This document does not define a SIP option tag [RFC3261] for the Info > Package mechanism. However, an Info Package specification can define > an option-tag associated with the specific Info Package, as described > in [Section 10.5]. > > For backward compatibility, if a UA indicates support of the INFO > method using the Allow header field [RFC3261], it does not implicitly > indicate support of the Info Package mechanism. A UA MUST use the > Recv-Info header field in order to indicate that it supports the Info > Package mechanism. Likewise, even if a UA uses the Recv-Info header > field to indicate that it supports the Info Package mechanism, in > addition the UA still indicates support of the INFO method using the > Allow header. > > ------------- > > Regards, > > Christer > From richard@shockey.us Tue Nov 17 07:47:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A265E3A690F for ; Tue, 17 Nov 2009 07:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rriV-PQHiNrf for ; Tue, 17 Nov 2009 07:47:13 -0800 (PST) Received: from outbound-mail-141.bluehost.com (outbound-mail-141.bluehost.com [67.222.38.31]) by core3.amsl.com (Postfix) with SMTP id A441B3A6BC6 for ; Tue, 17 Nov 2009 07:47:13 -0800 (PST) Received: (qmail 12570 invoked by uid 0); 17 Nov 2009 15:47:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 17 Nov 2009 15:47:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=baMS2xN/BxU1pZJSxjDYHBAuDlfjX8SPUBzUkVFergqhbDzw99jliK2ZITpGMyqbNmyC2qoTTWFreFomo5uz+FmyJKTIheDKu62zoBbZVUY/cpKK8sBaepwgvKgqsH2Y; Received: from [8.22.81.14] (helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NAQGu-0002wQ-9Y; Tue, 17 Nov 2009 08:47:12 -0700 From: "Richard Shockey" To: , Date: Tue, 17 Nov 2009 10:47:11 -0500 Message-ID: <013401ca679d$3a926700$afb73500$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnXhDNP6UoFkakQWCME6TnXYiPQAAPjF+A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 8.22.81.14 authed with richard+shockey.us} Subject: [sipcore] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 15:47:14 -0000 FYI to the general SIP community. There have been substantial field reports of difficulties with T.30 FAX is SIP networks and the SIP Forum was asked to help facilitate discussions among a group of technical experts in fax order to provider recommendations to either the IETF and or ITU SG16 on possible approaches to the problem. Fax is a essential realtime communications service that is not going away and making fax work properly needs to be addressed. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, November 17, 2009 3:15 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Forum - Fax Over IP Task Group Problem Statement Author(s) : X. Chen, et al. Filename : draft-jones-sip-forum-fax-problem-statement-00.txt Pages : 13 Date : 2009-11-17 This memo is published for informational purposes to document the issues identified by the SIP Forum with respect to the transmission of facsimile signaling messages and fax page data over Internet Protocol (IP) networks. Further, it is the intent of this memo to alert the IETF to the formation of a Fax Over IP Task Group within the SIP Forum chartered to investigate and address identified issues as they relate to the deployment of fax services in Session Initiation Protocol (SIP) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-sip-forum-fax-problem-statem ent-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From stpeter@stpeter.im Tue Nov 17 10:03:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CBE3A698F for ; Tue, 17 Nov 2009 10:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1rsTbDmiExW for ; Tue, 17 Nov 2009 10:03:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 05A343A672E for ; Tue, 17 Nov 2009 10:03:31 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1BCED40D16; Tue, 17 Nov 2009 11:03:28 -0700 (MST) Message-ID: <4B02E56F.1070107@stpeter.im> Date: Tue, 17 Nov 2009 11:03:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501E21EA0@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090504060701000600030300" Cc: sipcore@ietf.org Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 18:03:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090504060701000600030300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/16/09 12:02 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Combining presence and geolocation makes a lot of sense. I'm not so sure. :) FWIW, in the XMPP community we actively discourage people from including "rich presence" information in presence updates, because we see that as overloading of core data about availability for communication. We concluded that it is inappropriate for me to receive a presence update when a new song starts on your music player, you walk 3 meters to the north, etc., because I might not care about what tune you're listening to, you might not want me to know your location, etc. And in general presence is already a very chatty technology without introducing a lot more triggers for presence updates. Yes, techniques like composition and filtering are essentially another way to work around the problem (I'm not saying that the XMPP approach is the one true path to presence!). However, no matter how you slice it there are always challenges involved in adding presence and "rich presence" together. My two cents... Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms090504060701000600030300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTExNzE4MDMyN1owIwYJKoZIhvcNAQkEMRYEFIjzLiN0OISTu5lvb87R gQPnd/tQMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAALM/n481OI8GlY9djlheIB7C5ffCWBMKzXUFqQvQ d4iZsfmhFPBOg9hyQ9eh0hUgV2e4Tm9IITOSpegGeS68rzx2W4Y3H894yo1Y44j8OzATecg7 NFUXbf59CtSstAmfnqfLPTxV6Kbs/OYhJ1uqekW7bG784XVk6/WIew/waXLvBpr1EWtY3Qfw egN27keiav/++dT3fyBgw/Q6HgFQ3FoK/6jzsRWOUOfN6zAazZTAs3eyedpQ0EgN64gJ1u4+ 42H9qOytFCbX1ICXbkTUZ6/XZF/HiPtq5R7TTWY98Sr0sFMqAU5fSblv0di8VxGMoRk0fe0H FmV4BV3mx/cd5QAAAAAAAA== --------------ms090504060701000600030300-- From christer.holmberg@ericsson.com Tue Nov 17 13:41:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C9D3A69E5 for ; Tue, 17 Nov 2009 13:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTeBiHRVIAVy for ; Tue, 17 Nov 2009 13:41:02 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9843F3A68B6 for ; Tue, 17 Nov 2009 13:41:01 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-f1-4b03186a84cc Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 96.1B.06698.A68130B4; Tue, 17 Nov 2009 22:40:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 22:40:58 +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: Tue, 17 Nov 2009 22:40:58 +0100 Message-ID: In-Reply-To: <4B02B2CB.6020300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. thread-index: Acpnkhg8UO0qD5VPQZWHs7NFwbBanQANq+dA References: <4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <4B 02B2CB.6 020300@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 17 Nov 2009 21:40:58.0813 (UTC) FILETIME=[A684DED0:01CA67CE] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:41:02 -0000 Hi, >> Once a UA has indicated that it is willing to receive INFO requests >> for a specific Info Package, and a dialog has been established, the >> UA MUST be prepared to receive INFO request associated with that Info >> Package. > >This may be an editorial comment, or maybe not... > >If the above sentence were strictly true then there would be no need for the 469 response. As long as there is the possibility of removing something from the list of packages one is willing to receive=20 >there is the possibility of a race condition, where one is no longer willing, but the package is still received. I think maybe there should be some words to that effect in this section. Maybe we could add: "...until the UA indicates that it is no longer willing to receive INFO requests associated with that Info Package." ------------- >> For a specific dialog, a UA MUST NOT send an INFO request associated >> with an Info Package until it has received an indication that the >> remote UA is willing to receive INFO requests for that Info Package. > >Similarly, a comment here that one must cease sending info requests for a package after receiving a new indication revoking willingness to receive that package. I guess here we could also add: "..., and after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package." ------------- >> - A UA MUST NOT update its set of Info Packages more than once per SIP transaction. > >Is the above really what you mean? Namely that it may update it once - i.e. send it twice with two different values? > >I think you perhaps mean that a UA must not send two different values in the course of a single transaction. > Correct, I noted that myself also. So, maybe the text should say: - A UA MUST NOT provide more than one set of Info Packages per SIP transaction. Regards, Christer From pkyzivat@cisco.com Tue Nov 17 14:29:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C067C28C193 for ; Tue, 17 Nov 2009 14:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4apXR-YdWCnT for ; Tue, 17 Nov 2009 14:29:58 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DB48728C185 for ; Tue, 17 Nov 2009 14:29:58 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALeyAkurRN+K/2dsb2JhbAC+YZg7hDsE X-IronPort-AV: E=Sophos;i="4.44,760,1249257600"; d="scan'208";a="105631900" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2009 22:29:57 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAHMTsvI002364; Tue, 17 Nov 2009 22:29:57 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 17:29:56 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 17:29:56 -0500 Message-ID: <4B0323E2.70201@cisco.com> Date: Tue, 17 Nov 2009 17:29:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <4B02B2CB.6 020300@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2009 22:29:56.0060 (UTC) FILETIME=[7D4131C0:01CA67D5] Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:29:59 -0000 Christer, I think it is getting there. More inline. Thanks, Paul Christer Holmberg wrote: > Hi, > >>> Once a UA has indicated that it is willing to receive INFO > requests >>> for a specific Info Package, and a dialog has been established, > the >>> UA MUST be prepared to receive INFO request associated with that > Info >>> Package. >> This may be an editorial comment, or maybe not... >> >> If the above sentence were strictly true then there would be no need > for the 469 response. As long as there is the possibility of removing > something from the list of packages one is willing to receive >> there is the possibility of a race condition, where one is no longer > willing, but the package is still received. I think maybe there should > be some words to that effect in this section. > > Maybe we could add: > > "...until the UA indicates that it is no longer willing to receive INFO > requests associated with that Info Package." Works for me >>> For a specific dialog, a UA MUST NOT send an INFO request > associated >>> with an Info Package until it has received an indication that the >>> remote UA is willing to receive INFO requests for that Info > Package. >> Similarly, a comment here that one must cease sending info requests for > a package after receiving a new indication revoking willingness to > receive that package. > > I guess here we could also add: "..., and after the UA has received an > indication that the remote UA is no longer willing to receive INFO > requests associated with that Info Package." Just to be sure: "For a specific dialog, a UA MUST NOT send an INFO request with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info Package, *or* and after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package." Note substitution of "or" for "and" because we are discussing when it must NOT send. >>> - A UA MUST NOT update its set of Info Packages more than once per > SIP transaction. >> Is the above really what you mean? Namely that it may update it once - > i.e. send it twice with two different values? >> I think you perhaps mean that a UA must not send two different values > in the course of a single transaction. > > Correct, I noted that myself also. So, maybe the text should say: > > - A UA MUST NOT provide more than one set of Info Packages per SIP > transaction. I think that can still be construed that you are not allowed to send the same set again. How about: - Once a UA has sent an indication of the Info Packages it is willing to receive, it MUST NOT send an indication of a different set of packages within the same SIP transaction. (It MAY indicate the same set of packages again within the transaction.) Thanks, Paul From christer.holmberg@ericsson.com Wed Nov 18 03:28:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 688B63A6B2D for ; Wed, 18 Nov 2009 03:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACEWSUxhDDuL for ; Wed, 18 Nov 2009 03:28:24 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 32A373A6A70 for ; Wed, 18 Nov 2009 03:28:23 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-40-4b03da5468ef Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E6.84.06698.45AD30B4; Wed, 18 Nov 2009 12:28:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 12:28:17 +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, 18 Nov 2009 12:27:14 +0100 Message-ID: In-Reply-To: <4B0323E2.70201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. thread-index: Acpn1YAvM4ka955gQlmQ1Yzv90IMyAAa+7sg References: <4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <4B02B2CB.6 020300@cisco.com> <4B0323E2.70201@cisco.co m> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 18 Nov 2009 11:28:17.0368 (UTC) FILETIME=[39674580:01CA6842] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - Proposed new text for User Agent Behavior section. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:28:25 -0000 Hi,=20 >>>>For a specific dialog, a UA MUST NOT send an INFO request associated >>>>with an Info Package until it has received an indication that the >>>>remote UA is willing to receive INFO requests for that Info Package. >>>Similarly, a comment here that one must cease sending info requests=20 >>>for a package after receiving a new indication revoking willingness to=20 >>>receive that package. >>>=20 >>I guess here we could also add: "..., and after the UA has received an >>indication that the remote UA is no longer willing to receive INFO=20 >>requests associated with that Info Package." >=20 >Just to be sure: >=20 >"For a specific dialog, a UA MUST NOT send an INFO request=20 >with an Info Package until it has received an indication that=20 >the remote UA is willing to receive INFO requests for that=20 >Info Package, *or* and after the UA has received an indication that the >remote UA is no longer willing to receive INFO requests=20 >associated with that Info Package." >=20 >Note substitution of "or" for "and" because we are discussing=20 >when it must NOT send. Correct. --------- >>>>- A UA MUST NOT update its set of Info Packages more than once=20 >>>>per SIP transaction. >>>Is the above really what you mean? Namely that it may update it once=20 >>> - i.e. send it twice with two different values? >>>I think you perhaps mean that a UA must not send two different values >>>in the course of a single transaction. >>>=20 >>Correct, I noted that myself also. So, maybe the text should say: >>=20 >>- A UA MUST NOT provide more than one set of Info Packages per SIP=20 >>transaction. >=20 >I think that can still be construed that you are not allowed=20 >to send the same set again. How about: >=20 >- Once a UA has sent an indication of the Info Packages it is=20 >willing to receive, it MUST NOT send an indication of a=20 >different set of packages within the same SIP transaction.=20 >(It MAY indicate the same set of packages again within the=20 >transaction.) Looks ok. Thanks! Regards, Christer From christer.holmberg@ericsson.com Wed Nov 18 03:36:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982D63A68CB for ; Wed, 18 Nov 2009 03:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7-HrvO7Sfw1 for ; Wed, 18 Nov 2009 03:36:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 74F0628C0DF for ; Wed, 18 Nov 2009 03:36:39 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-fd-4b03dc4440ae Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4B.25.06698.44CD30B4; Wed, 18 Nov 2009 12:36:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 12:36: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 Date: Wed, 18 Nov 2009 12:36:24 +0100 Message-ID: In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? thread-index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAoTdeoA== References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 18 Nov 2009 11:36:36.0649 (UTC) FILETIME=[62FF8190:01CA6843] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:36:40 -0000 =20 Folks, We need to come to a conclusion on this topic: do we allow Recv-Info in PRACK or not? I hear those people saying that we have enough problems with allowing SDPs etc in PRACK, and that we shouldn't add more. I also hear those people saying that we would be able to re-use a PRACK, instad of sending an UPDATE, if there is a need to provide a Info Package set "in the middle of" an INVITE/re-INVITE transaction. Personally, since I've been involved in the problems-with-PRACK discussions, I would vote for NOT allowing it in PRACK. But, I will implement whatever the group decides upon :) Regards, Christer From brett@broadsoft.com Wed Nov 18 04:07:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40E83A68E3 for ; Wed, 18 Nov 2009 04:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QWeSG+Lu2GD for ; Wed, 18 Nov 2009 04:07:30 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id CB4A53A6948 for ; Wed, 18 Nov 2009 04:07:30 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 18 Nov 2009 04:07:26 -0800 From: Brett Tate To: Christer Holmberg , "sipcore@ietf.org" Date: Wed, 18 Nov 2009 04:07:15 -0800 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAoTdeoAABQWHg Message-ID: <747A6506A991724FB09B129B79D5FEB613FE3ADB10@EXMBXCLUS01.citservers.local> References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.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 Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:07:32 -0000 +1 for not allowing in PRACK. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, November 18, 2009 6:36 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > header - PRACK or no PRACK? >=20 >=20 > Folks, >=20 > We need to come to a conclusion on this topic: do we allow Recv-Info in > PRACK or not? >=20 > I hear those people saying that we have enough problems with allowing > SDPs etc in PRACK, and that we shouldn't add more. >=20 > I also hear those people saying that we would be able to re-use a > PRACK, > instad of sending an UPDATE, if there is a need to provide a Info > Package set "in the middle of" an INVITE/re-INVITE transaction. >=20 > Personally, since I've been involved in the problems-with-PRACK > discussions, I would vote for NOT allowing it in PRACK. But, I will > implement whatever the group decides upon :) >=20 > Regards, >=20 > Christer From sanjsinh@cisco.com Wed Nov 18 04:10:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AD03A6B72 for ; Wed, 18 Nov 2009 04:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoCOVnmIYdQZ for ; Wed, 18 Nov 2009 04:10:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9B5E43A6B6F for ; Wed, 18 Nov 2009 04:10:09 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOdyA0utJV2Y/2dsb2JhbAC8epg0hDsE X-IronPort-AV: E=Sophos;i="4.44,765,1249257600"; d="scan'208";a="68669247" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 18 Nov 2009 12:10:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nAICA7uu021880; Wed, 18 Nov 2009 12:10:07 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 06:10:07 -0600 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, 18 Nov 2009 06:10:05 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA287348@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header- PRACK or no PRACK? Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAoTdeoAABa1vg References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail><747A6 506A9917 24FB09B129B 79D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local><00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , X-OriginalArrivalTime: 18 Nov 2009 12:10:07.0094 (UTC) FILETIME=[11511160:01CA6848] Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header- PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:10:10 -0000 It should not be allowed in Prack. Thanks > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday, November 18, 2009 5:06 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info > header- PRACK or no PRACK? >=20 >=20 >=20 > Folks, >=20 > We need to come to a conclusion on this topic: do we allow Recv-Info in > PRACK or not? >=20 > I hear those people saying that we have enough problems with allowing > SDPs etc in PRACK, and that we shouldn't add more. >=20 > I also hear those people saying that we would be able to re-use a > PRACK, > instad of sending an UPDATE, if there is a need to provide a Info > Package set "in the middle of" an INVITE/re-INVITE transaction. >=20 > Personally, since I've been involved in the problems-with-PRACK > discussions, I would vote for NOT allowing it in PRACK. But, I will > implement whatever the group decides upon :) >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From BPenfield@acmepacket.com Wed Nov 18 05:34:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258F83A6A90 for ; Wed, 18 Nov 2009 05:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8o13kfLKwBV for ; Wed, 18 Nov 2009 05:34:42 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4370E3A6969 for ; Wed, 18 Nov 2009 05:34:42 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 18 Nov 2009 08:34:39 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 18 Nov 2009 08:34:38 -0500 From: Bob Penfield To: Christer Holmberg , "sipcore@ietf.org" Date: Wed, 18 Nov 2009 08:34:39 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? Thread-Index: AcpkaK7LnIc9Qkw4SHSSkfr9oQE08wADbgCgAADi0rAAAWIeIAAAXGtwAE8bqbAAoTdeoAAED5vQ Message-ID: <429446390BA91242867940DBE798A06B740334E57C@mail> References: <4AF79740.8020707@cisco.com><4AF7C69D.6040804@zonnet.nl><4AF7CDD0.308@zonnet.nl><4AF9CA6B.5080109@cisco.com><4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.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 Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:34:43 -0000 As I said before, I think allowing Recv-Info in a PRACK can be useful. Recv= -Info does not have the problems that SDP has because it is NOT a negotiati= on, it is an advertisement. Whatever you last got in a Recv-Info is what yo= u can send. I would recommend that Recv-Info be optional in a PRACK, but re= quire that the same Recv-Info be sent in the ACK. I would also make Recv-In= fo optional in 1xx, but require the same Recv-Info in the 200-OK. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, November 18, 2009 6:36 AM To: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r - PRACK or no PRACK? =20 Folks, We need to come to a conclusion on this topic: do we allow Recv-Info in PRACK or not? I hear those people saying that we have enough problems with allowing SDPs etc in PRACK, and that we shouldn't add more. I also hear those people saying that we would be able to re-use a PRACK, instad of sending an UPDATE, if there is a need to provide a Info Package set "in the middle of" an INVITE/re-INVITE transaction. Personally, since I've been involved in the problems-with-PRACK discussions, I would vote for NOT allowing it in PRACK. But, I will implement whatever the group decides upon :) Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From oferg@radvision.com Wed Nov 18 07:32:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A593A6A26 for ; Wed, 18 Nov 2009 07:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+CIZXyP+h9y for ; Wed, 18 Nov 2009 07:32:07 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 1D7D028B23E for ; Wed, 18 Nov 2009 07:31:44 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id nAIFUBZc007777 for sipcore@ietf.org; Wed, 18 Nov 2009 17:30:11 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id nAIFUB50007771 for ; Wed, 18 Nov 2009 17:30:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6863.DD445452" Date: Wed, 18 Nov 2009 17:29:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple parameter instance in a SIP header (RFC 3261 and 3455) Thread-Index: AcpoY9wIEWqznvCWR1y8DqvZgDhQyA== From: "Ofer Goren" To: Subject: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:32:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6863.DD445452 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. =20 I came across an ambiguity between to SIP-related RFC. In 3261 RFC, section 7.3.1, the following is stated: "Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once." =20 However, in RFC 3455, section 4.5.2.3, there is an example saying that the ccf and ecf parameters can appear twice: F2 Invite P1 -> P2 INVITE sip:ua2@home1.net SIP/2.0 Via: SIP/2.0/UDP p1.home1.net:5060;branch=3Dz9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7 To: sip:ua2@home1.net From: sip:ua1home1.net;tag=3D456248 Call-ID: 843817637684230998sdasdh09 CSeq: 18 INVITE Contact: sip:ua1@192.0.2.4 P-Charging-Function-Addresses: ccf=3D192.1.1.1; = ccf=3D192.1.1.2; ecf=3D192.1.1.3; ecf=3D192.1.1.4 =20 =20 My question is if this example in 3455 is indeed valid, or that the restriction mentioned in 3261 is still valid. =20 Thanks, =20 Ofer. ------_=_NextPart_001_01CA6863.DD445452 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.

 

I came across an ambiguity between to SIP-related = RFC.

In 3261 RFC, section 7.3.1, the following is = stated: “Even though an arbitrary number of parameter = pairs may be attached to

   a header = field value, any given parameter-name MUST = NOT appear more  than = once.”

 

However, in RFC 3455, = section 4.5.2.3, there is an example saying that the ccf = and ecf parameters can appear twice:

      F2 Invite P1 -> P2

         INVITE sip:ua2@home1.net SIP/2.0

         Via: SIP/2.0/UDP = p1.home1.net:5060;branch=3Dz9hG4bK34ghi7ab04

         Via: SIP/2.0/UDP = 192.0.2.4:5060;branch=3Dz9hG4bKnashds7

         To: sip:ua2@home1.net

         From: sip:ua1home1.net;tag=3D456248

         Call-ID: 843817637684230998sdasdh09

         CSeq: 18 INVITE

         Contact: sip:ua1@192.0.2.4

         P-Charging-Function-Addresses: ccf=3D192.1.1.1; ccf=3D192.1.1.2; ecf=3D192.1.1.3; ecf=3D192.1.1.4

 

 

My question is if this example in 3455 is indeed = valid, or that the restriction mentioned in 3261 is still valid.

 

Thanks,

 

Ofer.

------_=_NextPart_001_01CA6863.DD445452-- From dean.willis@softarmor.com Wed Nov 18 09:22:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C853A6982 for ; Wed, 18 Nov 2009 09:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEiEo0wafRNO for ; Wed, 18 Nov 2009 09:22:01 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4317A3A69D7 for ; Wed, 18 Nov 2009 09:22:01 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAIHLvK4012662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Nov 2009 11:21:58 -0600 Message-Id: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com> From: Dean Willis To: Ofer Goren In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 11:21:51 -0600 References: X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:22:03 -0000 On Nov 18, 2009, at 9:29 AM, Ofer Goren wrote: > I came across an ambiguity between to SIP-related RFC. > In 3261 RFC, section 7.3.1, the following is stated: =93Even though an = =20 > arbitrary number of parameter pairs may be attached to > a header field value, any given parameter-name MUST NOT appear =20 > more than once.=94 > > However, in RFC 3455, section 4.5.2.3, there is an example saying =20 > that the ccf and ecf parameters can appear twice: > F2 Invite P1 -> P2 > INVITE sip:ua2@home1.net SIP/2.0 > Via: SIP/2.0/UDP p1.home1.net:5060;branch=3Dz9hG4bK34ghi7ab04 > Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7 > To: sip:ua2@home1.net > From: sip:ua1home1.net;tag=3D456248 > Call-ID: 843817637684230998sdasdh09 > CSeq: 18 INVITE > Contact: sip:ua1@192.0.2.4 > P-Charging-Function-Addresses: ccf=3D192.1.1.1; =20 > ccf=3D192.1.1.2; ecf=3D192.1.1.3; ecf=3D192.1.1.4 > > > My question is if this example in 3455 is indeed valid, or that the =20= > restriction mentioned in 3261 is still valid. > I believe 3455 is inconsistent with 3261. It's what we get for not =20 taking those P-headers seriously enough during review. As I understand it, the reason behind non-recurring parameter names in =20= RFC 3261 is that there's no guarantee that parameters will not be =20 reordered by intermediaries, so unique naming rather than positional =20 indexing is required for most applications. In practice, this =20 reordering seldom (never?) happens. Also, I don't believe that RFC =20 3455 cares about the parameter ordering, so it wouldn't be affected by =20= this. However, strictly 3261-compliant parsers are likely to choke on =20= the example in 3455, as they might parse parameter/value pairs into a =20= hash map keyed by the parameter name. Question for the room: Is there any real reason to keep the =20 requirement for parameter-name non-recurrence within a header field =20 value as specified in RFC 3261 7.3.1, or should we relax this =20 requirement and perhaps add an errata statement to RFC 3261 doing so? Or should we errata-note the error in RFC 3455? -- Dean From pkyzivat@cisco.com Wed Nov 18 10:35:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6683A6A32 for ; Wed, 18 Nov 2009 10:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHndlXXA0nNF for ; Wed, 18 Nov 2009 10:35:53 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3F0AA3A687E for ; Wed, 18 Nov 2009 10:35:53 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAF/NA0urRN+K/2dsb2JhbACZFaYImBWEOwQ X-IronPort-AV: E=Sophos;i="4.44,766,1249257600"; d="scan'208";a="106156063" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2009 18:35:51 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAIIZoos018964; Wed, 18 Nov 2009 18:35:51 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:35:50 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:35:50 -0500 Message-ID: <4B043E85.2070405@cisco.com> Date: Wed, 18 Nov 2009 13:35:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com> In-Reply-To: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2009 18:35:50.0054 (UTC) FILETIME=[F3988460:01CA687D] Cc: Ofer Goren , sipcore@ietf.org Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:35:56 -0000 Dean Willis wrote: > Question for the room: Is there any real reason to keep the requirement > for parameter-name non-recurrence within a header field value as > specified in RFC 3261 7.3.1, or should we relax this requirement and > perhaps add an errata statement to RFC 3261 doing so? > > Or should we errata-note the error in RFC 3455? I know of at least one implementation that would consider this a major incompatible change, difficult to fix, because the parameters are kept in a hash table, with no provision for duplicates. We should errata 3455. Thanks, Paul From dean.willis@softarmor.com Wed Nov 18 12:52:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018C23A6A8D for ; Wed, 18 Nov 2009 12:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdH4eIUrxtVP for ; Wed, 18 Nov 2009 12:52:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2A1FF3A6891 for ; Wed, 18 Nov 2009 12:52:20 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAIKq9Y3014316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Nov 2009 14:52:10 -0600 Message-Id: <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B043E85.2070405@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 14:52:04 -0600 References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com> <4B043E85.2070405@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Ofer Goren , SIPCORE , hannu.hietalahti@nokia.com Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 20:52:21 -0000 On Nov 18, 2009, at 12:35 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: > >> Question for the room: Is there any real reason to keep the >> requirement for parameter-name non-recurrence within a header field >> value as specified in RFC 3261 7.3.1, or should we relax this >> requirement and perhaps add an errata statement to RFC 3261 doing so? >> Or should we errata-note the error in RFC 3455? > > I know of at least one implementation that would consider this a > major incompatible change, difficult to fix, because the parameters > are kept in a hash table, with no provision for duplicates. I'm willing to believe that; if I were writing a stack in Perl or Java, that's how I'd build it too. > We should errata 3455. If we go that route, we should probably also generate an LS to 3GPP informing them of the problem and asking them to suggest a fix, since they're the main consumers of 3455 if I understand the situation. I suggest that once our chair has determined consensus on this question that he might wish to call for a volunteer to do the LS. -- Dean From jbemmel@zonnet.nl Wed Nov 18 15:44:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4367F3A68AD for ; Wed, 18 Nov 2009 15:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfmK3kqAb820 for ; Wed, 18 Nov 2009 15:44:55 -0800 (PST) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by core3.amsl.com (Postfix) with ESMTP id F14FA3A6A11 for ; Wed, 18 Nov 2009 15:44:54 -0800 (PST) Received: (qmail 10323 invoked by uid 0); 18 Nov 2009 23:44:38 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Nov 2009 23:44:38 -0000 Message-ID: <4B0486E3.9040502@zonnet.nl> Date: Thu, 19 Nov 2009 00:44:35 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com> <4B043E85.2070405@cisco.com> <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> In-Reply-To: <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Ofer Goren , hannu.hietalahti@nokia.com Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261 and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:44:56 -0000 Some work on this was already done, see http://au.net/ietf/idref/draft-drage-sipping-rfc3455bis/ I remember some discussions on the issue of duplicate parameter names, perhaps Keith knows what happened with those Regards, Jeroen Dean Willis wrote: > > On Nov 18, 2009, at 12:35 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >> >>> Question for the room: Is there any real reason to keep the >>> requirement for parameter-name non-recurrence within a header field >>> value as specified in RFC 3261 7.3.1, or should we relax this >>> requirement and perhaps add an errata statement to RFC 3261 doing so? >>> Or should we errata-note the error in RFC 3455? >> >> I know of at least one implementation that would consider this a >> major incompatible change, difficult to fix, because the parameters >> are kept in a hash table, with no provision for duplicates. > > I'm willing to believe that; if I were writing a stack in Perl or > Java, that's how I'd build it too. > >> We should errata 3455. > > If we go that route, we should probably also generate an LS to 3GPP > informing them of the problem and asking them to suggest a fix, since > they're the main consumers of 3455 if I understand the situation. I > suggest that once our chair has determined consensus on this question > that he might wish to call for a volunteer to do the LS. > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Wed Nov 18 17:58:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64EA28C12E for ; Wed, 18 Nov 2009 17:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEyIsMcm+cMO for ; Wed, 18 Nov 2009 17:58:36 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D8B5A3A687D for ; Wed, 18 Nov 2009 17:58:35 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG81BEtAZnwM/2dsb2JhbADASokcCI5agkoIgWkE X-IronPort-AV: E=Sophos;i="4.44,768,1249257600"; d="scan'208";a="68804004" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Nov 2009 01:58:33 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJ1wXgQ003239; Thu, 19 Nov 2009 01:58:33 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 20:58:33 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 20:58:33 -0500 Message-ID: <4B04A646.6@cisco.com> Date: Wed, 18 Nov 2009 20:58:30 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bob Penfield References: <4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <429446390BA91242867940DBE798A06B740334E57C@mail> In-Reply-To: <429446390BA91242867940DBE798A06B740334E57C@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2009 01:58:33.0109 (UTC) FILETIME=[CC690C50:01CA68BB] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:58:37 -0000 Bob Penfield wrote: > As I said before, I think allowing Recv-Info in a PRACK can be useful. Recv-Info does not have the problems that SDP has because it is NOT a negotiation, it is an advertisement. Whatever you last got in a Recv-Info is what you can send. I agree. > I would recommend that Recv-Info be optional in a PRACK, Yes. > but require that the same Recv-Info be sent in the ACK. > I would also make Recv-Info optional in 1xx, but require the same Recv-Info in the 200-OK. Why? I don't think this is necessary. Especially for PRACK, you know if it got there when you get the response. No value in sending again later. And then it gets messy if you later change with an UPDATE before the ACK. For 1xx, I would agree that if you send in an *unreliable* 1xx that you SHOULD send again in a reliable response or other message. But even then, you might change your mind and want to send something else. How about just a note that if sent in an unreliable 1xx then it may not get there, and you should take that into account. Thanks, Paul > cheers, > (-:bob > > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Wednesday, November 18, 2009 6:36 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? > > > Folks, > > We need to come to a conclusion on this topic: do we allow Recv-Info in > PRACK or not? > > I hear those people saying that we have enough problems with allowing > SDPs etc in PRACK, and that we shouldn't add more. > > I also hear those people saying that we would be able to re-use a PRACK, > instad of sending an UPDATE, if there is a need to provide a Info > Package set "in the middle of" an INVITE/re-INVITE transaction. > > Personally, since I've been involved in the problems-with-PRACK > discussions, I would vote for NOT allowing it in PRACK. But, I will > implement whatever the group decides upon :) > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From oferg@radvision.com Thu Nov 19 03:47:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DC53A68CB for ; Thu, 19 Nov 2009 03:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08JwzvuisjZD for ; Thu, 19 Nov 2009 03:47:44 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 24D223A6924 for ; Thu, 19 Nov 2009 03:47:43 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id nAJBk9aK016606 for sipcore@ietf.org; Thu, 19 Nov 2009 13:46:09 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id nAJBjl4U016586; Thu, 19 Nov 2009 13:45:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA690D.AF40DE72" Date: Thu, 19 Nov 2009 13:40:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455) Thread-Index: AcpokNF2LoQVyHTRQHSJdvlogcmdTgAfEXSQ References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com><4B043E85.2070405@cisco.com> <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> From: "Ofer Goren" To: "Dean Willis" , "Paul Kyzivat" Cc: SIPCORE , hannu.hietalahti@nokia.com Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 11:47:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA690D.AF40DE72 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean. My question arise from a section I read in some 3GPP specification, = 24229-800, regarding the P-Charging-Vector. In section 5.3.2.1, it is stated that: "The I-CSCF shall add a type 3 orig-ioi parameter before the received = orig-ioi parameter. The I-CSCF shall set the type 3 orig-ioi parameter = to a value that identifies the sending network of the request. The = I-CSCF shall not include the type 3 term-ioi parameter". =20 This implies that at least 2 instances of orig-ioi prameter should be = part of this header. In another section, the same is implied regarding = term-ioi. So, looking for some clarifications in the RFCs, I came across = RFC 3455. So it looks like the 3GPP specifications are less strict regarding the = 3261 limitation. Or am I mistaken? =20 Thanks, Ofer ________________________________ nces@ietf.org on behalf of Dean Willis Sent: Wed 11/18/2009 22:52 To: Paul Kyzivat Cc: Ofer Goren; SIPCORE; hannu.hietalahti@nokia.com Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC = 3261and 3455) On Nov 18, 2009, at 12:35 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: > >> Question for the room: Is there any real reason to keep the=20 >> requirement for parameter-name non-recurrence within a header field=20 >> value as specified in RFC 3261 7.3.1, or should we relax this=20 >> requirement and perhaps add an errata statement to RFC 3261 doing so? >> Or should we errata-note the error in RFC 3455? > > I know of at least one implementation that would consider this a=20 > major incompatible change, difficult to fix, because the parameters=20 > are kept in a hash table, with no provision for duplicates. I'm willing to believe that; if I were writing a stack in Perl or=20 Java, that's how I'd build it too. > We should errata 3455. If we go that route, we should probably also generate an LS to 3GPP=20 informing them of the problem and asking them to suggest a fix, since=20 they're the main consumers of 3455 if I understand the situation. I=20 suggest that once our chair has determined consensus on this question=20 that he might wish to call for a volunteer to do the LS. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ------_=_NextPart_001_01CA690D.AF40DE72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Multiple parameter instance = in a SIP header (RFC 3261and 3455)=0A= =0A= =0A= =0A=
=0A=
Dean.
=0A=
My question arise from a = section I read in some 3GPP specification, 24229-800, regarding the = P-Charging-Vector.
=0A=
In section 5.3.2.1, it is = stated that:
=0A=
“The I-CSCF = shall add a type 3 orig-ioi = parameter before the received = orig-ioi parameter. The I-CSCF shall set the type 3 orig-ioi parameter = to a value that identifies the sending network of the request. The = I-CSCF shall not include the type 3 term-ioi = parameter”.
=0A=
 
=0A=
This implies that at least 2 instances of orig-ioi = prameter should be part of this header. In another section, the same is = implied regarding term-ioi. So, looking for some clarifications in the = RFCs, I came across RFC 3455.
=0A=
So it looks like the 3GPP specifications are less strict = regarding the 3261 limitation. Or am I mistaken?
=0A=
 
=0A=
Thanks,
=0A=
Ofer
=0A=
=0A=
=0A=
=0A=
nces@ietf.org on = behalf of Dean Willis
Sent: Wed 11/18/2009 22:52
To: = Paul Kyzivat
Cc: Ofer Goren; SIPCORE; = hannu.hietalahti@nokia.com
Subject: Re: [sipcore] Multiple = parameter instance in a SIP header (RFC 3261and = 3455)

=0A=

=0A=

On Nov 18, 2009, at 12:35 PM, Paul Kyzivat = wrote:

>
>
> Dean Willis = wrote:
>
>> Question for the room: Is there any real = reason to keep the 
>> requirement for parameter-name = non-recurrence within a header field 
>> value as = specified in RFC 3261 7.3.1, or should we relax this 
>> = requirement and perhaps add an errata statement to RFC 3261 doing = so?
>> Or should we errata-note the error in RFC = 3455?
>
> I know of at least one implementation that would = consider this a 
> major incompatible change, difficult to = fix, because the parameters 
> are kept in a hash table, with = no provision for duplicates.

I'm willing to believe that; if I = were writing a stack in Perl or 
Java, that's how I'd build it = too.

> We should errata 3455.

If we go that route, we = should probably also generate an LS to 3GPP 
informing them of = the problem and asking them to suggest a fix, since 
they're the = main consumers of 3455 if I understand the situation. I 
suggest = that once our chair has determined consensus on this = question 
that he might wish to call for a volunteer to do the = LS.

--
Dean
_______________________________________________<= BR>sipcore mailing list
sipcore@ietf.org
https://www.ietf.o= rg/mailman/listinfo/sipcore

------_=_NextPart_001_01CA690D.AF40DE72-- From BPenfield@acmepacket.com Thu Nov 19 04:56:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779063A6917 for ; Thu, 19 Nov 2009 04:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E1+NoeUw9B3 for ; Thu, 19 Nov 2009 04:56:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 704933A67CF for ; Thu, 19 Nov 2009 04:56:49 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 19 Nov 2009 07:56:46 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 19 Nov 2009 07:56:46 -0500 From: Bob Penfield To: Paul Kyzivat Date: Thu, 19 Nov 2009 07:56:44 -0500 Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? Thread-Index: Acpou9mfwtVQ61G4S82y8Yhcrg131AAWPhyw Message-ID: <429446390BA91242867940DBE798A06B740334E60E@mail> References: <4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail> <747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local> <00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <429446390BA91242867940DBE798A06B740334E57C@mail> <4B04A646.6@cisco.com> In-Reply-To: <4B04A646.6@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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:56:50 -0000 I was trying to avoid race conditions where the ACK might arrive before the= PRACK, which could occur if the UAS is allowed to send the 200-OK to the I= NVITE with an un-PRACKed 1xx that did not contain SDP. Maybe we should say = that if Recv-Info was in a PRACK or UPDATE for an "early" dialog, that the = ACK should not contain Recv-Info. As far as repeating the Recv-Info in 200-OK, that should only apply for unr= eliable 1xx response. cheers, (-:bob -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, November 18, 2009 8:58 PM To: Bob Penfield Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info heade= r - PRACK or no PRACK? Bob Penfield wrote: > As I said before, I think allowing Recv-Info in a PRACK can be useful. Re= cv-Info does not have the problems that SDP has because it is NOT a negotia= tion, it is an advertisement. Whatever you last got in a Recv-Info is what = you can send. I agree. > I would recommend that Recv-Info be optional in a PRACK, Yes. > but require that the same Recv-Info be sent in the ACK. > I would also make Recv-Info optional in 1xx, but require the same Recv-In= fo in the 200-OK. Why? I don't think this is necessary. Especially for PRACK, you know if it got there when you get the=20 response. No value in sending again later. And then it gets messy if you=20 later change with an UPDATE before the ACK. For 1xx, I would agree that if you send in an *unreliable* 1xx that you=20 SHOULD send again in a reliable response or other message. But even=20 then, you might change your mind and want to send something else. How about just a note that if sent in an unreliable 1xx then it may not=20 get there, and you should take that into account. Thanks, Paul > cheers, > (-:bob >=20 >=20 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Christer Holmberg > Sent: Wednesday, November 18, 2009 6:36 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info hea= der - PRACK or no PRACK? >=20 > =20 > Folks, >=20 > We need to come to a conclusion on this topic: do we allow Recv-Info in > PRACK or not? >=20 > I hear those people saying that we have enough problems with allowing > SDPs etc in PRACK, and that we shouldn't add more. >=20 > I also hear those people saying that we would be able to re-use a PRACK, > instad of sending an UPDATE, if there is a need to provide a Info > Package set "in the middle of" an INVITE/re-INVITE transaction. >=20 > Personally, since I've been involved in the problems-with-PRACK > discussions, I would vote for NOT allowing it in PRACK. But, I will > implement whatever the group decides upon :) >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Thu Nov 19 05:11:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234603A6B2C for ; Thu, 19 Nov 2009 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbNPttHsL3J1 for ; Thu, 19 Nov 2009 05:11:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 154AB3A6B1F for ; Thu, 19 Nov 2009 05:11:39 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-01-4b054406677b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7B.95.24094.604450B4; Thu, 19 Nov 2009 14:11:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 14:10:27 +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: Thu, 19 Nov 2009 14:09:50 +0100 Message-ID: In-Reply-To: <429446390BA91242867940DBE798A06B740334E60E@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? thread-index: Acpou9mfwtVQ61G4S82y8Yhcrg131AAWPhywAAEbBVA= References: <4AFA2795.5040606@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C68@DEMCHP99E35MSX.ww902.siemens.net><4AFCA34E.20200@cisco.com><7402509E63C5A145A6095D46C179A5B70725DA3C70@DEMCHP99E35MSX.ww902.siemens.net><4AFD64D2.7070605@cisco.com><429446390BA91242867940DBE798A06B740334E3E3@mail><747A6 506A9917 24FB09B129B7 9D5FEB613FE0BA6BC@EXMBXCLUS01.citservers.local><00FC4AA684E90E4DA2FF71021CD5A6CA20232A@XMB-RCD-101.cisco.com> <429446390BA91242867940DBE798A06B740334E57C@mail> <4B04A6 46.6@cis co.com> <429446390BA91242867940DBE798A06B740334E60E@mail> From: "Christer Holmberg" To: "Bob Penfield" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Nov 2009 13:10:27.0916 (UTC) FILETIME=[A9E868C0:01CA6919] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:11:55 -0000 Hi Bob, Please take a look at the proposed rules I sent out some rules ago. In normal cases you would not send Recv-Info in ACK. Regards, Christer=20 -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 Sent: 19. marraskuuta 2009 14:57 To: Paul Kyzivat Cc: Christer Holmberg; sipcore@ietf.org Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? I was trying to avoid race conditions where the ACK might arrive before the PRACK, which could occur if the UAS is allowed to send the 200-OK to the INVITE with an un-PRACKed 1xx that did not contain SDP. Maybe we should say that if Recv-Info was in a PRACK or UPDATE for an "early" dialog, that the ACK should not contain Recv-Info. As far as repeating the Recv-Info in 200-OK, that should only apply for unreliable 1xx response. cheers, (-:bob -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, November 18, 2009 8:58 PM To: Bob Penfield Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? Bob Penfield wrote: > As I said before, I think allowing Recv-Info in a PRACK can be useful. Recv-Info does not have the problems that SDP has because it is NOT a negotiation, it is an advertisement. Whatever you last got in a Recv-Info is what you can send. I agree. > I would recommend that Recv-Info be optional in a PRACK, Yes. > but require that the same Recv-Info be sent in the ACK. > I would also make Recv-Info optional in 1xx, but require the same Recv-Info in the 200-OK. Why? I don't think this is necessary. Especially for PRACK, you know if it got there when you get the=20 response. No value in sending again later. And then it gets messy if you later change with an UPDATE before the ACK. For 1xx, I would agree that if you send in an *unreliable* 1xx that you=20 SHOULD send again in a reliable response or other message. But even=20 then, you might change your mind and want to send something else. How about just a note that if sent in an unreliable 1xx then it may not=20 get there, and you should take that into account. Thanks, Paul > cheers, > (-:bob >=20 >=20 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Wednesday, November 18, 2009 6:36 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK? >=20 > =20 > Folks, >=20 > We need to come to a conclusion on this topic: do we allow Recv-Info in > PRACK or not? >=20 > I hear those people saying that we have enough problems with allowing > SDPs etc in PRACK, and that we shouldn't add more. >=20 > I also hear those people saying that we would be able to re-use a PRACK, > instad of sending an UPDATE, if there is a need to provide a Info > Package set "in the middle of" an INVITE/re-INVITE transaction. >=20 > Personally, since I've been involved in the problems-with-PRACK > discussions, I would vote for NOT allowing it in PRACK. But, I will > implement whatever the group decides upon :) >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From dean.willis@softarmor.com Thu Nov 19 20:27:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA383A685E for ; Thu, 19 Nov 2009 20:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU7ug5QixMGT for ; Thu, 19 Nov 2009 20:27:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 002F93A67FC for ; Thu, 19 Nov 2009 20:27:43 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAK4QGgs028962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Nov 2009 22:26:17 -0600 Message-Id: <34446762-9724-4B82-834C-E8D3A4DAB2F3@softarmor.com> From: Dean Willis To: Ofer Goren In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Nov 2009 22:26:11 -0600 References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com><4B043E85.2070405@cisco.com> <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , hannu.hietalahti@nokia.com Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 04:27:44 -0000 On Nov 19, 2009, at 5:40 AM, Ofer Goren wrote: > Dean. > My question arise from a section I read in some 3GPP specification, =20= > 24229-800, regarding the P-Charging-Vector. > In section 5.3.2.1, it is stated that: > =93The I-CSCF shall add a type 3 orig-ioi parameter before the =20 > received orig-ioi parameter. The I-CSCF shall set the type 3 orig-=20 > ioi parameter to a value that identifies the sending network of the =20= > request. The I-CSCF shall not include the type 3 term-ioi parameter=94. > > This implies that at least 2 instances of orig-ioi prameter should =20 > be part of this header. In another section, the same is implied =20 > regarding term-ioi. So, looking for some clarifications in the RFCs, =20= > I came across RFC 3455. > So it looks like the 3GPP specifications are less strict regarding =20 > the 3261 limitation. Or am I mistaken? > I believe you are correct. On further reflection, I also believe that =20= the 3GPP specification would "fail hard" with at least one of the =20 commercial SIP stacks with which I have a passing familiarity, due to =20= this conflict with MUST level requirements in RFC 3261. My opinion is that we need to work with 3GPP to get this bug in RFC =20 3455/24.229 fixed. Or we need to revise RFC 3261 and throw out all =20 those old SIP Stacks. But given that there are several billion euros =20 worth of product in circulation built on those stacks, I'm guessing =20 we're going to get a lot of push-back on this approach. It's probably =20= easier to fix RFC 3455 to have one instance of each parameter type =20 with multiple values associated with each parameter (that is, make the =20= value according to RFC 3261 sytax into a list of values). -- Dean= From harhittam@gmail.com Fri Nov 20 07:04:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D13A3A694E for ; Fri, 20 Nov 2009 07:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSFOS2stNPO2 for ; Fri, 20 Nov 2009 07:04:23 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 283533A68C7 for ; Fri, 20 Nov 2009 07:04:23 -0800 (PST) Received: by fxm7 with SMTP id 7so3832271fxm.29 for ; Fri, 20 Nov 2009 07:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5BDh7GrhIJJ//h6reuGxBo8ieaPvmyt4EupKV1LdRqo=; b=k7FmGjZxt2JeutbmMLjflFNH5PtIQSeMGG8si9H2hGuD5ZGE4VJkzF1s74TDuPpKHJ zwGREwWYAos5mBLxWN91H/6HITYDHJ1d/bLJCiqwTs4m0//mry4yqv/zuY3hiLss869w CcpBNH81QnlaY+7iYwcVS8tiW9t1oZRXnGia0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LEMj1QWQGa4JESS/g7eJ+w8cQTIQWbfVOKvwJb0Z2O8HiJgqYnf1XbR8jDeDG2ympc t9mVPIqcEiHTfthFnLHkQuBSPziCWrtWmg9UcmVV0PdgzbmQmtomEYJpc/eOe+QlZzG/ cgzPtTEotXY3o0UI4CKX9A00ouUhHWhT2rz/M= MIME-Version: 1.0 Received: by 10.216.88.21 with SMTP id z21mr470275wee.60.1258729457349; Fri, 20 Nov 2009 07:04:17 -0800 (PST) Date: Fri, 20 Nov 2009 17:04:17 +0200 Message-ID: From: Harhit Tam To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=0016e6d9677e2c76340478ceca21 Subject: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 15:08:47 -0000 --0016e6d9677e2c76340478ceca21 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Can we use e2e SIP (without proxies) using only the destination's DNS name? That is Bob's phone has a DNS name bob.domain.org, and Alice would like to make a call to that DNS name directly without using a SIP URI in the form of an e-mail address. How can we use SIP in this way? Thank you in advance. Regards. Harhit --0016e6d9677e2c76340478ceca21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Can we use e2e SIP (without proxies) using only the destina= tion's DNS name?

That is Bob's phone has a DNS name bob.domain.org, and Alice would like
to m= ake a call to that DNS name directly without using a SIP URI in the form of an e-mail address.

How can we use SIP in this way?

Thank y= ou in advance.

Regards.

Harhit

=A0
--0016e6d9677e2c76340478ceca21-- From jmpolk@cisco.com Fri Nov 20 10:13:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5113A6837 for ; Fri, 20 Nov 2009 10:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+6S0QfUTYiL for ; Fri, 20 Nov 2009 10:13:03 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5DC603A6825 for ; Fri, 20 Nov 2009 10:13:03 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL5qBkurR7Ht/2dsb2JhbACHbrU+l2OEPAQ X-IronPort-AV: E=Sophos;i="4.47,260,1257120000"; d="scan'208";a="437021528" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2009 18:12:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAKICgsP020213; Fri, 20 Nov 2009 18:12:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:12:42 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.71.49]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:12:41 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Nov 2009 12:12:40 -0600 To: Harhit Tam , sipcore@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2009 18:12:41.0915 (UTC) FILETIME=[0D06D0B0:01CA6A0D] Subject: Re: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:13:04 -0000 At 09:04 AM 11/20/2009, Harhit Tam wrote: >Hi all, > >Can we use e2e SIP (without proxies) using only the destination's DNS name? > >That is Bob's phone has a DNS name >bob.domain.org, and Alice would like >to make a call to that DNS name directly without using a SIP URI in the form >of an e-mail address. > >How can we use SIP in this way? Does Alice's UA know the IP address of Bob's UA? If yes, then this is all that's needed for point to point communication using SIP. If no, the DNS name needs to be resolved to an IP address somehow (i.e., by some entity) to direct the packet towards Bob's UA. James >Thank you in advance. > >Regards. > >Harhit > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From drage@alcatel-lucent.com Fri Nov 20 11:48:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C473A6812 for ; Fri, 20 Nov 2009 11:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4jYKdV6CgUF for ; Fri, 20 Nov 2009 11:48:21 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 4C0F43A67E7 for ; Fri, 20 Nov 2009 11:48:21 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAKJmGqp030321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 20 Nov 2009 20:48:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 20 Nov 2009 20:48:16 +0100 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Fri, 20 Nov 2009 20:48:15 +0100 Thread-Topic: Usage of Allow-Event header field Thread-Index: AcpqGAtgMAplBWBPTtSq0I1/C7F2Sg== Message-ID: 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [sipcore] Usage of Allow-Event header field X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:48:22 -0000 This header field was defined by RFC 3265. It was then reused by RFC 3903. In RFC 3265 it states: 3.3.7. Allow-Events header usage The "Allow-Events" header, if present, includes a list of tokens which indicates the event packages supported by the client (if sent in a request) or server (if sent in a response). In other words, a node sending an "Allow-Events" header is advertising that it can process SUBSCRIBE requests and generate NOTIFY requests for all of the event packages listed in that header. Any node implementing one or more event packages SHOULD include an appropriate "Allow-Events" header indicating all supported events in all methods which initiate dialogs and their responses (such as INVITE) and OPTIONS responses. This information is very useful, for example, in allowing user agents to render particular interface elements appropriately according to whether the events required to implement the features they represent are supported by the appropriate nodes. Note that "Allow-Events" headers MUST NOT be inserted by proxies. So is the above text applicable only to event packages where the SUBSCRIBE = / NOTIFY methods are used, or is it also applicable to event packages that = could exist only be used on the PUBLISH method? When I turn to RFC 3903 the text regarding Allow-Events is much more limite= d, and refers to its usage only within the PUBLISH and OPTIONS methods. If necessary, clients may probe for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the "Allow" header field in a response to an OPTIONS request indicates support for the PUBLISH method. In addition, the "Allow-Events" header field indicates the supported event packages. 7. Processing OPTIONS Requests A client may probe the ESC for the support of PUBLISH using the OPTIONS request defined in SIP [4]. The ESC processes OPTIONS requests as defined in Section 11.2 of RFC 3261 [4]. In the response to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list of allowed methods in the Allow header field. Also, it SHOULD list the supported event packages in an Allow-Events header field. Note that if the RFC 3265 text applies, then Allow-Events should also appea= r in 2xx PUBLISH responses, and this is not specified by RFC 3903. regards Keith From harhittam@gmail.com Fri Nov 20 13:24:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE7A3A67AB for ; Fri, 20 Nov 2009 13:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqk0fB9RbogV for ; Fri, 20 Nov 2009 13:24:20 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 3A8A03A67A3 for ; Fri, 20 Nov 2009 13:24:20 -0800 (PST) Received: by fxm7 with SMTP id 7so4237081fxm.29 for ; Fri, 20 Nov 2009 13:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xFRw2UlLGjQVVc6N/zArHRPM+vO0b1Ne25X5mKAesy4=; b=S0/Tk9hqQeYKmdxdIjPG2hlsYGekcvpQr/VjlBcCUiF3VRxcALEnYLDDvz4Q4kh7T9 vx0fHv5hf1AU06Lf0I+rW6bylkeqiUntdpfEO0Xlay72akEwToYFTEu6GdvHi5Pwxd7k p+lsubagKNw8N1WOsZr74P2zWdw1Vug7ooZEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z0eWgRupokV5M9OeGsLcnclNxIGcRNr7kvHuCT+Dpkzpq0unWcvBiqzLP4r9VaKMfQ rDqP7wiAhYzOhQGzHOl2eFYYfio3XVABsvqCHczosVhZwxrlF80kBEG8UJFKjqga3K2X S3tOzmH/l+M2xL8lkAy8FX1kZr8yIs0Cg8zZ0= MIME-Version: 1.0 Received: by 10.216.90.65 with SMTP id d43mr626543wef.41.1258752253843; Fri, 20 Nov 2009 13:24:13 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Nov 2009 23:24:13 +0200 Message-ID: From: Harhit Tam To: "James M. Polk" Content-Type: multipart/alternative; boundary=0016e6d99bd1f35afc0478d418e3 Cc: sipcore@ietf.org Subject: Re: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:24:21 -0000 --0016e6d99bd1f35afc0478d418e3 Content-Type: text/plain; charset=ISO-8859-1 Thanks. So, the To: and From: fields that normally carry a SIP URI, can be empty? Note that both Alice and Bob have DNS names and no SIP URIs. When Alice calls Bob, how can he know who is calling? By looking at the contact field of the incoming request? Thanks for your time! Regards. Harhit On Fri, Nov 20, 2009 at 8:12 PM, James M. Polk wrote: > At 09:04 AM 11/20/2009, Harhit Tam wrote: > >> Hi all, >> >> Can we use e2e SIP (without proxies) using only the destination's DNS >> name? >> >> That is Bob's phone has a DNS name bob.domain.org, and Alice would like >> >> to make a call to that DNS name directly without using a SIP URI in the >> form >> of an e-mail address. >> >> How can we use SIP in this way? >> > > Does Alice's UA know the IP address of Bob's UA? > > If yes, then this is all that's needed for point to point communication > using SIP. > > If no, the DNS name needs to be resolved to an IP address somehow (i.e., by > some entity) to direct the packet towards Bob's UA. > > James > > > Thank you in advance. >> >> Regards. >> >> Harhit >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > --0016e6d99bd1f35afc0478d418e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. So, the To: and From: fields that normally carry a SIP URI,
can= be empty? Note that both Alice and Bob have DNS names and no SIP URIs.
=
When Alice calls Bob, how can he know who is calling? By looking at the=
contact field of the incoming request?

Thanks for your time!

= Regards.

Harhit


On Fri, Nov 20= , 2009 at 8:12 PM, James M. Polk <jmpolk@cisco.com> wrote:
At 09:04 AM 11/20/2009, Harhit Tam wrote:
Hi all,

Can we use e2e SIP (without proxies) using only the destination's DNS n= ame?

That is Bob's phone has a DNS name bob.domain.org, and Alice would like
<= br> to make a call to that DNS name directly without using a SIP URI in the for= m
of an e-mail address.

How can we use SIP in this way?

Does Alice's UA know the IP address of Bob's UA?

If yes, then this is all that's needed for point to point communication= using SIP.

If no, the DNS name needs to be resolved to an IP address somehow (i.e., by= some entity) to direct the packet towards Bob's UA.

James


Thank you in advance.

Regards.

Harhit


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


--0016e6d99bd1f35afc0478d418e3-- From jmpolk@cisco.com Fri Nov 20 22:23:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751403A67B3 for ; Fri, 20 Nov 2009 22:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR-fcFQx2sS0 for ; Fri, 20 Nov 2009 22:23:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2452B3A68FD for ; Fri, 20 Nov 2009 22:23:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANcVB0urR7Ht/2dsb2JhbACHbrVRl1uCN4IFBA X-IronPort-AV: E=Sophos;i="4.47,263,1257120000"; d="scan'208";a="437375531" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2009 06:23:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAL6NH8Y011333; Sat, 21 Nov 2009 06:23:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 22:23:17 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.71.49]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 22:23:16 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Nov 2009 00:23:15 -0600 To: Harhit Tam From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2009 06:23:16.0765 (UTC) FILETIME=[1CA21CD0:01CA6A73] Cc: sipcore@ietf.org Subject: Re: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 06:23:21 -0000 At 03:24 PM 11/20/2009, Harhit Tam wrote: >Thanks. So, the To: and From: fields that normally carry a SIP URI, >can be empty? I don't believe they can be , and you must have the To: and From: tags for call identification. However, SIP doesn't route based on the To: or From: URIs, so asking if SIP can work without proxies doesn't ask if the To and From header values can be empty. SIP routes based on the Request-URI in the status line at the top of the SIP header - where the Request-URI (or R-URI) can be merely an IP address. >Note that both Alice and Bob have DNS names and no SIP URIs. > >When Alice calls Bob, how can he know who is calling? This is part of the discussion about "display names" -- which aren't at all part of the To or From SIP URIs, though they can be part of the same header value, but this is not required in RFC 3261. >By looking at the contact field of the incoming request? This is done in the From: header value (RFC 3261), or the P-Asserted-Identity header value (RFC 3323 or 3325, I can't remember which at this moment) or the Identity header value from RFC 4474 -- but not the Contact header value. (I think I got them all) Hope this helps James >Thanks for your time! > >Regards. > >Harhit > > >On Fri, Nov 20, 2009 at 8:12 PM, James M. Polk ><jmpolk@cisco.com> wrote: >At 09:04 AM 11/20/2009, Harhit Tam wrote: >Hi all, > >Can we use e2e SIP (without proxies) using only the destination's DNS name? > >That is Bob's phone has a DNS name >bob.domain.org, and Alice would like > >to make a call to that DNS name directly without using a SIP URI in the form >of an e-mail address. > >How can we use SIP in this way? > > >Does Alice's UA know the IP address of Bob's UA? > >If yes, then this is all that's needed for point to point >communication using SIP. > >If no, the DNS name needs to be resolved to an IP address somehow >(i.e., by some entity) to direct the packet towards Bob's UA. > >James > > >Thank you in advance. > >Regards. > >Harhit > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > > From hannu.hietalahti@nokia.com Mon Nov 23 00:02:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231C128C105 for ; Mon, 23 Nov 2009 00:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLzAM8+kui19 for ; Mon, 23 Nov 2009 00:02:20 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id CF4D528C106 for ; Mon, 23 Nov 2009 00:02:19 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAN81men011367; Mon, 23 Nov 2009 10:02:05 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 10:02:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 10:02:00 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 23 Nov 2009 09:01:59 +0100 From: To: , , Date: Mon, 23 Nov 2009 09:01:58 +0100 Thread-Topic: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455) Thread-Index: AcppmdK2dOXOty9cTDiwJ5p9jXhm9gCeNvfg Message-ID: <15443028349C3C44BA819EB51B3B4F3C537C09D38D@NOK-EUMSG-01.mgdnok.nokia.com> References: <4C065F92-B3C2-46A0-9799-8F15D0C2AE79@softarmor.com><4B043E85.2070405@cisco.com> <7C1AEC0E-C361-4E32-A0F8-FC467444238B@softarmor.com> <34446762-9724-4B82-834C-E8D3A4DAB2F3@softarmor.com> In-Reply-To: <34446762-9724-4B82-834C-E8D3A4DAB2F3@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-OriginalArrivalTime: 23 Nov 2009 08:02:00.0022 (UTC) FILETIME=[3BFEE760:01CA6C13] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Multiple parameter instance in a SIP header (RFC 3261and 3455) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:02:21 -0000 Hi, some solution to multiple header issue is indeed needed.=20 I think Keith has been working in this area and he is also the rapporteur o= f 24.229, so his comment would be appreciated, please? BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 20 November, 2009 06:26 >To: Ofer Goren >Cc: Paul Kyzivat; SIPCORE; Hietalahti Hannu (Nokia-CIC/Oulu) >Subject: Re: [sipcore] Multiple parameter instance in a SIP=20 >header (RFC 3261and 3455) > > >On Nov 19, 2009, at 5:40 AM, Ofer Goren wrote: > >> Dean. >> My question arise from a section I read in some 3GPP specification, =20 >> 24229-800, regarding the P-Charging-Vector. >> In section 5.3.2.1, it is stated that: >> "The I-CSCF shall add a type 3 orig-ioi parameter before the =20 >> received orig-ioi parameter. The I-CSCF shall set the type 3 orig-=20 >> ioi parameter to a value that identifies the sending network of the =20 >> request. The I-CSCF shall not include the type 3 term-ioi parameter". >> >> This implies that at least 2 instances of orig-ioi prameter should =20 >> be part of this header. In another section, the same is implied =20 >> regarding term-ioi. So, looking for some clarifications in=20 >the RFCs, =20 >> I came across RFC 3455. >> So it looks like the 3GPP specifications are less strict regarding =20 >> the 3261 limitation. Or am I mistaken? >> > >I believe you are correct. On further reflection, I also believe that =20 >the 3GPP specification would "fail hard" with at least one of the =20 >commercial SIP stacks with which I have a passing familiarity, due to =20 >this conflict with MUST level requirements in RFC 3261. > >My opinion is that we need to work with 3GPP to get this bug in RFC =20 >3455/24.229 fixed. Or we need to revise RFC 3261 and throw out all =20 >those old SIP Stacks. But given that there are several billion euros =20 >worth of product in circulation built on those stacks, I'm guessing =20 >we're going to get a lot of push-back on this approach. It's probably =20 >easier to fix RFC 3455 to have one instance of each parameter type =20 >with multiple values associated with each parameter (that is,=20 >make the =20 >value according to RFC 3261 sytax into a list of values). > >-- >Dean= From christer.holmberg@ericsson.com Mon Nov 23 04:14:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5042B3A6A5B for ; Mon, 23 Nov 2009 04:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQk96EMXswQx for ; Mon, 23 Nov 2009 04:14:40 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EC3293A6A38 for ; Mon, 23 Nov 2009 04:14:39 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-18-4b0a7caa5cc1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2C.4A.04191.AAC7A0B4; Mon, 23 Nov 2009 13:14:34 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:13:28 +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: Mon, 23 Nov 2009 13:13:29 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM/EzyUg4F5md1Trejk8QBtAWnlgAsjyIQB6GO31A= References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com><0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 23 Nov 2009 12:13:28.0081 (UTC) FILETIME=[5D2E0010:01CA6C36] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:14:41 -0000 Hi Robert, I've been thinking about the security consideration section of the 199. I do not think 199 introduces a new attack, because if a middle-man can send 199 he can probably also send a BYE. Below is some suggested text: "12. Security Considerations General security issues related to SIP responses are described in [RFC3261]. Due to the nature of the 199 response, it may be attractive to use it for launching attacks in order to terminate specific early dialogs (other early dialogs will not be affected).=20 In addition, if a man-in-the-middle sends a 199 response to the UAC, which terminates=20 a specific dialog, it can take a while until the UAS finds out that the=20 UAC, and possbile stateful intermediates, have terminated the dialog. However, the same kind of attack can be performed if a man-in-the-middle sends a=20 BYE request towards the UAC. The UAC will terminate the dialog for which the BYE request is sent, but it can take a while until the UAS finds out that the dialog has been termianted. SIP security mechanisms (e.g. hop-to-hop TLS) can be used to minimize,=20 or eliminate, the risk for such attacks." Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 15. lokakuuta 2009 18:53 > To: Robert Sparks > Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org;=20 > sipcore-chairs@tools.ietf.org > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 >=20 > Hi, > =20 > >Quick response to the clarifying questions: > > > > > >=09 > >=09 > >The security consideration section is not yet sufficient. > > > >It should have said: > > > >The security consideration section is not yet sufficient. If=20 > there is=20 > >an effective attack here, we need text that explores it. If there > isn't,=20 > >we need text that argues it isn't.=20 >=20 > Ok, I'll look into that.=20 > =09 > ------------------- > =09 >=20 > >Bottom of page 3, next to last paragraph, > > > > > >This sentence: > > When SIP entities upstream receive the non-2xx > > final response they will release resources associated with the > > session, and the UAC will terminate the session setup. > >is assuming the final response wasn't something the UAC=20 > could react to=20 > >by trying again with some related changes (like responding to a > 401/407). >=20 > Ok, now I got it. >=20 > So, I guess the text should say something like: >=20 > "When SIP entities upstream receive the non-2xx final=20 > response they will normally release resources associated with=20 > the session, and the UAC will terminate the session setup,=20 > unless the final response (e.g. a 401/407 final response)=20 > triggers a new session setup request to be sent." >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From brett@broadsoft.com Mon Nov 23 04:38:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C898D3A6858 for ; Mon, 23 Nov 2009 04:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UsgY1I89Mm1 for ; Mon, 23 Nov 2009 04:38:04 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E3F3A3A68F0 for ; Mon, 23 Nov 2009 04:38:04 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 23 Nov 2009 04:38:00 -0800 From: Brett Tate To: Christer Holmberg Date: Mon, 23 Nov 2009 04:37:48 -0800 Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM/EzyUg4F5md1Trejk8QBtAWnlgAsjyIQB6GO31AAAI01UA== Message-ID: <747A6506A991724FB09B129B79D5FEB613FE51A270@EXMBXCLUS01.citservers.local> References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com><0C768562-119E-46AB-A3C9-2C0130B7B6A3@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 Cc: "draft-ietf-sipcore-199@tools.ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:38:05 -0000 Hi Christer, BYE from called party is not allowed for terminating an early dialog. If I= recall the rfc3261 text correctly, it actually requires the ACK (or INVITE= 2xx timeout) before called party can send BYE. Since the BYE would be treated as an abnormal situation (BYE race condition= with INVITE 2xx), the outcomes might be different. Thus I don't think the= second paragraph of the proposed text is accurate. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Monday, November 23, 2009 7:13 AM > To: Robert Sparks > Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org; sipcore- > chairs@tools.ietf.org > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 >=20 >=20 > Hi Robert, >=20 > I've been thinking about the security consideration section of the 199. > I do not think 199 introduces a new attack, because if a middle-man can > send 199 he can probably also send a BYE. >=20 > Below is some suggested text: >=20 > "12. Security Considerations >=20 > General security issues related to SIP responses are described in > [RFC3261]. Due to the nature of the 199 response, it may be > attractive to use it for launching attacks in order to terminate > specific early dialogs (other early dialogs will not be affected). > In addition, if a man-in-the-middle sends a 199 response to the UAC, > which terminates > a specific dialog, it can take a while until the UAS finds out that > the > UAC, and possbile stateful intermediates, have terminated the > dialog. >=20 > However, the same kind of attack can be performed if a > man-in-the-middle sends a > BYE request towards the UAC. The UAC will terminate the dialog for > which the BYE > request is sent, but it can take a while until the UAS finds out > that > the dialog has > been termianted. SIP security mechanisms (e.g. hop-to-hop TLS) can > be > used to minimize, > or eliminate, the risk for such attacks." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 15. lokakuuta 2009 18:53 > > To: Robert Sparks > > Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org; > > sipcore-chairs@tools.ietf.org > > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 > > > > Hi, > > > > >Quick response to the clarifying questions: > > > > > > > > > > > > > > >The security consideration section is not yet sufficient. > > > > > >It should have said: > > > > > >The security consideration section is not yet sufficient. If > > there is > > >an effective attack here, we need text that explores it. If there > > isn't, > > >we need text that argues it isn't. > > > > Ok, I'll look into that. > > > > ------------------- > > > > > > >Bottom of page 3, next to last paragraph, > > > > > > > > >This sentence: > > > When SIP entities upstream receive the non-2xx > > > final response they will release resources associated with the > > > session, and the UAC will terminate the session setup. > > >is assuming the final response wasn't something the UAC > > could react to > > >by trying again with some related changes (like responding to a > > 401/407). > > > > Ok, now I got it. > > > > So, I guess the text should say something like: > > > > "When SIP entities upstream receive the non-2xx final > > response they will normally release resources associated with > > the session, and the UAC will terminate the session setup, > > unless the final response (e.g. a 401/407 final response) > > triggers a new session setup request to be sent." > > > > > > Regards, > > > > Christer > > > > > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Nov 23 04:45:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D976928C0E7 for ; Mon, 23 Nov 2009 04:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm5-OACZK3rz for ; Mon, 23 Nov 2009 04:45:41 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2BC8228C0DB for ; Mon, 23 Nov 2009 04:45:40 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-db-4b0a83ef03be Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 09.EC.04191.FE38A0B4; Mon, 23 Nov 2009 13:45:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:45:35 +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: Mon, 23 Nov 2009 13:45:31 +0100 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613FE51A270@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM/EzyUg4F5md1Trejk8QBtAWnlgAsjyIQB6GO31AAAI01UAAA6WEg References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com><0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com> <747A6506A991724FB09B129B79D5FEB613FE51A270@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" X-OriginalArrivalTime: 23 Nov 2009 12:45:35.0398 (UTC) FILETIME=[D9F33C60:01CA6C3A] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:45:42 -0000 Hi,=20 >BYE from called party is not allowed for terminating an early=20 >dialog. If I recall the rfc3261 text correctly, it actually=20 >requires the ACK (or INVITE 2xx timeout) before called party=20 >can send BYE. >=20 >Since the BYE would be treated as an abnormal situation (BYE=20 >race condition with INVITE 2xx), the outcomes might be=20 >different. Thus I don't think the second paragraph of the=20 >proposed text is accurate. Yes, you are probably right. In that case the second paragraph should of course be removed, and the text should indicate (as it did previously) that it does allow a new kind of attack. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: Monday, November 23, 2009 7:13 AM > > To: Robert Sparks > > Cc: draft-ietf-sipcore-199@tools.ietf.org;=20 > sipcore@ietf.org; sipcore-=20 > > chairs@tools.ietf.org > > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 > >=20 > >=20 > > Hi Robert, > >=20 > > I've been thinking about the security consideration section=20 > of the 199. > > I do not think 199 introduces a new attack, because if a middle-man=20 > > can send 199 he can probably also send a BYE. > >=20 > > Below is some suggested text: > >=20 > > "12. Security Considerations > >=20 > > General security issues related to SIP responses are described in > > [RFC3261]. Due to the nature of the 199 response, it may be > > attractive to use it for launching attacks in order to terminate > > specific early dialogs (other early dialogs will not be=20 > affected). > > In addition, if a man-in-the-middle sends a 199 response to the=20 > > UAC, which terminates > > a specific dialog, it can take a while until the UAS=20 > finds out that=20 > > the > > UAC, and possbile stateful intermediates, have terminated the=20 > > dialog. > >=20 > > However, the same kind of attack can be performed if a=20 > > man-in-the-middle sends a > > BYE request towards the UAC. The UAC will terminate the=20 > dialog for=20 > > which the BYE > > request is sent, but it can take a while until the UAS finds out=20 > > that the dialog has > > been termianted. SIP security mechanisms (e.g.=20 > hop-to-hop TLS) can=20 > > be used to minimize, > > or eliminate, the risk for such attacks." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 15. lokakuuta 2009 18:53 > > > To: Robert Sparks > > > Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org;=20 > > > sipcore-chairs@tools.ietf.org > > > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 > > > > > > Hi, > > > > > > >Quick response to the clarifying questions: > > > > > > > > > > > > > > > > > > > >The security consideration section is not yet sufficient. > > > > > > > >It should have said: > > > > > > > >The security consideration section is not yet sufficient. If > > > there is > > > >an effective attack here, we need text that explores=20 > it. If there > > > isn't, > > > >we need text that argues it isn't. > > > > > > Ok, I'll look into that. > > > > > > ------------------- > > > > > > > > > >Bottom of page 3, next to last paragraph, > > > > > > > > > > > >This sentence: > > > > When SIP entities upstream receive the non-2xx > > > > final response they will release resources associated with the > > > > session, and the UAC will terminate the session setup. > > > >is assuming the final response wasn't something the UAC > > > could react to > > > >by trying again with some related changes (like responding to a > > > 401/407). > > > > > > Ok, now I got it. > > > > > > So, I guess the text should say something like: > > > > > > "When SIP entities upstream receive the non-2xx final=20 > response they=20 > > > will normally release resources associated with the=20 > session, and the=20 > > > UAC will terminate the session setup, unless the final response=20 > > > (e.g. a 401/407 final response) triggers a new session=20 > setup request=20 > > > to be sent." > > > > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Mon Nov 23 06:10:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CDB3A6A78 for ; Mon, 23 Nov 2009 06:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMmujK7utE52 for ; Mon, 23 Nov 2009 06:10:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D6A9928C156 for ; Mon, 23 Nov 2009 06:10:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGAM0mCktAZnwM/2dsb2JhbACZLKURlmSEPAQ X-IronPort-AV: E=Sophos;i="4.47,272,1257120000"; d="scan'208";a="69765933" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Nov 2009 14:09:59 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANE9xx2019335; Mon, 23 Nov 2009 14:09:59 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:09:59 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 09:09:58 -0500 Message-ID: <4B0A97B6.8050902@cisco.com> Date: Mon, 23 Nov 2009 09:09:58 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Harhit Tam References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2009 14:09:58.0974 (UTC) FILETIME=[A4139DE0:01CA6C46] Cc: sipcore@ietf.org Subject: Re: [sipcore] e2e sip question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:10:05 -0000 Harhit Tam wrote: > Thanks. So, the To: and From: fields that normally carry a SIP URI, > can be empty? Note that both Alice and Bob have DNS names and no SIP URIs. > You may not have empty from and to, but you could use: To: sip:bob.domain.org From: sip:alice.domain.org Thanks, Paul > When Alice calls Bob, how can he know who is calling? By looking at the > contact field of the incoming request? > > Thanks for your time! > > Regards. > > Harhit > > > On Fri, Nov 20, 2009 at 8:12 PM, James M. Polk > wrote: > > At 09:04 AM 11/20/2009, Harhit Tam wrote: > > Hi all, > > Can we use e2e SIP (without proxies) using only the > destination's DNS name? > > That is Bob's phone has a DNS name bob.domain.org > , and Alice would like > > to make a call to that DNS name directly without using a SIP URI > in the form > of an e-mail address. > > How can we use SIP in this way? > > > Does Alice's UA know the IP address of Bob's UA? > > If yes, then this is all that's needed for point to point > communication using SIP. > > If no, the DNS name needs to be resolved to an IP address somehow > (i.e., by some entity) to direct the packet towards Bob's UA. > > James > > > Thank you in advance. > > Regards. > > Harhit > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From root@core3.amsl.com Mon Nov 23 13:15:07 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6529F28C1AA; Mon, 23 Nov 2009 13:15:04 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091123211506.6529F28C1AA@core3.amsl.com> Date: Mon, 23 Nov 2009 13:15:04 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:15:10 -0000 --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 Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-01.txt Pages : 61 Date : 2009-11-23 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-sec-flows-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-23130728.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Mon Nov 23 18:47:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951AF3A69D7 for ; Mon, 23 Nov 2009 18:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fC8ga2oJ055 for ; Mon, 23 Nov 2009 18:47:05 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id CFA3A28C0F7 for ; Mon, 23 Nov 2009 18:47:05 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:43939 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S81249AbZKXCrB (ORCPT ); Mon, 23 Nov 2009 20:47:01 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 20:47:01 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 24 Nov 2009 10:46:58 +0800 From: "Thomson, Martin" To: Paul Kyzivat , Brian Rosen Date: Tue, 24 Nov 2009 10:47:39 +0800 Thread-Topic: [sipcore] Does SIP Presence imply Geolocation? Thread-Index: Acpm0Za9gPMVG4ZhQ2qcXeytcgQBuAF3naOw Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648ED0D@SISPE7MB1.commscope.com> References: <4B016FCF.1080108@cisco.com> In-Reply-To: <4B016FCF.1080108@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:47:06 -0000 KE5vdCB3YW50aW5nIHRvIGludm9rZSB0aGUgbmVjcm9tYW50aWMgYXJ0cywgYnV0IHRoaXMgd2Fy cmFudGVkIGNsYXJpZmljYXRpb24uKQ0KDQo+IElJVUMsIGRvaW5nIHNvIHdvdWxkIGFzc2VydCB0 aGF0IHRoZQ0KPiBsb2NhdGlvbiB0aGVyZSBpcyB0aGUgbG9jYXRpb24gb2YgKm5vdGlmaWVyKiwg bm90IHRoZSBwcmVzZW50aXR5Lg0KPiBSaWdodD8NCg0KVGhlIHByZXNlbnRpdHkgaWRlbnRpZmll ciBpbiB0aGUgcmVmZXJlbmNlZCBQSURGLUxPIGRvY3VtZW50IHdvdWxkIGlkZW50aWZ5IHRoZSBz dWJqZWN0LiAgV2UgZGlzY3Vzc2VkIHRoaXMgYXQgc29tZSBsZW5ndGggaW4gU3RvY2tob2xtIChw cml2YXRlbHkpIGFuZCB0aGVyZSB3YXMgYSBnZW5lcmFsIHZpZXcgdGhhdCB3ZSB3b3VsZG4ndCBi ZSBzcGVjaWZ5aW5nIGFueSByZWxhdGlvbnNoaXAgdG8gdGhlIGVudGl0aWVzIGluIFNJUCBzaWdu YWxsaW5nLg0KDQpJIGtub3csIHRoYXQncyBhIGJpdCB3ZWFrLCBidXQgdGhhdCdzIGxhcmdlbHkg aW50ZW50aW9uYWwuICBCcmlhbiBhbmQgSmFtZXMgd2VyZSBib3RoIGludm9sdmVkLCBzbyB0aGV5 IG1heSBwcm92aWRlIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbi4NCg0KQ2hlZXJzLA0KLS1NYXJ0aW4N Cg0KKEZvciB0aGUgcmVjb3JkLCBJIHNpZGUgd2l0aCBCcmlhbidzIGludGVycHJldGF0aW9uLikN Cg0KDQo= From Martin.Thomson@andrew.com Mon Nov 23 18:50:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E756A28C1D5 for ; Mon, 23 Nov 2009 18:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq9rJZSVjNQP for ; Mon, 23 Nov 2009 18:50:09 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 9DBEC28C1DA for ; Mon, 23 Nov 2009 18:50:09 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:63651 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S81239AbZKXCuF (ORCPT ); Mon, 23 Nov 2009 20:50:05 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 20:50:05 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 24 Nov 2009 10:50:03 +0800 From: "Thomson, Martin" To: Brian Rosen , James Polk , "sipcore@ietf.org" Date: Tue, 24 Nov 2009 10:50:43 +0800 Thread-Topic: [sipcore] Inequalities for filters Thread-Index: Acpkn41/rIVlnm5wHEKv+jxXSUz3NwIEQnOw Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648ED11@SISPE7MB1.commscope.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:50:11 -0000 SSBkb24ndCB0aGluayB0aGF0IEphbWVzJyB1bmRlcnN0YW5kaW5nIGlzIHF1aXRlIGNvcnJlY3Qu DQoNClRoZSBsYXN0IG5vdGlmaWNhdGlvbiBzZWVuIGJ5IHRoZSB3YXRjaGVyIGRldGVybWluZXMg dGhlIGJhc2VsaW5lIGZvciBub3RpZmljYXRpb25zLiAgU28sIGlmIHRoZSAzbSwgNm0sIDltIGFu ZCA5OW0gbm90aWZpY2F0aW9ucyB3ZXJlIHN1cHByZXNzZWQsIHRoZSBzdWJzZXF1ZW50IDEwMG0g bm90aWZpY2F0aW9uIHdvbnQgYmUuDQoNCi0tTWFydGluDQoNCnAucy4gV2FzIHRoaXMgdGhlIGNv cnJlY3QgZ3JvdXAgdG8gZGlzY3VzcyB0aGlzIHRvcGljPyAgU0lNUExFIG9yIEdFT1BSSVYgc2Vl bSBtb3JlIGFwcHJvcHJpYXRlLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4gU2VudDogU2F0dXJkYXksIDE0 IE5vdmVtYmVyIDIwMDkgNzoyNiBBTQ0KPiBUbzogSmFtZXMgUG9sazsgc2lwY29yZUBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEluZXF1YWxpdGllcyBmb3IgZmlsdGVycw0KPiAN Cj4gSSBiZWxpZXZlIG9uZSBoYXMgdG8gYmUgcmVhc29uYWJsZS4NCj4gDQo+IElmIHRoZSB0YXJn ZXQgaXMgbW92aW5nIHNsb3dseSwgYW5kIHRoZSBmaWx0ZXIgZG9lc24ndCBnZXQgY2hhbmdlZCwN Cj4gdGhlbg0KPiB5ZXMuDQo+IA0KPiBJZiB0aGUgbWVjaGFuaXNtcyBpbiB0aGUgZGV2aWNlIGRv bid0IHJlYWN0IGZhc3QsIGFuZCB0aGUgdGFyZ2V0IGlzDQo+IG1vdmluZw0KPiBxdWlja2x5LCB5 b3UgbWF5IG5vdCBnZXQgaW50ZXJtZWRpYXRlIHJlcG9ydHMuICBZb3UgY2VydGFpbmx5IHNob3Vs ZG4ndA0KPiBnZXQNCj4gbW9yZSB0aGFuIG9uZSBvdXRzdGFuZGluZyBOT1RJRlkgb3ZlciB0aGlz IGtpbmQgb2YgZmlsdGVyLg0KPiANCj4gVGhlIHJlY2lwaWVudCBjYW4gY29udHJvbCB0aGUgcmF0 ZSBvZiBub3RpZmljYXRpb24gd2l0aCB0aGUgcmF0ZQ0KPiBjb250cm9sDQo+IGZpbHRlcnMsIHNv IGlmIGl0IGRvZXNuJ3Qgd2FudCB0byBiZSBpbnVuZGF0ZWQsIGl0IGNhbiBjb250cm9sIGl0Lg0K PiANCj4gV2hpbGUgd2UgaGF2ZSBzcGVlZCwgd2UgZG9uJ3QgaGF2ZSBhY2NlbGVyYXRpb24sIGFu ZCBJJ20gbm90IGludGVyZXN0ZWQNCj4gaW4NCj4gYWRkaW5nIGl0Lg0KPiANCj4gQnJpYW4NCj4g DQo+IA0KPiBPbiAxMS8xMy8wOSAzOjEwIFBNLCAiSmFtZXMgUG9sayIgPGptcG9sa0BjaXNjby5j b20+IHdyb3RlOg0KPiANCj4gPiBBbG9uZyB0aGlzIHRvcGljLCBhbmQgd2hhdCB3YXMgZGlzY3Vz c2VkIGluIG15IHJldmlldyBvZiB0aGUNCj4gPiBsb2MtZmlsdGVycy0wNyBJRCwgaXMgd2hhdCBo YXBwZW5zIGlmIGEgdGFyZ2V0IG1vdmVzIGJ5IGEgZml4ZWQNCj4gPiBhbW91bnQgKGkuZS4sIGl0 IGhhcyBjaGFuZ2VkIGxvY2F0aW9ucyBieSB0aGUgcHJlc2V0IG51bWJlciBvZg0KPiA+IG1ldGVy cykuICBUaGUgZXhhbXBsZSBpcyBpZiBhIHRhcmdldCBtb3ZlcyBieSAzIG1ldGVycyBzaW5jZSB0 aGUgbGFzdA0KPiA+IG5vdGlmaWNhdGlvbiwgc2VuZCBhIG5ldyBub3RpZmljYXRpb24gb2YgdGhp cyBtb3ZlbWVudC4NCj4gPg0KPiA+IFRoaXMgbGVhZCB0byB0aGUgaWRlYSBvZiBhIHRhcmdldCBt b3ZpbmcgbXVjaCBtb3JlIHRoYW4gM20sIGJ1dCBieSwNCj4gPiBzYXksIDEwMG0uICBEb2VzIGEg bm90aWZpY2F0aW9uIG5vdyBnZXQgc2VudCBhdCAzbS4gNm0sIDltLCAxMm0gLi4uDQo+ID4gOTlt LCBidXQgbm90IHRoZSBsYXN0IDFtLCBiZWNhdXNlIGl0IGhhc24ndCByZWFjdGVkIHRoZSB0aHJl c2hvbGQgb2YNCj4gPiAzbSBpbmNyZW1lbnRzLg0KPiA+DQo+ID4gVGhpcyBsZWFkIHRvIHRoZSBp ZGVhIHRoYXQgcGVyaGFwcyB0aGlzIHRhcmdldCBpcyBhY2NlbGVyYXRpbmcuIElzDQo+ID4gdGhp cyBvZiB2YWx1ZSwgYW5kIHNob3VsZCB0aGlzIGJlIGRldGVybWluZWQgYnkgdGhlIHRhcmdldCAo d2hpY2gNCj4gPiBzZW5zZXMgb3IgaXMgdG9sZCB3aGljaCBpbmNyZW1lbnQgaXMgaGFzIG1vdmVk KSBvciBkZXRlcm1pbmVkIGJ5DQo+ID4gY2FsY3VsYXRpb24gYnkgdGhlIHJlY2lwaWVudCB0aGF0 IHRoZSB0YXJnZXQgaXMgbW92aW5nIGF0IGEgZmFzdGVyIG9yDQo+ID4gc2xvd2VyIHBhY2Ugb3Ig c3BlZWQuDQo+ID4NCj4gPiBUaGlzIGlzIG5vdCBleGFjdGx5IGEgc2xpcHBlcnkgc2xvcGUgb2Yg bmV3IHRoaW5ncyB0byB0cmFjaywgYnV0IGl0DQo+ID4gaXNuJ3QgYSBzaW5nbGUgdmFsdWUgSU1P IGVpdGhlci4NCj4gPg0KPiA+IEphbWVzDQo+ID4NCj4gPiBBdCAwMToyOCBQTSAxMS8xMy8yMDA5 LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4gPj4gVGhlIGN1cnJlbnQgZmlsdGVyIHNwZWNzIGFsbG93 ICJjaGFuZ2VkIGJ5IiBzZW1hbnRpY3MsIGEgZGVsdGEgb24NCj4gdGhlIGxhc3QNCj4gPj4gdmFs dWUuICBJbiBsb2NhdGlvbiwgd2UgcmFuIGFjcm9zcyB0aGUgbmVlZCB0byBrbm93IHdoZW4gc3Bl ZWQgd2FzDQo+IGV4Y2VlZGVkDQo+ID4+IGJ5IHNvbWUgdmFsdWUuICBUaGlzIGlzIG5vdCBhIGRl bHRhLCBpdCdzIGEgY29tcGFyaXNvbiBhZ2FpbnN0IGENCj4gZml4ZWQNCj4gPj4gcXVhbnRpdHku DQo+ID4+DQo+ID4+IFdoYXQgaXMgdGhlIGFwcGV0aXRlIG9mIHRoZSB3b3JrIGdyb3VwIHRvIGFk ZCBhIGdlbmVyYWxpemVkDQo+IGluZXF1YWxpdHksDQo+ID4+IGJhc2VkIG9uIHRoZSBiYXNpYyAi Y2hhbmdlZCBieSIgc3ludGF4LCB0aGF0IGNvdmVycyB0aGUgb2J2aW91cw0KPiBncmVhdGVyDQo+ ID4+IHRoYW4sIGxlc3MgdGhhbiwgZXF1YWxzLCBub3QgZXF1YWxzLCBncmVhdGVyIHRoYW4gb3Ig ZXF1YWwgdG8uLi4/DQo+IFlvdSBnZXQgYQ0KPiA+PiBub3RpZnkgd2hlbiB0aGUgY29uZGl0aW9u IGlzIG1ldC4NCj4gPj4NCj4gPj4gVGhpcyB3b3VsZCBiZSBhIHNob3J0IGRyYWZ0Lg0KPiA+Pg0K PiA+PiBCcmlhbg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZQ0KPiA+DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg0K From Martin.Thomson@andrew.com Mon Nov 23 18:51:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1047928C1DA for ; Mon, 23 Nov 2009 18:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNuJiFXD17kq for ; Mon, 23 Nov 2009 18:51:49 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 4C7BD28C1D5 for ; Mon, 23 Nov 2009 18:51:49 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:5540 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S5375643AbZKXCvp (ORCPT ); Mon, 23 Nov 2009 20:51:45 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 23 Nov 2009 20:51:44 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 24 Nov 2009 10:51:42 +0800 From: "Thomson, Martin" To: Brian Rosen , "sipcore@ietf.org" Date: Tue, 24 Nov 2009 10:52:22 +0800 Thread-Topic: Inequalities for filters Thread-Index: Acpkl4btAPPiBrnU80CBl2hS17JzFgIGYjUg Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648ED13@SISPE7MB1.commscope.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:51:50 -0000 SSdkIGJlIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRoaXMgd29yayBnbyBhaGVhZC4NCg0KV291bGQg U0lNUExFIGJlIGEgYmV0dGVyIGZvcnVtIHRoYW4gU0lQQ09SRT8NCg0KLS1NYXJ0aW4NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBCcmlh biBSb3Nlbg0KPiBTZW50OiBTYXR1cmRheSwgMTQgTm92ZW1iZXIgMjAwOSA2OjI5IEFNDQo+IFRv OiBzaXBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtzaXBjb3JlXSBJbmVxdWFsaXRpZXMgZm9y IGZpbHRlcnMNCj4gDQo+IFRoZSBjdXJyZW50IGZpbHRlciBzcGVjcyBhbGxvdyAiY2hhbmdlZCBi eSIgc2VtYW50aWNzLCBhIGRlbHRhIG9uIHRoZQ0KPiBsYXN0DQo+IHZhbHVlLiAgSW4gbG9jYXRp b24sIHdlIHJhbiBhY3Jvc3MgdGhlIG5lZWQgdG8ga25vdyB3aGVuIHNwZWVkIHdhcw0KPiBleGNl ZWRlZA0KPiBieSBzb21lIHZhbHVlLiAgVGhpcyBpcyBub3QgYSBkZWx0YSwgaXQncyBhIGNvbXBh cmlzb24gYWdhaW5zdCBhIGZpeGVkDQo+IHF1YW50aXR5Lg0KPiANCj4gV2hhdCBpcyB0aGUgYXBw ZXRpdGUgb2YgdGhlIHdvcmsgZ3JvdXAgdG8gYWRkIGEgZ2VuZXJhbGl6ZWQgaW5lcXVhbGl0eSwN Cj4gYmFzZWQgb24gdGhlIGJhc2ljICJjaGFuZ2VkIGJ5IiBzeW50YXgsIHRoYXQgY292ZXJzIHRo ZSBvYnZpb3VzIGdyZWF0ZXINCj4gdGhhbiwgbGVzcyB0aGFuLCBlcXVhbHMsIG5vdCBlcXVhbHMs IGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0by4uLj8gIFlvdQ0KPiBnZXQgYQ0KPiBub3RpZnkgd2hl biB0aGUgY29uZGl0aW9uIGlzIG1ldC4NCj4gDQo+IFRoaXMgd291bGQgYmUgYSBzaG9ydCBkcmFm dC4NCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQoNCg== From jmpolk@cisco.com Mon Nov 23 22:38:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897593A6B36 for ; Mon, 23 Nov 2009 22:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWKzaDjxBOza for ; Mon, 23 Nov 2009 22:38:58 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5AC243A6A2A for ; Mon, 23 Nov 2009 22:38:58 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAI4OC0urRN+K/2dsb2JhbACHbbYml26EPAQ X-IronPort-AV: E=Sophos;i="4.47,276,1257120000"; d="scan'208";a="53228149" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2009 06:38:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAO6criC002144; Tue, 24 Nov 2009 06:38:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 22:38:53 -0800 Received: from jmpolk-wxp01.cisco.com ([10.21.95.102]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 22:38:52 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Nov 2009 00:38:44 -0600 To: "Thomson, Martin" , Brian Rosen , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D648ED11@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F01D648ED11@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Nov 2009 06:38:52.0799 (UTC) FILETIME=[C9CAD0F0:01CA6CD0] Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:38:59 -0000 At 08:50 PM 11/23/2009, Thomson, Martin wrote: >I don't think that James' understanding is quite correct. although I'm missing a few question marks at the end of obvious questions - I was probing for answers, not stating anything. >The last notification seen by the watcher determines the baseline >for notifications. So, if the 3m, 6m, 9m and 99m notifications were >suppressed, the subsequent 100m notification wont be. Let me try this again -- if the changed-by is set to look for increments of 3m, and a target is moving a 3mps, then there should be a NOFITY sent every second by the notifier, right? However, there is something to this -- the subscriber will get inundated with NOTIFYs. What if the notifier is accelerating? This is useful information to have IMO (i.e., that the delta is occurring more frequent). This will lead to more inundation. Is it important for the notifier to determine this, or the subscriber? Is there a timestamp of when each NOTIFY is sent for a subscriber to accurately determine this information? >--Martin > >p.s. Was this the correct group to discuss this topic? SIMPLE or >GEOPRIV seem more appropriate. I do not believe Geopriv has the expertise for this, as they do not regularly deal with SIP signaling (save for a few in the WG). This is tied to SIPCORE's Location Conveyance ID, as it's primary use case is for dereferencing a location URI. James > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Brian Rosen > > Sent: Saturday, 14 November 2009 7:26 AM > > To: James Polk; sipcore@ietf.org > > Subject: Re: [sipcore] Inequalities for filters > > > > I believe one has to be reasonable. > > > > If the target is moving slowly, and the filter doesn't get changed, > > then > > yes. > > > > If the mechanisms in the device don't react fast, and the target is > > moving > > quickly, you may not get intermediate reports. You certainly shouldn't > > get > > more than one outstanding NOTIFY over this kind of filter. > > > > The recipient can control the rate of notification with the rate > > control > > filters, so if it doesn't want to be inundated, it can control it. > > > > While we have speed, we don't have acceleration, and I'm not interested > > in > > adding it. > > > > Brian > > > > > > On 11/13/09 3:10 PM, "James Polk" wrote: > > > > > Along this topic, and what was discussed in my review of the > > > loc-filters-07 ID, is what happens if a target moves by a fixed > > > amount (i.e., it has changed locations by the preset number of > > > meters). The example is if a target moves by 3 meters since the last > > > notification, send a new notification of this movement. > > > > > > This lead to the idea of a target moving much more than 3m, but by, > > > say, 100m. Does a notification now get sent at 3m. 6m, 9m, 12m ... > > > 99m, but not the last 1m, because it hasn't reacted the threshold of > > > 3m increments. > > > > > > This lead to the idea that perhaps this target is accelerating. Is > > > this of value, and should this be determined by the target (which > > > senses or is told which increment is has moved) or determined by > > > calculation by the recipient that the target is moving at a faster or > > > slower pace or speed. > > > > > > This is not exactly a slippery slope of new things to track, but it > > > isn't a single value IMO either. > > > > > > James > > > > > > At 01:28 PM 11/13/2009, Brian Rosen wrote: > > >> The current filter specs allow "changed by" semantics, a delta on > > the last > > >> value. In location, we ran across the need to know when speed was > > exceeded > > >> by some value. This is not a delta, it's a comparison against a > > fixed > > >> quantity. > > >> > > >> What is the appetite of the work group to add a generalized > > inequality, > > >> based on the basic "changed by" syntax, that covers the obvious > > greater > > >> than, less than, equals, not equals, greater than or equal to...? > > You get a > > >> notify when the condition is met. > > >> > > >> This would be a short draft. > > >> > > >> Brian > > >> > > >> > > >> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Nov 24 00:00:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610BE3A6A04 for ; Tue, 24 Nov 2009 00:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAnsewsZ-MCY for ; Tue, 24 Nov 2009 00:00:50 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B704228C200 for ; Tue, 24 Nov 2009 00:00:49 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-e8-4b0b92ac89ad Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 36.69.06698.CA29B0B4; Tue, 24 Nov 2009 09:00:44 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:00:44 +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: Tue, 24 Nov 2009 09:00:43 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM/EzyUg4F5md1Trejk8QBtAWnlgAsjyIQB6GO31AAAI01UAAA6WEgAChR/XA= References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com><0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com><747A6506A991724FB09B129B79D5FEB613FE51A270@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Robert Sparks" X-OriginalArrivalTime: 24 Nov 2009 08:00:44.0048 (UTC) FILETIME=[391FF100:01CA6CDC] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 08:00:51 -0000 Hi, A new version of the suggested text: "12. Security Considerations General security issues related to SIP responses are described in [RFC3261]. Due to the nature of the 199 response, it may be attractive to use it for launching attacks in order to terminate specific early dialogs (other early dialogs will not be affected).=20 In addition, if a man-in-the-middle sends a 199 response to the UAC, which terminates=20 a specific dialog, it can take a while until the UAS finds out that the=20 UAC, and possbile stateful intermediates, have terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) can be used to minimize,=20 or eliminate, the risk for such attacks." Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 23. marraskuuta 2009 14:46 To: Brett Tate Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org; sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 Hi,=20 >BYE from called party is not allowed for terminating an early dialog. =20 >If I recall the rfc3261 text correctly, it actually requires the ACK=20 >(or INVITE 2xx timeout) before called party can send BYE. >=20 >Since the BYE would be treated as an abnormal situation (BYE race=20 >condition with INVITE 2xx), the outcomes might be different. Thus I=20 >don't think the second paragraph of the proposed text is accurate. Yes, you are probably right. In that case the second paragraph should of course be removed, and the text should indicate (as it did previously) that it does allow a new kind of attack. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: Monday, November 23, 2009 7:13 AM > > To: Robert Sparks > > Cc: draft-ietf-sipcore-199@tools.ietf.org; > sipcore@ietf.org; sipcore- > > chairs@tools.ietf.org > > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 > >=20 > >=20 > > Hi Robert, > >=20 > > I've been thinking about the security consideration section > of the 199. > > I do not think 199 introduces a new attack, because if a middle-man=20 > > can send 199 he can probably also send a BYE. > >=20 > > Below is some suggested text: > >=20 > > "12. Security Considerations > >=20 > > General security issues related to SIP responses are described in > > [RFC3261]. Due to the nature of the 199 response, it may be > > attractive to use it for launching attacks in order to terminate > > specific early dialogs (other early dialogs will not be > affected). > > In addition, if a man-in-the-middle sends a 199 response to the=20 > > UAC, which terminates > > a specific dialog, it can take a while until the UAS > finds out that > > the > > UAC, and possbile stateful intermediates, have terminated the=20 > > dialog. > >=20 > > However, the same kind of attack can be performed if a=20 > > man-in-the-middle sends a > > BYE request towards the UAC. The UAC will terminate the > dialog for > > which the BYE > > request is sent, but it can take a while until the UAS finds out=20 > > that the dialog has > > been termianted. SIP security mechanisms (e.g.=20 > hop-to-hop TLS) can > > be used to minimize, > > or eliminate, the risk for such attacks." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 15. lokakuuta 2009 18:53 > > > To: Robert Sparks > > > Cc: draft-ietf-sipcore-199@tools.ietf.org; sipcore@ietf.org;=20 > > > sipcore-chairs@tools.ietf.org > > > Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 > > > > > > Hi, > > > > > > >Quick response to the clarifying questions: > > > > > > > > > > > > > > > > > > > >The security consideration section is not yet sufficient. > > > > > > > >It should have said: > > > > > > > >The security consideration section is not yet sufficient. If > > > there is > > > >an effective attack here, we need text that explores > it. If there > > > isn't, > > > >we need text that argues it isn't. > > > > > > Ok, I'll look into that. > > > > > > ------------------- > > > > > > > > > >Bottom of page 3, next to last paragraph, > > > > > > > > > > > >This sentence: > > > > When SIP entities upstream receive the non-2xx > > > > final response they will release resources associated with the > > > > session, and the UAC will terminate the session setup. > > > >is assuming the final response wasn't something the UAC > > > could react to > > > >by trying again with some related changes (like responding to a > > > 401/407). > > > > > > Ok, now I got it. > > > > > > So, I guess the text should say something like: > > > > > > "When SIP entities upstream receive the non-2xx final > response they > > > will normally release resources associated with the > session, and the > > > UAC will terminate the session setup, unless the final response=20 > > > (e.g. a 401/407 final response) triggers a new session > setup request > > > to be sent." > > > > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From br@brianrosen.net Tue Nov 24 06:01:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87C23A6A72 for ; Tue, 24 Nov 2009 06:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2EE65J4N7hr for ; Tue, 24 Nov 2009 06:01:04 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E554D3A6A3E for ; Tue, 24 Nov 2009 06:01:03 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1NCvwm-00041K-Rq; Tue, 24 Nov 2009 08:00:49 -0600 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 24 Nov 2009 09:00:49 -0500 From: Brian Rosen To: James Polk , "Thomson, Martin" , "sipcore@ietf.org" Message-ID: Thread-Topic: [sipcore] Inequalities for filters Thread-Index: AcptDoatQk2ts38cz0qA26oEEDpRMA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:01:05 -0000 You use rate control to adjust the rate of notifies if you want to have a very small changed-by in a device that moves fast. Brian On 11/24/09 1:38 AM, "James Polk" wrote: > At 08:50 PM 11/23/2009, Thomson, Martin wrote: >> I don't think that James' understanding is quite correct. > > although I'm missing a few question marks at the end of obvious > questions - I was probing for answers, not stating anything. > > >> The last notification seen by the watcher determines the baseline >> for notifications. So, if the 3m, 6m, 9m and 99m notifications were >> suppressed, the subsequent 100m notification wont be. > > Let me try this again -- if the changed-by is set to look for > increments of 3m, and a target is moving a 3mps, then there should be > a NOFITY sent every second by the notifier, right? > > However, there is something to this -- the subscriber will get > inundated with NOTIFYs. > > What if the notifier is accelerating? > > This is useful information to have IMO (i.e., that the delta is > occurring more frequent). This will lead to more inundation. > > Is it important for the notifier to determine this, or the subscriber? > > Is there a timestamp of when each NOTIFY is sent for a subscriber to > accurately determine this information? > > >> --Martin >> >> p.s. Was this the correct group to discuss this topic? SIMPLE or >> GEOPRIV seem more appropriate. > > I do not believe Geopriv has the expertise for this, as they do not > regularly deal with SIP signaling (save for a few in the WG). > > This is tied to SIPCORE's Location Conveyance ID, as it's primary use > case is for dereferencing a location URI. > > James > > > >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Brian Rosen >>> Sent: Saturday, 14 November 2009 7:26 AM >>> To: James Polk; sipcore@ietf.org >>> Subject: Re: [sipcore] Inequalities for filters >>> >>> I believe one has to be reasonable. >>> >>> If the target is moving slowly, and the filter doesn't get changed, >>> then >>> yes. >>> >>> If the mechanisms in the device don't react fast, and the target is >>> moving >>> quickly, you may not get intermediate reports. You certainly shouldn't >>> get >>> more than one outstanding NOTIFY over this kind of filter. >>> >>> The recipient can control the rate of notification with the rate >>> control >>> filters, so if it doesn't want to be inundated, it can control it. >>> >>> While we have speed, we don't have acceleration, and I'm not interested >>> in >>> adding it. >>> >>> Brian >>> >>> >>> On 11/13/09 3:10 PM, "James Polk" wrote: >>> >>>> Along this topic, and what was discussed in my review of the >>>> loc-filters-07 ID, is what happens if a target moves by a fixed >>>> amount (i.e., it has changed locations by the preset number of >>>> meters). The example is if a target moves by 3 meters since the last >>>> notification, send a new notification of this movement. >>>> >>>> This lead to the idea of a target moving much more than 3m, but by, >>>> say, 100m. Does a notification now get sent at 3m. 6m, 9m, 12m ... >>>> 99m, but not the last 1m, because it hasn't reacted the threshold of >>>> 3m increments. >>>> >>>> This lead to the idea that perhaps this target is accelerating. Is >>>> this of value, and should this be determined by the target (which >>>> senses or is told which increment is has moved) or determined by >>>> calculation by the recipient that the target is moving at a faster or >>>> slower pace or speed. >>>> >>>> This is not exactly a slippery slope of new things to track, but it >>>> isn't a single value IMO either. >>>> >>>> James >>>> >>>> At 01:28 PM 11/13/2009, Brian Rosen wrote: >>>>> The current filter specs allow "changed by" semantics, a delta on >>> the last >>>>> value. In location, we ran across the need to know when speed was >>> exceeded >>>>> by some value. This is not a delta, it's a comparison against a >>> fixed >>>>> quantity. >>>>> >>>>> What is the appetite of the work group to add a generalized >>> inequality, >>>>> based on the basic "changed by" syntax, that covers the obvious >>> greater >>>>> than, less than, equals, not equals, greater than or equal to...? >>> You get a >>>>> notify when the condition is met. >>>>> >>>>> This would be a short draft. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Tue Nov 24 06:07:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFF73A67F2 for ; Tue, 24 Nov 2009 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPI7ATEDpbzj for ; Tue, 24 Nov 2009 06:07:41 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0AC803A67FD for ; Tue, 24 Nov 2009 06:07:40 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAFN3C0tAZnwN/2dsb2JhbACERJRwpw2HDZB5gS+BAwGBMVUEjTs X-IronPort-AV: E=Sophos;i="4.47,279,1257120000"; d="scan'208";a="70020262" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Nov 2009 14:07:36 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAOE7aa1012831; Tue, 24 Nov 2009 14:07:36 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:07:36 -0500 Received: from [10.86.241.179] ([10.86.241.179]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:07:35 -0500 Message-ID: <4B0BE8A6.9010409@cisco.com> Date: Tue, 24 Nov 2009 09:07:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomson, Martin" References: <4B016FCF.1080108@cisco.com> <8B0A9FCBB9832F43971E38010638454F01D648ED0D@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D648ED0D@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2009 14:07:35.0974 (UTC) FILETIME=[79414C60:01CA6D0F] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Does SIP Presence imply Geolocation? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:07:42 -0000 Thomson, Martin wrote: > (Not wanting to invoke the necromantic arts, but this warranted clarification.) > >> IIUC, doing so would assert that the >> location there is the location of *notifier*, not the presentity. >> Right? > > The presentity identifier in the referenced PIDF-LO document would identify the subject. We discussed this at some length in Stockholm (privately) and there was a general view that we wouldn't be specifying any relationship to the entities in SIP signalling. > > I know, that's a bit weak, but that's largely intentional. Brian and James were both involved, so they may provide further clarification. I'm sure you guys are more informed of this than I am, so I will defer. But if the geolocation header simply says: "here is a location - who its the location *of* is included in the location body", rather than "here is the location of the sender of this message", then what is a proxy that want to route by location (say for 911) to do if the identity of the presentity in the location info doesn't match that of the caller? Should it ignore it for routing purposes? (That of course isn't relevant to the case where this came up. A geolocation in a presence notify couldn't be used to route the request, since it is in-dialog.) From brian@estacado.net Tue Nov 24 13:27:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4BE3A6819 for ; Tue, 24 Nov 2009 13:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwNXKMS3ncii for ; Tue, 24 Nov 2009 13:27:19 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 98A093A680C for ; Tue, 24 Nov 2009 13:27:19 -0800 (PST) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAOLPp04013608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Nov 2009 15:25:51 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <4656101B-A8F8-4EC3-B9D7-D2B01FD824B0@estacado.net> From: Brian Hibbard To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 15:25:46 -0600 X-Mailer: Apple Mail (2.936) Cc: Kumiko Ono Subject: [sipcore] draft-ietf-sipcore-sec-flows-01: document scope and intent X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:27:20 -0000 A new version of the SIP Sec Flows draft is now available at http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-01.txt . The feedback on the draft so far raises some interesting points about the scope of the Sec Flows draft. There are some basic issues that need to be resolved for the draft to proceed. Responses to some of these issues may indicate the need for additional document(s) or a change in scope of the draft. == Informative vs Normative == The draft states in the first line of the introduction that it is not normative for SIP. That raises the question as to whether this should be on the standards track. Should this be informational or BCP? == Tutorial or Reference == Is the draft intended to be a hitchhikers' guide to security for SIP implementers? Does the draft intend to be a training tool to educate implementers in PKI? How far do we want to go in teaching developers how to generate and manage certificates? For example, are we trying to teach how to administer a Certificate Authority and want to deal with how certs are generated in the real world? Or are we only concerned with the cryptography of the messages, and we are only providing certificates and Are we only trying to provide specific reference examples for helping verify implementations? If so, should we be providing test vectors instead? Is the document intending to recommend how things should be done, how they might be done, or how they must be done? == Document Title == Depending on the resolution of the above, we may need to consider changing the document's title. From brian@estacado.net Tue Nov 24 13:27:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9083A687F for ; Tue, 24 Nov 2009 13:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQxU6tyjLagC for ; Tue, 24 Nov 2009 13:27:41 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 61D323A680C for ; Tue, 24 Nov 2009 13:27:41 -0800 (PST) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAOLPp05013608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Nov 2009 15:26:14 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> From: Brian Hibbard To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 15:26:14 -0600 X-Mailer: Apple Mail (2.936) Cc: Kumiko Ono Subject: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:27:42 -0000 There are a lot of paragraphs prefaced with "OPEN ISSUE" in the draft. This email points out some of them that are specifically related to the technical content of the draft. Some of these are questions which can hopefully be addressed by experts in the related areas. Some of these are issues that require working group consensus. == Message Composition in sections 4.2 and 5.X == Are we fine with using MESSAGE, or do we need to use INVITE? Do we want to demonstrate SIPS rules for Contact header field? Add a few lines about RFC 3263. Add a few lines about how the UA decides to create a new TLS session or use an existing one (but not "connection-reuse" draft level of reuse complexity). Any volunteers for writing this? == Observed Interoperability Issues in section 6== Who observed them? Is this experience from SIPits, etc? I think it would strengthen the idea that these are real-world, observed-in-the- wild issues to give sources. Do we mean client class devices, or user agents in general? Does this exclude proxies? (same question throughout section.) Is "...should send...must be prepared..." intended to be a normative statement? There is a larger issue as to whether this document is intended to be normative or informative. Should it be standards track? There's some implicit stuff here that should be explicit. Do you mean to recommend never attaching certs? It's probably worth mentioning the message size limit issue. What do we mean by "it cannot be relied upon"--that we can't rely on the peer sending it, or it is unreliable when the peer does send it? == Additional Test Scenarios section 7 == Are we sure all of this is truly folklore and none of it is from bona fide normative language somewhere? The true folklore portions may indicate future normative work we need to do. From first bullet, "peer's URI"...What URI? An AoR for the user? From or To values? Contacts? Request-URIs? For request URIs, do we need to discuss the effects of retargeting? Do we need to consider some of the current History-Info discussions? From second bullet: What if all you've got is an IP address? Do we disallow IPAddress entries in SubjectAltName? First sub-bullet (Wildcard matching is not allowed against these dNSName entries): Is there something that can be referenced here? In particular, RFC2818 explicitly allows wildcards in dNSName entries. It is not obvious to me whether the proscription against wildcards in RFC4474 should apply to general use of TLS, or just to identity. What about cases where the basic constraints or allowed uses are not appropriate? Is it worth putting in cases around self-signed certs? (i.e. self-signed cert, explicitly trusted, not trusted, etc.) How about cases where one or more certs in the chain to the root were not provided and not available through other means? Those seem like sensible cases to either include or explain why they aren't included. The self-signed cert is definitely a popular case among developers. == CRLs in section 10 == We should probably say something about CRLs. We need to get consensus on whether we want to recommend a method for retrieving CRLs. We could explicitly state that these are assumed to be retrieved out-of-band. Should they be retrieved by HTTP by some maintenance procedure? Via OCSP? How do we expect the SIP community to handle CRLs? == Appendix A. Making Test Certificates == The information in this section needs to be verified with the latest software versions. How to do conversions between supported types needs to be updated accordingly. From brian@estacado.net Tue Nov 24 13:29:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26623A6819 for ; Tue, 24 Nov 2009 13:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAWak7QgZtTw for ; Tue, 24 Nov 2009 13:29:03 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id D73FE3A682F for ; Tue, 24 Nov 2009 13:29:02 -0800 (PST) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAOLRaZH013912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Nov 2009 15:27:36 -0600 (CST) (envelope-from brian@estacado.net) Message-Id: <72962117-6FAF-44DE-8BB9-4C5D1C20A34A@estacado.net> From: Brian Hibbard To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 15:27:30 -0600 X-Mailer: Apple Mail (2.936) Cc: Kumiko Ono Subject: [sipcore] draft-ietf-sipcore-sec-flows-01: binary content issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:29:03 -0000 The binary content in the draft has not changed between version -00 and -01. There are known deficiencies in the certs and messages in the draft. The draft's content changes drastically when these are modified. Before I generate a version that affects the binary content, I want to make sure we have agreement on what the content *should* be. Even though the binary content is not in it's final form, verification of the cryptographic content can still proceed. The cryptographic content needs to be verified by someone other than myself before this draft can be accepted as RFC (or BCP?). == In general == Certificates need to have a "real" serial number, not 0. Certificates should have expiration dates far into the future as possible if we expect them to be useful. == Section 4.x == We need to generate a new TLS exchange in 4.1 where example.com and example.net resolve to different addresses. This will make the example in 4.2 clearer. == Section 5.x == Need more random-looking CSeq values. Do we need an example where we include a certificate in the message? Language in section 6 (paragraph "Observed S/MIME interoperability...") suggests we don't. Do we follow our own recommendations, or qualify the recommendation in Section 6? From vkg@alcatel-lucent.com Tue Nov 24 13:47:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221373A680C for ; Tue, 24 Nov 2009 13:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyHTc8T03oEu for ; Tue, 24 Nov 2009 13:47:58 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 223403A6819 for ; Tue, 24 Nov 2009 13:47:57 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nAOLleeR014692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 15:47:40 -0600 (CST) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nAOLleNx013093; Tue, 24 Nov 2009 15:47:40 -0600 (CST) Message-ID: <4B0C547B.1000309@alcatel-lucent.com> Date: Tue, 24 Nov 2009 15:47:39 -0600 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: Brian Hibbard References: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> In-Reply-To: <3E6B5A5B-DD53-4376-8767-584F6FDCB3A1@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE , Kumiko Ono Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:47:59 -0000 Brian Hibbard wrote: > == Additional Test Scenarios section 7 == > > Are we sure all of this is truly folklore and none of it is from bona > fide normative language somewhere? The true folklore portions may > indicate future normative work we need to do. [...] Brian: While I will go through the entire document, I can help you with specifically S7, having initially contributed it. I will get back to you after Thanksgiving with some feedback on S7 and other sections. Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From Martin.Thomson@andrew.com Tue Nov 24 15:14:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8923A67DB for ; Tue, 24 Nov 2009 15:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNf-NMkIY5CP for ; Tue, 24 Nov 2009 15:14:37 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BE5C83A67AF for ; Tue, 24 Nov 2009 15:14:37 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:58853 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S74249AbZKXXOb (ORCPT ); Tue, 24 Nov 2009 17:14:31 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 24 Nov 2009 17:14:30 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 25 Nov 2009 07:14:28 +0800 From: "Thomson, Martin" To: Brian Rosen , James Polk , "sipcore@ietf.org" Date: Wed, 25 Nov 2009 07:15:08 +0800 Thread-Topic: [sipcore] Inequalities for filters Thread-Index: AcptDoatQk2ts38cz0qA26oEEDpRMAATUZYg Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648EF1F@SISPE7MB1.commscope.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Inequalities for filters X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:14:39 -0000 VGhhdCdzIHJpZ2h0LCB0aGUgY2hhbmdlZEBieSBtaWdodCBpbmRpY2F0ZSB0aGUgbmVlZCBmb3Ig bm90aWZpY2F0aW9uLCBidXQgbWluLWludGVydmFsIGNhbiBzdXBwcmVzcyB0aGF0IG5vdGlmaWNh dGlvbiBhbnlob3cuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJp YW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCAy NSBOb3ZlbWJlciAyMDA5IDE6MDEgQU0NCj4gVG86IEphbWVzIFBvbGs7IFRob21zb24sIE1hcnRp bjsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEluZXF1YWxpdGll cyBmb3IgZmlsdGVycw0KPiANCj4gWW91IHVzZSByYXRlIGNvbnRyb2wgdG8gYWRqdXN0IHRoZSBy YXRlIG9mIG5vdGlmaWVzIGlmIHlvdSB3YW50IHRvIGhhdmUNCj4gYQ0KPiB2ZXJ5IHNtYWxsIGNo YW5nZWQtYnkgaW4gYSBkZXZpY2UgdGhhdCBtb3ZlcyBmYXN0Lg0KPiANCj4gQnJpYW4NCj4gDQo+ IA0KPiBPbiAxMS8yNC8wOSAxOjM4IEFNLCAiSmFtZXMgUG9sayIgPGptcG9sa0BjaXNjby5jb20+ IHdyb3RlOg0KPiANCj4gPiBBdCAwODo1MCBQTSAxMS8yMy8yMDA5LCBUaG9tc29uLCBNYXJ0aW4g d3JvdGU6DQo+ID4+IEkgZG9uJ3QgdGhpbmsgdGhhdCBKYW1lcycgdW5kZXJzdGFuZGluZyBpcyBx dWl0ZSBjb3JyZWN0Lg0KPiA+DQo+ID4gYWx0aG91Z2ggSSdtIG1pc3NpbmcgYSBmZXcgcXVlc3Rp b24gbWFya3MgYXQgdGhlIGVuZCBvZiBvYnZpb3VzDQo+ID4gcXVlc3Rpb25zIC0gSSB3YXMgcHJv YmluZyBmb3IgYW5zd2Vycywgbm90IHN0YXRpbmcgYW55dGhpbmcuDQo+ID4NCj4gPg0KPiA+PiBU aGUgbGFzdCBub3RpZmljYXRpb24gc2VlbiBieSB0aGUgd2F0Y2hlciBkZXRlcm1pbmVzIHRoZSBi YXNlbGluZQ0KPiA+PiBmb3Igbm90aWZpY2F0aW9ucy4gIFNvLCBpZiB0aGUgM20sIDZtLCA5bSBh bmQgOTltIG5vdGlmaWNhdGlvbnMgd2VyZQ0KPiA+PiBzdXBwcmVzc2VkLCB0aGUgc3Vic2VxdWVu dCAxMDBtIG5vdGlmaWNhdGlvbiB3b250IGJlLg0KPiA+DQo+ID4gTGV0IG1lIHRyeSB0aGlzIGFn YWluIC0tIGlmIHRoZSBjaGFuZ2VkLWJ5IGlzIHNldCB0byBsb29rIGZvcg0KPiA+IGluY3JlbWVu dHMgb2YgM20sIGFuZCBhIHRhcmdldCBpcyBtb3ZpbmcgYSAzbXBzLCB0aGVuIHRoZXJlIHNob3Vs ZCBiZQ0KPiA+IGEgTk9GSVRZIHNlbnQgZXZlcnkgc2Vjb25kIGJ5IHRoZSBub3RpZmllciwgcmln aHQ/DQo+ID4NCj4gPiBIb3dldmVyLCB0aGVyZSBpcyBzb21ldGhpbmcgdG8gdGhpcyAtLSB0aGUg c3Vic2NyaWJlciB3aWxsIGdldA0KPiA+IGludW5kYXRlZCAgd2l0aCBOT1RJRllzLg0KPiA+DQo+ ID4gV2hhdCBpZiB0aGUgbm90aWZpZXIgaXMgYWNjZWxlcmF0aW5nPw0KPiA+DQo+ID4gVGhpcyBp cyB1c2VmdWwgaW5mb3JtYXRpb24gdG8gaGF2ZSBJTU8gKGkuZS4sIHRoYXQgdGhlIGRlbHRhIGlz DQo+ID4gb2NjdXJyaW5nIG1vcmUgZnJlcXVlbnQpLiBUaGlzIHdpbGwgbGVhZCB0byBtb3JlIGlu dW5kYXRpb24uDQo+ID4NCj4gPiBJcyBpdCBpbXBvcnRhbnQgZm9yIHRoZSBub3RpZmllciB0byBk ZXRlcm1pbmUgdGhpcywgb3IgdGhlDQo+IHN1YnNjcmliZXI/DQo+ID4NCj4gPiBJcyB0aGVyZSBh IHRpbWVzdGFtcCBvZiB3aGVuIGVhY2ggTk9USUZZIGlzIHNlbnQgZm9yIGEgc3Vic2NyaWJlciB0 bw0KPiA+IGFjY3VyYXRlbHkgZGV0ZXJtaW5lIHRoaXMgaW5mb3JtYXRpb24/DQo+ID4NCj4gPg0K PiA+PiAtLU1hcnRpbg0KPiA+Pg0KPiA+PiBwLnMuIFdhcyB0aGlzIHRoZSBjb3JyZWN0IGdyb3Vw IHRvIGRpc2N1c3MgdGhpcyB0b3BpYz8gIFNJTVBMRSBvcg0KPiA+PiBHRU9QUklWIHNlZW0gbW9y ZSBhcHByb3ByaWF0ZS4NCj4gPg0KPiA+IEkgZG8gbm90IGJlbGlldmUgR2VvcHJpdiBoYXMgdGhl IGV4cGVydGlzZSBmb3IgdGhpcywgYXMgdGhleSBkbyBub3QNCj4gPiByZWd1bGFybHkgZGVhbCB3 aXRoIFNJUCBzaWduYWxpbmcgKHNhdmUgZm9yIGEgZmV3IGluIHRoZSBXRykuDQo+ID4NCj4gPiBU aGlzIGlzIHRpZWQgdG8gU0lQQ09SRSdzIExvY2F0aW9uIENvbnZleWFuY2UgSUQsIGFzIGl0J3Mg cHJpbWFyeSB1c2UNCj4gPiBjYXNlIGlzIGZvciBkZXJlZmVyZW5jaW5nIGEgbG9jYXRpb24gVVJJ Lg0KPiA+DQo+ID4gSmFtZXMNCj4gPg0KPiA+DQo+ID4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+PiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4N Cj4gPj4+IFNlbnQ6IFNhdHVyZGF5LCAxNCBOb3ZlbWJlciAyMDA5IDc6MjYgQU0NCj4gPj4+IFRv OiBKYW1lcyBQb2xrOyBzaXBjb3JlQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIEluZXF1YWxpdGllcyBmb3IgZmlsdGVycw0KPiA+Pj4NCj4gPj4+IEkgYmVsaWV2ZSBvbmUg aGFzIHRvIGJlIHJlYXNvbmFibGUuDQo+ID4+Pg0KPiA+Pj4gSWYgdGhlIHRhcmdldCBpcyBtb3Zp bmcgc2xvd2x5LCBhbmQgdGhlIGZpbHRlciBkb2Vzbid0IGdldCBjaGFuZ2VkLA0KPiA+Pj4gdGhl bg0KPiA+Pj4geWVzLg0KPiA+Pj4NCj4gPj4+IElmIHRoZSBtZWNoYW5pc21zIGluIHRoZSBkZXZp Y2UgZG9uJ3QgcmVhY3QgZmFzdCwgYW5kIHRoZSB0YXJnZXQgaXMNCj4gPj4+IG1vdmluZw0KPiA+ Pj4gcXVpY2tseSwgeW91IG1heSBub3QgZ2V0IGludGVybWVkaWF0ZSByZXBvcnRzLiAgWW91IGNl cnRhaW5seQ0KPiBzaG91bGRuJ3QNCj4gPj4+IGdldA0KPiA+Pj4gbW9yZSB0aGFuIG9uZSBvdXRz dGFuZGluZyBOT1RJRlkgb3ZlciB0aGlzIGtpbmQgb2YgZmlsdGVyLg0KPiA+Pj4NCj4gPj4+IFRo ZSByZWNpcGllbnQgY2FuIGNvbnRyb2wgdGhlIHJhdGUgb2Ygbm90aWZpY2F0aW9uIHdpdGggdGhl IHJhdGUNCj4gPj4+IGNvbnRyb2wNCj4gPj4+IGZpbHRlcnMsIHNvIGlmIGl0IGRvZXNuJ3Qgd2Fu dCB0byBiZSBpbnVuZGF0ZWQsIGl0IGNhbiBjb250cm9sIGl0Lg0KPiA+Pj4NCj4gPj4+IFdoaWxl IHdlIGhhdmUgc3BlZWQsIHdlIGRvbid0IGhhdmUgYWNjZWxlcmF0aW9uLCBhbmQgSSdtIG5vdA0K PiBpbnRlcmVzdGVkDQo+ID4+PiBpbg0KPiA+Pj4gYWRkaW5nIGl0Lg0KPiA+Pj4NCj4gPj4+IEJy aWFuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IE9uIDExLzEzLzA5IDM6MTAgUE0sICJKYW1lcyBQb2xr IiA8am1wb2xrQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+IEFsb25nIHRoaXMgdG9w aWMsIGFuZCB3aGF0IHdhcyBkaXNjdXNzZWQgaW4gbXkgcmV2aWV3IG9mIHRoZQ0KPiA+Pj4+IGxv Yy1maWx0ZXJzLTA3IElELCBpcyB3aGF0IGhhcHBlbnMgaWYgYSB0YXJnZXQgbW92ZXMgYnkgYSBm aXhlZA0KPiA+Pj4+IGFtb3VudCAoaS5lLiwgaXQgaGFzIGNoYW5nZWQgbG9jYXRpb25zIGJ5IHRo ZSBwcmVzZXQgbnVtYmVyIG9mDQo+ID4+Pj4gbWV0ZXJzKS4gIFRoZSBleGFtcGxlIGlzIGlmIGEg dGFyZ2V0IG1vdmVzIGJ5IDMgbWV0ZXJzIHNpbmNlIHRoZQ0KPiBsYXN0DQo+ID4+Pj4gbm90aWZp Y2F0aW9uLCBzZW5kIGEgbmV3IG5vdGlmaWNhdGlvbiBvZiB0aGlzIG1vdmVtZW50Lg0KPiA+Pj4+ DQo+ID4+Pj4gVGhpcyBsZWFkIHRvIHRoZSBpZGVhIG9mIGEgdGFyZ2V0IG1vdmluZyBtdWNoIG1v cmUgdGhhbiAzbSwgYnV0DQo+IGJ5LA0KPiA+Pj4+IHNheSwgMTAwbS4gIERvZXMgYSBub3RpZmlj YXRpb24gbm93IGdldCBzZW50IGF0IDNtLiA2bSwgOW0sIDEybQ0KPiAuLi4NCj4gPj4+PiA5OW0s IGJ1dCBub3QgdGhlIGxhc3QgMW0sIGJlY2F1c2UgaXQgaGFzbid0IHJlYWN0ZWQgdGhlIHRocmVz aG9sZA0KPiBvZg0KPiA+Pj4+IDNtIGluY3JlbWVudHMuDQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGxl YWQgdG8gdGhlIGlkZWEgdGhhdCBwZXJoYXBzIHRoaXMgdGFyZ2V0IGlzIGFjY2VsZXJhdGluZy4g SXMNCj4gPj4+PiB0aGlzIG9mIHZhbHVlLCBhbmQgc2hvdWxkIHRoaXMgYmUgZGV0ZXJtaW5lZCBi eSB0aGUgdGFyZ2V0ICh3aGljaA0KPiA+Pj4+IHNlbnNlcyBvciBpcyB0b2xkIHdoaWNoIGluY3Jl bWVudCBpcyBoYXMgbW92ZWQpIG9yIGRldGVybWluZWQgYnkNCj4gPj4+PiBjYWxjdWxhdGlvbiBi eSB0aGUgcmVjaXBpZW50IHRoYXQgdGhlIHRhcmdldCBpcyBtb3ZpbmcgYXQgYSBmYXN0ZXINCj4g b3INCj4gPj4+PiBzbG93ZXIgcGFjZSBvciBzcGVlZC4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgaXMg bm90IGV4YWN0bHkgYSBzbGlwcGVyeSBzbG9wZSBvZiBuZXcgdGhpbmdzIHRvIHRyYWNrLCBidXQN Cj4gaXQNCj4gPj4+PiBpc24ndCBhIHNpbmdsZSB2YWx1ZSBJTU8gZWl0aGVyLg0KPiA+Pj4+DQo+ ID4+Pj4gSmFtZXMNCj4gPj4+Pg0KPiA+Pj4+IEF0IDAxOjI4IFBNIDExLzEzLzIwMDksIEJyaWFu IFJvc2VuIHdyb3RlOg0KPiA+Pj4+PiBUaGUgY3VycmVudCBmaWx0ZXIgc3BlY3MgYWxsb3cgImNo YW5nZWQgYnkiIHNlbWFudGljcywgYSBkZWx0YSBvbg0KPiA+Pj4gdGhlIGxhc3QNCj4gPj4+Pj4g dmFsdWUuICBJbiBsb2NhdGlvbiwgd2UgcmFuIGFjcm9zcyB0aGUgbmVlZCB0byBrbm93IHdoZW4g c3BlZWQNCj4gd2FzDQo+ID4+PiBleGNlZWRlZA0KPiA+Pj4+PiBieSBzb21lIHZhbHVlLiAgVGhp cyBpcyBub3QgYSBkZWx0YSwgaXQncyBhIGNvbXBhcmlzb24gYWdhaW5zdCBhDQo+ID4+PiBmaXhl ZA0KPiA+Pj4+PiBxdWFudGl0eS4NCj4gPj4+Pj4NCj4gPj4+Pj4gV2hhdCBpcyB0aGUgYXBwZXRp dGUgb2YgdGhlIHdvcmsgZ3JvdXAgdG8gYWRkIGEgZ2VuZXJhbGl6ZWQNCj4gPj4+IGluZXF1YWxp dHksDQo+ID4+Pj4+IGJhc2VkIG9uIHRoZSBiYXNpYyAiY2hhbmdlZCBieSIgc3ludGF4LCB0aGF0 IGNvdmVycyB0aGUgb2J2aW91cw0KPiA+Pj4gZ3JlYXRlcg0KPiA+Pj4+PiB0aGFuLCBsZXNzIHRo YW4sIGVxdWFscywgbm90IGVxdWFscywgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvLi4uPw0KPiA+ Pj4gWW91IGdldCBhDQo+ID4+Pj4+IG5vdGlmeSB3aGVuIHRoZSBjb25kaXRpb24gaXMgbWV0Lg0K PiA+Pj4+Pg0KPiA+Pj4+PiBUaGlzIHdvdWxkIGJlIGEgc2hvcnQgZHJhZnQuDQo+ID4+Pj4+DQo+ ID4+Pj4+IEJyaWFuDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IHNpcGNvcmUg bWFpbGluZyBsaXN0DQo+ID4+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gPg0KPiAN Cj4gDQoNCg== From drage@alcatel-lucent.com Wed Nov 25 07:48:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4E13A6A91 for ; Wed, 25 Nov 2009 07:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=-1.746, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkQh2oBfxlyV for ; Wed, 25 Nov 2009 07:48:07 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 37EE53A6861 for ; Wed, 25 Nov 2009 07:48:06 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPFm0WR001919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Nov 2009 16:48:00 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 25 Nov 2009 16:48:00 +0100 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Wed, 25 Nov 2009 16:47:58 +0100 Thread-Topic: Usage of Allow-Event header field Thread-Index: AcpqGAtgMAplBWBPTtSq0I1/C7F2SgDzmGpQ 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [sipcore] Usage of Allow-Event header field X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:48:08 -0000 Does anyone have a response to this (Adam possibly?) before all the experts= on that side of the pond start digging into their thanksgiving turkey. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Friday, November 20, 2009 7:48 PM > To: sipcore@ietf.org > Subject: [sipcore] Usage of Allow-Event header field >=20 > This header field was defined by RFC 3265. >=20 > It was then reused by RFC 3903. >=20 > In RFC 3265 it states: >=20 > 3.3.7. Allow-Events header usage >=20 > The "Allow-Events" header, if present, includes a list of tokens > which indicates the event packages supported by the client (if sent > in a request) or server (if sent in a response). In other words, a > node sending an "Allow-Events" header is advertising that it can > process SUBSCRIBE requests and generate NOTIFY requests for all of > the event packages listed in that header. >=20 > Any node implementing one or more event packages SHOULD include an > appropriate "Allow-Events" header indicating all supported=20 > events in > all methods which initiate dialogs and their responses (such as > INVITE) and OPTIONS responses. >=20 > This information is very useful, for example, in allowing=20 > user agents > to render particular interface elements appropriately according to > whether the events required to implement the features they=20 > represent > are supported by the appropriate nodes. >=20 > Note that "Allow-Events" headers MUST NOT be inserted by proxies. >=20 >=20 > So is the above text applicable only to event packages where=20 > the SUBSCRIBE / NOTIFY methods are used, or is it also=20 > applicable to event packages that could exist only be used on=20 > the PUBLISH method? >=20 > When I turn to RFC 3903 the text regarding Allow-Events is=20 > much more limited, and refers to its usage only within the=20 > PUBLISH and OPTIONS methods. >=20 > If necessary, clients may probe for the support of PUBLISH=20 > using the > OPTIONS request defined in SIP [4]. The presence of=20 > "PUBLISH" in the > "Allow" header field in a response to an OPTIONS request indicates > support for the PUBLISH method. In addition, the "Allow-Events" > header field indicates the supported event packages. >=20 > 7. Processing OPTIONS Requests >=20 > A client may probe the ESC for the support of PUBLISH using the > OPTIONS request defined in SIP [4]. The ESC processes OPTIONS > requests as defined in Section 11.2 of RFC 3261 [4]. In=20 > the response > to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list > of allowed methods in the Allow header field. Also, it SHOULD list > the supported event packages in an Allow-Events header field. >=20 > Note that if the RFC 3265 text applies, then Allow-Events=20 > should also appear in 2xx PUBLISH responses, and this is not=20 > specified by RFC 3903. >=20 > regards >=20 > Keith >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@nostrum.com Wed Nov 25 13:21:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6636E3A69C4 for ; Wed, 25 Nov 2009 13:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0Cn7w1rrtTe for ; Wed, 25 Nov 2009 13:21:56 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 11F853A6B4B for ; Wed, 25 Nov 2009 13:21:55 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAPLLm7m018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 15:21:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B0D9FEC.3060103@nostrum.com> Date: Wed, 25 Nov 2009 15:21:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------030005030201090909060601" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Last Call: draft-roach-sip-http-subscribe-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:21:57 -0000 This is a multi-part message in MIME format. --------------030005030201090909060601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as an individual] A new version of the SIP HTTP Subscribe draft is now available. I consider this version to be functionally complete, and plan to hand it off to the APPS ADs for evaluation and publication in the next two to three weeks (we plan to publish this document as an individual submission, not a working-group document). If you have any interest in this subject matter, please review the document and comment on the "SIP HTTP Events" mailing list. To ensure that your comments can be incorporated, ensure that you do so before Friday, December 11th. The new version of the document is available here: http://www.ietf.org/id/draft-roach-sip-http-subscribe-03.txt Information about the "SIP HTTP Events" mailing list is available here: https://www.ietf.org/mailman/listinfo/sip-http-events /a -------- Original Message -------- Subject: New Version Notification for draft-roach-sip-http-subscribe-03 Date: Wed, 25 Nov 2009 13:08:08 -0800 (PST) From: IETF I-D Submission Tool To: adam@nostrum.com A new version of I-D, draft-roach-sip-http-subscribe-03.txt has been successfuly submitted by Adam Roach and posted to the IETF repository. Filename: draft-roach-sip-http-subscribe Revision: 03 Title: A SIP Event Package for Subscribing to Changes to an HTTP Resource Creation_date: 2009-11-25 WG ID: Independent Submission Number_of_pages: 18 Abstract: The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources. The IETF Secretariat. --------------030005030201090909060601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit [as an individual]

A new version of the SIP HTTP Subscribe draft is now available. I consider this version to be functionally complete, and plan to hand it off to the APPS ADs for evaluation and publication in the next two to three weeks (we plan to publish this document as an individual submission, not a working-group document). If you have any interest in this subject matter, please review the document and comment on the "SIP HTTP Events" mailing list. To ensure that your comments can be incorporated, ensure that you do so before Friday, December 11th.

The new version of the document is available here:
  http://www.ietf.org/id/draft-roach-sip-http-subscribe-03.txt

Information about the "SIP HTTP Events" mailing list is available here:
  https://www.ietf.org/mailman/listinfo/sip-http-events

/a

-------- Original Message --------
Subject: New Version Notification for draft-roach-sip-http-subscribe-03
Date: Wed, 25 Nov 2009 13:08:08 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: adam@nostrum.com 


A new version of I-D, draft-roach-sip-http-subscribe-03.txt has been successfuly submitted by Adam Roach and posted to the IETF repository.

Filename:	 draft-roach-sip-http-subscribe
Revision:	 03
Title:		 A SIP Event Package for Subscribing to Changes to an HTTP Resource
Creation_date:	 2009-11-25
WG ID:		 Independent Submission
Number_of_pages: 18

Abstract:
The Session Initiation Protocol (SIP) is increasingly being used in
systems that are tightly coupled with Hypertext Transport Protocol
(HTTP) servers for a variety of reasons.  In many of these cases,
applications can benefit from being able to discover, in near-real-
time, when a specific HTTP resource is created, changed, or deleted.
This document proposes a mechanism, based on the SIP events
framework, for doing so.

This document further proposes that the HTTP work necessary to make
such a mechanism work be extensible to support protocols other than
SIP for monitoring HTTP resources.
                                                                                  


The IETF Secretariat.
--------------030005030201090909060601-- From root@core3.amsl.com Wed Nov 25 17:00:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 778043A67EB; Wed, 25 Nov 2009 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091126010001.778043A67EB@core3.amsl.com> Date: Wed, 25 Nov 2009 17:00:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:00:01 -0000 --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 Core Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi, D. Willis Filename : draft-ietf-sipcore-subnot-etags-03.txt Pages : 25 Date : 2009-11-25 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 26, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sipcore-subnot-etags-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-25165024.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Wed Nov 25 17:03:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE75D3A693F for ; Wed, 25 Nov 2009 17:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ra1Py9ryw3 for ; Wed, 25 Nov 2009 17:03:36 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D9BD93A680C for ; Wed, 25 Nov 2009 17:03:35 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAQ13SXG025109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2009 19:03:29 -0600 Message-Id: <86B0A2FD-CB20-4E49-B69A-66162E91178D@softarmor.com> From: Dean Willis To: SIPCORE Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Nov 2009 19:03:23 -0600 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Revised draft-ietf-sipcore-subnot-etags to -03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 01:03:36 -0000 Based on discussions with Robert and Adam, I've revised the subnot- etags document. There are no "real" changes, just clarifications on what an entity tag means in SIP, the uniqueness-scope of such tags, and very minor language cleanup. Previously, we had a lot of debate on whether an eTag is truly "unique". It's not; it is unique only within a map of the state-vector space of each resource. For a given resource, each eTag is associated with one and only one view of that resource's state (which we call an "entity".) For a given resource, identical eTags mean identical entities. Comparison of eTags between resources is meaningless, as they refer to disjoint state spaces. That is, if resource A as seen by Alice has an entity-tag of 0x77A and resource B as seen by Bob has an entity tag of 0X77A, this doesn't mean that the two entities are the same. Doesn't mean they're different, either; it means absolutely nothing that they have entity tags with the same value. I promise the draft now makes more sense than this synopsis. I'm not sure I like the graphic rendering of the resource model in section 4. Please take a look at it and provide feedback. -- Dean From gonzalo.camarillo@ericsson.com Fri Nov 27 05:33:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E2B3A6A4A for ; Fri, 27 Nov 2009 05:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN9HAcORS6Xs for ; Fri, 27 Nov 2009 05:33:58 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 52F173A6A44 for ; Fri, 27 Nov 2009 05:33:58 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-92-4b0fd53f1ee7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.9E.14961.F35DF0B4; Fri, 27 Nov 2009 14:33:51 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 14:33:51 +0100 Received: from [131.160.126.197] ([131.160.126.197]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 14:33:50 +0100 Message-ID: <4B0FD53A.10705@ericsson.com> Date: Fri, 27 Nov 2009 15:33:46 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4AFA3E1A.8060204@ericsson.com> In-Reply-To: <4AFA3E1A.8060204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2009 13:33:51.0062 (UTC) FILETIME=[418D7F60:01CA6F66] X-Brightmail-Tracker: AAAAAA== Cc: Brian Hibbard Subject: Re: [sipcore] Reviewing the sec-flows draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 13:33:59 -0000 Folks, as you may have noticed, Brian has submitted a new revision of this draft and sent a couple of notes to the list (on November 24th) describing the topics on which he expects to get feedback. Please, send your comments to this list. Thanks, Gonzalo SIPCORE co-chair Gonzalo Camarillo wrote: > Folks, > > as you know, we have asked for volunteers to review the sec-flows draft > many times. We got a couple of reviews but we would like to get at least > one dedicated review more. If you want to volunteer, please send your > review to the list. > > Additionally, the reviews we got pointed out at issues that require WG > consensus (as opposed to the editor simply going off and implementing > them). > > As next steps, the draft's editor (Brian) will be submitting a new > revision of the draft because the current one has expired. Then, he will > be sending a set of emails to the list so that we can reach consensus on > the issues that need discussion. > > Thanks, > > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From alan@sipstation.com Mon Nov 30 05:13:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA443A6A79 for ; Mon, 30 Nov 2009 05:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke16rKp8R9vr for ; Mon, 30 Nov 2009 05:13:42 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id F03633A6A7C for ; Mon, 30 Nov 2009 05:13:41 -0800 (PST) Received: from 24-107-156-208.dhcp.stls.mo.charter.com ([24.107.156.208] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NF64M-000H7d-LN for sipcore@ietf.org; Mon, 30 Nov 2009 13:13:34 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.156.208 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+U+zXOiD/n5mjwlVf3CXjZz1d9QVqkhrk= Message-ID: <4B13C4FC.5050907@sipstation.com> Date: Mon, 30 Nov 2009 07:13:32 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:13:44 -0000 Comments: Section 4.1 first paragraph. The part of this paragraph beginning with "Normally, UACs are not expected..." should probably be indented as it is a note. There are probably other places where this could be done to improve the readability of the document. Section 4.1, third paragraph about 3xx response. I can see why this is necessary, but I wonder if anyone will support this requirement? Section 5.1.2, Step 3 says "Same as per Step 3 above..." but it is not clear what step this is. Section 5.1.3, Step 1 says "The proxy MUST then perform Steps 2 and 3." I presume this means the next 2 steps? Section 5.1.3, Step 3 references "Same as per Step 3 above..." Section 6.3.2: Might want to include an explanation why a timeout should be treated as a 487 instead of a 408. Does this document have a good voicemail example? This is the application I am most interested in, so it would be nice to have a very clear example of this. Nits: p.25 "gratuitly" > "gratuitously" Thanks, Alan From francois.audet@skypelabs.com Mon Nov 30 14:56:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3033A6861 for ; Mon, 30 Nov 2009 14:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVX09GPd9Utd for ; Mon, 30 Nov 2009 14:56:27 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 996323A68D8 for ; Mon, 30 Nov 2009 14:56:27 -0800 (PST) Received: by gxk28 with SMTP id 28so1778733gxk.9 for ; Mon, 30 Nov 2009 14:56:18 -0800 (PST) Received: by 10.150.45.35 with SMTP id s35mr8352674ybs.129.1259621777892; Mon, 30 Nov 2009 14:56:17 -0800 (PST) Received: from ?172.17.1.16? (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by mx.google.com with ESMTPS id 6sm1798835ywc.54.2009.11.30.14.56.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 14:56:16 -0800 (PST) Sender: =?UTF-8?Q?Fran=C3=A7ois_Audet?= Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Francois AUDET In-Reply-To: <4B13C4FC.5050907@sipstation.com> Date: Mon, 30 Nov 2009 14:56:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> References: <4B13C4FC.5050907@sipstation.com> To: Alan Johnston X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 30 Nov 2009 15:06:04 -0800 Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:01:26 -0000 On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >=20 > Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >=20 That was the intent of section B.2 (in the appendix). Are you saying you'd want a better voicemail example? Or that we add = more voicemail examples? What do you have in mind?= From shida@ntt-at.com Mon Nov 30 17:40:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF34B3A6A0E for ; Mon, 30 Nov 2009 17:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2rplCX41ynX for ; Mon, 30 Nov 2009 17:40:05 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.41.245.13]) by core3.amsl.com (Postfix) with SMTP id AC9843A6922 for ; Mon, 30 Nov 2009 17:40:00 -0800 (PST) Received: (qmail 12317 invoked from network); 1 Dec 2009 01:53:55 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway12.websitewelcome.com with SMTP; 1 Dec 2009 01:53:55 -0000 Received: from fl1-118-109-66-179.tky.mesh.ad.jp ([118.109.66.179]:54929 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFHiP-0003zA-5T; Mon, 30 Nov 2009 19:39:41 -0600 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> Date: Tue, 1 Dec 2009 10:39:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B13C4FC.5050907@sipstation.com> <98E67934-70CE-49E4-A2C3-05C3EB42573F@skype.net> To: Francois AUDET X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Some comments on draft-barnes-sipcore-rfc4244bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:40:05 -0000 Francois; This was something Cullen asked we add to the draft too. I am assuming what we need is to add an explicit text that aids =20 voicemail server to identify the target of the voicemail box. =20 If a call was initially received at Alice then diverted=20 to Carol, then to Bob which then diverts to voicemail,=20 the question is for which AoR should the voicemail server=20 leave a voicemail?=20 I think the answer depends on the configuration=20 of the voicemail server. But with the "mp" tag and=20 "mp" index we can identify when the mapping=20 (diversion) took place making it much more =20 deterministic to identify the target of the voicemail box. Looking at the example from the draft below;=20 History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc History-Info: ;index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1;rc History-Info: ;index=3D1.3;mp=3D1.2 History-Info: ;index=3D1.3.1 If the voicemail server is configured to use the voicemail box=20 of the initial target it can look for the first mp tag and look=20 at the hi-entry that mp index references (bob@example.com).=20 If the voicemail server is configured to use the voicemail box=20 of the last target then it can look for the last mp tag and look=20 at the hi-entry that mp index references (carol@example.com) etc.=20 Regards Shida On Dec 1, 2009, at 7:56 AM, Francois AUDET wrote: >=20 > On Nov 30, 2009, at 5:13 , Alan Johnston wrote: >=20 >>=20 >> Does this document have a good voicemail example? This is the = application I am most interested in, so it would be nice to have a very = clear example of this. >>=20 >=20 > That was the intent of section B.2 (in the appendix). >=20 > Are you saying you'd want a better voicemail example? Or that we add = more voicemail examples? What do you have in mind? > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore