From bill.wu@huawei.com Thu Dec 1 18:02:01 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1027F1F0CAF for ; Thu, 1 Dec 2011 18:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH3z1K++45ta for ; Thu, 1 Dec 2011 18:02:00 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with SMTP id 4D6631F0CAC for ; Thu, 1 Dec 2011 18:02:00 -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 <0LVK00KNX0B2SL@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 02 Dec 2011 10:01:50 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVK005ZR0B2WO@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 02 Dec 2011 10:01:50 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFM50207; Fri, 02 Dec 2011 10:01:49 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Dec 2011 10:01:43 +0800 Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Dec 2011 10:01:37 +0800 Date: Fri, 02 Dec 2011 10:01:36 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: dispatch@ietf.org Message-id: <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> X-Mailman-Approved-At: Thu, 01 Dec 2011 19:42:04 -0800 Subject: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 02:02:01 -0000 Hi, Hadriel: Your Straw WG proposal in DISPATCH meeting looks interesting to me. Unfortunetely I was not present in the Dispatch when I was in Taipei meeting. So I read your drafts related to Straw and have couples of questions: 1. Why SIP request routing loop will happen? Isn't SIP request initiated from one end and terminated at the other end? Is SIP request routing loop only apply to some subset of SIP message type? 2. What cause unending SIP request routing loop? Is it becos media loop back? How media loop back has to do with signaling loop back? 3. What's the difference between end to end media loopback and hop by hop media loopback? what message signaling exchange looks like? 4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you intend to drop these header extension or reuse these header extension and fill the missing part? 5. Is there any tools at the SIP level like trace route and ping to test the path reachability? 6. Why B2BUA1 at the one end should care about how many paths it can go through to the B2BUA2 at the other end? Isn't SIP request routed in the transparent manner? 7. How many B2BUAs from one end to the other end should be traversed in the path? I will be appreciated if you can clarify a little bit to me? Regards! -Qin From HKaplan@acmepacket.com Fri Dec 2 06:43:02 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1821F8C83 for ; Fri, 2 Dec 2011 06:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8glWREv3rSP for ; Fri, 2 Dec 2011 06:43:01 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 281B621F8C82 for ; Fri, 2 Dec 2011 06:43:00 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Dec 2011 09:42:55 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 2 Dec 2011 09:42:55 -0500 From: Hadriel Kaplan To: Qin Wu Thread-Topic: Comments on Straw WG proposal and related deliverals Thread-Index: AQHMsQCsVkhmbMXw2E+8u8owFWJUdw== Date: Fri, 2 Dec 2011 14:42:54 +0000 Message-ID: References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> In-Reply-To: <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <81C701551900E043A8D862D2F6BD0BF9@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 14:43:02 -0000 Hi Qin,=20 comments inline... On Dec 1, 2011, at 9:01 PM, Qin Wu wrote: > So I read your drafts related to Straw and have couples of questions: > 1. Why SIP request routing loop will happen? Isn't SIP request initiated= from one end and terminated at the other end? > Is SIP request routing loop only apply to some subset of SIP message = type? In theory it applies to any out-of-dialog request type, but typically it ha= ppens with INVITEs today. The "loop" is just that the INVITE gets routed across proxies/B2BUAs, and a= t some point it reaches a proxy/b2bua that routes the request back upstream= - either literally back to the same previous proxies/b2buas or to another = proxy/b2bua which eventually routes it back to the same one that erroneousl= y sent it upstream. In deployed networks this is usually caused by misconf= iguration of dial-plans/routing-tables, but has also occurred due to call-f= orwarding loops. =20 If all the SIP devices were strict Proxies, then they'd detect and stop the= loop based on either the Via header check or Max-Forwards reaching 0. But= with B2BUAs the Via isn't usable for loop detection, and some B2BUAs reset= the Max-Forwards value, so draft-kaplan-dispatch-b2bua-loop-detection-00 s= ays not to do that but instead copy and decrement the Max-Foreards. > 2. What cause unending SIP request routing loop? Is it becos media loop = back? How media loop back has to do with signaling loop back? No the two have nothing to do with each other. Draft-kaplan-dispatch-b2bua= -loop-detection-00 is just about signaling loops (which are bad). Draft-ka= plan-dispatch-sip-traceroute-00 is about using media-loopback for call test= ing, but is not about a "loop" at the signaling layer. > 3. What's the difference between end to end media loopback and hop by ho= p media loopback? what message signaling exchange looks like? End-to-end media-loopback would be just a media-loopback session based on d= raft-ietf-mmusic-media-loopback-16, and thus a session to the target of the= request. So for example if you make a loopback test call to +17815551212,= then your SIP INVITE request would reach the UAS representing +17815551212= , and that UAS would loop media back to you. Hop-by-hop is where you'd mak= e a loopback test call to +17815551212, but the first time you'd make it th= e first media-plane B2BUA along the path to +17815551212 would actually ans= wer the call and loop media to you; the second time you'd make it the secon= d B2BUA along the path would answer the call, and so on until you'd finally= reach +17815551212. That way you can test the signaling+media path on a h= op-by-hop basis towards the target destination. > 4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you i= ntend to drop these header extension or reuse these header extension and fi= ll the missing part? I don't know what you mean - where do I say there's a missing feature? > 5. Is there any tools at the SIP level like trace route and ping to test= the path reachability? Sort of, but not always. You can just send OPTIONS requests as a form of "= ping", but not all devices support it and it's not always clear that the OP= TIONS got the whole way to the target (I've been told some B2BUAs answer OP= TIONS not targeted at them). If OPTIONs works, you can also reduce the Max= -Forwards for the OPTIONS request as form of traceroute, but since some B2B= UAs reset Max-Forwards that doesn't always work. > 6. Why B2BUA1 at the one end should care about how many paths it can go = through to the B2BUA2 at the other end? Isn't SIP request routed in the tra= nsparent manner? If you mean in draft-kaplan-dispatch-sip-traceroute-00, the purpose is for = troubleshooting. There will obviously be strict rules/policies on B2BUAs t= hat support this draft as to whether they accept such requests and from who= m, and when. For example I doubt they'd let user/consumer UAs perform this= test - more like only operator/administrator test devices. And obviously = if the operator doesn't want to let anyone do this they can just not enable= it to begin with. > 7. How many B2BUAs from one end to the other end should be traversed in = the path? There's no limit in theory, though in practice I think the default Max-Forw= ards value of 70 is reasonably high enough never to be reached for good cal= ls. -hadriel From gonzalo.camarillo@ericsson.com Mon Dec 5 03:11:11 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02D21F8ABC for ; Mon, 5 Dec 2011 03:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pLKuRF6Xv0r for ; Mon, 5 Dec 2011 03:11:10 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9688321F8AD8 for ; Mon, 5 Dec 2011 03:11:01 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-12-4edca6c4050c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CF.3B.09514.4C6ACDE4; Mon, 5 Dec 2011 12:11:00 +0100 (CET) Received: from [131.160.36.73] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Dec 2011 12:10:59 +0100 Message-ID: <4EDCA6C3.10703@ericsson.com> Date: Mon, 5 Dec 2011 13:10:59 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Fwd: Closing the SPLICES WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 11:11:11 -0000 FYI. If you have something to say about the email below, please reply to it on the SPLICES list. Cheers, Gonzalo -------- Original Message -------- Subject: Closing the SPLICES WG Date: Mon, 05 Dec 2011 13:09:28 +0200 From: Gonzalo Camarillo To: SPLICES WG Folks, there seems to be zero activity around the SPLICES WG. After talking to the chair (Simon Pietro) and a few people who were active in the group in the past, we have decided to close it down. So, unless somebody can convince me otherwise (by providing solid arguments), I intend to close down the WG by December 15th. Cheers, Gonzalo From bill.wu@huawei.com Tue Dec 6 00:27:18 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49F821F8B39 for ; Tue, 6 Dec 2011 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVF1bJCvBgfA for ; Tue, 6 Dec 2011 00:27:18 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6CE21F8B37 for ; Tue, 6 Dec 2011 00:27:17 -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 <0LVR006N8WRHG3@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 06 Dec 2011 16:26:05 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVR00CFCWRF9N@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 06 Dec 2011 16:26:05 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFO88496; Tue, 06 Dec 2011 16:25:40 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Dec 2011 16:25:37 +0800 Received: from w53375q (10.138.41.130) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Dec 2011 16:25:39 +0800 Date: Tue, 06 Dec 2011 16:25:38 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Hadriel Kaplan Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 08:27:18 -0000 Hi, Hadriel: Thank for your useful clarification. I have some followup comments below. ----- Original Message ----- From: "Hadriel Kaplan" To: "Qin Wu" Cc: Sent: Friday, December 02, 2011 10:42 PM Subject: Re: Comments on Straw WG proposal and related deliverals Hi Qin, comments inline... On Dec 1, 2011, at 9:01 PM, Qin Wu wrote: > So I read your drafts related to Straw and have couples of questions: > 1. Why SIP request routing loop will happen? Isn't SIP request initiated from one end and terminated at the other end? > Is SIP request routing loop only apply to some subset of SIP message type? In theory it applies to any out-of-dialog request type, but typically it happens with INVITEs today. The "loop" is just that the INVITE gets routed across proxies/B2BUAs, and at some point it reaches a proxy/b2bua that routes the request back upstream - either literally back to the same previous proxies/b2buas or to another proxy/b2bua which eventually routes it back to the same one that erroneously sent it upstream. In deployed networks this is usually caused by misconfiguration of dial-plans/routing-tables, but has also occurred due to call-forwarding loops. If all the SIP devices were strict Proxies, then they'd detect and stop the loop based on either the Via header check or Max-Forwards reaching 0. But with B2BUAs the Via isn't usable for loop detection, and some B2BUAs reset the Max-Forwards value, so draft-kaplan-dispatch-b2bua-loop-detection-00 says not to do that but instead copy and decrement the Max-Foreards. [Qin]: In the loop detection mechanism you proposed, How do you prevent some bad B2BUAs in the path without support of loop mechanism resetting the MAX-Forward value or you need to assume all the B2BUAs in the path should support loop detection mechanism you proposed? Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via header? > 2. What cause unending SIP request routing loop? Is it becos media loop back? How media loop back has to do with signaling loop back? No the two have nothing to do with each other. Draft-kaplan-dispatch-b2bua-loop-detection-00 is just about signaling loops (which are bad). Draft-kaplan-dispatch-sip-traceroute-00 is about using media-loopback for call testing, but is not about a "loop" at the signaling layer. [Qin]: Okay. I see. > 3. What's the difference between end to end media loopback and hop by hop media loopback? what message signaling exchange looks like? End-to-end media-loopback would be just a media-loopback session based on draft-ietf-mmusic-media-loopback-16, and thus a session to the target of the request. So for example if you make a loopback test call to +17815551212, then your SIP INVITE request would reach the UAS representing +17815551212, and that UAS would loop media back to you. Hop-by-hop is where you'd make a loopback test call to +17815551212, but the first time you'd make it the first media-plane B2BUA along the path to +17815551212 would actually answer the call and loop media to you; the second time you'd make it the second B2BUA along the path would answer the call, and so on until you'd finally reach +17815551212. That way you can test the signaling+media path on a hop-by-hop basis towards the target destination. [Qin]: Good example, Now I know their difference. But one more question is: why each B2BUAs in the path more close to the user/consumer device answer the call on behalf of UAS representing +17815551212? Is that becos this is test signaling? or new SIP request type only for test? > 4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you intend to drop these header extension or reuse these header extension and fill the missing part? I don't know what you mean - where do I say there's a missing feature? [Qin]: That's what you mentioned in the open issue section 5 of draft-kaplan-dispatch-sip-traceroute. The question is do you want to fix MAX-Forward or Do you want to define new header extension? This is a little contradict to me when reading draft-kaplan-dispatch-b2bua-loop-detection and draft-kaplan-dispatch-sip-traceroute. It looks to me in draft-kaplan-dispatch-b2bua-loop-detection, it propose additional new behavior for B2BUAs without any change to MAX-Forward while in the draft-kaplan-dispatch-sip-traceroute, it seems it propose some new header extension? > 5. Is there any tools at the SIP level like trace route and ping to test the path reachability? Sort of, but not always. You can just send OPTIONS requests as a form of "ping", but not all devices support it and it's not always clear that the OPTIONS got the whole way to the target (I've been told some B2BUAs answer OPTIONS not targeted at them). If OPTIONs works, you can also reduce the Max-Forwards for the OPTIONS request as form of traceroute, but since some B2BUAs reset Max-Forwards that doesn't always work. [Qin]: So your proposal can works when some B2BUA reset Max-Forward? > 6. Why B2BUA1 at the one end should care about how many paths it can go through to the B2BUA2 at the other end? Isn't SIP request routed in the transparent manner? If you mean in draft-kaplan-dispatch-sip-traceroute-00, the purpose is for troubleshooting. There will obviously be strict rules/policies on B2BUAs that support this draft as to whether they accept such requests and from whom, and when. For example I doubt they'd let user/consumer UAs perform this test - more like only operator/administrator test devices. And obviously if the operator doesn't want to let anyone do this they can just not enable it to begin with. [Qin]: Agree. But do you believe the information about B2BUAs in the path regarding whether they accept such requests and from whom (topological information about the path), and when should be reported to the operator test devices instead of consumer device? How this formation help troubleshooting and pinpoint the root of loop back? > 7. How many B2BUAs from one end to the other end should be traversed in the path? There's no limit in theory, though in practice I think the default Max-Forwards value of 70 is reasonably high enough never to be reached for good calls. [Qin]: I see and agree. -hadriel From mary.ietf.barnes@gmail.com Thu Dec 8 12:28:08 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E444421F8C0A for ; Thu, 8 Dec 2011 12:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph4q2JVhjmvs for ; Thu, 8 Dec 2011 12:28:08 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81C21F8C0D for ; Thu, 8 Dec 2011 12:28:08 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1933103vcb.31 for ; Thu, 08 Dec 2011 12:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dBd162erjj4y1Ui6WFy+RaI9ptJUaIsiJstaQ8+FSZo=; b=Fu/M/VHZw47lF9uljqG+VEm3wt4QSD/xhFmN2x8RwebPuj56TqzKn4n5k0ll2B4y9O i/T50Xp0RpTvaePRDSkRN6TZxyuAkJDg7qw6eKhKEErMueQYVPiiXe90FhM1EVgHt5kP FtGJwSraT7TH+pES4sWc7sdpMuS+1qHWBjY38= MIME-Version: 1.0 Received: by 10.220.108.197 with SMTP id g5mr549777vcp.44.1323376087606; Thu, 08 Dec 2011 12:28:07 -0800 (PST) Received: by 10.52.111.34 with HTTP; Thu, 8 Dec 2011 12:28:07 -0800 (PST) Date: Thu, 8 Dec 2011 14:28:07 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: rai-ads@tools.ietf.org Subject: [dispatch] Deadlines for IETF-83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:28:09 -0000 Hi folks, As presented in Taipei and per the wiki, the deadlines for IETF-83 are as follows: http://trac.tools.ietf.org/wg/dispatch/trac/wiki * Jan 16th, 2012. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to deadline for scheduling WG sessions] * Jan 23, 2012. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics] * Feb 6, 2012. Topics that are to be the focus of IETF-83 are announced. [One week before AD BoF approval, 4 weeks before -00 deadline, *one week* after deadline for requesting WG session] * March 5, 2012. -00 draft deadline. * March 12, 2012, 2011. Draft deadline. So, please send proposals ASAP and comment on those topics that were posted after the IETF-82 deadlines (e.g., STRAW). The sooner discussion is started, the better prepared we will be to dispatch the item before or at the meeting. Thanks, Mary DISPATCH WG co-chair From HKaplan@acmepacket.com Fri Dec 9 12:52:02 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDF521F8AD2 for ; Fri, 9 Dec 2011 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWI-OX7ijYaV for ; Fri, 9 Dec 2011 12:52:02 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 17CAF21F843C for ; Fri, 9 Dec 2011 12:52:01 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Dec 2011 15:51:57 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 9 Dec 2011 15:51:57 -0500 From: Hadriel Kaplan To: Qin Wu Thread-Topic: Comments on Straw WG proposal and related deliverals Thread-Index: AQHMtrRjV+cjH7gtI02T9tX4IirrvQ== Date: Fri, 9 Dec 2011 20:51:56 +0000 Message-ID: <3ED586B1-B2E8-459D-B29B-8653DE38DFC2@acmepacket.com> References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <517E56620A3DF84BAD87DD425521E815@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:52:02 -0000 Hi Qin, I'm splitting the email into two responses: one for the loop detection and = a separate one for the traceroute topic. This is about the loop detection... On Dec 6, 2011, at 3:25 AM, Qin Wu wrote: > [Qin]: In the loop detection mechanism you proposed, How do you prevent s= ome bad B2BUAs in the path without support of loop mechanism resetting the= MAX-Forward value or you need to assume all the B2BUAs in the path should = support loop detection mechanism you proposed? If a B2BUA along the loop-path doesn't follow the draft and instead resets = the Max-Forwards value, then the loop won't be detected by that mechanism. = That's no worse than not publishing the draft, but obviously no better eit= her. In the cases of loops I've seen occur in actual deployments, it doesn= 't cross that many B2BUAs before it loops - usually it's a loop that could = be prevented if only one or two B2BUAs would stop resetting Max-Forwards. > Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-= 00, how loop is detected by one B2BUA initiating the Invite message? Is it = indicated by the value of Max-Forward and via header? Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2BUA-= 1 due to a conflicting route table. By "sends it" I mean the B2BUA receive= s an INVITE on its UAS side and generates an INVITE on its UAC side based o= n that received one, with some headers the same but with new Call-ID/tags/V= ia/Contact/etc. If both B2BUAs reset the Max-Forwards to 70 every time the= y send it to each other, this creates an infinite loop because they'll just= keep generating INVITEs to each other until they run out of CPU. If, on t= he other hand, each B2BUA copied and decremented the Max-Forwards from the = received INVITE into the new INVITE they send, as SIP Proxies do, then the = MAx-Forwards would eventually reach the value 0 and whichever B2BUA receive= s that will reject the INVITE and thus stop the loop from becoming infinite= . The Via header can't be used for this, because it doesn't (and arguably sho= uldn't) get copied by B2BUAs from a received INVITE on their UAS side to a = new one on their UAC side. -hadriel= From HKaplan@acmepacket.com Fri Dec 9 13:25:52 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EEC1F0C52 for ; Fri, 9 Dec 2011 13:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpRzc1GRT9oo for ; Fri, 9 Dec 2011 13:25:51 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 594461F0C4D for ; Fri, 9 Dec 2011 13:25:51 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 9 Dec 2011 16:25:48 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 9 Dec 2011 16:25:48 -0500 From: Hadriel Kaplan To: Qin Wu Thread-Topic: Comments on Straw WG proposal and related deliverals Thread-Index: AQHMtrkdRX1WTVRZBEC7bFd4H3dDxg== Date: Fri, 9 Dec 2011 21:25:47 +0000 Message-ID: <3AEF0B46-C1CE-446F-B265-07CCC93789FA@acmepacket.com> References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <815E8427B6145C41B7FCF141F96DC6C4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 21:25:52 -0000 On Dec 6, 2011, at 3:25 AM, Qin Wu wrote: >> 3. What's the difference between end to end media loopback and hop by ho= p media loopback? what message signaling exchange looks like? >=20 > End-to-end media-loopback would be just a media-loopback session based on= draft-ietf-mmusic-media-loopback-16, and thus a session to the target of t= he request. So for example if you make a loopback test call to +1781555121= 2, then your SIP INVITE request would reach the UAS representing +178155512= 12, and that UAS would loop media back to you. Hop-by-hop is where you'd m= ake a loopback test call to +17815551212, but the first time you'd make it = the first media-plane B2BUA along the path to +17815551212 would actually a= nswer the call and loop media to you; the second time you'd make it the sec= ond B2BUA along the path would answer the call, and so on until you'd final= ly reach +17815551212. That way you can test the signaling+media path on a= hop-by-hop basis towards the target destination. >=20 > [Qin]: Good example, Now I know their difference. > But one more question is: >=20 > why each B2BUAs in the path more close to the user/consumer device answer= the=20 > call on behalf of UAS representing +17815551212? Is that=20 > becos this is test signaling? or new SIP request type only for test? In the traceroute case, you'd have a test-device/phone that generates the c= all using a B2bua-Hops header value of 1, then a value of 2, then 3, and so= on each time it makes the test call. The rest of the message appears exac= tly the same as a normal loopback call - i.e., it is an INVITE to the final= target with other headers being normal, etc. >> 4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you i= ntend to drop these header extension or reuse these header extension and fi= ll the missing part? >=20 > I don't know what you mean - where do I say there's a missing feature? >=20 > [Qin]: That's what you mentioned in the open issue section 5 of draft-kap= lan-dispatch-sip-traceroute. > The question is do you want to fix MAX-Forward or Do you want to define n= ew header extension? > This is a little contradict to me when reading draft-kaplan-dispatch-b2bu= a-loop-detection and draft-kaplan-dispatch-sip-traceroute. > It looks to me in draft-kaplan-dispatch-b2bua-loop-detection, it propose = additional new behavior for B2BUAs without any change to MAX-Forward=20 > while in the draft-kaplan-dispatch-sip-traceroute, it seems it propose so= me new header extension? Ahh, I see. Right, today Max-Forwards can't be used for this traceroute co= ncept because devices reset the Max-Forwards value. The loop detection dra= ft is an attempt to "fix" that. So the open question for the traceroute dr= aft is whether it should use Max-Forwards and hope all b2bua's implement th= e loop-detection draft, or whether it should use a new header like "B2bua-H= ops". >> 5. Is there any tools at the SIP level like trace route and ping to test= the path reachability? >=20 > Sort of, but not always. You can just send OPTIONS requests as a form of= "ping", but not all devices support it and it's not always clear that the = OPTIONS got the whole way to the target (I've been told some B2BUAs answer = OPTIONS not targeted at them). If OPTIONs works, you can also reduce the M= ax-Forwards for the OPTIONS request as form of traceroute, but since some B= 2BUAs reset Max-Forwards that doesn't always work. >=20 > [Qin]: So your proposal can works when some B2BUA reset Max-Forward? Yes, the traceroute draft currently doesn't rely on Max-Forwards, because i= t uses a new header. Of course the new header has to make it through b2bua= 's (not be deleted), but they don't all have to decrement its value or unde= rstand it (only b2bua's which want to answer the traceroute/loopback call w= ould have to do that). >> 6. Why B2BUA1 at the one end should care about how many paths it can go = through to the B2BUA2 at the other end? Isn't SIP request routed in the tra= nsparent manner? >=20 > If you mean in draft-kaplan-dispatch-sip-traceroute-00, the purpose is fo= r troubleshooting. There will obviously be strict rules/policies on B2BUAs= that support this draft as to whether they accept such requests and from w= hom, and when. For example I doubt they'd let user/consumer UAs perform th= is test - more like only operator/administrator test devices. And obviousl= y if the operator doesn't want to let anyone do this they can just not enab= le it to begin with. >=20 > [Qin]: Agree. But do you believe the information about B2BUAs in the path= regarding whether they accept such requests and from whom (topological inf= ormation about the path), and when should be reported to the operator test = devices instead of consumer device? How this formation help troubleshooting= and pinpoint the root of loop back? I think those types of decisions are policies decided on by the administrat= ors of the b2bua's, rather than something to put in the draft. It's up to = the admin to decide who/what/where/when. Is that what you're asking? (i.e.= , does that answer your question, or am I not understanding your question?) -hadriel= From bill.wu@huawei.com Mon Dec 12 00:32:40 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363DA21F8A80 for ; Mon, 12 Dec 2011 00:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.303 X-Spam-Level: X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxhceqK3+qiH for ; Mon, 12 Dec 2011 00:32:39 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE621F8A67 for ; Mon, 12 Dec 2011 00:32:38 -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 <0LW300FN8126E3@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 12 Dec 2011 16:32:30 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW3005RS123AE@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 12 Dec 2011 16:32:30 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT90153; Mon, 12 Dec 2011 16:32:29 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 16:32:28 +0800 Received: from w53375q (10.138.41.130) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 16:32:28 +0800 Date: Mon, 12 Dec 2011 16:32:27 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Hadriel Kaplan Message-id: <623E45210CDC4C4982A24C5CF1C391D7@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3ED586B1-B2E8-459D-B29B-8653DE38DFC2@acmepacket.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 08:32:40 -0000 Hi, Hadriel: ----- Original Message ----- >From: "Hadriel Kaplan" >To: "Qin Wu" >Cc: >Sent: Saturday, December 10, 2011 4:51 AM >Subject: Re: Comments on Straw WG proposal and related deliverals >Hi Qin, >I'm splitting the email into two responses: one for the loop detection and a separate one for the traceroute topic. >This is about the loop detection... >On Dec 6, 2011, at 3:25 AM, Qin Wu wrote: >> [Qin]: In the loop detection mechanism you proposed, How do you prevent some bad B2BUAs in the path without support of loop mechanism resetting the MAX-Forward value or you need to assume >all the B2BUAs in the path should support loop detection mechanism you proposed? >If a B2BUA along the loop-path doesn't follow the draft and instead resets the Max-Forwards value, then the loop won't be detected by that mechanism. That's no worse than not publishing the draft, but >obviously no better either. In the cases of loops I've seen occur in actual deployments, it doesn't cross that many B2BUAs before it loops - usually it's a loop that could be prevented if only one or two >B2BUAs would stop resetting Max-Forwards. [Qin]: Really?, I am not sure how many B2BUAs really get invloved in the SIP session call? Suppose Alice place a call to Bob, B2BUA1 is near to Alice and B2BUA2 is near to Bob, both B2BUA2 and B2BUA follow the mechanism in your draft(i.e., stop reseting Max-Forwards), but there is a bad B2BUA3 does not follow this rule(i.e., always reseting Max-Fowards), the Invite message always pass through this bad B2BUA3, How do you prevent such loop? But I agree with B2BUA on two sides support stopping reseting Max-Foward can alleviate loop harm if loop does happen. > Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via >header? >Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2BUA-1 due to a conflicting route table. By "sends it" I mean the B2BUA receives an INVITE on its UAS side and >generates an INVITE on its UAC side based on that received one, with some headers the same but with new Call-ID/tags/Via/Contact/etc. If both B2BUAs reset the Max-Forwards to 70 every time they >send it to each other, this creates an infinite loop because they'll just keep generating INVITEs to each other until they run out of CPU. If, on the other hand, each B2BUA copied and decremented the >Max-Forwards from the received INVITE into the new INVITE they send, as SIP Proxies do, then the MAx-Forwards would eventually reach the value 0 and whichever B2BUA receives that will reject >the INVITE and thus stop the loop from becoming infinite. [Qin]: How B2BUA behavior to deal with Max foward is different from UAC behavior to deal with Max Forward specified in the section 8.1.1.6 of RFC3261 and other Max Foward specifiction described in the section 16.3 and section 16.6 of RFC3261 " 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. " " 16.3 Request Validation 3. Max-Forwards check The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse. If the request does not contain a Max-Forwards header field, this check is passed. If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed. If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response. " " 16.6 Request Forwarding 3. Max-Forwards If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. Some existing UAs will not provide a Max-Forwards header field in a request. " It is better to specify the Max-Foward behavior difference between this draft and RFC3261. Is it compliant with what it said in the RFC3261? since B2BUA has two role, i.e., comination of UAC and UAS. Also I am aware this draft doesn't explain how loop is detected. Does this mean this draft follows the mechanism specifed in the RFC3261 " 16.3 Request Validation 4. Optional Loop Detection check An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent- by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response. " " 16.6 Request Fowarding 8. Add a Via header field value The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy. Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter. A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and distinguish loops from spirals. Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy- Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3). " Also when I read section 8.2.2.2 of RFC3261, I am confused, it said: " 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. " Is it for loop detection or for duplication request detection? >>The Via header can't be used for this, because it doesn't (and arguably shouldn't) get copied by B2BUAs from a received INVITE on their UAS side to a new one on their UAC side. [Qin]: Okay, so what's the standard behavior for proxy to deal with Via header in RFC3261? The reasonable to ask this question is B2BUA is not simply acting as a proxy or a server. -hadriel= From bill.wu@huawei.com Mon Dec 12 01:28:14 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2A21F8A7E for ; Mon, 12 Dec 2011 01:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAOL0cp8oXQM for ; Mon, 12 Dec 2011 01:28:14 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1652421F8AF3 for ; Mon, 12 Dec 2011 01:28:13 -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 <0LW300GWM3JNAI@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 12 Dec 2011 17:26:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW300EEN3JNQP@szxga04-in.huawei.com> for dispatch@ietf.org; Mon, 12 Dec 2011 17:26:11 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFP57003; Mon, 12 Dec 2011 17:26:10 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 17:26:09 +0800 Received: from w53375q (10.138.41.130) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 17:26:07 +0800 Date: Mon, 12 Dec 2011 17:26:06 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Hadriel Kaplan Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3AEF0B46-C1CE-446F-B265-07CCC93789FA@acmepacket.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 09:28:14 -0000 Hi, Hadriel: ----- Original Message ----- From: "Hadriel Kaplan" To: "Qin Wu" Cc: Sent: Saturday, December 10, 2011 5:25 AM Subject: Re: Comments on Straw WG proposal and related deliverals On Dec 6, 2011, at 3:25 AM, Qin Wu wrote: >> 3. What's the difference between end to end media loopback and hop by hop media loopback? what message signaling exchange looks like? > > End-to-end media-loopback would be just a media-loopback session based on draft-ietf-mmusic-media-loopback-16, and thus a session to the target of the request. So for example if you make a loopback test call to +17815551212, then your SIP INVITE request would reach the UAS representing +17815551212, and that UAS would loop media back to you. Hop-by-hop is where you'd make a loopback test call to +17815551212, but the first time you'd make it the first media-plane B2BUA along the path to +17815551212 would actually answer the call and loop media to you; the second time you'd make it the second B2BUA along the path would answer the call, and so on until you'd finally reach +17815551212. That way you can test the signaling+media path on a hop-by-hop basis towards the target destination. > > [Qin]: Good example, Now I know their difference. > But one more question is: > > why each B2BUAs in the path more close to the user/consumer device answer the > call on behalf of UAS representing +17815551212? Is that > becos this is test signaling? or new SIP request type only for test? In the traceroute case, you'd have a test-device/phone that generates the call using a B2bua-Hops header value of 1, then a value of 2, then 3, and so on each time it makes the test call. The rest of the message appears exactly the same as a normal loopback call - i.e., it is an INVITE to the final target with other headers being normal, etc. [Qin]: That is to say each time you make the test call, the test call will reach each B2BUA that support new header in the path one by one. One followup question how does B2BUA answer the test call? what kind of information should be sent from the B2BUA that support new header? B2BUA keeps state of new header value for each user? >> 4. What is missing feature in "MAX-Forward" and "MAX-Breadth" ? Do you intend to drop these header extension or reuse these header extension and fill the missing part? > > I don't know what you mean - where do I say there's a missing feature? > > [Qin]: That's what you mentioned in the open issue section 5 of draft-kaplan-dispatch-sip-traceroute. > The question is do you want to fix MAX-Forward or Do you want to define new header extension? > This is a little contradict to me when reading draft-kaplan-dispatch-b2bua-loop-detection and draft-kaplan-dispatch-sip-traceroute. > It looks to me in draft-kaplan-dispatch-b2bua-loop-detection, it propose additional new behavior for B2BUAs without any change to MAX-Forward > while in the draft-kaplan-dispatch-sip-traceroute, it seems it propose some new header extension? Ahh, I see. Right, today Max-Forwards can't be used for this traceroute concept because devices reset the Max-Forwards value. The loop detection draft is an attempt to "fix" that. So the open question for the traceroute draft is whether it should use Max-Forwards and hope all b2bua's implement the loop-detection draft, or whether it should use a new header like "B2bua-Hops". [Qin]: Does this means Max-Fowards behavior for B2BUA and B2BUA-Hops are two competing mechanisms for the same goal? shall we allow both? >> 5. Is there any tools at the SIP level like trace route and ping to test the path reachability? > > Sort of, but not always. You can just send OPTIONS requests as a form of "ping", but not all devices support it and it's not always clear that the OPTIONS got the whole way to the target (I've been told some B2BUAs answer OPTIONS not targeted at them). If OPTIONs works, you can also reduce the Max-Forwards for the OPTIONS request as form of traceroute, but since some B2BUAs reset Max-Forwards that doesn't always work. > > [Qin]: So your proposal can works when some B2BUA reset Max-Forward? Yes, the traceroute draft currently doesn't rely on Max-Forwards, because it uses a new header. Of course the new header has to make it through b2bua's (not be deleted), but they don't all have to decrement its value or understand it (only b2bua's which want to answer the traceroute/loopback call would have to do that). [Qin]: How do you guarantee that the new header can traverse B2BUA? what if one proxy or B2BUA that doesn't support new header between two sides discard the message that carry the new header ? or you just assume the proxy will not drop the new header even the proxy doesn't understand the new header? >> 6. Why B2BUA1 at the one end should care about how many paths it can go through to the B2BUA2 at the other end? Isn't SIP request routed in the transparent manner? > > If you mean in draft-kaplan-dispatch-sip-traceroute-00, the purpose is for troubleshooting. There will obviously be strict rules/policies on B2BUAs that support this draft as to whether they accept such requests and from whom, and when. For example I doubt they'd let user/consumer UAs perform this test - more like only operator/administrator test devices. And obviously if the operator doesn't want to let anyone do this they can just not enable it to begin with. > > [Qin]: Agree. But do you believe the information about B2BUAs in the path regarding whether they accept such requests and from whom (topological information about the path), and when should be reported to the operator test devices instead of consumer device? How this formation help troubleshooting and pinpoint the root of loop back? I think those types of decisions are policies decided on by the administrators of the b2bua's, rather than something to put in the draft. It's up to the admin to decide who/what/where/when. Is that what you're asking? (i.e., does that answer your question, or am I not understanding your question?) [Qin]: Just be curious, but I am okay with your answer.:-) -hadriel= From HKaplan@acmepacket.com Mon Dec 12 15:10:32 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956721F850B for ; Mon, 12 Dec 2011 15:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzlpJOQ5x1VV for ; Mon, 12 Dec 2011 15:10:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E024D21F8500 for ; Mon, 12 Dec 2011 15:10:26 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Dec 2011 18:10:23 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.110]) with mapi id 14.01.0270.001; Mon, 12 Dec 2011 18:10:23 -0500 From: Hadriel Kaplan To: Qin Wu Thread-Topic: Comments on Straw WG proposal and related deliverals Thread-Index: AQHMuSM5U4bFDTUjaU+ogjEgvRrhpw== Date: Mon, 12 Dec 2011 23:10:23 +0000 Message-ID: <1D713A01-36D2-40B5-BFE2-77C889A3FC8D@acmepacket.com> References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3ED586B1-B2E8-459D-B29B-8653DE38DFC2@acmepacket.com> <623E45210CDC4C4982A24C5CF1C391D7@china.huawei.com> In-Reply-To: <623E45210CDC4C4982A24C5CF1C391D7@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 23:10:32 -0000 On Dec 12, 2011, at 3:32 AM, Qin Wu wrote: >> If a B2BUA along the loop-path doesn't follow the draft and instead rese= ts the Max-Forwards value, then the loop won't be detected by that mechanis= m. That's no worse than not publishing the draft, but >obviously no better= either. In the cases of loops I've seen occur in actual deployments, it d= oesn't cross that many B2BUAs before it loops - usually it's a loop that co= uld be prevented if only one or two >B2BUAs would stop resetting Max-Forwar= ds. >=20 > [Qin]: Really?, I am not sure how many B2BUAs really get invloved in the = SIP session call? Suppose Alice place a call to Bob, B2BUA1 is near to Alic= e and B2BUA2 is near to Bob, both B2BUA2 and B2BUA follow the mechanism in = your draft(i.e., stop reseting Max-Forwards), but there is a bad B2BUA3 doe= s not follow this rule(i.e., always reseting Max-Fowards), the Invite messa= ge always pass through this bad B2BUA3, How do you prevent such loop? Of course if N number of B2BUAs are involved in a loop, then N number have = to decrement Max-Forwards. But I was talking about in practice how many ar= e usually involved in the loop - note I said "involved in the loop", not ho= w many B2BUAs does a request traverse. In other words, a call from Alice t= o Bob typically goes through many B2BUAs, but what matters is how many are = part of the loop itself. If the loop is because B2BUA3 sends it to B2BUA2 = and B2BUA2 sends it back to B2BUA3 and B3BUA3 sends it back to B2BUA2, then= B2BUA2 and B2BUA3 could stop the loop if they decremented Max-Forwards, ev= en if B2BUA1 did not. >> Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection= -00, how loop is detected by one B2BUA initiating the Invite message? Is it= indicated by the value of Max-Forward and via >header? >=20 >> Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2B= UA-1 due to a conflicting route table. By "sends it" I mean the B2BUA rece= ives an INVITE on its UAS side and >generates an INVITE on its UAC side bas= ed on that received one, with some headers the same but with new Call-ID/ta= gs/Via/Contact/etc. If both B2BUAs reset the Max-Forwards to 70 every time= they >send it to each other, this creates an infinite loop because they'll= just keep generating INVITEs to each other until they run out of CPU. If,= on the other hand, each B2BUA copied and decremented the >Max-Forwards fro= m the received INVITE into the new INVITE they send, as SIP Proxies do, the= n the MAx-Forwards would eventually reach the value 0 and whichever B2BUA r= eceives that will reject >the INVITE and thus stop the loop from becoming i= nfinite. >=20 >=20 > [Qin]:=20 > How B2BUA behavior to deal with Max foward is different from UAC behavior= to deal with Max Forward specified in the section 8.1.1.6 of RFC3261 and o= ther Max Foward specifiction described in the section 16.3 and section 16.= 6 of RFC3261 > It is better to specify the Max-Foward behavior difference between this d= raft and RFC3261. Is it compliant with what it said in the RFC3261? since = B2BUA has two role, i.e., comination of UAC and UAS. >=20 I believe one could claim the draft clarifies RFC 3261, without changing it= . But I'd be fine with claiming it updated it instead. I don't much care = either way. > Also I am aware this draft doesn't explain how loop is detected. Does thi= s mean this draft follows the mechanism specifed in the RFC3261 The draft currently uses the Max-Forwards reaching the value 0 as a loop de= tection. > Is it for loop detection or for duplication request detection? The "Merged Request" portion of 3261 is about the same request reaching the= same UAS twice due to forking. It's not about B2BUAs, although a B2BUA's = UAS portion needs to handle Merged Requests.=20 (really very little of 3261 considered B2BUAs) >>> The Via header can't be used for this, because it doesn't (and arguably= shouldn't) get copied by B2BUAs from a received INVITE on their UAS side t= o a new one on their UAC side. >=20 > [Qin]: Okay, so what's the standard behavior for proxy to deal with Via h= eader in RFC3261? The reasonable to ask this question is B2BUA is not simpl= y acting as a proxy or a server. RFC 3261 provides Proxies with an optional-to-implement loop detection mech= anism using the Via header. RFC 5393 strengthened that by requiring forkin= g Proxies to implement that check, but not non-forking proxies. And neithe= r 3261 nor 5393 require B2BUAs to perform such a check. -hadriel From HKaplan@acmepacket.com Mon Dec 12 15:21:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57D821F858C for ; Mon, 12 Dec 2011 15:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9zrJN5bnxP9 for ; Mon, 12 Dec 2011 15:21:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 323A021F8541 for ; Mon, 12 Dec 2011 15:21:31 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Dec 2011 18:21:30 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.110]) with mapi id 14.01.0270.001; Mon, 12 Dec 2011 18:21:30 -0500 From: Hadriel Kaplan To: Qin Wu Thread-Topic: Comments on Straw WG proposal and related deliverals Thread-Index: AQHMuSTGU4bFDTUjaU+ogjEgvRrhpw== Date: Mon, 12 Dec 2011 23:21:29 +0000 Message-ID: <25639A8E-0D9F-4C19-BBA3-8AEDBF4BF3A0@acmepacket.com> References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3AEF0B46-C1CE-446F-B265-07CCC93789FA@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <34B98E5211140F4886564CB17816F000@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 23:21:32 -0000 On Dec 12, 2011, at 4:26 AM, Qin Wu wrote: > In the traceroute case, you'd have a test-device/phone that generates the= call using a B2bua-Hops header value of 1, then a value of 2, then 3, and = so on each time it makes the test call. The rest of the message appears ex= actly the same as a normal loopback call - i.e., it is an INVITE to the fin= al target with other headers being normal, etc. >=20 > [Qin]: That is to say each time you make the test call, the test call wil= l reach each B2BUA that support new header in the path one by one. One foll= owup question how does B2BUA answer the test call? > what kind of information should be sent from the B2BUA that support new h= eader? B2BUA keeps state of new header value for each user? =20 Nope. No state needs to be stored in the B2BUAs. The test-device/UAC maki= ng the test calls keeps track of what B2bua-hops header value is uses in ea= ch test call it tries. Basically this whole model follows the same model o= f ICMP Traceroute done by hosts today: when you do a "traceroute 1.2.3.4", = your PC starts with an ICMP Echo request using a TTL of 1, and the first ho= p it reaches responds with TTL expired, then your PC sends another ICMP wit= h a TTL of 2, and the second IP hop responds, and so on. So in the SIP cas= e, your tester would generate a SIP call to the target with a B2bua-hops of= 0, then 1, then 2. Each time it is a new SIP dialog request, so it gets n= ew Call-ID and tags, etc., but to the same target number. > Ahh, I see. Right, today Max-Forwards can't be used for this traceroute = concept because devices reset the Max-Forwards value. The loop detection d= raft is an attempt to "fix" that. So the open question for the traceroute = draft is whether it should use Max-Forwards and hope all b2bua's implement = the loop-detection draft, or whether it should use a new header like "B2bua= -Hops". >=20 > [Qin]: Does this means Max-Fowards behavior for B2BUA and B2BUA-Hops are = two competing mechanisms for the same goal? shall we allow both? No, the two drafts are not competing for the same goal - it's just that the= means of performing traceroute testing might be achievable using Max-Forwa= rds if we think the loop-detection draft is likely to be implemented. But = you'd still need both drafts, separately. > Yes, the traceroute draft currently doesn't rely on Max-Forwards, because= it uses a new header. Of course the new header has to make it through b2b= ua's (not be deleted), but they don't all have to decrement its value or un= derstand it (only b2bua's which want to answer the traceroute/loopback call= would have to do that). >=20 > [Qin]: How do you guarantee that the new header can traverse B2BUA? what = if one proxy or B2BUA that doesn't support new header between two sides dis= card the message that carry the new header ? or you just assume the proxy w= ill not drop the new header even the proxy doesn't understand the new heade= r? A "Proxy" would never delete the new header, since a "Proxy" has to follow = RFC 3261 which mandates "Proxies" ignore and do not delete unknown headers.= A B2BUA, however, could delete it of course - there's nothing any draft c= an do about that, no matter what new or old headers/bodies/params/etc. we u= se for anything ever. Such "guarantees" are impossible. BUT, since the po= int of this draft is to help SIP domain administrators manage and troublesh= oot their own networks, then if they want it to work they can tell their B2= BUA vendors to do it, and if their B2BUA vendors want to help their custome= rs then they'll do it, and it would then work. If it's not useful, then pe= ople won't ask their vendors to do it, and it won't happen. -hadriel From bill.wu@huawei.com Mon Dec 12 20:11:35 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF04F21F854E for ; Mon, 12 Dec 2011 20:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsIv3PQEHmK7 for ; Mon, 12 Dec 2011 20:11:35 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AFE3F21F84A8 for ; Mon, 12 Dec 2011 20:11:34 -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 <0LW4004MAJHTN8@szxga04-in.huawei.com> for dispatch@ietf.org; Tue, 13 Dec 2011 12:08:17 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW400KO2JHT3H@szxga04-in.huawei.com> for dispatch@ietf.org; Tue, 13 Dec 2011 12:08:17 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFU29650; Tue, 13 Dec 2011 12:07:59 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Dec 2011 12:07:57 +0800 Received: from w53375q (10.138.41.130) by szxeml422-hub.china.huawei.com (10.82.67.161) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Dec 2011 12:07:58 +0800 Date: Tue, 13 Dec 2011 12:07:57 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Hadriel Kaplan Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3ED586B1-B2E8-459D-B29B-8653DE38DFC2@acmepacket.com> <623E45210CDC4C4982A24C5CF1C391D7@china.huawei.com> <1D713A01-36D2-40B5-BFE2-77C889A3FC8D@acmepacket.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 04:11:35 -0000 Hi, Hadriel: ----- Original Message ----- From: "Hadriel Kaplan" To: "Qin Wu" Cc: Sent: Tuesday, December 13, 2011 7:10 AM Subject: Re: Comments on Straw WG proposal and related deliverals On Dec 12, 2011, at 3:32 AM, Qin Wu wrote: >> If a B2BUA along the loop-path doesn't follow the draft and instead resets the Max-Forwards value, then the loop won't be detected by that mechanism. That's no worse than not publishing the draft, but >obviously no better either. In the cases of loops I've seen occur in actual deployments, it doesn't cross that many B2BUAs before it loops - usually it's a loop that could be prevented if only one or two >B2BUAs would stop resetting Max-Forwards. > > [Qin]: Really?, I am not sure how many B2BUAs really get invloved in the SIP session call? Suppose Alice place a call to Bob, B2BUA1 is near to Alice and B2BUA2 is near to Bob, both B2BUA2 and B2BUA follow the mechanism in your draft(i.e., stop reseting Max-Forwards), but there is a bad B2BUA3 does not follow this rule(i.e., always reseting Max-Fowards), the Invite message always pass through this bad B2BUA3, How do you prevent such loop? Of course if N number of B2BUAs are involved in a loop, then N number have to decrement Max-Forwards. But I was talking about in practice how many are usually involved in the loop - note I said "involved in the loop", not how many B2BUAs does a request traverse. In other words, a call from Alice to Bob typically goes through many B2BUAs, but what matters is how many are part of the loop itself. If the loop is because B2BUA3 sends it to B2BUA2 and B2BUA2 sends it back to B2BUA3 and B3BUA3 sends it back to B2BUA2, then B2BUA2 and B2BUA3 could stop the loop if they decremented Max-Forwards, even if B2BUA1 did not. [Qin]: Sure I believe what you said above. Is there any cases that the mechanism you proposed can not be used to fix the loop problem. Suppose we have 100 loop problems, how many problems we can use the mechanism you proposed to solve? Also further more, I want to know whether there is some downside to use the mechanism you specified in the draft? Is there any impact to the existing deployment that follow RFC3261 for MAX-Forward processing? >> Also it is not clear to me in draft-kaplan-dispatch-b2bua-loop-detection-00, how loop is detected by one B2BUA initiating the Invite message? Is it indicated by the value of Max-Forward and via >header? > >> Let's say B2BUA-1 sends an INVITE to B2BUA-2, which sends it back to B2BUA-1 due to a conflicting route table. By "sends it" I mean the B2BUA receives an INVITE on its UAS side and >generates an INVITE on its UAC side based on that received one, with some headers the same but with new Call-ID/tags/Via/Contact/etc. If both B2BUAs reset the Max-Forwards to 70 every time they >send it to each other, this creates an infinite loop because they'll just keep generating INVITEs to each other until they run out of CPU. If, on the other hand, each B2BUA copied and decremented the >Max-Forwards from the received INVITE into the new INVITE they send, as SIP Proxies do, then the MAx-Forwards would eventually reach the value 0 and whichever B2BUA receives that will reject >the INVITE and thus stop the loop from becoming infinite. > > > [Qin]: > How B2BUA behavior to deal with Max foward is different from UAC behavior to deal with Max Forward specified in the section 8.1.1.6 of RFC3261 and other Max Foward specifiction described in the section 16.3 and section 16.6 of RFC3261 > It is better to specify the Max-Foward behavior difference between this draft and RFC3261. Is it compliant with what it said in the RFC3261? since B2BUA has two role, i.e., comination of UAC and UAS. > I believe one could claim the draft clarifies RFC 3261, without changing it. But I'd be fine with claiming it updated it instead. I don't much care either way. [Qin]: If you really change the RFC3261, it is fair to claim that. But if you don't, it is not harm to make it clear in the document to say the mechanism proposed in the draft is compliant with RFC3261. > Also I am aware this draft doesn't explain how loop is detected. Does this mean this draft follows the mechanism specifed in the RFC3261 The draft currently uses the Max-Forwards reaching the value 0 as a loop detection. [Qin]: Okay. > Is it for loop detection or for duplication request detection? The "Merged Request" portion of 3261 is about the same request reaching the same UAS twice due to forking. It's not about B2BUAs, although a B2BUA's UAS portion needs to handle Merged Requests. (really very little of 3261 considered B2BUAs) [Qin]: Is it a mistake for UAS described in the RFC3261 to generate a 482 (Loop Detected) response rather than generate a response to indicate this is about the same request reaching the same UAS? It looks really confusing to me. >>> The Via header can't be used for this, because it doesn't (and arguably shouldn't) get copied by B2BUAs from a received INVITE on their UAS side to a new one on their UAC side. > > [Qin]: Okay, so what's the standard behavior for proxy to deal with Via header in RFC3261? The reasonable to ask this question is B2BUA is not simply acting as a proxy or a server. RFC 3261 provides Proxies with an optional-to-implement loop detection mechanism using the Via header. RFC 5393 strengthened that by requiring forking Proxies to implement that check, but not non-forking proxies. And neither 3261 nor 5393 require B2BUAs to perform such a check. [Qin]: So B2BUA in your draft doesn't need to do such complicated check, rather than use more simpler way, i.e.,use Max-Forwards reaching the value 0 as a loop detection? am I right? -hadriel From bill.wu@huawei.com Mon Dec 12 23:16:41 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A1B1F0C3F for ; Mon, 12 Dec 2011 23:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0BZ13eZNQSx for ; Mon, 12 Dec 2011 23:16:40 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6B21F86FF for ; Mon, 12 Dec 2011 23:16:40 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW400E5IS7LFZ@szxga05-in.huawei.com> for dispatch@ietf.org; Tue, 13 Dec 2011 15:16:33 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW4001MOS7H0P@szxga05-in.huawei.com> for dispatch@ietf.org; Tue, 13 Dec 2011 15:16:32 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFU40677; Tue, 13 Dec 2011 15:16:31 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Dec 2011 15:16:26 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Dec 2011 15:16:29 +0800 Date: Tue, 13 Dec 2011 15:16:28 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Hadriel Kaplan Message-id: <1553DF9465DB4DBDA6F93538BFD3BAA9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <2A0C30FC-9B55-4762-B3A4-98681654C41B@acmepacket.com> <482C8466-60D1-43D0-AD48-C2FD4EB8490A@edvina.net> <66753CFA-09BB-4D90-8A17-6A124E83FA61@acmepacket.com> <3A44CA32-45A7-4336-BA19-3DE19622FE13@cisco.com> <602F294C-39CF-4DBC-ADAC-CFE17056D3DC@acmepacket.com> <3A790D72-4649-49DC-BD6C-AF836E2B29F5@acmepacket.com> <690E6A3F-3446-42AD-B578-A3559CBE4ED3@edvina.net> <53C87D0ED4B54996B41F18914959B28E@china.huawei.com> <3AEF0B46-C1CE-446F-B265-07CCC93789FA@acmepacket.com> <25639A8E-0D9F-4C19-BBA3-8AEDBF4BF3A0@acmepacket.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on Straw WG proposal and related deliverals X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 07:16:41 -0000 Hi, Hadriel: ----- Original Message ----- From: "Hadriel Kaplan" To: "Qin Wu" Cc: Sent: Tuesday, December 13, 2011 7:21 AM Subject: Re: Comments on Straw WG proposal and related deliverals On Dec 12, 2011, at 4:26 AM, Qin Wu wrote: > In the traceroute case, you'd have a test-device/phone that generates the call using a B2bua-Hops header value of 1, then a value of 2, then 3, and so on each time it makes the test call. The rest of the message appears exactly the same as a normal loopback call - i.e., it is an INVITE to the final target with other headers being normal, etc. > > [Qin]: That is to say each time you make the test call, the test call will reach each B2BUA that support new header in the path one by one. One followup question how does B2BUA answer the test call? > what kind of information should be sent from the B2BUA that support new header? B2BUA keeps state of new header value for each user? Nope. No state needs to be stored in the B2BUAs. The test-device/UAC making the test calls keeps track of what B2bua-hops header value is uses in each test call it tries. Basically this whole model follows the same model of ICMP Traceroute done by hosts today: when you do a "traceroute 1.2.3.4", your PC starts with an ICMP Echo request using a TTL of 1, and the first hop it reaches responds with TTL expired, then your PC sends another ICMP with a TTL of 2, and the second IP hop responds, and so on. So in the SIP case, your tester would generate a SIP call to the target with a B2bua-hops of 0, then 1, then 2. Each time it is a new SIP dialog request, so it gets new Call-ID and tags, etc., but to the same target number. [Qin]: I get your idea. One thing is not clear to me is: in draft-kaplan-dispatch-sip-traceroute , the default value of 70 will be used for the B2bua-Hops header when A SIP User Agent Client MAY generate a B2bua-Hops header field, However as you explained above, for traceroute testing, the SIP User Agent Client generates the call using a B2bua-Hops header value of 1, then a value of 2, then 3, Is there discrepancy here? > Ahh, I see. Right, today Max-Forwards can't be used for this traceroute concept because devices reset the Max-Forwards value. The loop detection draft is an attempt to "fix" that. So the open question for the traceroute draft is whether it should use Max-Forwards and hope all b2bua's implement the loop-detection draft, or whether it should use a new header like "B2bua-Hops". > > [Qin]: Does this means Max-Fowards behavior for B2BUA and B2BUA-Hops are two competing mechanisms for the same goal? shall we allow both? No, the two drafts are not competing for the same goal - it's just that the means of performing traceroute testing might be achievable using Max-Forwards if we think the loop-detection draft is likely to be implemented. But you'd still need both drafts, separately. [Qin]: Sorry, I agree both traceroute and loop detection mechanism are useful and may be complementary with each other. However what I am really asking is whether Max-Forward and B2BUA-Hops is competing? If the loop-detection draft got accepted, does it mean B2BUA-Hops is redundant? or we allow both coexist? > Yes, the traceroute draft currently doesn't rely on Max-Forwards, because it uses a new header. Of course the new header has to make it through b2bua's (not be deleted), but they don't all have to decrement its value or understand it (only b2bua's which want to answer the traceroute/loopback call would have to do that). > > [Qin]: How do you guarantee that the new header can traverse B2BUA? what if one proxy or B2BUA that doesn't support new header between two sides discard the message that carry the new header ? or you just assume the proxy will not drop the new header even the proxy doesn't understand the new header? A "Proxy" would never delete the new header, since a "Proxy" has to follow RFC 3261 which mandates "Proxies" ignore and do not delete unknown headers. A B2BUA, however, could delete it of course - there's nothing any draft can do about that, no matter what new or old headers/bodies/params/etc. we use for anything ever. Such "guarantees" are impossible. BUT, since the point of this draft is to help SIP domain administrators manage and troubleshoot their own networks, then if they want it to work they can tell their B2BUA vendors to do it, and if their B2BUA vendors want to help their customers then they'll do it, and it would then work. If it's not useful, then people won't ask their vendors to do it, and it won't happen. [Qin]: I agree. Thank for your clarification. -hadriel From pravindran@sonusnet.com Tue Dec 13 04:44:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923B221F8AE6 for ; Tue, 13 Dec 2011 04:44:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHgdXWngHzMB for ; Tue, 13 Dec 2011 04:43:59 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 026D921F84B0 for ; Tue, 13 Dec 2011 04:43:47 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pBDCiPhB003392; Tue, 13 Dec 2011 07:44:25 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 07:43:45 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 18:14:17 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Tue, 13 Dec 2011 18:14:17 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "'Hadriel Kaplan'" Thread-Topic: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints Thread-Index: AQHMobqOaTd0AdLxGkakbC/liJa9DZWp4XQAgAF3/ACAAA1LgIAD97kAgAAPhYCAKlAr4A== Date: Tue, 13 Dec 2011 12:44:16 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DABACB@inba-mail01.sonusnet.com> References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> <0E63C2EE-81B6-45CD-8B67-7216DB69DAD7@acmepacket.com> <011601cca486$d1f132c0$75d39840$@packetizer.com> In-Reply-To: <011601cca486$d1f132c0$75d39840$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Dec 2011 12:44:17.0467 (UTC) FILETIME=[ED5068B0:01CCB994] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 12:44:00 -0000 Paul/Hadriel, I understand that most of the folks are interested in session-id for Troubleshooting and logging purposes as per the earlier discussions. I agree with Paul that we will define the rules for session-id and it=20 may not possible to restrict the usage of the session-id to=20 troubleshooting only. But it is important for IETF to make sure that the proposed session-id mechanism does not leads to any new security issues=20 or SIP architectural issues and I'm interested in hearing those caveats=20 in the session-id. In case of SBC kind of devices, it may violates even basic RFC 3261 and so,= =20 IETF may not be enforce any rule to it. On the other hand, SBC is flexible to pass across if "clever mechanism" is proposed by the customer. Thanks Partha >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Paul E. Jones >Sent: Wednesday, November 16, 2011 11:10 PM >To: 'Hadriel Kaplan' >Cc: dispatch@ietf.org >Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to >two endpoints > >Hadriel, > >> > I do not propose that the WG do anything with the Session-ID. I >> > only want us to define one where all devices have a common >> > understanding of what the value is. Once we do that, then we can >> > actually rely on it for something else meaningful. But, that will >> > be another WG and another charter ;-) >> >> The big concern I have with anyone using the Session-ID for anything >> other than troubleshooting/logging, is that SBCs will invariably end >> up having to go change the Session-ID in certain call scenarios to >> purposefully be something that does not match both sides, simply to >> counter-act whatever clever mechanism someone's decided to use >> Session- ID for. There are lots of reasons that could happen, from >> fixing bugs to fixing scenarios their clever scheme didn't take into >> account and breaks stuff for, to just plain not wanting the clever >> mechanism to happen due to some policy reasons. If that happens, we >> lose the ability to use Session-ID for troubleshooting. > >I would hope people do not introduce "clever" mechanisms. I'd very much >like the rules to be well-defined. Once the rules are defined, then we >could use Session-ID for other things, but I would not expect there to >be changes to SIP as a result. For SIP, there should one and only one >way of signaling the Session-ID. With those well-defined rules, then we >should be able to rely on it for other things, but I don't want to >define those other things yet. If all we get is logging, then it's >still worth the effort. I just hope we can use it more broadly. > >> We've gone over examples of cases where that could happen in email >> threads of my earlier Session-ID drafts, which is why I ended up >> changing the drafts to *only* make it used for >logging/troubleshooting. > >If we work through use cases and hit a wall, that would be reason for >concern. I do think we can make it work, though. It would require >functionality on the B2BUA that decides to re-route calls, etc., but >that will happen with time. > >> I know some people in the IETF don't care much about having a header >> value purely for troubleshooting correlation, but we hear this desire >> time and time again from the people who run/manage SIP networks. (I'm >> not saying you don't want that too - I'm just saying a header for >> troubleshooting alone is worth having) > >So, aim high... :) > >Paul > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From paulej@packetizer.com Tue Dec 13 13:26:52 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C1B21F85C7 for ; Tue, 13 Dec 2011 13:26:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+HZlMi5Lffm for ; Tue, 13 Dec 2011 13:26:52 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D822121F8500 for ; Tue, 13 Dec 2011 13:26:51 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pBDLQmUI016840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Dec 2011 16:26:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1323811609; bh=z4hnOg9DQvLecz88v8fK1qowkNFemo6rRyI8ydrVvUI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ui4jM0I5p6tfGMLaXa8Oe+7k0xMVeUhxU+x7rICGEnIso4yiWpgdBzgFw98hqENJL idG78H/E/8xtoTWGa/M/gjvG6CGq2297DlVyJlXcd4Trtybqd9AJDaTt9n0HfycM7g H1JbiOrVFjWQRlrbDwA497EEDArJLYBJG2Zt5h1w= From: "Paul E. Jones" To: "'Ravindran, Parthasarathi'" , "'Hadriel Kaplan'" References: <01af01cca093$ce85e5a0$6b91b0e0$@packetizer.com> <8B269C87-2B41-4F83-A7C9-3443E05E323B@acmepacket.com> <008e01cca1c0$8f3527c0$ad9f7740$@packetizer.com> <98C324EC-A04C-4490-9E5F-A0D44E9C49BA@acmepacket.com> <01d801cca283$3410bf30$9c323d90$@packetizer.com> <0E63C2EE-81B6-45CD-8B67-7216DB69DAD7@acmepacket.com> <011601cca486$d1f132c0$75d39840$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C01DABACB@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DABACB@inba-mail01.sonusnet.com> Date: Tue, 13 Dec 2011 16:26:35 -0500 Message-ID: <030401ccb9dd$e4960650$adc212f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQM4kK2PtwYoA4yO/2keicmD4G9X/gD/RGHTAXK6cSMCLKWx1gJ50BrFAaksWKAB8y/1mAHee8sOAiOixXWSjN+94A== Content-Language: en-us Cc: dispatch@ietf.org Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 21:26:53 -0000 Partha, No matter what the purpose is for a Session-ID, whether it is logging, associating two endpoints in a call, associating media flows with a call, etc., we have the same challenges in trying to define an identifier that is appropriate. What we propose in the Session-ID draft, we believe, meets the requirements and addresses shortcomings in current SIP and H.323 identifiers that were intended to serve the purpose of identifying calls end-to-end. That said, I'm happy to debate the technical aspects of our or other proposals. However, we can't seem to get to a point where we can agree on a charter where we can actually do the work. I understand we don't want a working group that just flounders, but I do not believe that will be the case. I very much want to get the working group started so we can progress the work. Paul > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Tuesday, December 13, 2011 7:44 AM > To: Paul E. Jones; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Subject: RE: [dispatch] Session-Id: Problem 3: A session is limited to > two endpoints > > Paul/Hadriel, > > I understand that most of the folks are interested in session-id for > Troubleshooting and logging purposes as per the earlier discussions. > I agree with Paul that we will define the rules for session-id and it > may not possible to restrict the usage of the session-id to > troubleshooting only. But it is important for IETF to make sure that > the proposed session-id mechanism does not leads to any new security > issues or SIP architectural issues and I'm interested in hearing those > caveats in the session-id. > > In case of SBC kind of devices, it may violates even basic RFC 3261 and > so, IETF may not be enforce any rule to it. On the other hand, SBC is > flexible to pass across if "clever mechanism" is proposed by the > customer. > > Thanks > Partha > > > >-----Original Message----- > >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >Behalf Of Paul E. Jones > >Sent: Wednesday, November 16, 2011 11:10 PM > >To: 'Hadriel Kaplan' > >Cc: dispatch@ietf.org > >Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to > >two endpoints > > > >Hadriel, > > > >> > I do not propose that the WG do anything with the Session-ID. I > >> > only want us to define one where all devices have a common > >> > understanding of what the value is. Once we do that, then we can > >> > actually rely on it for something else meaningful. But, that will > >> > be another WG and another charter ;-) > >> > >> The big concern I have with anyone using the Session-ID for anything > >> other than troubleshooting/logging, is that SBCs will invariably end > >> up having to go change the Session-ID in certain call scenarios to > >> purposefully be something that does not match both sides, simply to > >> counter-act whatever clever mechanism someone's decided to use > >> Session- ID for. There are lots of reasons that could happen, from > >> fixing bugs to fixing scenarios their clever scheme didn't take into > >> account and breaks stuff for, to just plain not wanting the clever > >> mechanism to happen due to some policy reasons. If that happens, we > >> lose the ability to use Session-ID for troubleshooting. > > > >I would hope people do not introduce "clever" mechanisms. I'd very > >much like the rules to be well-defined. Once the rules are defined, > >then we could use Session-ID for other things, but I would not expect > >there to be changes to SIP as a result. For SIP, there should one and > >only one way of signaling the Session-ID. With those well-defined > >rules, then we should be able to rely on it for other things, but I > >don't want to define those other things yet. If all we get is logging, > >then it's still worth the effort. I just hope we can use it more > broadly. > > > >> We've gone over examples of cases where that could happen in email > >> threads of my earlier Session-ID drafts, which is why I ended up > >> changing the drafts to *only* make it used for > >logging/troubleshooting. > > > >If we work through use cases and hit a wall, that would be reason for > >concern. I do think we can make it work, though. It would require > >functionality on the B2BUA that decides to re-route calls, etc., but > >that will happen with time. > > > >> I know some people in the IETF don't care much about having a header > >> value purely for troubleshooting correlation, but we hear this desire > >> time and time again from the people who run/manage SIP networks. (I'm > >> not saying you don't want that too - I'm just saying a header for > >> troubleshooting alone is worth having) > > > >So, aim high... :) > > > >Paul > > > > > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org > >https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Mon Dec 19 09:45:44 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D361F0C4C for ; Mon, 19 Dec 2011 09:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.587 X-Spam-Level: X-Spam-Status: No, score=-97.587 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzN5PgkbDPOj for ; Mon, 19 Dec 2011 09:45:42 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfa.amsl.com (Postfix) with SMTP id 6242A1F0C52 for ; Mon, 19 Dec 2011 09:45:42 -0800 (PST) Received: (qmail 22994 invoked by uid 0); 19 Dec 2011 17:45:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 19 Dec 2011 17:45:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=aXB3LCdzG842gWPE97D8GZMrH/eYhl/6aQ2hgQsff9c=; b=lcPUuSxERUGn2iHcr1HQ5QJG4VH9x5QFMwKz3YhqpiZbvADMT1OOWpQ01PrE7gz0Ta0cGw9q820Wj5lDIWyIRpmVZyyXyuSDcBNuAr9y14EfY+ZJjjgONK5EU0H0k7sI; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RchH5-0005Ac-0K for dispatch@ietf.org; Mon, 19 Dec 2011 10:45:19 -0700 From: "Richard Shockey" To: Date: Mon, 19 Dec 2011 12:45:17 -0500 Message-ID: <00fa01ccbe75$f9222f80$eb668e80$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FB_01CCBE4C.104C2780" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acy+deSz5Xw7G0aTRjCN9Dn2k/+apA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:45:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00FB_01CCBE4C.104C2780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER (Washington, D.C.) - FCC Chairman Julius Genachowski announced today the appointment of Henning Schulzrinne as Chief Technology Officer. FCC Chairman Genachowski said, "I'm delighted that Henning will be joining us. The communications technology revolution is key to our economy and broad opportunity. With the appointment of Henning - a world-class technologist - we extend our commitment to technology excellence at the FCC and to strong engagement with outside technology experts." As Chief Technology Officer, Schulzrinne will guide the FCC's work on technology and engineering issues, together with the FCC's Office of Engineering and Technology. He will advise on matters across the agency to ensure that FCC policies are driving technological innovation, including serving as a resource to FCC Commissioners. He will also help the FCC engage with technology experts outside the agency and promote technical excellence among agency staff. He will be based in the FCC's Office of Strategic Planning and Policy Analysis. Schulzrinne is Julian Clarence Levi Professor of Mathematical Methods and Computer Science and Professor of Engineering at The Fu Foundation School of Engineering at Columbia University. He has been an Engineering Fellow at the FCC since 2010. He has published more than 250 journal and conference papers, and more than 70 Internet Requests for Comment (RFCs). He is widely known for the development of key protocols that enable voice-over-IP (VoIP) and other multimedia applications that are now Internet standards, including the Session Initiation Protocol (SIP). His research interests include Internet multimedia systems, applied network engineering, wireless networks, security, quality of service, and performance evaluation. Schulzrinne received his undergraduate degree in economics and electrical engineering from the Darmstadt University of Technology, Germany, his MSEE degree as a Fulbright scholar from the University of Cincinnati, Ohio and his Ph.D. from the University of Massachusetts in Amherst, Massachusetts. He was a member of technical staff at AT&T Bell Laboratories, Murray Hill and an associate department head at GMD-Fokus (Berlin), before joining the Computer Science and Electrical Engineering departments at Columbia University, New York. He is an IEEE Fellow and a former member of the Internet Architecture Board (IAB). Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_00FB_01CCBE4C.104C2780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FCC NAMES HENNING SCHULZRINNE = CHIEF TECHNOLOGY OFFICER

 

(Washington, D.C.) – FCC = Chairman Julius Genachowski announced today the appointment of = Henning

Schulzrinne as Chief Technology = Officer.

 

FCC Chairman Genachowski said, = “I’m delighted that Henning will be joining us. The = communications

technology revolution is key to = our economy and broad opportunity. With the appointment of Henning = –

a world-class technologist – = we extend our commitment to technology excellence at the FCC and = to

strong engagement with outside = technology experts.”

 

As Chief Technology Officer, = Schulzrinne will guide the FCC’s work on technology and = engineering

issues, together with the = FCC’s Office of Engineering and Technology. He will advise on = matters across

the agency to ensure that FCC = policies are driving technological innovation, including serving as = a

resource to FCC Commissioners. He = will also help the FCC engage with technology experts outside = the

agency and promote technical = excellence among agency staff. He will be based in the FCC’s = Office of

Strategic Planning and Policy = Analysis.

 

Schulzrinne is Julian Clarence = Levi Professor of Mathematical Methods and Computer Science = and

Professor of Engineering at The Fu = Foundation School of Engineering at Columbia University. He = has

been an Engineering Fellow at the = FCC since 2010. He has published more than 250 journal and

conference papers, and more than = 70 Internet Requests for Comment (RFCs). He is widely known for = the

development of key protocols that = enable voice-over-IP (VoIP) and other multimedia applications that = are

now Internet standards, including = the Session Initiation Protocol (SIP). His research interests = include

Internet multimedia systems, = applied network engineering, wireless networks, security, quality of = service,

and performance = evaluation.

 

Schulzrinne received his = undergraduate degree in economics and electrical engineering from = the

Darmstadt University of = Technology, Germany, his MSEE degree as a Fulbright scholar from = the

University of Cincinnati, Ohio and = his Ph.D. from the University of Massachusetts in Amherst,

Massachusetts. He was a member of = technical staff at AT&T Bell Laboratories, Murray Hill and = an

associate department head at = GMD-Fokus (Berlin), before joining the Computer Science and = Electrical

Engineering departments at = Columbia University, New York. He is an IEEE Fellow and a former = member

of the Internet Architecture Board = (IAB).

 

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype-linkedin-facebook: = rshockey101
http//www.sipforum.org

 

------=_NextPart_000_00FB_01CCBE4C.104C2780-- From paulej@packetizer.com Mon Dec 19 10:00:15 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BDB21F8BB5 for ; Mon, 19 Dec 2011 10:00:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeLuVlPpnLr6 for ; Mon, 19 Dec 2011 10:00:13 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 41ADD21F8BAE for ; Mon, 19 Dec 2011 10:00:13 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id pBJI0BZV009067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Dec 2011 13:00:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1324317612; bh=F/q7Sa4ErEBZsrkeU9kDUCltYK1N+yzTRQDuuCh2y+8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=RSev0uJZtt1cPKrAEF8kys9sbAnmX/ig/kfgWJh0/C+h7lZaldc5vHSCijZjyvWZy KKK6cVjfvZaMDq5QmqogZrc+PXGPvsm55ZbFCQq2aj8w0hyTpdQgjHNqCtHGEPIjwm /2Gz6SnT26BwFbSWBPaS0Q2x3oa+2qrpEbNhu/r0= From: "Paul E. Jones" To: Date: Mon, 19 Dec 2011 13:00:09 -0500 Message-ID: <014301ccbe78$0c766360$25632a20$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01CCBE4E.23A193E0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Acy+eAqBbk2BaSs3THClEtyh3UqaQQ== Subject: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:00:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0144_01CCBE4E.23A193E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I've not seen much discussion on this topic over the past month. Even so, I've not seen any objection to proceeding work. The only concern raised recently is around the definition of the word "session", to which we're proposing to make that a part of the first deliverable. What do we need to do in order to move this work forward? Paul PS - The charter text that seems to have reached general acceptance is below End-to-end Session Identifier in SIP (charter proposal) The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP is not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. Consideration must be given to the fact that the entities involved in a communication session might change as a result of service interaction in the network, such as call transfers, joins, etc. A SIP end-to-end Session Identifier has been considered as possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements have also been identified and come directly from other Existing working group within the RAI area (e.g. SIPRec, Splices). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value(s) so that it is possible to identify a call end-to end even when performing interworking between protocols. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification, including the definition of a "session" 2. Specification of new end-to-end Session Identifier mechanism Goal and Milestone: August 2012 - Requirement and use case document sent to the IESG (Informational) March 2013 - Specification of the new mechanism sent to the IESG (PS) ------=_NextPart_000_0144_01CCBE4E.23A193E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I’ve = not seen much discussion on this topic over the past month.  Even = so, I’ve not seen any objection to proceeding work.  The only = concern raised recently is around the definition of the word = “session”, to which we’re proposing to make that a = part of the first deliverable.

 

What do we = need to do in order to move this work forward?

 

Paul

 

PS – = The charter text that seems to have reached general acceptance is = below

 

 

End-to-end Session Identifier in SIP (charter = proposal)

 

The end-to-end Session Identifier in SIP-based = multimedia communication networks refers to the ability for endpoints, = intermediate devices, and management and monitoring system to identify = and correlate SIP messages and dialogs of the same higher-level = end-to-end "communication session" across multiple SIP = devices, hops, and administrative domains.

 

Unfortunately, there are a number of factors that = contribute to the fact that the current dialog identifiers defined in = SIP is not suitable for end-to-end session identification. Perhaps the = most important factor worth describing is that in real-world deployments = Back-to-Back User Agents (B2BUAs) devices like Session Border = Controllers (SBC) often change the call identifiers (e.g., the From-tag = and To-tag that are used in conjunction with the Call-ID header to make = the dialog-id) as the session signaling passes through.

 

An = end-to-end Session Identifier should allow the possibility to identify = the communication session from the point of origin, passing through any = number of intermediaries, to the ultimate point of termination. It = should have the same aim as the From-tag, To-tag and Call-ID = conjunction, but should not be mangled by intermediaries.  = Consideration must be given to the fact that the entities involved in a = communication session might change as a result of service interaction in = the network, such as call transfers, joins, etc.

 

A SIP = end-to-end Session Identifier has been considered as possible solution = of different use cases like troubleshooting, billing, session tracking, = session recording, media and signaling correlation, and so forth.  = Some of these requirements have also been identified and come directly = from other Existing working group within the RAI area (e.g. SIPRec, = Splices).

 

Moreover, other standards organizations have = identified the need for SIP and H.323 to carry the same "session = ID" value(s) so that it is possible to identify a call end-to end = even when performing interworking between protocols.

 

The working = group will produce the following deliverables:

 

1. A = requirement and use case document with key consideration for SIP Session = End-to-End Identification, including the definition of a = "session"

 

2. = Specification of new end-to-end Session Identifier = mechanism

 

Goal and Milestone:

 

August 2012 = - Requirement and use case document sent to the IESG = (Informational)

 

March 2013 - = Specification of the new mechanism sent to the IESG = (PS)

 

 

 

------=_NextPart_000_0144_01CCBE4E.23A193E0-- From pkyzivat@alum.mit.edu Mon Dec 19 10:52:40 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3E21F84BC for ; Mon, 19 Dec 2011 10:52:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ggMUqVUmq4 for ; Mon, 19 Dec 2011 10:52:39 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEA321F84BB for ; Mon, 19 Dec 2011 10:52:37 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id B6Zs1i0050EZKEL5D6sep3; Mon, 19 Dec 2011 18:52:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id B6sd1i00g07duvL3M6se1T; Mon, 19 Dec 2011 18:52:38 +0000 Message-ID: <4EEF87F4.6040304@alum.mit.edu> Date: Mon, 19 Dec 2011 13:52:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <00fa01ccbe75$f9222f80$eb668e80$@us> In-Reply-To: <00fa01ccbe75$f9222f80$eb668e80$@us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:52:40 -0000 On 12/19/11 12:45 PM, Richard Shockey wrote: > *FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER* !!! May he wish for interesting times! I hope this doesn't turn out to be a role for which success is impossible. Best Wishes, Paul > (Washington, D.C.) – FCC Chairman Julius Genachowski announced today the > appointment of Henning > > Schulzrinne as Chief Technology Officer. > > FCC Chairman Genachowski said, “I’m delighted that Henning will be > joining us. The communications > > technology revolution is key to our economy and broad opportunity. With > the appointment of Henning – > > a world-class technologist – we extend our commitment to technology > excellence at the FCC and to > > strong engagement with outside technology experts.” > > As Chief Technology Officer, Schulzrinne will guide the FCC’s work on > technology and engineering > > issues, together with the FCC’s Office of Engineering and Technology. He > will advise on matters across > > the agency to ensure that FCC policies are driving technological > innovation, including serving as a > > resource to FCC Commissioners. He will also help the FCC engage with > technology experts outside the > > agency and promote technical excellence among agency staff. He will be > based in the FCC’s Office of > > Strategic Planning and Policy Analysis. > > Schulzrinne is Julian Clarence Levi Professor of Mathematical Methods > and Computer Science and > > Professor of Engineering at The Fu Foundation School of Engineering at > Columbia University. He has > > been an Engineering Fellow at the FCC since 2010. He has published more > than 250 journal and > > conference papers, and more than 70 Internet Requests for Comment > (RFCs). He is widely known for the > > development of key protocols that enable voice-over-IP (VoIP) and other > multimedia applications that are > > now Internet standards, including the Session Initiation Protocol (SIP). > His research interests include > > Internet multimedia systems, applied network engineering, wireless > networks, security, quality of service, > > and performance evaluation. > > Schulzrinne received his undergraduate degree in economics and > electrical engineering from the > > Darmstadt University of Technology, Germany, his MSEE degree as a > Fulbright scholar from the > > University of Cincinnati, Ohio and his Ph.D. from the University of > Massachusetts in Amherst, > > Massachusetts. He was a member of technical staff at AT&T Bell > Laboratories, Murray Hill and an > > associate department head at GMD-Fokus (Berlin), before joining the > Computer Science and Electrical > > Engineering departments at Columbia University, New York. He is an IEEE > Fellow and a former member > > of the Internet Architecture Board (IAB). > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From marshall.eubanks@gmail.com Mon Dec 19 10:54:15 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1688C21F84C9 for ; Mon, 19 Dec 2011 10:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOz3IjwN+RWy for ; Mon, 19 Dec 2011 10:54:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADC521F84BC for ; Mon, 19 Dec 2011 10:54:13 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2123190obc.31 for ; Mon, 19 Dec 2011 10:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0G9JTn1JE3x8Mg2JcO2vBlg9KFyRERYT1p4FU7PeDog=; b=BKGKdd+3kNHmI0FeaD+PBUhQYTcwMVZxZTh2lCaVvQV333NR5XBr0iY8VrMP5yhh8V KH8h7IsMOQTXo1jTETNYQc1jQxoHCM3mR6G3OksjNFkiw0EJ8bkTPdcNSGNxkdy/9yr7 mOrwvVJSA9vkBATLmESNtwMYVPwUGn83/Z98A= MIME-Version: 1.0 Received: by 10.182.159.99 with SMTP id xb3mr10927279obb.8.1324320853094; Mon, 19 Dec 2011 10:54:13 -0800 (PST) Received: by 10.182.227.67 with HTTP; Mon, 19 Dec 2011 10:54:13 -0800 (PST) In-Reply-To: <4EEF87F4.6040304@alum.mit.edu> References: <00fa01ccbe75$f9222f80$eb668e80$@us> <4EEF87F4.6040304@alum.mit.edu> Date: Mon, 19 Dec 2011 13:54:13 -0500 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:54:15 -0000 On Mon, Dec 19, 2011 at 1:52 PM, Paul Kyzivat wrote= : > On 12/19/11 12:45 PM, Richard Shockey wrote: >> >> *FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER* > > > !!! > > May he wish for interesting times! I don't think he has to wish for them now... Marshall > > I hope this doesn't turn out to be a role for which success is impossible= . > > =A0 =A0 =A0 =A0Best Wishes, > =A0 =A0 =A0 =A0Paul > >> (Washington, D.C.) =96 FCC Chairman Julius Genachowski announced today t= he >> appointment of Henning >> >> Schulzrinne as Chief Technology Officer. >> >> FCC Chairman Genachowski said, =93I=92m delighted that Henning will be >> joining us. The communications >> >> technology revolution is key to our economy and broad opportunity. With >> the appointment of Henning =96 >> >> a world-class technologist =96 we extend our commitment to technology >> excellence at the FCC and to >> >> strong engagement with outside technology experts.=94 >> >> As Chief Technology Officer, Schulzrinne will guide the FCC=92s work on >> technology and engineering >> >> issues, together with the FCC=92s Office of Engineering and Technology. = He >> will advise on matters across >> >> the agency to ensure that FCC policies are driving technological >> innovation, including serving as a >> >> resource to FCC Commissioners. He will also help the FCC engage with >> technology experts outside the >> >> agency and promote technical excellence among agency staff. He will be >> based in the FCC=92s Office of >> >> Strategic Planning and Policy Analysis. >> >> Schulzrinne is Julian Clarence Levi Professor of Mathematical Methods >> and Computer Science and >> >> Professor of Engineering at The Fu Foundation School of Engineering at >> Columbia University. He has >> >> been an Engineering Fellow at the FCC since 2010. He has published more >> than 250 journal and >> >> conference papers, and more than 70 Internet Requests for Comment >> (RFCs). He is widely known for the >> >> development of key protocols that enable voice-over-IP (VoIP) and other >> multimedia applications that are >> >> now Internet standards, including the Session Initiation Protocol (SIP). >> His research interests include >> >> Internet multimedia systems, applied network engineering, wireless >> networks, security, quality of service, >> >> and performance evaluation. >> >> Schulzrinne received his undergraduate degree in economics and >> electrical engineering from the >> >> Darmstadt University of Technology, Germany, his MSEE degree as a >> Fulbright scholar from the >> >> University of Cincinnati, Ohio and his Ph.D. from the University of >> Massachusetts in Amherst, >> >> Massachusetts. He was a member of technical staff at AT&T Bell >> Laboratories, Murray Hill and an >> >> associate department head at GMD-Fokus (Berlin), before joining the >> Computer Science and Electrical >> >> Engineering departments at Columbia University, New York. He is an IEEE >> Fellow and a former member >> >> of the Internet Architecture Board (IAB). >> >> Richard Shockey >> Shockey Consulting >> Chairman of the Board of Directors SIP Forum >> PSTN Mobile: +1 703.593.2683 >> >> skype-linkedin-facebook: rshockey101 >> http//www.sipforum.org >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From hgs@cs.columbia.edu Mon Dec 19 11:05:43 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE8C11E809D for ; Mon, 19 Dec 2011 11:05: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eakg5m8MEBAH for ; Mon, 19 Dec 2011 11:05:43 -0800 (PST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF011E8097 for ; Mon, 19 Dec 2011 11:05:42 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pBJJ5elD002500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Dec 2011 14:05:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Henning Schulzrinne In-Reply-To: <4EEF87F4.6040304@alum.mit.edu> Date: Mon, 19 Dec 2011 14:05:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9FA2BD0E-6670-4A0E-8307-1BC50455E1D3@cs.columbia.edu> References: <00fa01ccbe75$f9222f80$eb668e80$@us> <4EEF87F4.6040304@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: dispatch@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:05:44 -0000 VoIP and related issues will play a major role in the FCC's work in the = next year or two. For example, the FCC Technical Advisory Committee = (TAC) will be looking at the "PSTN transition"; a video of a recent = workshop can be found at http://www.fcc.gov/events/public-switched-telephone-network-transition-0 The Commission needs input from technically-oriented folks. Thus, don't = hesitate to contact me if you or your organization wants to stop by at = the Commission, or you have information you want to share. (FCC staff = meets with both individuals and groups regularly, both within the rule = making process and outside. No campaign donation or JD degree required.) For what it's worth, I've been tasked with outreach to standardization = organizations as one of my responsibilities. Henning On Dec 19, 2011, at 1:52 PM, Paul Kyzivat wrote: > On 12/19/11 12:45 PM, Richard Shockey wrote: >> *FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER* >=20 > !!! >=20 > May he wish for interesting times! >=20 > I hope this doesn't turn out to be a role for which success is = impossible. >=20 > Best Wishes, > Paul From richard@shockey.us Mon Dec 19 11:49:23 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA811E80B9 for ; Mon, 19 Dec 2011 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.926 X-Spam-Level: X-Spam-Status: No, score=-99.926 tagged_above=-999 required=5 tests=[AWL=2.339, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kd70rn1c1nh for ; Mon, 19 Dec 2011 11:49:23 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 1876711E8080 for ; Mon, 19 Dec 2011 11:49:23 -0800 (PST) Received: (qmail 29428 invoked by uid 0); 19 Dec 2011 19:49:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 19 Dec 2011 19:49:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=KsNte8MvMvsdWUViTyg7YbDgkb/gl9zojGYwkNwlLt8=; b=FpoPRY16L6EMOHPoekVCTT6SLCfO/R5GQH4OSfUpQAMhPQfYzu40aXqjEs89j6xeqYlEjrTzjYy0wPyTN5i6u3OcjrXC9mxa6N7m4icfcZXzoRRBl04en8iPnv9GHyu2; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RcjCn-0004eI-4w; Mon, 19 Dec 2011 12:49:01 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <00fa01ccbe75$f9222f80$eb668e80$@us> <4EEF87F4.6040304@alum.mit.edu> <9FA2BD0E-6670-4A0E-8307-1BC50455E1D3@cs.columbia.edu> In-Reply-To: <9FA2BD0E-6670-4A0E-8307-1BC50455E1D3@cs.columbia.edu> Date: Mon, 19 Dec 2011 14:48:58 -0500 Message-ID: <015401ccbe87$4108cd20$c31a6760$@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: Acy+gTZrBBmvjoG+Qwe/FlSzc6ZtOQAA5LfQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:49:23 -0000 And yours truly was the opening act at the Workshop. Henning is absolutely right here. If there was ever a time for the RAI community to reach out the policy folks its now. BTW if you really want to understand what is going on here you can add this to your holiday reading list. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1122/FCC-11-1 61A1.pdf War and Peace without the plot. If it seems overwhelming, it is but regulators have to deal with the law as it is, not as they would prefer it to be. Though some of these issues are US specific I would suspect that other national jurisdictions will start to take up these issues in the upcoming months and years. There are very relevant technical issues our community might have to deal with or certainly clarify. The above order specifically calls out non modification of the SIP headers by forwarding elements as it might relate to billing data such as Calling Party Number or SS7 Charge number. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 19, 2011 2:06 PM To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER VoIP and related issues will play a major role in the FCC's work in the next year or two. For example, the FCC Technical Advisory Committee (TAC) will be looking at the "PSTN transition"; a video of a recent workshop can be found at http://www.fcc.gov/events/public-switched-telephone-network-transition-0 The Commission needs input from technically-oriented folks. Thus, don't hesitate to contact me if you or your organization wants to stop by at the Commission, or you have information you want to share. (FCC staff meets with both individuals and groups regularly, both within the rule making process and outside. No campaign donation or JD degree required.) For what it's worth, I've been tasked with outreach to standardization organizations as one of my responsibilities. Henning On Dec 19, 2011, at 1:52 PM, Paul Kyzivat wrote: > On 12/19/11 12:45 PM, Richard Shockey wrote: >> *FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER* > > !!! > > May he wish for interesting times! > > I hope this doesn't turn out to be a role for which success is impossible. > > Best Wishes, > Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dan-ietf@danyork.org Mon Dec 19 16:34:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898A521F844F for ; Mon, 19 Dec 2011 16:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHniFbFT9tT0 for ; Mon, 19 Dec 2011 16:34:20 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62CD121F844A for ; Mon, 19 Dec 2011 16:34:20 -0800 (PST) Received: by qadb15 with SMTP id b15so2786241qad.10 for ; Mon, 19 Dec 2011 16:34:20 -0800 (PST) Received: by 10.224.192.8 with SMTP id do8mr28670402qab.46.1324341259859; Mon, 19 Dec 2011 16:34:19 -0800 (PST) Received: from [172.20.12.141] (cpe-74-65-173-47.maine.res.rr.com. [74.65.173.47]) by mx.google.com with ESMTPS id dj9sm43510654qab.18.2011.12.19.16.34.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 16:34:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5CBF24C-5CCE-44A5-8C5B-AB4779D9BFCC" From: Dan York In-Reply-To: <9FA2BD0E-6670-4A0E-8307-1BC50455E1D3@cs.columbia.edu> Date: Mon, 19 Dec 2011 19:34:16 -0500 Message-Id: <23E0B149-44AE-4F1F-B414-87D8D3173EEE@danyork.org> References: <00fa01ccbe75$f9222f80$eb668e80$@us> <4EEF87F4.6040304@alum.mit.edu> <9FA2BD0E-6670-4A0E-8307-1BC50455E1D3@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1251.1) Cc: dispatch@ietf.org Subject: [dispatch] Video available for FCC workshops - Re: FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:34:21 -0000 --Apple-Mail=_A5CBF24C-5CCE-44A5-8C5B-AB4779D9BFCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Henning, MANY congrats on your new appointment! I wish you all the best in this = new role ... and certainly may take you up on this invitation below. = I'm very glad with the FCC discussing the PSTN transition to have = someone like you in this role.=20 For those of you interested, the FCC has nicely made available the video = recording for both of the workshops they held this month on the PSTN = transition. The first workshop on December 6th covered primarily issues = related to: 1) public safety; 2) access to networks for folks with = disabilities; 3) challenges facing rural networks; and 4) issues with = edge devices such as alarm systems, consumer devices, etc. The workshop = was about 4 hours in length and the video is available at: http://www.fcc.gov/events/public-switched-telephone-network-transition The second workshop on December 14th was about 6 or 7 hours long and = covered a very wide range of topics. As Richard Shockey mentioned, he = led off the day on behalf of the SIP Forum and was followed by many = others. A full list of panelists is at = http://www.fcc.gov/document/panelists-slated-dec-14-telephone-network-tran= sition-workshop (you have to click the "Expand" button in the lower = right to see the full page). As Henning mentions below, the video is at = the URL: http://www.fcc.gov/events/public-switched-telephone-network-transition-0 Congrats again, Henning! Dan On Dec 19, 2011, at 2:05 PM, Henning Schulzrinne wrote: > VoIP and related issues will play a major role in the FCC's work in = the next year or two. For example, the FCC Technical Advisory Committee = (TAC) will be looking at the "PSTN transition"; a video of a recent = workshop can be found at >=20 > = http://www.fcc.gov/events/public-switched-telephone-network-transition-0 >=20 > The Commission needs input from technically-oriented folks. Thus, = don't hesitate to contact me if you or your organization wants to stop = by at the Commission, or you have information you want to share. (FCC = staff meets with both individuals and groups regularly, both within the = rule making process and outside. No campaign donation or JD degree = required.) >=20 > For what it's worth, I've been tasked with outreach to standardization = organizations as one of my responsibilities. >=20 > Henning >=20 > On Dec 19, 2011, at 1:52 PM, Paul Kyzivat wrote: >=20 >> On 12/19/11 12:45 PM, Richard Shockey wrote: >>> *FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER* >>=20 >> !!! >>=20 >> May he wish for interesting times! >>=20 >> I hope this doesn't turn out to be a role for which success is = impossible. >>=20 >> Best Wishes, >> Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --Apple-Mail=_A5CBF24C-5CCE-44A5-8C5B-AB4779D9BFCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.fcc.gov/events/public-switched-telephone-network-transiti= on

The second workshop on December 14th was = about 6 or 7 hours long and covered a very wide range of topics. As = Richard Shockey mentioned, he led off the day on behalf of the SIP Forum = and was followed by many others.  A full list of panelists is = at http://www.fcc.gov/document/panelists-slated-dec-= 14-telephone-network-transition-workshop (you have to click the = "Expand" button in the lower right to see the full page).  As = Henning mentions below, the video is at the = URL:


Congrats again, = Henning!

Dan


On Dec 19, 2011, at 2:05 PM, Henning Schulzrinne wrote:

VoIP = and related issues will play a major role in the FCC's work in the next = year or two. For example, the FCC Technical Advisory Committee (TAC) = will be looking at the "PSTN transition"; a video of a recent workshop = can be found at

http://www.fcc.gov/events/public-switched-telephone-network-transi= tion-0

The Commission needs input from technically-oriented = folks. Thus, don't hesitate to contact me if you or your organization = wants to stop by at the Commission, or you have information you want to = share. (FCC staff meets with both individuals and groups regularly, both = within the rule making process and outside. No campaign donation or JD = degree required.)

For what it's worth, I've been tasked with = outreach to standardization organizations as one of my = responsibilities.

Henning

On Dec 19, 2011, at 1:52 PM, = Paul Kyzivat wrote:

On 12/19/11 12:45 = PM, Richard Shockey wrote:
*FCC NAMES HENNING SCHULZRINNE = CHIEF TECHNOLOGY OFFICER*

!!!

May he wish for = interesting times!

I hope this = doesn't turn out to be a role for which success is = impossible.

Best = Wishes,
= Paul

__________________________________________= _____
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatc= h

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
To: "dispatch@ietf.org" Thread-Topic: SIP media load balancer requirement Thread-Index: AczAUbSbDDcFGmmuRPiqlrieYjsdqQ== Date: Thu, 22 Dec 2011 02:31:32 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2011 02:31:33.0939 (UTC) FILETIME=[D242F830:01CCC051] Subject: [dispatch] SIP media load balancer requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 02:30:58 -0000 Hi all, As a continuation of IETF-81 Dispatch minutes (http://www.ietf.org/mail-arc= hive/web/dispatch/current/msg03742.html) about SIP load balancing, I though= t of discussing about SIP media servers load balancing as mentioned in the = SIP load balancing proposed charter (http://www.ietf.org/mail-archive/web/d= ispatch/current/msg03615.html). "As SIP request resource consumption in SIP signaling only server varies dr= astically from SIP media servers [3], should the solution be split such tha= t load balancing of a pure signaling server is different than that of a SIP= server that handles signaling as well as media?" SIP media server load balancing solution will be different from signaling o= nly because the downstream resource consumption is mainly because of media = (RTP) than signaling (SIP) and the units to indicate the load balancing in= formation will be different in both solution. There is a need to indicate t= hose media resource consumption to the load balancer in the standard manner= . Please let me know your comment on this. Thanks Partha From pravindran@sonusnet.com Thu Dec 22 05:38:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9021F84D2 for ; Thu, 22 Dec 2011 05:38:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRRC4tEEqo+R for ; Thu, 22 Dec 2011 05:38:01 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93B21F8B0C for ; Thu, 22 Dec 2011 05:38:01 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pBMDcdjQ013792; Thu, 22 Dec 2011 08:38:40 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 08:34:38 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 19:05:16 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Thu, 22 Dec 2011 19:05:15 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "dispatch@ietf.org" Thread-Topic: [dispatch] Revised Proposed Session-ID Charter Thread-Index: Acy+eAqBbk2BaSs3THClEtyh3UqaQQCM0KAg Date: Thu, 22 Dec 2011 13:35:15 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DAE343@inba-mail01.sonusnet.com> References: <014301ccbe78$0c766360$25632a20$@packetizer.com> In-Reply-To: <014301ccbe78$0c766360$25632a20$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.103] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DAE343inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2011 13:35:16.0704 (UTC) FILETIME=[8A7AAE00:01CCC0AE] Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 13:38:04 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DAE343inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, I like to see this charter moving forward. Thanks Partha From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Paul E. Jones Sent: Monday, December 19, 2011 11:30 PM To: dispatch@ietf.org Subject: [dispatch] Revised Proposed Session-ID Charter Folks, I've not seen much discussion on this topic over the past month. Even so, = I've not seen any objection to proceeding work. The only concern raised re= cently is around the definition of the word "session", to which we're propo= sing to make that a part of the first deliverable. What do we need to do in order to move this work forward? Paul PS - The charter text that seems to have reached general acceptance is belo= w End-to-end Session Identifier in SIP (charter proposal) The end-to-end Session Identifier in SIP-based multimedia communication net= works refers to the ability for endpoints, intermediate devices, and manage= ment and monitoring system to identify and correlate SIP messages and dialo= gs of the same higher-level end-to-end "communication session" across multi= ple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact th= at the current dialog identifiers defined in SIP is not suitable for end-to= -end session identification. Perhaps the most important factor worth descri= bing is that in real-world deployments Back-to-Back User Agents (B2BUAs) de= vices like Session Border Controllers (SBC) often change the call identifie= rs (e.g., the From-tag and To-tag that are used in conjunction with the Cal= l-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier should allow the possibility to identify t= he communication session from the point of origin, passing through any numb= er of intermediaries, to the ultimate point of termination. It should have = the same aim as the From-tag, To-tag and Call-ID conjunction, but should no= t be mangled by intermediaries. Consideration must be given to the fact th= at the entities involved in a communication session might change as a resul= t of service interaction in the network, such as call transfers, joins, etc= . A SIP end-to-end Session Identifier has been considered as possible solutio= n of different use cases like troubleshooting, billing, session tracking, s= ession recording, media and signaling correlation, and so forth. Some of t= hese requirements have also been identified and come directly from other Ex= isting working group within the RAI area (e.g. SIPRec, Splices). Moreover, other standards organizations have identified the need for SIP an= d H.323 to carry the same "session ID" value(s) so that it is possible to i= dentify a call end-to end even when performing interworking between protoco= ls. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Sessi= on End-to-End Identification, including the definition of a "session" 2. Specification of new end-to-end Session Identifier mechanism Goal and Milestone: August 2012 - Requirement and use case document sent to the IESG (Informati= onal) March 2013 - Specification of the new mechanism sent to the IESG (PS) --_000_387F9047F55E8C42850AD6B3A7A03C6C01DAE343inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

I like to see this cha= rter moving forward.

 

Thanks

Partha

 

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Monday, December 19, 2011 11:30 PM
To: dispatch@ietf.org
Subject: [dispatch] Revised Proposed Session-ID Charter

 

Folks,

 

I’ve not seen much discussion on this topic ov= er the past month.  Even so, I’ve not seen any objection to proc= eeding work.  The only concern raised recently is around the definitio= n of the word “session”, to which we’re proposing to make that a part of the first deliverable.

 

What do we need to do in order to move this work for= ward?

 

Paul

 

PS – The charter text that seems to have reach= ed general acceptance is below

 

 

End-to-end Session Identifier in SIP (charter pro= posal)

 

The end-to-end Session Identifier in SIP-based multi= media communication networks refers to the ability for endpoints, intermedi= ate devices, and management and monitoring system to identify and correlate= SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple = SIP devices, hops, and administrative domains.

 

Unfortunately, there are a number of factors that co= ntribute to the fact that the current dialog identifiers defined in SIP is = not suitable for end-to-end session identification. Perhaps the most import= ant factor worth describing is that in real-world deployments Back-to-Back User Agents (B2BUAs) devices like S= ession Border Controllers (SBC) often change the call identifiers (e.g., th= e From-tag and To-tag that are used in conjunction with the Call-ID header = to make the dialog-id) as the session signaling passes through.

 

An end-to-end Session Identifier should allow the po= ssibility to identify the communication session from the point of origin, p= assing through any number of intermediaries, to the ultimate point of termi= nation. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled= by intermediaries.  Consideration must be given to the fact that the = entities involved in a communication session might change as a result of se= rvice interaction in the network, such as call transfers, joins, etc.

 

A SIP end-to-end Session Identifier has been conside= red as possible solution of different use cases like troubleshooting, billi= ng, session tracking, session recording, media and signaling correlation, a= nd so forth.  Some of these requirements have also been identified and come directly from other Existing working gr= oup within the RAI area (e.g. SIPRec, Splices).

 

Moreover, other standards organizations have identif= ied the need for SIP and H.323 to carry the same "session ID" val= ue(s) so that it is possible to identify a call end-to end even when perfor= ming interworking between protocols.

 

The working group will produce the following deliver= ables:

 

1. A requirement and use case document with key cons= ideration for SIP Session End-to-End Identification, including the definiti= on of a "session"

 

2. Specification of new end-to-end Session Identifie= r mechanism

 

Goal and Milestone:

 

August 2012 - Requirement and use case document sent= to the IESG (Informational)

 

March 2013 - Specification of the new mechanism sent= to the IESG (PS)

 

 

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C01DAE343inbamail01sonus_-- From richard@shockey.us Thu Dec 22 09:58:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13FE21F8AD6 for ; Thu, 22 Dec 2011 09:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.095 X-Spam-Level: X-Spam-Status: No, score=-101.095 tagged_above=-999 required=5 tests=[AWL=1.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPSN6YSdnTwx for ; Thu, 22 Dec 2011 09:57:58 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 28F0621F8AD1 for ; Thu, 22 Dec 2011 09:57:58 -0800 (PST) Received: (qmail 6989 invoked by uid 0); 22 Dec 2011 17:57:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 22 Dec 2011 17:57:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=jru0QZ+zML8/h+lIOJ+wfGiKeLvPDTw41i/pPZSNmzc=; b=SV7yWJ8jjkX/w9sOplvF3/HrOUTnABvWnAX+rok5LFemieHuemWpMSoM4GBnb0Sf7MW7POTKJAX2hdCM8LlUNAEt8pYDbSMX/Vig99nqdkdLkU1cOyhohiPPcV2C6mBd; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RdmtZ-0007oL-OF; Thu, 22 Dec 2011 10:57:34 -0700 From: "Richard Shockey" To: "'Ravindran, Parthasarathi'" , "'Paul E. Jones'" , References: <014301ccbe78$0c766360$25632a20$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C01DAE343@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DAE343@inba-mail01.sonusnet.com> Date: Thu, 22 Dec 2011 12:57:31 -0500 Message-ID: <000f01ccc0d3$2e3e5090$8abaf1b0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CCC0A9.45684890" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acy+eAqBbk2BaSs3THClEtyh3UqaQQCM0KAgAAnvSzA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:58:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01CCC0A9.45684890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +100 Please !! This is very much needed work. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi Sent: Thursday, December 22, 2011 8:35 AM To: Paul E. Jones; dispatch@ietf.org Subject: Re: [dispatch] Revised Proposed Session-ID Charter Paul, I like to see this charter moving forward. Thanks Partha From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Monday, December 19, 2011 11:30 PM To: dispatch@ietf.org Subject: [dispatch] Revised Proposed Session-ID Charter Folks, I've not seen much discussion on this topic over the past month. Even so, I've not seen any objection to proceeding work. The only concern raised recently is around the definition of the word "session", to which we're proposing to make that a part of the first deliverable. What do we need to do in order to move this work forward? Paul PS - The charter text that seems to have reached general acceptance is below End-to-end Session Identifier in SIP (charter proposal) The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP is not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. Consideration must be given to the fact that the entities involved in a communication session might change as a result of service interaction in the network, such as call transfers, joins, etc. A SIP end-to-end Session Identifier has been considered as possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements have also been identified and come directly from other Existing working group within the RAI area (e.g. SIPRec, Splices). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value(s) so that it is possible to identify a call end-to end even when performing interworking between protocols. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification, including the definition of a "session" 2. Specification of new end-to-end Session Identifier mechanism Goal and Milestone: August 2012 - Requirement and use case document sent to the IESG (Informational) March 2013 - Specification of the new mechanism sent to the IESG (PS) ------=_NextPart_000_0010_01CCC0A9.45684890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+100   Please !!  This is very = much needed work.

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ravindran, Parthasarathi
Sent: Thursday, = December 22, 2011 8:35 AM
To: Paul E. Jones; = dispatch@ietf.org
Subject: Re: [dispatch] Revised Proposed = Session-ID Charter

 

Paul,

 

I like to see this = charter moving forward.

 

Thanks

Partha

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Paul E. Jones
Sent: Monday, December 19, 2011 = 11:30 PM
To: dispatch@ietf.org
Subject: [dispatch] = Revised Proposed Session-ID Charter

 

Folks,

 

I’ve = not seen much discussion on this topic over the past month.  Even = so, I’ve not seen any objection to proceeding work.  The only = concern raised recently is around the definition of the word = “session”, to which we’re proposing to make that a = part of the first deliverable.

 

What do we = need to do in order to move this work forward?

 

Paul

 

PS – = The charter text that seems to have reached general acceptance is = below

 

 

End-to-end Session Identifier in SIP (charter = proposal)

 

The end-to-end Session Identifier in SIP-based = multimedia communication networks refers to the ability for endpoints, = intermediate devices, and management and monitoring system to identify = and correlate SIP messages and dialogs of the same higher-level = end-to-end "communication session" across multiple SIP = devices, hops, and administrative domains.

 

Unfortunately, there are a number of factors that = contribute to the fact that the current dialog identifiers defined in = SIP is not suitable for end-to-end session identification. Perhaps the = most important factor worth describing is that in real-world deployments = Back-to-Back User Agents (B2BUAs) devices like Session Border = Controllers (SBC) often change the call identifiers (e.g., the From-tag = and To-tag that are used in conjunction with the Call-ID header to make = the dialog-id) as the session signaling passes through.

 

An = end-to-end Session Identifier should allow the possibility to identify = the communication session from the point of origin, passing through any = number of intermediaries, to the ultimate point of termination. It = should have the same aim as the From-tag, To-tag and Call-ID = conjunction, but should not be mangled by intermediaries.  = Consideration must be given to the fact that the entities involved in a = communication session might change as a result of service interaction in = the network, such as call transfers, joins, etc.

 

A SIP = end-to-end Session Identifier has been considered as possible solution = of different use cases like troubleshooting, billing, session tracking, = session recording, media and signaling correlation, and so forth.  = Some of these requirements have also been identified and come directly = from other Existing working group within the RAI area (e.g. SIPRec, = Splices).

 

Moreover, other standards organizations have = identified the need for SIP and H.323 to carry the same "session = ID" value(s) so that it is possible to identify a call end-to end = even when performing interworking between protocols.

 

The working = group will produce the following deliverables:

 

1. A = requirement and use case document with key consideration for SIP Session = End-to-End Identification, including the definition of a = "session"

 

2. = Specification of new end-to-end Session Identifier = mechanism

 

Goal and Milestone:

 

August 2012 = - Requirement and use case document sent to the IESG = (Informational)

 

March 2013 - = Specification of the new mechanism sent to the IESG = (PS)

 

 

 

------=_NextPart_000_0010_01CCC0A9.45684890-- From R.Jesske@telekom.de Thu Dec 22 23:33:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA611E8096 for ; Thu, 22 Dec 2011 23:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBV0r0AoKBNe for ; Thu, 22 Dec 2011 23:32:57 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8421F84CC for ; Thu, 22 Dec 2011 23:32:56 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 23 Dec 2011 08:32:55 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.93]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 23 Dec 2011 08:32:55 +0100 From: To: , Date: Fri, 23 Dec 2011 08:32:54 +0100 Thread-Topic: [dispatch] Revised Proposed Session-ID Charter Thread-Index: Acy+eAqBbk2BaSs3THClEtyh3UqaQQCzH8Ow Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0A6278577C@HE111648.emea1.cds.t-internal.com> References: <014301ccbe78$0c766360$25632a20$@packetizer.com> In-Reply-To: <014301ccbe78$0c766360$25632a20$@packetizer.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6278577CHE111648emea1_" MIME-Version: 1.0 Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 07:33:00 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6278577CHE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, I strongly support the work and I'm happy with the proposal as it stays. Please let start with the work. Best Regards Roland ________________________________ Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Paul E. Jones Gesendet: Montag, 19. Dezember 2011 19:00 An: dispatch@ietf.org Betreff: [dispatch] Revised Proposed Session-ID Charter Folks, I've not seen much discussion on this topic over the past month. Even so, = I've not seen any objection to proceeding work. The only concern raised re= cently is around the definition of the word "session", to which we're propo= sing to make that a part of the first deliverable. What do we need to do in order to move this work forward? Paul PS - The charter text that seems to have reached general acceptance is belo= w End-to-end Session Identifier in SIP (charter proposal) The end-to-end Session Identifier in SIP-based multimedia communication net= works refers to the ability for endpoints, intermediate devices, and manage= ment and monitoring system to identify and correlate SIP messages and dialo= gs of the same higher-level end-to-end "communication session" across multi= ple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact th= at the current dialog identifiers defined in SIP is not suitable for end-to= -end session identification. Perhaps the most important factor worth descri= bing is that in real-world deployments Back-to-Back User Agents (B2BUAs) de= vices like Session Border Controllers (SBC) often change the call identifie= rs (e.g., the From-tag and To-tag that are used in conjunction with the Cal= l-ID header to make the dialog-id) as the session signaling passes through. An end-to-end Session Identifier should allow the possibility to identify t= he communication session from the point of origin, passing through any numb= er of intermediaries, to the ultimate point of termination. It should have = the same aim as the From-tag, To-tag and Call-ID conjunction, but should no= t be mangled by intermediaries. Consideration must be given to the fact th= at the entities involved in a communication session might change as a resul= t of service interaction in the network, such as call transfers, joins, etc= . A SIP end-to-end Session Identifier has been considered as possible solutio= n of different use cases like troubleshooting, billing, session tracking, s= ession recording, media and signaling correlation, and so forth. Some of t= hese requirements have also been identified and come directly from other Ex= isting working group within the RAI area (e.g. SIPRec, Splices). Moreover, other standards organizations have identified the need for SIP an= d H.323 to carry the same "session ID" value(s) so that it is possible to i= dentify a call end-to end even when performing interworking between protoco= ls. The working group will produce the following deliverables: 1. A requirement and use case document with key consideration for SIP Sessi= on End-to-End Identification, including the definition of a "session" 2. Specification of new end-to-end Session Identifier mechanism Goal and Milestone: August 2012 - Requirement and use case document sent to the IESG (Informati= onal) March 2013 - Specification of the new mechanism sent to the IESG (PS) --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6278577CHE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Paul,
 
I strongly support the work and I'm = happy with=20 the proposal as it stays.
 
Please let start with the work.
 
Best Regards
 
Roland

Von: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] Im Auftrag von Paul E.=20 Jones
Gesendet: Montag, 19. Dezember 2011 19:00
An:=20 dispatch@ietf.org
Betreff: [dispatch] Revised Proposed Session-ID= =20 Charter

Folks,

 

I’ve not seen much discussion on this topic over= the past=20 month.  Even so, I’ve not seen any objection to proceeding work.=   The=20 only concern raised recently is around the definition of the word “se= ssion”, to=20 which we’re proposing to make that a part of the first=20 deliverable.

 

What do we need to do in order to move this work=20 forward?

 

Paul

 

PS – The charter text that seems to have reached= general=20 acceptance is below

 

 

End-to-end Session Identifier in SIP (charter=20 proposal)

 

The end-to-end Session Identifier in SIP-based multime= dia=20 communication networks refers to the ability for endpoints, intermediate=20 devices, and management and monitoring system to identify and correlate SIP= =20 messages and dialogs of the same higher-level end-to-end "communication ses= sion"=20 across multiple SIP devices, hops, and administrative domains.

 

Unfortunately, there are a number of factors that cont= ribute=20 to the fact that the current dialog identifiers defined in SIP is not suita= ble=20 for end-to-end session identification. Perhaps the most important factor wo= rth=20 describing is that in real-world deployments Back-to-Back User Agents (B2BU= As)=20 devices like Session Border Controllers (SBC) often change the call identif= iers=20 (e.g., the From-tag and To-tag that are used in conjunction with the Call-I= D=20 header to make the dialog-id) as the session signaling passes=20 through.

 

An end-to-end Session Identifier should allow the poss= ibility=20 to identify the communication session from the point of origin, passing thr= ough=20 any number of intermediaries, to the ultimate point of termination. It shou= ld=20 have the same aim as the From-tag, To-tag and Call-ID conjunction, but shou= ld=20 not be mangled by intermediaries.  Consideration must be given to the = fact=20 that the entities involved in a communication session might change as a res= ult=20 of service interaction in the network, such as call transfers, joins, etc.= =20

 

A SIP end-to-end Session Identifier has been considere= d as=20 possible solution of different use cases like troubleshooting, billing, ses= sion=20 tracking, session recording, media and signaling correlation, and so=20 forth.  Some of these requirements have also been identified and come= =20 directly from other Existing working group within the RAI area (e.g. SIPRec= ,=20 Splices).

 

Moreover, other standards organizations have identifie= d the=20 need for SIP and H.323 to carry the same "session ID" value(s) so that it i= s=20 possible to identify a call end-to end even when performing interworking be= tween=20 protocols.

 

The working group will produce the following=20 deliverables:

 

1. A requirement and use case document with key consid= eration=20 for SIP Session End-to-End Identification, including the definition of a=20 "session"

 

2. Specification of new end-to-end Session Identifier= =20 mechanism

 

Goal and Milestone:

 

August 2012 - Requirement and use case document sent t= o the=20 IESG (Informational)

 

March 2013 - Specification of the new mechanism sent t= o the=20 IESG (PS)

 

 

 

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0A6278577CHE111648emea1_-- From laura.liess.dt@googlemail.com Fri Dec 23 05:45:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767F821F8B75 for ; Fri, 23 Dec 2011 05:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWvN6m5D+xic for ; Fri, 23 Dec 2011 05:45:50 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59F6C21F8B66 for ; Fri, 23 Dec 2011 05:45:50 -0800 (PST) Received: by wibhj6 with SMTP id hj6so3936121wib.31 for ; Fri, 23 Dec 2011 05:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2QW4DrXJXEz3+VQt+RyWmkNBiTcqxJMy6CzcV0ckA/s=; b=Vus35UNKzk5z0r1PJ0Bk+8/HmDvKLao3RMcHUL8gBH+FzHplyE94T5/pkE0o5PVQIl g2m4HOLw7orzMdWrT/MNw1sfS8Oc4O7vceusoeW59hspSzc97WRKksUplsPv7N7SRQ59 yh2H4fkdreYZWQqjCSNr9iQ0s53kVOk3+nOh0= MIME-Version: 1.0 Received: by 10.180.79.35 with SMTP id g3mr32361446wix.19.1324647949585; Fri, 23 Dec 2011 05:45:49 -0800 (PST) Received: by 10.227.175.66 with HTTP; Fri, 23 Dec 2011 05:45:49 -0800 (PST) In-Reply-To: <014301ccbe78$0c766360$25632a20$@packetizer.com> References: <014301ccbe78$0c766360$25632a20$@packetizer.com> Date: Fri, 23 Dec 2011 14:45:49 +0100 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 13:45:51 -0000 Paul, We already had a consensus in Dispatch that this work is needed and that there are enough people willing to contribute. There were objections to the initial charter but, as you already pointed out, the current charter text seems to have reached general acceptance. I suggest you ask Gonzalo how to proceed to start the WG. Laura 2011/12/19 Paul E. Jones : > Folks, > > > > I=92ve not seen much discussion on this topic over the past month.=A0 Eve= n so, > I=92ve not seen any objection to proceeding work.=A0 The only concern rai= sed > recently is around the definition of the word =93session=94, to which we= =92re > proposing to make that a part of the first deliverable. > > > > What do we need to do in order to move this work forward? > > > > Paul > > > > PS =96 The charter text that seems to have reached general acceptance is = below > > > > > > End-to-end Session Identifier in SIP (charter proposal) > > > > The end-to-end Session Identifier in SIP-based multimedia communication > networks refers to the ability for endpoints, intermediate devices, and > management and monitoring system to identify and correlate SIP messages a= nd > dialogs of the same higher-level end-to-end "communication session" acros= s > multiple SIP devices, hops, and administrative domains. > > > > Unfortunately, there are a number of factors that contribute to the fact > that the current dialog identifiers defined in SIP is not suitable for > end-to-end session identification. Perhaps the most important factor wort= h > describing is that in real-world deployments Back-to-Back User Agents > (B2BUAs) devices like Session Border Controllers (SBC) often change the c= all > identifiers (e.g., the From-tag and To-tag that are used in conjunction w= ith > the Call-ID header to make the dialog-id) as the session signaling passes > through. > > > > An end-to-end Session Identifier should allow the possibility to identify > the communication session from the point of origin, passing through any > number of intermediaries, to the ultimate point of termination. It should > have the same aim as the From-tag, To-tag and Call-ID conjunction, but > should not be mangled by intermediaries.=A0 Consideration must be given t= o the > fact that the entities involved in a communication session might change a= s a > result of service interaction in the network, such as call transfers, joi= ns, > etc. > > > > A SIP end-to-end Session Identifier has been considered as possible solut= ion > of different use cases like troubleshooting, billing, session tracking, > session recording, media and signaling correlation, and so forth.=A0 Some= of > these requirements have also been identified and come directly from other > Existing working group within the RAI area (e.g. SIPRec, Splices). > > > > Moreover, other standards organizations have identified the need for SIP = and > H.323 to carry the same "session ID" value(s) so that it is possible to > identify a call end-to end even when performing interworking between > protocols. > > > > The working group will produce the following deliverables: > > > > 1. A requirement and use case document with key consideration for SIP > Session End-to-End Identification, including the definition of a "session= " > > > > 2. Specification of new end-to-end Session Identifier mechanism > > > > Goal and Milestone: > > > > August 2012 - Requirement and use case document sent to the IESG > (Informational) > > > > March 2013 - Specification of the new mechanism sent to the IESG (PS) > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >