From yiu_lee@cable.comcast.com Tue Dec 1 10:09:40 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DEA28C11D for ; Tue, 1 Dec 2009 10:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElGY6KIRPjQ5 for ; Tue, 1 Dec 2009 10:09:39 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 8CB033A68AB for ; Tue, 1 Dec 2009 10:09:39 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.62711634; Tue, 01 Dec 2009 13:09:29 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:09:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Dec 2009 18:09:27 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3342517763_802600" Content-class: urn:content-classes:message Date: Tue, 1 Dec 2009 13:09:22 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: VoIP Use Cases Questions thread-index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQ== From: "Lee, Yiu" To: X-OriginalArrivalTime: 01 Dec 2009 18:09:28.0557 (UTC) FILETIME=[6C51F9D0:01CA72B1] Subject: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:09:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342517763_802600 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi team, We got some feedbacks from the IESG for this draft. We want to ask the team for opinions. Q1: Should this draft be descriptive or prescriptive? In other words, should this draft describe what is happening in the real-world or what the WG plans to see. We think this draft is to capture what is happening in the real-world. Q2: Should the SBC reset the Max-Forwards? In our network, the SBC does reset the Max-Forwards. However, the IESG thinks the SBC should decrement the Max-Forwards rather than resetting it. This is back to Q1, should this draft be descriptive or prescriptive. After we receive comments from the WG, we will update the draft and release a new revision. Thanks, Adam and Yiu --B_3342517763_802600 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBRB9EvmttjyEn3Zy6DPUeUvHrs/ATAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDExODA5MjJaMA0GCSqGSIb3DQEBAQUABIIBADPM h/YVWp3l0kP4byRXUeTuP/mJlYWeLLXiRAldbf9iMypEKHu/ei2/rZQDMVlqninMM4i9i7o/ M1eUaEO3+jB+CjCXbi6aC9JlN3HFgVZNzMV78OHhOuJvSuwuoAP/09RzO4iVUND9DciAHQVG VNn6gBTU9WXUS9nIuecYBee4sCS4V+1+PS3vtX6VABCkDFFQleeLsXTfNzSQQLAUUv2SRndu LSLO8Zoh89Wz//wWqpxRdsHw+ZKs/X9gC9B+mA91iSaGOX5XoWY0Q1/FrxE2bsq3nyqVednT C3MrPxbT19Xfyrp/bmdniO+xXp3S/1/2BPIGGb+AJmnDo6/rLgU= --B_3342517763_802600-- From tmartin@timedatacorp.com Tue Dec 1 11:20:02 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBFD3A692E for ; Tue, 1 Dec 2009 11:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9VQlv13dpGs for ; Tue, 1 Dec 2009 11:20:01 -0800 (PST) Received: from outbound.mse14.exchange.ms (outbound.mse14.exchange.ms [216.52.164.186]) by core3.amsl.com (Postfix) with ESMTP id C7A5D3A6831 for ; Tue, 1 Dec 2009 11:19:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 14:19:49 -0500 Message-ID: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQ References: From: "Terry Martin" To: "Lee, Yiu" , Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:20:02 -0000 I am not a member of the team writing the draft but I have been = monitoring this list for several years because I work with SBC's and = VoIP networks and I want to understand how these system can be put = together to improve my customers experience. =20 >From my perspective it does have to have a descriptive component to = outline real world direction vendors are taking. But it should offer = some prescriptive definitions to improve on real world implementation = issues.=20 As for Max-forwards, all the systems I work with have a limit and it = resets. I believe the reason why it is done this way is to keep memory = and process usage to a minumim to keep costs down. I would like to understand why the IESG thinks the SBC should decrement the Max-Forwards rather than resetting it. I would like to understand = the benefits for doing decrementing verse resetting. How will it help = my customers? That is what I am looking for in the draft. Thank you for allowing me to comment. =20 Terry Martin TimeData Corporation VP of Network Operation West Coast Number=A0=A0=A0=A0 503-678-2224 Cell: 503-318-8909 -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On = Behalf Of Lee, Yiu Sent: Tuesday, December 01, 2009 10:09 AM To: speermint@ietf.org Subject: [Speermint] VoIP Use Cases Questions Hi team, We got some feedbacks from the IESG for this draft. We want to ask the = team for opinions. Q1: Should this draft be descriptive or prescriptive? In other words, = should this draft describe what is happening in the real-world or what the WG = plans to see. We think this draft is to capture what is happening in the real-world. Q2: Should the SBC reset the Max-Forwards? In our network, the SBC does reset the Max-Forwards. However, the IESG thinks the SBC should = decrement the Max-Forwards rather than resetting it. This is back to Q1, should = this draft be descriptive or prescriptive. After we receive comments from the WG, we will update the draft and = release a new revision. Thanks, Adam and Yiu From yiu_lee@cable.comcast.com Tue Dec 1 11:40:39 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B2028C0ED for ; Tue, 1 Dec 2009 11:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1pCwP8ADT0F for ; Tue, 1 Dec 2009 11:40:38 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 8796A3A6A47 for ; Tue, 1 Dec 2009 11:40:38 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73787622; Tue, 01 Dec 2009 14:40:15 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 14:40:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Dec 2009 19:40:13 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3342523212_1166155" Date: Tue, 1 Dec 2009 14:40:11 -0500 Message-ID: In-Reply-To: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions thread-index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCA= From: "Lee, Yiu" To: "Terry Martin" , X-OriginalArrivalTime: 01 Dec 2009 19:40:16.0245 (UTC) FILETIME=[1B653250:01CA72BE] Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:40:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342523212_1166155 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Terry, You don't have to be the member of the team to give us comments. We welcome you for any feedback. For the Max-Forward question, the IESG believes that the SBC is only a hop of the call, so it should not reset the Max-Forward. Rather, it should just decrement the Max-Forward. Other than that, I can't think of any benefit. Yiu On 12/1/09 2:19 PM, "Terry Martin" wrote: > I am not a member of the team writing the draft but I have been monitorin= g > this list for several years because I work with SBC's and VoIP networks a= nd I > want to understand how these system can be put together to improve my > customers experience. >=20 > From my perspective it does have to have a descriptive component to outli= ne > real world direction vendors are taking. But it should offer some > prescriptive definitions to improve on real world implementation issues. >=20 > As for Max-forwards, all the systems I work with have a limit and it rese= ts. > I believe the reason why it is done this way is to keep memory and proces= s > usage to a minumim to keep costs down. >=20 > I would like to understand why the IESG thinks the SBC should decrement > the Max-Forwards rather than resetting it. I would like to understand th= e > benefits for doing decrementing verse resetting. How will it help my > customers? >=20 > That is what I am looking for in the draft. >=20 >=20 > Thank you for allowing me to comment. >=20 > =20 > Terry Martin > TimeData Corporation > VP of Network Operation > West Coast Number=A0=A0=A0=A0 503-678-2224 > Cell: 503-318-8909 >=20 >=20 > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On B= ehalf > Of Lee, Yiu > Sent: Tuesday, December 01, 2009 10:09 AM > To: speermint@ietf.org > Subject: [Speermint] VoIP Use Cases Questions >=20 > Hi team, >=20 > We got some feedbacks from the IESG for this draft. We want to ask the te= am > for opinions. >=20 > Q1: Should this draft be descriptive or prescriptive? In other words, sho= uld > this draft describe what is happening in the real-world or what the WG pl= ans > to see. We think this draft is to capture what is happening in the > real-world. >=20 > Q2: Should the SBC reset the Max-Forwards? In our network, the SBC does > reset the Max-Forwards. However, the IESG thinks the SBC should decrement > the Max-Forwards rather than resetting it. This is back to Q1, should thi= s > draft be descriptive or prescriptive. >=20 > After we receive comments from the WG, we will update the draft and relea= se > a new revision. >=20 > Thanks, > Adam and Yiu >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint --B_3342523212_1166155 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBQFsY17GDBppWJS2F+LSlvwIEThNjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDExOTQwMTFaMA0GCSqGSIb3DQEBAQUABIIBAEGJ ImYPHi6p1j9HETYQRlG80O4vn9NoFL575t2RXaw+RKIaycUNeJT5JCNb5Fs94YOez1Tc+ER+ 9drCFyoW6oMzxZyowTXYk609Oe+PzMxyIu8o5J2uqpV6Hd1LRjKah1hc1xDk6Fu0QWj6uAOT M+XKmWDOxw5Ur+xkx2LHya818bvP5eMI9tuEbrHjVGzvy9Oq02Ha9h3+smKaWTD6Eo1KKl5X QMSOq8Qmuv/YCwmPhsv3THbOB0vgbz51qb6Vm0s4fux+HGxln8dFEELSJCMWNgkT/zFimWkS /9KmHt5XIhEZ5RGga/vEGMZQqQr93BVl26nuqE9VBEL0SUrQutQ= --B_3342523212_1166155-- From john.elwell@siemens-enterprise.com Tue Dec 1 12:13:55 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7B43A68FF for ; Tue, 1 Dec 2009 12:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9-RcnkvCR7M for ; Tue, 1 Dec 2009 12:13:54 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 74F2F3A68B5 for ; Tue, 1 Dec 2009 12:13:53 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-174110; Tue, 1 Dec 2009 21:13:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 66B5C23F01F7; Tue, 1 Dec 2009 21:13:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 1 Dec 2009 21:13:44 +0100 From: "Elwell, John" To: "Lee, Yiu" , "speermint@ietf.org" Date: Tue, 1 Dec 2009 21:13:42 +0100 Thread-Topic: VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQAEC0yA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:13:55 -0000 Adam and Yiu, Your general question about whether the draft is descriptive or prescriptiv= e is a good one. The draft is currently designated Informational, which would suggest it is = descriptive, although Informational RFCs have been published that have a pr= escriptive content. So the Informational designation perhaps doesn't mean m= uch. Reading the Introduction section, it certainly isn't clear. The fact that i= t states "Most of=20 the message diagrams were based on previous work described within=20 existing IETF standards documents." would suggest that is showing what ought to be done rather than what is typ= ically done in practice. Whatever the intent, the intent should be made clear in the Introduction se= ction. However, there has been some discussion about abandoning this work item. John > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Lee, Yiu > Sent: 01 December 2009 18:09 > To: speermint@ietf.org > Subject: [Speermint] VoIP Use Cases Questions >=20 > Hi team, >=20 > We got some feedbacks from the IESG for this draft. We want=20 > to ask the team > for opinions. >=20 > Q1: Should this draft be descriptive or prescriptive? In=20 > other words, should > this draft describe what is happening in the real-world or=20 > what the WG plans > to see. We think this draft is to capture what is happening in the > real-world. >=20 > Q2: Should the SBC reset the Max-Forwards? In our network,=20 > the SBC does > reset the Max-Forwards. However, the IESG thinks the SBC=20 > should decrement > the Max-Forwards rather than resetting it. This is back to=20 > Q1, should this > draft be descriptive or prescriptive. >=20 > After we receive comments from the WG, we will update the=20 > draft and release > a new revision. >=20 > Thanks, > Adam and Yiu >=20 > = From yiu_lee@cable.comcast.com Tue Dec 1 12:36:14 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DAB3A67D1 for ; Tue, 1 Dec 2009 12:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7vV9nwBLi1P for ; Tue, 1 Dec 2009 12:36:13 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 192DF3A68A0 for ; Tue, 1 Dec 2009 12:36:13 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.83413814; Tue, 01 Dec 2009 15:35:51 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 15:35:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Dec 2009 20:35:49 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3342526546_1352497" Date: Tue, 1 Dec 2009 15:35:44 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: VoIP Use Cases Questions thread-index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQAEC0yAAAERUmE= From: "Lee, Yiu" To: "Elwell, John" , X-OriginalArrivalTime: 01 Dec 2009 20:35:51.0779 (UTC) FILETIME=[DF874B30:01CA72C5] Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:36:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342526546_1352497 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi John, It seems you refer to the "draft-ietf-speermint-flows" draft. Our questions are about the "draft-ietf-speermint-voip-consolidated-usecases" Thanks, Yiu On 12/1/09 3:13 PM, "Elwell, John" wrote: > Adam and Yiu, > > Your general question about whether the draft is descriptive or prescriptive > is a good one. > > The draft is currently designated Informational, which would suggest it is > descriptive, although Informational RFCs have been published that have a > prescriptive content. So the Informational designation perhaps doesn't mean > much. > > Reading the Introduction section, it certainly isn't clear. The fact that it > states "Most of > the message diagrams were based on previous work described within > existing IETF standards documents." > would suggest that is showing what ought to be done rather than what is > typically done in practice. > > Whatever the intent, the intent should be made clear in the Introduction > section. > > However, there has been some discussion about abandoning this work item. > > John > > >> -----Original Message----- >> From: speermint-bounces@ietf.org >> [mailto:speermint-bounces@ietf.org] On Behalf Of Lee, Yiu >> Sent: 01 December 2009 18:09 >> To: speermint@ietf.org >> Subject: [Speermint] VoIP Use Cases Questions >> >> Hi team, >> >> We got some feedbacks from the IESG for this draft. We want >> to ask the team >> for opinions. >> >> Q1: Should this draft be descriptive or prescriptive? In >> other words, should >> this draft describe what is happening in the real-world or >> what the WG plans >> to see. We think this draft is to capture what is happening in the >> real-world. >> >> Q2: Should the SBC reset the Max-Forwards? In our network, >> the SBC does >> reset the Max-Forwards. However, the IESG thinks the SBC >> should decrement >> the Max-Forwards rather than resetting it. This is back to >> Q1, should this >> draft be descriptive or prescriptive. >> >> After we receive comments from the WG, we will update the >> draft and release >> a new revision. >> >> Thanks, >> Adam and Yiu >> >> --B_3342526546_1352497 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBSXE+D/HWSEFcBfjUTmdoAzpKzyozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDEyMDM1NDRaMA0GCSqGSIb3DQEBAQUABIIBACHH tCsQYTjSPf+b9i3b4wJoXxSwOmOGR6Rww2y23otDWZsO/COL/qsyHFnkz2cKzDKpvLDFPw0D KG7hlQaTxDxVsgqvD8Zho1Fy1dY1AMxRFLONmwnJcS+IVbfVsjSWC39iv43umb68UWAhRm1m z9McZMvNYqeobuopvIr+ZtaDBjl1MQpyzDzRrK8h3+A8oaTDO3VPrHM/kNMbUF1AdEumKFFI aOwnM34vo3I0I8p5DHzuZ8q1dsbRye8Du3jbajZiVkdlgSKHQsgwML873+gwz3L9fZfOiEYe TbboKctBK/s3CBRkteu4MtzjHRmxyG0VA2C6qIXFyFf1H2z2SlM= --B_3342526546_1352497-- From hmmr@cisco.com Tue Dec 1 14:02:55 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10173A680B for ; Tue, 1 Dec 2009 14:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rlm38zECvhe for ; Tue, 1 Dec 2009 14:02:54 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AED623A679C for ; Tue, 1 Dec 2009 14:02:54 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACYhFUtAZnwM/2dsb2JhbADAc4kgCY51gkqBZwQ X-IronPort-AV: E=Sophos;i="4.47,323,1257120000"; d="scan'208";a="204192678" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2009 22:02:46 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nB1M2kPP010000; Tue, 1 Dec 2009 22:02:46 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 16:02:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 16:02:45 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAABOSb0A== References: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> From: "Mike Hammer (hmmr)" To: "Lee, Yiu" , "Terry Martin" , X-OriginalArrivalTime: 01 Dec 2009 22:02:46.0116 (UTC) FILETIME=[0383FA40:01CA72D2] Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:02:55 -0000 The benefit of not resetting but decrementing relates to the possibility = that this peering point is one of a series where other interfaces could = lead to possible looping of a call. Problem is that you can't always = guarantee what happens at the next hop. Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] = On > Behalf Of Lee, Yiu > Sent: Tuesday, December 01, 2009 2:40 PM > To: Terry Martin; speermint@ietf.org > Subject: Re: [Speermint] VoIP Use Cases Questions >=20 > Hi Terry, >=20 > You don't have to be the member of the team to give us comments. We > welcome you for any feedback. >=20 > For the Max-Forward question, the IESG believes that the SBC is only a = hop > of the call, so it should not reset the Max-Forward. Rather, it should > just decrement the Max-Forward. Other than that, I can't think of any > benefit. >=20 > Yiu >=20 >=20 > On 12/1/09 2:19 PM, "Terry Martin" wrote: >=20 > > I am not a member of the team writing the draft but I have been > > monitoring this list for several years because I work with SBC's and > > VoIP networks and I want to understand how these system can be put > > together to improve my customers experience. > > > > From my perspective it does have to have a descriptive component to > > outline real world direction vendors are taking. But it should = offer > > some prescriptive definitions to improve on real world = implementation > issues. > > > > As for Max-forwards, all the systems I work with have a limit and it > resets. > > I believe the reason why it is done this way is to keep memory and > > process usage to a minumim to keep costs down. > > > > I would like to understand why the IESG thinks the SBC should > > decrement the Max-Forwards rather than resetting it. I would like = to > > understand the benefits for doing decrementing verse resetting. How > > will it help my customers? > > > > That is what I am looking for in the draft. > > > > > > Thank you for allowing me to comment. > > > > > > Terry Martin > > TimeData Corporation > > VP of Network Operation > > West Coast Number=A0=A0=A0=A0 503-678-2224 > > Cell: 503-318-8909 > > > > > > -----Original Message----- > > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > > On Behalf Of Lee, Yiu > > Sent: Tuesday, December 01, 2009 10:09 AM > > To: speermint@ietf.org > > Subject: [Speermint] VoIP Use Cases Questions > > > > Hi team, > > > > We got some feedbacks from the IESG for this draft. We want to ask = the > > team for opinions. > > > > Q1: Should this draft be descriptive or prescriptive? In other = words, > > should this draft describe what is happening in the real-world or = what > > the WG plans to see. We think this draft is to capture what is > > happening in the real-world. > > > > Q2: Should the SBC reset the Max-Forwards? In our network, the SBC > > does reset the Max-Forwards. However, the IESG thinks the SBC should > > decrement the Max-Forwards rather than resetting it. This is back to > > Q1, should this draft be descriptive or prescriptive. > > > > After we receive comments from the WG, we will update the draft and > > release a new revision. > > > > Thanks, > > Adam and Yiu > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint From tmartin@timedatacorp.com Tue Dec 1 14:09:54 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DB828C122 for ; Tue, 1 Dec 2009 14:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfPSW7bgx7YU for ; Tue, 1 Dec 2009 14:09:53 -0800 (PST) Received: from outbound.mse14.exchange.ms (outbound.mse14.exchange.ms [216.52.164.186]) by core3.amsl.com (Postfix) with ESMTP id 883FB3A682C for ; Tue, 1 Dec 2009 14:09:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 17:09:42 -0500 Message-ID: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F799E0@mse14be2.mse14.exchange.ms> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAABOSb0AAAPmbg References: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> From: "Terry Martin" To: "Mike Hammer (hmmr)" , "Lee, Yiu" , Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:09:54 -0000 Thanks to all for addressing the question. What I have seen so far is this appears to be a legitimate = recommendation, under certain conditions, which means it should be added = to document for consideration Terry Martin TimeData Corporation VP of Network Operation West Coast Number=A0=A0=A0=A0 503-678-2224 Cell: 503-318-8909 -----Original Message----- From: Mike Hammer (hmmr) [mailto:hmmr@cisco.com]=20 Sent: Tuesday, December 01, 2009 2:03 PM To: Lee, Yiu; Terry Martin; speermint@ietf.org Subject: RE: [Speermint] VoIP Use Cases Questions The benefit of not resetting but decrementing relates to the possibility = that this peering point is one of a series where other interfaces could = lead to possible looping of a call. Problem is that you can't always = guarantee what happens at the next hop. Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] = On > Behalf Of Lee, Yiu > Sent: Tuesday, December 01, 2009 2:40 PM > To: Terry Martin; speermint@ietf.org > Subject: Re: [Speermint] VoIP Use Cases Questions >=20 > Hi Terry, >=20 > You don't have to be the member of the team to give us comments. We > welcome you for any feedback. >=20 > For the Max-Forward question, the IESG believes that the SBC is only a = hop > of the call, so it should not reset the Max-Forward. Rather, it should > just decrement the Max-Forward. Other than that, I can't think of any > benefit. >=20 > Yiu >=20 >=20 > On 12/1/09 2:19 PM, "Terry Martin" wrote: >=20 > > I am not a member of the team writing the draft but I have been > > monitoring this list for several years because I work with SBC's and > > VoIP networks and I want to understand how these system can be put > > together to improve my customers experience. > > > > From my perspective it does have to have a descriptive component to > > outline real world direction vendors are taking. But it should = offer > > some prescriptive definitions to improve on real world = implementation > issues. > > > > As for Max-forwards, all the systems I work with have a limit and it > resets. > > I believe the reason why it is done this way is to keep memory and > > process usage to a minumim to keep costs down. > > > > I would like to understand why the IESG thinks the SBC should > > decrement the Max-Forwards rather than resetting it. I would like = to > > understand the benefits for doing decrementing verse resetting. How > > will it help my customers? > > > > That is what I am looking for in the draft. > > > > > > Thank you for allowing me to comment. > > > > > > Terry Martin > > TimeData Corporation > > VP of Network Operation > > West Coast Number=A0=A0=A0=A0 503-678-2224 > > Cell: 503-318-8909 > > > > > > -----Original Message----- > > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > > On Behalf Of Lee, Yiu > > Sent: Tuesday, December 01, 2009 10:09 AM > > To: speermint@ietf.org > > Subject: [Speermint] VoIP Use Cases Questions > > > > Hi team, > > > > We got some feedbacks from the IESG for this draft. We want to ask = the > > team for opinions. > > > > Q1: Should this draft be descriptive or prescriptive? In other = words, > > should this draft describe what is happening in the real-world or = what > > the WG plans to see. We think this draft is to capture what is > > happening in the real-world. > > > > Q2: Should the SBC reset the Max-Forwards? In our network, the SBC > > does reset the Max-Forwards. However, the IESG thinks the SBC should > > decrement the Max-Forwards rather than resetting it. This is back to > > Q1, should this draft be descriptive or prescriptive. > > > > After we receive comments from the WG, we will update the draft and > > release a new revision. > > > > Thanks, > > Adam and Yiu > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint From yiu_lee@cable.comcast.com Tue Dec 1 16:08:07 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E08A3A68B4 for ; Tue, 1 Dec 2009 16:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.271 X-Spam-Level: X-Spam-Status: No, score=0.271 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSszXT9arPIK for ; Tue, 1 Dec 2009 16:08:06 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 63C223A6859 for ; Tue, 1 Dec 2009 16:08:06 -0800 (PST) Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73811485; Tue, 01 Dec 2009 19:06:38 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 19:06:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Dec 2009 00:06:37 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3342539195_159868" Date: Tue, 1 Dec 2009 19:06:33 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions thread-index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAABOSb0AAEaOb9 From: "Lee, Yiu" To: "Mike Hammer (hmmr)" , "Terry Martin" , X-OriginalArrivalTime: 02 Dec 2009 00:06:37.0798 (UTC) FILETIME=[5124A860:01CA72E3] Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:08:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342539195_159868 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Agreed that by decrementing the Max-Forward can prevent from possible looping. I have no problem to update the draft to reflect the change if I hear no objection from the list. One thing I want to mention is that this draft isn't intended to be BCP, so call flows captured in this draft are only informative. On 12/1/09 5:02 PM, "Mike Hammer (hmmr)" wrote: > The benefit of not resetting but decrementing relates to the possibility = that > this peering point is one of a series where other interfaces could lead t= o > possible looping of a call. Problem is that you can't always guarantee w= hat > happens at the next hop. >=20 > Mike >=20 >=20 >> -----Original Message----- >> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On >> Behalf Of Lee, Yiu >> Sent: Tuesday, December 01, 2009 2:40 PM >> To: Terry Martin; speermint@ietf.org >> Subject: Re: [Speermint] VoIP Use Cases Questions >>=20 >> Hi Terry, >>=20 >> You don't have to be the member of the team to give us comments. We >> welcome you for any feedback. >>=20 >> For the Max-Forward question, the IESG believes that the SBC is only a h= op >> of the call, so it should not reset the Max-Forward. Rather, it should >> just decrement the Max-Forward. Other than that, I can't think of any >> benefit. >>=20 >> Yiu >>=20 >>=20 >> On 12/1/09 2:19 PM, "Terry Martin" wrote: >>=20 >>> I am not a member of the team writing the draft but I have been >>> monitoring this list for several years because I work with SBC's and >>> VoIP networks and I want to understand how these system can be put >>> together to improve my customers experience. >>>=20 >>> From my perspective it does have to have a descriptive component to >>> outline real world direction vendors are taking. But it should offer >>> some prescriptive definitions to improve on real world implementation >> issues. >>>=20 >>> As for Max-forwards, all the systems I work with have a limit and it >> resets. >>> I believe the reason why it is done this way is to keep memory and >>> process usage to a minumim to keep costs down. >>>=20 >>> I would like to understand why the IESG thinks the SBC should >>> decrement the Max-Forwards rather than resetting it. I would like to >>> understand the benefits for doing decrementing verse resetting. How >>> will it help my customers? >>>=20 >>> That is what I am looking for in the draft. >>>=20 >>>=20 >>> Thank you for allowing me to comment. >>>=20 >>>=20 >>> Terry Martin >>> TimeData Corporation >>> VP of Network Operation >>> West Coast Number=A0=A0=A0=A0 503-678-2224 >>> Cell: 503-318-8909 >>>=20 >>>=20 >>> -----Original Message----- >>> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] >>> On Behalf Of Lee, Yiu >>> Sent: Tuesday, December 01, 2009 10:09 AM >>> To: speermint@ietf.org >>> Subject: [Speermint] VoIP Use Cases Questions >>>=20 >>> Hi team, >>>=20 >>> We got some feedbacks from the IESG for this draft. We want to ask the >>> team for opinions. >>>=20 >>> Q1: Should this draft be descriptive or prescriptive? In other words, >>> should this draft describe what is happening in the real-world or what >>> the WG plans to see. We think this draft is to capture what is >>> happening in the real-world. >>>=20 >>> Q2: Should the SBC reset the Max-Forwards? In our network, the SBC >>> does reset the Max-Forwards. However, the IESG thinks the SBC should >>> decrement the Max-Forwards rather than resetting it. This is back to >>> Q1, should this draft be descriptive or prescriptive. >>>=20 >>> After we receive comments from the WG, we will update the draft and >>> release a new revision. >>>=20 >>> Thanks, >>> Adam and Yiu >>>=20 >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www.ietf.org/mailman/listinfo/speermint --B_3342539195_159868 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBT5e2WKWsTyb6RZknUtM0xBNVcuvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDIwMDA2MzNaMA0GCSqGSIb3DQEBAQUABIIBAHHO tslNUzXYGx6gxd3N8X7l4CEBD9CyEigkdieHfc1vv+AWEItWWeFecbvFtL6nmaZng0GUJdtX NE/WxaPtmvFhULyrsso276bSo1UKFcxyT4kJVXA/ooHpDI5QHv/Gs9f/xbNPjOwXvS8kuSwq ITG1MnmRjHuDhlwBIvwZOZp1RuOW3oejH2p66lPbOGDL9WnSIvDBvgfwTwTIwWaSZNLFPtxT bL34W6okGad5s05IRfWgHu2mfJpjq3I5hJoN9SHKGq2t93Cvxr4W111iFRUCbcMc4wfYLNYw Rc0SOXB2dXTfhWxWgnyO8mEX9MLuNf04uf5X+ulSLxrLslR8jgY= --B_3342539195_159868-- From BPenfield@acmepacket.com Tue Dec 1 16:10:07 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A208F3A68DE for ; Tue, 1 Dec 2009 16:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4SZGzwOhBnw for ; Tue, 1 Dec 2009 16:10:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E7ACE3A6859 for ; Tue, 1 Dec 2009 16:10:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 1 Dec 2009 19:09:56 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 1 Dec 2009 19:09:54 -0500 From: Bob Penfield To: "Lee, Yiu" , "Mike Hammer (hmmr)" , Terry Martin , "speermint@ietf.org" Date: Tue, 1 Dec 2009 19:09:53 -0500 Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAABOSb0AAEaOb9AAAXlFA= Message-ID: <429446390BA91242867940DBE798A06B740334E9A9@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:10:07 -0000 Our SBC does decrement Max-Forwards. It's the right thing to do. -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Beh= alf Of Lee, Yiu Sent: Tuesday, December 01, 2009 7:07 PM To: Mike Hammer (hmmr); Terry Martin; speermint@ietf.org Subject: Re: [Speermint] VoIP Use Cases Questions Agreed that by decrementing the Max-Forward can prevent from possible looping. I have no problem to update the draft to reflect the change if I hear no objection from the list. One thing I want to mention is that this draft isn't intended to be BCP, so call flows captured in this draft are only informative. On 12/1/09 5:02 PM, "Mike Hammer (hmmr)" wrote: > The benefit of not resetting but decrementing relates to the possibility = that > this peering point is one of a series where other interfaces could lead t= o > possible looping of a call. Problem is that you can't always guarantee w= hat > happens at the next hop. >=20 > Mike >=20 >=20 >> -----Original Message----- >> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On >> Behalf Of Lee, Yiu >> Sent: Tuesday, December 01, 2009 2:40 PM >> To: Terry Martin; speermint@ietf.org >> Subject: Re: [Speermint] VoIP Use Cases Questions >>=20 >> Hi Terry, >>=20 >> You don't have to be the member of the team to give us comments. We >> welcome you for any feedback. >>=20 >> For the Max-Forward question, the IESG believes that the SBC is only a h= op >> of the call, so it should not reset the Max-Forward. Rather, it should >> just decrement the Max-Forward. Other than that, I can't think of any >> benefit. >>=20 >> Yiu >>=20 >>=20 >> On 12/1/09 2:19 PM, "Terry Martin" wrote: >>=20 >>> I am not a member of the team writing the draft but I have been >>> monitoring this list for several years because I work with SBC's and >>> VoIP networks and I want to understand how these system can be put >>> together to improve my customers experience. >>>=20 >>> From my perspective it does have to have a descriptive component to >>> outline real world direction vendors are taking. But it should offer >>> some prescriptive definitions to improve on real world implementation >> issues. >>>=20 >>> As for Max-forwards, all the systems I work with have a limit and it >> resets. >>> I believe the reason why it is done this way is to keep memory and >>> process usage to a minumim to keep costs down. >>>=20 >>> I would like to understand why the IESG thinks the SBC should >>> decrement the Max-Forwards rather than resetting it. I would like to >>> understand the benefits for doing decrementing verse resetting. How >>> will it help my customers? >>>=20 >>> That is what I am looking for in the draft. >>>=20 >>>=20 >>> Thank you for allowing me to comment. >>>=20 >>>=20 >>> Terry Martin >>> TimeData Corporation >>> VP of Network Operation >>> West Coast Number=A0=A0=A0=A0 503-678-2224 >>> Cell: 503-318-8909 >>>=20 >>>=20 >>> -----Original Message----- >>> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] >>> On Behalf Of Lee, Yiu >>> Sent: Tuesday, December 01, 2009 10:09 AM >>> To: speermint@ietf.org >>> Subject: [Speermint] VoIP Use Cases Questions >>>=20 >>> Hi team, >>>=20 >>> We got some feedbacks from the IESG for this draft. We want to ask the >>> team for opinions. >>>=20 >>> Q1: Should this draft be descriptive or prescriptive? In other words, >>> should this draft describe what is happening in the real-world or what >>> the WG plans to see. We think this draft is to capture what is >>> happening in the real-world. >>>=20 >>> Q2: Should the SBC reset the Max-Forwards? In our network, the SBC >>> does reset the Max-Forwards. However, the IESG thinks the SBC should >>> decrement the Max-Forwards rather than resetting it. This is back to >>> Q1, should this draft be descriptive or prescriptive. >>>=20 >>> After we receive comments from the WG, we will update the draft and >>> release a new revision. >>>=20 >>> Thanks, >>> Adam and Yiu >>>=20 >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www.ietf.org/mailman/listinfo/speermint From drage@alcatel-lucent.com Wed Dec 2 01:36:00 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4C128C175 for ; Wed, 2 Dec 2009 01:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD0Sg8GeOAvM for ; Wed, 2 Dec 2009 01:35:59 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id EB7F73A6A1E for ; Wed, 2 Dec 2009 01:35:58 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB29ZkVq000657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 10:35:46 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 2 Dec 2009 10:35:46 +0100 From: "DRAGE, Keith (Keith)" To: "Lee, Yiu" , Terry Martin , "speermint@ietf.org" Date: Wed, 2 Dec 2009 10:35:45 +0100 Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAAHQLt8A== Message-ID: References: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:36:00 -0000 The purpose of the Max-Forward header field is to limit the lifetime of the= request in the call as a whole, i.e. that something must have gone wrong i= n the routeing if it expires. By resetting the Max-Forward header field on = exit from the subnetwork bounded by the SBC, you assume the routeing betwee= n and beyond subnetworks is perfect and requests cannot get lost in this sp= ace. Such thoughts are a fallacy. I could understand a methodology of addin= g counts, if you thing you have taken rather more than your fair share with= in the subnetwork, but resetting to its default value is in my view erroneo= us. Keith > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Lee, Yiu > Sent: Tuesday, December 01, 2009 7:40 PM > To: Terry Martin; speermint@ietf.org > Subject: Re: [Speermint] VoIP Use Cases Questions >=20 > Hi Terry, >=20 > You don't have to be the member of the team to give us=20 > comments. We welcome you for any feedback. >=20 > For the Max-Forward question, the IESG believes that the SBC=20 > is only a hop of the call, so it should not reset the=20 > Max-Forward. Rather, it should just decrement the=20 > Max-Forward. Other than that, I can't think of any benefit. >=20 > Yiu >=20 >=20 > On 12/1/09 2:19 PM, "Terry Martin" wrote: >=20 > > I am not a member of the team writing the draft but I have been=20 > > monitoring this list for several years because I work with=20 > SBC's and=20 > > VoIP networks and I want to understand how these system can be put=20 > > together to improve my customers experience. > >=20 > > From my perspective it does have to have a descriptive component to=20 > > outline real world direction vendors are taking. But it=20 > should offer=20 > > some prescriptive definitions to improve on real world=20 > implementation issues. > >=20 > > As for Max-forwards, all the systems I work with have a=20 > limit and it resets. > > I believe the reason why it is done this way is to keep memory and=20 > > process usage to a minumim to keep costs down. > >=20 > > I would like to understand why the IESG thinks the SBC should=20 > > decrement the Max-Forwards rather than resetting it. I=20 > would like to=20 > > understand the benefits for doing decrementing verse=20 > resetting. How=20 > > will it help my customers? > >=20 > > That is what I am looking for in the draft. > >=20 > >=20 > > Thank you for allowing me to comment. > >=20 > > =20 > > Terry Martin > > TimeData Corporation > > VP of Network Operation > > West Coast Number=A0=A0=A0=A0 503-678-2224 > > Cell: 503-318-8909 > >=20 > >=20 > > -----Original Message----- > > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org]=20 > > On Behalf Of Lee, Yiu > > Sent: Tuesday, December 01, 2009 10:09 AM > > To: speermint@ietf.org > > Subject: [Speermint] VoIP Use Cases Questions > >=20 > > Hi team, > >=20 > > We got some feedbacks from the IESG for this draft. We want=20 > to ask the=20 > > team for opinions. > >=20 > > Q1: Should this draft be descriptive or prescriptive? In=20 > other words,=20 > > should this draft describe what is happening in the=20 > real-world or what=20 > > the WG plans to see. We think this draft is to capture what is=20 > > happening in the real-world. > >=20 > > Q2: Should the SBC reset the Max-Forwards? In our network, the SBC=20 > > does reset the Max-Forwards. However, the IESG thinks the=20 > SBC should=20 > > decrement the Max-Forwards rather than resetting it. This=20 > is back to=20 > > Q1, should this draft be descriptive or prescriptive. > >=20 > > After we receive comments from the WG, we will update the draft and=20 > > release a new revision. > >=20 > > Thanks, > > Adam and Yiu > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www.ietf.org/mailman/listinfo/speermint > = From D.Malas@cablelabs.com Wed Dec 2 13:50:34 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E403A689E for ; Wed, 2 Dec 2009 13:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FtfbzXQbdeR for ; Wed, 2 Dec 2009 13:50:33 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id DD13E3A694A for ; Wed, 2 Dec 2009 13:50:32 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nB2LoIBg022467; Wed, 2 Dec 2009 14:50:18 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Dec 2009 14:50:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from 10.4.10.173 ([10.4.10.173]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Dec 2009 21:50:18 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 02 Dec 2009 14:50:18 -0700 From: Daryl Malas To: "DRAGE, Keith (Keith)" , "Lee, Yiu" , Terry Martin , "speermint@ietf.org" Message-ID: Thread-Topic: [Speermint] VoIP Use Cases Questions Thread-Index: AcpysWhplhOFAJi5WkqLwNkVNoJ7tQABs0ZQAAF4sCAAHQLt8AAZ0wM6 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Approved: ondar Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 21:50:34 -0000 I agree from the standpoint I do not think SBC's should reset the Max-Forward value. --Daryl On 12/2/09 2:35 AM, "DRAGE, Keith (Keith)" wrote= : > The purpose of the Max-Forward header field is to limit the lifetime of t= he > request in the call as a whole, i.e. that something must have gone wrong = in > the routeing if it expires. By resetting the Max-Forward header field on = exit > from the subnetwork bounded by the SBC, you assume the routeing between a= nd > beyond subnetworks is perfect and requests cannot get lost in this space.= Such > thoughts are a fallacy. I could understand a methodology of adding counts= , if > you thing you have taken rather more than your fair share within the > subnetwork, but resetting to its default value is in my view erroneous. >=20 > Keith >=20 >> -----Original Message----- >> From: speermint-bounces@ietf.org >> [mailto:speermint-bounces@ietf.org] On Behalf Of Lee, Yiu >> Sent: Tuesday, December 01, 2009 7:40 PM >> To: Terry Martin; speermint@ietf.org >> Subject: Re: [Speermint] VoIP Use Cases Questions >>=20 >> Hi Terry, >>=20 >> You don't have to be the member of the team to give us >> comments. We welcome you for any feedback. >>=20 >> For the Max-Forward question, the IESG believes that the SBC >> is only a hop of the call, so it should not reset the >> Max-Forward. Rather, it should just decrement the >> Max-Forward. Other than that, I can't think of any benefit. >>=20 >> Yiu >>=20 >>=20 >> On 12/1/09 2:19 PM, "Terry Martin" wrote: >>=20 >>> I am not a member of the team writing the draft but I have been >>> monitoring this list for several years because I work with >> SBC's and=20 >>> VoIP networks and I want to understand how these system can be put >>> together to improve my customers experience. >>>=20 >>> From my perspective it does have to have a descriptive component to >>> outline real world direction vendors are taking. But it >> should offer=20 >>> some prescriptive definitions to improve on real world >> implementation issues. >>>=20 >>> As for Max-forwards, all the systems I work with have a >> limit and it resets. >>> I believe the reason why it is done this way is to keep memory and >>> process usage to a minumim to keep costs down. >>>=20 >>> I would like to understand why the IESG thinks the SBC should >>> decrement the Max-Forwards rather than resetting it. I >> would like to=20 >>> understand the benefits for doing decrementing verse >> resetting. How=20 >>> will it help my customers? >>>=20 >>> That is what I am looking for in the draft. >>>=20 >>>=20 >>> Thank you for allowing me to comment. >>>=20 >>> =20 >>> Terry Martin >>> TimeData Corporation >>> VP of Network Operation >>> West Coast Number=A0=A0=A0=A0 503-678-2224 >>> Cell: 503-318-8909 >>>=20 >>>=20 >>> -----Original Message----- >>> From: speermint-bounces@ietf.org >> [mailto:speermint-bounces@ietf.org] >>> On Behalf Of Lee, Yiu >>> Sent: Tuesday, December 01, 2009 10:09 AM >>> To: speermint@ietf.org >>> Subject: [Speermint] VoIP Use Cases Questions >>>=20 >>> Hi team, >>>=20 >>> We got some feedbacks from the IESG for this draft. We want >> to ask the=20 >>> team for opinions. >>>=20 >>> Q1: Should this draft be descriptive or prescriptive? In >> other words,=20 >>> should this draft describe what is happening in the >> real-world or what >>> the WG plans to see. We think this draft is to capture what is >>> happening in the real-world. >>>=20 >>> Q2: Should the SBC reset the Max-Forwards? In our network, the SBC >>> does reset the Max-Forwards. However, the IESG thinks the >> SBC should=20 >>> decrement the Max-Forwards rather than resetting it. This >> is back to=20 >>> Q1, should this draft be descriptive or prescriptive. >>>=20 >>> After we receive comments from the WG, we will update the draft and >>> release a new revision. >>>=20 >>> Thanks, >>> Adam and Yiu >>>=20 >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www.ietf.org/mailman/listinfo/speermint >>=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint ----------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com From root@core3.amsl.com Thu Dec 3 10:45:01 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EA28A3A681F; Thu, 3 Dec 2009 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091203184501.EA28A3A681F@core3.amsl.com> Date: Thu, 3 Dec 2009 10:45:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-voip-consolidated-usecases-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : VoIP SIP Peering Use Cases Author(s) : A. Uzelac, Y. Lee Filename : draft-ietf-speermint-voip-consolidated-usecases-15.txt Pages : 25 Date : 2009-12-03 This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-voip-consolidated-usecases-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-03103607.I-D@ietf.org> --NextPart-- From yiu_lee@cable.comcast.com Thu Dec 3 10:48:21 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0C53A6782 for ; Thu, 3 Dec 2009 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWh5n+b4byrG for ; Thu, 3 Dec 2009 10:48:20 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 531893A67A5 for ; Thu, 3 Dec 2009 10:48:20 -0800 (PST) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.63021977; Thu, 03 Dec 2009 13:48:09 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 13:48:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Dec 2009 18:48:08 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3342692884_1108569" Date: Thu, 3 Dec 2009 13:48:03 -0500 Message-ID: In-Reply-To: <20091203184501.EA28A3A681F@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D Action:draft-ietf-speermint-voip-consolidated-usecases-15.txt thread-index: Acp0SSSpYooJ8EJhWkCQQnNelyaWqw== From: "Lee, Yiu" To: X-OriginalArrivalTime: 03 Dec 2009 18:48:09.0224 (UTC) FILETIME=[285F2880:01CA7449] Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-voip-consolidated-usecases-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:48:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342692884_1108569 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This revision tries to address the comments from the AD reviews. Please take time to review it. Thanks. On 12/3/09 1:45 PM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session PEERing for Multimedia INTerconnect > Working Group of the IETF. > > > Title : VoIP SIP Peering Use Cases > Author(s) : A. Uzelac, Y. Lee > Filename : draft-ietf-speermint-voip-consolidated-usecases-15.txt > Pages : 25 > Date : 2009-12-03 > > This document depicts many common Voice over IP (VoIP) use cases for > Session Initiation Protocol (SIP) Peering. These use cases are > categorized into static and on-demand, and then further sub- > categorized into direct and indirect. These use cases are not an > exhaustive set, but rather the most common use cases deployed today. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 6, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-use > cases-15.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint --B_3342692884_1108569 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBTcWwcqiRnIOA/0V2ZsaG5TGaWaTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDMxODQ4MDNaMA0GCSqGSIb3DQEBAQUABIIBAIGx ynoa+XCTi7sLN799FeaRKvB2g/aEUaGbfckZDdas8w5t6EBfMRxfxeuKl86KoqL9A2fSJHbf XmbZPBK1eTCcW9hSGF/jpaYzT0EucAhInjK+wKYFPDsA4Pp2eSXZ4tqDr4h66RTQkAUDJald lXEB4oN+A4U5KY7nnEoic6PhBdf+Trvmm+8SZ12HoNJMbYHVoI+DI6Amz55YkYBNKVDBhHmB ssBOBtLDR3vEW1YOmXwXUyz8lyDY1fbFBSPLchgNB1IV9+poJsaRoAyTXhP+V0+ZBOg5y5Pk 2fmaJj7oCa0EsM7spOyfxvpeHGuBKu5OCKH7P+1AWYxEIlz7OHA= --B_3342692884_1108569-- From D.Hancock@CableLabs.com Fri Dec 4 10:42:50 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555333A6A21 for ; Fri, 4 Dec 2009 10:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f02fvTHhC8-B for ; Fri, 4 Dec 2009 10:42:49 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 772853A6A16 for ; Fri, 4 Dec 2009 10:42:49 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id nB4Igduo028131 for ; Fri, 4 Dec 2009 11:42:39 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 4 Dec 2009 11:42:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Dec 2009 11:42:39 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Interconnect draft - requirement entity Thread-Index: Acp1EY4Fzu9yvIiaRemQ4uFstjlDXQ== From: "David Hancock" To: X-Approved: ondar Subject: [Speermint] SIP Interconnect draft - requirement entity X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:42:50 -0000 I would like to start addressing the comments received during presentation of draft-hancock-sip-interconnect-guidelines-02 at the IETF#76 SPEERMINT meeting. This email discusses the comment received on the first issue.=20 Here is the issue: What entity is used as the subject of normative statements in the document? Comments recorded in the meeting minutes: JON PETERSON on Requirement Entity (slide 5): Make sure that the interconnect spec describes what the SIP traffic between domains looks like must comply with) WITHOUT RESPECT TO WHAT ELEMENT makes this happen or how it is achieved. IMPORTANT POINT / KEY CHANGE!!=20 Proposed resolution: Actually version 02 of the draft already proposes a resolution, so I would like to start with that. This solution places requirements on the SBE and DBE, but modifies the definition of these entities slightly (within the scope of the draft) to meet the spirit of the above comment. Here is the text from the -02 draft, inserted immediately after the architecture diagram in section-3: This document places requirements on the following two entities in the Peering architecture: o the SBE in support of the SIP/SDP interface between two peering networks o the DBE in support of the RTP/RTCP interface between peering networks Based on the definition of the SBE in the peering architecture document [I-D.ietf-speermint-architecture], it's not entirely correct to make the SBE responsible for meeting all the SIP signaling requirements at the peering interface. For example, the SBE can play the role of a firewall or a SIP proxy that is largely transparent to the SIP messages crossing the interface. In reality, the responsibility for supporting this interface belongs to all the SIP entities in the SIP signaling chain, including the SBE plus the SIP proxies and UAs inside the network. Furthermore, when this network is serving as a transit network, the SIP signaling chain can extend into another network. To resolve this issue, this document extends the definition of the SBE slightly so that when it is specified as the target entity of a normative requirement on the SIP/SDP peering interface, the SBE represents all the SIP entities in the SIP signaling chain that can effect the SIP/SDP peering interface. Likewise, the DBE can act as a media relay (performing no media encode/decode) that is transparent to the RTP/RTCP packets exchanged with the peer network. Therefore, this document extends the definition of the DBE so that when it is specified as the target entity of a normative requirement on the RTP/RTCP interface, it represents the media endpoint in the peering network that terminates the RTP/RTCP stream. Is this approach acceptable to everyone, or would you like to see something different? Thanks David From hmmr@cisco.com Sat Dec 5 11:40:28 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501C73A685B for ; Sat, 5 Dec 2009 11:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DofVHSfX5PsI for ; Sat, 5 Dec 2009 11:40:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 085943A682B for ; Sat, 5 Dec 2009 11:40:26 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHNFGkutJV2a/2dsb2JhbAC+LJZlhDME X-IronPort-AV: E=Sophos;i="4.47,347,1257120000"; d="scan'208";a="72302411" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Dec 2009 19:40:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nB5JeGxF020850; Sat, 5 Dec 2009 19:40:16 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Dec 2009 13:40:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Dec 2009 13:40:15 -0600 Message-ID: In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SIP Interconnect draft - requirement entity Thread-Index: Acp1EY4Fzu9yvIiaRemQ4uFstjlDXQA0R4Zw References: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> From: "Mike Hammer (hmmr)" To: "David Hancock" , X-OriginalArrivalTime: 05 Dec 2009 19:40:16.0098 (UTC) FILETIME=[C4F5C420:01CA75E2] Subject: Re: [Speermint] SIP Interconnect draft - requirement entity X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 19:40:28 -0000 David, This is in line with the comments I made earlier about reflecting the functional entity to which the requirements apply. Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of David Hancock > Sent: Friday, December 04, 2009 1:43 PM > To: speermint@ietf.org > Subject: [Speermint] SIP Interconnect draft - requirement entity >=20 > I would like to start addressing the comments received during > presentation of draft-hancock-sip-interconnect-guidelines-02 at the > IETF#76 SPEERMINT meeting. This email discusses the comment received on > the first issue. >=20 > Here is the issue: > What entity is used as the subject of normative statements in the > document? >=20 > Comments recorded in the meeting minutes: > JON PETERSON on Requirement Entity (slide 5): Make sure that the > interconnect spec describes what the SIP traffic between domains looks > like must comply with) WITHOUT RESPECT TO WHAT ELEMENT makes this happen > or how it is achieved. IMPORTANT POINT / KEY CHANGE!! >=20 > Proposed resolution: > Actually version 02 of the draft already proposes a resolution, so I > would like to start with that. This solution places requirements on the > SBE and DBE, but modifies the definition of these entities slightly > (within the scope of the draft) to meet the spirit of the above comment. >=20 > Here is the text from the -02 draft, inserted immediately after the > architecture diagram in section-3: >=20 > This document places requirements on the following two entities in > the Peering architecture: >=20 > o the SBE in support of the SIP/SDP interface between two peering > networks >=20 > o the DBE in support of the RTP/RTCP interface between peering > networks >=20 > Based on the definition of the SBE in the peering architecture > document [I-D.ietf-speermint-architecture], it's not entirely correct > to make the SBE responsible for meeting all the SIP signaling > requirements at the peering interface. For example, the SBE can play > the role of a firewall or a SIP proxy that is largely transparent to > the SIP messages crossing the interface. In reality, the > responsibility for supporting this interface belongs to all the SIP > entities in the SIP signaling chain, including the SBE plus the SIP > proxies and UAs inside the network. Furthermore, when this network > is serving as a transit network, the SIP signaling chain can extend > into another network. To resolve this issue, this document extends > the definition of the SBE slightly so that when it is specified as > the target entity of a normative requirement on the SIP/SDP peering > interface, the SBE represents all the SIP entities in the SIP > signaling chain that can effect the SIP/SDP peering interface. >=20 > Likewise, the DBE can act as a media relay (performing no media > encode/decode) that is transparent to the RTP/RTCP packets exchanged > with the peer network. Therefore, this document extends the > definition of the DBE so that when it is specified as the target > entity of a normative requirement on the RTP/RTCP interface, it > represents the media endpoint in the peering network that terminates > the RTP/RTCP stream. >=20 > Is this approach acceptable to everyone, or would you like to see > something different? >=20 > Thanks > David >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint From hmmr@cisco.com Sat Dec 5 12:06:52 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965113A685B for ; Sat, 5 Dec 2009 12:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woc52T7Zke1g for ; Sat, 5 Dec 2009 12:06:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6038A3A6807 for ; Sat, 5 Dec 2009 12:06:51 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADNMGkutJV2a/2dsb2JhbAC+PpZhhDME X-IronPort-AV: E=Sophos;i="4.47,347,1257120000"; d="scan'208";a="72226387" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2009 20:06:41 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nB5K6fKE023888; Sat, 5 Dec 2009 20:06:41 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Dec 2009 14:06:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Dec 2009 14:06:40 -0600 Message-ID: In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SIP Interconnect draft - requirement entity Thread-Index: Acp1EY4Fzu9yvIiaRemQ4uFstjlDXQA1Lfxw References: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> From: "Mike Hammer (hmmr)" To: "David Hancock" , X-OriginalArrivalTime: 05 Dec 2009 20:06:40.0965 (UTC) FILETIME=[759D4750:01CA75E6] Subject: Re: [Speermint] SIP Interconnect draft - requirement entity X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 20:06:52 -0000 David, Given the text you have below, could you take a look at the section headings as well? That may give rise to implicit assumptions about where exactly some function might be performed. Mike > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of David Hancock > Sent: Friday, December 04, 2009 1:43 PM > To: speermint@ietf.org > Subject: [Speermint] SIP Interconnect draft - requirement entity >=20 > I would like to start addressing the comments received during > presentation of draft-hancock-sip-interconnect-guidelines-02 at the > IETF#76 SPEERMINT meeting. This email discusses the comment received on > the first issue. >=20 > Here is the issue: > What entity is used as the subject of normative statements in the > document? >=20 > Comments recorded in the meeting minutes: > JON PETERSON on Requirement Entity (slide 5): Make sure that the > interconnect spec describes what the SIP traffic between domains looks > like must comply with) WITHOUT RESPECT TO WHAT ELEMENT makes this happen > or how it is achieved. IMPORTANT POINT / KEY CHANGE!! >=20 > Proposed resolution: > Actually version 02 of the draft already proposes a resolution, so I > would like to start with that. This solution places requirements on the > SBE and DBE, but modifies the definition of these entities slightly > (within the scope of the draft) to meet the spirit of the above comment. >=20 > Here is the text from the -02 draft, inserted immediately after the > architecture diagram in section-3: >=20 > This document places requirements on the following two entities in > the Peering architecture: >=20 > o the SBE in support of the SIP/SDP interface between two peering > networks >=20 > o the DBE in support of the RTP/RTCP interface between peering > networks >=20 > Based on the definition of the SBE in the peering architecture > document [I-D.ietf-speermint-architecture], it's not entirely correct > to make the SBE responsible for meeting all the SIP signaling > requirements at the peering interface. For example, the SBE can play > the role of a firewall or a SIP proxy that is largely transparent to > the SIP messages crossing the interface. In reality, the > responsibility for supporting this interface belongs to all the SIP > entities in the SIP signaling chain, including the SBE plus the SIP > proxies and UAs inside the network. Furthermore, when this network > is serving as a transit network, the SIP signaling chain can extend > into another network. To resolve this issue, this document extends > the definition of the SBE slightly so that when it is specified as > the target entity of a normative requirement on the SIP/SDP peering > interface, the SBE represents all the SIP entities in the SIP > signaling chain that can effect the SIP/SDP peering interface. >=20 > Likewise, the DBE can act as a media relay (performing no media > encode/decode) that is transparent to the RTP/RTCP packets exchanged > with the peer network. Therefore, this document extends the > definition of the DBE so that when it is specified as the target > entity of a normative requirement on the RTP/RTCP interface, it > represents the media endpoint in the peering network that terminates > the RTP/RTCP stream. >=20 > Is this approach acceptable to everyone, or would you like to see > something different? >=20 > Thanks > David >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint From john.elwell@siemens-enterprise.com Sun Dec 6 23:09:16 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BDB3A6A11 for ; Sun, 6 Dec 2009 23:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssGB-be11GQ3 for ; Sun, 6 Dec 2009 23:09:15 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 909C53A6A10 for ; Sun, 6 Dec 2009 23:09:15 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-212826; Mon, 7 Dec 2009 08:09:04 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 92E301EB81F1; Mon, 7 Dec 2009 08:09:04 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 7 Dec 2009 08:09:04 +0100 From: "Elwell, John" To: David Hancock , "speermint@ietf.org" Date: Mon, 7 Dec 2009 08:09:02 +0100 Thread-Topic: SIP Interconnect draft - requirement entity Thread-Index: Acp1EY4Fzu9yvIiaRemQ4uFstjlDXQBeiing Message-ID: References: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60278E8F7@srvxchg3.cablelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Speermint] SIP Interconnect draft - requirement entity X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 07:09:16 -0000 This seems a reasonable approach. John=20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of David Hancock > Sent: 04 December 2009 18:43 > To: speermint@ietf.org > Subject: [Speermint] SIP Interconnect draft - requirement entity >=20 > I would like to start addressing the comments received during > presentation of draft-hancock-sip-interconnect-guidelines-02 at the > IETF#76 SPEERMINT meeting. This email discusses the comment=20 > received on > the first issue.=20 >=20 > Here is the issue: > What entity is used as the subject of normative statements in the > document? >=20 > Comments recorded in the meeting minutes: > JON PETERSON on Requirement Entity (slide 5): Make sure that the > interconnect spec describes what the SIP traffic between domains looks > like must comply with) WITHOUT RESPECT TO WHAT ELEMENT makes=20 > this happen > or how it is achieved. IMPORTANT POINT / KEY CHANGE!!=20 >=20 > Proposed resolution: > Actually version 02 of the draft already proposes a resolution, so I > would like to start with that. This solution places=20 > requirements on the > SBE and DBE, but modifies the definition of these entities slightly > (within the scope of the draft) to meet the spirit of the=20 > above comment. >=20 > Here is the text from the -02 draft, inserted immediately after the > architecture diagram in section-3: >=20 > This document places requirements on the following two entities in > the Peering architecture: >=20 > o the SBE in support of the SIP/SDP interface between two peering > networks >=20 > o the DBE in support of the RTP/RTCP interface between peering > networks >=20 > Based on the definition of the SBE in the peering architecture > document [I-D.ietf-speermint-architecture], it's not=20 > entirely correct > to make the SBE responsible for meeting all the SIP signaling > requirements at the peering interface. For example, the=20 > SBE can play > the role of a firewall or a SIP proxy that is largely=20 > transparent to > the SIP messages crossing the interface. In reality, the > responsibility for supporting this interface belongs to all the SIP > entities in the SIP signaling chain, including the SBE plus the SIP > proxies and UAs inside the network. Furthermore, when this network > is serving as a transit network, the SIP signaling chain can extend > into another network. To resolve this issue, this document extends > the definition of the SBE slightly so that when it is specified as > the target entity of a normative requirement on the SIP/SDP peering > interface, the SBE represents all the SIP entities in the SIP > signaling chain that can effect the SIP/SDP peering interface. >=20 > Likewise, the DBE can act as a media relay (performing no media > encode/decode) that is transparent to the RTP/RTCP packets=20 > exchanged > with the peer network. Therefore, this document extends the > definition of the DBE so that when it is specified as the target > entity of a normative requirement on the RTP/RTCP interface, it > represents the media endpoint in the peering network that=20 > terminates > the RTP/RTCP stream. >=20 > Is this approach acceptable to everyone, or would you like to see > something different? >=20 > Thanks > David >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint > = From victor.pascual.avila@gmail.com Tue Dec 15 12:46:31 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D863A6891 for ; Tue, 15 Dec 2009 12:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xspc29aME4ob for ; Tue, 15 Dec 2009 12:46:30 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E08403A68D8 for ; Tue, 15 Dec 2009 12:46:25 -0800 (PST) Received: by bwz23 with SMTP id 23so282048bwz.29 for ; Tue, 15 Dec 2009 12:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ktmBe1olXaQRJV5kHXvXN9smDHnefXp9yqBfJ16zk08=; b=N56v/y34GYPy2975VYWUygd9QMGFMzw2GA7w/F9mdNMR9oArW5b7aTaWX5+6jNRnal dzP4H4izT4aFD83+JanpqZwXYF48gWz6mKlqq2c807BPXgMWkTZuoWi+UsPgib2VofrV OlZjUk+zFx6zkH2cNBUweM0aF4PqSYLfJz2AQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YhjiqAjzN3axYH+PyIo/Wyd9XwRTerNfGs7U/w1SJQjjq4JuVW+vUGlILFWajgiYSR 7XwrPXKXjNFhrd7YwVCNPKEYQpwlvbziumg+jfrSSbRlXN2v8xxeYNkzZAo/03QwvlPc yeG4HxrLA/x5tAHhU6okvBuYR+VcZJNhhhm9A= MIME-Version: 1.0 Received: by 10.204.32.19 with SMTP id a19mr25133bkd.90.1260909968208; Tue, 15 Dec 2009 12:46:08 -0800 (PST) In-Reply-To: References: <9E1B4F4BA637A44BAD5E18CF09EAFB9003F7994A@mse14be2.mse14.exchange.ms> Date: Tue, 15 Dec 2009 21:46:08 +0100 Message-ID: <618e24240912151246hb340896r145b4904662d5bdd@mail.gmail.com> From: Victor Pascual Avila To: "Lee, Yiu" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 20:46:31 -0000 On Tue, Dec 1, 2009 at 8:40 PM, Lee, Yiu wrote: > For the Max-Forward question, the IESG believes that the SBC is only a ho= p > of the call, so it should not reset the Max-Forward. Rather, it should ju= st > decrement the Max-Forward. I support this opinion. --=20 Victor Pascual =C3=81vila From yiu_lee@cable.comcast.com Wed Dec 16 04:36:48 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80423A6930 for ; Wed, 16 Dec 2009 04:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmJf41PS4vmk for ; Wed, 16 Dec 2009 04:36:48 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id AF4983A690E for ; Wed, 16 Dec 2009 04:36:47 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.64454073; Wed, 16 Dec 2009 07:36:29 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 07:36:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 166.217.195.138 ([166.217.195.138]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Dec 2009 12:36:28 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="B_3343793783_1861" Date: Wed, 16 Dec 2009 07:36:22 -0500 Message-ID: In-Reply-To: <618e24240912151246hb340896r145b4904662d5bdd@mail.gmail.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Speermint] VoIP Use Cases Questions thread-index: Acp+TF+Zdaz3gIlxTkCpy6g7CDLLkg== From: "Lee, Yiu" To: "Victor Pascual Avila" X-OriginalArrivalTime: 16 Dec 2009 12:36:29.0656 (UTC) FILETIME=[6429DD80:01CA7E4C] Cc: speermint@ietf.org Subject: Re: [Speermint] VoIP Use Cases Questions X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 12:36:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3343793783_1861 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Victor, This change has been updated in version 15. Thanks, Yiu On 12/15/09 3:46 PM, "Victor Pascual Avila" wrote: > On Tue, Dec 1, 2009 at 8:40 PM, Lee, Yiu wrote: >> For the Max-Forward question, the IESG believes that the SBC is only a hop >> of the call, so it should not reset the Max-Forward. Rather, it should just >> decrement the Max-Forward. > > I support this opinion. --B_3343793783_1861 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBSXvxbhf6tFJXMazm2sgPt+BiKVejAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTYxMjM2MjJaMA0GCSqGSIb3DQEBAQUABIIBADcg aMvZrm5IUIxZV9nkQVW9i5iGrHTOoEWTEFKr72TIUMheU4g0dXISD5DOkGhSBQudHel1nnMi geuawwzNMeeMsE42Zjfc2PiKCSm6sDlxRuVTLSYqpe+ChrkPsZo9ThKE2p9uM/rkOYQrHOgf gg98K8D3Ic/yAwaqRSXB3CJg1WDlUw5v5tIkpihAWKEqPhpUewh6WmqmS87/1oUWv1ssapJu /7u1tTQJzcd5gJyDE1QTjSpLYy0EfaOgqvDmdeM1prdyKywUCnnsB5YF0gSEeRZ0DSRUdG2Z Mll9GN3PYan9NqecD+ZnvDwGy3QaVvi7KKIs9XSSPhuktGIa0tw= --B_3343793783_1861--