From nobody Fri Dec 1 19:47:22 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926DB126B72 for ; Fri, 1 Dec 2017 19:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBMiwDEqsgKX for ; Fri, 1 Dec 2017 19:47:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16901201FA for ; Fri, 1 Dec 2017 19:47:16 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB23lFq4094835 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Dec 2017 21:47:15 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "rtcweb@ietf.org" From: Adam Roach Cc: draft-ietf-rtcweb-sdp@tools.ietf.org Message-ID: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> Date: Fri, 1 Dec 2017 21:47:10 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 03:47:21 -0000 [as an individual] I wrote a script that extracts the SDP from the XML source of draft-ietf-rtcweb-sdp-08 and does some very basic syntax checks on it. I'm posting the results here as feedback on the document to assist in correcting the examples. Note that I have *not* performed any semantic verification of the SDP itself, only the syntax. Total error count: 152 ============================================================================== 5.2.1 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle a=identity:eyJpZHAiOnsiZG9tYWluIjoibmlpZi5odSIsInByb3RvY29sIjoiaWRwLmh0bWwifSwiYXNzZXJ0a W9uIjoiZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhVeUo5LmV5SmpiMjUwWlc1MGN5STZleUptYVc1b lpYSndjbWx1ZENJNlczc2lZV3huYjNKcGRHaHRJam9pYzJoaExUSTFOaUlzSW1ScFoyVnpkQ0k2SWprek9rTXdPa kl6T2pKR09rRXlPakF3T2pBd09qQkVPalV4T2tGRE9rUXlPalUwT2pZMU9rWTBPak5DT2pkRU9qa3lPa1JET2pnN E9qTXpPalV4T2pJek9qUXdPamN5T2preE9qZ3pPalZDT2pBeE9qSkdPalV3T2pjNE9qTkdJbjFkZlN3aWFXUmxib lJwZEhraU9pSnRhWE5wUUc1cGFXWXVhSFVpZlEuSTVQdGhKNFFDT05TOFVXd25OOUh3MEdaTDl3d0RBVGRrTWtFW llmdlNVTTJ6Umd5R09WSGgzRmpnc2FPZklkRnFsNUx6azBFbndVOTNQOUlCQ0xZOWtia3V1c0V1S25YRGVNLTNIN WFmdTJvZl9CTlZjUnB3MmdBdlNBbVR6SlltcEpqMFEtdmV0TmtVT1huZE9HLUIzT3ZGb3QwZVNENlZSNUdhb2wyc GduS3FSTktOd3dacEZ1eUZZbFRodHJIdGNiT19WV3o4QnZpTThKS25OdExWd1JxNUhMX2ZLTlRCNzFDYkoyWmh5W XU1UEdwWDhXcXJMWC1ybm5YSFY3RnhoTTh5OHdrLWd5cnRZazVnbFlZeUFrcTVqZklSXzRzWER5d19Qc1BWTW1aZ XltenVGV3BQTzVFWlJYR0ZpRjFET0o4Q0Q3Z3Zta2dUdlBXSWpkemtBIn0= *** ERROR: invalid syntax for 'identity' *** Note: Removing errant spaces fixes this problem. m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp:60065 IN IP4 203.0.113.141 a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 UDP  2122194687 192.0.2.4 61667 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 2 UDP  1685987071 203.0.113.141 60065 typ srflx raddr 192.0.2.4 rport 61667 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.2.1 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle a=identity:ew0KICAiaWRwIjp7DQogICAgImRvbWFpbiI6ICJjaXNjb3NwYXJrLmNvbSIsDQogICAg InByb3RvY29sIjogImRlZmF1bHQiDQogIH0sDQogICJhc3NlcnRpb24iOiAibEp3WkVocmFVOXBTblJo V0U1d1VVYzFjR0ZYV1hWaFNGVnBabEV1U1RWUWRHaEtORkZEVDA1VE9GVlhkMjVPT1VoM01FZGFURGwz ZDBSQlZHUnJUV3RGVw0KICAgICAgICAgICAgICBsbG1kbE5WVFRKNlVtZDVSMDlXU0dnelJtcG5jMkZQ Wmtsa1JuRnNOVXg2YXpCRmJuZFZPVE5RT1VsQ1EweFpPV3RpYTNWMWMwVjFTMjVZUkdWTkxUTklODQog ICAgICAgICAgICAgIFdGbWRUSnZabDlDVGxaalVuQjNNbWRCZGxOQmJWUjZTbGx0Y0VwcU1GRXRkbVYw VG10VlQxaHVaRTlITFVJelQzWkdiM1F3WlZORU5sWlNOVWRoYjJ3eWMNCiAgICAgICAgICAgICAgR2R1 UzNGU1RrdE9kM2RhY0VaMWVVWlpiRlJvZEhKSWRHTmlUMTlXVjNvNFFuWnBUVGhLUzI1T2RFeFdkMUp4 TlVoTVgyWkxUbFJDTnpGRFlrb3lXbWg1VyINCn0= *** ERROR: invalid syntax for 'identity' *** Note: Removing errant spaces fixes this problem. m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:05067423 a=ice-pwd:1747d1ee3474a28a397a4c3f3af08a068 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates ============================================================================== 5.2.2.1 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 99 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:120 VP8/90000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.2.1 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host a=candidate:1 1 UDP 565689203 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 99 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.2.2 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 1 UDP  2122194687 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 99 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 a=rtpmap:120 VP8/90000 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.2.2 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host a=candidate:0 1 UDP 3618095783 2001:DB8:30c:1266:5916:3779:22f6:77f7 49203 typ host a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 99 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 a=rtcp-fb:99 nack a=rtcp-fb:99 nack pli a=rtcp-fb:99 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.3 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE data a=ice-options:trickle m=application 54609 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.141 a=mid:data a=sendrecv a=sctp-port:5000 a=max-message-size:100000 a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=candidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host a=candidate:1 1 UDP 1694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 a=end-of-candidates ============================================================================== 5.2.3 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE data m=application 49203 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.77 a=mid:data a=sendrecv a=sctp-port:5000 a=max-message-size:100000 a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates ============================================================================== 5.2.4 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.2.4 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=inactive a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 198.51.100.7 51556 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 49203 typ srflx raddr 198.51.100.7 rport 51556 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.2.5 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio dtmf a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=audio 54609 UDP/TLS/RTP/SAVPF 126 c=IN IP4 203.0.113.141 a=mid:dtmf a=msid:ma tb a=sendonly a=rtpmap:126 telephone-event/8000 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.5 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio dtmf m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates m=audio 49203 UDP/TLS/RTP/SAVPF 126 c=IN IP4 203.0.113.77 a=mid:dtmf a=msid:ma tb a=recvonly a=rtpmap:126 telephone-event/8000 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.6 SDP Offer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 203.0.113.141 54609 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendonly a=rtpmap:120 VP8/90000 a=content:slides a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.6 SDP Answer ============================================================================== v=0 o=- 16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=recvonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 203.0.113.77 49203 typ host a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=recvonly a=rtpmap:120 VP8/90000 a=content:slides a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.7 SDP Offer w/BUNDLE ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp:54610 IN IP4 203.0.113.141 a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 UDP 2122194687 192.0.2.4 61666 typ host a=candidate:1 2 UDP  1685987071 203.0.113.141 54610 typ srflx raddr 192.0.2.4 rport 61666 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. m=video 62537 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=ice-ufrag:6550074c a=ice-pwd:74af08a068a28a397a4c3f31747d1ee34 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:2 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp:62538 IN IP4 203.0.113.141 a=rtcp-rsize a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61886 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 62537 typ srflx raddr 192.0.2.4 rport 61886 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 2122194687 192.0.2.4 61888 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Adding 'UDP' fixes this problem. a=candidate:1 2 UDP 1685987071 203.0.113.141 62538 typ srflx raddr 192.0.2.4 rport 61888 ============================================================================== 5.2.8 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video data a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=msid:ma ta a=mid:audio a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid m=application 54609 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.141 a=mid:data a=sctp-port:5000 a=max-message-size:100000 a=sendrecv ============================================================================== 5.2.8 SDP Answer ============================================================================== v=0 o=- 16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video data a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=msid:ma ta a=mid:audio a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid m=application 49203 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.77 a=mid:data a=sctp-port:5000 a=max-message-size:100000 a=sendrecv ============================================================================== 5.2.10 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 54609 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid m=application 10000 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.141 a=mid:data a=sctp-port:5000 a=max-message-size:100000 a=sendrecv a=setup:actpass a=ice-ufrag:89819013 a=ice-pwd:1747d1ee3474af08a068a28a397a4c3f3 a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=candidate:0 1 UDP  2113667327 192.0.2.4 10000 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.2.10 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid m=application 20000 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 203.0.113.77 a=mid:data a=sctp-port:5000 a=max-message-size:100000 a=setup:active a=sendrecv a=ice-ufrag:991Ca2a5e a=ice-pwd:921d5d47efbabd9a2de4e99bd291c325 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=candidate:0 1 UDP 2113667327 198.51.100.7 20000 typ host a=end-of-candidates ============================================================================== 5.2.11 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.2.10 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates ============================================================================== 5.2.11 SDP Updated Offer ============================================================================== v=0 o=- 20518 1 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 54609 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.141 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.2.11 SDP Updated Answer ============================================================================== v=0 o=-  16833 1 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio video a=group:LS audio video a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 120 c=IN IP4 203.0.113.77 a=mid:video a=msid:ma tb a=sendrecv a=rtpmap:120 VP8/90000 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.3.1 SDP Offer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 m2 a=group:LS m0 m1 a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:m0 a=msid:ma ta a=sendonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 0 UDP/TLS/RTP/SAVPF 98 100 c=IN IP4 203.0.113.141 a=bundle-only a=mid:m1 a=msid:ma tb a=sendonly a=rtpmap:98 VP8/90000 a=fmtp:98 max-fr=30 a=rtpmap:100 VP8/90000 a=fmtp:100 max-fr=15 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:1 send pt=98;max-width=1280;max-height=720; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:2 send pt=100;max-width=640;max-height=480; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:send 1;~2 m=video 0 UDP/TLS/RTP/SAVPF 101 102 c=IN IP4 203.0.113.141 a=bundle-only a=mid:m2 a=msid:ma tc a=sendonly a=rtpmap:101 H264/90000 a=rtpmap:102 H264/90000 a=fmtp:101 profile-level-id=42401f;packetization-mode=0;max-fr=30 a=fmtp:102 profile-level-id=42401f;packetization-mode=1;max-fr=15 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:3 send pt=101;max-width=1280;max-height=720; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:4 send pt=102;max-width=640;max-height=360; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:send 3;4 ============================================================================== 5.3.1 SDP Answer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 m2 a=group:LS m0 m1 a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:m0 a=msid:ma ta a=recvonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 198.51.100.7 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 98 100 c=IN IP4 203.0.113.77 a=mid:m1 a=msid:ma tb a=recvonly a=rtpmap:98 VP8/90000 a=rtpmap:100 VP8/90000 a=fmtp:98 max-fr=30 a=fmtp:100 max-fr=15 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:1 recv pt=98;max-width=1280;max-height=720; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:2 recv pt=100;max-width=640;max-height=480; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:recv 1;2 m=video 49203 UDP/TLS/RTP/SAVPF 101 102 c=IN IP4 203.0.113.77 a=mid:m2 a=msid:ma tc a=recvonly a=rtpmap:101 H264/90000 a=rtpmap:102 H264/90000 a=fmtp:101 profile-level-id=42401f;packetization-mode=1;max-fr=30 a=fmtp:102 profile-level-id=42401f;packetization-mode=1;max-fr=15 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:3 recv pt=101;max-width=1280;max-height=720; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:4 recv pt=102;max-width=640;max-height=360; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:recv 3;4 ============================================================================== 5.3.2 SDP Offer with SVC ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 a=group:LS m0 m1 a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:m0 a=msid:ma ta a=sendonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 0 UDP/TLS/RTP/SAVPF 96 97 100 c=IN IP4 203.0.113.141 a=bundle-only a=mid:m1 a=msid:ma tb a=sendonly a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=4d0028; packetization-mode=1;max-fr=30;max-fs=8040 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=4d0028;packetization-mode=1; max-fr=15;max-fs=1200 a=rtpmap:100 H264-SVC/90000 a=fmtp:100 profile-level-id=4d0028;packetization-mode=1; max-fr=30;max-fs=8040 a=depend:100 lay m1:96,97 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.3.2 SDP Answer with SVC ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 a=group:LS m0 m1 a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:m0 a=msid:ma ta a=recvonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host a=candidate:1 1 UDP  1694302206 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 96 100 c=IN IP4 203.0.113.77 a=mid:m1 a=msid:ma tb a=recvonly a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=4d0028;packetization-mode=1; max-fr=30;max-fs=8040 a=rtpmap:100 H264-SVC/90000 a=fmtp:100 profile-level-id=4d0028;packetization-mode=1; max-fr=30;max-fs=8040 a=depend:100 lay m1:96 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid ============================================================================== 5.3.5 SDP Offer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 a=group:LS m0 m1 a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=mid:m0 a=msid:ma ta a=sendonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=rtcp-mux a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 0 UDP/TLS/RTP/SAVPF 98 100 101 103 c=IN IP4 203.0.113.141 a=bundle-only a=mid:m1 a=msid:ma tb a=sendonly a=rtpmap:98 VP8/90000 a=rtpmap:100 VP8/90000 a=rtpmap:101 flexfec/90000 a=rtpmap:103 flexfec/90000 a=fmtp:98 max-fr=30;max-fs=8040 a=fmtp:100 max-fr=15;max-fs=1200 a=fmtp:101 L=5; D=10; ToP=2; repair-window=200000 a=fmtp:103 L=5; D=10; ToP=2; repair-window=200000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:1 send pt=98; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:2 send pt=100; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:send 1;2 ============================================================================== 5.3.5 SDP Answer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE m0 m1 a=group:LS m0 m1 a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.77 a=mid:m0 a=msid:ma ta a=recvonly a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host a=candidate:1 1 UDP  1694302206 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates m=video 49203 UDP/TLS/RTP/SAVPF 98 100 101 103 c=IN IP4 203.0.113.77 a=mid:m1 a=msid:ma tb a=recvonly a=rtpmap:98 VP8/90000 a=rtpmap:100 VP8/90000 a=rtpmap:101 flexfec/90000 a=rtpmap:103 flexfec/90000 a=fmtp:98 max-fr=30;max-fs=8040 a=fmtp:100 max-fr=15;max-fs=1200 a=fmtp:101 L=5; D=10; ToP=2; repair-window=200000 a=fmtp:103 L=5; D=10; ToP=2; repair-window=200000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id *** ERROR: invalid syntax for 'extmap' *** Note: Removing duplicate 'a=' fixes this. a=rid:1 recv pt=98; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=rid:2 recv pt=100; *** ERROR: invalid syntax for 'rid' *** Note: Removing trailing semicolon fixes this. a=simulcast:recv 1;2 ============================================================================== 5.4.1 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=rtcp-fb:* nack a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.4.1 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 98 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMA/8000 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=rtcp-fb:* nack a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates ============================================================================== 5.4.2 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 c=IN IP4 203.0.113.141 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMA/8000 a=maxptime:120 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:actpass a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=rtcp-fb:* nack a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr 192.0.2.4 rport 61665 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=end-of-candidates ============================================================================== 5.4.2 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE audio a=ice-options:trickle m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 98 c=IN IP4 203.0.113.77 a=mid:audio a=msid:ma ta a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMA/8000 a=maxptime:120 a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=tls-id:1 *** ERROR: invalid syntax for 'tls-id' *** Note: tls-id must be 20 chars or longer. a=rtcp-mux a=rtcp-rsize a=rtcp-fb:* nack a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 a=end-of-candidates ============================================================================== 5.4.3 SDP Answer ============================================================================== v=0 o=- 20519 0 IN IP4 0.0.0.0 s=- t=0 0 m=audio 49203 UDP/TLS/RTP/SAVPF 109 c=IN IP4 203.0.113.141 a=rtcp:60065 IN IP4 203.0.113.141 a=sendrecv a=rtpmap:109 opus/48000/2 a=maxptime:120 a=ice-ufrag:ufrag:c300d85b *** ERROR: invalid syntax for 'ice-ufrag' *** Note: Removing errant 'ufrag:' fixes this. a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=setup:active a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=candidate:0 1 UDP  2113667327 198.51.100.7 51556 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 51556 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 UDP 2113667326 198.51.100.7 51558 typ host a=candidate:1 2 UDP  1694302206 203.0.113.77 60065 typ srflx raddr 198.51.100.7 rport 51558 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. m=video 0 UDP/TLS/RTP/SAVPF 98 100 m=video 0 UDP/TLS/RTP/SAVPF 98 100 ============================================================================== 5.4.5 SDP Offer ============================================================================== v=0 o=- 20518 0 IN IP4 0.0.0.0 s=- t=0 0 a=ice-ufrag:074c6550 a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 a=rtcp-rsize m=audio 54732 RTP/AVP 109 *** ERROR: invalid syntax for 'm' *** Note: Using the correct transport value fixes this. c=IN IP4 203.0.113.141 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=rtpmap:109 opus/48000 a=ptime:20 a=sendrecv a=rtcp-mux a=rtcp:64678 IN IP4 203.0.113.141 a=candidate:0 1 UDP  2113667327 192.0.2.4 54732 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  694302207 203.0.113.141 54732 typ srflx raddr 192.0.2.4 rport 54732 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 UDP 2113667326 192.0.2.4 64678 typ host a=candidate:1 2 UDP  1694302206 203.0.113.141 64678 typ srflx raddr 192.0.2.4 rport 64678 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. m=video 62445 RTP/AVP 120 *** ERROR: invalid syntax for 'm' *** Note: Using the correct transport value fixes this. c=IN IP4 203.0.113.141 a=fingerprint:sha-256 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=rtpmap:120 VP8/90000 a=sendrecv a=rtcp-mux a=rtcp:54721 IN IP4 203.0.113.141 a=candidate:0 1 UDP  2113667327 192.0.2.4 62445 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:1 1 UDP  1694302207 203.0.113.141 62537 typ srflx raddr 192.0.2.4 rport 62445 *** ERROR: invalid syntax for 'candidate' *** Note: Removing errant spaces fixes this problem. a=candidate:0 2 2113667326 192.0.2.4 54721 typ host *** ERROR: invalid syntax for 'candidate' *** Note: Adding 'UDP' fixes this problem. a=candidate:1 2 UDP 1694302206 203.0.113.141 54721 typ srflx raddr 192.0.2.4 rport 54721 a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir ============================================================================== 5.4.5 SDP Answer ============================================================================== v=0 o=-  16833 0 IN IP4 0.0.0.0 s=- t=0 0 m=audio 49203 RTP/AVP 109 *** ERROR: invalid syntax for 'm' *** Note: Using the correct transport value fixes this. c=IN IP4 203.0.113.77 a=rtpmap:109 opus/48000 a=ptime:20 a=sendrecv a=ice-ufrag:c300d85b a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 a=fingerprint:sha-256 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 *** ERROR: invalid syntax for 'fingerprint' *** Note: Removing errant spaces fixes this problem. a=rtcp-mux a=candidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.51.100.7 rport 49203 m=video  63130 RTP/SAVP 120 *** ERROR: invalid syntax for 'm' *** Note: Using the correct transport value fixes this. c=IN IP4 203.0.113.77 a=rtpmap:120 VP8/90000 a=sendrecv a=ice-ufrag:e39091na a=ice-pwd:dbc325921d5dd29e4e99147efbabd9a2 a=fingerprint:sha-256 BB:0A9:0E:05:E9:26:33:E8:70:88:A25:2F:70:9F:04: :19:E2:1C:3B:4B:9F:81:5:2F:70:9F:04::F4:A5:A8:D8: *** ERROR: invalid syntax for 'fingerprint' (there's too much wrong here to enumerate) a=rtcp-mux a=candidate:0 1 UDP 2113667327 198.51.100.7 63130 typ host a=candidate:1 1 UDP 1694302207 203.0.113.77 63130 typ srflx raddr 198.51.100.7 rport 63130 a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir /a From nobody Sat Dec 2 02:01:39 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E26126B7E for ; Sat, 2 Dec 2017 02:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXCRPDtfYuFp for ; Sat, 2 Dec 2017 02:01:32 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE82E124BAC for ; Sat, 2 Dec 2017 02:01:31 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-65-5a2279f9d319 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4E.A2.13624.9F9722A5; Sat, 2 Dec 2017 11:01:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Sat, 2 Dec 2017 11:01:29 +0100 From: Christer Holmberg To: Adam Roach , "rtcweb@ietf.org" CC: "draft-ietf-rtcweb-sdp@tools.ietf.org" Thread-Topic: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp Thread-Index: AQHTayJhmBFuBmiUPUGn/k7cmaR5PKMv0T1A Date: Sat, 2 Dec 2017 10:01:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0354AC@ESESSMB109.ericsson.se> References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> In-Reply-To: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdUvdnpVKUwcZOY4s9fxexW/zrfMJo sfZfO7sDs8eSJT+ZPGbtfMLi8eXyZ7YA5igum5TUnMyy1CJ9uwSujEWn1rIXfFvKWtG6/SZ7 A+ORKaxdjJwcEgImEnee72DpYuTiEBI4zCix+/9+VghnMaPE5m03mLsYOTjYBCwkuv9pgzSI CLhJbPz2jh3EZhYIlrj58CQbiC0sYCNx+soiVogaW4ll+3YxQ9hGEqunL2ADGcMioCLxZnEm SJhXwFeif8skRhBbSMBOYtqZc0wgJZwC9hL/jgeBhBkFxCS+n1rDBLFJXOLWk/lMECcLSCzZ c54ZwhaVePn4H9QrShIrtl9iBBnDLKApsX6XPkSrosSU7ofsEFsFJU7OfMIygVF0FpKpsxA6 ZiHpmIWkYwEjyypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwLg5uOW31Q7Gg88dDzEKcDAq 8fDOzVKKEmJNLCuuzD3EKMHBrCTC+9oOKMSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBA emJJanZqakFqEUyWiYNTqoExi0Vp0+KLntV7Nsa2Nh/3m6KR1q1vb/TbrGlhn9wetTVPZzZ5 Cz74pfjnsN/S4kqfX5bb0zk7txVN3iIzr8rQeKlF2vpbycVxaYqlvM8nOjHNaZ11Xtu3+9vK Btvnb6PPzo7Of29RpDEhua4ma/ureasn9ndJqfxanXP2LN+Dlhmc79/4ytsqsRRnJBpqMRcV JwIAMcZAp5cCAAA= Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 10:01:38 -0000 SGksDQoNCkluIGFkZGl0aW9uIHRvIHRoZSBjb21tZW50cyBnaXZlbiBieSBBZGFtLCB0aGUgZXhh bXBsZXMgYWxzbyBuZWVkIHRvIGJlIHVwZGF0ZWQgaW4gb3JkZXIgdG8gcmVmbGVjdCB0aGUgbGF0 ZXN0IHZlcnNpb24gb2YgQlVORExFOiBhcGFydCBmcm9tIHRoZSBpbml0aWFsIG9mZmVyIChyZWFk OiBiZWZvcmUgdGhlIGJ1bmRsZSBncm91cCBoYXMgYmVlbiBjcmVhdGVkKSwgdGhlIHBvcnQgaXMg T05MWSBhc3NpZ25lZCB0byB0aGUgYnVuZGxlZCBtLSBzZWN0aW9uIHJlcHJlc2VudGVkIGJ5IHRo ZSBCVU5ETEUtdGFnLiBBbGwgb3RoZXIgbS0gc2VjdGlvbnMgKGJvdGggaW4gb2ZmZXJzIGFuZCBh bnN3ZXJzKSBoYXZlIGEgemVybyBwb3J0IHZhbHVlIGFuZCBhbiBTRFAgYnVuZGxlLW9ubHkgYXR0 cmlidXRlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBZGFtIFJvYWNoDQpTZW50OiAwMiBEZWNlbWJlciAyMDE3IDA1OjQ3DQpUbzogcnRj d2ViQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1ydGN3ZWItc2RwQHRvb2xzLmlldGYub3JnDQpT dWJqZWN0OiBbcnRjd2ViXSBTeW50YXggaXNzdWVzIGluIGRyYWZ0LWlldGYtcnRjd2ViLXNkcA0K DQpbYXMgYW4gaW5kaXZpZHVhbF0NCg0KSSB3cm90ZSBhIHNjcmlwdCB0aGF0IGV4dHJhY3RzIHRo ZSBTRFAgZnJvbSB0aGUgWE1MIHNvdXJjZSBvZiANCmRyYWZ0LWlldGYtcnRjd2ViLXNkcC0wOCBh bmQgZG9lcyBzb21lIHZlcnkgYmFzaWMgc3ludGF4IGNoZWNrcyBvbiBpdC4gDQpJJ20gcG9zdGlu ZyB0aGUgcmVzdWx0cyBoZXJlIGFzIGZlZWRiYWNrIG9uIHRoZSBkb2N1bWVudCB0byBhc3Npc3Qg aW4gDQpjb3JyZWN0aW5nIHRoZSBleGFtcGxlcy4gTm90ZSB0aGF0IEkgaGF2ZSAqbm90KiBwZXJm b3JtZWQgYW55IHNlbWFudGljIA0KdmVyaWZpY2F0aW9uIG9mIHRoZSBTRFAgaXRzZWxmLCBvbmx5 IHRoZSBzeW50YXguDQoNClRvdGFsIGVycm9yIGNvdW50OiAxNTINCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQo1LjIuMSBTRFAgT2ZmZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS0g MjA1MTggMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgYXVkaW8N CmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KYT1pZGVudGl0eTpleUpwWkhBaU9uc2laRzl0WVdsdUlq b2libWxwWmk1b2RTSXNJbkJ5YjNSdlkyOXNJam9pYVdSd0xtaDBiV3dpZlN3aVlYTnpaWEowYSAN Clc5dUlqb2laWGxLYUdKSFkybFBhVXBUVlhwSk1VNXBTWE5KYmxJMVkwTkpOa2xyY0ZoVmVVbzVM bVY1U21waU1qVXdXbGMxTUdONVNUWmxlVXB0WVZjMWIgDQpscFlTbmRqYld4MVpFTkpObGN6YzJs WlYzaHVZak5LY0dSSGFIUkphbTlwWXpKb2FFeFVTVEZPYVVselNXMVNjRm95Vm5wa1EwazJTV3By ZWs5clRYZFBhIA0Ka2w2VDJwS1IwOXJSWGxQYWtGM1QycEJkMDlxUWtWUGFsVjRUMnRHUkU5clVY bFBhbFV3VDJwWk1VOXJXVEJQYWs1RFQycGtSVTlxYTNsUGExSkVUMnBuTiANCkU5cVRYcFBhbFY0 VDJwSmVrOXFVWGRQYW1ONVQycHJlRTlxWjNwUGFsWkRUMnBCZUU5cVNrZFBhbFYzVDJwak5FOXFU a2RKYmpGa1psTjNhV0ZYVW14aWIgDQpsSndaRWhyYVU5cFNuUmhXRTV3VVVjMWNHRlhXWFZoU0ZW cFpsRXVTVFZRZEdoS05GRkRUMDVUT0ZWWGQyNU9PVWgzTUVkYVREbDNkMFJCVkdSclRXdEZXIA0K bGxtZGxOVlRUSjZVbWQ1UjA5V1NHZ3pSbXBuYzJGUFprbGtSbkZzTlV4NmF6QkZibmRWT1ROUU9V bENRMHhaT1d0aWEzVjFjMFYxUzI1WVJHVk5MVE5JTiANCldGbWRUSnZabDlDVGxaalVuQjNNbWRC ZGxOQmJWUjZTbGx0Y0VwcU1GRXRkbVYwVG10VlQxaHVaRTlITFVJelQzWkdiM1F3WlZORU5sWlNO VWRoYjJ3eWMgDQpHZHVTM0ZTVGt0T2QzZGFjRVoxZVVaWmJGUm9kSEpJZEdOaVQxOVdWM280UW5a cFRUaEtTMjVPZEV4V2QxSnhOVWhNWDJaTFRsUkNOekZEWWtveVdtaDVXIA0KWFUxVUVkd1dEaFhj WEpNV0MxeWJtNVlTRlkzUm5ob1RUaDVPSGRyTFdkNWNuUlphelZuYkZsWmVVRnJjVFZxWmtsU1h6 UnpXRVI1ZDE5UWMxQldUVzFhWiANClhsdGVuVkdWM0JRVHpWRldsSllSMFpwUmpGRVQwbzRRMFEz WjNadGEyZFVkbEJYU1dwa2VtdEJJbjA9DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9y ICdpZGVudGl0eScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMg cHJvYmxlbS4NCg0KbT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQRiAxMDkgMCA4DQpjPUlO IElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2 DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPXJ0cG1hcDowIFBDTVUvODAwMA0KYT1ydHBt YXA6OCBQQ01BLzgwMDANCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzowNzRjNjU1MA0KYT1p Y2UtcHdkOmEyOGEzOTdhNGMzZjMxNzQ3ZDFlZTM0NzRhZjA4YTA2OA0KYT1maW5nZXJwcmludDpz aGEtMjU2IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4OjczOjA0IA0K OkJCOjA1OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyDQoNCioqKiBF UlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmlu ZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RwYXNzDQph PXRscy1pZDoxDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiog Tm90ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4DQph PXJ0Y3A6NjAwNjUgSU4gSVA0IDIwMy4wLjExMy4xNDENCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6 MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoy IHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQ wqAgMjEyMjE5NDY4NyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZh bGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3Bh Y2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MSAxIFVEUMKgIDE2ODU5ODcw NzEgMjAzLjAuMTEzLjE0MSA1NDYwOSB0eXAgc3JmbHggcmFkZHIgDQoxOTIuMC4yLjQgcnBvcnQg NjE2NjUNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBO b3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5k aWRhdGU6MCAyIFVEUMKgIDIxMjIxOTQ2ODcgMTkyLjAuMi40IDYxNjY3IHR5cCBob3N0DQoNCioq KiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3Zp bmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMiBV RFDCoCAxNjg1OTg3MDcxIDIwMy4wLjExMy4xNDEgNjAwNjUgdHlwIHNyZmx4IHJhZGRyIA0KMTky LjAuMi40IHJwb3J0IDYxNjY3DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5k aWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2Js ZW0uDQoNCmE9ZW5kLW9mLWNhbmRpZGF0ZXMNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjIu MSBTRFAgQW5zd2VyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0twqAgMTY4MzMgMCBJ TiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgYXVkaW8NCmE9aWNlLW9w dGlvbnM6dHJpY2tsZQ0KYT1pZGVudGl0eTpldzBLSUNBaWFXUndJanA3RFFvZ0lDQWdJbVJ2YldG cGJpSTZJQ0pqYVhOamIzTndZWEpyTG1OdmJTSXNEUW9nSUNBZyANCkluQnliM1J2WTI5c0lqb2dJ bVJsWm1GMWJIUWlEUW9nSUgwc0RRb2dJQ0poYzNObGNuUnBiMjRpT2lBaWJFcDNXa1ZvY21GVk9Y QlRibEpvIA0KVjBVMWQxVlZZekZqUjBaWVYxaFdhRk5HVm5CYWJFVjFVMVJXVVdSSGFFdE9Sa1pF VkRBMVZFOUdWbGhrTWpWUFQxVm9NMDFGWkdGVVJHd3ogDQpaREJTUWxaSFVuSlVWM1JHVncwS0lD QWdJQ0FnSUNBZ0lDQWdJQ0JzYkcxa2JFNVdWRlJLTmxWdFpEVlNNRGxYVTBkbmVsSnRjRzVqTWta USANCldtdHNhMUp1Um5OT1ZYZzJZWHBDUm1KdVpGWlBWRTVSVDFWc1ExRXdlRnBQVjNScFlUTldN V013VmpGVE1qVlpVa2RXVGt4VVRrbE9EUW9nIA0KSUNBZ0lDQWdJQ0FnSUNBZ0lGZEdiV1JVU25a YWJEbERWR3hhYWxWdVFqTk5iV1JDWkd4T1FtSldValpUYkd4MFkwVndjVTFHUlhSa2JWWXcgDQpW RzEwVmxReGFIVmFSVGxJVEZWSmVsUXpXa2RpTTFGM1dsWk9SVTVzV2xOT1ZXUm9ZakozZVdNTkNp QWdJQ0FnSUNBZ0lDQWdJQ0FnUjJSMSANClV6TkdVMVJyZEU5a00yUmhZMFZhTVdWVldscGlSbEp2 WkVoS1NXUkhUbWxVTVRsWFZqTnZORkZ1V25CVVZHaExVekkxVDJSRmVGZGtNVXA0IA0KVGxWb1RW Z3lXa3hVYkZKRFRucEdSRmxyYjNsWGJXZzFWeUlOQ24wPQ0KDQoqKiogRVJST1I6IGludmFsaWQg c3ludGF4IGZvciAnaWRlbnRpdHknDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBm aXhlcyB0aGlzIHByb2JsZW0uDQoNCm09YXVkaW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTA5 IDAgOA0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQph PXNlbmRyZWN2DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPXJ0cG1hcDowIFBDTVUvODAw MA0KYT1ydHBtYXA6OCBQQ01BLzgwMDANCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzowNTA2 NzQyMw0KYT1pY2UtcHdkOjE3NDdkMWVlMzQ3NGEyOGEzOTdhNGMzZjNhZjA4YTA2OA0KYT1maW5n ZXJwcmludDpzaGEtMjU2IDZCOjhCOkYwOjY1OjVGOjc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2 OjFCOjM1IA0KOkRDOkI4OjVGOjY0OjFBOjI0OkMyOjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4 DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3Rl OiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDph Y3RpdmUNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1p ZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRj cC1tdXgNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4 dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0 OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQIDIxMjIxOTQ2ODcgMTk4LjUxLjEwMC43IDUx NTU2IHR5cCBob3N0DQphPWNhbmRpZGF0ZToxIDEgVURQIDE2ODU5ODcwNzEgMjAzLjAuMTEzLjc3 IDQ5MjAzIHR5cCBzcmZseCByYWRkciANCjE5OC41MS4xMDAuNyBycG9ydCA1MTU1Ng0KYT1lbmQt b2YtY2FuZGlkYXRlcw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMi4yLjEgU0RQIE9mZmVy DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDIwNTE4IDAgSU4gSVA0IDAuMC4wLjAN CnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIHZpZGVvDQphPWdyb3VwOkxTIGF1ZGlv IHZpZGVvDQphPWljZS1vcHRpb25zOnRyaWNrbGUNCm09YXVkaW8gNTQ2MDkgVURQL1RMUy9SVFAv U0FWUEYgMTA5IDAgOA0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6YXVkaW8NCmE9bXNp ZDptYSB0YQ0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1ydHBtYXA6 MCBQQ01VLzgwMDANCmE9cnRwbWFwOjggUENNQS84MDAwDQphPW1heHB0aW1lOjEyMA0KYT1pY2Ut dWZyYWc6MDc0YzY1NTANCmE9aWNlLXB3ZDphMjhhMzk3YTRjM2YzMTc0N2QxZWUzNDc0YWYwOGEw NjgNCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpG NDpBNTpBODpEODo3MzowNDogDQpCQjowNToyRjo3MDo5RjowNDpBOTowRTowNTpFOToyNjozMzpF ODo3MDo4ODpBMg0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQn DQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoN CmE9c2V0dXA6YWN0cGFzcw0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4 IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdl ci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLW11eC1vbmx5DQphPXJ0Y3AtcnNpemUNCmE9ZXh0bWFw OjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZlbA0KYT1leHRtYXA6 MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1jYW5kaWRhdGU6MCAxIFVE UMKgIDIxMjIxOTQ2ODcgMTkyLjAuMi40IDYxNjY1IHR5cCBob3N0DQoNCioqKiBFUlJPUjogaW52 YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNw YWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMSBVRFDCoCAxNjg1OTg3 MDcxIDIwMy4wLjExMy4xNDEgNTQ2MDkgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40IHJwb3J0 IDYxNjY1DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiog Tm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9ZW5k LW9mLWNhbmRpZGF0ZXMNCm09dmlkZW8gNTQ2MDkgVURQL1RMUy9SVFAvU0FWUEYgOTkgMTIwDQpj PUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDp2aWRlbw0KYT1tc2lkOm1hIHRiDQphPXNlbmRy ZWN2DQphPXJ0cG1hcDo5OSBIMjY0LzkwMDAwDQphPWZtdHA6OTkgcHJvZmlsZS1sZXZlbC1pZD00 ZDAwMjg7cGFja2V0aXphdGlvbi1tb2RlPTENCmE9cnRwbWFwOjEyMCBWUDgvOTAwMDANCmE9cnRj cC1mYjo5OSBuYWNrDQphPXJ0Y3AtZmI6OTkgbmFjayBwbGkNCmE9cnRjcC1mYjo5OSBjY20gZmly DQphPXJ0Y3AtZmI6MTIwIG5hY2sNCmE9cnRjcC1mYjoxMjAgbmFjayBwbGkNCmE9cnRjcC1mYjox MjAgY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1p ZA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMi4yLjEgU0RQIEFuc3dlcg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQp2PTANCm89LcKgIDE2ODMzIDAgSU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0w IDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIHZpZGVvDQphPWdyb3VwOkxTIGF1ZGlvIHZpZGVvDQph PWljZS1vcHRpb25zOnRyaWNrbGUNCm09YXVkaW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTA5 DQpjPUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9bWlkOmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9c2Vu ZHJlY3YNCmE9cnRwbWFwOjEwOSBvcHVzLzQ4MDAwLzINCmE9bWF4cHRpbWU6MTIwDQphPWljZS11 ZnJhZzpjMzAwZDg1Yg0KYT1pY2UtcHdkOmRlNGU5OWJkMjkxYzMyNTkyMWQ1ZDQ3ZWZiYWJkOWEy DQphPWZpbmdlcnByaW50OnNoYS0yNTYgNkI6OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6 RjM6M0Y6NDY6MUI6MzUgDQo6REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6 MkM6MTk6MDgNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0K KioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQph PXNldHVwOmFjdGl2ZQ0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZv ciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4N Cg0KYT1ydGNwLW11eA0KYT1ydGNwLW11eC1vbmx5DQphPXJ0Y3AtcnNpemUNCmE9ZXh0bWFwOjEg dXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZlbA0KYT1leHRtYXA6MiB1 cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1jYW5kaWRhdGU6MCAxIFVEUCAz NjE4MDk1NzgzIDE5OC41MS4xMDAuNyA0OTIwMyB0eXAgaG9zdA0KYT1jYW5kaWRhdGU6MSAxIFVE UCA1NjU2ODkyMDMgMjAzLjAuMTEzLjc3IDQ5MjAzIHR5cCBzcmZseCByYWRkciANCjE5OC41MS4x MDAuNyBycG9ydCA1MTU1Ng0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KbT12aWRlbyA0OTIwMyBVRFAv VExTL1JUUC9TQVZQRiA5OQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDp2aWRlbw0KYT1t c2lkOm1hIHRiDQphPXNlbmRyZWN2DQphPXJ0cG1hcDo5OSBIMjY0LzkwMDAwDQphPWZtdHA6OTkg cHJvZmlsZS1sZXZlbC1pZD00ZDAwMjg7cGFja2V0aXphdGlvbi1tb2RlPTENCmE9cnRjcC1mYjo5 OSBuYWNrDQphPXJ0Y3AtZmI6OTkgbmFjayBwbGkNCmE9cnRjcC1mYjo5OSBjY20gZmlyDQphPWV4 dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KNS4yLjIuMiBTRFAgT2ZmZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0w DQpvPS0gMjA1MTggMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUg YXVkaW8gdmlkZW8NCmE9Z3JvdXA6TFMgYXVkaW8gdmlkZW8NCmE9aWNlLW9wdGlvbnM6dHJpY2ts ZQ0KbT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQRiAxMDkgMCA4DQpjPUlOIElQNCAyMDMu MC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQphPXJ0cG1h cDoxMDkgb3B1cy80ODAwMC8yDQphPXJ0cG1hcDowIFBDTVUvODAwMA0KYT1ydHBtYXA6OCBQQ01B LzgwMDANCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzowNzRjNjU1MA0KYT1pY2UtcHdkOmEy OGEzOTdhNGMzZjMxNzQ3ZDFlZTM0NzRhZjA4YTA2OA0KYT1maW5nZXJwcmludDpzaGEtMjU2IDE5 OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4OjczOjA0OiANCkJCOjA1OjJG OjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyDQoNCioqKiBFUlJPUjogaW52 YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQg c3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RwYXNzDQphPXRscy1pZDox DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiogTm90ZTogdGxz LWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4DQphPXJ0Y3AtbXV4 LW9ubHkNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4 dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0 OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAgMjEyMjE5NDY4NyAxOTIuMC4yLjQgNjE2 NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScN CioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0K YT1jYW5kaWRhdGU6MCAxIFVEUMKgIDIxMjIxOTQ2ODcgMjAwMTpEQjg6ODEwMTozYTU1OjQ4NTg6 YTJhOToyMmZmOjk5YjkgDQo2MTY2NSB0eXAgaG9zdA0KDQoqKiogRVJST1I6IGludmFsaWQgc3lu dGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4 ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWVuZC1vZi1jYW5kaWRhdGVzDQptPXZpZGVvIDU0NjA5IFVE UC9UTFMvUlRQL1NBVlBGIDk5IDEyMA0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6dmlk ZW8NCmE9bXNpZDptYSB0Yg0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6OTkgSDI2NC85MDAwMA0KYT1m bXRwOjk5IHByb2ZpbGUtbGV2ZWwtaWQ9NGQwMDI4O3BhY2tldGl6YXRpb24tbW9kZT0xDQphPXJ0 cG1hcDoxMjAgVlA4LzkwMDAwDQphPXJ0Y3AtZmI6OTkgbmFjaw0KYT1ydGNwLWZiOjk5IG5hY2sg cGxpDQphPXJ0Y3AtZmI6OTkgY2NtIGZpcg0KYT1ydGNwLWZiOjEyMCBuYWNrDQphPXJ0Y3AtZmI6 MTIwIG5hY2sgcGxpDQphPXJ0Y3AtZmI6MTIwIGNjbSBmaXINCmE9ZXh0bWFwOjIgdXJuOmlldGY6 cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjIu Mi4yIFNEUCBBbnN3ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS3CoCAxNjgzMyAw IElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBhdWRpbyB2aWRlbw0K YT1ncm91cDpMUyBhdWRpbyB2aWRlbw0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDQ5 MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDph dWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8y DQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6YzMwMGQ4NWINCmE9aWNlLXB3ZDpkZTRlOTli ZDI5MWMzMjU5MjFkNWQ0N2VmYmFiZDlhMg0KYT1maW5nZXJwcmludDpzaGEtMjU2IDZCOjhCOkYw OjY1OjVGOjc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2OjFCOjM1IA0KOkRDOkI4OjVGOjY0OjFB OjI0OkMyOjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4DQoNCioqKiBFUlJPUjogaW52YWxpZCBz eW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2Vz IGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RpdmUNCmE9dGxzLWlkOjENCg0KKioq IEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVz dCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1tdXgtb25seQ0K YT1ydGNwLXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMt YXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2Rlczpt aWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMzYxODA5NTc4MyAxOTguNTEuMTAwLjcgNDkyMDMgdHlw IGhvc3QNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMzYxODA5NTc4MyAyMDAxOkRCODozMGM6MTI2Njo1 OTE2OjM3Nzk6MjJmNjo3N2Y3IA0KNDkyMDMgdHlwIGhvc3QNCmE9ZW5kLW9mLWNhbmRpZGF0ZXMN Cm09dmlkZW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgOTkNCmM9SU4gSVA0IDIwMy4wLjExMy43 Nw0KYT1taWQ6dmlkZW8NCmE9bXNpZDptYSB0Yg0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6OTkgSDI2 NC85MDAwMA0KYT1mbXRwOjk5IHByb2ZpbGUtbGV2ZWwtaWQ9NGQwMDI4O3BhY2tldGl6YXRpb24t bW9kZT0xDQphPXJ0Y3AtZmI6OTkgbmFjaw0KYT1ydGNwLWZiOjk5IG5hY2sgcGxpDQphPXJ0Y3At ZmI6OTkgY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVz Om1pZA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMi4zIFNEUCBPZmZlcg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOCAwIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAw DQphPWdyb3VwOkJVTkRMRSBkYXRhDQphPWljZS1vcHRpb25zOnRyaWNrbGUNCm09YXBwbGljYXRp b24gNTQ2MDkgVURQL0RUTFMvU0NUUCB3ZWJydGMtZGF0YWNoYW5uZWwNCmM9SU4gSVA0IDIwMy4w LjExMy4xNDENCmE9bWlkOmRhdGENCmE9c2VuZHJlY3YNCmE9c2N0cC1wb3J0OjUwMDANCmE9bWF4 LW1lc3NhZ2Utc2l6ZToxMDAwMDANCmE9c2V0dXA6YWN0cGFzcw0KYT10bHMtaWQ6MQ0KDQoqKiog RVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0 IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1pY2UtdWZyYWc6MDc0YzY1NTANCmE9aWNlLXB3 ZDphMjhhMzk3YTRjM2YzMTc0N2QxZWUzNDc0YWYwOGEwNjgNCmE9ZmluZ2VycHJpbnQ6c2hhLTI1 NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpGNDpBNTpBODpEODo3MzowNCANCjpCQjow NToyRjo3MDo5RjowNDpBOTowRTowNTpFOToyNjozMzpFODo3MDo4ODpBMg0KDQoqKiogRVJST1I6 IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJy YW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjEx MzY2NzMyNyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFAgMTY5 NDMwMjIwNyAyMDMuMC4xMTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciANCjE5Mi4wLjIuNCBy cG9ydCA2MTY2NQ0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CjUuMi4zIFNEUCBBbnN3ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS3CoCAxNjgz MyAwIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBkYXRhDQptPWFw cGxpY2F0aW9uIDQ5MjAzIFVEUC9EVExTL1NDVFAgd2VicnRjLWRhdGFjaGFubmVsDQpjPUlOIElQ NCAyMDMuMC4xMTMuNzcNCmE9bWlkOmRhdGENCmE9c2VuZHJlY3YNCmE9c2N0cC1wb3J0OjUwMDAN CmE9bWF4LW1lc3NhZ2Utc2l6ZToxMDAwMDANCmE9c2V0dXA6YWN0aXZlDQphPXRscy1pZDoxDQoN CioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiogTm90ZTogdGxzLWlk IG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPWljZS11ZnJhZzpjMzAwZDg1Yg0KYT1p Y2UtcHdkOmRlNGU5OWJkMjkxYzMyNTkyMWQ1ZDQ3ZWZiYWJkOWEyDQphPWZpbmdlcnByaW50OnNo YS0yNTYgNkI6OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6 REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5n IGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZTowIDEgVURQ IDIxMTM2NjczMjcgMTk4LjUxLjEwMC43IDUxNTU2IHR5cCBob3N0DQphPWNhbmRpZGF0ZToxIDEg VURQIDE2OTQzMDIyMDcgMjAzLjAuMTEzLjc3IDQ5MjAzIHR5cCBzcmZseCByYWRkciANCjE5OC41 MS4xMDAuNyBycG9ydCA1MTU1Ng0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCjUuMi40IFNEUCBPZmZlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89 LSAyMDUxOCAwIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBhdWRp bw0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9UTFMvUlRQL1NBVlBG IDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6YXVkaW8NCmE9bXNpZDptYSB0YQ0K YT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjANCmE9 aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3NGFm MDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6Qjg6 NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6 MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnBy aW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVt Lg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5 bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBs b25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1tdXgtb25seQ0KYT1ydGNwLXJzaXplDQphPWV4 dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9ZXh0 bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRlOjAg MSBVRFDCoCAyMTEzNjY3MzI3IDE5Mi4wLjIuNCA2MTY2NSB0eXAgaG9zdA0KDQoqKiogRVJST1I6 IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFu dCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZToxIDEgVURQwqAgMTY4 NTk4NzA3MSAyMDMuMC4xMTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciANCjE5Mi4wLjIuNCBy cG9ydCA2MTY2NQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0K KioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQph PWVuZC1vZi1jYW5kaWRhdGVzDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS4yLjQgU0RQIEFu c3dlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LcKgIDE2ODMzIDAgSU4gSVA0IDAu MC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvDQptPWF1ZGlvIDQ5MjAzIFVE UC9UTFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDphdWRpbw0K YT1tc2lkOm1hIHRhDQphPWluYWN0aXZlDQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPW1h eHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6YzMwMGQ4NWINCmE9aWNlLXB3ZDpkZTRlOTliZDI5MWMz MjU5MjFkNWQ0N2VmYmFiZDlhMg0KYT1maW5nZXJwcmludDpzaGEtMjU2IDZCOjhCOkYwOjY1OjVG Ojc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2OjFCOjM1IA0KOkRDOkI4OjVGOjY0OjFBOjI0OkMy OjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXgg Zm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVz IHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RpdmUNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9S OiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAy MCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1tdXgtb25seQ0KYT1ydGNw LXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8t bGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9 Y2FuZGlkYXRlOjAgMSBVRFDCoCAyMTEzNjY3MzI3IDE5OC41MS4xMDAuNyA1MTU1NiB0eXAgaG9z dA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6 IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0 ZToxIDEgVURQwqAgMTY4NTk4NzA3MSAyMDMuMC4xMTMuMTQxIDQ5MjAzIHR5cCBzcmZseCByYWRk ciANCjE5OC41MS4xMDAuNyBycG9ydCA1MTU1Ng0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4 IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMg dGhpcyBwcm9ibGVtLg0KDQphPWVuZC1vZi1jYW5kaWRhdGVzDQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KNS4yLjUgU0RQIE9mZmVyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDIw NTE4IDAgSU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIGR0 bWYNCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQ RiAxMDkgMCA4DQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lkOm1h IHRhDQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPXJ0cG1hcDowIFBD TVUvODAwMA0KYT1ydHBtYXA6OCBQQ01BLzgwMDANCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJh ZzowNzRjNjU1MA0KYT1pY2UtcHdkOmEyOGEzOTdhNGMzZjMxNzQ3ZDFlZTM0NzRhZjA4YTA2OA0K YT1maW5nZXJwcmludDpzaGEtMjU2IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1 OkE4OkQ4OjczOjA0IA0KOkJCOjA1OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4Ojcw Ojg4OkEyDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioq KiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1z ZXR1cDphY3RwYXNzDQphPXRscy1pZDoxDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9y ICd0bHMtaWQnDQoqKiogTm90ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0K DQphPXJ0Y3AtbXV4DQphPXJ0Y3AtbXV4LW9ubHkNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1 cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVy bjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAg MjEyMjE5NDY4NyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlk IHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2Vz IGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MSAxIFVEUMKgIDE2ODU5ODcwNzEg MjAzLjAuMTEzLjE0MSA1NDYwOSB0eXAgc3JmbHggcmFkZHIgDQoxOTIuMC4yLjQgcnBvcnQgNjE2 NjUNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3Rl OiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1lbmQtb2Yt Y2FuZGlkYXRlcw0KbT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQRiAxMjYNCmM9SU4gSVA0 IDIwMy4wLjExMy4xNDENCmE9bWlkOmR0bWYNCmE9bXNpZDptYSB0Yg0KYT1zZW5kb25seQ0KYT1y dHBtYXA6MTI2IHRlbGVwaG9uZS1ldmVudC84MDAwDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFt czpydHAtaGRyZXh0OnNkZXM6bWlkDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS4yLjUgU0RQ IEFuc3dlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LcKgIDE2ODMzIDAgSU4gSVA0 IDAuMC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIGR0bWYNCm09YXVkaW8g NDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTA5DQpjPUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9bWlk OmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9c2VuZHJlY3YNCmE9cnRwbWFwOjEwOSBvcHVzLzQ4MDAw LzINCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzpjMzAwZDg1Yg0KYT1pY2UtcHdkOmRlNGU5 OWJkMjkxYzMyNTkyMWQ1ZDQ3ZWZiYWJkOWEyDQphPWZpbmdlcnByaW50OnNoYS0yNTYgNkI6OEI6 RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6REM6Qjg6NUY6NjQ6 MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVSUk9SOiBpbnZhbGlk IHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFj ZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdGl2ZQ0KYT10bHMtaWQ6MQ0KDQoq KiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBt dXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLW11eC1vbmx5 DQphPXJ0Y3AtcnNpemUNCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3Ny Yy1hdWRpby1sZXZlbA0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVz Om1pZA0KYT1jYW5kaWRhdGU6MCAxIFVEUCAyMTIyMTk0Njg3IDE5OC41MS4xMDAuNyA1MTU1NiB0 eXAgaG9zdA0KYT1jYW5kaWRhdGU6MSAxIFVEUCAxNjg1OTg3MDcxIDIwMy4wLjExMy43NyA0OTIw MyB0eXAgc3JmbHggcmFkZHIgDQoxOTguNTEuMTAwLjcgcnBvcnQgNTE1NTYNCmE9ZW5kLW9mLWNh bmRpZGF0ZXMNCm09YXVkaW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTI2DQpjPUlOIElQNCAy MDMuMC4xMTMuNzcNCmE9bWlkOmR0bWYNCmE9bXNpZDptYSB0Yg0KYT1yZWN2b25seQ0KYT1ydHBt YXA6MTI2IHRlbGVwaG9uZS1ldmVudC84MDAwDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpy dHAtaGRyZXh0OnNkZXM6bWlkDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS4yLjYgU0RQIE9m ZmVyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDIwNTE5IDAgSU4gSVA0IDAuMC4w LjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIHZpZGVvDQphPWdyb3VwOkxTIGF1 ZGlvIHZpZGVvDQphPWljZS1vcHRpb25zOnRyaWNrbGUNCm09YXVkaW8gNTQ2MDkgVURQL1RMUy9S VFAvU0FWUEYgMTA5DQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lk Om1hIHRhDQphPXNlbmRvbmx5DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPW1heHB0aW1l OjEyMA0KYT1pY2UtdWZyYWc6MDc0YzY1NTANCmE9aWNlLXB3ZDphMjhhMzk3YTRjM2YzMTc0N2Qx ZWUzNDc0YWYwOGEwNjgNCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4 MTpFNjpCODo1QzpGNDpBNTpBODpEODo3MzowNCANCjpCQjowNToyRjo3MDo5RjowNDpBOTowRTow NTpFOToyNjozMzpFODo3MDo4ODpBMg0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAn ZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlz IHByb2JsZW0uDQoNCmE9c2V0dXA6YWN0cGFzcw0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGlu dmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNo YXJzIG9yIGxvbmdlci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLW11eC1vbmx5DQphPXJ0Y3AtcnNp emUNCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZl bA0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1jYW5k aWRhdGU6MCAxIFVEUMKgIDIxMjIxOTQ2ODcgMjAzLjAuMTEzLjE0MSA1NDYwOSB0eXAgaG9zdA0K DQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJl bW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWVuZC1vZi1jYW5k aWRhdGVzDQptPXZpZGVvIDU0NjA5IFVEUC9UTFMvUlRQL1NBVlBGIDEyMA0KYz1JTiBJUDQgMjAz LjAuMTEzLjE0MQ0KYT1taWQ6dmlkZW8NCmE9bXNpZDptYSB0Yg0KYT1zZW5kb25seQ0KYT1ydHBt YXA6MTIwIFZQOC85MDAwMA0KYT1jb250ZW50OnNsaWRlcw0KYT1ydGNwLWZiOjEyMCBuYWNrDQph PXJ0Y3AtZmI6MTIwIG5hY2sgcGxpDQphPXJ0Y3AtZmI6MTIwIGNjbSBmaXINCmE9ZXh0bWFwOjIg dXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo1LjIuNiBTRFAgQW5zd2VyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDE2 ODMzIDAgSU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIHZp ZGVvDQphPWdyb3VwOkxTIGF1ZGlvIHZpZGVvDQphPWljZS1vcHRpb25zOnRyaWNrbGUNCm09YXVk aW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTA5DQpjPUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9 bWlkOmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9cmVjdm9ubHkNCmE9cnRwbWFwOjEwOSBvcHVzLzQ4 MDAwLzINCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzpjMzAwZDg1Yg0KYT1pY2UtcHdkOmRl NGU5OWJkMjkxYzMyNTkyMWQ1ZDQ3ZWZiYWJkOWEyDQphPWZpbmdlcnByaW50OnNoYS0yNTYgNkI6 OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6REM6Qjg6NUY6 NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVSUk9SOiBpbnZh bGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBz cGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdGl2ZQ0KYT10bHMtaWQ6MQ0K DQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1p ZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLW11eC1v bmx5DQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2 ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9Y2Fu ZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNyAyMDMuMC4xMTMuNzcgNDkyMDMgdHlwIGhvc3QNCmE9 ZW5kLW9mLWNhbmRpZGF0ZXMNCm09dmlkZW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTIwDQpj PUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9bWlkOnZpZGVvDQphPW1zaWQ6bWEgdGINCmE9cmVjdm9u bHkNCmE9cnRwbWFwOjEyMCBWUDgvOTAwMDANCmE9Y29udGVudDpzbGlkZXMNCmE9cnRjcC1mYjox MjAgbmFjaw0KYT1ydGNwLWZiOjEyMCBuYWNrIHBsaQ0KYT1ydGNwLWZiOjEyMCBjY20gZmlyDQph PWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KNS4yLjcgU0RQIE9mZmVyIHcvQlVORExFDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCnY9MA0Kbz0tIDIwNTE4IDAgSU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0wIDANCmE9Z3Jv dXA6QlVORExFIGF1ZGlvIHZpZGVvDQphPWdyb3VwOkxTIGF1ZGlvIHZpZGVvDQphPWljZS1vcHRp b25zOnRyaWNrbGUNCm09YXVkaW8gNTQ2MDkgVURQL1RMUy9SVFAvU0FWUEYgMTA5DQpjPUlOIElQ NCAyMDMuMC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQph PXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6MDc0 YzY1NTANCmE9aWNlLXB3ZDphMjhhMzk3YTRjM2YzMTc0N2QxZWUzNDc0YWYwOGEwNjgNCmE9Zmlu Z2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpGNDpBNTpBODpE ODo3MzowNCANCjpCQjowNToyRjo3MDo5RjowNDpBOTowRTowNTpFOToyNjozMzpFODo3MDo4ODpB Mg0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoqKiogTm90 ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9c2V0dXA6 YWN0cGFzcw0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxz LWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1y dGNwLW11eA0KYT1ydGNwOjU0NjEwIElOIElQNCAyMDMuMC4xMTMuMTQxDQphPXJ0Y3AtcnNpemUN CmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZlbA0K YT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1jYW5kaWRh dGU6MCAxIFVEUMKgIDIxMjIxOTQ2ODcgMTkyLjAuMi40IDYxNjY1IHR5cCBob3N0DQoNCioqKiBF UlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3Zpbmcg ZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMSBVRFDC oCAxNjg1OTg3MDcxIDIwMy4wLjExMy4xNDEgNTQ2MDkgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAu Mi40IHJwb3J0IDYxNjY1DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRh dGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0u DQoNCmE9Y2FuZGlkYXRlOjAgMiBVRFAgMjEyMjE5NDY4NyAxOTIuMC4yLjQgNjE2NjYgdHlwIGhv c3QNCmE9Y2FuZGlkYXRlOjEgMiBVRFDCoCAxNjg1OTg3MDcxIDIwMy4wLjExMy4xNDEgNTQ2MTAg dHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40IHJwb3J0IDYxNjY2DQoNCioqKiBFUlJPUjogaW52 YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNw YWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCm09dmlkZW8gNjI1MzcgVURQL1RMUy9SVFAvU0FW UEYgMTIwDQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDp2aWRlbw0KYT1tc2lkOm1hIHRi DQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMjAgVlA4LzkwMDAwDQphPWljZS11ZnJhZzo2NTUwMDc0 Yw0KYT1pY2UtcHdkOjc0YWYwOGEwNjhhMjhhMzk3YTRjM2YzMTc0N2QxZWUzNA0KYT1maW5nZXJw cmludDpzaGEtMjU2IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4Ojcz OjA0IA0KOkJCOjA1OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyDQoN CioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBS ZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3Rw YXNzDQphPXRscy1pZDoyDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQn DQoqKiogTm90ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3At bXV4DQphPXJ0Y3A6NjI1MzggSU4gSVA0IDIwMy4wLjExMy4xNDENCmE9cnRjcC1yc2l6ZQ0KYT1y dGNwLWZiOjEyMCBuYWNrDQphPXJ0Y3AtZmI6MTIwIG5hY2sgcGxpDQphPXJ0Y3AtZmI6MTIwIGNj bSBmaXINCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9 Y2FuZGlkYXRlOjAgMSBVRFDCoCAyMTIyMTk0Njg3IDE5Mi4wLjIuNCA2MTg4NiB0eXAgaG9zdA0K DQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJl bW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZTox IDEgVURQwqAgMTY4NTk4NzA3MSAyMDMuMC4xMTMuMTQxIDYyNTM3IHR5cCBzcmZseCByYWRkciAN CjE5Mi4wLjIuNCBycG9ydCA2MTg4Ng0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAn Y2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBw cm9ibGVtLg0KDQphPWNhbmRpZGF0ZTowIDIgMjEyMjE5NDY4NyAxOTIuMC4yLjQgNjE4ODggdHlw IGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBO b3RlOiBBZGRpbmcgJ1VEUCcgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZToxIDIg VURQIDE2ODU5ODcwNzEgMjAzLjAuMTEzLjE0MSA2MjUzOCB0eXAgc3JmbHggcmFkZHIgDQoxOTIu MC4yLjQgcnBvcnQgNjE4ODgNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjIuOCBTRFAgT2Zm ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS0gMjA1MTggMCBJTiBJUDQgMC4wLjAu MA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgYXVkaW8gdmlkZW8gZGF0YQ0KYT1ncm91cDpM UyBhdWRpbyB2aWRlbw0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9U TFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1tc2lkOm1hIHRhDQph PW1pZDphdWRpbw0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhw dGltZToxMjANCmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3 NDdkMWVlMzQ3NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6 OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6 MEU6MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBm b3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMg dGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9S OiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAy MCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1tdXgtb25seQ0KYT1ydGNw LXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8t bGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9 Y2FuZGlkYXRlOjAgMSBVRFDCoCAyMTIyMTk0Njg3IDE5Mi4wLjIuNCA2MTY2NSB0eXAgaG9zdA0K DQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJl bW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZTox IDEgVURQwqAgMTY4NTk4NzA3MSAyMDMuMC4xMTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciAN CjE5Mi4wLjIuNCBycG9ydCA2MTY2NQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAn Y2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBw cm9ibGVtLg0KDQphPWVuZC1vZi1jYW5kaWRhdGVzDQptPXZpZGVvIDU0NjA5IFVEUC9UTFMvUlRQ L1NBVlBGIDEyMA0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6dmlkZW8NCmE9bXNpZDpt YSB0Yg0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTIwIFZQOC85MDAwMA0KYT1ydGNwLWZiOjEyMCBu YWNrDQphPXJ0Y3AtZmI6MTIwIG5hY2sgcGxpDQphPXJ0Y3AtZmI6MTIwIGNjbSBmaXINCmE9ZXh0 bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCm09YXBwbGljYXRpb24g NTQ2MDkgVURQL0RUTFMvU0NUUCB3ZWJydGMtZGF0YWNoYW5uZWwNCmM9SU4gSVA0IDIwMy4wLjEx My4xNDENCmE9bWlkOmRhdGENCmE9c2N0cC1wb3J0OjUwMDANCmE9bWF4LW1lc3NhZ2Utc2l6ZTox MDAwMDANCmE9c2VuZHJlY3YNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjIuOCBTRFAgQW5z d2VyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDE2ODMzIDAgSU4gSVA0IDAuMC4w LjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvIHZpZGVvIGRhdGENCmE9Z3JvdXA6 TFMgYXVkaW8gdmlkZW8NCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA0OTIwMyBVRFAv VExTL1JUUC9TQVZQRiAxMDkNCmM9SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1tc2lkOm1hIHRhDQph PW1pZDphdWRpbw0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhw dGltZToxMjANCmE9aWNlLXVmcmFnOmMzMDBkODViDQphPWljZS1wd2Q6ZGU0ZTk5YmQyOTFjMzI1 OTIxZDVkNDdlZmJhYmQ5YTINCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiA2Qjo4QjpGMDo2NTo1Rjo3 ODpFMjo1MTozQjpBQzo2RjpGMzozRjo0NjoxQjozNSANCjpEQzpCODo1Rjo2NDoxQToyNDpDMjo0 MzpGMDpBMTo1ODpEMDpBMToyQzoxOTowOA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZv ciAnZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0 aGlzIHByb2JsZW0uDQoNCmE9c2V0dXA6YWN0aXZlDQphPXRscy1pZDoxDQoNCioqKiBFUlJPUjog aW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiogTm90ZTogdGxzLWlkIG11c3QgYmUgMjAg Y2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4DQphPXJ0Y3AtbXV4LW9ubHkNCmE9cnRjcC1y c2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxl dmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNh bmRpZGF0ZTowIDEgVURQIDIxMjIxOTQ2ODcgMTk4LjUxLjEwMC43IDUxNTU2IHR5cCBob3N0DQph PWNhbmRpZGF0ZToxIDEgVURQIDE2ODU5ODcwNzEgMjAzLjAuMTEzLjc3IDQ5MjAzIHR5cCBzcmZs eCByYWRkciANCjE5OC41MS4xMDAuNyBycG9ydCA1MTU1Ng0KYT1lbmQtb2YtY2FuZGlkYXRlcw0K bT12aWRlbyA0OTIwMyBVRFAvVExTL1JUUC9TQVZQRiAxMjANCmM9SU4gSVA0IDIwMy4wLjExMy43 Nw0KYT1taWQ6dmlkZW8NCmE9bXNpZDptYSB0Yg0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTIwIFZQ OC85MDAwMA0KYT1ydGNwLWZiOjEyMCBuYWNrDQphPXJ0Y3AtZmI6MTIwIG5hY2sgcGxpDQphPXJ0 Y3AtZmI6MTIwIGNjbSBmaXINCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6 c2RlczptaWQNCm09YXBwbGljYXRpb24gNDkyMDMgVURQL0RUTFMvU0NUUCB3ZWJydGMtZGF0YWNo YW5uZWwNCmM9SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6ZGF0YQ0KYT1zY3RwLXBvcnQ6NTAw MA0KYT1tYXgtbWVzc2FnZS1zaXplOjEwMDAwMA0KYT1zZW5kcmVjdg0KDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCjUuMi4xMCBTRFAgT2ZmZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpv PS0gMjA1MTggMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgYXVk aW8gdmlkZW8NCmE9Z3JvdXA6TFMgYXVkaW8gdmlkZW8NCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0K bT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQRiAxMDkNCmM9SU4gSVA0IDIwMy4wLjExMy4x NDENCmE9bWlkOmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9c2VuZHJlY3YNCmE9cnRwbWFwOjEwOSBv cHVzLzQ4MDAwLzINCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzowNzRjNjU1MA0KYT1pY2Ut cHdkOmEyOGEzOTdhNGMzZjMxNzQ3ZDFlZTM0NzRhZjA4YTA2OA0KYT1maW5nZXJwcmludDpzaGEt MjU2IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4OjczOjA0IA0KOkJC OjA1OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyDQoNCioqKiBFUlJP UjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBl cnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RwYXNzDQphPXRs cy1pZDoxDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiogTm90 ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4DQphPXJ0 Y3AtbXV4LW9ubHkNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRw LWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAt aGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAgMjExMzY2NzMyNyAxOTIuMC4y LjQgNTQ2MDkgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRp ZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxl bS4NCg0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KbT12aWRlbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQ RiAxMjANCmM9SU4gSVA0IDIwMy4wLjExMy4xNDENCmE9bWlkOnZpZGVvDQphPW1zaWQ6bWEgdGIN CmE9c2VuZHJlY3YNCmE9cnRwbWFwOjEyMCBWUDgvOTAwMDANCmE9cnRjcC1mYjoxMjAgbmFjaw0K YT1ydGNwLWZiOjEyMCBuYWNrIHBsaQ0KYT1ydGNwLWZiOjEyMCBjY20gZmlyDQphPWV4dG1hcDoy IHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQptPWFwcGxpY2F0aW9uIDEwMDAw IFVEUC9EVExTL1NDVFAgd2VicnRjLWRhdGFjaGFubmVsDQpjPUlOIElQNCAyMDMuMC4xMTMuMTQx DQphPW1pZDpkYXRhDQphPXNjdHAtcG9ydDo1MDAwDQphPW1heC1tZXNzYWdlLXNpemU6MTAwMDAw DQphPXNlbmRyZWN2DQphPXNldHVwOmFjdHBhc3MNCmE9aWNlLXVmcmFnOjg5ODE5MDEzDQphPWlj ZS1wd2Q6MTc0N2QxZWUzNDc0YWYwOGEwNjhhMjhhMzk3YTRjM2YzDQphPWZpbmdlcnByaW50OnNo YS0yNTYgMjk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQ6IA0K QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5n IGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZTowIDEgVURQ wqAgMjExMzY2NzMyNyAxOTIuMC4yLjQgMTAwMDAgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZh bGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3Bh Y2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCjUuMi4xMCBTRFAgQW5zd2VyDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CnY9MA0Kbz0twqAgMTY4MzMgMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpC VU5ETEUgYXVkaW8gdmlkZW8NCmE9Z3JvdXA6TFMgYXVkaW8gdmlkZW8NCmE9aWNlLW9wdGlvbnM6 dHJpY2tsZQ0KbT1hdWRpbyA0OTIwMyBVRFAvVExTL1JUUC9TQVZQRiAxMDkNCmM9SU4gSVA0IDIw My4wLjExMy43Nw0KYT1taWQ6YXVkaW8NCmE9bXNpZDptYSB0YQ0KYT1zZW5kcmVjdg0KYT1ydHBt YXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjANCmE9aWNlLXVmcmFnOmMzMDBkODVi DQphPWljZS1wd2Q6ZGU0ZTk5YmQyOTFjMzI1OTIxZDVkNDdlZmJhYmQ5YTINCmE9ZmluZ2VycHJp bnQ6c2hhLTI1NiA2Qjo4QjpGMDo2NTo1Rjo3ODpFMjo1MTozQjpBQzo2RjpGMzozRjo0NjoxQjoz NSANCjpEQzpCODo1Rjo2NDoxQToyNDpDMjo0MzpGMDpBMTo1ODpEMDpBMToyQzoxOTowOA0KDQoq KiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVt b3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9c2V0dXA6YWN0aXZl DQphPXRscy1pZDoxDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoq KiogTm90ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4 DQphPXJ0Y3AtbXV4LW9ubHkNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJh bXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFt czpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQIDIxMTM2NjczMjcgMTk4 LjUxLjEwMC43IDQ5MjAzIHR5cCBob3N0DQphPWVuZC1vZi1jYW5kaWRhdGVzDQptPXZpZGVvIDQ5 MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEyMA0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDp2 aWRlbw0KYT1tc2lkOm1hIHRiDQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMjAgVlA4LzkwMDAwDQph PXJ0Y3AtZmI6MTIwIG5hY2sNCmE9cnRjcC1mYjoxMjAgbmFjayBwbGkNCmE9cnRjcC1mYjoxMjAg Y2NtIGZpcg0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0K bT1hcHBsaWNhdGlvbiAyMDAwMCBVRFAvRFRMUy9TQ1RQIHdlYnJ0Yy1kYXRhY2hhbm5lbA0KYz1J TiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDpkYXRhDQphPXNjdHAtcG9ydDo1MDAwDQphPW1heC1t ZXNzYWdlLXNpemU6MTAwMDAwDQphPXNldHVwOmFjdGl2ZQ0KYT1zZW5kcmVjdg0KYT1pY2UtdWZy YWc6OTkxQ2EyYTVlDQphPWljZS1wd2Q6OTIxZDVkNDdlZmJhYmQ5YTJkZTRlOTliZDI5MWMzMjUN CmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiA3Qjo4QjpGMDo2NTo1Rjo3ODpFMjo1MTozQjpBQzo2RjpG MzozRjo0NjoxQjozNTogDQpEQzpCODo1Rjo2NDoxQToyNDpDMjo0MzpGMDpBMTo1ODpEMDpBMToy QzoxOTowOA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoq KiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9 Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNyAxOTguNTEuMTAwLjcgMjAwMDAgdHlwIGhvc3QN CmE9ZW5kLW9mLWNhbmRpZGF0ZXMNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjIuMTEgU0RQ IE9mZmVyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDIwNTE4IDAgSU4gSVA0IDAu MC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvDQphPWljZS1vcHRpb25zOnRy aWNrbGUNCm09YXVkaW8gNTQ2MDkgVURQL1RMUy9SVFAvU0FWUEYgMTA5DQpjPUlOIElQNCAyMDMu MC4xMTMuMTQxDQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQphPXJ0cG1h cDoxMDkgb3B1cy80ODAwMC8yDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6MDc0YzY1NTAN CmE9aWNlLXB3ZDphMjhhMzk3YTRjM2YzMTc0N2QxZWUzNDc0YWYwOGEwNjgNCmE9ZmluZ2VycHJp bnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpGNDpBNTpBODpEODo3Mzow NCANCjpCQjowNToyRjo3MDo5RjowNDpBOTowRTowNTpFOToyNjozMzpFODo3MDo4ODpBMg0KDQoq KiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVt b3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9c2V0dXA6YWN0cGFz cw0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0K KioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1ydGNwLW11 eA0KYT1ydGNwLW11eC1vbmx5DQphPXJ0Y3AtcnNpemUNCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFy YW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1sZXZlbA0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJh bXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1jYW5kaWRhdGU6MCAxIFVEUMKgIDIxMTM2NjczMjcg MTkyLjAuMi40IDYxNjY1IHR5cCBob3N0DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9y ICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlz IHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMSBVRFDCoCA2OTQzMDIyMDcgMjAzLjAuMTEzLjE0 MSA1NDYwOSB0eXAgc3JmbHggcmFkZHIgDQoxOTIuMC4yLjQgcnBvcnQgNjE2NjUNCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBl cnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1lbmQtb2YtY2FuZGlkYXRlcw0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMi4xMCBTRFAgQW5zd2VyDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCnY9MA0Kbz0twqAgMTY4MzMgMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0K YT1ncm91cDpCVU5ETEUgYXVkaW8NCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA0OTIw MyBVRFAvVExTL1JUUC9TQVZQRiAxMDkNCmM9SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6YXVk aW8NCmE9bXNpZDptYSB0YQ0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0K YT1tYXhwdGltZToxMjANCmE9aWNlLXVmcmFnOmMzMDBkODViDQphPWljZS1wd2Q6ZGU0ZTk5YmQy OTFjMzI1OTIxZDVkNDdlZmJhYmQ5YTINCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiA2Qjo4QjpGMDo2 NTo1Rjo3ODpFMjo1MTozQjpBQzo2RjpGMzozRjo0NjoxQjozNSANCjpEQzpCODo1Rjo2NDoxQToy NDpDMjo0MzpGMDpBMTo1ODpEMDpBMToyQzoxOTowOA0KDQoqKiogRVJST1I6IGludmFsaWQgc3lu dGF4IGZvciAnZmluZ2VycHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBm aXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9c2V0dXA6YWN0aXZlDQphPXRscy1pZDoxDQoNCioqKiBF UlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQnDQoqKiogTm90ZTogdGxzLWlkIG11c3Qg YmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3AtbXV4DQphPXJ0Y3AtbXV4LW9ubHkNCmE9 cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1 ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlk DQphPWNhbmRpZGF0ZTowIDEgVURQIDIxMTM2NjczMjcgMTk4LjUxLjEwMC43IDUxNTU2IHR5cCBo b3N0DQphPWNhbmRpZGF0ZToxIDEgVURQIDE2OTQzMDIyMDcgMjAzLjAuMTEzLjc3IDQ5MjAzIHR5 cCBzcmZseCByYWRkciANCjE5OC41MS4xMDAuNyBycG9ydCA1MTU1Ng0KYT1lbmQtb2YtY2FuZGlk YXRlcw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMi4xMSBTRFAgVXBkYXRlZCBPZmZlcg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOCAxIElOIElQNCAwLjAuMC4wDQpz PS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBhdWRpbyB2aWRlbw0KYT1ncm91cDpMUyBhdWRpbyB2 aWRlbw0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9UTFMvUlRQL1NB VlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6YXVkaW8NCmE9bXNpZDptYSB0 YQ0KYT1zZW5kcmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjAN CmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3 NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6 Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6 MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2Zpbmdl cnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9i bGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlk IHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBv ciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1tdXgtb25seQ0KYT1ydGNwLXJzaXplDQph PWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9 ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRl OjAgMSBVRFDCoCAyMTEzNjY3MzI3IDE5Mi4wLjIuNCA2MTY2NSB0eXAgaG9zdA0KDQoqKiogRVJS T1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVy cmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZToxIDEgVURQwqAg Njk0MzAyMjA3IDIwMy4wLjExMy4xNDEgNTQ2MDkgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40 IHJwb3J0IDYxNjY1DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUn DQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoN CmE9ZW5kLW9mLWNhbmRpZGF0ZXMNCm09dmlkZW8gNTQ2MDkgVURQL1RMUy9SVFAvU0FWUEYgMTIw DQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPW1pZDp2aWRlbw0KYT1tc2lkOm1hIHRiDQphPXNl bmRyZWN2DQphPXJ0cG1hcDoxMjAgVlA4LzkwMDAwDQphPXJ0Y3AtZmI6MTIwIG5hY2sNCmE9cnRj cC1mYjoxMjAgbmFjayBwbGkNCmE9cnRjcC1mYjoxMjAgY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46 aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CjUuMi4xMSBTRFAgVXBkYXRlZCBBbnN3ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpv PS3CoCAxNjgzMyAxIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBh dWRpbyB2aWRlbw0KYT1ncm91cDpMUyBhdWRpbyB2aWRlbw0KYT1pY2Utb3B0aW9uczp0cmlja2xl DQptPWF1ZGlvIDQ5MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEz Ljc3DQphPW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMDkg b3B1cy80ODAwMC8yDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6YzMwMGQ4NWINCmE9aWNl LXB3ZDpkZTRlOTliZDI5MWMzMjU5MjFkNWQ0N2VmYmFiZDlhMg0KYT1maW5nZXJwcmludDpzaGEt MjU2IDZCOjhCOkYwOjY1OjVGOjc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2OjFCOjM1IA0KOkRD OkI4OjVGOjY0OjFBOjI0OkMyOjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4DQoNCioqKiBFUlJP UjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBl cnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RpdmUNCmE9dGxz LWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3Rl OiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRj cC1tdXgtb25seQ0KYT1ydGNwLXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAt aGRyZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1o ZHJleHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNyAxOTguNTEuMTAw LjcgNTE1NTYgdHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFAgMTY5NDMwMjIwNyAyMDMuMC4x MTMuNzcgNDkyMDMgdHlwIHNyZmx4IHJhZGRyIA0KMTk4LjUxLjEwMC43IHJwb3J0IDUxNTU2DQph PWVuZC1vZi1jYW5kaWRhdGVzDQptPXZpZGVvIDQ5MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEyMA0K Yz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDp2aWRlbw0KYT1tc2lkOm1hIHRiDQphPXNlbmRy ZWN2DQphPXJ0cG1hcDoxMjAgVlA4LzkwMDAwDQphPXJ0Y3AtZmI6MTIwIG5hY2sNCmE9cnRjcC1m YjoxMjAgbmFjayBwbGkNCmE9cnRjcC1mYjoxMjAgY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46aWV0 ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUu My4xIFNEUCBPZmZlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOSAwIElO IElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBtMCBtMSBtMg0KYT1ncm91 cDpMUyBtMCBtMQ0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9UTFMv UlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6bTANCmE9bXNpZDpt YSB0YQ0KYT1zZW5kb25seQ0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZTox MjANCmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVl MzQ3NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6 RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6 RTk6MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2Zp bmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBw cm9ibGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZh bGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFy cyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46 aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjpp ZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAgMjEx MzY2NzMyNyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5 bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZp eGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MSAxIFVEUMKgIDY5NDMwMjIwNyAyMDMu MC4xMTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciANCjE5Mi4wLjIuNCBycG9ydCA2MTY2NQ0K DQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJl bW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWVuZC1vZi1jYW5k aWRhdGVzDQptPXZpZGVvIDAgVURQL1RMUy9SVFAvU0FWUEYgOTggMTAwDQpjPUlOIElQNCAyMDMu MC4xMTMuMTQxDQphPWJ1bmRsZS1vbmx5DQphPW1pZDptMQ0KYT1tc2lkOm1hIHRiDQphPXNlbmRv bmx5DQphPXJ0cG1hcDo5OCBWUDgvOTAwMDANCmE9Zm10cDo5OCBtYXgtZnI9MzANCmE9cnRwbWFw OjEwMCBWUDgvOTAwMDANCmE9Zm10cDoxMDAgbWF4LWZyPTE1DQphPXJ0Y3AtZmI6KiBuYWNrDQph PXJ0Y3AtZmI6KiBuYWNrIHBsaQ0KYT1ydGNwLWZiOiogY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46 aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1leHRtYXA6MyBhPWV4dG1hcDozIHVy bjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6cnRwLXN0cmVhbS1pZA0KDQoqKiogRVJST1I6 IGludmFsaWQgc3ludGF4IGZvciAnZXh0bWFwJw0KKioqIE5vdGU6IFJlbW92aW5nIGR1cGxpY2F0 ZSAnYT0nIGZpeGVzIHRoaXMuDQoNCmE9cmlkOjEgc2VuZCBwdD05ODttYXgtd2lkdGg9MTI4MDtt YXgtaGVpZ2h0PTcyMDsNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3JpZCcNCioq KiBOb3RlOiBSZW1vdmluZyB0cmFpbGluZyBzZW1pY29sb24gZml4ZXMgdGhpcy4NCg0KYT1yaWQ6 MiBzZW5kIHB0PTEwMDttYXgtd2lkdGg9NjQwO21heC1oZWlnaHQ9NDgwOw0KDQoqKiogRVJST1I6 IGludmFsaWQgc3ludGF4IGZvciAncmlkJw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNl bWljb2xvbiBmaXhlcyB0aGlzLg0KDQphPXNpbXVsY2FzdDpzZW5kIDE7fjINCm09dmlkZW8gMCBV RFAvVExTL1JUUC9TQVZQRiAxMDEgMTAyDQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPWJ1bmRs ZS1vbmx5DQphPW1pZDptMg0KYT1tc2lkOm1hIHRjDQphPXNlbmRvbmx5DQphPXJ0cG1hcDoxMDEg SDI2NC85MDAwMA0KYT1ydHBtYXA6MTAyIEgyNjQvOTAwMDANCmE9Zm10cDoxMDEgcHJvZmlsZS1s ZXZlbC1pZD00MjQwMWY7cGFja2V0aXphdGlvbi1tb2RlPTA7bWF4LWZyPTMwDQphPWZtdHA6MTAy IHByb2ZpbGUtbGV2ZWwtaWQ9NDI0MDFmO3BhY2tldGl6YXRpb24tbW9kZT0xO21heC1mcj0xNQ0K YT1ydGNwLWZiOiogbmFjaw0KYT1ydGNwLWZiOiogbmFjayBwbGkNCmE9cnRjcC1mYjoqIGNjbSBm aXINCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9ZXh0 bWFwOjMgYT1leHRtYXA6MyB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOnJ0cC1zdHJl YW0taWQNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2V4dG1hcCcNCioqKiBOb3Rl OiBSZW1vdmluZyBkdXBsaWNhdGUgJ2E9JyBmaXhlcyB0aGlzLg0KDQphPXJpZDozIHNlbmQgcHQ9 MTAxO21heC13aWR0aD0xMjgwO21heC1oZWlnaHQ9NzIwOw0KDQoqKiogRVJST1I6IGludmFsaWQg c3ludGF4IGZvciAncmlkJw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBm aXhlcyB0aGlzLg0KDQphPXJpZDo0IHNlbmQgcHQ9MTAyO21heC13aWR0aD02NDA7bWF4LWhlaWdo dD0zNjA7DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdyaWQnDQoqKiogTm90ZTog UmVtb3ZpbmcgdHJhaWxpbmcgc2VtaWNvbG9uIGZpeGVzIHRoaXMuDQoNCmE9c2ltdWxjYXN0OnNl bmQgMzs0DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS4zLjEgU0RQIEFuc3dlcg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOSAwIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9 MCAwDQphPWdyb3VwOkJVTkRMRSBtMCBtMSBtMg0KYT1ncm91cDpMUyBtMCBtMQ0KYT1pY2Utb3B0 aW9uczp0cmlja2xlDQptPWF1ZGlvIDQ5MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJ UDQgMjAzLjAuMTEzLjc3DQphPW1pZDptMA0KYT1tc2lkOm1hIHRhDQphPXJlY3Zvbmx5DQphPXJ0 cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6YzMwMGQ4 NWINCmE9aWNlLXB3ZDpkZTRlOTliZDI5MWMzMjU5MjFkNWQ0N2VmYmFiZDlhMg0KYT1maW5nZXJw cmludDpzaGEtMjU2IDZCOjhCOkYwOjY1OjVGOjc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2OjFC OjM1IA0KOkRDOkI4OjVGOjY0OjFBOjI0OkMyOjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4DQoN CioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBS ZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3Rp dmUNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcN CioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1t dXgNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpz c3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNk ZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAgMjExMzY2NzMyNyAxOTguNTEuMTAwLjcgNjE2 NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScN CioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0K YT1jYW5kaWRhdGU6MSAxIFVEUMKgIDY5NDMwMjIwNyAyMDMuMC4xMTMuNzcgNDkyMDMgdHlwIHNy Zmx4IHJhZGRyIA0KMTk4LjUxLjEwMC43IHJwb3J0IDYxNjY1DQoNCioqKiBFUlJPUjogaW52YWxp ZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNl cyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9ZW5kLW9mLWNhbmRpZGF0ZXMNCm09dmlkZW8gNDky MDMgVURQL1RMUy9SVFAvU0FWUEYgOTggMTAwDQpjPUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9bWlk Om0xDQphPW1zaWQ6bWEgdGINCmE9cmVjdm9ubHkNCmE9cnRwbWFwOjk4IFZQOC85MDAwMA0KYT1y dHBtYXA6MTAwIFZQOC85MDAwMA0KYT1mbXRwOjk4IG1heC1mcj0zMA0KYT1mbXRwOjEwMCBtYXgt ZnI9MTUNCmE9cnRjcC1mYjoqIG5hY2sNCmE9cnRjcC1mYjoqIG5hY2sgcGxpDQphPXJ0Y3AtZmI6 KiBjY20gZmlyDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlk DQphPWV4dG1hcDozIGE9ZXh0bWFwOjMgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2Rlczpy dHAtc3RyZWFtLWlkDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdleHRtYXAnDQoq KiogTm90ZTogUmVtb3ZpbmcgZHVwbGljYXRlICdhPScgZml4ZXMgdGhpcy4NCg0KYT1yaWQ6MSBy ZWN2IHB0PTk4O21heC13aWR0aD0xMjgwO21heC1oZWlnaHQ9NzIwOw0KDQoqKiogRVJST1I6IGlu dmFsaWQgc3ludGF4IGZvciAncmlkJw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNlbWlj b2xvbiBmaXhlcyB0aGlzLg0KDQphPXJpZDoyIHJlY3YgcHQ9MTAwO21heC13aWR0aD02NDA7bWF4 LWhlaWdodD00ODA7DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdyaWQnDQoqKiog Tm90ZTogUmVtb3ZpbmcgdHJhaWxpbmcgc2VtaWNvbG9uIGZpeGVzIHRoaXMuDQoNCmE9c2ltdWxj YXN0OnJlY3YgMTsyDQptPXZpZGVvIDQ5MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEwMSAxMDINCmM9 SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6bTINCmE9bXNpZDptYSB0Yw0KYT1yZWN2b25seQ0K YT1ydHBtYXA6MTAxIEgyNjQvOTAwMDANCmE9cnRwbWFwOjEwMiBIMjY0LzkwMDAwDQphPWZtdHA6 MTAxIHByb2ZpbGUtbGV2ZWwtaWQ9NDI0MDFmO3BhY2tldGl6YXRpb24tbW9kZT0xO21heC1mcj0z MA0KYT1mbXRwOjEwMiBwcm9maWxlLWxldmVsLWlkPTQyNDAxZjtwYWNrZXRpemF0aW9uLW1vZGU9 MTttYXgtZnI9MTUNCmE9cnRjcC1mYjoqIG5hY2sNCmE9cnRjcC1mYjoqIG5hY2sgcGxpDQphPXJ0 Y3AtZmI6KiBjY20gZmlyDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNk ZXM6bWlkDQphPWV4dG1hcDozIGE9ZXh0bWFwOjMgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6 c2RlczpydHAtc3RyZWFtLWlkDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdleHRt YXAnDQoqKiogTm90ZTogUmVtb3ZpbmcgZHVwbGljYXRlICdhPScgZml4ZXMgdGhpcy4NCg0KYT1y aWQ6MyByZWN2IHB0PTEwMTttYXgtd2lkdGg9MTI4MDttYXgtaGVpZ2h0PTcyMDsNCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3JpZCcNCioqKiBOb3RlOiBSZW1vdmluZyB0cmFpbGlu ZyBzZW1pY29sb24gZml4ZXMgdGhpcy4NCg0KYT1yaWQ6NCByZWN2IHB0PTEwMjttYXgtd2lkdGg9 NjQwO21heC1oZWlnaHQ9MzYwOw0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAncmlk Jw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBmaXhlcyB0aGlzLg0KDQph PXNpbXVsY2FzdDpyZWN2IDM7NA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMy4yIFNEUCBP ZmZlciB3aXRoIFNWQw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOSAwIElO IElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBtMCBtMQ0KYT1ncm91cDpM UyBtMCBtMQ0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9UTFMvUlRQ L1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1taWQ6bTANCmE9bXNpZDptYSB0 YQ0KYT1zZW5kb25seQ0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjAN CmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3 NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6 Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6 MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2Zpbmdl cnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9i bGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlk IHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBv ciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1yc2l6ZQ0KYT1leHRtYXA6MSB1cm46aWV0 ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRm OnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQwqAgMjExMzY2 NzMyNyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRh eCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVz IHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MSAxIFVEUMKgIDY5NDMwMjIwNyAyMDMuMC4x MTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciANCjE5Mi4wLjIuNCBycG9ydCA2MTY2NQ0KDQoq KiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92 aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWVuZC1vZi1jYW5kaWRh dGVzDQptPXZpZGVvIDAgVURQL1RMUy9SVFAvU0FWUEYgOTYgOTcgMTAwDQpjPUlOIElQNCAyMDMu MC4xMTMuMTQxDQphPWJ1bmRsZS1vbmx5DQphPW1pZDptMQ0KYT1tc2lkOm1hIHRiDQphPXNlbmRv bmx5DQphPXJ0cG1hcDo5NiBIMjY0LzkwMDAwDQphPWZtdHA6OTYgcHJvZmlsZS1sZXZlbC1pZD00 ZDAwMjg7IA0KcGFja2V0aXphdGlvbi1tb2RlPTE7bWF4LWZyPTMwO21heC1mcz04MDQwDQphPXJ0 cG1hcDo5NyBIMjY0LzkwMDAwDQphPWZtdHA6OTcgcHJvZmlsZS1sZXZlbC1pZD00ZDAwMjg7cGFj a2V0aXphdGlvbi1tb2RlPTE7IA0KbWF4LWZyPTE1O21heC1mcz0xMjAwDQphPXJ0cG1hcDoxMDAg SDI2NC1TVkMvOTAwMDANCmE9Zm10cDoxMDAgcHJvZmlsZS1sZXZlbC1pZD00ZDAwMjg7cGFja2V0 aXphdGlvbi1tb2RlPTE7IA0KbWF4LWZyPTMwO21heC1mcz04MDQwDQphPWRlcGVuZDoxMDAgbGF5 IG0xOjk2LDk3DQphPXJ0Y3AtZmI6KiBuYWNrDQphPXJ0Y3AtZmI6KiBuYWNrIHBsaQ0KYT1ydGNw LWZiOiogY2NtIGZpcg0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVz Om1pZA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMy4yIFNEUCBBbnN3ZXIgd2l0aCBTVkMN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS0gMjA1MTkgMCBJTiBJUDQgMC4wLjAuMA0K cz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgbTAgbTENCmE9Z3JvdXA6TFMgbTAgbTENCmE9aWNl LW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA0OTIwMyBVRFAvVExTL1JUUC9TQVZQRiAxMDkNCmM9 SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6bTANCmE9bXNpZDptYSB0YQ0KYT1yZWN2b25seQ0K YT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjANCmE9aWNlLXVmcmFnOjA3 NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3NGFmMDhhMDY4DQphPWZp bmdlcnByaW50OnNoYS0yNTYgNkI6OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6 NDY6MUI6MzUgDQo6REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6 MDgNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5v dGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPXNldHVw OmFjdGl2ZQ0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAndGxz LWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxvbmdlci4NCg0KYT1y dGNwLW11eA0KYT1ydGNwLXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRy ZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJl eHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNiAxOTguNTEuMTAwLjcg NTE1NTYgdHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFDCoCAxNjk0MzAyMjA2IDIwMy4wLjEx My43NyA0OTIwMyB0eXAgc3JmbHggcmFkZHIgDQoxOTguNTEuMTAwLjcgcnBvcnQgNTE1NTYNCg0K KioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1v dmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1lbmQtb2YtY2FuZGlk YXRlcw0KbT12aWRlbyA0OTIwMyBVRFAvVExTL1JUUC9TQVZQRiA5NiAxMDANCmM9SU4gSVA0IDIw My4wLjExMy43Nw0KYT1taWQ6bTENCmE9bXNpZDptYSB0Yg0KYT1yZWN2b25seQ0KYT1ydHBtYXA6 OTYgSDI2NC85MDAwMA0KYT1mbXRwOjk2IHByb2ZpbGUtbGV2ZWwtaWQ9NGQwMDI4O3BhY2tldGl6 YXRpb24tbW9kZT0xOyANCm1heC1mcj0zMDttYXgtZnM9ODA0MA0KYT1ydHBtYXA6MTAwIEgyNjQt U1ZDLzkwMDAwDQphPWZtdHA6MTAwIHByb2ZpbGUtbGV2ZWwtaWQ9NGQwMDI4O3BhY2tldGl6YXRp b24tbW9kZT0xOyANCm1heC1mcj0zMDttYXgtZnM9ODA0MA0KYT1kZXBlbmQ6MTAwIGxheSBtMTo5 Ng0KYT1ydGNwLWZiOiogbmFjaw0KYT1ydGNwLWZiOiogbmFjayBwbGkNCmE9cnRjcC1mYjoqIGNj bSBmaXINCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo1LjMuNSBTRFAgT2ZmZXINCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0Kdj0wDQpvPS0gMjA1MTkgMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91 cDpCVU5ETEUgbTAgbTENCmE9Z3JvdXA6TFMgbTAgbTENCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0K bT1hdWRpbyA1NDYwOSBVRFAvVExTL1JUUC9TQVZQRiAxMDkNCmM9SU4gSVA0IDIwMy4wLjExMy4x NDENCmE9bWlkOm0wDQphPW1zaWQ6bWEgdGENCmE9c2VuZG9ubHkNCmE9cnRwbWFwOjEwOSBvcHVz LzQ4MDAwLzINCmE9bWF4cHRpbWU6MTIwDQphPWljZS11ZnJhZzowNzRjNjU1MA0KYT1pY2UtcHdk OmEyOGEzOTdhNGMzZjMxNzQ3ZDFlZTM0NzRhZjA4YTA2OA0KYT1maW5nZXJwcmludDpzaGEtMjU2 IDE5OkUyOjFDOjNCOjRCOjlGOjgxOkU2OkI4OjVDOkY0OkE1OkE4OkQ4OjczOjA0IA0KOkJCOjA1 OjJGOjcwOjlGOjA0OkE5OjBFOjA1OkU5OjI2OjMzOkU4OjcwOjg4OkEyDQoNCioqKiBFUlJPUjog aW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJh bnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RwYXNzDQphPXJ0Y3At bXV4DQphPXRscy1pZDoxDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICd0bHMtaWQn DQoqKiogTm90ZTogdGxzLWlkIG11c3QgYmUgMjAgY2hhcnMgb3IgbG9uZ2VyLg0KDQphPXJ0Y3At cnNpemUNCmE9ZXh0bWFwOjEgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c3NyYy1hdWRpby1s ZXZlbA0KYT1leHRtYXA6MiB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzZGVzOm1pZA0KYT1j YW5kaWRhdGU6MCAxIFVEUMKgIDIxMTM2NjczMjcgMTkyLjAuMi40IDYxNjY1IHR5cCBob3N0DQoN CioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVt b3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEg MSBVRFDCoCA2OTQzMDIyMDcgMjAzLjAuMTEzLjE0MSA1NDYwOSB0eXAgc3JmbHggcmFkZHIgDQox OTIuMC4yLjQgcnBvcnQgNjE2NjUNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2Nh bmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJv YmxlbS4NCg0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KbT12aWRlbyAwIFVEUC9UTFMvUlRQL1NBVlBG IDk4IDEwMCAxMDEgMTAzDQpjPUlOIElQNCAyMDMuMC4xMTMuMTQxDQphPWJ1bmRsZS1vbmx5DQph PW1pZDptMQ0KYT1tc2lkOm1hIHRiDQphPXNlbmRvbmx5DQphPXJ0cG1hcDo5OCBWUDgvOTAwMDAN CmE9cnRwbWFwOjEwMCBWUDgvOTAwMDANCmE9cnRwbWFwOjEwMSBmbGV4ZmVjLzkwMDAwDQphPXJ0 cG1hcDoxMDMgZmxleGZlYy85MDAwMA0KYT1mbXRwOjk4IG1heC1mcj0zMDttYXgtZnM9ODA0MA0K YT1mbXRwOjEwMCBtYXgtZnI9MTU7bWF4LWZzPTEyMDANCmE9Zm10cDoxMDEgTD01OyBEPTEwOyBU b1A9MjsgcmVwYWlyLXdpbmRvdz0yMDAwMDANCmE9Zm10cDoxMDMgTD01OyBEPTEwOyBUb1A9Mjsg cmVwYWlyLXdpbmRvdz0yMDAwMDANCmE9cnRjcC1mYjoqIG5hY2sNCmE9cnRjcC1mYjoqIG5hY2sg cGxpDQphPXJ0Y3AtZmI6KiBjY20gZmlyDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAt aGRyZXh0OnNkZXM6bWlkDQphPWV4dG1hcDozIGE9ZXh0bWFwOjMgdXJuOmlldGY6cGFyYW1zOnJ0 cC1oZHJleHQ6c2RlczpydHAtc3RyZWFtLWlkDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXgg Zm9yICdleHRtYXAnDQoqKiogTm90ZTogUmVtb3ZpbmcgZHVwbGljYXRlICdhPScgZml4ZXMgdGhp cy4NCg0KYT1yaWQ6MSBzZW5kIHB0PTk4Ow0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZv ciAncmlkJw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBmaXhlcyB0aGlz Lg0KDQphPXJpZDoyIHNlbmQgcHQ9MTAwOw0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZv ciAncmlkJw0KKioqIE5vdGU6IFJlbW92aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBmaXhlcyB0aGlz Lg0KDQphPXNpbXVsY2FzdDpzZW5kIDE7Mg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuMy41 IFNEUCBBbnN3ZXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdj0wDQpvPS0gMjA1MTkgMCBJTiBJ UDQgMC4wLjAuMA0Kcz0tDQp0PTAgMA0KYT1ncm91cDpCVU5ETEUgbTAgbTENCmE9Z3JvdXA6TFMg bTAgbTENCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA0OTIwMyBVRFAvVExTL1JUUC9T QVZQRiAxMDkNCmM9SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6bTANCmE9bXNpZDptYSB0YQ0K YT1yZWN2b25seQ0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1tYXhwdGltZToxMjANCmE9 aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3NGFm MDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgNkI6OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6 QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6 RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnBy aW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVt Lg0KDQphPXNldHVwOmFjdGl2ZQ0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3lu dGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIwIGNoYXJzIG9yIGxv bmdlci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBh cmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFy YW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNiAx OTguNTEuMTAwLjcgNTE1NTYgdHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFDCoCAxNjk0MzAy MjA2IDIwMy4wLjExMy43NyA0OTIwMyB0eXAgc3JmbHggcmFkZHIgDQoxOTguNTEuMTAwLjcgcnBv cnQgNTE1NTYNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioq KiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1l bmQtb2YtY2FuZGlkYXRlcw0KbT12aWRlbyA0OTIwMyBVRFAvVExTL1JUUC9TQVZQRiA5OCAxMDAg MTAxIDEwMw0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQphPW1pZDptMQ0KYT1tc2lkOm1hIHRiDQph PXJlY3Zvbmx5DQphPXJ0cG1hcDo5OCBWUDgvOTAwMDANCmE9cnRwbWFwOjEwMCBWUDgvOTAwMDAN CmE9cnRwbWFwOjEwMSBmbGV4ZmVjLzkwMDAwDQphPXJ0cG1hcDoxMDMgZmxleGZlYy85MDAwMA0K YT1mbXRwOjk4IG1heC1mcj0zMDttYXgtZnM9ODA0MA0KYT1mbXRwOjEwMCBtYXgtZnI9MTU7bWF4 LWZzPTEyMDANCmE9Zm10cDoxMDEgTD01OyBEPTEwOyBUb1A9MjsgcmVwYWlyLXdpbmRvdz0yMDAw MDANCmE9Zm10cDoxMDMgTD01OyBEPTEwOyBUb1A9MjsgcmVwYWlyLXdpbmRvdz0yMDAwMDANCmE9 cnRjcC1mYjoqIG5hY2sNCmE9cnRjcC1mYjoqIG5hY2sgcGxpDQphPXJ0Y3AtZmI6KiBjY20gZmly DQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWV4dG1h cDozIGE9ZXh0bWFwOjMgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczpydHAtc3RyZWFt LWlkDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdleHRtYXAnDQoqKiogTm90ZTog UmVtb3ZpbmcgZHVwbGljYXRlICdhPScgZml4ZXMgdGhpcy4NCg0KYT1yaWQ6MSByZWN2IHB0PTk4 Ow0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAncmlkJw0KKioqIE5vdGU6IFJlbW92 aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBmaXhlcyB0aGlzLg0KDQphPXJpZDoyIHJlY3YgcHQ9MTAw Ow0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAncmlkJw0KKioqIE5vdGU6IFJlbW92 aW5nIHRyYWlsaW5nIHNlbWljb2xvbiBmaXhlcyB0aGlzLg0KDQphPXNpbXVsY2FzdDpyZWN2IDE7 Mg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuNC4xIFNEUCBPZmZlcg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQp2PTANCm89LSAyMDUxOCAwIElOIElQNCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQph PWdyb3VwOkJVTkRMRSBhdWRpbw0KYT1pY2Utb3B0aW9uczp0cmlja2xlDQptPWF1ZGlvIDU0NjA5 IFVEUC9UTFMvUlRQL1NBVlBGIDEwOSAwIDgNCmM9SU4gSVA0IDIwMy4wLjExMy4xNDENCmE9bWlk OmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9c2VuZHJlY3YNCmE9cnRwbWFwOjEwOSBvcHVzLzQ4MDAw LzINCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPXJ0cG1hcDo4IFBDTUEvODAwMA0KYT1tYXhwdGlt ZToxMjANCmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdk MWVlMzQ3NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNoYS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6 ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6 MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3Ig J2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhp cyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBp bnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBj aGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9cnRjcC1yc2l6ZQ0KYT1ydGNwLWZiOiog bmFjaw0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJhbXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxl dmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNh bmRpZGF0ZTowIDEgVURQwqAgMjExMzY2NzMyNyAxOTIuMC4yLjQgNjE2NjUgdHlwIGhvc3QNCg0K KioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1v dmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MSAx IFVEUMKgIDY5NDMwMjIwNyAyMDMuMC4xMTMuMTQxIDU0NjA5IHR5cCBzcmZseCByYWRkciANCjE5 Mi4wLjIuNCBycG9ydCA2MTY2NQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2Fu ZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9i bGVtLg0KDQphPWVuZC1vZi1jYW5kaWRhdGVzDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS40 LjEgU0RQIEFuc3dlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LcKgIDE2ODMzIDAg SU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0wIDANCmE9Z3JvdXA6QlVORExFIGF1ZGlvDQphPWljZS1v cHRpb25zOnRyaWNrbGUNCm09YXVkaW8gNDkyMDMgVURQL1RMUy9SVFAvU0FWUEYgMTA5IDAgOTgN CmM9SU4gSVA0IDIwMy4wLjExMy43Nw0KYT1taWQ6YXVkaW8NCmE9bXNpZDptYSB0YQ0KYT1zZW5k cmVjdg0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDAvMg0KYT1ydHBtYXA6MCBQQ01VLzgwMDANCmE9 cnRwbWFwOjAgUENNQS84MDAwDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6YzMwMGQ4NWIN CmE9aWNlLXB3ZDpkZTRlOTliZDI5MWMzMjU5MjFkNWQ0N2VmYmFiZDlhMg0KYT1maW5nZXJwcmlu dDpzaGEtMjU2IDZCOjhCOkYwOjY1OjVGOjc4OkUyOjUxOjNCOkFDOjZGOkYzOjNGOjQ2OjFCOjM1 IA0KOkRDOkI4OjVGOjY0OjFBOjI0OkMyOjQzOkYwOkExOjU4OkQwOkExOjJDOjE5OjA4DQoNCioq KiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdmaW5nZXJwcmludCcNCioqKiBOb3RlOiBSZW1v dmluZyBlcnJhbnQgc3BhY2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1zZXR1cDphY3RpdmUN CmE9dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioq KiBOb3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgN CmE9cnRjcC1yc2l6ZQ0KYT1ydGNwLWZiOiogbmFjaw0KYT1leHRtYXA6MSB1cm46aWV0ZjpwYXJh bXM6cnRwLWhkcmV4dDpzc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRmOnBhcmFt czpydHAtaGRyZXh0OnNkZXM6bWlkDQphPWNhbmRpZGF0ZTowIDEgVURQIDIxMTM2NjczMjcgMTk4 LjUxLjEwMC43IDUxNTU2IHR5cCBob3N0DQphPWNhbmRpZGF0ZToxIDEgVURQIDE2OTQzMDIyMDcg MjAzLjAuMTEzLjc3IDQ5MjAzIHR5cCBzcmZseCByYWRkciANCjE5OC41MS4xMDAuNyBycG9ydCA1 MTU1Ng0KYT1lbmQtb2YtY2FuZGlkYXRlcw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjUuNC4y IFNEUCBPZmZlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOCAwIElOIElQ NCAwLjAuMC4wDQpzPS0NCnQ9MCAwDQphPWdyb3VwOkJVTkRMRSBhdWRpbw0KYT1pY2Utb3B0aW9u czp0cmlja2xlDQptPWF1ZGlvIDU0NjA5IFVEUC9UTFMvUlRQL1NBVlBGIDEwOSAwIDgNCmM9SU4g SVA0IDIwMy4wLjExMy4xNDENCmE9bWlkOmF1ZGlvDQphPW1zaWQ6bWEgdGENCmE9c2VuZHJlY3YN CmE9cnRwbWFwOjEwOSBvcHVzLzQ4MDAwLzINCmE9cnRwbWFwOjAgUENNVS84MDAwDQphPXJ0cG1h cDowIFBDTUEvODAwMA0KYT1tYXhwdGltZToxMjANCmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWlj ZS1wd2Q6YTI4YTM5N2E0YzNmMzE3NDdkMWVlMzQ3NGFmMDhhMDY4DQphPWZpbmdlcnByaW50OnNo YS0yNTYgMTk6RTI6MUM6M0I6NEI6OUY6ODE6RTY6Qjg6NUM6RjQ6QTU6QTg6RDg6NzM6MDQgDQo6 QkI6MDU6MkY6NzA6OUY6MDQ6QTk6MEU6MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTINCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5n IGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdHBhc3MNCmE9 dGxzLWlkOjENCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ3Rscy1pZCcNCioqKiBO b3RlOiB0bHMtaWQgbXVzdCBiZSAyMCBjaGFycyBvciBsb25nZXIuDQoNCmE9cnRjcC1tdXgNCmE9 cnRjcC1yc2l6ZQ0KYT1ydGNwLWZiOiogbmFjaw0KYT1leHRtYXA6MS9yZWN2b25seSB1cm46aWV0 ZjpwYXJhbXM6cnRwLWhkcmV4dDpjc3JjLWF1ZGlvLWxldmVsDQphPWV4dG1hcDoyIHVybjppZXRm OnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjMgdXJuOmlldGY6 cGFyYW1zOnJ0cC1oZHJleHQ6c2RlczptaWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFDCoCAyMTEzNjY3 MzI3IDE5Mi4wLjIuNCA2MTY2NSB0eXAgaG9zdA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4 IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMg dGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZToxIDEgVURQwqAgNjk0MzAyMjA3IDIwMy4wLjEx My4xNDEgNTQ2MDkgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40IHJwb3J0IDYxNjY1DQoNCioq KiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3Zp bmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9ZW5kLW9mLWNhbmRpZGF0 ZXMNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo1LjQuMiBTRFAgQW5zd2VyDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCnY9MA0Kbz0twqAgMTY4MzMgMCBJTiBJUDQgMC4wLjAuMA0Kcz0tDQp0PTAg MA0KYT1ncm91cDpCVU5ETEUgYXVkaW8NCmE9aWNlLW9wdGlvbnM6dHJpY2tsZQ0KbT1hdWRpbyA0 OTIwMyBVRFAvVExTL1JUUC9TQVZQRiAxMDkgMCA5OA0KYz1JTiBJUDQgMjAzLjAuMTEzLjc3DQph PW1pZDphdWRpbw0KYT1tc2lkOm1hIHRhDQphPXNlbmRyZWN2DQphPXJ0cG1hcDoxMDkgb3B1cy80 ODAwMC8yDQphPXJ0cG1hcDowIFBDTVUvODAwMA0KYT1ydHBtYXA6MCBQQ01BLzgwMDANCmE9bWF4 cHRpbWU6MTIwDQphPWljZS11ZnJhZzpjMzAwZDg1Yg0KYT1pY2UtcHdkOmRlNGU5OWJkMjkxYzMy NTkyMWQ1ZDQ3ZWZiYWJkOWEyDQphPWZpbmdlcnByaW50OnNoYS0yNTYgNkI6OEI6RjA6NjU6NUY6 Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6 NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBm b3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMg dGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdGl2ZQ0KYT10bHMtaWQ6MQ0KDQoqKiogRVJST1I6 IGludmFsaWQgc3ludGF4IGZvciAndGxzLWlkJw0KKioqIE5vdGU6IHRscy1pZCBtdXN0IGJlIDIw IGNoYXJzIG9yIGxvbmdlci4NCg0KYT1ydGNwLW11eA0KYT1ydGNwLXJzaXplDQphPXJ0Y3AtZmI6 KiBuYWNrDQphPWV4dG1hcDoxL3NlbmRvbmx5IHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OmNz cmMtYXVkaW8tbGV2ZWwNCmE9ZXh0bWFwOjIgdXJuOmlldGY6cGFyYW1zOnJ0cC1oZHJleHQ6c2Rl czptaWQNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNyAxOTguNTEuMTAwLjcgNTE1NTYg dHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFAgMTY5NDMwMjIwNyAyMDMuMC4xMTMuNzcgNDky MDMgdHlwIHNyZmx4IHJhZGRyIA0KMTk4LjUxLjEwMC43IHJwb3J0IDUxNTU2DQphPWVuZC1vZi1j YW5kaWRhdGVzDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS40LjMgU0RQIEFuc3dlcg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQp2PTANCm89LSAyMDUxOSAwIElOIElQNCAwLjAuMC4wDQpzPS0N CnQ9MCAwDQptPWF1ZGlvIDQ5MjAzIFVEUC9UTFMvUlRQL1NBVlBGIDEwOQ0KYz1JTiBJUDQgMjAz LjAuMTEzLjE0MQ0KYT1ydGNwOjYwMDY1IElOIElQNCAyMDMuMC4xMTMuMTQxDQphPXNlbmRyZWN2 DQphPXJ0cG1hcDoxMDkgb3B1cy80ODAwMC8yDQphPW1heHB0aW1lOjEyMA0KYT1pY2UtdWZyYWc6 dWZyYWc6YzMwMGQ4NWINCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ljZS11ZnJh ZycNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgJ3VmcmFnOicgZml4ZXMgdGhpcy4NCg0KYT1p Y2UtcHdkOmRlNGU5OWJkMjkxYzMyNTkyMWQ1ZDQ3ZWZiYWJkOWEyDQphPWZpbmdlcnByaW50OnNo YS0yNTYgNkI6OEI6RjA6NjU6NUY6Nzg6RTI6NTE6M0I6QUM6NkY6RjM6M0Y6NDY6MUI6MzUgDQo6 REM6Qjg6NUY6NjQ6MUE6MjQ6QzI6NDM6RjA6QTE6NTg6RDA6QTE6MkM6MTk6MDgNCg0KKioqIEVS Uk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ2ZpbmdlcnByaW50Jw0KKioqIE5vdGU6IFJlbW92aW5n IGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPXNldHVwOmFjdGl2ZQ0KYT1y dGNwLXJzaXplDQphPWV4dG1hcDoxIHVybjppZXRmOnBhcmFtczpydHAtaGRyZXh0OnNzcmMtYXVk aW8tbGV2ZWwNCmE9Y2FuZGlkYXRlOjAgMSBVRFDCoCAyMTEzNjY3MzI3IDE5OC41MS4xMDAuNyA1 MTU1NiB0eXAgaG9zdA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRl Jw0KKioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0K DQphPWNhbmRpZGF0ZToxIDEgVURQwqAgNjk0MzAyMjA3IDIwMy4wLjExMy43NyA0OTIwMyB0eXAg c3JmbHggcmFkZHIgDQoxOTguNTEuMTAwLjcgcnBvcnQgNTE1NTYNCg0KKioqIEVSUk9SOiBpbnZh bGlkIHN5bnRheCBmb3IgJ2NhbmRpZGF0ZScNCioqKiBOb3RlOiBSZW1vdmluZyBlcnJhbnQgc3Bh Y2VzIGZpeGVzIHRoaXMgcHJvYmxlbS4NCg0KYT1jYW5kaWRhdGU6MCAyIFVEUCAyMTEzNjY3MzI2 IDE5OC41MS4xMDAuNyA1MTU1OCB0eXAgaG9zdA0KYT1jYW5kaWRhdGU6MSAyIFVEUMKgIDE2OTQz MDIyMDYgMjAzLjAuMTEzLjc3IDYwMDY1IHR5cCBzcmZseCByYWRkciANCjE5OC41MS4xMDAuNyBy cG9ydCA1MTU1OA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0K KioqIE5vdGU6IFJlbW92aW5nIGVycmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQpt PXZpZGVvIDAgVURQL1RMUy9SVFAvU0FWUEYgOTggMTAwDQptPXZpZGVvIDAgVURQL1RMUy9SVFAv U0FWUEYgOTggMTAwDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KNS40LjUgU0RQIE9mZmVyDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCnY9MA0Kbz0tIDIwNTE4IDAgSU4gSVA0IDAuMC4wLjANCnM9 LQ0KdD0wIDANCmE9aWNlLXVmcmFnOjA3NGM2NTUwDQphPWljZS1wd2Q6YTI4YTM5N2E0YzNmMzE3 NDdkMWVlMzQ3NGFmMDhhMDY4DQphPXJ0Y3AtcnNpemUNCm09YXVkaW8gNTQ3MzIgUlRQL0FWUCAx MDkNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ20nDQoqKiogTm90ZTogVXNpbmcg dGhlIGNvcnJlY3QgdHJhbnNwb3J0IHZhbHVlIGZpeGVzIHRoaXMuDQoNCmM9SU4gSVA0IDIwMy4w LjExMy4xNDENCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiAxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpC ODo1QzpGNDpBNTpBODpEODo3MzowNCANCjpCQjowNToyRjo3MDo5RjowNDpBOTowRTowNTpFOToy NjozMzpFODo3MDo4ODpBMg0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2Vy cHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2Js ZW0uDQoNCmE9cnRwbWFwOjEwOSBvcHVzLzQ4MDAwDQphPXB0aW1lOjIwDQphPXNlbmRyZWN2DQph PXJ0Y3AtbXV4DQphPXJ0Y3A6NjQ2NzggSU4gSVA0IDIwMy4wLjExMy4xNDENCmE9Y2FuZGlkYXRl OjAgMSBVRFDCoCAyMTEzNjY3MzI3IDE5Mi4wLjIuNCA1NDczMiB0eXAgaG9zdA0KDQoqKiogRVJS T1I6IGludmFsaWQgc3ludGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IFJlbW92aW5nIGVy cmFudCBzcGFjZXMgZml4ZXMgdGhpcyBwcm9ibGVtLg0KDQphPWNhbmRpZGF0ZToxIDEgVURQwqAg Njk0MzAyMjA3IDIwMy4wLjExMy4xNDEgNTQ3MzIgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40 IHJwb3J0IDU0NzMyDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUn DQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoN CmE9Y2FuZGlkYXRlOjAgMiBVRFAgMjExMzY2NzMyNiAxOTIuMC4yLjQgNjQ2NzggdHlwIGhvc3QN CmE9Y2FuZGlkYXRlOjEgMiBVRFDCoCAxNjk0MzAyMjA2IDIwMy4wLjExMy4xNDEgNjQ2NzggdHlw IHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40IHJwb3J0IDY0Njc4DQoNCioqKiBFUlJPUjogaW52YWxp ZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNl cyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCm09dmlkZW8gNjI0NDUgUlRQL0FWUCAxMjANCg0KKioq IEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ20nDQoqKiogTm90ZTogVXNpbmcgdGhlIGNvcnJl Y3QgdHJhbnNwb3J0IHZhbHVlIGZpeGVzIHRoaXMuDQoNCmM9SU4gSVA0IDIwMy4wLjExMy4xNDEN CmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiBEQzpCODo1Rjo2NDoxQToyNDpDMjo0MzpGMDpBMTo1ODpE MDpBMToyQzoxOTowOCANCjo2Qjo4QjpGMDo2NTo1Rjo3ODpFMjo1MTozQjpBQzo2RjpGMzozRjo0 NjoxQjozNQ0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2VycHJpbnQnDQoq KiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9 cnRwbWFwOjEyMCBWUDgvOTAwMDANCmE9c2VuZHJlY3YNCmE9cnRjcC1tdXgNCmE9cnRjcDo1NDcy MSBJTiBJUDQgMjAzLjAuMTEzLjE0MQ0KYT1jYW5kaWRhdGU6MCAxIFVEUMKgIDIxMTM2NjczMjcg MTkyLjAuMi40IDYyNDQ1IHR5cCBob3N0DQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50YXggZm9y ICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlz IHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMSBVRFDCoCAxNjk0MzAyMjA3IDIwMy4wLjExMy4x NDEgNjI1MzcgdHlwIHNyZmx4IHJhZGRyIA0KMTkyLjAuMi40IHJwb3J0IDYyNDQ1DQoNCioqKiBF UlJPUjogaW52YWxpZCBzeW50YXggZm9yICdjYW5kaWRhdGUnDQoqKiogTm90ZTogUmVtb3Zpbmcg ZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjAgMiAyMTEz NjY3MzI2IDE5Mi4wLjIuNCA1NDcyMSB0eXAgaG9zdA0KDQoqKiogRVJST1I6IGludmFsaWQgc3lu dGF4IGZvciAnY2FuZGlkYXRlJw0KKioqIE5vdGU6IEFkZGluZyAnVURQJyBmaXhlcyB0aGlzIHBy b2JsZW0uDQoNCmE9Y2FuZGlkYXRlOjEgMiBVRFAgMTY5NDMwMjIwNiAyMDMuMC4xMTMuMTQxIDU0 NzIxIHR5cCBzcmZseCByYWRkciANCjE5Mi4wLjIuNCBycG9ydCA1NDcyMQ0KYT1ydGNwLWZiOjEy MCBuYWNrIHBsaQ0KYT1ydGNwLWZiOjEyMCBjY20gZmlyDQoNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KNS40LjUgU0RQIEFuc3dlcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp2PTANCm89LcKgIDE2 ODMzIDAgSU4gSVA0IDAuMC4wLjANCnM9LQ0KdD0wIDANCm09YXVkaW8gNDkyMDMgUlRQL0FWUCAx MDkNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5bnRheCBmb3IgJ20nDQoqKiogTm90ZTogVXNpbmcg dGhlIGNvcnJlY3QgdHJhbnNwb3J0IHZhbHVlIGZpeGVzIHRoaXMuDQoNCmM9SU4gSVA0IDIwMy4w LjExMy43Nw0KYT1ydHBtYXA6MTA5IG9wdXMvNDgwMDANCmE9cHRpbWU6MjANCmE9c2VuZHJlY3YN CmE9aWNlLXVmcmFnOmMzMDBkODViDQphPWljZS1wd2Q6ZGU0ZTk5YmQyOTFjMzI1OTIxZDVkNDdl ZmJhYmQ5YTINCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiBCQjowNToyRjo3MDo5RjowNDpBOTowRTow NTpFOToyNjozMzpFODo3MDo4ODpBMiANCjoxOTpFMjoxQzozQjo0Qjo5Rjo4MTpFNjpCODo1QzpG NDpBNTpBODpEODo3MzowNA0KDQoqKiogRVJST1I6IGludmFsaWQgc3ludGF4IGZvciAnZmluZ2Vy cHJpbnQnDQoqKiogTm90ZTogUmVtb3ZpbmcgZXJyYW50IHNwYWNlcyBmaXhlcyB0aGlzIHByb2Js ZW0uDQoNCmE9cnRjcC1tdXgNCmE9Y2FuZGlkYXRlOjAgMSBVRFAgMjExMzY2NzMyNyAxOTguNTEu MTAwLjcgNDkyMDMgdHlwIGhvc3QNCmE9Y2FuZGlkYXRlOjEgMSBVRFAgMTY5NDMwMjIwNyAyMDMu MC4xMTMuNzcgNDkyMDMgdHlwIHNyZmx4IHJhZGRyIA0KMTk4LjUxLjEwMC43IHJwb3J0IDQ5MjAz DQptPXZpZGVvwqAgNjMxMzAgUlRQL1NBVlAgMTIwDQoNCioqKiBFUlJPUjogaW52YWxpZCBzeW50 YXggZm9yICdtJw0KKioqIE5vdGU6IFVzaW5nIHRoZSBjb3JyZWN0IHRyYW5zcG9ydCB2YWx1ZSBm aXhlcyB0aGlzLg0KDQpjPUlOIElQNCAyMDMuMC4xMTMuNzcNCmE9cnRwbWFwOjEyMCBWUDgvOTAw MDANCmE9c2VuZHJlY3YNCmE9aWNlLXVmcmFnOmUzOTA5MW5hDQphPWljZS1wd2Q6ZGJjMzI1OTIx ZDVkZDI5ZTRlOTkxNDdlZmJhYmQ5YTINCmE9ZmluZ2VycHJpbnQ6c2hhLTI1NiBCQjowQTk6MEU6 MDU6RTk6MjY6MzM6RTg6NzA6ODg6QTI1OjJGOjcwOjlGOjA0OiANCjoxOTpFMjoxQzozQjo0Qjo5 Rjo4MTo1OjJGOjcwOjlGOjA0OjpGNDpBNTpBODpEODoNCg0KKioqIEVSUk9SOiBpbnZhbGlkIHN5 bnRheCBmb3IgJ2ZpbmdlcnByaW50JyAodGhlcmUncyB0b28gbXVjaCB3cm9uZyBoZXJlIA0KdG8g ZW51bWVyYXRlKQ0KDQphPXJ0Y3AtbXV4DQphPWNhbmRpZGF0ZTowIDEgVURQIDIxMTM2NjczMjcg MTk4LjUxLjEwMC43IDYzMTMwIHR5cCBob3N0DQphPWNhbmRpZGF0ZToxIDEgVURQIDE2OTQzMDIy MDcgMjAzLjAuMTEzLjc3IDYzMTMwIHR5cCBzcmZseCByYWRkciANCjE5OC41MS4xMDAuNyBycG9y dCA2MzEzMA0KYT1ydGNwLWZiOjEyMCBuYWNrIHBsaQ0KYT1ydGNwLWZiOjEyMCBjY20gZmlyDQoN Ci9hDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpy dGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Sun Dec 3 07:24:47 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A611242EA for ; Sun, 3 Dec 2017 07:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSAhQ7KE48Kq for ; Sun, 3 Dec 2017 07:24:41 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15B112009C for ; Sun, 3 Dec 2017 07:24:40 -0800 (PST) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 71A2224A45; Sun, 3 Dec 2017 10:24:36 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp27.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1A6FC24941; Sun, 3 Dec 2017 10:24:35 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sun, 03 Dec 2017 10:24:36 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> Date: Sun, 3 Dec 2017 08:24:33 -0700 Cc: RTCWeb IETF , draft-ietf-rtcweb-sdp@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3530F649-EED5-4F27-BADA-3EF9011A6AAB@iii.ca> References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 15:24:46 -0000 That's great thank you. Could you please create issues in github (and = only need one for fingerprint is broken, not every occurrence of it).=20 > On Dec 1, 2017, at 8:47 PM, Adam Roach wrote: >=20 > [as an individual] >=20 > I wrote a script that extracts the SDP from the XML source of = draft-ietf-rtcweb-sdp-08 and does some very basic syntax checks on it. = I'm posting the results here as feedback on the document to assist in = correcting the examples. Note that I have *not* performed any semantic = verification of the SDP itself, only the syntax. >=20 > Total error count: 152 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.1 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > = a=3Didentity:eyJpZHAiOnsiZG9tYWluIjoibmlpZi5odSIsInByb3RvY29sIjoiaWRwLmh0b= WwifSwiYXNzZXJ0a = W9uIjoiZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhVeUo5LmV5SmpiMjUwWlc1MGN= 5STZleUptYVc1b = lpYSndjbWx1ZENJNlczc2lZV3huYjNKcGRHaHRJam9pYzJoaExUSTFOaUlzSW1ScFoyVnpkQ0k= 2SWprek9rTXdPa = kl6T2pKR09rRXlPakF3T2pBd09qQkVPalV4T2tGRE9rUXlPalUwT2pZMU9rWTBPak5DT2pkRU9= qa3lPa1JET2pnN = E9qTXpPalV4T2pJek9qUXdPamN5T2preE9qZ3pPalZDT2pBeE9qSkdPalV3T2pjNE9qTkdJbjF= kZlN3aWFXUmxib = lJwZEhraU9pSnRhWE5wUUc1cGFXWXVhSFVpZlEuSTVQdGhKNFFDT05TOFVXd25OOUh3MEdaTDl= 3d0RBVGRrTWtFW = llmdlNVTTJ6Umd5R09WSGgzRmpnc2FPZklkRnFsNUx6azBFbndVOTNQOUlCQ0xZOWtia3V1c0V= 1S25YRGVNLTNIN = WFmdTJvZl9CTlZjUnB3MmdBdlNBbVR6SlltcEpqMFEtdmV0TmtVT1huZE9HLUIzT3ZGb3QwZVN= ENlZSNUdhb2wyc = GduS3FSTktOd3dacEZ1eUZZbFRodHJIdGNiT19WV3o4QnZpTThKS25OdExWd1JxNUhMX2ZLTlR= CNzFDYkoyWmh5W = XU1UEdwWDhXcXJMWC1ybm5YSFY3RnhoTTh5OHdrLWd5cnRZazVnbFlZeUFrcTVqZklSXzRzWER= 5d19Qc1BWTW1aZ = XltenVGV3BQTzVFWlJYR0ZpRjFET0o4Q0Q3Z3Zta2dUdlBXSWpkemtBIn0=3D >=20 > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:60065 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2122194687 192.0.2.4 61667 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 60065 typ srflx raddr = 192.0.2.4 rport 61667 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.1 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > = a=3Didentity:ew0KICAiaWRwIjp7DQogICAgImRvbWFpbiI6ICJjaXNjb3NwYXJrLmNvbSIsD= QogICAg = InByb3RvY29sIjogImRlZmF1bHQiDQogIH0sDQogICJhc3NlcnRpb24iOiAibEp3WkVocmFVOX= BTblJo = V0U1d1VVYzFjR0ZYV1hWaFNGVnBabEV1U1RWUWRHaEtORkZEVDA1VE9GVlhkMjVPT1VoM01FZG= FURGwz = ZDBSQlZHUnJUV3RGVw0KICAgICAgICAgICAgICBsbG1kbE5WVFRKNlVtZDVSMDlXU0dnelJtcG= 5jMkZQ = Wmtsa1JuRnNOVXg2YXpCRmJuZFZPVE5RT1VsQ1EweFpPV3RpYTNWMWMwVjFTMjVZUkdWTkxUTk= lODQog = ICAgICAgICAgICAgIFdGbWRUSnZabDlDVGxaalVuQjNNbWRCZGxOQmJWUjZTbGx0Y0VwcU1GRX= RkbVYw = VG10VlQxaHVaRTlITFVJelQzWkdiM1F3WlZORU5sWlNOVWRoYjJ3eWMNCiAgICAgICAgICAgIC= AgR2R1 = UzNGU1RrdE9kM2RhY0VaMWVVWlpiRlJvZEhKSWRHTmlUMTlXVjNvNFFuWnBUVGhLUzI1T2RFeF= dkMUp4 TlVoTVgyWkxUbFJDTnpGRFlrb3lXbWg1VyINCn0=3D >=20 > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:05067423 > a=3Dice-pwd:1747d1ee3474a28a397a4c3f3af08a068 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.2.1 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 99 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.2.1 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=3Dcandidate:1 1 UDP 565689203 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 99 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.2.2 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2122194687 = 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 99 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.2.2 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=3Dcandidate:0 1 UDP 3618095783 2001:DB8:30c:1266:5916:3779:22f6:77f7 = 49203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 99 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.3 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE data > a=3Dice-options:trickle > m=3Dapplication 54609 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsendrecv > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.3 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE data > m=3Dapplication 49203 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsendrecv > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.4 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.4 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dinactive > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 49203 typ srflx raddr = 198.51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.5 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio dtmf > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 126 > c=3DIN IP4 203.0.113.141 > a=3Dmid:dtmf > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:126 telephone-event/8000 > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.5 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio dtmf > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 126 > c=3DIN IP4 203.0.113.77 > a=3Dmid:dtmf > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:126 telephone-event/8000 > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.6 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 203.0.113.141 54609 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:120 VP8/90000 > a=3Dcontent:slides > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.6 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 203.0.113.77 49203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:120 VP8/90000 > a=3Dcontent:slides > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.7 SDP Offer w/BUNDLE > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:54610 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2122194687 192.0.2.4 61666 typ host > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 54610 typ srflx raddr = 192.0.2.4 rport 61666 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 62537 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Dice-ufrag:6550074c > a=3Dice-pwd:74af08a068a28a397a4c3f31747d1ee34 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:2 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:62538 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61886 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 62537 typ srflx raddr = 192.0.2.4 rport 61886 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 2122194687 192.0.2.4 61888 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 62538 typ srflx raddr = 192.0.2.4 rport 61888 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.8 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video data > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmsid:ma ta > a=3Dmid:audio > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 54609 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.8 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video data > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmsid:ma ta > a=3Dmid:audio > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 49203 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.10 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 54609 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 10000 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv > a=3Dsetup:actpass > a=3Dice-ufrag:89819013 > a=3Dice-pwd:1747d1ee3474af08a068a28a397a4c3f3 > a=3Dfingerprint:sha-256 = 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 10000 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.10 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 20000 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:active > a=3Dsendrecv > a=3Dice-ufrag:991Ca2a5e > a=3Dice-pwd:921d5d47efbabd9a2de4e99bd291c325 > a=3Dfingerprint:sha-256 = 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: = DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 20000 typ host > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.11 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.10 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.11 SDP Updated Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 1 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.2.11 SDP Updated Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 1 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.1 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 m2 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:98 VP8/90000 > a=3Dfmtp:98 max-fr=3D30 > a=3Drtpmap:100 VP8/90000 > a=3Dfmtp:100 max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 send pt=3D98;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 send pt=3D100;max-width=3D640;max-height=3D480; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 1;~2 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 101 102 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m2 > a=3Dmsid:ma tc > a=3Dsendonly > a=3Drtpmap:101 H264/90000 > a=3Drtpmap:102 H264/90000 > a=3Dfmtp:101 profile-level-id=3D42401f;packetization-mode=3D0;max-fr=3D3= 0 > a=3Dfmtp:102 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D1= 5 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:3 send pt=3D101;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:4 send pt=3D102;max-width=3D640;max-height=3D360; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 3;4 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.1 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 m2 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 98 100 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Dfmtp:98 max-fr=3D30 > a=3Dfmtp:100 max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 recv pt=3D98;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 recv pt=3D100;max-width=3D640;max-height=3D480; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 1;2 > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 101 102 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m2 > a=3Dmsid:ma tc > a=3Drecvonly > a=3Drtpmap:101 H264/90000 > a=3Drtpmap:102 H264/90000 > a=3Dfmtp:101 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D3= 0 > a=3Dfmtp:102 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D1= 5 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:3 recv pt=3D101;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:4 recv pt=3D102;max-width=3D640;max-height=3D360; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 3;4 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.2 SDP Offer with SVC > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 96 97 100 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 profile-level-id=3D4d0028; = packetization-mode=3D1;max-fr=3D30;max-fs=3D8040 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1; = max-fr=3D15;max-fs=3D1200 > a=3Drtpmap:100 H264-SVC/90000 > a=3Dfmtp:100 profile-level-id=3D4d0028;packetization-mode=3D1; = max-fr=3D30;max-fs=3D8040 > a=3Ddepend:100 lay m1:96,97 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.2 SDP Answer with SVC > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302206 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 96 100 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 profile-level-id=3D4d0028;packetization-mode=3D1; = max-fr=3D30;max-fs=3D8040 > a=3Drtpmap:100 H264-SVC/90000 > a=3Dfmtp:100 profile-level-id=3D4d0028;packetization-mode=3D1; = max-fr=3D30;max-fs=3D8040 > a=3Ddepend:100 lay m1:96 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.5 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Drtcp-mux > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:101 flexfec/90000 > a=3Drtpmap:103 flexfec/90000 > a=3Dfmtp:98 max-fr=3D30;max-fs=3D8040 > a=3Dfmtp:100 max-fr=3D15;max-fs=3D1200 > a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 send pt=3D98; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 send pt=3D100; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 1;2 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.3.5 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302206 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:101 flexfec/90000 > a=3Drtpmap:103 flexfec/90000 > a=3Dfmtp:98 max-fr=3D30;max-fs=3D8040 > a=3Dfmtp:100 max-fr=3D15;max-fs=3D1200 > a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 = urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 recv pt=3D98; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 recv pt=3D100; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 1;2 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.1 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.1 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.2 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr = 192.0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.2 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 > a=3Dend-of-candidates >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.3 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Drtcp:60065 IN IP4 203.0.113.141 > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:ufrag:c300d85b >=20 > *** ERROR: invalid syntax for 'ice-ufrag' > *** Note: Removing errant 'ufrag:' fixes this. >=20 > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 = :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2113667326 198.51.100.7 51558 typ host > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.77 60065 typ srflx raddr = 198.51.100.7 rport 51558 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.5 SDP Offer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Drtcp-rsize > m=3Daudio 54732 RTP/AVP 109 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.141 > a=3Dfingerprint:sha-256 = 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 = :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtpmap:109 opus/48000 > a=3Dptime:20 > a=3Dsendrecv > a=3Drtcp-mux > a=3Drtcp:64678 IN IP4 203.0.113.141 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 54732 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54732 typ srflx raddr = 192.0.2.4 rport 54732 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2113667326 192.0.2.4 64678 typ host > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.141 64678 typ srflx raddr = 192.0.2.4 rport 64678 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 62445 RTP/AVP 120 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.141 > a=3Dfingerprint:sha-256 = DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 = :6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtpmap:120 VP8/90000 > a=3Dsendrecv > a=3Drtcp-mux > a=3Drtcp:54721 IN IP4 203.0.113.141 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 62445 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.141 62537 typ srflx raddr = 192.0.2.4 rport 62445 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 2113667326 192.0.2.4 54721 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.141 54721 typ srflx raddr = 192.0.2.4 rport 54721 > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 5.4.5 SDP Answer > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > m=3Daudio 49203 RTP/AVP 109 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.77 > a=3Drtpmap:109 opus/48000 > a=3Dptime:20 > a=3Dsendrecv > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 = :19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtcp-mux > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr = 198.51.100.7 rport 49203 > m=3Dvideo 63130 RTP/SAVP 120 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.77 > a=3Drtpmap:120 VP8/90000 > a=3Dsendrecv > a=3Dice-ufrag:e39091na > a=3Dice-pwd:dbc325921d5dd29e4e99147efbabd9a2 > a=3Dfingerprint:sha-256 = BB:0A9:0E:05:E9:26:33:E8:70:88:A25:2F:70:9F:04: = :19:E2:1C:3B:4B:9F:81:5:2F:70:9F:04::F4:A5:A8:D8: >=20 > *** ERROR: invalid syntax for 'fingerprint' (there's too much wrong = here to enumerate) >=20 > a=3Drtcp-mux > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 63130 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 63130 typ srflx raddr = 198.51.100.7 rport 63130 > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir >=20 > /a >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Dec 3 10:04:54 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDCE124D85 for ; Sun, 3 Dec 2017 10:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJPFMEd0lUws for ; Sun, 3 Dec 2017 10:04:45 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04CF127010 for ; Sun, 3 Dec 2017 10:04:44 -0800 (PST) X-AuditID: c1b4fb30-ca9ff700000029e3-e3-5a243cbadcbe Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.11.10723.ABC342A5; Sun, 3 Dec 2017 19:04:42 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Sun, 3 Dec 2017 19:04:42 +0100 From: Christer Holmberg To: Cullen Jennings , Adam Roach CC: RTCWeb IETF , "draft-ietf-rtcweb-sdp@tools.ietf.org" Thread-Topic: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp Thread-Index: AQHTayJhmBFuBmiUPUGn/k7cmaR5PKMxrpuAgAA9b4A= Date: Sun, 3 Dec 2017 18:04:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0377F6@ESESSMB109.ericsson.se> References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> <3530F649-EED5-4F27-BADA-3EF9011A6AAB@iii.ca> In-Reply-To: <3530F649-EED5-4F27-BADA-3EF9011A6AAB@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7lO4uG5Uog9N/1S32/F3EbvGv8wmj xYf1Pxgt1v5rZ3dg8Viy5CeTx+XzHxk9Zu18wuLx5fJntgCWKC6blNSczLLUIn27BK6MC9de Mxa86GCt+L/9FHsD4+KtLF2MnBwSAiYS/6Z/B7K5OIQEDjNKnHi6kgnCWcwo8X3pR9YuRg4O NgELie5/2iANIgJOEu1PXzGD2MwCRRLXt21jB7GFBWwkTl9ZxApRYyuxbN8uZgjbSqLx3mMW kDEsAioSTZ+DQMK8Ar4SXQ9vs4HYQgJ5Ejv+TmUEsTmBym/v2QUWZxQQk/h+ag0TxCpxiVtP 5jNB3CwgsWTPeWYIW1Ti5eN/rBC2kkTjkiesEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMY RWchGTsLScssJC2zkLQsYGRZxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYUQe3/DbYwfjy ueMhRgEORiUe3l96KlFCrIllxZW5hxglOJiVRHhdRYFCvCmJlVWpRfnxRaU5qcWHGKU5WJTE eU968kYJCaQnlqRmp6YWpBbBZJk4OKUaGE3rblxOErvi6/Dq8sxzft2a9Zdn5OxqLlvZecy4 b8+mkjSD011brwR9CpW9V7puge0Bben7Ua/Zp6n/Kl53R9M0kmkW92Pb1KTjuYITz78VYdnd 9vMXo/J9Rpv1u4tOPHFvqHX0Waz/XjCK+4JYzq7VlXP6trt+tq37za7lvOBA3mPemI1G7kos xRmJhlrMRcWJAHvale6kAgAA Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 18:04:52 -0000 Do you have the link to the GitHub repo? Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 03 December 2017 17:25 To: Adam Roach Cc: RTCWeb IETF ; draft-ietf-rtcweb-sdp@tools.ietf.org Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp That's great thank you. Could you please create issues in github (and only = need one for fingerprint is broken, not every occurrence of it).=20 > On Dec 1, 2017, at 8:47 PM, Adam Roach wrote: >=20 > [as an individual] >=20 > I wrote a script that extracts the SDP from the XML source of draft-ietf-= rtcweb-sdp-08 and does some very basic syntax checks on it. I'm posting the= results here as feedback on the document to assist in correcting the examp= les. Note that I have *not* performed any semantic verification of the SDP = itself, only the syntax. >=20 > Total error count: 152 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.1 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > a=3Didentity:eyJpZHAiOnsiZG9tYWluIjoibmlpZi5odSIsInByb3RvY29sIjoiaWRwLmh0= bWwifSwiYXNzZXJ0a W9uIjoiZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhVeUo5Lm= V5SmpiMjUwWlc1MGN5STZleUptYVc1b lpYSndjbWx1ZENJNlczc2lZV3huYjNKcGRHaHRJam9p= YzJoaExUSTFOaUlzSW1ScFoyVnpkQ0k2SWprek9rTXdPa kl6T2pKR09rRXlPakF3T2pBd09qQk= VPalV4T2tGRE9rUXlPalUwT2pZMU9rWTBPak5DT2pkRU9qa3lPa1JET2pnN E9qTXpPalV4T2pJ= ek9qUXdPamN5T2preE9qZ3pPalZDT2pBeE9qSkdPalV3T2pjNE9qTkdJbjFkZlN3aWFXUmxib l= JwZEhraU9pSnRhWE5wUUc1cGFXWXVhSFVpZlEuSTVQdGhKNFFDT05TOFVXd25OOUh3MEdaTDl3d= 0RBVGRrTWtFW llmdlNVTTJ6Umd5R09WSGgzRmpnc2FPZklkRnFsNUx6azBFbndVOTNQOUlCQ0x= ZOWtia3V1c0V1S25YRGVNLTNIN WFmdTJvZl9CTlZjUnB3MmdBdlNBbVR6SlltcEpqMFEtdmV0T= mtVT1huZE9HLUIzT3ZGb3QwZVNENlZSNUdhb2wyc GduS3FSTktOd3dacEZ1eUZZbFRodHJIdGN= iT19WV3o4QnZpTThKS25OdExWd1JxNUhMX2ZLTlRCNzFDYkoyWmh5W XU1UEdwWDhXcXJMWC1yb= m5YSFY3RnhoTTh5OHdrLWd5cnRZazVnbFlZeUFrcTVqZklSXzRzWER5d19Qc1BWTW1aZ XltenV= GV3BQTzVFWlJYR0ZpRjFET0o4Q0Q3Z3Zta2dUdlBXSWpkemtBIn0=3D >=20 > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:60065 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2122194687 192.0.2.4 61667 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 60065 typ srflx raddr 192= .0.2.4 rport 61667 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.1 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > a=3Didentity:ew0KICAiaWRwIjp7DQogICAgImRvbWFpbiI6ICJjaXNjb3NwYXJrLmNvbSIs= DQogICAg InByb3RvY29sIjogImRlZmF1bHQiDQogIH0sDQogICJhc3NlcnRpb24iOiAibEp3Wk= VocmFVOXBTblJo V0U1d1VVYzFjR0ZYV1hWaFNGVnBabEV1U1RWUWRHaEtORkZEVDA1VE9GVlhk= MjVPT1VoM01FZGFURGwz ZDBSQlZHUnJUV3RGVw0KICAgICAgICAgICAgICBsbG1kbE5WVFRKNl= VtZDVSMDlXU0dnelJtcG5jMkZQ Wmtsa1JuRnNOVXg2YXpCRmJuZFZPVE5RT1VsQ1EweFpPV3Rp= YTNWMWMwVjFTMjVZUkdWTkxUTklODQog ICAgICAgICAgICAgIFdGbWRUSnZabDlDVGxaalVuQj= NNbWRCZGxOQmJWUjZTbGx0Y0VwcU1GRXRkbVYw VG10VlQxaHVaRTlITFVJelQzWkdiM1F3WlZO= RU5sWlNOVWRoYjJ3eWMNCiAgICAgICAgICAgICAgR2R1 UzNGU1RrdE9kM2RhY0VaMWVVWlpiRl= JvZEhKSWRHTmlUMTlXVjNvNFFuWnBUVGhLUzI1T2RFeFdkMUp4 TlVoTVgyWkxUbFJDTnpGRFlr= b3lXbWg1VyINCn0=3D >=20 > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:05067423 > a=3Dice-pwd:1747d1ee3474a28a397a4c3f3af08a068 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.2.1 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 99 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.2.1 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=3Dcandidate:1 1 UDP 565689203 203.0.113.77 49203 typ srflx raddr 198.51= .100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 99 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.2.2 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2122194687 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 = 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 99 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.2.2 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=3Dcandidate:0 1 UDP 3618095783 2001:DB8:30c:1266:5916:3779:22f6:77f7 49= 203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 99 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:99 H264/90000 > a=3Dfmtp:99 profile-level-id=3D4d0028;packetization-mode=3D1 > a=3Drtcp-fb:99 nack > a=3Drtcp-fb:99 nack pli > a=3Drtcp-fb:99 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.3 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE data > a=3Dice-options:trickle > m=3Dapplication 54609 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsendrecv > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.3 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE data > m=3Dapplication 49203 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsendrecv > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.4 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.4 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dinactive > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 49203 typ srflx raddr 198= .51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.5 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio dtmf > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 126 > c=3DIN IP4 203.0.113.141 > a=3Dmid:dtmf > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:126 telephone-event/8000 > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.5 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio dtmf > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 126 > c=3DIN IP4 203.0.113.77 > a=3Dmid:dtmf > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:126 telephone-event/8000 > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.6 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 203.0.113.141 54609 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:120 VP8/90000 > a=3Dcontent:slides > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.6 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 203.0.113.77 49203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:120 VP8/90000 > a=3Dcontent:slides > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.7 SDP Offer w/BUNDLE > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:54610 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2122194687 192.0.2.4 61666 typ host > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 54610 typ srflx raddr 192= .0.2.4 rport 61666 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 62537 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Dice-ufrag:6550074c > a=3Dice-pwd:74af08a068a28a397a4c3f31747d1ee34 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:2 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp:62538 IN IP4 203.0.113.141 > a=3Drtcp-rsize > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61886 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 62537 typ srflx raddr 192= .0.2.4 rport 61886 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 2122194687 192.0.2.4 61888 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1685987071 203.0.113.141 62538 typ srflx raddr 192.= 0.2.4 rport 61888 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.8 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video data > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmsid:ma ta > a=3Dmid:audio > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.141 54609 typ srflx raddr 192= .0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 54609 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.8 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video data > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmsid:ma ta > a=3Dmid:audio > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 49203 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.10 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 54609 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 10000 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.141 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsendrecv > a=3Dsetup:actpass > a=3Dice-ufrag:89819013 > a=3Dice-pwd:1747d1ee3474af08a068a28a397a4c3f3 > a=3Dfingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: = BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 10000 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.10 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=3Dapplication 20000 UDP/DTLS/SCTP webrtc-datachannel > c=3DIN IP4 203.0.113.77 > a=3Dmid:data > a=3Dsctp-port:5000 > a=3Dmax-message-size:100000 > a=3Dsetup:active > a=3Dsendrecv > a=3Dice-ufrag:991Ca2a5e > a=3Dice-pwd:921d5d47efbabd9a2de4e99bd291c325 > a=3Dfingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: = DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 20000 typ host > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.11 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.10 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.11 SDP Updated Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 1 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 54609 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.141 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.2.11 SDP Updated Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 1 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio video > a=3Dgroup:LS audio video > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-mux-only > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 120 > c=3DIN IP4 203.0.113.77 > a=3Dmid:video > a=3Dmsid:ma tb > a=3Dsendrecv > a=3Drtpmap:120 VP8/90000 > a=3Drtcp-fb:120 nack > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.1 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 m2 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:98 VP8/90000 > a=3Dfmtp:98 max-fr=3D30 > a=3Drtpmap:100 VP8/90000 > a=3Dfmtp:100 max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 send pt=3D98;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 send pt=3D100;max-width=3D640;max-height=3D480; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 1;~2 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 101 102 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m2 > a=3Dmsid:ma tc > a=3Dsendonly > a=3Drtpmap:101 H264/90000 > a=3Drtpmap:102 H264/90000 > a=3Dfmtp:101 profile-level-id=3D42401f;packetization-mode=3D0;max-fr=3D30 > a=3Dfmtp:102 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:3 send pt=3D101;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:4 send pt=3D102;max-width=3D640;max-height=3D360; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 3;4 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.1 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 m2 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 98 100 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Dfmtp:98 max-fr=3D30 > a=3Dfmtp:100 max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 recv pt=3D98;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 recv pt=3D100;max-width=3D640;max-height=3D480; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 1;2 > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 101 102 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m2 > a=3Dmsid:ma tc > a=3Drecvonly > a=3Drtpmap:101 H264/90000 > a=3Drtpmap:102 H264/90000 > a=3Dfmtp:101 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D30 > a=3Dfmtp:102 profile-level-id=3D42401f;packetization-mode=3D1;max-fr=3D15 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:3 recv pt=3D101;max-width=3D1280;max-height=3D720; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:4 recv pt=3D102;max-width=3D640;max-height=3D360; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 3;4 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.2 SDP Offer with SVC > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 96 97 100 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 profile-level-id=3D4d0028; packetization-mode=3D1;max-fr=3D30= ;max-fs=3D8040 > a=3Drtpmap:97 H264/90000 > a=3Dfmtp:97 profile-level-id=3D4d0028;packetization-mode=3D1; max-fr=3D15= ;max-fs=3D1200 > a=3Drtpmap:100 H264-SVC/90000 > a=3Dfmtp:100 profile-level-id=3D4d0028;packetization-mode=3D1; max-fr=3D3= 0;max-fs=3D8040 > a=3Ddepend:100 lay m1:96,97 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.2 SDP Answer with SVC > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302206 203.0.113.77 49203 typ srflx raddr 198.= 51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 96 100 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:96 H264/90000 > a=3Dfmtp:96 profile-level-id=3D4d0028;packetization-mode=3D1; max-fr=3D30= ;max-fs=3D8040 > a=3Drtpmap:100 H264-SVC/90000 > a=3Dfmtp:100 profile-level-id=3D4d0028;packetization-mode=3D1; max-fr=3D3= 0;max-fs=3D8040 > a=3Ddepend:100 lay m1:96 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.5 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Dsendonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Drtcp-mux > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=3DIN IP4 203.0.113.141 > a=3Dbundle-only > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Dsendonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:101 flexfec/90000 > a=3Drtpmap:103 flexfec/90000 > a=3Dfmtp:98 max-fr=3D30;max-fs=3D8040 > a=3Dfmtp:100 max-fr=3D15;max-fs=3D1200 > a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 send pt=3D98; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 send pt=3D100; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:send 1;2 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.3.5 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE m0 m1 > a=3Dgroup:LS m0 m1 > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m0 > a=3Dmsid:ma ta > a=3Drecvonly > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302206 203.0.113.77 49203 typ srflx raddr 198.= 51.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates > m=3Dvideo 49203 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=3DIN IP4 203.0.113.77 > a=3Dmid:m1 > a=3Dmsid:ma tb > a=3Drecvonly > a=3Drtpmap:98 VP8/90000 > a=3Drtpmap:100 VP8/90000 > a=3Drtpmap:101 flexfec/90000 > a=3Drtpmap:103 flexfec/90000 > a=3Dfmtp:98 max-fr=3D30;max-fs=3D8040 > a=3Dfmtp:100 max-fr=3D15;max-fs=3D1200 > a=3Dfmtp:101 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Dfmtp:103 L=3D5; D=3D10; ToP=3D2; repair-window=3D200000 > a=3Drtcp-fb:* nack > a=3Drtcp-fb:* nack pli > a=3Drtcp-fb:* ccm fir > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:3 a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id >=20 > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=3D' fixes this. >=20 > a=3Drid:1 recv pt=3D98; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Drid:2 recv pt=3D100; >=20 > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. >=20 > a=3Dsimulcast:recv 1;2 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.1 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:8 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.1 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.2 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=3DIN IP4 203.0.113.141 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:actpass > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dextmap:3 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54609 typ srflx raddr 192.= 0.2.4 rport 61665 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.2 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dgroup:BUNDLE audio > a=3Dice-options:trickle > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=3DIN IP4 203.0.113.77 > a=3Dmid:audio > a=3Dmsid:ma ta > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Drtpmap:0 PCMU/8000 > a=3Drtpmap:0 PCMA/8000 > a=3Dmaxptime:120 > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Dtls-id:1 >=20 > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. >=20 > a=3Drtcp-mux > a=3Drtcp-rsize > a=3Drtcp-fb:* nack > a=3Dextmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 > a=3Dend-of-candidates >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.3 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20519 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > m=3Daudio 49203 UDP/TLS/RTP/SAVPF 109 > c=3DIN IP4 203.0.113.141 > a=3Drtcp:60065 IN IP4 203.0.113.141 > a=3Dsendrecv > a=3Drtpmap:109 opus/48000/2 > a=3Dmaxptime:120 > a=3Dice-ufrag:ufrag:c300d85b >=20 > *** ERROR: invalid syntax for 'ice-ufrag' > *** Note: Removing errant 'ufrag:' fixes this. >=20 > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 := DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dsetup:active > a=3Drtcp-rsize > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 51556 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2113667326 198.51.100.7 51558 typ host > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.77 60065 typ srflx raddr 198.= 51.100.7 rport 51558 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 > m=3Dvideo 0 UDP/TLS/RTP/SAVPF 98 100 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.5 SDP Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 20518 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > a=3Dice-ufrag:074c6550 > a=3Dice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=3Drtcp-rsize > m=3Daudio 54732 RTP/AVP 109 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.141 > a=3Dfingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 := BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtpmap:109 opus/48000 > a=3Dptime:20 > a=3Dsendrecv > a=3Drtcp-mux > a=3Drtcp:64678 IN IP4 203.0.113.141 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 54732 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 694302207 203.0.113.141 54732 typ srflx raddr 192.= 0.2.4 rport 54732 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 UDP 2113667326 192.0.2.4 64678 typ host > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.141 64678 typ srflx raddr 192= .0.2.4 rport 64678 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > m=3Dvideo 62445 RTP/AVP 120 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.141 > a=3Dfingerprint:sha-256 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 := 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtpmap:120 VP8/90000 > a=3Dsendrecv > a=3Drtcp-mux > a=3Drtcp:54721 IN IP4 203.0.113.141 > a=3Dcandidate:0 1 UDP 2113667327 192.0.2.4 62445 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.141 62537 typ srflx raddr 192= .0.2.4 rport 62445 >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Dcandidate:0 2 2113667326 192.0.2.4 54721 typ host >=20 > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. >=20 > a=3Dcandidate:1 2 UDP 1694302206 203.0.113.141 54721 typ srflx raddr 192.= 0.2.4 rport 54721 > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 5.4.5 SDP Answer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > v=3D0 > o=3D- 16833 0 IN IP4 0.0.0.0 > s=3D- > t=3D0 0 > m=3Daudio 49203 RTP/AVP 109 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.77 > a=3Drtpmap:109 opus/48000 > a=3Dptime:20 > a=3Dsendrecv > a=3Dice-ufrag:c300d85b > a=3Dice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=3Dfingerprint:sha-256 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 := 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 >=20 > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. >=20 > a=3Drtcp-mux > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr 198.5= 1.100.7 rport 49203 > m=3Dvideo 63130 RTP/SAVP 120 >=20 > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. >=20 > c=3DIN IP4 203.0.113.77 > a=3Drtpmap:120 VP8/90000 > a=3Dsendrecv > a=3Dice-ufrag:e39091na > a=3Dice-pwd:dbc325921d5dd29e4e99147efbabd9a2 > a=3Dfingerprint:sha-256 BB:0A9:0E:05:E9:26:33:E8:70:88:A25:2F:70:9F:04: := 19:E2:1C:3B:4B:9F:81:5:2F:70:9F:04::F4:A5:A8:D8: >=20 > *** ERROR: invalid syntax for 'fingerprint' (there's too much wrong here = to enumerate) >=20 > a=3Drtcp-mux > a=3Dcandidate:0 1 UDP 2113667327 198.51.100.7 63130 typ host > a=3Dcandidate:1 1 UDP 1694302207 203.0.113.77 63130 typ srflx raddr 198.5= 1.100.7 rport 63130 > a=3Drtcp-fb:120 nack pli > a=3Drtcp-fb:120 ccm fir >=20 > /a >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Dec 3 12:23:00 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10AA127011 for ; Sun, 3 Dec 2017 12:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTZz_hcrFkh0 for ; Sun, 3 Dec 2017 12:22:50 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D62126D85 for ; Sun, 3 Dec 2017 12:22:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 332A07C320C; Sun, 3 Dec 2017 21:22:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfP_zOGFlak4; Sun, 3 Dec 2017 21:22:42 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id A5EC57C045D; Sun, 3 Dec 2017 21:22:42 +0100 (CET) To: Adam Roach , "rtcweb@ietf.org" Cc: draft-ietf-rtcweb-sdp@tools.ietf.org References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> From: Harald Alvestrand Message-ID: <4615d633-dfc8-4ce5-593e-5c996046cecf@alvestrand.no> Date: Sun, 3 Dec 2017 21:22:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 20:22:58 -0000 Great to see attention on this! Nils Ohlmeier also wrote an extraction script (https://github.com/nils-ohlmeier/sdpextractor - I have suggested a PR that changes the file name format), do you want to publish yours too? One of my "really want to do this some day" projects is to extract the SDP examples and throw them at Chrome to see that at least the parser doesn't blow up on them. Harald Den 02. des. 2017 04:47, skrev Adam Roach: > [as an individual] > > I wrote a script that extracts the SDP from the XML source of > draft-ietf-rtcweb-sdp-08 and does some very basic syntax checks on it. > I'm posting the results here as feedback on the document to assist in > correcting the examples. Note that I have *not* performed any semantic > verification of the SDP itself, only the syntax. > > Total error count: 152 > > ============================================================================== > > 5.2.1 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > a=identity:eyJpZHAiOnsiZG9tYWluIjoibmlpZi5odSIsInByb3RvY29sIjoiaWRwLmh0bWwifSwiYXNzZXJ0a > W9uIjoiZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhVeUo5LmV5SmpiMjUwWlc1MGN5STZleUptYVc1b > lpYSndjbWx1ZENJNlczc2lZV3huYjNKcGRHaHRJam9pYzJoaExUSTFOaUlzSW1ScFoyVnpkQ0k2SWprek9rTXdPa > kl6T2pKR09rRXlPakF3T2pBd09qQkVPalV4T2tGRE9rUXlPalUwT2pZMU9rWTBPak5DT2pkRU9qa3lPa1JET2pnN > E9qTXpPalV4T2pJek9qUXdPamN5T2preE9qZ3pPalZDT2pBeE9qSkdPalV3T2pjNE9qTkdJbjFkZlN3aWFXUmxib > lJwZEhraU9pSnRhWE5wUUc1cGFXWXVhSFVpZlEuSTVQdGhKNFFDT05TOFVXd25OOUh3MEdaTDl3d0RBVGRrTWtFW > llmdlNVTTJ6Umd5R09WSGgzRmpnc2FPZklkRnFsNUx6azBFbndVOTNQOUlCQ0xZOWtia3V1c0V1S25YRGVNLTNIN > WFmdTJvZl9CTlZjUnB3MmdBdlNBbVR6SlltcEpqMFEtdmV0TmtVT1huZE9HLUIzT3ZGb3QwZVNENlZSNUdhb2wyc > GduS3FSTktOd3dacEZ1eUZZbFRodHJIdGNiT19WV3o4QnZpTThKS25OdExWd1JxNUhMX2ZLTlRCNzFDYkoyWmh5W > XU1UEdwWDhXcXJMWC1ybm5YSFY3RnhoTTh5OHdrLWd5cnRZazVnbFlZeUFrcTVqZklSXzRzWER5d19Qc1BWTW1aZ > XltenVGV3BQTzVFWlJYR0ZpRjFET0o4Q0Q3Z3Zta2dUdlBXSWpkemtBIn0= > > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. > > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp:60065 IN IP4 203.0.113.141 > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 UDP  2122194687 192.0.2.4 61667 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 2 UDP  1685987071 203.0.113.141 60065 typ srflx raddr > 192.0.2.4 rport 61667 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.2.1 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > a=identity:ew0KICAiaWRwIjp7DQogICAgImRvbWFpbiI6ICJjaXNjb3NwYXJrLmNvbSIsDQogICAg > InByb3RvY29sIjogImRlZmF1bHQiDQogIH0sDQogICJhc3NlcnRpb24iOiAibEp3WkVocmFVOXBTblJo > V0U1d1VVYzFjR0ZYV1hWaFNGVnBabEV1U1RWUWRHaEtORkZEVDA1VE9GVlhkMjVPT1VoM01FZGFURGwz > ZDBSQlZHUnJUV3RGVw0KICAgICAgICAgICAgICBsbG1kbE5WVFRKNlVtZDVSMDlXU0dnelJtcG5jMkZQ > Wmtsa1JuRnNOVXg2YXpCRmJuZFZPVE5RT1VsQ1EweFpPV3RpYTNWMWMwVjFTMjVZUkdWTkxUTklODQog > ICAgICAgICAgICAgIFdGbWRUSnZabDlDVGxaalVuQjNNbWRCZGxOQmJWUjZTbGx0Y0VwcU1GRXRkbVYw > VG10VlQxaHVaRTlITFVJelQzWkdiM1F3WlZORU5sWlNOVWRoYjJ3eWMNCiAgICAgICAgICAgICAgR2R1 > UzNGU1RrdE9kM2RhY0VaMWVVWlpiRlJvZEhKSWRHTmlUMTlXVjNvNFFuWnBUVGhLUzI1T2RFeFdkMUp4 > TlVoTVgyWkxUbFJDTnpGRFlrb3lXbWg1VyINCn0= > > *** ERROR: invalid syntax for 'identity' > *** Note: Removing errant spaces fixes this problem. > > m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:05067423 > a=ice-pwd:1747d1ee3474a28a397a4c3f3af08a068 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > > ============================================================================== > > 5.2.2.1 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: > BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 99 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:120 VP8/90000 > a=rtcp-fb:99 nack > a=rtcp-fb:99 nack pli > a=rtcp-fb:99 ccm fir > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.2.1 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=candidate:1 1 UDP 565689203 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 99 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 > a=rtcp-fb:99 nack > a=rtcp-fb:99 nack pli > a=rtcp-fb:99 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.2.2 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: > BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 1 UDP  2122194687 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 > 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 99 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 > a=rtpmap:120 VP8/90000 > a=rtcp-fb:99 nack > a=rtcp-fb:99 nack pli > a=rtcp-fb:99 ccm fir > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.2.2 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 3618095783 198.51.100.7 49203 typ host > a=candidate:0 1 UDP 3618095783 2001:DB8:30c:1266:5916:3779:22f6:77f7 > 49203 typ host > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 99 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 > a=rtcp-fb:99 nack > a=rtcp-fb:99 nack pli > a=rtcp-fb:99 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.3 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE data > a=ice-options:trickle > m=application 54609 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.141 > a=mid:data > a=sendrecv > a=sctp-port:5000 > a=max-message-size:100000 > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 1 UDP 2113667327 192.0.2.4 61665 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > a=end-of-candidates > > ============================================================================== > > 5.2.3 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE data > m=application 49203 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.77 > a=mid:data > a=sendrecv > a=sctp-port:5000 > a=max-message-size:100000 > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > > ============================================================================== > > 5.2.4 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.2.4 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=inactive > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 198.51.100.7 51556 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 49203 typ srflx raddr > 198.51.100.7 rport 51556 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.2.5 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio dtmf > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=audio 54609 UDP/TLS/RTP/SAVPF 126 > c=IN IP4 203.0.113.141 > a=mid:dtmf > a=msid:ma tb > a=sendonly > a=rtpmap:126 telephone-event/8000 > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.5 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio dtmf > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > m=audio 49203 UDP/TLS/RTP/SAVPF 126 > c=IN IP4 203.0.113.77 > a=mid:dtmf > a=msid:ma tb > a=recvonly > a=rtpmap:126 telephone-event/8000 > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.6 SDP Offer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 203.0.113.141 54609 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendonly > a=rtpmap:120 VP8/90000 > a=content:slides > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.6 SDP Answer > ============================================================================== > > v=0 > o=- 16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=recvonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 203.0.113.77 49203 typ host > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=recvonly > a=rtpmap:120 VP8/90000 > a=content:slides > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.7 SDP Offer w/BUNDLE > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp:54610 IN IP4 203.0.113.141 > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 UDP 2122194687 192.0.2.4 61666 typ host > a=candidate:1 2 UDP  1685987071 203.0.113.141 54610 typ srflx raddr > 192.0.2.4 rport 61666 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > m=video 62537 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=ice-ufrag:6550074c > a=ice-pwd:74af08a068a28a397a4c3f31747d1ee34 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:2 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp:62538 IN IP4 203.0.113.141 > a=rtcp-rsize > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61886 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 62537 typ srflx raddr > 192.0.2.4 rport 61886 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 2122194687 192.0.2.4 61888 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. > > a=candidate:1 2 UDP 1685987071 203.0.113.141 62538 typ srflx raddr > 192.0.2.4 rport 61888 > > ============================================================================== > > 5.2.8 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video data > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=msid:ma ta > a=mid:audio > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2122194687 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1685987071 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=application 54609 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.141 > a=mid:data > a=sctp-port:5000 > a=max-message-size:100000 > a=sendrecv > > ============================================================================== > > 5.2.8 SDP Answer > ============================================================================== > > v=0 > o=- 16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video data > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=msid:ma ta > a=mid:audio > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2122194687 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1685987071 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=application 49203 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.77 > a=mid:data > a=sctp-port:5000 > a=max-message-size:100000 > a=sendrecv > > ============================================================================== > > 5.2.10 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 54609 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=application 10000 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.141 > a=mid:data > a=sctp-port:5000 > a=max-message-size:100000 > a=sendrecv > a=setup:actpass > a=ice-ufrag:89819013 > a=ice-pwd:1747d1ee3474af08a068a28a397a4c3f3 > a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: > BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 1 UDP  2113667327 192.0.2.4 10000 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.2.10 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > m=application 20000 UDP/DTLS/SCTP webrtc-datachannel > c=IN IP4 203.0.113.77 > a=mid:data > a=sctp-port:5000 > a=max-message-size:100000 > a=setup:active > a=sendrecv > a=ice-ufrag:991Ca2a5e > a=ice-pwd:921d5d47efbabd9a2de4e99bd291c325 > a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: > DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 1 UDP 2113667327 198.51.100.7 20000 typ host > a=end-of-candidates > > ============================================================================== > > 5.2.11 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.2.10 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > > ============================================================================== > > 5.2.11 SDP Updated Offer > ============================================================================== > > v=0 > o=- 20518 1 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 54609 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.141 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.2.11 SDP Updated Answer > ============================================================================== > > v=0 > o=-  16833 1 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio video > a=group:LS audio video > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-mux-only > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 120 > c=IN IP4 203.0.113.77 > a=mid:video > a=msid:ma tb > a=sendrecv > a=rtpmap:120 VP8/90000 > a=rtcp-fb:120 nack > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.3.1 SDP Offer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 m2 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:m0 > a=msid:ma ta > a=sendonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 0 UDP/TLS/RTP/SAVPF 98 100 > c=IN IP4 203.0.113.141 > a=bundle-only > a=mid:m1 > a=msid:ma tb > a=sendonly > a=rtpmap:98 VP8/90000 > a=fmtp:98 max-fr=30 > a=rtpmap:100 VP8/90000 > a=fmtp:100 max-fr=15 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:1 send pt=98;max-width=1280;max-height=720; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:2 send pt=100;max-width=640;max-height=480; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:send 1;~2 > m=video 0 UDP/TLS/RTP/SAVPF 101 102 > c=IN IP4 203.0.113.141 > a=bundle-only > a=mid:m2 > a=msid:ma tc > a=sendonly > a=rtpmap:101 H264/90000 > a=rtpmap:102 H264/90000 > a=fmtp:101 profile-level-id=42401f;packetization-mode=0;max-fr=30 > a=fmtp:102 profile-level-id=42401f;packetization-mode=1;max-fr=15 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:3 send pt=101;max-width=1280;max-height=720; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:4 send pt=102;max-width=640;max-height=360; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:send 3;4 > > ============================================================================== > > 5.3.1 SDP Answer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 m2 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:m0 > a=msid:ma ta > a=recvonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 198.51.100.7 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 98 100 > c=IN IP4 203.0.113.77 > a=mid:m1 > a=msid:ma tb > a=recvonly > a=rtpmap:98 VP8/90000 > a=rtpmap:100 VP8/90000 > a=fmtp:98 max-fr=30 > a=fmtp:100 max-fr=15 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:1 recv pt=98;max-width=1280;max-height=720; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:2 recv pt=100;max-width=640;max-height=480; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:recv 1;2 > m=video 49203 UDP/TLS/RTP/SAVPF 101 102 > c=IN IP4 203.0.113.77 > a=mid:m2 > a=msid:ma tc > a=recvonly > a=rtpmap:101 H264/90000 > a=rtpmap:102 H264/90000 > a=fmtp:101 profile-level-id=42401f;packetization-mode=1;max-fr=30 > a=fmtp:102 profile-level-id=42401f;packetization-mode=1;max-fr=15 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:3 recv pt=101;max-width=1280;max-height=720; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:4 recv pt=102;max-width=640;max-height=360; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:recv 3;4 > > ============================================================================== > > 5.3.2 SDP Offer with SVC > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:m0 > a=msid:ma ta > a=sendonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 0 UDP/TLS/RTP/SAVPF 96 97 100 > c=IN IP4 203.0.113.141 > a=bundle-only > a=mid:m1 > a=msid:ma tb > a=sendonly > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=4d0028; > packetization-mode=1;max-fr=30;max-fs=8040 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=4d0028;packetization-mode=1; > max-fr=15;max-fs=1200 > a=rtpmap:100 H264-SVC/90000 > a=fmtp:100 profile-level-id=4d0028;packetization-mode=1; > max-fr=30;max-fs=8040 > a=depend:100 lay m1:96,97 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.3.2 SDP Answer with SVC > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:m0 > a=msid:ma ta > a=recvonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=candidate:1 1 UDP  1694302206 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 96 100 > c=IN IP4 203.0.113.77 > a=mid:m1 > a=msid:ma tb > a=recvonly > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=4d0028;packetization-mode=1; > max-fr=30;max-fs=8040 > a=rtpmap:100 H264-SVC/90000 > a=fmtp:100 profile-level-id=4d0028;packetization-mode=1; > max-fr=30;max-fs=8040 > a=depend:100 lay m1:96 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > ============================================================================== > > 5.3.5 SDP Offer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=mid:m0 > a=msid:ma ta > a=sendonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=rtcp-mux > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 0 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=IN IP4 203.0.113.141 > a=bundle-only > a=mid:m1 > a=msid:ma tb > a=sendonly > a=rtpmap:98 VP8/90000 > a=rtpmap:100 VP8/90000 > a=rtpmap:101 flexfec/90000 > a=rtpmap:103 flexfec/90000 > a=fmtp:98 max-fr=30;max-fs=8040 > a=fmtp:100 max-fr=15;max-fs=1200 > a=fmtp:101 L=5; D=10; ToP=2; repair-window=200000 > a=fmtp:103 L=5; D=10; ToP=2; repair-window=200000 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:1 send pt=98; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:2 send pt=100; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:send 1;2 > > ============================================================================== > > 5.3.5 SDP Answer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE m0 m1 > a=group:LS m0 m1 > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.77 > a=mid:m0 > a=msid:ma ta > a=recvonly > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667326 198.51.100.7 51556 typ host > a=candidate:1 1 UDP  1694302206 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > m=video 49203 UDP/TLS/RTP/SAVPF 98 100 101 103 > c=IN IP4 203.0.113.77 > a=mid:m1 > a=msid:ma tb > a=recvonly > a=rtpmap:98 VP8/90000 > a=rtpmap:100 VP8/90000 > a=rtpmap:101 flexfec/90000 > a=rtpmap:103 flexfec/90000 > a=fmtp:98 max-fr=30;max-fs=8040 > a=fmtp:100 max-fr=15;max-fs=1200 > a=fmtp:101 L=5; D=10; ToP=2; repair-window=200000 > a=fmtp:103 L=5; D=10; ToP=2; repair-window=200000 > a=rtcp-fb:* nack > a=rtcp-fb:* nack pli > a=rtcp-fb:* ccm fir > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:3 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id > > *** ERROR: invalid syntax for 'extmap' > *** Note: Removing duplicate 'a=' fixes this. > > a=rid:1 recv pt=98; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=rid:2 recv pt=100; > > *** ERROR: invalid syntax for 'rid' > *** Note: Removing trailing semicolon fixes this. > > a=simulcast:recv 1;2 > > ============================================================================== > > 5.4.1 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=rtcp-fb:* nack > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.4.1 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:0 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=rtcp-fb:* nack > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > > ============================================================================== > > 5.4.2 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 54609 UDP/TLS/RTP/SAVPF 109 0 8 > c=IN IP4 203.0.113.141 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:0 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:actpass > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=rtcp-fb:* nack > a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP  2113667327 192.0.2.4 61665 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54609 typ srflx raddr > 192.0.2.4 rport 61665 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=end-of-candidates > > ============================================================================== > > 5.4.2 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=group:BUNDLE audio > a=ice-options:trickle > m=audio 49203 UDP/TLS/RTP/SAVPF 109 0 98 > c=IN IP4 203.0.113.77 > a=mid:audio > a=msid:ma ta > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=rtpmap:0 PCMU/8000 > a=rtpmap:0 PCMA/8000 > a=maxptime:120 > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=tls-id:1 > > *** ERROR: invalid syntax for 'tls-id' > *** Note: tls-id must be 20 chars or longer. > > a=rtcp-mux > a=rtcp-rsize > a=rtcp-fb:* nack > a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > a=candidate:0 1 UDP 2113667327 198.51.100.7 51556 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > a=end-of-candidates > > ============================================================================== > > 5.4.3 SDP Answer > ============================================================================== > > v=0 > o=- 20519 0 IN IP4 0.0.0.0 > s=- > t=0 0 > m=audio 49203 UDP/TLS/RTP/SAVPF 109 > c=IN IP4 203.0.113.141 > a=rtcp:60065 IN IP4 203.0.113.141 > a=sendrecv > a=rtpmap:109 opus/48000/2 > a=maxptime:120 > a=ice-ufrag:ufrag:c300d85b > > *** ERROR: invalid syntax for 'ice-ufrag' > *** Note: Removing errant 'ufrag:' fixes this. > > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=setup:active > a=rtcp-rsize > a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level > a=candidate:0 1 UDP  2113667327 198.51.100.7 51556 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 51556 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 UDP 2113667326 198.51.100.7 51558 typ host > a=candidate:1 2 UDP  1694302206 203.0.113.77 60065 typ srflx raddr > 198.51.100.7 rport 51558 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > m=video 0 UDP/TLS/RTP/SAVPF 98 100 > m=video 0 UDP/TLS/RTP/SAVPF 98 100 > > ============================================================================== > > 5.4.5 SDP Offer > ============================================================================== > > v=0 > o=- 20518 0 IN IP4 0.0.0.0 > s=- > t=0 0 > a=ice-ufrag:074c6550 > a=ice-pwd:a28a397a4c3f31747d1ee3474af08a068 > a=rtcp-rsize > m=audio 54732 RTP/AVP 109 > > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. > > c=IN IP4 203.0.113.141 > a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=rtpmap:109 opus/48000 > a=ptime:20 > a=sendrecv > a=rtcp-mux > a=rtcp:64678 IN IP4 203.0.113.141 > a=candidate:0 1 UDP  2113667327 192.0.2.4 54732 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  694302207 203.0.113.141 54732 typ srflx raddr > 192.0.2.4 rport 54732 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 UDP 2113667326 192.0.2.4 64678 typ host > a=candidate:1 2 UDP  1694302206 203.0.113.141 64678 typ srflx raddr > 192.0.2.4 rport 64678 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > m=video 62445 RTP/AVP 120 > > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. > > c=IN IP4 203.0.113.141 > a=fingerprint:sha-256 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 > :6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=rtpmap:120 VP8/90000 > a=sendrecv > a=rtcp-mux > a=rtcp:54721 IN IP4 203.0.113.141 > a=candidate:0 1 UDP  2113667327 192.0.2.4 62445 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:1 1 UDP  1694302207 203.0.113.141 62537 typ srflx raddr > 192.0.2.4 rport 62445 > > *** ERROR: invalid syntax for 'candidate' > *** Note: Removing errant spaces fixes this problem. > > a=candidate:0 2 2113667326 192.0.2.4 54721 typ host > > *** ERROR: invalid syntax for 'candidate' > *** Note: Adding 'UDP' fixes this problem. > > a=candidate:1 2 UDP 1694302206 203.0.113.141 54721 typ srflx raddr > 192.0.2.4 rport 54721 > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > > ============================================================================== > > 5.4.5 SDP Answer > ============================================================================== > > v=0 > o=-  16833 0 IN IP4 0.0.0.0 > s=- > t=0 0 > m=audio 49203 RTP/AVP 109 > > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. > > c=IN IP4 203.0.113.77 > a=rtpmap:109 opus/48000 > a=ptime:20 > a=sendrecv > a=ice-ufrag:c300d85b > a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 > a=fingerprint:sha-256 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 > :19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 > > *** ERROR: invalid syntax for 'fingerprint' > *** Note: Removing errant spaces fixes this problem. > > a=rtcp-mux > a=candidate:0 1 UDP 2113667327 198.51.100.7 49203 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 49203 typ srflx raddr > 198.51.100.7 rport 49203 > m=video  63130 RTP/SAVP 120 > > *** ERROR: invalid syntax for 'm' > *** Note: Using the correct transport value fixes this. > > c=IN IP4 203.0.113.77 > a=rtpmap:120 VP8/90000 > a=sendrecv > a=ice-ufrag:e39091na > a=ice-pwd:dbc325921d5dd29e4e99147efbabd9a2 > a=fingerprint:sha-256 BB:0A9:0E:05:E9:26:33:E8:70:88:A25:2F:70:9F:04: > :19:E2:1C:3B:4B:9F:81:5:2F:70:9F:04::F4:A5:A8:D8: > > *** ERROR: invalid syntax for 'fingerprint' (there's too much wrong here > to enumerate) > > a=rtcp-mux > a=candidate:0 1 UDP 2113667327 198.51.100.7 63130 typ host > a=candidate:1 1 UDP 1694302207 203.0.113.77 63130 typ srflx raddr > 198.51.100.7 rport 63130 > a=rtcp-fb:120 nack pli > a=rtcp-fb:120 ccm fir > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Dec 3 12:40:51 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A40127011 for ; Sun, 3 Dec 2017 12:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbxEyEE7PEAC for ; Sun, 3 Dec 2017 12:40:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EA0126D85 for ; Sun, 3 Dec 2017 12:40:47 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB3KeebJ068689 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 3 Dec 2017 14:40:41 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Harald Alvestrand , "rtcweb@ietf.org" Cc: draft-ietf-rtcweb-sdp@tools.ietf.org References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> <4615d633-dfc8-4ce5-593e-5c996046cecf@alvestrand.no> From: Adam Roach Message-ID: <231d0e13-9a2d-0805-46ff-764547005135@nostrum.com> Date: Sun, 3 Dec 2017 14:40:35 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <4615d633-dfc8-4ce5-593e-5c996046cecf@alvestrand.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 20:40:50 -0000 On 12/3/17 2:22 PM, Harald Alvestrand wrote: > Great to see attention on this! > > Nils Ohlmeier also wrote an extraction script > (https://github.com/nils-ohlmeier/sdpextractor - I have suggested a PR > that changes the file name format), do you want to publish yours too? > What I wrote was mostly done for the purpose of validating, so extraction is a very small part of it. It's also a bit fragile, in that it heavily relies on the exact format of the -08 XML source. With those caveats (and the warning that it's written in perl), the relevant portion of my script is: #!/usr/bin/perl my $source = 'draft-ietf-rtcweb-sdp-08.xml'; open(S, $source) || die $!; $xml = join ('',); close (S); $xml =~ s///gos; while ($xml =~ /(.*?)<\/texttable>/gos) {   my $title = $1;   my $body = $2;   my $column = 0;   my $sdp = '';   while ($body =~ /(.*?)<\/c>/gos) {     if ($column == 0){       my $line = $1;       $line =~ s/[ \t]*[\r\n]+[ \t]*/ /gos;       if ($line !~ /\*\*/) {         $sdp .= "$line\n";       }     }     $column = 1 - $column;   }   &process($title, $sdp); } You'll have to write your own "process" subroutine to do whatever you want to happen with the extracted SDP. /a From nobody Mon Dec 4 15:55:25 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F73128D69 for ; Mon, 4 Dec 2017 15:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqr8oNBLatHQ for ; Mon, 4 Dec 2017 15:55:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7259A120724 for ; Mon, 4 Dec 2017 15:55:22 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB4NtHG4050257 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Dec 2017 17:55:18 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Cullen Jennings Cc: RTCWeb IETF , "draft-ietf-rtcweb-sdp@tools.ietf.org" References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> <3530F649-EED5-4F27-BADA-3EF9011A6AAB@iii.ca> <7594FB04B1934943A5C02806D1A2204B6C0377F6@ESESSMB109.ericsson.se> From: Adam Roach Message-ID: Date: Mon, 4 Dec 2017 17:55:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0377F6@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 23:55:25 -0000 Christer -- I filed mine at , which I hope is the right location. /a On 12/3/17 12:04, Christer Holmberg wrote: > Do you have the link to the GitHub repo? > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 03 December 2017 17:25 > To: Adam Roach > Cc: RTCWeb IETF ; draft-ietf-rtcweb-sdp@tools.ietf.org > Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp > > That's great thank you. Could you please create issues in github (and only need one for fingerprint is broken, not every occurrence of it). > > >> On Dec 1, 2017, at 8:47 PM, Adam Roach wrote: >> >> [as an individual] >> >> I wrote a script that extracts the SDP from the XML source of draft-ietf-rtcweb-sdp-08 and does some very basic syntax checks on it. I'm posting the results here as feedback on the document to assist in correcting the examples. Note that I have *not* performed any semantic verification of the SDP itself, only the syntax. >> >> Total error count: 152 From nobody Mon Dec 4 16:36:47 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC7126557 for ; Mon, 4 Dec 2017 16:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IQy_DAkAc7R for ; Mon, 4 Dec 2017 16:36:43 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915861250B8 for ; Mon, 4 Dec 2017 16:36:43 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id w47so13970393uah.3 for ; Mon, 04 Dec 2017 16:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=grPtty8BKYJlZ1XjGt77N8zRz6CkzL66AG964SdzMhU=; b=IjMpGG20UAU01rKHNzv9tTMoaxdzqMHJreBdVZkqe1itSgQsqZWlQZfB9ii2johbkn SsQ1CqhAZZ4vi59hAeM7c76EnqnpfwlfYbzipIiU8S6lJLvg3jZZ8hn2WvgnqxIoFhPt MSJFZ2ipuYFSK6rfYuZaJfgLu53vXUpL74FGeQHxeZbYY7E9dePZ7NMXzAS78c8/IhBU o7gYtHnyEBIb32mjoiQo+nYa88bmmt/JlQjyXqNX7VUrnZKt7E+y3oO6VbnkPq1Cd3M0 uHNZhWHJvUmyNcP42V320vH/ZyhW1ohm/nBWRII50IgnJMJkNlh7OvMjKEhRaaQnt0ZO Dhgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=grPtty8BKYJlZ1XjGt77N8zRz6CkzL66AG964SdzMhU=; b=PLDV0wJrZ64/AHXL36P5OguL6+7XzOhWxSV7BvEL8hL15krpk8plUOkWLPFTnvwDzd n6ILmUYrbfmNMydXvqvib09pGzMWmeWkDStdJIKSFOlMhs9eJH/a6P9kQVFINMH7SIce oyW8bEgliK4z69sI+X3hAF38e9IOCbcWyNKnA6YA8vjzjzwlwRqAvnzzhpmL1JyW/zWg TUi/Rpa1r/EO3jzep0Ag3qEbRp2x0QMWozxJIkStUaDnKhur08/2uHxgCmzvKZtM/bTV ffIWmir1bMboqc5vqUMH2WpJqmf3gxYil23m33zYRNRe0DUUOv80PvYb7PZKuOUfuIiq 2e2A== X-Gm-Message-State: AKGB3mJ3hkUKa0Gru9Nv3SnHSbBsUgVPxVoT6jlFZY/SomGSLCDx07wy Fjh3VJszmAyV/wpucuLZlHaeCyKdoAUJ6ggUp3U= X-Google-Smtp-Source: AGs4zMa2Pcj8SbLC1N38wPZT4Qhe89uzOgA4NhbJSD2q9cmRUwt/1TSlx9l2XTzU05X5AOtunTa6f8vP+tpIFaKZwpg= X-Received: by 10.176.17.199 with SMTP id q7mr1847876uac.49.1512434202296; Mon, 04 Dec 2017 16:36:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.194 with HTTP; Mon, 4 Dec 2017 16:36:41 -0800 (PST) In-Reply-To: References: <92b7b153-754a-0237-ad0a-6ec08c40e262@nostrum.com> <3530F649-EED5-4F27-BADA-3EF9011A6AAB@iii.ca> <7594FB04B1934943A5C02806D1A2204B6C0377F6@ESESSMB109.ericsson.se> From: Suhas Nandakumar Date: Mon, 4 Dec 2017 16:36:41 -0800 Message-ID: To: Adam Roach Cc: Christer Holmberg , Cullen Jennings , RTCWeb IETF , "draft-ietf-rtcweb-sdp@tools.ietf.org" Content-Type: multipart/alternative; boundary="f403045d7a245fc9c9055f8d0702" Archived-At: Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 00:36:47 -0000 --f403045d7a245fc9c9055f8d0702 Content-Type: text/plain; charset="UTF-8" Thanks a lot Adam for filing the issues. The link you have used is the right one. I haven't looked at all the issues but would like to bring one point to notice. The extra spaces sneaked in during the attempt to improve the readability. We will take a look at the issues and get back Cheers Suhas On Mon, Dec 4, 2017 at 3:55 PM, Adam Roach wrote: > Christer -- > > I filed mine at , which I hope is > the right location. > > /a > > On 12/3/17 12:04, Christer Holmberg wrote: > >> Do you have the link to the GitHub repo? >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen >> Jennings >> Sent: 03 December 2017 17:25 >> To: Adam Roach >> Cc: RTCWeb IETF ; draft-ietf-rtcweb-sdp@tools.ietf.org >> Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp >> >> That's great thank you. Could you please create issues in github (and >> only need one for fingerprint is broken, not every occurrence of it). >> >> >> On Dec 1, 2017, at 8:47 PM, Adam Roach wrote: >>> >>> [as an individual] >>> >>> I wrote a script that extracts the SDP from the XML source of >>> draft-ietf-rtcweb-sdp-08 and does some very basic syntax checks on it. I'm >>> posting the results here as feedback on the document to assist in >>> correcting the examples. Note that I have *not* performed any semantic >>> verification of the SDP itself, only the syntax. >>> >>> Total error count: 152 >>> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403045d7a245fc9c9055f8d0702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Adam for filing the issues. The link you have= used is the right one. I haven't looked at all the issues but would li= ke to bring one point to notice. The extra spaces sneaked in during the att= empt to improve the readability.
We will take a look at the issues and = get back

Cheers
Suhas

On Mon, Dec 4, 2017 at 3= :55 PM, Adam Roach <adam@nostrum.com> wrote:
Christer --

I filed mine at <https://github.com/fluffy/ietf/issue= s>, which I hope is the right location.

/a

On 12/3/17 12:04, Christer Holmberg wrote:
Do you have the link to the GitHub repo?

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: 03 December 2017 17:25
To: Adam Roach <ad= am@nostrum.com>
Cc: RTCWeb IETF <rt= cweb@ietf.org>; draft-ietf-rtcweb-sdp@tools.ietf.org
Subject: Re: [rtcweb] Syntax issues in draft-ietf-rtcweb-sdp

That's great thank you. Could you please create issues in github (and o= nly need one for fingerprint is broken, not every occurrence of it).


On Dec 1, 2017, at 8:47 PM, Adam Roach <adam@nostrum.com> wrote:

[as an individual]

I wrote a script that extracts the SDP from the XML source of draft-ietf-rt= cweb-sdp-08 and does some very basic syntax checks on it. I'm posting t= he results here as feedback on the document to assist in correcting the exa= mples. Note that I have *not* performed any semantic verification of the SD= P itself, only the syntax.

Total error count: 152

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--f403045d7a245fc9c9055f8d0702-- From nobody Thu Dec 7 13:45:30 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA20128C9C; Thu, 7 Dec 2017 13:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yECOJ6PKrbc0; Thu, 7 Dec 2017 13:45:18 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959B0126DFE; Thu, 7 Dec 2017 13:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=101417; q=dns/txt; s=iport; t=1512683118; x=1513892718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dut2dfM0Rnv1cxKo99HTy/JQkOMnkBGfXJKivbB3/g4=; b=ARXAbkx0P+KVas2yFJwjz+ctufTrCaQcFgXoNUYPHlBXhZnCEIdr6P53 gp93XpDDySV0TW5W5RLffxTg986TsOFe+IcASpOlKTxAj9Pd/6vlpHeid nkmISfzfvjqWwGQT4pEWFrNO2oP80dqiOIUWeIePIAkQZ9RW6vtQdjFmz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQCftSla/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKAUQvZnInB50agX1+h3eOFBSBfgMKGAEMhEdPAoVjQRYBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAQIBAQEKDgFTCwULAgEIEQMBAgEVCwEGByEGCxQJCAIEA?= =?us-ascii?q?Q0FH4g0cEwDDQgQqi6HNQ2DIQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg1mCCoF?= =?us-ascii?q?WgWmCdTaCa4FxHg84FgmFOQWLSoY/hzqJAT0Ch3aIKYR8ghaGEYs1jQU9iGoCE?= =?us-ascii?q?RkBgToBJgMvgU9vFTqCKQmCEDYDHIFneAEBh1GBM4EVAQEB?= X-IronPort-AV: E=Sophos; i="5.45,374,1508803200"; d="scan'208,217"; a="41739751" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 21:45:17 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vB7LjGZ7025645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 21:45:16 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 15:45:16 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 15:45:15 -0600 From: "Mo Zanaty (mzanaty)" To: Stephen Botzko , "Ali C. Begen" CC: "rtcweb@ietf.org" , "payload@ietf.org" Thread-Topic: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction Thread-Index: AQHTb6Sq5fMniPLQpk+FmOyhGufnSQ== Date: Thu, 7 Dec 2017 21:45:15 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> <4A105783-051C-469E-8080-ED438E8DB803@networked.media> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.199] Content-Type: multipart/alternative; boundary="_000_D64EF1DF7668Emzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:45:23 -0000 --_000_D64EF1DF7668Emzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thank you for the detailed review and comments. We are updating the draft t= o address your comments as noted below (see Mo: inline). Thanks, Mo From: payload > o= n behalf of Stephen Botzko > Date: Tuesday, November 21, 2017 at 4:22 PM To: "Ali C. Begen" > Cc: "rtcweb@ietf.org" >, "payload@ietf.org" > Subject: Re: [payload] WGLC on RTP Payload Format for Flexible Forward Erro= r Correction I have reviewed it, but I don't think it is ready for publication yet. My commends follow. BR Stephen >>> Abstract >>> Overall, the purpose is to reconstruct RTP source packets that were lost in= transmission, using the source and repair packets that were received. I e= xpected that to be stated somewhere in the abstract and introduction. Mo: Agreed, some readers unfamiliar with FEC may benefit from a brief state= ment of the purpose of FEC, which we will add. >>> These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols. >>> This is of course the usual FEC jargon. But it isn=92t clear if the symbol= s in this draft are bits, bytes, or the full source packets payloads. Overall, the draft generally uses the phrase =93source packet=94 and =93rep= air packet=94. =93repair symbols=94 shows up in section 4.2, and there it = seems to mean bits or bytes. The draft needs to clarify this, as the many = implementers won=92t have any real knowledge of FEC. I suggest removing references to =93symbols=94, as the XOR construction and= repair mechanisms really don=92t need to talk about =93symbols=94. Mo: Agreed, we will use packets not symbols throughout. Also, =93FEC packets=94 appears to be the same thing as =93repair packets= =94. It would be better to use one term for both. Repair packets might be= clearer (though they reconstruct lost packets, and don't actually repair t= hem). Mo: We will clarify that these are FEC repair packets, and any shorter name= will be consistent throughout. >>> These repair symbols are sent in a repair flow separate from the source flo= w >>> The word =93flow=94 appears 19 times in the document with no explanation on= what exactly is meant. I believe it simply means that the source and repa= ir packets use different SSRCs (or different payload types?), but this is n= ot as clear as it might be. FWIW, I realize that =93flow=94 is also used extensively in RFC6363. But = RFC6363 defines flows in terms of transport identifier (such as standard 5 = tuple), and that definition doesn=92t apply here, since source and repair f= lows can use the same 5 tuple. Mo: We will avoid 'flow', which is also used extensively in RFC7656 RTP Tax= onomy with no definition. The taxonomy terms relevant for this draft are Re= dundancy RTP Stream and Source RTP Stream. If this begins to sound awkward = repeated many times, we will choose a consistent shorthand and avoid 'flow'= (replace with stream). >>> Moreover, alternate FEC codes may be used with the payload formats presente= d. >>> Does this mean that the FEC codes might not be XOR? If so, the document do= esn=92t say anything about how that is done (and the repair generation and = recovery methods in the draft are specific to XOR). So if means what is me= ant, the sentence should probably be removed. If it doesn=92t mean that, then what does it mean? Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility. Section 1.1 >>> Note that the source and repair packets belong to different source and repair flows, and the sender must provide a way for the receivers to demultiplex them, even in the case they are sent in the same 5-tuple (i.e., same source/destination address/port with UDP). >>> The =93different source and repair flows=94 aspect of the note is repetitiv= e, since it is also stated in step 3 immediately above this paragraph. =93= Even in the case=94 is understated, =93especially in the case=94 is closer = to the truth of it. It might be simpler to just say that source and repair= packets MUST use different SSRCs (or different payload types?), and delet= e this sentence. Mo: This will be clarified when 'flow' is removed throughout. >>> The repair packets may be sent proactively or on-demand. >>> How are they sent on demand? I don=92t see any methods for requesting repa= ir packets. Either procedures should be defined/referenced or the sentence= deleted. Mo: We will clarify that on-demand means in response to RTCP NACK, or the n= ew CC (ACK) feedback under design for RMCAT (draft-avtcore-cc-feedback-mess= age). Or we can word this more generically for any current or future NACK o= r ACK based feedback messages. >>> In this document, we refer to the time that spans a FEC block, which consists of the source packets and the corresponding repair packets, as the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in a FEC block, to allow all the repair packets to arrive. >>> Not sure if the intent is SHOULD wait or should wait. Mo: We will clarify this as SHOULD wait, and more specifically, SHOULD buff= er source and repair packets this long to allow for recovery upon packet lo= ss. More importantly, the FEC patterns in the draft are all defined to have a f= ixed number of packets. The =93time that spans an FEC block=94 is not cons= tant, especially for variable-rate video. The receiver has no idea how lon= g that repair window time might be for a specific FEC block. At some point the receiver decides it=92s time to deliver the source packet= s =96 either because (a) It is receiving source packets with no break in sequence number, so = there is no need to wait for repair (b) It has received enough repair packets to recover the missing source = packets (c) It has received all the repair packets, and they aren=92t sufficien= t to recover the missing source packets (d) It is choosing not to wait any longer. Case (d) might be reached because it is starting to receive packets in the = next FEC block, or it might be reached because of a real-time constraint The wording in the above paragraph doesn=92t cover these cases very well. = And the FEC decoder doesn=92t always need to wait for all the repair packet= s to be received before it can begin the repair process. It=92s probably more useful to point out that using flexflec does add delay= , and it needs to be clear that the repair window (in time units) is nomina= l. Or maybe specify the repair window in packets? Mo: repair-window (in microseconds) is a required parameter when negotiatin= g this payload format. Fixed block size in packets is an optional parameter= (L=3Dcolumns, D=3Drows). >>> Suppose that we have a group of D x L source packets that have sequence numbers starting from 1 running to D x L, and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as 1-D non-interleaved FEC protection >>> I think the document would be clearer if this was in new section =96 preced= ed by a short into saying how flexspec provides non-interleaved (row), inte= rleaved (column), and hybrid row+column (2-D) FEC patterns. This is a key = concept in the draft, and should be more prominent. I think there should also be four use-case sections. Separate sections for= row and column, and the retransmission mode (=93R=94 bit) should probably = have a short section too. Mo: Agreed, we will separate into more sections. >>> 1.1.3. Overhead Computation >>> Overhead isn=92t used much in the document, and I am not sure this particul= ar definition adds much value. It might be better phrased as =93FEC Overhe= ad Considerations=94, since the overhead fractions really don=92t have much= practical use, especially when the source packets are of unequal size. Mo: Ok, we will rename this. >>> 3.1. Definitions >>> FEC Block, and repair window should be defined here (neither are defined in= RFC6363). Parity Codes are not defined in RFC6363 either, and probably sh= ould be defined here. 1-D non-interleaved, 1-D interleaved, 2-D protection perhaps should be defi= ned. It might be cleaner to define source block here, since the RFC6363 definiti= on doesn=92t precisely apply (because its definition of ADU flow depends on= 5-tuple). In general there are very few definitions in RFC6363 that are used in flexf= ec, so if it were my draft I=92d just redefine them explicitly here. Mo: Ok, we will define what is used. >>> 3.2. Notations >>> I=92m not sure that bitmask needs to be here, though the text is ok. Mo: We will keep it for clarity. 4.1. Source Packets >>> The source packets MUST contain the information that identifies the source block and the position within the source block occupied by the packet. >>> This is a meaningless MUST, since the source RTP packet is simply sent with= out modification. The sequence number and SSRC are used to map the packets= onto the repair packets. Overall, paragraph 4.1 is confusing, because it gives the impression that s= omething else needs to be done, and then says that there isn=92t. Plus, it= is supposed =93define the format of the source packet=94 - which it doesn= =92t do. I think it=92s better just to say earlier in the document that the source p= ackets can be any RTP packets, and leave it at that. Perhaps tie that stat= ement to the use of systematic codes. Then focus on defining the repair pa= cket format, which is the heart of the draft. The advantages of not modifying the source packets is better placed somewhe= re else in the document =96 perhaps in section 1.1, when the FEC encoder an= d Decoders are introduced. Mo: Agreed, nothing normative to do here, so we will remove this MUST and d= escribe what systematic codes are. 4.2. Repair Packets >>> o Marker (M) Bit: This bit is not used for this payload type, and SHALL be set to 0 >>> And ignored by receivers? Mo: Agreed, "SHALL be set to 0 by senders, and SHALL be ignored by receiver= s". >>> Note that this document registers new payload formats for the repair packets (Refer to Section 5 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type, and hence, will discard the repair packet. >>> This probably should be said somewhere, but I think it=92s better moved som= ewhere other than the repair packet format description. Mo: Agreed, will move to a better section. I believe this also requires that the CSRCs in the repair RTP header be set= to the SSRCs of the source packets. That isn=92t stated, but is implied b= y the structure in table 10. Mo: It is stated below Figure 10 in FEC Header (see CSRC_i), but should be = moved up before Figure 10 in RTP Header. >>> The format of the FEC header is shown in Figure 10. The FEC header consists of the following fields: >>> No. This is the first of four? possible formats, depending on R,F,M, and N= , shown in figures 10-15. M is ambiguous - appears as M and M (columns). = Some fields are really repair symbols (P,X,C,M, PT Recovery, Length Recover= y, recovery), and are meaningless on their own. This rather important deta= il doesn=92t show up until you get to 6.2. Figure 15 also affects figure 9, since the unspecified =93Repair symbols=94= in figure 9 are replaced by the =93retransmission payload=94 In figure 15.= The contents of that =93retransmission payload=94 are not specified anywh= ere in the draft. This whole section is a confusing mess, and needs to be restructured. I gu= ess one approach is to change 6.2 to =93Repair symbol construction=94, and = explicitly refer to it for all fields in the FEC header that are XORed. On= e way or another, you need to separate out the fields that specify the FEC = parameters from the embedded repair symbols mixed into the structure. Mo: Agreed, implementors have also asked for clearer separation of the diff= erent repair formats, especially for FEC vs Retransmission, so we will sepa= rate this into clearer sections. >>> o The CSRC_i (32 bits) field describes the SSRC of the packets protected by this particular FEC packet. If a FEC packet contains protects multiple SSRCs (indicated by the CSRC Count > 1), there will be multiple blocks of data containing the SN base and Mask fields. >>> Does this mean that a repair flow can protect multiple RTP sources? If so,= this should be clearly stated earlier. There might be other implications = of supporting this (do all the sources need to have the same CNAME???) Mo: Yes, a repair stream can span multiple source streams. We will clarify = this earlier. The same CNAME is noted earlier in this section under the SSR= C bullet. >>> If M>0, N=3D0, is Row FEC, and no column FEC will follow Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. If M>0, N=3D1, is Row FEC, and column FEC will follow. Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. and more to come If M>0, N>1, indicates column FEC of every M packet in a group of N packets starting at SN base. Hence, FEC =3D SN+(Mx0), SN+(Mx1), ... , SN+(MxN). Figure 14: Interpreting the M and N field values >>> First, this is not a figure. Second, the names are not consistent with the = 1-d non-interleaved, 1-d interleaved, and 2-d described above. The names n= eed to be consistent. FWIW, these names are a bit more intuitive to me. Mo: Agreed, we will add the 1-d non-interleaved, 1-d interleaved and 2-d la= bels to the row/column FEC shorthand names here. >>> Note that the parsing of this packet is different. >>> =93this=94 is indefinite. In general you should name the four(?) header ty= pes, I think that will make things simpler. Mo: Agreed, the different repair formats will be separated into cleaer sect= ions. >>> Figure 15: Protocol format for Retransmission >>> This is mis-titled. It also isn=92t clear. The figure shows the alternati= ve FEC header format, but I believe the intent is that the retransmission p= ayload replaces the =93repair symbols=94 shown in figure 9. That isn=92t o= bvious from the organization. Mo: Agreed, the different repair formats will be separated into cleaer sect= ions. >>> It should be noted that a mask-based approach (similar to the ones specified in [RFC2733] and [RFC5109= ]) may not be very efficient to indicate which source packets in the current source block are associated with a given repair packet. In particular, for the applications that would like to use large source block sizes, the size of the mask that is required to describe the source-repair packet associations may be prohibitively large. The 8-bit fields proposed in [SMPTE2022-1] indicate a systematized approach. = Instead the approach in this document uses the 8-bit fields to indicate packet offsets protected by the FEC packet. The approach in [SMPTE2022-1] is inherently more efficient for regular patte= rns, it does not provide flexibility to represent other protection patterns (e.g., staircase). >>> I have no idea why this note is here. I=92d delete it. There's no point i= n talking about all the roads not taken. Mo: Agreed, we will remove it. >>> 5. Payload Format Parameters >>> If no specific FEC code is specified in the subtype, then the FEC code defaults to the parity code defined in this specification. >>> Since there is no syntax to specify the FEC code, a receiver has no way to = know for certain that the parity code is being used. I guess that the stat= ement in 5.2.1 might cover this Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility. >>> =93There are no optional format parameters defined for this payload. Any unknown option in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, it can be deleted from the answer. >>> For SDP at least, any FEC code in the offer would be deleted by an existing= receiver, so if parity is mandatory-to-implement you=92d get interoperabil= ity at least. But why not just specify the FEC code parameter (with Parity= as a choice) now? Mo: The original draft allowed other codes (e.g. Reed-Solomon or Raptor) to= be negotiated as a parameter, but the workgroup decided to remove this fle= xibility and require other codes to use other payload format names. >>> 6.2. Repair Packet Construction The RTP header of a repair packet is formed based on the guidelines given in Section 4.2. >>> Since 4.2 is a mess, it=92s not surprising that 6.2 is also. The FEC header length isn=92t limited to 28 octets in the retransmission ca= se (which is conveniently skipped in 6.2) It would be good to specify what=92s in the skipped bits in the header, rat= her than making people figure it out. (=93V-2=94 and Sequence Number) Also phrases like =93The next 4 bits of the FEC bit string are written into= the CC recovery field in the FEC header=94 should be written as like =93Th= e next 4 bits of the FEC bit string are XORed into the CC recovery field in= the FEC header=94 BTW, I don=92t think the =93FEC bit string=94 nomenclature is all that usef= ul, given that you end up specifying the XOR field by field anyway. Mo: Agreed, we will clarify this. >>> The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. If the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. >>> This presumably defines what is placed into the =93repair symbols=94 back i= n figure 9. But it doesn=92t say that. I believe this is incomplete. It doesn=92t say how to handle extension hea= ders. It isn=92t clear whether padding octets are XORed (RFC 3550 says the= padding octets =93are not part of the payload=94). SRTP MKI and authentica= tion tag would also be recovered (which is not possible in the current draf= t). Mo: We will clarify this. We need a good name for the part of the RTP packe= t after the fixed 12 byte header (CSRC list, extension header, RTP payload = and padding, as described in the second bullet of this section). >>> 6.3.2. Recovering the RTP Header This procedure recovers the header of an RTP packet up to (and including) the SSRC field. >>> But it doesn=92t recover the full header, and that should be more clearly s= tated, Mo: Do you mean it can't recover RTP version (assumes 2)? We can clarify th= at. The rest of the header can be recovered. FWIW, =93if the repair symbols=94 were defined as running from the first by= te after the SSRC to the end of the source RTP packet, then the full RTP pa= cket would be recovered =96 including SRTP MKI and authentication tag, whic= h cannot be recovered now. Mo: Yes, that is the design, we will clarify this. Again, a word for that (= after SSRC to end, after fixed 12 byte header) would greatly clarify this. >>> 6.3.3. Recovering the RTP Payload 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header >>> As is the SSRC, though in a different way. Mo: Yes, we will note this to avoid any confusion. >>> 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header. 3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. Note that the FEC header may be 12, 16, 32 octets depending on the length of the bitmask. 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2. >>> This is close to the algorithm I suggested above (starting the =93Repair sy= mbols=94 in figure 9 from the first octet after the SSRC). That=92s good, but it isn=92t consistent with the text in 6.2 (=93The repai= r packet payload consists of the bits that are generated by applying the XO= R operation on the payloads of the source RTP packets). So the text as written fails to recover (or fails to generate the repair pa= cket correctly, depending on how you look at it). Also, any RTP padding, SRTP MKI + authentication tag in the repair packets = themselves shouldn=92t be included in the XOR. RTP Padding, RTP MKI and the authentication tag lengths that are part of th= e source packets do need to be taken into account when computing Y. I'm no= t sure the current FEC header handles that well. This section uses "FEC Bit String" to mean something different than it mean= t earlier in the document. Note the repair algorithms could include authentication of input packets an= d recovered source packets. Mo: Yes, "payloads" will be removed, it is overloaded and incorrect. Again,= we need a good word for all bytes after 12. >>> 8. Congestion Control Considerations >>> I=92d remove the reference to[I-D.singh-rmcat-adaptive-fec]. Mo: Agreed, we will remove it. >>> However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13][Nagy14]. >>> What does this sentence mean? The draft doesn=92t talk about using FEC for= either bandwidth estimation or capacity probing. I suggest deleting it. Mo: Agreed, we will remove it. >>> 9. Security Considerations >>> Since the sender of the repair packets might not be the sender of the sourc= e packets, there is an obvious threat of injection of bogus repair packets.= Authentication can be helpful in mitigating that threat. Such authentication (if possible) should be done an any packets that are us= ed in the recovery process, and also on the reconstructed output packets. One could strengthen this into "MUST not" normative language if one wished. Mo: Agreed, we will make it a MUST if the recovered packet can be authentic= ated (i.e. SRTP source packets). NITS Overall, the document frequently uses first person plural (Suppose we have,= If we apply, We generate, We refer, We assume, =85). I think the authors= should consider rephrasing those sentences. Mo: We will rephrase ;) Section 1 >>> Situations where adaptivitiy of FEC parameters is desired, the endpoint can use the in-band mechanism, whereas when the FEC parameters are fixed, the endpoint may prefer to negotiate them out-of-band. >>> The sentence uses incorrect grammar. I suggest The in-band mechanism is advantageous when the endpoint is adapting the FEC= parameters; the out-of-band mechanism may be preferable when the FEC param= eters are fixed. Mo: Agreed, we will reword. Section 1.1 >>> In a nutshell, >>> Informal English =96 I suggest rephrasing. Mo: Agreed, we will remove. >>> Section 8 However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13][Nagy14]. >>> Probing? Mo: We will remove this anyway. On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen > wrote: Obviously the deadline for the WGLC is Dec. 7th. -acbegen > On Nov 17, 2017, at 5:35 AM, Roni Even > wrote: > > Hi, > I would like to start a three week WGLC on RTP Payload Format for Flexibl= e Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05. > The WGLC will end on November 7th > > Mo has posted some clarifications to the payload WG mailing list payload= mailing list archives > > Please send comments to the payload mailing list. > THe double posting is to notify RTCweb WG that the WGLC has started sinc= e this document is needed for RTCweb > > > Roni Even > Payload WG co-chair > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_D64EF1DF7668Emzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9CA4D2F7E1FCC84BA6A959ED878C53C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thank you for the detailed review and comments. We are updating the draft t= o address your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <payload-bounces@ietf.org> on behalf of St= ephen Botzko <stephen.botzko= @gmail.com>
Date: Tuesday, November 21, 2017 at= 4:22 PM
To: "Ali C. Begen" <ali.begen@networked.media>= ;
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>, "payload@= ietf.org" <payload@ietf.org= >
Subject: Re: [payload] WGLC on RTP = Payload Format for Flexible Forward Error Correction

I have reviewed it, but I don't think it is ready for publ= ication yet.

My commends follow.

BR
Stephen 

 

>>>
Abstract
>>>
Overall, the purpose is to reconstruct RTP source packets that were los=
t in transmission, using the source and repair packets that were received.&=
nbsp; I expected that to be stated somewhere in the abstract and introducti=
on.
Mo: Agreed, some readers unfamiliar with FEC may benefit from a brief = statement of the purpose of FEC, which we will add. 
 
>>> 

These parity codes are systematic codes, w=
here a number of repair


   symbols are generated from a =
set of source symbols.


>>> 

This is of =
course the usual FEC jargon.  But it isn=92t clear if the symbols in t=
his draft are bits, bytes, or the full source packets payloads.  


=
Overall, the draft generally uses the phrase =93source packet=94 and =93rep=
air packet=94.  =93repair symbols=94 shows up in section 4.2, and th=
ere it seems to mean bits or bytes.  The draft needs to clarify this, =
as the many implementers won=92t have any real knowledge of FEC.

 


I suggest removing references to =93symbols=94, as the XOR construction=
 and repair mechanisms really don=92t need to talk about =93symbols=94.


Mo: Agreed, we will use packets not symbols throughout. 


Also, =93FEC packets=94 appears to be the same thing as =93repair packe=
ts=94.  It would be better to use one term for both.  Repair pack=
ets might be clearer (though they reconstruct lost packets, and don't actua=
lly repair them).
Mo: We will clarify that these are FEC repair packets, and any shorter name= will be consistent throughout.

>>>  

These repair symbols are sent in a repair =
flow separate from the source flow


>>> 


The word =
=93flow=94 appears 19 times in the document with no explanation on what exa=
ctly is meant.  I believe it simply means that the source and repair p=
ackets use different SSRCs (or different payload
 types?), but this is not as clear as it might be.  


=
FWIW, I realize that =93flow=94 is also used extensively in RFC6363. &=
nbsp; But RFC6363 defines flows in terms of transport identifier (such as s=
tandard 5 tuple), and that definition doesn=92t apply here, since source an=
d repair flows can use the same 5 tuple.
Mo: We will avoid 'flow', which is also used extensively in RFC7656 RTP Tax= onomy with no definition. The taxonomy terms relevant for this draft are Re= dundancy RTP Stream and Source RTP Stream. If this begins to sound awkward = repeated many times, we will choose a consistent shorthand and avoid 'flow' (replace with stream).

>>> 

Moreover, alternate FEC codes may be used =
with the payload formats presented.

>>> 

Does this mean that the FEC codes might not be XOR?&= nbsp; If so, the document doesn=92t say anything about how that is done (an= d the repair generation and recovery methods in the draft are specific to X= OR).  So if means what is meant, the sentence should probably be removed.

If it doesn=92t mean that, then what does it mean?

Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility.

Section 1.1

>>> 

   Note that the source and repa=
ir packets belong to different source
   and repair flows, and the sen=
der must provide a way for the receivers
   to demultiplex them, even in =
the case they are sent in the same
   5-tuple (i.e., same source/de=
stination address/port with UDP).

>>> 

The =93different source and repair flows=94 aspect o= f the note is repetitive, since it is also stated in step 3 immediately abo= ve this paragraph.  =93Even in the case=94 is understated, =93especial= ly in the case=94 is closer to the truth of it.  It might be simpler to just say that source and repair packets MUST use diffe= rent SSRCs  (or different payload types?), and delete this sentence.

Mo: This will be clarified when 'flow' is remo= ved throughout. 

= >>> 

The repair packets may be sent proactively=
 or on-demand.

= >>> 

How are they sent on demand?  I don=92t see any= methods for requesting repair packets.  Either procedures should be d= efined/referenced or the sentence deleted.
Mo: We will clarify that on-demand means in response to RTCP NACK, or the n= ew CC (ACK) feedback under design for RMCAT (draft-avtcore-cc-feedback-mess= age). Or we can word this more generically for any current or future NACK o= r ACK based feedback messages.

>>> 

In this document, we refer to the time tha=
t
   spans a FEC block, which cons=
ists of the source packets and the
   corresponding repair packets,=
 as the repair window.  At the receiver
   side, the FEC decoder should =
wait at least for the duration of the
   repair window after getting t=
he first packet in a FEC block, to allow
   all the repair packets to arr=
ive.

>>> 

Not sure if the intent is SHOULD wait or should wait= .
Mo: We will clarify this as SHOULD wait, and more specifically, SHOULD buff= er source and repair packets this long to allow for recovery upon packet lo= ss.

More importantly, the FEC patterns in the draft are = all defined to have a fixed number of packets.  The =93time that spans= an FEC block=94 is not constant, especially for variable-rate video. = The receiver has no idea how long that repair window time might be for a specific FEC block.

At some point the receiver decides it=92s time to de= liver the source packets =96 either because

(a)    It is receiving source packets with no break in sequence number, so = there is no need to wait for repair

(b)    It has received enough repair packets to recover the missing source = packets

(c)     It has received all the repair packets, and they aren=92t sufficient= to recover the missing source packets

(d)    It is choosing not to wait any longer.

 

Case (d) might be reached bec= ause it is starting to receive packets in the next FEC block, or it might b= e reached because of a real-time constraint

 

The wording in the above paragraph doesn=92t cover t= hese cases very well.  And the FEC decoder doesn=92t always need to wa= it for all the repair packets to be received before it can begin the repair= process.

It=92s probably more useful to point out that using = flexflec does add delay, and it needs to be clear that the repair window (i= n time units) is nominal.  Or maybe specify the repair window in packe= ts? 

Mo: repair-window (in microseconds) is a required parameter when negotiatin= g this payload format. Fixed block size in packets is an optional parameter= (L=3Dcolumns, D=3Drows).

>>> 

Suppose that we have a group of D x L sour=
ce packets that have
   sequence numbers starting fro=
m 1 running to D x L, and a repair
   packet is generated by applyi=
ng the XOR operation to every L
   consecutive packets as sketch=
ed in Figure 3.  This process is
   referred to as 1-D non-interl=
eaved FEC protection

>>> 

I think the document would be clearer if this was in= new section =96 preceded by a short into saying how flexspec provides non-= interleaved (row), interleaved (column), and hybrid row+column (2-D) FE= C patterns.  This is a key concept in the draft, and should be more prominent. 

I think there should also be four use-case sections.=   Separate sections for row and column, and the retransmission mode (= =93R=94 bit) should probably have a short section too.
Mo: Agreed, we will separate into more sections.

>>> 

1.1.3<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">.  Overhead Computation

>>> 


Overhead isn=92t used much in the document, and I am= not sure this particular definition adds much value.  It might be bet= ter phrased as =93FEC Overhead Considerations=94, since the overhead fracti= ons really don=92t have much practical use, especially when the source packets are of unequal size.

Mo: Ok, we will rename this. 

>>> 

3.1.  Definitions

>>> 

FEC Block, and repair window should be defined here = (neither are defined in RFC6363).  Parity Codes are not defined in RFC= 6363 either, and probably should be defined here.


1-D non-interleaved, 1-D interleaved, 2-D protection= perhaps should be defined.


It might be cleaner to define source block here, sin= ce the RFC6363 definition doesn=92t precisely apply (because its definition= of ADU flow depends on 5-tuple). 


In general there are very few definitions in RFC6363= that are used in flexfec, so if it were my draft I=92d just redefine them = explicitly here.
Mo: Ok, we will define what is used.

>>> 

3.2.&= nbsp; Notations

>>> 

I=92m not sure that bitmask needs to be here, though= the text is ok.

Mo: We will keep it for clarity. <= /p>

 

4.1.  Source Packets

>>> 

   The source packets MUST conta=
in the information that identifies the
   source block and the position=
 within the source block occupied by the
   packet. 

>>> 

This is a meaningless MUST, since the source RTP pac= ket is simply sent without modification.  The sequence number and SSRC= are used to map the packets onto the repair packets.  

Overall, paragraph 4.1 is confusing, because it give= s the impression that something else needs to be done, and then says that t= here isn=92t.  Plus, it is supposed =93define the format of the source= packet=94 -  which it doesn=92t do. 


I think it=92s better just to say earlier in the doc= ument that the source packets can be any RTP packets, and leave it at that.=   Perhaps tie that statement to the use of systematic codes.  The= n focus on defining the repair packet format, which is the heart of the draft.


The advantages of not modifying the source packets i= s better placed somewhere else in the document =96 perhaps in section 1.1, = when the FEC encoder and Decoders are introduced.

Mo: Agreed, nothing normative to do here, so w= e will remove this MUST and describe what systematic codes are. 

4.2.&= nbsp; Repair Packets

 

>>> 

   o  Marker (M) Bit: This =
bit is not used for this payload type, and


      SHALL be se=
t to 0


>>> 


And ignored by receivers?
Mo: Agreed, "SHALL be set to 0 by senders, and SHALL be ignored by rec= eivers".

>>> 

Note that this document


      registers n=
ew payload formats for the repair packets (Refer to

      Section 5 for details).  According to [RFC3550], an RTP receiver


      that cannot=
 recognize a payload type must discard it.  This

      provides ba=
ckward compatibility.  If a non-FEC-capable receiver


      receives a =
repair packet, it will not recognize the payload type,<=
/pre>

      and hence, =
will discard the repair packet.


>>> 


This probably should be said somewhere, but I think =
it=92s better moved somewhere other than the repair packet format descripti=
on.


Mo: Agreed, will move to a better section.&nbs=
p;


I believe this also requires that the CSRCs in the r=
epair RTP header be set to the SSRCs of the source packets.  That isn=
=92t stated, but is implied by the structure in table 10.


Mo: It is stated below Figure 10 in FEC Header (see =
CSRC_i), but should be moved up before Figure 10 in RTP Header.


>>> 


The format of the FEC header is shown in F=
igure 10.


The FEC header consists of the following f=
ields:


>>> 


No.  This is the first of four? possible format=
s, depending on R,F,M, and N, shown in figures 10-15.  M is ambiguous =
- appears as M and M (columns).  Some fields are really repair symbols=
 (P,X,C,M, PT Recovery, Length Recovery, recovery),
 and are meaningless on their own.  This rather important detail doesn=
=92t show up until you get to 6.2.







Figure 15 also affects figure 9, since the unspecifi=
ed =93Repair symbols=94 in figure 9 are replaced by the =93retransmission p=
ayload=94 In figure 15.  The contents of that =93retransmission payloa=
d=94 are not specified anywhere in the draft.







This whole section is a confusing mess, and needs to=
 be restructured.  I guess one approach is to change 6.2 to =93Repair =
symbol construction=94, and explicitly refer to it for all fields in the FE=
C header that are XORed.  One way or another,
 you need to separate out the fields that specify the FEC parameters from t=
he embedded repair symbols mixed into the structure.


Mo: Agreed, implementors have also asked for c=
learer separation of the different repair formats, especially for FEC vs Re=
transmission, so we will separate this into clearer sections. <=
/p>

>>> 


   o  The CSRC_i (32 bits) =
field describes the SSRC of the packets


      protected b=
y this particular FEC packet.  If a FEC packet contains


      protects mu=
ltiple SSRCs (indicated by the CSRC Count > 1), there


      will be mul=
tiple blocks of data containing the SN base and Mask

      fields.


>>> 


Does this mean that a repair flow can protect multip=
le RTP sources?  If so, this should be clearly stated earlier.  T=
here might be other implications of supporting this (do all the sources nee=
d to have the same CNAME???)


Mo: Yes, a repair stream can span multiple source st=
reams. We will clarify this earlier. The same CNAME is noted earlier in thi=
s section under the SSRC bullet.


>>> 


If M>0, N=3D0,  is Row FEC, and no=
 column FEC will follow


       =
        Hence, FEC =3D SN, SN+1, SN&=
#43;2, ... , SN+(M-1), SN+M.


 


   If M>0, N=3D1,  is Ro=
w FEC, and column FEC will follow.


       =
          Hence, FEC =3D SN, S=
N+1, SN+2, ... , SN+(M-1), SN+M.


       =
     and more to come


 


   If M>0, N>1,  indi=
cates column FEC of every M packet


       =
             in=
 a group of N packets starting at SN base.


       =
          Hence, FEC =3D SN=
3;(Mx0), SN+(Mx1), ... , SN+(MxN).


 


 


       =
      Figure 14: Interpreting the M and N field va=
lues


>>> 


First, this is not a figure. Second, the names are n=
ot consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d descri=
bed above.  The names need to be consistent.  FWIW, these names a=
re a bit more intuitive to me.


Mo: Agreed, we will add the 1-d non-interleave=
d, 1-d interleaved and 2-d labels to the row/column FEC shorthand names her=
e.  


>>> 


Note that the parsing of this packet is di=
fferent. 


>>> 


=93this=94 is indefinite.  In general you shoul=
d name the four(?) header types, I think that will make things simpler.&nbs=
p;



Mo: Agreed, the different repair formats will =
be separated into cleaer sections. 


>>> 


Figure 15: Protocol format for Retransmiss=
ion


>>> 


This is mis-titled.  It also isn=92t clear.&nbs=
p; The figure shows the alternative FEC header format, but I believe the in=
tent is that the retransmission payload replaces the =93repair symbols=94 s=
hown in figure 9.  That isn=92t obvious from the organization. &n=
bsp;



Mo: Agreed, the different repair formats will be sep=
arated into cleaer sections. 







>>> 


=
   It should be noted that a mask-based approach (similar to =
the ones


=
   specified in [RFC2733]
 and [RFC5109]) may =
not be very efficient to


=
   indicate which source packets in the current source block =
are


=
   associated with a given repair packet.  In particular=
, for the


=
   applications that would like to use large source block siz=
es, the


=
   size of the mask that is required to describe the source-r=
epair


=
   packet associations may be prohibitively large.  The =
8-bit fields


=
   proposed in [SMPTE2022-1]
 indicate a systematized approach.  Instead


=
   the approach in this document uses the 8-bit fields to ind=
icate


=
   packet offsets protected by the FEC packet.  The appr=
oach in


=
   [SMPTE2022-1] is
 inherently more efficient for regular patterns, it


=
   does not provide flexibility to represent other protection=
 patterns


=
   (e.g., staircase).


>>> 


I have no idea why this note is here.  I=92d de=
lete it.  There's no point in talking about all the roads not taken.


Mo: Agreed, we will remove it.







>>> 


5. 
 Payload Format Parameters


>>> 


If no specific FEC code is specified=



   in the subtype, then the FEC =
code defaults to the parity code defined


   in this specification.<=
/span>


>>> 


Since th=
ere is no syntax to specify the FEC code, a receiver has no way to know for=
 certain that the parity code is being used.  I guess that the =
statement in 5.2.1 might cover this 


M=
o: This will be removed. The original draft allowed other codes (e.g. Reed-=
Solomon or Raptor) to be negotiated, but the workgroup decided to remove th=
is flexibility.


>>> 


=93There are no optional format parameters=
 defined for this payload.


      Any unknown=
 option in the offer MUST be ignored and deleted from

      the answer.=
  If FEC is not desired by the receiver, it can be=



      deleted fro=
m the answer.


>>> 

=
For SDP at least, any FEC code in the offer would be deleted by an existing=
 receiver, so if parity is mandatory-to-implement you=92d get interoperabil=
ity at least.  But why not just specify the FEC code parameter (with P=
arity as a choice) now?


Mo: The original draft=
 allowed other codes (e.g. Reed-Solomon or Raptor) to be negotiated as a pa=
rameter, but the workgroup decided to remove this flexibility and require o=
ther codes to use other payload format names. =



>>> 




6.2.  Repair Packet Construction






   The RTP header of a repair pa=
cket is formed based on the guidelines


   given in S=
ection 4.2.


>>> 


Since 4.2 is a mess, it=92s not surprising that 6.2 =
is also.


The FEC header length isn=92t limited to 28 octets i=
n the retransmission case (which is conveniently skipped in 6.2)


It would be good to specify what=92s in the skipped =
bits in the header, rather than making people figure it out. (=93V-2=94 and=
 Sequence Number)


Also phr=
ases like =93The next 4 bits of the FEC bit str=
ing are written into the CC recovery field in the FEC header=94 should be w=
ritten as like =93The next 4 bits of the=
 FEC bit string are XORed into the CC recovery field in the FEC header=94


 


BTW, I don=92t think the =93FEC bit string=94 nomenc=
lature is all that useful, given that you end up specifying the XOR field b=
y field anyway.


Mo: Agreed, we will clarify this.


>>> 


   The repair packet payload con=
sists of the bits that are generated by


   applying the XOR operation on=
 the payloads of the source RTP packets.


   If the payload lengths of the=
 source packets are not equal, each


   shorter packet MUST be padded=
 to the length of the longest packet by


   adding octet 0's at the end.<=
span>


>>> 


This presumably defines what is placed into the =93r=
epair symbols=94 back in figure 9.  But it doesn=92t say that.


I believe this is incomplete.  It doesn=92t say=
 how to handle extension headers.  It isn=92t clear whether padding oc=
tets are XORed (RFC 3550 says the padding octets =93are not part of the pay=
load=94). SRTP MKI and authentication tag would also
 be recovered (which is not possible in the current draft).

Mo: We will clarify this. We need a good name for th=
e part of the RTP packet after the fixed 12 byte header (CSRC list, extensi=
on header, RTP payload and padding, as described in the second bullet of th=
is section).


>>> 


6.3.2=
. 
 Recovering the RTP Header


This procedure recovers the header of an R=
TP packet up to (and


   including) the SSRC field.


 


>>> 


But it doesn=92t recover the full header, and that s=
hould be more clearly stated,
Mo: Do you mean it can't recover RTP version (assumes 2)? We can clarify th= at. The rest of the header can be recovered.

FWIW, =93if the repair symbols=94 were defined as ru= nning from the first byte after the SSRC to the end of the source RTP packe= t, then the full RTP packet would be recovered =96 including SRTP MKI and a= uthentication tag, which cannot be recovered now.

Mo: Yes, that is the design, we will clarify t= his. Again, a word for that (after SSRC to end, after fixed 12 byte header)= would greatly clarify this.

>>> 

6.3.3= .  Recovering the RTP Payload

 

   2.  For each of the sour=
ce packets that are successfully received in
       T, co=
mpute the bit string from the Y octets of data starting with
       the 1=
3th octet of the packet.  If any of the bit strings
       gener=
ated from the source packets has a length shorter than Y,
       pad t=
hem to that length.  The padding of octet 0 MUST be added at
       the e=
nd of the bit string.  Note that the information of the
      =
 first 8 octets are protected by the FEC header=

>>> 

As is the SSRC, though in a different way.
Mo: Yes, we will note this to avoid any confusion.

>>> 

   2.  For each of the source packets that are successfu= lly received in

       T, compute the bit string from the= Y octets of data starting with

       the 13th octet of the packet. = ; If any of the bit strings

       generated from the source packets = has a length shorter than Y,

       pad them to that length.  The= padding of octet 0 MUST be added at

       the end of the bit string.  N= ote that the information of the

       first 8 octets are protected by th= e FEC header.

 

   3.  For the repair packet in T, compute the FEC bit s= tring from the

       repair packet payload, i.e., the Y= octets of data following the

       FEC header.  Note that the FE= C header may be 12, 16, 32 octets

       depending on the length of the bit= mask.

 

 

   4.  Calculate the recovered bit string as the XOR of = the bit strings

       generated from all source packets = in T and the FEC bit string

       generated from the repair packet i= n T.

 

   5.  Append the recovered bit string (Y octets) to the= new packet

       generated in Section 6.3.2.

>>> 

This is close to the al=
gorithm I suggested above (starting the =93Repair symbols=94 in figure 9 fr=
om the first octet after the SSRC).  
That=92s good, but it i=
sn=92t consistent with the text in 6.2 (=93The =
repair packet payload consists of the bits that are generated by applying t=
he XOR operation on the payloads of the source RTP packets).&=
nbsp; 
So the text as written fails to recover (or fails to generate the repa=
ir packet correctly, depending on how you look at it).
Also, any RTP padding, SRTP MKI + authentication tag in the repair=
 packets themselves shouldn=92t be included in the XOR.  

RTP Padding, RTP MKI and the authentication tag lengths that are part =
of the source packets do need to be taken into account when computing Y.  I=
'm not sure the current FEC header handles that well.





This section uses "FEC Bit String" to mean something d=
ifferent than it meant earlier in the document.





Note the repair algorithms could include authentication of input=
 packets and recovered source packets.


Mo: Yes, "payloads" will be removed, it is overloaded a=
nd incorrect. Again, we need a good word for all bytes after 12.



>>> 




8.  Congestion Control Considerations


 



>>> 


I=92d remove the reference to[I-D.singh-rmcat-adaptive-fec].



Mo: Agreed, we will remove it.



>>> 


However, it MAY still continue to use=
 FEC if considered for bandwidth


   estimation instead of sp=
eculatively probe for additional capacity


   [Hol=
mer13][Nagy14].



>>> 



What does this sentence mean?  The draft doesn=92t talk about using FE=
C for either bandwidth estimation or capacity probing.  I suggest dele=
ting it.



Mo: Agreed, we will remove it. 



>>> 



9<=
/span>. 
 Security Considerations



>>> 





Since the sender of the repair packets might not be the sender of the sourc=
e packets, there is an obvious threat of injection of bogus repair packets.=
  Authentication can be helpful in mitigating that threat.  =




Such authentication (if possible) should be done an any packets that are us=
ed in the recovery process, and also on the reconstructed output packets.









One could strengthen this into "MUST not" normative language if o=
ne wished.


Mo: Agreed, we will =
make it a MUST if the recovered packet can be authenticated (i.e. SRTP=
 source packets). 









NITS



Overall, the document frequently uses first person plural (Suppose we have,=
 If we apply, We generate,  We refer, We assume, =85).  I think t=
he authors should consider rephrasing those sentences.



Mo: We will rephrase ;)



 



Section 1



>>> 



Situations where adaptivitiy



   of FEC parameters is desired, the endpoint can use the in-=
band



   mechanism, whereas when the FEC parameters are fixed, the =
endpoint



   may prefer to negotiate them out-of-band.



>>> 



The sentence uses incorrect grammar.  I suggest



The in-band mechanism is advantageous when the endpoint is adapting the FEC=
 parameters; the out-of-band mechanism may be preferable when the FEC param=
eters are fixed.



Mo: Agreed, we will reword.



Section 1.1



>>> 


In a nutshell,


>>> 



Informal English =96 I suggest rephrasing.



Mo: Agreed, we will remove. 



>>> 



Section 8


However, it MAY still continue to use=
 FEC if considered for bandwidth


   estimation instead of sp=
eculatively probe for additional capacity


   [Hol=
mer13][Nagy14].



>>> 



Probing?



Mo: We will remove this anyway.



 

On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen <ali.bege= n@networked.media> wrote:
Obviously the deadline for the WGLC is Dec. 7th.

-acbegen

> On Nov 17, 2017, at 5:35 AM, Roni Even <roni.even@huawei.com> wrote:
>
> Hi,
> I would like to start a three week WGLC on RTP Payload Format for Flex= ible Forward Error Correction in draft-ietf-payload-flexible-fec-schem= e-05.
> The WGLC will end on November 7th
>
> Mo has posted some clarifications to the payload WG mailing list = payload mailing list archives
>
> Please send comments to the payload mailing list.
> THe double posting is to  notify RTCweb WG that the WGLC has star= ted since this document is needed for RTCweb
>
>
> Roni Even
> Payload WG co-chair
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

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

--_000_D64EF1DF7668Emzanatyciscocom_-- From nobody Fri Dec 8 04:08:42 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70D6124B17 for ; Fri, 8 Dec 2017 04:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk4UDyzpzgVO for ; Fri, 8 Dec 2017 04:08:39 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC62120454 for ; Fri, 8 Dec 2017 04:08:38 -0800 (PST) X-AuditID: c1b4fb25-36dff70000000151-24-5a2a80c422be Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.0E.00337.4C08A2A5; Fri, 8 Dec 2017 13:08:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Fri, 8 Dec 2017 13:08:36 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP examples need to be aligned with latest version of BUNDLE Thread-Index: AQHTcB1FG+1FPu18CUSj8DDCBmYDBg== Date: Fri, 8 Dec 2017 12:08:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D6504F83272D8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7oO6RBq0ogx2zDCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxosP81kKpnNWdPwNb2B8x97FyMkhIWAicfvlR6YuRi4OIYHD jBJfDq5lh3AWM0rsfLWKrYuRg4NNwEKi+582SIOIgLrE5YcXwJqFBdwlGu/sY4eI+0gc2/SH GcLWk+hcsYwFxGYRUJFo7HzGBmLzClhLnOntB6tnFBCT+H5qDROIzSwgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXEFgWaueHEbXaQcyQEFCWW98tBtCZInDg6gQlivKDEyZlPWCYwCs1CMnUW krJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfAYqJ4DyLaWuPiEF1nJAkaOVYyixanFSbnpRsZ6 qUWZycXF+Xl6eaklmxiBUXJwy2/VHYyX3zgeYhTgYFTi4f2fpBUlxJpYVlyZe4hRgoNZSYSX yx8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgZH/d4dP nJBV2fYmx/BrBlLZx7RnudToz5D4ULF442WXaXalD7dUvTqs1XvmzLNrd3muGa1/LFQzq+iz akpunMkewwMnCvnL33eu2JO7eclGu8MqArkpu9OVerj5PxWtao1NOCv78ILysfWOjx/y//bR 2sH+YpNPxcSLl0ruBPLN0269tnqZXpkSS3FGoqEWc1FxIgD51CVLjgIAAA== Archived-At: Subject: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 12:08:41 -0000 --_000_D6504F83272D8christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At some point some of the examples in section 7 of JSEP need to be updated,= in order to align with the latest version of BUNDLE. Regards, Christer --_000_D6504F83272D8christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9576F49A16F09B4EB5278AFFB7A5C1AB@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

At some point some of the examples in section 7 of JSEP need to be upd= ated, in order to align with the latest version of BUNDLE.

Regards,

Christer


--_000_D6504F83272D8christerholmbergericssoncom_-- From nobody Fri Dec 8 04:48:40 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46786124B17; Fri, 8 Dec 2017 04:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I97wrQIwAUGE; Fri, 8 Dec 2017 04:48:30 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E795C124D68; Fri, 8 Dec 2017 04:48:29 -0800 (PST) X-AuditID: c1b4fb3a-3d5ff70000003538-b5-5a2a8a1b3558 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.91.13624.B1A8A2A5; Fri, 8 Dec 2017 13:48:28 +0100 (CET) Received: from [147.214.162.243] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 8 Dec 2017 13:48:27 +0100 To: Roni Even , "payload@ietf.org" CC: "rtcweb@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: Date: Fri, 8 Dec 2017 13:50:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060606050603090003020403" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7lK5Ml1aUQU8jq8Wli2eZLD4dO89i sfZfO7sDs0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgynh3oIWtYN0vxor2ed9ZGhiXXmDs YuTkkBAwkei8dB7I5uIQEjjMKPFj0TZ2CGczo0TL/Q4mkCphgQiJ549us4HYIgLeEhunH2cH sZkF1CXuLD4HZgsJBEv8vDEBrJ5NwELi5o9GsHpeAXuJz2ePgm1jEVCRODJnMSuILSoQI3G4 ZzorRI2gxMmZT1hAbE6BEImlj/tZQI5gFuhmlNjw8h0rxAJtiYamDlaIs5Ukrs+7zjKBUWAW kv5ZyHpmgR0YJrHj4QUmCFtcounLSqi4rcSdubuZIWxtiWULX0PZuhKLtq1gxxS3lpjx6yAb hK0oMaX7IVSNqcTrox8ZIWwjiXd7GtkXMPKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiM wYNbflvtYDz43PEQowAHoxIP77okrSgh1sSy4srcQ4wqQHMebVh9gVGKJS8/L1VJhJfLHyjN m5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBUXyN9Ksls/QU J/2ziryb6SB1IntrsMm/MwEbfiuvjZOoudfe27qam3P7v0sLHr8zftHy72kKS7yRzT8Hr7e1 5ruTMiY8j5pfmtGkW9cfvSqyoexVYOu368xzzpU8qti25fZ6kZ3GT69o/9e83HLghpcGw3eZ i7J9LxizN7RVtP1d8cM0691bIyWW4oxEQy3mouJEAGXQwKzJAgAA Archived-At: Subject: Re: [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 12:48:34 -0000 --------------ms060606050603090003020403 Content-Type: multipart/alternative; boundary="------------FAE74EA59A17C036B41BDBDD" Content-Language: en-GB This is a multi-part message in MIME format. --------------FAE74EA59A17C036B41BDBDD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Sorry for being a day late, but here are my WGLC comments. I thought this was in better shape, but clearly not ready. I actually=20 have not reviewed all in detail. I hope I will have time to do that when = you have addressed these issues. 1. Section 4.2: =A0 =A0=A0 =A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP Header= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Transport Header=A0= =A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 | __ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 FEC Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= =A0=A0 > RTP Payload =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 Repair Symbols=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ __| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9: Form= at of repair packets The bracket appears to big as it indicates that parts of the RTP header=20 is payload. I would prefer drawing this like this: =A0=A0=A0=A0=A0=A0 =A0 =A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP Header= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Transport Header=A0= =A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ --+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 FEC Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= =A0=A0 > RTP Payload =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 Repair Symbols=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ --+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9: Form= at of repair packets 2. Section 4.2: =A0=A0 o=A0 Synchronization Source (SSRC): The SSRC value SHALL be rando= mly =A0=A0=A0=A0=A0 assigned as suggested by [RFC3550]. I would suggest that you make it clear that the SSRC value should be set = randomly for a particular Repair flow, to avoid the misinterpretation=20 that each packet should have a random SSRC value. 3. Section 4.2: This allows the sender to =A0=A0=A0=A0=A0 multiplex the source and repair flows on the same port, = or =A0=A0=A0=A0=A0 multiplex multiple repair flows on a single port. I would suggest that you rewrite this like this: This allows the sender to =A0=A0=A0=A0=A0 multiplex the source and repair flows in the same RTP se= ssion, or =A0=A0=A0=A0=A0 multiplex multiple repair flows in a single RTP session.= 4. Section 4.2: The repair =A0=A0=A0=A0=A0 flows SHOULD use the RTCP CNAME field to associate thems= elves with =A0=A0=A0=A0=A0 the source flow. I think you should reformulate this to be more precise to say: The repair =A0=A0=A0=A0=A0 flows SHOULD use the same RTCP SDES CNAME value as the s= ource=20 flows to associate them when source and repair flows originate from the same endpoint. 5. Section 4.2: =A0=A0=A0=A0=A0 In some networks, the RTP Source, which produces the sou= rce =A0=A0=A0=A0=A0 packets and the FEC Source, which generates the repair p= ackets =A0=A0=A0=A0=A0 from the source packets may not be the same host.=A0 In = such =A0=A0=A0=A0=A0 scenarios, using the same CNAME for the source and repai= r flows =A0=A0=A0=A0=A0 means that the RTP Source and the FEC Source MUST share = the same =A0=A0=A0=A0=A0 CNAME (for this specific source-repair flow association)= =2E=A0 A =A0=A0=A0=A0=A0 common CNAME may be produced based on an algorithm that = is known =A0=A0=A0=A0=A0 both to the RTP and FEC Source [RFC7022].=A0 This usage = is compliant =A0=A0=A0=A0=A0 with [RFC3550]. I think this may actually be the wrong way of handling this. Is it=20 really important that the CNAME can be used to determine which SSRC are=20 plausible as source flows for a given repair flow. If we skip that=20 feature, one can use CNAMES as usual where they are primarily depending=20 on the endpoint that originates the RTP flow with a given SSRC and the=20 synchronization context. As the repair packet is indicating explicitly=20 which source packets, this should not be a real issue. Thus, I suggest that the above text removes sentence with MUST. Instead=20 one could add the following sentence directly after the propsed sentence = in issue 4: However, repair flows that protects source flows from multiple different = endpoints SHOULD instead use a CNAME value associated with the Repair=20 Flow sending endpoint. And the above text could be deleted. 6. Section 4.2: Figure 9 should include the CSRC list and the FEC payload formats use of = the CSRC list should be listed prior to Figure 10. This as the CSRC list = is part of the RTP header. 7. Section 4.2: =A0=A0 o=A0 The SN base_i (16 bits) field indicates the lowest sequence =A0=A0=A0=A0=A0 number, taking wrap around into account, of the source p= ackets for =A0=A0=A0=A0=A0 a particular SSSRC (indicated in CSRC_i) protected by th= is repair =A0=A0=A0=A0=A0 packet. Note spelling SSSRC / SSRC. 8. Label on Figures 12, 13, 15: They all says "Protocol format for ..." While I think for clarity they should say: "Payload FEC header format=20 for ..." 9. Section 4.2: =A0=A0 Note that the parsing of this packet is different.=A0 The sequenc= e =A0=A0 number (SN base_i) replaces the length recovery in the FEC packet= =2E =A0=A0 The CSRC Count (CC) which would be 1, M and N would be set to 0, = and =A0=A0 the reserved bits from the FEC header are removed.=A0 By doing th= is, we =A0=A0 save 64 bits. I actually don't fully understand this paragraph: In the third sentence: Why will the CC field be 1? This is the CC field=20 value of the reconstructed (retransmitted) packet, isn't it? Thus, you=20 can't say anything about its original value here? The CC field value in=20 the RTP header of the FEC packet will have CC =3D 1, but not this field. Then you have a confusion around what M and N is. Actually, I think the=20 M (Columns) needs to change letter to something that isn't used in the=20 packet already. M is colliding with M (marker bit) recovery field, thus=20 please change the letter. 10. Figure 15: When retransmitting an packet, where is the source packets CSRC list=20 going? That should be indicated in this figure for clarity. Same is true = for RTP header Extensions present in the source packet. 11. Section 6.2: =A0=A0 The FEC header includes 12 octets (or upto 28 octets when the lon= ger =A0=A0 optional masks are used). This is not strictly true, it is dependent on the number of SSRCs that=20 the packet repairs. 12. Section 6.2: Missing discussion of what to do with source packet CSRC list and RTP=20 header extension. 13. Section 6.3.2: Missing text for recovery of source packets CSRC list and RTP header=20 extensions. 14. Section 6.2: =A0=A0 Due to this possible padding and mandatory FEC header, a repair =A0=A0 packet has a larger size than the source packets it protects. Thi= s =A0=A0 may cause problems if the resulting repair packet size exceeds th= e =A0=A0 Maximum Transmission Unit (MTU) size of the path over which the =A0=A0 repair flow is sent. I think this should add a recommendation that the media encoding and RTP = payload packetization for source packets should be adjusted to a lower=20 maximum packet size to allow space for the FEC headers to avoid forcing=20 them into being fragmented. This of course only is possible in cases=20 where the source packet generating endpoint is aware of the addition of=20 the FEC packets and its strategy of combining them. Cheers Magnus Den 2017-11-17 kl. 03:35, skrev Roni Even: > > Hi, > > I would like to start a three week WGLC on RTP Payload Format for=20 > Flexible Forward Error Correction in=20 > draft-ietf-payload-flexible-fec-scheme-05=20 > = =2E > > The WGLC will end on November 7^th > > Mo has posted some clarifications to the payload WG mailing list=20 > payload mailing list archives=20 > > > Please send comments to the payload mailing list. > > THe double posting is to =A0notify RTCweb WG that the WGLC has started = > since this document is needed for RTCweb > > Roni Even > > Payload WG co-chair > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------FAE74EA59A17C036B41BDBDD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually have not reviewed all in detail. I hope I will have time to do that when you have addressed these issues.


1. Section 4.2:

=A0 =A0=A0 =A0=A0=A0=A0=A0=A0 +------------------------------+=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 IP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Tran= sport Header=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 RTP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 | __
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 FEC Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0=A0=A0 > RTP Payload
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 R= epair Symbols=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 /
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ __|

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9:= Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header is payload. I would prefer drawing this like this:

=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 +------------------------------+=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 IP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Tran= sport Header=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 RTP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ --+=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 FEC Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0=A0=A0 > RTP Payload
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 R= epair Symbols=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 /
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ --+

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Figure 9: Format of repair packets

2. Section 4.2:

=A0=A0 o=A0 Synchronization Source (SSRC): The SSRC value SHALL be= randomly
=A0=A0=A0=A0=A0 assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set randomly for a particular Repair flow, to avoid the misinterpretation that each packet should have a random SSRC value.

3. Section 4.2:

This allows the sender to
=A0=A0=A0=A0=A0 multiplex the source and repair flows on the same p= ort, or
=A0=A0=A0=A0=A0 multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
=A0=A0=A0=A0=A0 multiplex the source and repair flows in the same R= TP session, or
=A0=A0=A0=A0=A0 multiplex multiple repair flows in a single RTP ses= sion.

4. Section 4.2:

The repair
=A0=A0=A0=A0=A0 flows SHOULD use the RTCP CNAME field to associate themselves with
=A0=A0=A0=A0=A0 the source flow.

I think you should reformulate this to be more precise to say:

=

The repair
=A0=A0=A0=A0=A0 flows SHOULD use the same RTCP SDES CNAME value as = the source flows to associate them when
source and repair flows originate from the same endpoint.


5. Section 4.2:

=A0=A0=A0=A0=A0 In some networks, the RTP Source, which produces t= he source
=A0=A0=A0=A0=A0 packets and the FEC Source, which generates the rep= air packets
=A0=A0=A0=A0=A0 from the source packets may not be the same host.=A0= In such
=A0=A0=A0=A0=A0 scenarios, using the same CNAME for the source and = repair flows
=A0=A0=A0=A0=A0 means that the RTP Source and the FEC Source MUST s= hare the same
=A0=A0=A0=A0=A0 CNAME (for this specific source-repair flow associa= tion).=A0 A
=A0=A0=A0=A0=A0 common CNAME may be produced based on an algorithm = that is known
=A0=A0=A0=A0=A0 both to the RTP and FEC Source [RFC7022].=A0 This u= sage is compliant
=A0=A0=A0=A0=A0 with [RFC3550].

I think this may actually be the wrong way of handling this. Is it really important that the CNAME can be used to determine which SSRC are plausible as source flows for a given repair flow. If we skip that feature, one can use CNAMES as usual where they are primarily depending on the endpoint that originates the RTP flow with a given SSRC and the synchronization context. As the repair packet is indicating explicitly which source packets, this should not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead one could add the following sentence directly after the propsed sentence in issue 4:

However, repair flows that protects source flows from multiple different endpoints SHOULD instead use a CNAME value associated with the Repair Flow sending endpoint.

And the above text could be deleted.


6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of the CSRC list should be listed prior to Figure 10. This as the CSRC list is part of the RTP header.

7. Section 4.2:

=A0=A0 o=A0 The SN base_i (16 bits) field indicates the lowest seq= uence
=A0=A0=A0=A0=A0 number, taking wrap around into account, of the sou= rce packets for
=A0=A0=A0=A0=A0 a particular SSSRC (indicated in CSRC_i) protected = by this repair
=A0=A0=A0=A0=A0 packet.

Note spelling SSSRC / SSRC.

8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format for ..."

9. Section 4.2:

=A0=A0 Note that the parsing of this packet is different.=A0 The sequence
=A0=A0 number (SN base_i) replaces the length recovery in the FEC packet.
=A0=A0 The CSRC Count (CC) which would be 1, M and N would be set t= o 0, and
=A0=A0 the reserved bits from the FEC header are removed.=A0 By doi= ng this, we
=A0=A0 save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field value of the reconstructed (retransmitted) packet, isn't it? Thus, you can't say anything about its original value here? The CC field value in the RTP header of the FEC packet will have CC =3D 1,= but not this field.=A0

Then you have a confusion around what M and N is. Actually, I think the M (Columns) needs to change letter to something that isn't used in the packet already. M is colliding with M (marker bit) recovery field, thus please change the letter.

10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list going? That should be indicated in this figure for clarity. Same is true for RTP header Extensions present in the source packet.

11. Section 6.2:

=A0=A0 The FEC header includes 12 octets (or upto 28 octets when t= he longer
=A0=A0 optional masks are used).=A0

This is not strictly true, it is dependent on the number of SSRCs that the packet repairs.

12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP header extension.

13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header extensions.

14. Section 6.2:

=A0=A0 Due to this possible padding and mandatory FEC header, a repair
=A0=A0 packet has a larger size than the source packets it protects= =2E=A0 This
=A0=A0 may cause problems if the resulting repair packet size excee= ds the
=A0=A0 Maximum Transmission Unit (MTU) size of the path over which = the
=A0=A0 repair flow is sent.

I think this should add a recommendation that the media encoding and RTP payload packetization for source packets should be adjusted to a lower maximum packet size to allow space for the FEC headers to avoid forcing them into being fragmented. This of course only is possible in cases where the source packet generating endpoint is aware of the addition of the FEC packets and its strategy of combining them.

Cheers

Magnus



Den 2017-11-17 kl. 03:35, skrev Roni Even:

Hi,

I would like to start a three week WGLC on= RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.<= /o:p>

The WGLC will end on November 7th

=A0

Mo has posted some clarifications to the payload WG mailing list =A0payload mailing list archives

=A0

Please send comments to the payload mailin= g list.

THe double posting is to =A0notify RTCweb WG that the WGLC has started since this document is needed for RTCweb

=A0=

=A0=

Roni Even=

Payload WG co-chair

=A0=

=A0



_______________________________________________
rtcweb mailing list
rtc=
web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------FAE74EA59A17C036B41BDBDD--

--------------ms060606050603090003020403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzEyMDgxMjUwNTBaMC8GCSqGSIb3DQEJBDEiBCAaS7ALooeleiw55BVO
0QDP8U6mYkU3eodbYXxBJMhytDBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAhpx5JMKxcUF2NiSX3UKXJ+LvYpjwx5DGqCK0Ac4k3ad/wEiG
yh13GdOrEPLl2rl2V9TX88mCy+l4JZ6NPKHxC00qFPBKnR3AiID1I3353DYc7DbH0wQP4aNi
wZTKKmgVzvO/vQvu+JitXAVv6frjSsM2IgiAhu8GE9dhPta4/Y/ZpEO1e3nePocSgUTb8C5+
iHTtcccs4LPGs9U8SYSfYtkk6Z5pXfyqzn0siy1q6nsA+9s6aNu3t1FHW8E4lYPNkIFgAOxj
uix7r5IChbdALRFnC3iVUKi3tvG9q1BFQEp3lEbtCjiLhM9f9cmErvEgx7TzXZ4dDRQUYcUf
+RwQnwAAAAAAAA==
--------------ms060606050603090003020403--


From nobody Fri Dec  8 08:32:13 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A9126D05 for ; Fri,  8 Dec 2017 08:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzAflfs4CNYp for ; Fri,  8 Dec 2017 08:32:10 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8695D124D68 for ; Fri,  8 Dec 2017 08:32:10 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id h2so7836650uae.12 for ; Fri, 08 Dec 2017 08:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IHB6nB5PEd+fUjc8/d+IyMCcZpYtPtLbTIMSWs7f58E=; b=Gugx1xEgBTnf/smrPs4+NgD36+PgmEoG3M6SlrIPE7Dm4KH67vb8qHLvePHevJDVYp MMT3cOqp2Fw6WPrZye2bgBESekNOgfV9FYQ2es92aisANDRhLO3aBNzqavdv0aizJOaR csKxA1uG5ttGfNI5BgzyVBfNMEJr7bpKQnzAGfAjbV6JLbUF1ssW3PbEJ/tZH2+jxGes 6RU4bns1cZqhavktDur5R78XlAtC8IwdTdpx5yT12l8YLyBd3HZaXQP4DUhqpkj0cLDa 9R3xVtz2Bi/0N4eX/ex8Yiiy80bibt5K1+7j4gxYEcNKfbMsUbg/y68eJfhbvZHHFjau BQmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IHB6nB5PEd+fUjc8/d+IyMCcZpYtPtLbTIMSWs7f58E=; b=seclw8cQ10B1I4IUA9pPGp0xEi21qaY94xSZZ/rPFMMFaGRlILHdOeJkDzW61jHMhJ m/8c5CbwU2gwnmtz+GXHlwB5P5wDdzwR1OCxjFltdhE/RHzG88N/kfEoY/Dc6+fyjzDm SSuQL69EPCaS6NG1D5ekOwYOnq5/qmtylORHJTXpYDmJ2al5ldgrJgufeh7/jLc8efbG zh76uRGgzidAtw/jZV/C4+sidtF6eVzhMrMJAtFKLdfrWlUPlLeGg0DP2HieeGTghmsm U4n8UWpsV08/tqn3Tixd0X8PmzYe7WaCz4jRnXRmau5h/TUHE4uS/gTa6p3WiMfZZrA8 T0wA==
X-Gm-Message-State: AKGB3mJDlgCYHd4qeQwruUoMKv4DDAnUWAC8H9RpoO2HrZ98uXuZW3BQ bS4DrhdkY17dUB9d0HJyQwGIq3lnIRjBUBDA+VfNrA==
X-Google-Smtp-Source: AGs4zMZy8k2ynpQtKP9sUFPhde1wpHJx96DI9MOYoaRIaOlFsonyeRdY62W02HBMbbPm+ehIyxY8bSl7m0jh8jSp6tk=
X-Received: by 10.159.51.2 with SMTP id o2mr18631278uab.194.1512750729053; Fri, 08 Dec 2017 08:32:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Fri, 8 Dec 2017 08:31:48 -0800 (PST)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Fri, 8 Dec 2017 08:31:48 -0800
Message-ID: 
To: Christer Holmberg 
Cc: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045dcc9cd7c5e9055fd6b964"
Archived-At: 
Subject: Re: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Dec 2017 16:32:13 -0000

--f403045dcc9cd7c5e9055fd6b964
Content-Type: text/plain; charset="UTF-8"

Christer, can you summarize the differences? I will file an issue against
JSEP.

On Fri, Dec 8, 2017 at 4:08 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> At some point some of the examples in section 7 of JSEP need to be
> updated, in order to align with the latest version of BUNDLE.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--f403045dcc9cd7c5e9055fd6b964
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Christer, can you summarize the differences? I will file a=
n issue against JSEP.

On Fri, Dec 8, 2017 at 4:08 AM, Christer Holmberg <=
christer.holmberg@ericsson.com> wrote:







Hi,







At some point some of the examples in section 7 of JSEP need to be upd=
ated, in order to align with the latest version of BUNDLE.







Regards,







Christer















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--f403045dcc9cd7c5e9055fd6b964--


From nobody Fri Dec  8 10:52:44 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AE3128B38; Fri,  8 Dec 2017 10:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-SiZG_hNqRi; Fri,  8 Dec 2017 10:52:34 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A34128B8E; Fri,  8 Dec 2017 10:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32185; q=dns/txt; s=iport; t=1512759154; x=1513968754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D6ioEaPly2C/UqpwDqT7GAdGGyIo5w965SDsW6rv5Bo=; b=ZhdisYbWBC86ILrlXAJdEL0ijAEjmzPCwhQ7CXD/aTbrQ736pLOGyICc C9D5HpNSr+WBxkO+M1IKKGFXm00Q/8Nd+BpqwsrbUIf9QfJc70nGeA/Kw 0k6AHsKXsGLDI15EF2x8bblIXKNgzBs6NYygHRm96yBS0rTz/FyVCtplR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AADu3Spa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mdCcHjhyPAYF9lwwUggEKGAEKhElPAoRfPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQMBAStBCw4CAgEIEQMBAhYLBwcbDAsUCQgCBAENBQmJO2QQq?= =?us-ascii?q?jMmij4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYNWgguBVoFpgyuCWEsmgRERHDg?= =?us-ascii?q?fhTkFikWYQwKHd40nghaGEos5ikCCSIknAhEZAYE6AR85JoEpbxU6gikJgkYfG?= =?us-ascii?q?YFOeIkhgRUBAQE?=
X-IronPort-AV: E=Sophos; i="5.45,378,1508803200"; d="scan'208,217"; a="41626922"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 18:52:33 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB8IqXMF016055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 18:52:33 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 12:52:32 -0600
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 12:52:32 -0600
From: "Mo Zanaty (mzanaty)" 
To: Magnus Westerlund , Roni Even , "payload@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction
Thread-Index: AQHTcFW0HojzYcah6EWMBE4vaDiXiA==
Date: Fri, 8 Dec 2017 18:52:32 +0000
Message-ID: 
References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.217.90]
Content-Type: multipart/alternative; boundary="_000_D65040BB7693Dmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Dec 2017 18:52:38 -0000

--_000_D65040BB7693Dmzanatyciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Magnus,

Thank you for the review and comments. We are updating the draft to address=
 your comments as noted below (see Mo: inline).

Thanks,
Mo


From: payload > o=
n behalf of 'Magnus Westerlund' >
Date: Friday, December 8, 2017 at 7:50 AM
To: Roni Even >, "payload=
@ietf.org" >
Cc: "rtcweb@ietf.org" >
Subject: Re: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible For=
ward Error Correction


Hi,

Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually have =
not reviewed all in detail. I hope I will have time to do that when you hav=
e addressed these issues.


1. Section 4.2:

            +------------------------------+
            |          IP Header           |
            +------------------------------+
            |       Transport Header       |
            +------------------------------+
            |          RTP Header          | __
            +------------------------------+   |
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ __|

                    Figure 9: Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header is =
payload. I would prefer drawing this like this:

            +------------------------------+
            |          IP Header           |
            +------------------------------+
            |       Transport Header       |
            +------------------------------+
            |          RTP Header          |
            +------------------------------+ --+
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ --+

                    Figure 9: Format of repair packets

Mo: Agreed, we will update the ASCII art.


2. Section 4.2:

   o  Synchronization Source (SSRC): The SSRC value SHALL be randomly
      assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set ra=
ndomly for a particular Repair flow, to avoid the misinterpretation that ea=
ch packet should have a random SSRC value.

Mo: Agreed, will do.


3. Section 4.2:

This allows the sender to
      multiplex the source and repair flows on the same port, or
      multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
      multiplex the source and repair flows in the same RTP session, or
      multiplex multiple repair flows in a single RTP session.

Mo: Agreed, we will reword as suggested.


4. Section 4.2:

The repair
      flows SHOULD use the RTCP CNAME field to associate themselves with
      the source flow.

I think you should reformulate this to be more precise to say:

The repair
      flows SHOULD use the same RTCP SDES CNAME value as the source flows t=
o associate them when
source and repair flows originate from the same endpoint.

Mo: Per the point below, I am inclined to remove CNAME guidance or restrict=
ions entirely, since they seem irrelevant.


5. Section 4.2:

      In some networks, the RTP Source, which produces the source
      packets and the FEC Source, which generates the repair packets
      from the source packets may not be the same host.  In such
      scenarios, using the same CNAME for the source and repair flows
      means that the RTP Source and the FEC Source MUST share the same
      CNAME (for this specific source-repair flow association).  A
      common CNAME may be produced based on an algorithm that is known
      both to the RTP and FEC Source [RFC7022].  This usage is compliant
      with [RFC3550].

I think this may actually be the wrong way of handling this. Is it really i=
mportant that the CNAME can be used to determine which SSRC are plausible a=
s source flows for a given repair flow. If we skip that feature, one can us=
e CNAMES as usual where they are primarily depending on the endpoint that o=
riginates the RTP flow with a given SSRC and the synchronization context. A=
s the repair packet is indicating explicitly which source packets, this sho=
uld not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead one=
 could add the following sentence directly after the propsed sentence in is=
sue 4:

However, repair flows that protects source flows from multiple different en=
dpoints SHOULD instead use a CNAME value associated with the Repair Flow se=
nding endpoint.

And the above text could be deleted.

Mo: Since all source and repair streams must be in the same RTP session, I =
agree CNAME is mostly irrelevant, and I am inclined to remove all mention o=
f CNAME, except maybe to say it should follow RFC 7022.


6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of th=
e CSRC list should be listed prior to Figure 10. This as the CSRC list is p=
art of the RTP header.

Mo: Agreed, the text on CSRC_i / list will move up before Figure 10.


7. Section 4.2:

   o  The SN base_i (16 bits) field indicates the lowest sequence
      number, taking wrap around into account, of the source packets for
      a particular SSSRC (indicated in CSRC_i) protected by this repair
      packet.

Note spelling SSSRC / SSRC.

Mo: Noted.


8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format for .=
.."

Mo: Ok, we will rename the labels.


9. Section 4.2:

   Note that the parsing of this packet is different.  The sequence
   number (SN base_i) replaces the length recovery in the FEC packet.
   The CSRC Count (CC) which would be 1, M and N would be set to 0, and
   the reserved bits from the FEC header are removed.  By doing this, we
   save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field val=
ue of the reconstructed (retransmitted) packet, isn't it? Thus, you can't s=
ay anything about its original value here? The CC field value in the RTP he=
ader of the FEC packet will have CC =3D 1, but not this field.

Then you have a confusion around what M and N is. Actually, I think the M (=
Columns) needs to change letter to something that isn't used in the packet =
already. M is colliding with M (marker bit) recovery field, thus please cha=
nge the letter.

Mo: We will clarify this by splitting into separate sections for each repai=
r format variant, and perhaps use L/D instead of M/N (to match the SDP para=
meters L/D).


10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list going?=
 That should be indicated in this figure for clarity. Same is true for RTP =
header Extensions present in the source packet.

Mo: We will clarify this by splitting into separate sections for each repai=
r format variant. For all variants, all bytes after 12 (including any CSRC =
list or extension headers) are considered "payload" (we will find a better =
word for this since payload is obviously very overloaded).


11. Section 6.2:

   The FEC header includes 12 octets (or upto 28 octets when the longer
   optional masks are used).

This is not strictly true, it is dependent on the number of SSRCs that the =
packet repairs.

Mo: Yes, we will clarify this.


12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP heade=
r extension.

Mo: Yes, the updates to section 4.2 will be echoed in 6.2.


13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header extens=
ions.

Mo: Yes, we will add this.


14. Section 6.2:

   Due to this possible padding and mandatory FEC header, a repair
   packet has a larger size than the source packets it protects.  This
   may cause problems if the resulting repair packet size exceeds the
   Maximum Transmission Unit (MTU) size of the path over which the
   repair flow is sent.

I think this should add a recommendation that the media encoding and RTP pa=
yload packetization for source packets should be adjusted to a lower maximu=
m packet size to allow space for the FEC headers to avoid forcing them into=
 being fragmented. This of course only is possible in cases where the sourc=
e packet generating endpoint is aware of the addition of the FEC packets an=
d its strategy of combining them.

Mo: Agreed, this seems like an appropriate recommendation, so we will add i=
t.


Cheers

Magnus


Den 2017-11-17 kl. 03:35, skrev Roni Even:
Hi,
I would like to start a three week WGLC on RTP Payload Format for Flexible =
Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.
The WGLC will end on November 7th

Mo has posted some clarifications to the payload WG mailing list  payload m=
ailing list archives

Please send comments to the payload mailing list.
THe double posting is to  notify RTCweb WG that the WGLC has started since =
this document is needed for RTCweb


Roni Even
Payload WG co-chair





_______________________________________________
rtcweb mailing list
rtcweb@ietf.orghttps://www.ietf.org/mailman/listinf=
o/rtcweb


--

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_D65040BB7693Dmzanatyciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <56E745B5E32A664287FEDE446939460A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Magnus,











Thank you for the review and comments. We are updating the draft to ad=
dress your comments as noted below (see Mo: inline).







Thanks,


Mo


















From: payload <payload-bounces@ietf.org> on behalf of 'M=
agnus Westerlund' <mag=
nus.westerlund@ericsson.com>

Date: Friday, December 8, 2017 at 7=
:50 AM

To: Roni Even <roni.even@huawei.com>, "payload@ietf.org" <payload@ietf.org>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [payload] [rtcweb] WGL=
C on RTP Payload Format for Flexible Forward Error Correction













Hi,


Sorry for being a day late, but here are my WGLC comments.


I thought this was in better shape, but clearly not ready. I actually ha=
ve not reviewed all in detail. I hope I will have time to do that when you =
have addressed these issues.










1. Section 4.2:




            +------=
------------------------+

           =
 |          IP Header &nb=
sp;         |

           =
 +------------------------------+

           =
 |       Transport Header   &n=
bsp;   |

           =
 +------------------------------+

           =
 |          RTP Header &n=
bsp;        | __

           =
 +------------------------------+   |

           =
 |          FEC Header &n=
bsp;        |    \

           =
 +------------------------------+     > RTP =
Payload

           =
 |        Repair Symbols  &nbs=
p;     |    /

           =
 +------------------------------+ __|



            &nb=
sp;       Figure 9: Format of repair packets<=
br>



The bracket appears to big as it indicates that parts of the RTP header =
is payload. I would prefer drawing this like this:


            +------=
------------------------+

           =
 |          IP Header &nb=
sp;         |

           =
 +------------------------------+

           =
 |       Transport Header   &n=
bsp;   |

           =
 +------------------------------+

           =
 |          RTP Header &n=
bsp;        | 

           =
 +------------------------------+ --+  

           =
 |          FEC Header &n=
bsp;        |    \

           =
 +------------------------------+     > RTP =
Payload

           =
 |        Repair Symbols  &nbs=
p;     |    /

           =
 +------------------------------+ --+



           =
         Figure 9: Format of repair=
 packets














Mo: Agreed, we will update the ASCII art.












2. Section 4.2:


   o  Synchronization Source (SSRC): The SSRC value SHALL=
 be randomly

      assigned as suggested by [RFC3550]. 




I would suggest that you make it clear that the SSRC value should be set=
 randomly for a particular Repair flow, to avoid the misinterpretation that=
 each packet should have a random SSRC value.













Mo: Agreed, will do.












3. Section 4.2:


This allows the sender to

      multiplex the source and repair flows on the=
 same port, or

      multiplex multiple repair flows on a single =
port.


I would suggest that you rewrite this like this:


This allows the sender to

      multiplex the source and repair flows in the=
 same RTP session, or

      multiplex multiple repair flows in a single =
RTP session.












Mo: Agreed, we will reword as suggested.












4. Section 4.2:


The repair

      flows SHOULD use the RTCP CNAME field to ass=
ociate themselves with

      the source flow.


I think you should reformulate this to be more precise to say:


The repair

      flows SHOULD use the same RTCP SDES CNAME va=
lue as the source flows to associate them when

source and repair flows originate from the same endpoint. 




Mo: Per the point below, I am inclined to remove CNAME guidance or restr=
ictions entirely, since they seem irrelevant.

















5. Section 4.2:


      In some networks, the RTP Source, which p=
roduces the source

      packets and the FEC Source, which generates =
the repair packets

      from the source packets may not be the same =
host.  In such

      scenarios, using the same CNAME for the sour=
ce and repair flows

      means that the RTP Source and the FEC Source=
 MUST share the same

      CNAME (for this specific source-repair flow =
association).  A

      common CNAME may be produced based on an alg=
orithm that is known

      both to the RTP and FEC Source [RFC7022].&nb=
sp; This usage is compliant

      with [RFC3550].




I think this may actually be the wrong way of handling this. Is it reall=
y important that the CNAME can be used to determine which SSRC are plausibl=
e as source flows for a given repair flow. If we skip that feature, one can=
 use CNAMES as usual where they
 are primarily depending on the endpoint that originates the RTP flow with =
a given SSRC and the synchronization context. As the repair packet is indic=
ating explicitly which source packets, this should not be a real issue.





Thus, I suggest that the above text removes sentence with MUST. Instead =
one could add the following sentence directly after the propsed sentence in=
 issue 4:


However, repair flows that protects source flows from multiple different=
 endpoints SHOULD instead use a CNAME value associated with the Repair Flow=
 sending endpoint.


And the above text could be deleted. 




Mo: Since all source and repair streams must be in the same RTP session,=
 I agree CNAME is mostly irrelevant, and I am inclined to remove all mentio=
n of CNAME, except maybe to say it should follow RFC 7022.

















6. Section 4.2: 




Figure 9 should include the CSRC list and the FEC payload formats use of=
 the CSRC list should be listed prior to Figure 10. This as the CSRC list i=
s part of the RTP header.








Mo: Agreed, the text on CSRC_i / list will move up before Figure 10.&n=
bsp;












7. Section 4.2:


   o  The SN base_i (16 bits) field indicates the lowest =
sequence

      number, taking wrap around into account, of =
the source packets for

      a particular SSSRC (indicated in CSRC_i) pro=
tected by this repair

      packet.


Note spelling SSSRC / SSRC.












Mo: Noted.












8. Label on Figures 12, 13, 15:


They all says "Protocol format for ..."


While I think for clarity they should say: "Payload FEC header form=
at for ..."












Mo: Ok, we will rename the labels.












9. Section 4.2:


   Note that the parsing of this packet is different.  Th=
e sequence

   number (SN base_i) replaces the length recovery in the FEC pac=
ket.

   The CSRC Count (CC) which would be 1, M and N would be set to =
0, and

   the reserved bits from the FEC header are removed.  By do=
ing this, we

   save 64 bits.




I actually don't fully understand this paragraph: 




In the third sentence: Why will the CC field be 1? This is the CC field =
value of the reconstructed (retransmitted) packet, isn't it? Thus, you can'=
t say anything about its original value here? The CC field value in the RTP=
 header of the FEC packet will have
 CC =3D 1, but not this field. 


Then you have a confusion around what M and N is. Actually, I think the =
M (Columns) needs to change letter to something that isn't used in the pack=
et already. M is colliding with M (marker bit) recovery field, thus please =
change the letter.













Mo: We will clarify this by splitting into separate sections for each =
repair format variant, and perhaps use L/D instead of M/N (to match the SDP=
 parameters L/D).












10. Figure 15:


When retransmitting an packet, where is the source packets CSRC list goi=
ng? That should be indicated in this figure for clarity. Same is true for R=
TP header Extensions present in the source packet.








Mo: We will clarify this by splitting into separate sections for each =
repair format variant. For all variants, all bytes after 12 (including any =
CSRC list or extension headers) are considered "payload" (we will=
 find a better word for this since payload
 is obviously very overloaded).












11. Section 6.2:


   The FEC header includes 12 octets (or upto 28 octets when t=
he longer

   optional masks are used).  




This is not strictly true, it is dependent on the number of SSRCs that t=
he packet repairs.












Mo: Yes, we will clarify this.












12. Section 6.2:


Missing discussion of what to do with source packet CSRC list and RTP he=
ader extension.








Mo: Yes, the updates to section 4.2 will be echoed in 6.2.












13. Section 6.3.2:


Missing text for recovery of source packets CSRC list and RTP header ext=
ensions.








Mo: Yes, we will add this.












14. Section 6.2:


   Due to this possible padding and mandatory FEC header, a re=
pair

   packet has a larger size than the source packets it protects.&=
nbsp; This

   may cause problems if the resulting repair packet size exceeds=
 the

   Maximum Transmission Unit (MTU) size of the path over which th=
e

   repair flow is sent.


I think this should add a recommendation that the media encoding and RTP=
 payload packetization for source packets should be adjusted to a lower max=
imum packet size to allow space for the FEC headers to avoid forcing them i=
nto being fragmented. This of course
 only is possible in cases where the source packet generating endpoint is a=
ware of the addition of the FEC packets and its strategy of combining them.








Mo: Agreed, this seems like an appropriate recommendation, so we will =
add it.












Cheers


Magnus











Den 2017-11-17 kl. 03:35, skrev Roni Even:









Hi,


I would like to start a three week WGLC on 
RTP Payload Format for Flexible Forward Error Correction in 
draft-ietf-payload-flexible-fec-scheme-05.


The WGLC will end on November 7th 


 


Mo has posted some clarifications to the payload WG =
mailing list  payload mailing list archives


 


Please send comments to the payload mailing list. 


THe double posting is to  notify RTCweb WG that the WGLC has started since this document is ne=
eded for RTCweb


 =



 =



Roni Even


Payload WG co-chair=



 =



 






 


_______________________________________________
rtcweb mailing list
rtcwe=
b@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb






--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com
----------------------------------------------------------------------








--_000_D65040BB7693Dmzanatyciscocom_--


From nobody Fri Dec  8 11:33:24 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D965126579 for ; Fri,  8 Dec 2017 11:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRhOal1npx0D for ; Fri,  8 Dec 2017 11:33:21 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5828C124F57 for ; Fri,  8 Dec 2017 11:33:20 -0800 (PST)
X-AuditID: c1b4fb25-36dff70000000151-14-5a2ae8fe3d47
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.FE.00337.EF8EA2A5; Fri,  8 Dec 2017 20:33:18 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Fri, 8 Dec 2017 20:33:17 +0100
From: Christer Holmberg 
To: Justin Uberti 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
Thread-Index: AQHTcB1FG+1FPu18CUSj8DDCBmYDBqM5kxgAgABCu+A=
Date: Fri, 8 Dec 2017 19:33:16 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C046555@ESESSMB109.ericsson.se>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C046555ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7hO6/F1pRBivPK1lsnSpksfZfO7sD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK6Nl9ga3gh2/FnklqDYxPvLsYOTkkBEwkujob 2bsYuTiEBA4zSsxd9Y8RwlnMKPGw7wRTFyMHB5uAhUT3P22QBhEBNYmHs3axgtjMAuoSdxaf YwexhQXCJH7Mf8UCUi4iEC7ROS0IotxKYsGKNWAlLAIqEpeOnmYBsXkFfCXO/jsItbeJUeLi sSOMIAlOgUCJSdO7weYzCohJfD+1hglil7jErSfzmSCOFpBYsuc8M4QtKvHy8T9WCFtJYu3h 7SwQ9fkSy1+9ZIdYJihxcuYTlgmMIrOQjJqFpGwWkrJZQC8wC2hKrN+lD1GiKDGl+yE7hK0h 0TpnLjuy+AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgfF0cMtv1R2Ml984HmIU4GBU 4uFdC4wzIdbEsuLK3EOMEhzMSiK8XP5AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATS E0tSs1NTC1KLYLJMHJxSDYzOjoffCAWx5+/d0XhJT4tHrr43942mnIrRu4JzthcMD5hK5L34 71NxY/vbouLtyyzuFPFyXn4n8ne23E9hY61zzdkO5YFT3C59cNJqXzFb//4ON5NVFqxn7v+8 uJ2j6Zrbvra2Vw8ZTOYY9Z4VvbSjeLf87U82Z+qf35fT1PuQ8+bsZtejzZOVWIozEg21mIuK EwEIPcKzowIAAA==
Archived-At: 
Subject: Re: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Dec 2017 19:33:24 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C046555ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCj5DaHJpc3RlciwgY2FuIHlvdSBzdW1tYXJpemUgdGhlIGRpZmZlcmVuY2VzPyBJIHdp
bGwgZmlsZSBhbiBpc3N1ZSBhZ2FpbnN0IEpTRVAuDQoNClRoZSBpbml0aWFsIG9mZmVyIGlzIGFz
IGJlZm9yZSwgaS5lLiwgeW91IGFzc2lnbiBhIHVuaXF1ZSBhZGRyZXNzLCBTRFAgYXR0cmlidXRl
cyBldGMgdG8gZWFjaCBidW5kbGVkIG0tIHNlY3Rpb24uDQoNCkJ1dCwgaW4gdGhlIGFuc3dlciwg
YW5kIGluIGV2ZXJ5IHN1YnNlcXVlbnQgb2ZmZXIvYW5zd2VyLCB5b3Ugb25seSBhc3NpZ24gdGhl
IEJVTkRMRSBwb3J0IHRvIHRoZSBidW5kbGVkIG0tIHNlY3Rpb24gcmVwcmVzZW50ZWQgYnkgdGhl
IG9mZmVyZXIvYW5zd2VyZXIgQlVORExFLXRhZy4gVG8gZXZlcnkgb3RoZXIgbS0gc2VjdGlvbiB5
b3UgYXNzaWduIGEgemVybyBwb3J0IHZhbHVlIGFuZCBhIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZSAo
cHJldmlvdXNseSB0aGUgYnVuZGxlLW9ubHkgYXR0cmlidXRlIHdhcyBvbmx5IGRlZmluZWQgZm9y
IG9mZmVycykuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gRnJpLCBEZWMgOCwgMjAx
NyBhdCA0OjA4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz
b24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhp
LA0KDQpBdCBzb21lIHBvaW50IHNvbWUgb2YgdGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gNyBvZiBK
U0VQIG5lZWQgdG8gYmUgdXBkYXRlZCwgaW4gb3JkZXIgdG8gYWxpZ24gd2l0aCB0aGUgbGF0ZXN0
IHZlcnNpb24gb2YgQlVORExFLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5n
IGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C046555ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwv
c3Bhbj5DaHJpc3RlciwgY2FuIHlvdSBzdW1tYXJpemUgdGhlIGRpZmZlcmVuY2VzPyBJIHdpbGwg
ZmlsZSBhbiBpc3N1ZSBhZ2FpbnN0IEpTRVAuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGluaXRpYWwgb2Zm
ZXIgaXMgYXMgYmVmb3JlLCBpLmUuLCB5b3UgYXNzaWduIGEgdW5pcXVlIGFkZHJlc3MsIFNEUCBh
dHRyaWJ1dGVzIGV0YyB0byBlYWNoIGJ1bmRsZWQgbS0gc2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCwgaW4gdGhlIGFuc3dlciwgYW5kIGluIGV2
ZXJ5IHN1YnNlcXVlbnQgb2ZmZXIvYW5zd2VyLCB5b3Ugb25seSBhc3NpZ24gdGhlIEJVTkRMRSBw
b3J0IHRvIHRoZSBidW5kbGVkIG0tIHNlY3Rpb24gcmVwcmVzZW50ZWQgYnkgdGhlIG9mZmVyZXIv
YW5zd2VyZXIgQlVORExFLXRhZy4NCiBUbyBldmVyeSBvdGhlciBtLSBzZWN0aW9uIHlvdSBhc3Np
Z24gYSB6ZXJvIHBvcnQgdmFsdWUgYW5kIGEgYnVuZGxlLW9ubHkgYXR0cmlidXRlIChwcmV2aW91
c2x5IHRoZSBidW5kbGUtb25seSBhdHRyaWJ1dGUgd2FzIG9ubHkgZGVmaW5lZCBmb3Igb2ZmZXJz
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBGcmksIERlYyA4LCAyMDE3IGF0IDQ6MDggQU0sIENocmlzdGVyIEhv
bG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t
IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr
Ij5BdCBzb21lIHBvaW50IHNvbWUgb2YgdGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gNyBvZiBKU0VQ
IG5lZWQgdG8gYmUgdXBkYXRlZCwgaW4gb3JkZXIgdG8gYWxpZ24gd2l0aCB0aGUgbGF0ZXN0IHZl
cnNpb24gb2YgQlVORExFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DaHJpc3Rl
cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0
Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5y
dGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C046555ESESSMB109erics_--


From nobody Fri Dec  8 11:35:20 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A31289B0 for ; Fri,  8 Dec 2017 11:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr6tvTmKpxZh for ; Fri,  8 Dec 2017 11:35:16 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8168126579 for ; Fri,  8 Dec 2017 11:35:15 -0800 (PST)
X-AuditID: c1b4fb30-cc1ff700000029e3-0e-5a2ae97160a9
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.0D.10723.179EA2A5; Fri,  8 Dec 2017 20:35:14 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Fri, 8 Dec 2017 20:35:13 +0100
From: Christer Holmberg 
To: Christer Holmberg , Justin Uberti 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
Thread-Index: AQHTcB1FG+1FPu18CUSj8DDCBmYDBqM5kxgAgABCu+CAAAD+0A==
Date: Fri, 8 Dec 2017 19:35:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C046586@ESESSMB109.ericsson.se>
References:   <7594FB04B1934943A5C02806D1A2204B6C046555@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C046555@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C046586ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7sW7RS60ogy8d3BZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyps/9xVzQl17x59dBxgbGFSldjJwcEgImEqfX bGDuYuTiEBI4zCixrOsDlLOYUeLB+9UsXYwcHGwCFhLd/7RBGkQEYiR+9d1hBLGZBdQl7iw+ xw5iCwuESfyY/wqsXEQgXKJzWhBEuZPE9rW3wMpZBFQkXu68zgZi8wr4SjQfW84EseoYo8SM g8fBejkF/CSe/IsCqWEUEJP4fmoNE8QqcYlbT+YzQdwsILFkz3lmCFtU4uXjf6wQtpLE2sPb WSDq8yVWLr7LArFLUOLkzCcsExhFZiEZNQtJ2SwkZbOArmAW0JRYv0sfokRRYkr3Q3YIW0Oi dc5cdmTxBYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+nglt8GOxhfPnc8xCjAwajE w3v+uVaUEGtiWXFl7iFGCQ5mJRFeLn+gEG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLp iSWp2ampBalFMFkmDk6pBsb+10dlRGrPXvB2fiy2d+3BWW7rC6abvnCT6M0uSi4+xOt59vrE He/mqShvVxS+Z+Bft+S03mqHU0svGk+2fdv/LsP64OsrH591TNzBUOhk82qi4mrmbacXJ5lH P1Fg3dni1+i6Sbd8RszJH7f4FT9PsW+/vEK7wvec5KHKz5MjJhgpcqcx1f5TYinOSDTUYi4q TgQAsoBvEKMCAAA=
Archived-At: 
Subject: Re: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Dec 2017 19:35:18 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C046586ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Tm90ZSB0aGF0IEkgZGlkIE5PVCBjaGVjayB3aGV0aGVyIG90aGVyIGNoYW5nZXMgYXJlIG5lZWRl
ZCBpbiBKU0VQIGR1ZSB0byB0aGUgY2hhbmdlcyBpbiBCVU5ETEUg4oCTIEkgb25seSBjaGVja2Vk
IHRoZSBleGFtcGxlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFtt
YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xt
YmVyZw0KU2VudDogMDggRGVjZW1iZXIgMjAxNyAyMTozMw0KVG86IEp1c3RpbiBVYmVydGkgPGp1
YmVydGlAZ29vZ2xlLmNvbT4NCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRj
d2ViXSBKU0VQIGV4YW1wbGVzIG5lZWQgdG8gYmUgYWxpZ25lZCB3aXRoIGxhdGVzdCB2ZXJzaW9u
IG9mIEJVTkRMRQ0KDQpIaSwNCg0KPkNocmlzdGVyLCBjYW4geW91IHN1bW1hcml6ZSB0aGUgZGlm
ZmVyZW5jZXM/IEkgd2lsbCBmaWxlIGFuIGlzc3VlIGFnYWluc3QgSlNFUC4NCg0KVGhlIGluaXRp
YWwgb2ZmZXIgaXMgYXMgYmVmb3JlLCBpLmUuLCB5b3UgYXNzaWduIGEgdW5pcXVlIGFkZHJlc3Ms
IFNEUCBhdHRyaWJ1dGVzIGV0YyB0byBlYWNoIGJ1bmRsZWQgbS0gc2VjdGlvbi4NCg0KQnV0LCBp
biB0aGUgYW5zd2VyLCBhbmQgaW4gZXZlcnkgc3Vic2VxdWVudCBvZmZlci9hbnN3ZXIsIHlvdSBv
bmx5IGFzc2lnbiB0aGUgQlVORExFIHBvcnQgdG8gdGhlIGJ1bmRsZWQgbS0gc2VjdGlvbiByZXBy
ZXNlbnRlZCBieSB0aGUgb2ZmZXJlci9hbnN3ZXJlciBCVU5ETEUtdGFnLiBUbyBldmVyeSBvdGhl
ciBtLSBzZWN0aW9uIHlvdSBhc3NpZ24gYSB6ZXJvIHBvcnQgdmFsdWUgYW5kIGEgYnVuZGxlLW9u
bHkgYXR0cmlidXRlIChwcmV2aW91c2x5IHRoZSBidW5kbGUtb25seSBhdHRyaWJ1dGUgd2FzIG9u
bHkgZGVmaW5lZCBmb3Igb2ZmZXJzKS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiBG
cmksIERlYyA4LCAyMDE3IGF0IDQ6MDggQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o
b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bT4+IHdyb3RlOg0KSGksDQoNCkF0IHNvbWUgcG9pbnQgc29tZSBvZiB0aGUgZXhhbXBsZXMgaW4g
c2VjdGlvbiA3IG9mIEpTRVAgbmVlZCB0byBiZSB1cGRhdGVkLCBpbiBvcmRlciB0byBhbGlnbiB3
aXRoIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiBCVU5ETEUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
cnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo=

--_000_7594FB04B1934943A5C02806D1A2204B6C046586ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2
MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90ZSB0aGF0IEkgZGlkIE5PVCBj
aGVjayB3aGV0aGVyIG90aGVyIGNoYW5nZXMgYXJlIG5lZWRlZCBpbiBKU0VQIGR1ZSB0byB0aGUg
Y2hhbmdlcyBpbiBCVU5ETEUg4oCTIEkgb25seSBjaGVja2VkIHRoZSBleGFtcGxlcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21h
aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0
ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMDggRGVjZW1iZXIgMjAxNyAyMTozMzxicj4N
CjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aUBnb29nbGUuY29tJmd0Ozxicj4N
CjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRj
d2ViXSBKU0VQIGV4YW1wbGVzIG5lZWQgdG8gYmUgYWxpZ25lZCB3aXRoIGxhdGVzdCB2ZXJzaW9u
IG9mIEJVTkRMRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5DaHJpc3RlciwgY2FuIHlvdSBzdW1tYXJpemUgdGhl
IGRpZmZlcmVuY2VzPyBJIHdpbGwgZmlsZSBhbiBpc3N1ZSBhZ2FpbnN0IEpTRVAuPHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+VGhlIGluaXRpYWwgb2ZmZXIgaXMgYXMgYmVmb3JlLCBpLmUuLCB5b3UgYXNzaWduIGEg
dW5pcXVlIGFkZHJlc3MsIFNEUCBhdHRyaWJ1dGVzIGV0YyB0byBlYWNoIGJ1bmRsZWQgbS0gc2Vj
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCwgaW4g
dGhlIGFuc3dlciwgYW5kIGluIGV2ZXJ5IHN1YnNlcXVlbnQgb2ZmZXIvYW5zd2VyLCB5b3Ugb25s
eSBhc3NpZ24gdGhlIEJVTkRMRSBwb3J0IHRvIHRoZSBidW5kbGVkIG0tIHNlY3Rpb24gcmVwcmVz
ZW50ZWQgYnkgdGhlIG9mZmVyZXIvYW5zd2VyZXIgQlVORExFLXRhZy4NCiBUbyBldmVyeSBvdGhl
ciBtLSBzZWN0aW9uIHlvdSBhc3NpZ24gYSB6ZXJvIHBvcnQgdmFsdWUgYW5kIGEgYnVuZGxlLW9u
bHkgYXR0cmlidXRlIChwcmV2aW91c2x5IHRoZSBidW5kbGUtb25seSBhdHRyaWJ1dGUgd2FzIG9u
bHkgZGVmaW5lZCBmb3Igb2ZmZXJzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIERlYyA4LCAyMDE3IGF0
IDQ6MDggQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj
ayI+QXQgc29tZSBwb2ludCBzb21lIG9mIHRoZSBleGFtcGxlcyBpbiBzZWN0aW9uIDcgb2YgSlNF
UCBuZWVkIHRvIGJlIHVwZGF0ZWQsIGluIG9yZGVyIHRvIGFsaWduIHdpdGggdGhlIGxhdGVzdCB2
ZXJzaW9uIG9mIEJVTkRMRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hyaXN0
ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy
dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+
cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7594FB04B1934943A5C02806D1A2204B6C046586ESESSMB109erics_--


From nobody Sat Dec  9 17:41:52 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3191275C5 for ; Sat,  9 Dec 2017 17:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saFBDkJue0UR for ; Sat,  9 Dec 2017 17:41:48 -0800 (PST)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B758E127599 for ; Sat,  9 Dec 2017 17:41:48 -0800 (PST)
Received: by mail-ua0-x22b.google.com with SMTP id e10so9800814uah.10 for ; Sat, 09 Dec 2017 17:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k0qN6/9KFhCRBmLnHte8cu4cpdEJVMWWf2QnM07sqo0=; b=hl1ZeND05i1q5dFdfHHgcbA737tFs+2o1Ks18X+DM+bFwBbEL6Fw8SZrk3SPWgfDy/ TPh8laxd5koAIM8d/vcuAJT3FFs+7vYSG02nMxZIHuxZ2XZ1It+fYPolLNZdn2wVKzqe uflr3wg/jjWjxJuISSY1u3ME8j9wMRYS8HSy4WBi4/MXC/S9XI4PiB9JrDtFiD18BLc+ xUWstNN7ctfKO+XObtR/9pTatZy6GoNt3e7yfzQg/kKqSaKaNM//qYXd1o1PbFXX+ChB fTHZ4jptQdiqYGJQKbarEVuNu9XogZT3qZo987K/QGpLw2Yik/s2ZBZjFtV7+shsPn7K dZYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k0qN6/9KFhCRBmLnHte8cu4cpdEJVMWWf2QnM07sqo0=; b=qthnudWsvVCBfVcB90pjcIzdkzYPLJbMgVVUoP3fWUjQ8pKL/+1XdnBjgQwxmtqlp3 s9ZU83h3nqZsfvOJNOsKzDV2tzrtoT+8tEwImjXQ2XfGjvLsmonszIPUVpAHlqM1WoN1 Mtg+zyH7htS8/1MAvJ4potEv7z7x2g7iB2zV3cfnsz1Q9UkJqcsWNQOKseWH48lYH7cW 86nb4hNiKq25MvunWbWPPmhGXhNRURCBmNfqEDItgxujighKDx6PYgUFd0EcLfa7J5kS TFQy4DIPFoo+W8j+PC+ukc7ujBzoXDnnXDj/aKK8duIMc8tsld9cNy5+Qv5mWS/WR6Lt r9mQ==
X-Gm-Message-State: AKGB3mIE5yHqyhM5nlIySsK05ErFUmf6fmrojzI5F42JAIxUqpHikxAn Son2FMGGhEkjt4V5PHpUY6HbtrRwr2lUDD1mBPvg7w==
X-Google-Smtp-Source: AGs4zMYLdj+a8gGTPE5GWjF4U64kxKtLTggiWqiLTb6IyPMb5/opmMvXPiS6wxuhlmKHnXwV7aYxMYmsudwOBz+DUco=
X-Received: by 10.159.51.2 with SMTP id o2mr23235631uab.194.1512870107215; Sat, 09 Dec 2017 17:41:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Sat, 9 Dec 2017 17:41:26 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C046586@ESESSMB109.ericsson.se>
References:   <7594FB04B1934943A5C02806D1A2204B6C046555@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C046586@ESESSMB109.ericsson.se>
From: Justin Uberti 
Date: Sat, 9 Dec 2017 17:41:26 -0800
Message-ID: 
To: Christer Holmberg 
Cc: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045dcc9c559e73055ff285e9"
Archived-At: 
Subject: Re: [rtcweb] JSEP examples need to be aligned with latest version of BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Dec 2017 01:41:51 -0000

--f403045dcc9c559e73055ff285e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

https://github.com/rtcweb-wg/jsep/issues/843

On Fri, Dec 8, 2017 at 11:35 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Note that I did NOT check whether other changes are needed in JSEP due to
> the changes in BUNDLE =E2=80=93 I only checked the examples.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 08 December 2017 21:33
> *To:* Justin Uberti 
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] JSEP examples need to be aligned with latest
> version of BUNDLE
>
>
>
> Hi,
>
>
>
> >Christer, can you summarize the differences? I will file an issue
> against JSEP.
>
>
>
> The initial offer is as before, i.e., you assign a unique address, SDP
> attributes etc to each bundled m- section.
>
>
>
> But, in the answer, and in every subsequent offer/answer, you only assign
> the BUNDLE port to the bundled m- section represented by the
> offerer/answerer BUNDLE-tag. To every other m- section you assign a zero
> port value and a bundle-only attribute (previously the bundle-only
> attribute was only defined for offers).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> On Fri, Dec 8, 2017 at 4:08 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> At some point some of the examples in section 7 of JSEP need to be
> updated, in order to align with the latest version of BUNDLE.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

--f403045dcc9c559e73055ff285e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Fri, Dec 8, 2017 at 11:35 AM, Ch=
rister Holmberg <christer.holmberg@ericsson.com> wrote:











Note that I did NOT check whether oth=
er changes are needed in JSEP due to the changes in BUNDLE =E2=80=93 I only=
 checked the examples.


=C2=A0


Regards,


=C2=A0


Christer


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d">=C2=A0






From: =
rtcweb [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Christer Holmberg

Sent: 08 December 2017 21:33

To: Justin Uberti <juberti@google.com>

Cc: rtcweb@ietf=
.org

Subject: Re: [rtcweb] JSEP examples need to be aligned with latest v=
ersion of BUNDLE






=C2=A0


Hi,


=C2=A0




>Christer, c=
an you summarize the differences? I will file an issue against JSEP.


=C2=A0


The initial offer is as before, i.e.,=
 you assign a unique address, SDP attributes etc to each bundled m- section=
.


=C2=A0


But, in the answer, and in every subs=
equent offer/answer, you only assign the BUNDLE port to the bundled m- sect=
ion represented by the offerer/answerer BUNDLE-tag.
 To every other m- section you assign a zero port value and a bundle-only a=
ttribute (previously the bundle-only attribute was only defined for offers)=
.


=C2=A0


Regards,


=C2=A0


Christer


=C2=A0






=C2=A0




On Fri, Dec 8, 2017 at 4:08 AM, Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:








Hi,






=C2=A0






At some point some of the examples in s=
ection 7 of JSEP need to be updated, in order to align with the latest vers=
ion of BUNDLE.






=C2=A0






Regards,






=C2=A0






Christer






=C2=A0






=C2=A0








_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb






=C2=A0












--f403045dcc9c559e73055ff285e9--


From nobody Sun Dec 10 17:27:54 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A2127005; Sun, 10 Dec 2017 17:27:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151295566844.21261.16059266159445889874@ietfa.amsl.com>
Date: Sun, 10 Dec 2017 17:27:48 -0800
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-07.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Dec 2017 01:27:48 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF.

        Title           : WebRTC Forward Error Correction Requirements
        Author          : Justin Uberti
	Filename        : draft-ietf-rtcweb-fec-07.txt
	Pages           : 12
	Date            : 2017-12-10

Abstract:
   This document provides information and requirements for how Forward
   Error Correction (FEC) should be used by WebRTC implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-fec-07
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 11 14:43:49 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F51276AF for ; Mon, 11 Dec 2017 14:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIBBKLMKRLIH for ; Mon, 11 Dec 2017 14:43:46 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E6D1272E1 for ; Mon, 11 Dec 2017 14:43:45 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id f199so11869177vka.8 for ; Mon, 11 Dec 2017 14:43:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=YKl/unqsJHsU82e24fYf3yEoUHmJkBKPuoIn+z7FnV0=; b=E7QIocndjMXYu+cYZn93Grq3XBlmChdTlcOwpvzImgWeV+SGBYGigvcOjccpZaEaXR OXWlvUgqdc6tShRiR4v3RzyggyH6XzCKVrS5HJP+BejXMb0MH4NGC9ELUbJSQgCuK+ux PxuYq/o+tQXigDQTBEHWGdoBy7sN2uuJFfqxb0UELB8YgKatViKwx9/mgFnETqHHClsq J8yRNZd337ARHw3c1rFST8EmzNHC/7PIuR9tNWe/XfRJA9oeZ9AxX2cxpmZV4dqp/rcU evXH0FDO7lDOJ+z//x/+QeqVljy5hnEjkCRCdCniXXKpRPg8MS6db+DaGuqO7AxaGl0K HSsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=YKl/unqsJHsU82e24fYf3yEoUHmJkBKPuoIn+z7FnV0=; b=BmiLGgu9hByDZnoJEFTl959yr6T/6kwPgbZ68QeALE/Ki/1cSi3RN21/uTl+uiV6bG 8wju+m/p4NYrrZskiNKVxFoKl+1JhCb2u9WkxEhellxZ1YcPYidBT48E5udEj/7bLGZn D1sXg5BiQB9/TAuL8xCByKh4+9O4/lm+U8W7bo3VKgHINg8+SOEQk+f4+MKrmpd+uEZM sUUoi/u9C4FreBhEH5p6KNdOnUmOm1h5q+7BukcL0jMyV7U9rD8grm1cj8dD8TAYuRZa D/k3G7leoDPfi5YvURbGVAyjifLCnEgaqKMKksV02UbEmOYbUL3H9PmE6FurgkjYPNqU oBow==
X-Gm-Message-State: AKGB3mJYdi8dtTTZvH+iW6rjea8w3o6c3/8A3q2puRZ86YotjJ08geYP yNihKp2HP2VsENW9UxtX+8Zpny/3KdroTCDv/Ft/f+Et
X-Google-Smtp-Source: ACJfBoslZvABoJytdX7iIzEs0wJN+Z5/ii1XjqCebZ2z3Bpq3yRUb/M7VfAHbjShuBlxUmj5hJzZtF0I5tdl2Ec5KPw=
X-Received: by 10.31.160.145 with SMTP id j139mr2060431vke.155.1513032224219;  Mon, 11 Dec 2017 14:43:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Mon, 11 Dec 2017 14:43:23 -0800 (PST)
In-Reply-To: <151295566844.21261.16059266159445889874@ietfa.amsl.com>
References: <151295566844.21261.16059266159445889874@ietfa.amsl.com>
From: Justin Uberti 
Date: Mon, 11 Dec 2017 14:43:23 -0800
Message-ID: 
Cc: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a1142df1042f6c50560184408"
Archived-At: 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-07.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Dec 2017 22:43:48 -0000

--001a1142df1042f6c50560184408
Content-Type: text/plain; charset="UTF-8"

This update of the FEC document addresses Magnus' review comments.

At this time, I believe there are no outstanding issues.

On Sun, Dec 10, 2017 at 5:27 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Real-Time Communication in WEB-browsers
> WG of the IETF.
>
>         Title           : WebRTC Forward Error Correction Requirements
>         Author          : Justin Uberti
>         Filename        : draft-ietf-rtcweb-fec-07.txt
>         Pages           : 12
>         Date            : 2017-12-10
>
> Abstract:
>    This document provides information and requirements for how Forward
>    Error Correction (FEC) should be used by WebRTC implementations.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-rtcweb-fec-07
> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a1142df1042f6c50560184408
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This update of the FEC document addresses Magnus' revi=
ew comments.=C2=A0

At this time, I believe there are no =
outstanding issues.

On Sun, Dec 10, 2017 at 5:27 PM,  <internet-drafts@ietf.org=
> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Real-Time Communication in WEB-browsers WG=
 of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 WebRTC Forward Error Correction Requirements

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just=
in Uberti

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-rtcweb-fec-07.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 12

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-12-10



Abstract:

=C2=A0 =C2=A0This document provides information and requirements for how Fo=
rward

=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC implementation=
s.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-i=
etf-rtcweb-fec/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-rtcw=
eb-fec-07

https://datatracker.ietf.org/doc/=
html/draft-ietf-rtcweb-fec-07



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-rtcweb-fec-07





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




--001a1142df1042f6c50560184408--


From nobody Mon Dec 11 19:49:11 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A971293E8; Mon, 11 Dec 2017 19:49:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-rtcweb-jsep@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com>
Date: Mon, 11 Dec 2017 19:49:05 -0800
Archived-At: 
Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Dec 2017 03:49:05 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-jsep-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "yes", but I have some minor comments and nits:

Substantive:

- General:
I still find the edges around where SDP is and isn't required a bit vague.
Section 3.3 says that the JSEP implementation internal representation is SDP.
While I have trouble imagining implementing this otherwise, do we really mean
to mandate the internals? Is there an assumption that said internal
representation is _serialized_ SDP vs some abstract internal representation?

Section 3.1 says that the signaling model is not specified. Is there an
implicit assumption that, however things are signaled, the signaling process
moves around serialized SDP? Or is it envisioned that one could write an
application without serialized SDP occurring anywhere above the API?

-5, throughout: There are a number of normative keywords used in constructions
like "... MUST foo, as described in RFCXXX". That construction is ambiguous
about whether it defines a normative requirement to do something, and the doing
of that something is described in the RFC, or if describes the referenced RFC
as defining the MUST.

In general, it's best to avoid using 2119/8174 keywords to talk about external
requirements, except as a direct quote. I think this is especially true here
given the interdependencies between drafts in cluster 238. If in the future we
update a dependency to change a normative requirement, we risk creating
conflicts, and we make it unclear which text is authoritative.

-5.1.1: I think the operative requirement is "MUST support" rather than "MUST
indicate support". (While indication may also be required, it seems a
consequence of "MUST support".)

-5.1.2: " Any profile in the offer matching one of the following MUST be
accepted:" Isn't the real requirement that any of the following must be
interpreted the same, or otherwise in some specified way? I assume there may be
completely unrelated reasons to reject an m-section, but the "MUST be accepted"
language seems to overrule that.

-5.4: "The SDP returned from createOffer or createAnswer MUST NOT be changed
   before passing it to setLocalDescription."
Is that a requirement on the JSEP implementation, or the javascript
application? If the latter, is it appropriate to put normative requirements on
the application? It seems like it would be better to normatively state the JSEP
implementations's behavior when the application does something incorrect. 
(Which seems to be done further down the page.)

-5.7: " The effect of rollback MUST be the same regardless of whether
setLocalDescription or setRemoteDescription is called." Does that mean if I
call setLocalDescription, then rollback with a call to setRemoteDescription,
_both_ are rolled back?

-5.8.3: The MUSTs in this section seem to be putting requirements on the SDP
being parsed. Shouldn't they instead describe the parser's behavior based on
that SDP input? The correctness of the SDP being parsed seems beyond the
control of the implementation.

-8, second paragraph: When describing how the javascript is untrusted, it may
be worth mentioning that it may have been downloaded from an untrusted source.

Editorial and Nits:

-1.1: Please expand ICE and MCU on the first mention.
s/config/configuration
Sentence starting with "Through its abstraction of signaling...": Should that
say "Though it abstracts signaling..."

-2: Please consider using the boilerplate from RFC 8174. There are a number of
instances of lowercase versions of normative keywords.

-3.2, paragraph 2: The MUST seems like a statement of fact.

-3.4.1, 2nd paragraph: Please expand or explain "mid" on first mention. (It is
explained 3.5.2.1)

-3.5.1, last paragraph: Inconsistent capitalization: "MID"

-3.5.2.1: Please expand (or define) "ufrag" on first mention.

-3.6.1, first paragraph: is "intersect" the correct verb here? Missing
conjunction in "hardware decoder capababilities, local policy".

-3.6.2, 2nd paragraph: s/"may be producing"/"may produce"

-4.1.2: Please expand LS on first mention. (I can guess from context. Please
don't make me :-)  )

- 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP"
"for each SDP line, the generation of the SDP will follow the process defined
for generating an initial offer from the document that specifies the given SDP
line." While I worked out what that means, I found "document" to be ambiguous.
At first I interpreted it as the "SDP document" rather than "the RFC". (Note
this occurs several times in subsequent sections.)

-4.1.8, third paragraph: ""pranswer" indicates that a description should be
parsed as an
   answer, but not a final answer"
I think it would be more clear to say "... parsed as a provisional answer,
rather than a final answer".

-5.2.1: Paragraph starting with: " Each m= section, provided it is not marked
as bundle-only, MUST generate..." The m= section is not the real actor here, is
it?



From nobody Tue Dec 12 05:32:03 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8F7126CC7 for ; Tue, 12 Dec 2017 05:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa0gdagr4oYe for ; Tue, 12 Dec 2017 05:31:55 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9ED126C3D for ; Tue, 12 Dec 2017 05:31:55 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id i40so47117495qti.8 for ; Tue, 12 Dec 2017 05:31:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HTvpbwof52nYnhZXPbM+ht0/YS2297MjXv8393kPGE0=; b=Ase3AMNPvWZKqIswJY/NKiVGBrXGgjIvnTozFw+FaWUymkdAgFJ8VggYK7qiLVZOQP zGWQBVxq7g7WckIXQ+06NzXirLHNZFUtlZJWuIG8ZsMrUAEVnXXFMIrDEzCdgWLJ1TIr E9z6Dl9qU56Ofo0RGRI/AiA9gxxhPCwDIqivo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HTvpbwof52nYnhZXPbM+ht0/YS2297MjXv8393kPGE0=; b=S9oK5GRAeAmjc0GVA7mrbRXfn9k5F6w3G6GA/ycKPXunXgkQikyGXhNvpgKUjZv10y r4RObSdfIWxAzc2SgDJ379T1RpEyCZ2Y/EK2lRh6JIzpKEri/uxq3lzfaZUVfc75dGEs TZ4w3H1dgyuAm9HYUvAugy04T3pRvrU06zFBqhyA5jlrfZLtGFJG9capy7v2xe/2MYNA Byq6B1r6mkqRERcK7V8HpEhwQYMnCPTLtLPx1zb0BmWjVP3cWiHFQf/jg0ea4gXRWtuq LThsK5+pqoXuWeU8mNindRSbAonVtVVQAi7HTAiEHC/gGOagwqYqkSfUO/REBe+0a80r yVkw==
X-Gm-Message-State: AKGB3mISy2XTQLdRruKXnKa/VsbxXI6N9+WHUDjpSg29cLzYIvRm7t9p KkUQ+71lgK3gTebml1O2aQSxmY3c0EA=
X-Google-Smtp-Source: ACJfBosTS0w6XAlbIXzXr/md//tcwzLNNWaJ7zoqVqQGfiY8tMX2I+hb8TJLZd+LXsTF87L1iDv+Lg==
X-Received: by 10.55.158.82 with SMTP id h79mr5578306qke.22.1513085514594; Tue, 12 Dec 2017 05:31:54 -0800 (PST)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id a19sm5347789qtj.74.2017.12.12.05.31.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 05:31:53 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner 
In-Reply-To: 
Date: Tue, 12 Dec 2017 08:31:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Dec 2017 13:32:02 -0000

These have been lingering for a bit, and I=E2=80=99d like to see if =
can=E2=80=99t resolve them.  Please let us know if you=E2=80=99ve got =
any opinions on the following 3 issues, which happen to be the only open =
issues stopping us from WGLCing this draft.

spt

> On Jul 20, 2017, at 02:45, Justin Uberti  wrote:
>=20
> Since there will be no WG meeting this week, here are the open issues =
for the document. Feedback on these issues is the only thing standing =
between this document and WGLC.
>=20
> 1. https://github.com/juberti/draughts/issues/59
>=20
> In the problem statement, should the paragraph on VPNs mention IP =
address discovery?=20
>=20
> Currently, the problem statement says the following:
>    1.  If the client is behind a Network Address Translator (NAT), the
>        client's private IP addresses, typically [RFC1918] addresses, =
can
>        be learned.
>=20
>    2.  If the client tries to hide its physical location through a
>        Virtual Private Network (VPN), and the VPN and local OS support
>        routing over multiple interfaces (i.e., a "split-tunnel" VPN),
>        WebRTC will discover the public address for the VPN as well as
>        the ISP public address that the VPN runs over.
>=20
> However, Bernard mentioned that even without split-tunnel support, the =
ICE implementation allows discovery of the VPN private address. I think =
this is covered by the first paragraph, but perhaps this should be =
spelled out further. Thoughts?
>=20
>=20
> 2. https://github.com/juberti/draughts/issues/60.
>=20
> Should supporting WebRTC over Tor be an explicit goal of this document =
(and mentioned in the goals section)?=20
>=20
> This scenario is possible via Mode 4, e.g. force-proxy mode, but it =
may be out of scope for this document. Bernard mentioned that it may be =
out of scope as Tor distros can disable Javascript, making WebRTC =
useless, but upon investigation I found that the default Tor bundle does =
enable Javascript, and so this is worth considering. Thoughts?
>=20
>=20
> 3. https://github.com/juberti/draughts/issues/61
>=20
> Should the document discuss implementation details as it relates to =
suggested default behavior?=20
>=20
> The document currently says the following:
>=20
>     1.  By default, WebRTC should follow normal IP routing rules, to =
the
>        extent that this is easy to determine (i.e., not considering
>        proxies).  This can be accomplished by binding local sockets to
>        the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
>        allows the OS to route WebRTC traffic the same way as it would
>        HTTP traffic, and allows only the 'typical' public addresses to
>        be discovered.
>=20
> However, Bernard thinks that this text may be making some assumptions, =
specifically about whether a strong or weak host model is used. My =
thinking was that spelling out the general implementation approach helps =
readers grok exactly what this section is getting at, but open to other =
opinions here.
>=20
>=20
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Tue Dec 12 13:53:53 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96542124217; Tue, 12 Dec 2017 13:53:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty 
To: "The IESG" 
Cc: draft-ietf-rtcweb-jsep@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151311562760.14100.8542671795905150712.idtracker@ietfa.amsl.com>
Date: Tue, 12 Dec 2017 13:53:47 -0800
Archived-At: 
Subject: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Dec 2017 21:53:48 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-rtcweb-jsep-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm sure the RFC editor would have caught this nit:

2nd paragraph of security considerations section:
While formally the JSEP interface is an API, it is better to think of
   it is an Internet protocol
s/is an Internet/as an Internet/



From nobody Tue Dec 12 15:40:05 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E40127873; Tue, 12 Dec 2017 15:40:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-rtcweb-jsep@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151312200513.30209.14827472180959771709.idtracker@ietfa.amsl.com>
Date: Tue, 12 Dec 2017 15:40:05 -0800
Archived-At: 
Subject: [rtcweb] Eric Rescorla's Recuse on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Dec 2017 23:40:05 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-rtcweb-jsep-24: Recuse

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am an author on this document.



From nobody Wed Dec 13 11:51:31 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027D0126E7A; Wed, 13 Dec 2017 11:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=2.2] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Kt+UWl9M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QmaZg2qi
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph8tlN3Ka3Pq; Wed, 13 Dec 2017 11:51:26 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35143126B71; Wed, 13 Dec 2017 11:51:23 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8405320BA8; Wed, 13 Dec 2017 14:51:22 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 13 Dec 2017 14:51:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=3Ol8XMJ9fVRgCWUMgBy01CkTTOWEsR/Nw2caAQ6fptU=; b=Kt+UWl9M Ui6UPTngnbtiRTo23hIjSH1DHfz5OSE9XktR+EwsRIQysiOvogFr76aFmBGjOcBQ oyWA7BYTbMldj17k1Vq0YLCJrhG2wi4P9iajvqvjrWv9JvNdS7wfV2v2Jur3jjBC s6kMj/JI6w3GmTkurNrp7+LUzZHArgpXph0zypYE3P24eEKe156uZ2h9P5yAO9Ni gjZoQHv5/9/XdJFItyjZxaE26wfB9GD7lnVQyGa8tAtbRuWdoifBuCM+pyJD17uf JnixqJPt5RMFyXzF/tblGpRIGv1xgte33WQehj89b4R0OK2tc0T0Hl6Qb1oORDWs fFibKFh0u+q2MA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=3Ol8XMJ9fVRgCWUMgBy01CkTTOWEs R/Nw2caAQ6fptU=; b=QmaZg2qiF6tDilH/zxBi7NTGIHeFlZ0L9a9UZpzE0sJk5 sL4BlVHVrhmOqJ2a+rryu2tTi63OzGZtAC7YUOp/F5m3CJ9/vDVUPlU/8w2EzjsQ 5RbYxHMDrVVieWBvYKFBKMEGTShO+ByEfWh0xaHWaW/x5pQso37ar8fsCyLr7QEp QKHDFBJ9kG/p08Z4h2yTUBb4tyRbPuIQCWtOH4NJOTCyeyPI9ahRe7E3isBE/ydO XlKn18u8aHZXwcNFagU935W/cmON4YTUkqGDOMEOk+wk13hq85tkdagIPcYcaSpS o+1x18BPivYQcj0bKqrlRdxtfJTdQ3NpcAMGfHO9w==
X-ME-Sender: 
Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id 7313E240F6; Wed, 13 Dec 2017 14:51:20 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BFA7169F-F2CB-4F4E-AF02-2DBB7F3F9269"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: 
Date: Wed, 13 Dec 2017 14:51:19 -0500
Cc: Robert Sparks , draft-ietf-rtcweb-jsep.all@ietf.org,  gen-art , "rtcweb@ietf.org" 
Message-Id: <9A22DCE9-9614-41D8-92C3-D283B5237B57@cooperw.in>
References: <150222067484.12279.1715829344429803452@ietfa.amsl.com> 
To: Justin Uberti 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [rtcweb] [Gen-art] Genart last call review of draft-ietf-rtcweb-jsep-21
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Dec 2017 19:51:29 -0000

--Apple-Mail=_BFA7169F-F2CB-4F4E-AF02-2DBB7F3F9269
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Robert, thanks for your review. Justin, thanks for your response. I have =
entered a Yes ballot.

Alissa


> On Aug 26, 2017, at 2:10 PM, Justin Uberti  wrote:
>=20
> Thanks for this careful review. A new version of the document (-22) =
has been posted which addresses almost all of these comments, with a few =
exceptions noted below.
>=20
> Diff: =
https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-jsep-21&url2=3Ddraft=
-ietf-rtcweb-jsep-22&difftype=3D--html =

>=20
> On Tue, Aug 8, 2017 at 12:31 PM, Robert Sparks > wrote:
> Reviewer: Robert Sparks
> Review result: Almost Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>=20
> For more information, please see the FAQ at
>=20
> >.
>=20
> Document: draft-ietf-rtcweb-jsep-21
> Reviewer: Robert Sparks
> Review Date: 2017-08-08
> IETF LC End Date: 2017-08-11
> IESG Telechat date: Not scheduled for a telechat
>=20
> Summary: Almost ready for publication as a Proposed Standard RFC, but =
with
> issues that need to be addressed before publishing
>=20
> Major issues:
>=20
> The last paragraph of 5.1 needs more context. Why woudn't you expect =
the
> re-offer to fail, given that you already know the peer is using the =
older
> profile strings? It's not clear from the email list and proceedings =
how the
> document ended up with this particular text.
>=20
> Minor issues:
>=20
> Second paragraph of 3.2, last sentence: at "these parameters or reject
> them" - "these" and "them" have ambiguous antecedents. It's not clear =
if you
> are trying to point to the parameters that don't follow the earlier =
stated
> rule, or all parameters. The sentence is complex. Splitting it up and
> finding a way to avoid the need for the semicolon will likely make it
> easier to say what you mean.
>=20
> Last paragraph on page 5 - first sentence: at "One way to mitigate =
this" -
> "this" has an unclear antecedent. Did you mean "One way to reduce the
> complexity of the application's responsibilities"?
>=20
> Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please
> state precisely which fields you mean.
>=20
> Odd edge: The description createAnswer (in 4.1.7) leaves open the
> possibility that the application could call createAnswer twice
> (back-to-back with no intervening calls to other APIs) with different
> values in the options parameter. Is this ok? If not, should there be
> language that says not to do that somewhere?
>=20
> Slightly more than minor maybe: The first paragraph of 5.1.2 has at =
least a
> reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's =
in
> RFC5764. Assuming that this is only a reference error, then the last
> sentence seems like a stray. It doesn't seem to be in the right =
context
> ("this advertisement" doesn't cast back to the discussion of the two
> profiles above it, which are both UDP only). Please clarify the =
sentence,
> giving it the right context, or remove it.
>=20
> The fourth sentence of the second bullet of section 5.2.1 is =
confusing. (It
> starts "It is RECOMMENDED that the ".) RFC3265 requires the
> initial sess-id high-order bit to be zero. As written, this can be =
read to
> say that setting that bit to zero is only RECOMMENDED, and that it's
> possible to have sess-ids that are something other than 64 bits. You =
mean
> to say "Do what 3265 says to do and make the lower 63 bits random". =
Here's
> one possible replacement for the sentence: "RFC 3265 requires that the
> high-order bit of the initial  be zero. It is RECOMMENDED =
that the
> remaining 63 bits be initially set to a cryptographically random =
value."
>=20
> The last paragraph of 5.3.1 prohibits the same attributes from =
generated
> answers that are prohibited in generated offers. Consider adding text =
for
> what to do if an offer shows up from a peer with some of those =
prohibited
> attributes.
>=20
> This is covered by the last paragraph on page 43:
>=20
>    Note that these requirements are in some cases stricter than those =
of
>    SDP.  Implementations MUST be prepared to accept compliant SDP even
>    if it would not conform to the requirements for generating SDP in=20=

>    this specification.=20
>=20
>=20
> The second paragraph of section 5.4 is confusing. A slight =
restructuring of
> the sentences would remove much of the potential confusion, I think. I
> suggest replacing the first sentence (which is very complex) with =
this:
> "After calling setLocalDescription, the application MAY modify the SDP =
to
> reduce the capabilities in the offer before sending it to the far =
side, as
> long as it remains a valid SDP offer and specifies a subset of what =
was in
> the original offer. Likewise, an application that has received an =
offer
> from a peer MAY modify the received SDP, subject to those same =
constraints,
> before calling setRemoteDescription."
>=20
> The first paragraph of section 5.7.1 is simply restating requirements =
from
> RFC4566. Restating normative requirements like that has led to interop
> problems through unintended introduced ambiguity and spec maintenance
> problems. Please consider rewriting the paragraph to say "RFC4566 =
says" and
> avoid the 2119 keywords.
>=20
> We considered this, but found that a) RFC4566 is clearly cited, and b) =
the actual restatement was very minor, really just affecting the =
discussion of the v=3D and o=3D lines. As a result we concluded that =
pointing the reader elsewhere just for those two lines did not seem like =
an improvement.
> =20
>=20
> On page 69, at "If the application attempt to transmit DTMF when using =
a
> media format that does not have a corresponding telephone-event =
format,
> this MUST result in an error". This sentence is out-of-place. The =
section
> is about applying a remote description. If the document needs to =
retain the
> sentence, it belongs off in some "processing media" section. In =
particular,
> the current placement of text is confusing about what and when an =
error
> could be returned, and it could be misread to say that an error should =
be
> returned to the setRemoteDescription call.
>=20
> Nits:
>=20
> Section 1.2 second paragraph - "This was rejected based on a feeling". =
Can
> you write something that speaks to consensus here? "Based on a =
feeling"
> isn't quite right. Maybe "using the argument"?
>=20
> PeerConnection is used first at the next to last paragraph of section =
3.
> Please add a reference at that point.
>=20
> "LS" (lipsync) is first used at 4.1.2, with no context for what it is.
> Please add a reference.
>=20
> The concept of a "pending local description" is used in sections =
3.5.1,
> 4.1.6, and 4.1.7  but isn't really explained until much later in the
> document. Please provide forward references, or move a description of =
what
> a pending description is earlier in the document.
>=20
> In 4.1.7 (create Answer) why would calling setLocalDescription cause =
the
> answer to be a _pending_ local description. I think it's the full on =
local
> description at that point, not a pending one?
>=20
> At 4.1.17's first paragraph: Why is "if parsed successfully" necessary =
to
> call out? I suggest removing the phrase.
>=20
> 4.2.3 talks about setting direction properties, but the values that =
can be
> set aren't called out (and even then only by inference from a list in =
an
> example) in section 4.2.5. Should there be explicit pointers to the =
api doc
> here? (And in section 4.2.6?)
>=20
> There are two paragraphs on page 50 that start "The next step is to". =
They
> are both referring to the same step. I suggest combining the =
paragraphs.
>=20
> The 4th bullet on page 64 is ambiguous at "this m=3D section". It =
looks like
> this bullet should just be merged with the previous bullet.
>=20
> The second paragraph of 6.8 starts "Next, ". I think it should start
> "First, ".
>=20
> It's not clear what the "Or," in the first bullet on page 65 is =
referring
> to. Are you trying to say "If the m=3D section is not new, and the ICE =
ufrag
> and password values have changed" or something else?
>=20
> The intent here is as stated, "if the m=3D section is not new and the =
values have changed". We discussed this but concluded that the meaning =
of the current text was clear.
> =20
>=20
> In the last paragraph of section 8 at "programmer MUST recognize". =
That is
> not an appropriate use of 2119. I suggest "needs to be aware" instead =
of
> "MUST recognize".
>=20
> Micro Nits:
>=20
> Suggested change to the first sentence of 1.1
>=20
>   OLD:
>=20
>     The thinking behind WebRTC call setup has been to fully specify =
and
> control the media plane, but to leave the signaling plane up to the
> application as much as possible.
>=20
>   New:
>=20
>     WebRTC call setup has been designed to focus on controlling the =
media
> plane, leaving signaling plane behavior up to the application as much =
as
> possible.
>=20
> The first full bullet on page 18 has a sentence that starts "Note that =
when
> considering". Please change that to simply "When considering". As =
written,
> there is an implication that this is a consequence of something =
specified
> somewhere else.
>=20
> The verb "surfaced" appears three times in the document without =
support or
> definition. Can you replace them with simpler language?
>=20
> At the second to last sub-bullet at the end of page 66, please remove =
"note
> that". The sentence is stronger without it.
>=20
> I noted these sections as particularly hard to read when going through =
the
> document linearly. I don't have concrete suggestions for improvement, =
but
> perhaps other eyes (if they agree the sections could use improvement) =
can
> come up with something:
>  - First sentence of the first paragraph on page 19.
>  - 2nd sentence of the 4th paragraph on page 19.
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org 
> https://www.ietf.org/mailman/listinfo/rtcweb =

>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_BFA7169F-F2CB-4F4E-AF02-2DBB7F3F9269
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Robert, thanks for your review. Justin, =
thanks for your response. I have entered a Yes ballot.

Alissa


On Aug 26, 2017, at 2:10 PM, =
Justin Uberti <juberti@google.com> wrote:

Thanks for this careful review. A new version of the document =
(-22) has been posted which addresses almost all of these comments, with =
a few exceptions noted below.

Diff: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-jsep-21&a=
mp;url2=3Ddraft-ietf-rtcweb-jsep-22&difftype=3D--html

On Tue, =
Aug 8, 2017 at 12:31 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
Reviewer: =
Robert Sparks

Review result: Almost Ready



I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments =
just

like any other last call comments.



For more information, please see the FAQ at



<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.



Document: draft-ietf-rtcweb-jsep-21

Reviewer: Robert Sparks

Review Date: 2017-08-08

IETF LC End Date: 2017-08-11

IESG Telechat date: Not scheduled for a telechat



Summary: Almost ready for publication as a Proposed Standard RFC, but =
with

issues that need to be addressed before publishing



Major issues:



The last paragraph of 5.1 needs more context. Why woudn't you expect =
the

re-offer to fail, given that you already know the peer is using the =
older

profile strings? It's not clear from the email list and proceedings how =
the

document ended up with this particular text.



Minor issues:



Second paragraph of 3.2, last sentence: at "these parameters or =
reject

them" - "these" and "them" have ambiguous antecedents. It's not clear if =
you

are trying to point to the parameters that don't follow the earlier =
stated

rule, or all parameters. The sentence is complex. Splitting it up and

finding a way to avoid the need for the semicolon will likely make it

easier to say what you mean.



Last paragraph on page 5 - first sentence: at "One way to mitigate this" =
-

"this" has an unclear antecedent. Did you mean "One way to reduce the

complexity of the application's responsibilities"?



Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. =
Please

state precisely which fields you mean.



Odd edge: The description createAnswer (in 4.1.7) leaves open the

possibility that the application could call createAnswer twice

(back-to-back with no intervening calls to other APIs) with different

values in the options parameter. Is this ok? If not, should there be

language that says not to do that somewhere?



Slightly more than minor maybe: The first paragraph of 5.1.2 has at =
least a

reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's =
in

RFC5764. Assuming that this is only a reference error, then the last

sentence seems like a stray. It doesn't seem to be in the right =
context

("this advertisement" doesn't cast back to the discussion of the two

profiles above it, which are both UDP only). Please clarify the =
sentence,

giving it the right context, or remove it.



The fourth sentence of the second bullet of section 5.2.1 is confusing. =
(It

starts "It is RECOMMENDED that the <sess-id>".) RFC3265 requires =
the

initial sess-id high-order bit to be zero. As written, this can be read =
to

say that setting that bit to zero is only RECOMMENDED, and that it's

possible to have sess-ids that are something other than 64 bits. You =
mean

to say "Do what 3265 says to do and make the lower 63 bits random". =
Here's

one possible replacement for the sentence: "RFC 3265 requires that =
the

high-order bit of the initial <sess-id> be zero. It is RECOMMENDED =
that the

remaining 63 bits be initially set to a cryptographically random =
value."



The last paragraph of 5.3.1 prohibits the same attributes from =
generated

answers that are prohibited in generated offers. Consider adding text =
for

what to do if an offer shows up from a peer with some of those =
prohibited

attributes.

This is covered by the last paragraph =
on page 43:

   Note that these requirements are in some cases =
stricter than those of
   SDP.  Implementations MUST be prepared to accept compliant SDP even
   if it would not conform to the requirements for generating SDP =
in 
   this =
specification. 




The second paragraph of section 5.4 is confusing. A slight restructuring =
of

the sentences would remove much of the potential confusion, I think. =
I

suggest replacing the first sentence (which is very complex) with =
this:

"After calling setLocalDescription, the application MAY modify the SDP =
to

reduce the capabilities in the offer before sending it to the far side, =
as

long as it remains a valid SDP offer and specifies a subset of what was =
in

the original offer. Likewise, an application that has received an =
offer

from a peer MAY modify the received SDP, subject to those same =
constraints,

before calling setRemoteDescription."



The first paragraph of section 5.7.1 is simply restating requirements =
from

RFC4566. Restating normative requirements like that has led to =
interop

problems through unintended introduced ambiguity and spec maintenance

problems. Please consider rewriting the paragraph to say "RFC4566 says" =
and

avoid the 2119 keywords.

We considered this, but found that a) =
RFC4566 is clearly cited, and b) the actual restatement was very minor, =
really just affecting the discussion of the v=3D and o=3D lines. As a =
result we concluded that pointing the reader elsewhere just for those =
two lines did not seem like an improvement.
 



On page 69, at "If the application attempt to transmit DTMF when using =
a

media format that does not have a corresponding telephone-event =
format,

this MUST result in an error". This sentence is out-of-place. The =
section

is about applying a remote description. If the document needs to retain =
the

sentence, it belongs off in some "processing media" section. In =
particular,

the current placement of text is confusing about what and when an =
error

could be returned, and it could be misread to say that an error should =
be

returned to the setRemoteDescription call.



Nits:



Section 1.2 second paragraph - "This was rejected based on a feeling". =
Can

you write something that speaks to consensus here? "Based on a =
feeling"

isn't quite right. Maybe "using the argument"?



PeerConnection is used first at the next to last paragraph of section =
3.

Please add a reference at that point.



"LS" (lipsync) is first used at 4.1.2, with no context for what it =
is.

Please add a reference.



The concept of a "pending local description" is used in sections =
3.5.1,

4.1.6, and 4.1.7  but isn't really explained until much later in =
the

document. Please provide forward references, or move a description of =
what

a pending description is earlier in the document.



In 4.1.7 (create Answer) why would calling setLocalDescription cause =
the

answer to be a _pending_ local description. I think it's the full on =
local

description at that point, not a pending one?



At 4.1.17's first paragraph: Why is "if parsed successfully" necessary =
to

call out? I suggest removing the phrase.



4.2.3 talks about setting direction properties, but the values that can =
be

set aren't called out (and even then only by inference from a list in =
an

example) in section 4.2.5. Should there be explicit pointers to the api =
doc

here? (And in section 4.2.6?)



There are two paragraphs on page 50 that start "The next step is to". =
They

are both referring to the same step. I suggest combining the =
paragraphs.



The 4th bullet on page 64 is ambiguous at "this m=3D section". It looks =
like

this bullet should just be merged with the previous bullet.
=



The second paragraph of 6.8 starts "Next, ". I think it should start

"First, ".



It's not clear what the "Or," in the first bullet on page 65 is =
referring

to. Are you trying to say "If the m=3D section is not new, and the ICE =
ufrag

and password values have changed" or something else?

The intent here is as stated, "if the m=3D section is not new =
and the values have changed". We discussed this but concluded that the =
meaning of the current text was clear.
 



In the last paragraph of section 8 at "programmer MUST recognize". That =
is

not an appropriate use of 2119. I suggest "needs to be aware" instead =
of

"MUST recognize".



Micro Nits:



Suggested change to the first sentence of 1.1



  OLD:



    The thinking behind WebRTC call setup has been to fully =
specify and

control the media plane, but to leave the signaling plane up to the

application as much as possible.



  New:



    WebRTC call setup has been designed to focus on =
controlling the media

plane, leaving signaling plane behavior up to the application as much =
as

possible.



The first full bullet on page 18 has a sentence that starts "Note that =
when

considering". Please change that to simply "When considering". As =
written,

there is an implication that this is a consequence of something =
specified

somewhere else.



The verb "surfaced" appears three times in the document without support =
or

definition. Can you replace them with simpler language?



At the second to last sub-bullet at the end of page 66, please remove =
"note

that". The sentence is stronger without it.



I noted these sections as particularly hard to read when going through =
the

document linearly. I don't have concrete suggestions for improvement, =
but

perhaps other eyes (if they agree the sections could use improvement) =
can

come up with something:

 - First sentence of the first paragraph on page 19.

 - 2nd sentence of the 4th paragraph on page 19.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
Gen-art =
mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

=

--Apple-Mail=_BFA7169F-F2CB-4F4E-AF02-2DBB7F3F9269--


From nobody Wed Dec 13 21:42:21 2017
Return-Path: 
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03B71200F3; Wed, 13 Dec 2017 21:42:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins 
To: "The IESG" 
Cc: draft-ietf-rtcweb-jsep@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151323013465.6079.10099272164953886555.idtracker@ietfa.amsl.com>
Date: Wed, 13 Dec 2017 21:42:14 -0800
Archived-At: 
Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Dec 2017 05:42:14 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-rtcweb-jsep-24: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found myself wishing that Section 3.8 was a bit clearer about the advantages
of sequential versus parallel forking. I can imagine some of the advantages
because I have a SIP background, and I can dig some of what I was expecting to
see in 3.8.2, but I'm imagining and digging, and I'm betting that the document
could be more explicit about the tradeoffs - just saying "if you're
communicating with a SIP endpoint, most of them can only exchange media with
one endpoint at a time" is already helping.



From nobody Thu Dec 14 13:32:29 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247D0129477 for ; Thu, 14 Dec 2017 13:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vluVseW8wXU2 for ; Thu, 14 Dec 2017 13:32:25 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B631F127599 for ; Thu, 14 Dec 2017 13:32:24 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id y10so6157240otg.10 for ; Thu, 14 Dec 2017 13:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F49eYc8NQIR6bGekf5AcWT54a8hC2ZSmBCWKvc9jwxk=; b=iihf/Sq5kxxnFLXm+Xe1lQQ0HXYHAk0EAS9ftQledo+XlPitipgGxqnNX0Jdk60vIz NSbkW32QU2O+b7e84zf5nVeNooDwubkWWfIxjPyDewlwuAyqg09G8zHBC79NdNNGKX1m gL329ZhKOjHmSwi9IKwSkMGXXiG8hJ13WfndAU4qT/RVXRTaR9DePeOlbQEVzJxdJOXc Pmh7rW/prQS2WB2+2mr+oMLhnjYhxSkKDi/JeHjqrxcJYEQ0S00YDo3O0n/eKjqHaWeV sbvSE+oMYFgFwrcj8QXljz9aaWJ0Rh0gh75WD4M7rCGrSZmTs2t8PV9nrwKFQjlm0Tw/ QV/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F49eYc8NQIR6bGekf5AcWT54a8hC2ZSmBCWKvc9jwxk=; b=rQ7E2N2IogYP3sNBDhsdiV/GGJCfOzGfenObeC90y3JpnXBXg7lcvUtQ0dRiaJhfLd P2AtgcjSZzMC50eWV5omWKA++6BqMmJstHS5a9IJgMVw21FU6GmbcC3p1wP0Wgr8Ie/e Q98fpI4Lf9+QIz7LbPBKlwloW1UBClYijK1SbUlhLrHWY68noX1eWhFKOo+xEG1pYncP 8qf/RJ2aGXT2vHkblH6ga5ERjBi15BEhaJ8M80MGnFnrUlcoJfvBfEB+vIIjhztUXOES DDUgqGcs2h9frm7aJacYn1XdipWK85buHcuyau6sIFdWITa/ObC9TKQrmjEpArk7ozjI ReZA==
X-Gm-Message-State: AKGB3mLr95eW7S9P8HOkJl2PzweRUYTxQsqv5LlchdWcjdPo9U5JApaA LL9igAOa8r4WFKHj3fusmlm3z0h771x026WbizhIHw==
X-Google-Smtp-Source: ACJfBou4krSSUHM1cfbgLRblEDQXo7MJ1RkFKM8kg6I9ThnnSmNVj7ZKOPSerHCDvh3s0JSmLNrEaKpRQ0Bba7I5dZA=
X-Received: by 10.157.32.19 with SMTP id n19mr6316839ota.133.1513287143936; Thu, 14 Dec 2017 13:32:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Thu, 14 Dec 2017 13:32:23 -0800 (PST)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Thu, 14 Dec 2017 15:32:23 -0600
Message-ID: 
To: Justin Uberti 
Cc: "rtcweb@ietf.org" , Bernard Aboba 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Dec 2017 21:32:28 -0000

Since I was asked...

1. I think that this might benefit from a mention of the case.  You
are taking the effort to address the VPN case, but if someone has a
public address, this might be a surprise.

2. No specific text necessary here I think.  Forcing a proxy should do
for this case.  It's true that Tor browser doesn't necessarily disable
JS and WebRTC, but the forced proxy mode is a reasonable strategy for
that case.

3. I agree with you.

On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti  wrote:
> Since there will be no WG meeting this week, here are the open issues for
> the document. Feedback on these issues is the only thing standing between
> this document and WGLC.
>
> 1. https://github.com/juberti/draughts/issues/59
>
> In the problem statement, should the paragraph on VPNs mention IP address
> discovery?
>
> Currently, the problem statement says the following:
>
>    1.  If the client is behind a Network Address Translator (NAT), the
>
>        client's private IP addresses, typically [RFC1918] addresses, can
>
>        be learned.
>
>    2.  If the client tries to hide its physical location through a
>
>        Virtual Private Network (VPN), and the VPN and local OS support
>
>        routing over multiple interfaces (i.e., a "split-tunnel" VPN),
>
>        WebRTC will discover the public address for the VPN as well as
>
>        the ISP public address that the VPN runs over.
>
> However, Bernard mentioned that even without split-tunnel support, the ICE
> implementation allows discovery of the VPN private address. I think this is
> covered by the first paragraph, but perhaps this should be spelled out
> further. Thoughts?
>
> 2. https://github.com/juberti/draughts/issues/60.
>
> Should supporting WebRTC over Tor be an explicit goal of this document (and
> mentioned in the goals section)?
>
> This scenario is possible via Mode 4, e.g. force-proxy mode, but it may be
> out of scope for this document. Bernard mentioned that it may be out of
> scope as Tor distros can disable Javascript, making WebRTC useless, but upon
> investigation I found that the default Tor bundle does enable Javascript,
> and so this is worth considering. Thoughts?
>
> 3. https://github.com/juberti/draughts/issues/61
>
> Should the document discuss implementation details as it relates to
> suggested default behavior?
>
> The document currently says the following:
>
>     1.  By default, WebRTC should follow normal IP routing rules, to the
>
>        extent that this is easy to determine (i.e., not considering
>
>        proxies).  This can be accomplished by binding local sockets to
>
>        the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
>
>        allows the OS to route WebRTC traffic the same way as it would
>
>        HTTP traffic, and allows only the 'typical' public addresses to
>
>        be discovered.
>
> However, Bernard thinks that this text may be making some assumptions,
> specifically about whether a strong or weak host model is used. My thinking
> was that spelling out the general implementation approach helps readers grok
> exactly what this section is getting at, but open to other opinions here.
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From nobody Tue Dec 19 04:28:09 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3312DA6B for ; Tue, 19 Dec 2017 04:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_aUdyk6Mxum for ; Tue, 19 Dec 2017 04:28:06 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D50126C2F for ; Tue, 19 Dec 2017 04:28:05 -0800 (PST)
X-AuditID: c1b4fb2d-b4dff70000007932-e2-5a3905d3adc3
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.B7.31026.3D5093A5; Tue, 19 Dec 2017 13:28:03 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Tue, 19 Dec 2017 13:28:02 +0100
From: Christer Holmberg 
To: "rtcweb@ietf.org" 
Thread-Topic: [MMUSIC] Publication has been requested for draft-ietf-mmusic-sdp-bundle-negotiation-47
Thread-Index: AQHTeC0KYIcrkHhuG0G+6Vq2JV8oIaNKrLcA
Date: Tue, 19 Dec 2017 12:28:02 +0000
Message-ID: 
References: <151362128440.3478.11553006795675719495.idtracker@ietfa.amsl.com>
In-Reply-To: <151362128440.3478.11553006795675719495.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <79F780510AFDA74A89CC0F97D9378636@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdQPcyq2WUwbYWcYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsaqjh71gJ0vFrYvvmRsYPzJ3MXJySAiYSPSefMnSxcjFISRw mFFiycseNghnCaPElV1PWbsYOTjYBCwkuv9pgzSICKhLXH54gR3EFhZIk3j5eRczRDxd4sbc uawQtpHE28mn2EFaWQRUJSb1ZoKEeQWsJW7v6wArFxLwlbi/aS8TSAmngJ/El2awiYwCYhLf T61hArGZBcQlbj2ZzwRxpoDEkj3noU4WlXj5+B/YJlEBPYkNJ26DbZIQUJRY3i8H0aojsWD3 JzYI21riyqPjjBC2tsSyha+ZIa4RlDg58wnLBEaxWUi2zULSPgtJ+ywk7bOQtC9gZF3FKFqc Wlycm25krJdalJlcXJyfp5eXWrKJERg9B7f81t3BuPq14yFGAQ5GJR5ev3cWUUKsiWXFlbmH GCU4mJVEeBfuBArxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLg lGpg9P3r+aOjQ7dGeoKPsK/xlzmzw9ireRz80w4wzNe44yh37+uhKea1D5mc6g+FRxmeM+Hc +f322dt+vmfUOC8f131/2qBNanbxu/M3ahg2n8wr+Cn+dOq75Bcux5P/9Bqczg+uyn6rs6qP eeEklx/hlhHWImeKdee99fv/pO9S47rAabxHQ/g+KrEUZyQaajEXFScCAHHLnkuaAgAA
Archived-At: 
Subject: [rtcweb] FW: [MMUSIC] Publication has been requested for draft-ietf-mmusic-sdp-bundle-negotiation-47
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Dec 2017 12:28:08 -0000

FYI,

Christer

On 18/12/17 20:21, "mmusic on behalf of Flemming Andreasen"
 wrote:

>Flemming Andreasen has requested publication of
>draft-ietf-mmusic-sdp-bundle-negotiation-47 as Proposed Standard on
>behalf of the MMUSIC working group.
>
>Please verify the document's state at
>https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic


From nobody Thu Dec 21 18:25:19 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114031200F1 for ; Thu, 21 Dec 2017 18:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haBRLPeKkZ1y for ; Thu, 21 Dec 2017 18:25:15 -0800 (PST)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCE812711B for ; Thu, 21 Dec 2017 18:25:15 -0800 (PST)
Received: by mail-ua0-x235.google.com with SMTP id i4so18793377uab.5 for ; Thu, 21 Dec 2017 18:25:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RphAf0fi6Ftazp31cvb2hxEiay88NqhiNXyjO46E7y4=; b=KbRc5aO01qBbSVNr0sqGr7Qf0aXBurfUGU+Iaszd2NRktgcE2ifQvZD84UflwCpSw1 C1uhw/FCCPNbyDv+bgrft1t2ge7XMHIZ2M6dLafQoZuY6lC7qRxNu0SqvLeZpn9ptMx0 xvX+pHDs0Z8oXxa6dtPSxcDPVlaa3QVWl5OenI/MQ7S9Vu2sAoydR0KLQlt/6oprRJve aFCJXHlZD/1V2uHD9JjogGoxZFFkVXjI6B2lj2LnqbvcxD2ufnVcBVC0ato3NvD9PDhu p1CbzggwdJ/VmV9NaOe7jP62XIYTmWY/0E8JoVAWVNoeFwgghnGmMvj8EE5QQoPkNPBh 6eeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RphAf0fi6Ftazp31cvb2hxEiay88NqhiNXyjO46E7y4=; b=L+BxzmTNWj4Sms5idRmqPDJ4VzIvSasuF/V7xGOVCNValBV9LJLYtMdDai4p6twjKY pNC2KCFuQql6ttfKQlrDLrmoklCiAQiTv4c1aMSzN0VWo9/iJCFcFYZjl3ygB2WbIFI6 eq+/iAhf1+RhAPPUjyNasPHwM0xAzCf+fsdhQxxnup2BYkuhioyqIbbSwyo8XrFzb5To HygWJSw5Av14FRonTdC3twapT3pjEIUoLUTMbbp2tzkPL4JnJJjAXkr8YDWMO1fImR/y F86Uvmn2JKkHITVwebv4HRTuIotffrVKInk9yZwF7+Arh7LgPOCTVqf0QRRCZs/ZFL+g 8A5Q==
X-Gm-Message-State: AKGB3mJdq4mehr7oqzxOeB+hfd3FkhqWkbTbROjxKqOjr+oJc4P3qMPS /o2KHYulITreB2xFpY4O+rmV234iWGlVqimJqLueSA==
X-Google-Smtp-Source: ACJfBotuEj1RjVddOW/N32gHuFL1FHYbYhn/Mcm2r3MrReCcpP233FR59w1hu79YvmjrPiNPaI7ahAVvEz+gNkK35UM=
X-Received: by 10.176.0.73 with SMTP id 67mr13448678uai.132.1513909513771; Thu, 21 Dec 2017 18:25:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Thu, 21 Dec 2017 18:24:52 -0800 (PST)
In-Reply-To: <151323013465.6079.10099272164953886555.idtracker@ietfa.amsl.com>
References: <151323013465.6079.10099272164953886555.idtracker@ietfa.amsl.com>
From: Justin Uberti 
Date: Thu, 21 Dec 2017 18:24:52 -0800
Message-ID: 
To: Spencer Dawkins 
Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org,  RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Type: multipart/alternative; boundary="001a11c16aaacaffe40560e4860e"
Archived-At: 
Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Dec 2017 02:25:18 -0000

--001a11c16aaacaffe40560e4860e
Content-Type: text/plain; charset="UTF-8"

Thanks for your comments. Didn't follow what you were saying completely
though, are you asking for some additional discussion about upsides or
downsides of parallel forking (or both)?


On Wed, Dec 13, 2017 at 9:42 PM, Spencer Dawkins <
spencerdawkins.ietf@gmail.com> wrote:

> Spencer Dawkins has entered the following ballot position for
> draft-ietf-rtcweb-jsep-24: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I found myself wishing that Section 3.8 was a bit clearer about the
> advantages
> of sequential versus parallel forking. I can imagine some of the advantages
> because I have a SIP background, and I can dig some of what I was
> expecting to
> see in 3.8.2, but I'm imagining and digging, and I'm betting that the
> document
> could be more explicit about the tradeoffs - just saying "if you're
> communicating with a SIP endpoint, most of them can only exchange media
> with
> one endpoint at a time" is already helping.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11c16aaacaffe40560e4860e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for your comments. Didn't follow what you were =
saying completely though, are you asking for some additional discussion abo=
ut upsides or downsides of parallel forking (or both)?

=


On Wed, Dec 13, 2=
017 at 9:42 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com=
> wrote:
Spencer Dawkins ha=
s entered the following ballot position for

draft-ietf-rtcweb-jsep-24: Yes



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-=
ietf-rtcweb-jsep/







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

COMMENT:

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



I found myself wishing that Section 3.8 was a bit clearer about the advanta=
ges

of sequential versus parallel forking. I can imagine some of the advantages=


because I have a SIP background, and I can dig some of what I was expecting=
 to

see in 3.8.2, but I'm imagining and digging, and I'm betting that t=
he document

could be more explicit about the tradeoffs - just saying "if you'r=
e

communicating with a SIP endpoint, most of them can only exchange media wit=
h

one endpoint at a time" is already helping.





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--001a11c16aaacaffe40560e4860e--


From nobody Thu Dec 21 18:25:49 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E614812D80F for ; Thu, 21 Dec 2017 18:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbJ3CddqpTTF for ; Thu, 21 Dec 2017 18:25:42 -0800 (PST)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4137112D7F9 for ; Thu, 21 Dec 2017 18:25:35 -0800 (PST)
Received: by mail-ua0-x22b.google.com with SMTP id q13so18784863uaq.8 for ; Thu, 21 Dec 2017 18:25:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mToGk8npejFtdv7ffIEpQQQWcnndxb5BFwW3do0+Vag=; b=ouLAkj4D96kq+V203qRSWear/KsOJuwSqd/w0w0taVcs7BEhkJqzrGZ+V7qqCG3RIs d1DW2dIczgktbXu34uewC8nmkEqIngXMHJoUmapgfxzfNdJPxtnYggJH0BSuyD19VV6+ eh5SM0tNJoaY6LhEDHSUDD113F/KA9/wMy47lbd88ywlyhviWA5PUKfy4R9XBgkH9KJ1 /XPuYiQ8zCICqbz7Qx1i4MK4JaoVHSIdljysBB3bWCnFzrZ2/HZ1rgsdCyl6ZmCvi9x3 apCFmAR57M72qqzW0OtWpMzo7wwPOOLDq4rk2n/Zfp5C1NSVAEiMef6x8exLgaRgoUhy VA+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mToGk8npejFtdv7ffIEpQQQWcnndxb5BFwW3do0+Vag=; b=glDBRHYSgvzs0jLyHoSQPGxgzDW92DoIyoQ1nN4kLwlrxtUnP58RMpFG7qIvkrp1ox ZhQnyFWibP+nauvsUsZBuHeZx2soX9I12GXWpWoLK94J3qM3S/JnAfm4IalKXwqB/loc l1tLqWHupUksnw1bHSU7PSyK+IMmUvOMQSsB8CccIzJ8UT/PhThoaUIYDY1ds2QERJ7c FEe6/3+QCxSeNDTpkkR0NN3GsL4vuI1pjay2+5E7INaz78PsRO0QS/qx7Owy+040FAzX ao/IpclOn4z3z0fadGRSRc4ir9QFuZAOqSBfYa2VbIpJT0wLG71LpYteDLWcyAmDxyIi 7LUQ==
X-Gm-Message-State: AKGB3mK9slJ2QXMT8lj744OzIob3duHJbYMjH0tbE4DlfomJGFUZp2ox NNDlUdbDyGN9y+4FXzSw6Io7oFFSn8SSaS+jEYuY7A==
X-Google-Smtp-Source: ACJfBotUS2y/h6BHfpdTp7fCy1hFnS9qytvOCiYf0aDHgpWGIQrC8O6m29u/xt5/z5AdJIpO3tkoGZXP+NqQhnIuWQ8=
X-Received: by 10.176.80.252 with SMTP id d57mr14381250uaa.203.1513909533943;  Thu, 21 Dec 2017 18:25:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Thu, 21 Dec 2017 18:25:13 -0800 (PST)
In-Reply-To: <151311562760.14100.8542671795905150712.idtracker@ietfa.amsl.com>
References: <151311562760.14100.8542671795905150712.idtracker@ietfa.amsl.com>
From: Justin Uberti 
Date: Thu, 21 Dec 2017 18:25:13 -0800
Message-ID: 
To: Kathleen Moriarty 
Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org,  RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c191078fea4ec0560e487db"
Archived-At: 
Subject: Re: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Dec 2017 02:25:44 -0000

--94eb2c191078fea4ec0560e487db
Content-Type: text/plain; charset="UTF-8"

Thanks, will fix in -25.

On Tue, Dec 12, 2017 at 1:53 PM, Kathleen Moriarty <
Kathleen.Moriarty.ietf@gmail.com> wrote:

> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-rtcweb-jsep-24: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm sure the RFC editor would have caught this nit:
>
> 2nd paragraph of security considerations section:
> While formally the JSEP interface is an API, it is better to think of
>    it is an Internet protocol
> s/is an Internet/as an Internet/
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--94eb2c191078fea4ec0560e487db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks, will fix in -25.
<=
br>
On Tue, Dec 12, 2017 at 1:53 PM, Kathleen Mor=
iarty <Kathleen.Moriarty.ietf@gmail.com> wrot=
e:
Kathleen Moriarty has entered the foll=
owing ballot position for

draft-ietf-rtcweb-jsep-24: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-=
ietf-rtcweb-jsep/







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

COMMENT:

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



I'm sure the RFC editor would have caught this nit:



2nd paragraph of security considerations section:

While formally the JSEP interface is an API, it is better to think of

=C2=A0 =C2=A0it is an Internet protocol

s/is an Internet/as an Internet/





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--94eb2c191078fea4ec0560e487db--


From nobody Thu Dec 21 18:27:08 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A612D864 for ; Thu, 21 Dec 2017 18:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqaXX9cwcMhk for ; Thu, 21 Dec 2017 18:27:04 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A0E12D7F9 for ; Thu, 21 Dec 2017 18:27:04 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id l36so18821000uae.4 for ; Thu, 21 Dec 2017 18:27:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wkd6s05o9c0ZEralbbqbTjNjiYNq+NsRhozITUgfb/A=; b=Inq4Y6eKcpNszyY/b/Tl98qnsT694mXhr8zIqB8lkj5AhJwVmHDjKOLpMC3DYTrHRI /JN/r9uW0v6ecdB0YoGTnSFwa8nPmB/yDpfMnCBkek9tLMTLdShfo8jAGIlD4WZb4RHl 108V/hgHM6dW+0FV2gURnrADTXd44RNd1hbHqmi+DONHCD+CPqrRAztIkZ7+xDCfZMcC bl7vR1+8HqdZgTRjoU8cLYRw58JKUU5KvSkghgW9vIO5quBtZCDmigXxr1vGhZFQ0yU7 vAbyVthSRUsZWIs5nXKrq246qCwsL9Nde4GvU2plPp6NlGk0aNMLt6LT8unt1e8FhSg8 PlKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wkd6s05o9c0ZEralbbqbTjNjiYNq+NsRhozITUgfb/A=; b=foknoq2RWOGP9E7dUfyzoAmoHzDHmv7PwXsATTcygevs2f8T7LAe1ioQ5jiInUuwlB ohOSfu3RgPzOia2smElhZrnlCXdevSpyDOOvto+1alFO3/h3QZiQZwsilANYMrCSgA6c VdgfnFwIO5XD8wpcsOluzmfJDfzNdUqO7U0f6d6sMSTnBx+HMAM9t/ovr5lPhBQti6A5 9eFvJ0H9rty88BbStLboXmUCB/76OSSkAcNfcL7cRs4OdxGUyEktUYWwWZet2TZ+lEW0 isqm6o8FDGkzVdujhaAwGCa12n0gNnRHQ2C+tnCfG3i6I9J1BEEra2Ln+1hHutEPMI+j qK3w==
X-Gm-Message-State: AKGB3mLnmeOHgZABVILQZJNVvpq6IUW7IwuLdJ9KLx9HxfmDJnEtIFKU 7mpkqFlJb4r+1zHGld711YHVzktgFfrU1CGdO5sw1Q==
X-Google-Smtp-Source: ACJfBos6I+bn4r1a0lM/Lk4LvnXLB5ePCZ8UjSvfiGWk8LNaV1D/OnuYddK+6vAlXuhQ1RGmCGvoKydugdQhLecC2nQ=
X-Received: by 10.159.51.2 with SMTP id o2mr14043662uab.194.1513909623106; Thu, 21 Dec 2017 18:27:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Thu, 21 Dec 2017 18:26:42 -0800 (PST)
In-Reply-To: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com>
References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com>
From: Justin Uberti 
Date: Thu, 21 Dec 2017 18:26:42 -0800
Message-ID: 
To: Ben Campbell 
Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org,  RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Type: multipart/alternative; boundary="f403045dcc9c4f72610560e48d3f"
Archived-At: 
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Dec 2017 02:27:07 -0000

--f403045dcc9c4f72610560e48d3f
Content-Type: text/plain; charset="UTF-8"

Thanks for the detailed comments, will send a full response shortly.

On Mon, Dec 11, 2017 at 7:49 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-rtcweb-jsep-24: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting "yes", but I have some minor comments and nits:
>
> Substantive:
>
> - General:
> I still find the edges around where SDP is and isn't required a bit vague.
> Section 3.3 says that the JSEP implementation internal representation is
> SDP.
> While I have trouble imagining implementing this otherwise, do we really
> mean
> to mandate the internals? Is there an assumption that said internal
> representation is _serialized_ SDP vs some abstract internal
> representation?
>
> Section 3.1 says that the signaling model is not specified. Is there an
> implicit assumption that, however things are signaled, the signaling
> process
> moves around serialized SDP? Or is it envisioned that one could write an
> application without serialized SDP occurring anywhere above the API?
>
> -5, throughout: There are a number of normative keywords used in
> constructions
> like "... MUST foo, as described in RFCXXX". That construction is ambiguous
> about whether it defines a normative requirement to do something, and the
> doing
> of that something is described in the RFC, or if describes the referenced
> RFC
> as defining the MUST.
>
> In general, it's best to avoid using 2119/8174 keywords to talk about
> external
> requirements, except as a direct quote. I think this is especially true
> here
> given the interdependencies between drafts in cluster 238. If in the
> future we
> update a dependency to change a normative requirement, we risk creating
> conflicts, and we make it unclear which text is authoritative.
>
> -5.1.1: I think the operative requirement is "MUST support" rather than
> "MUST
> indicate support". (While indication may also be required, it seems a
> consequence of "MUST support".)
>
> -5.1.2: " Any profile in the offer matching one of the following MUST be
> accepted:" Isn't the real requirement that any of the following must be
> interpreted the same, or otherwise in some specified way? I assume there
> may be
> completely unrelated reasons to reject an m-section, but the "MUST be
> accepted"
> language seems to overrule that.
>
> -5.4: "The SDP returned from createOffer or createAnswer MUST NOT be
> changed
>    before passing it to setLocalDescription."
> Is that a requirement on the JSEP implementation, or the javascript
> application? If the latter, is it appropriate to put normative
> requirements on
> the application? It seems like it would be better to normatively state the
> JSEP
> implementations's behavior when the application does something incorrect.
> (Which seems to be done further down the page.)
>
> -5.7: " The effect of rollback MUST be the same regardless of whether
> setLocalDescription or setRemoteDescription is called." Does that mean if I
> call setLocalDescription, then rollback with a call to
> setRemoteDescription,
> _both_ are rolled back?
>
> -5.8.3: The MUSTs in this section seem to be putting requirements on the
> SDP
> being parsed. Shouldn't they instead describe the parser's behavior based
> on
> that SDP input? The correctness of the SDP being parsed seems beyond the
> control of the implementation.
>
> -8, second paragraph: When describing how the javascript is untrusted, it
> may
> be worth mentioning that it may have been downloaded from an untrusted
> source.
>
> Editorial and Nits:
>
> -1.1: Please expand ICE and MCU on the first mention.
> s/config/configuration
> Sentence starting with "Through its abstraction of signaling...": Should
> that
> say "Though it abstracts signaling..."
>
> -2: Please consider using the boilerplate from RFC 8174. There are a
> number of
> instances of lowercase versions of normative keywords.
>
> -3.2, paragraph 2: The MUST seems like a statement of fact.
>
> -3.4.1, 2nd paragraph: Please expand or explain "mid" on first mention.
> (It is
> explained 3.5.2.1)
>
> -3.5.1, last paragraph: Inconsistent capitalization: "MID"
>
> -3.5.2.1: Please expand (or define) "ufrag" on first mention.
>
> -3.6.1, first paragraph: is "intersect" the correct verb here? Missing
> conjunction in "hardware decoder capababilities, local policy".
>
> -3.6.2, 2nd paragraph: s/"may be producing"/"may produce"
>
> -4.1.2: Please expand LS on first mention. (I can guess from context.
> Please
> don't make me :-)  )
>
> - 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP"
> "for each SDP line, the generation of the SDP will follow the process
> defined
> for generating an initial offer from the document that specifies the given
> SDP
> line." While I worked out what that means, I found "document" to be
> ambiguous.
> At first I interpreted it as the "SDP document" rather than "the RFC".
> (Note
> this occurs several times in subsequent sections.)
>
> -4.1.8, third paragraph: ""pranswer" indicates that a description should be
> parsed as an
>    answer, but not a final answer"
> I think it would be more clear to say "... parsed as a provisional answer,
> rather than a final answer".
>
> -5.2.1: Paragraph starting with: " Each m= section, provided it is not
> marked
> as bundle-only, MUST generate..." The m= section is not the real actor
> here, is
> it?
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f403045dcc9c4f72610560e48d3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the detailed comments, will send a full respons=
e shortly.

O=
n Mon, Dec 11, 2017 at 7:49 PM, Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the fol=
lowing ballot position for

draft-ietf-rtcweb-jsep-24: Yes



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-=
ietf-rtcweb-jsep/







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

COMMENT:

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



I'm balloting "yes", but I have some minor comments and nits:=




Substantive:



- General:

I still find the edges around where SDP is and isn't required a bit vag=
ue.

Section 3.3 says that the JSEP implementation internal representation is SD=
P.

While I have trouble imagining implementing this otherwise, do we really me=
an

to mandate the internals? Is there an assumption that said internal

representation is _serialized_ SDP vs some abstract internal representation=
?



Section 3.1 says that the signaling model is not specified. Is there an

implicit assumption that, however things are signaled, the signaling proces=
s

moves around serialized SDP? Or is it envisioned that one could write an
application without serialized SDP occurring anywhere above the API?



-5, throughout: There are a number of normative keywords used in constructi=
ons

like "... MUST foo, as described in RFCXXX". That construction is=
 ambiguous

about whether it defines a normative requirement to do something, and the d=
oing

of that something is described in the RFC, or if describes the referenced R=
FC

as defining the MUST.



In general, it's best to avoid using 2119/8174 keywords to talk about e=
xternal

requirements, except as a direct quote. I think this is especially true her=
e

given the interdependencies between drafts in cluster 238. If in the future=
 we

update a dependency to change a normative requirement, we risk creating

conflicts, and we make it unclear which text is authoritative.



-5.1.1: I think the operative requirement is "MUST support" rathe=
r than "MUST

indicate support". (While indication may also be required, it seems a<=
br>
consequence of "MUST support".)



-5.1.2: " Any profile in the offer matching one of the following MUST =
be

accepted:" Isn't the real requirement that any of the following mu=
st be

interpreted the same, or otherwise in some specified way? I assume there ma=
y be

completely unrelated reasons to reject an m-section, but the "MUST be =
accepted"

language seems to overrule that.



-5.4: "The SDP returned from createOffer or createAnswer MUST NOT be c=
hanged

=C2=A0 =C2=A0before passing it to setLocalDescription."

Is that a requirement on the JSEP implementation, or the javascript

application? If the latter, is it appropriate to put normative requirements=
 on

the application? It seems like it would be better to normatively state the =
JSEP

implementations's behavior when the application does something incorrec=
t.

(Which seems to be done further down the page.)



-5.7: " The effect of rollback MUST be the same regardless of whether<=
br>
setLocalDescription or setRemoteDescription is called." Does that mean=
 if I

call setLocalDescription, then rollback with a call to setRemoteDescription=
,

_both_ are rolled back?



-5.8.3: The MUSTs in this section seem to be putting requirements on the SD=
P

being parsed. Shouldn't they instead describe the parser's behavior=
 based on

that SDP input? The correctness of the SDP being parsed seems beyond the
control of the implementation.



-8, second paragraph: When describing how the javascript is untrusted, it m=
ay

be worth mentioning that it may have been downloaded from an untrusted sour=
ce.



Editorial and Nits:



-1.1: Please expand ICE and MCU on the first mention.

s/config/configuration

Sentence starting with "Through its abstraction of signaling...":=
 Should that

say "Though it abstracts signaling..."



-2: Please consider using the boilerplate from RFC 8174. There are a number=
 of

instances of lowercase versions of normative keywords.



-3.2, paragraph 2: The MUST seems like a statement of fact.



-3.4.1, 2nd paragraph: Please expand or explain "mid" on first me=
ntion. (It is

explained 3.5.2.1)



-3.5.1, last paragraph: Inconsistent capitalization: "MID"



-3.5.2.1: Please expand (or define) "ufrag" on first mention.



-3.6.1, first paragraph: is "intersect" the correct verb here? Mi=
ssing

conjunction in "hardware decoder capababilities, local policy".


-3.6.2, 2nd paragraph: s/"may be producing"/"may produce&quo=
t;



-4.1.2: Please expand LS on first mention. (I can guess from context. Pleas=
e

don't make me :-)=C2=A0 )



- 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP"

"for each SDP line, the generation of the SDP will follow the process =
defined

for generating an initial offer from the document that specifies the given =
SDP

line." While I worked out what that means, I found "document"=
; to be ambiguous.

At first I interpreted it as the "SDP document" rather than "=
;the RFC". (Note

this occurs several times in subsequent sections.)



-4.1.8, third paragraph: ""pranswer" indicates that a descri=
ption should be

parsed as an

=C2=A0 =C2=A0answer, but not a final answer"

I think it would be more clear to say "... parsed as a provisional ans=
wer,

rather than a final answer".



-5.2.1: Paragraph starting with: " Each m=3D section, provided it is n=
ot marked

as bundle-only, MUST generate..." The m=3D section is not the real act=
or here, is

it?





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--f403045dcc9c4f72610560e48d3f--


From nobody Thu Dec 21 18:32:12 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03FF12D7EE for ; Thu, 21 Dec 2017 18:32:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlCK4VHAuxh0 for ; Thu, 21 Dec 2017 18:32:05 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516C6120713 for ; Thu, 21 Dec 2017 18:32:02 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id k132so7606651vke.10 for ; Thu, 21 Dec 2017 18:32:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nvp0QBdvsSmesStK5a5Lqu/Bh5bY9p+Fsycs+WbU9nE=; b=Hqg4jXH9fB3sQMGpVSm0pCgAWsvGpxptXCciuZ8+UnQcDyc5ug3DJkbqhmbQsiWhpc lKv8RFrXov/62soIXgfx75PxT7zSkgDvADfC7VKNyd1IZKJkY5n6eIIJrf1+ngT2hnlJ nlW3iKjdvqo6YBQEEsw9OVw+o58v1YqtfQw8wryPnSQERQdZmPOKPAEDJ4L+NHKNEifu ZaTV4Lb6Wb8XtPxbV2tBVk80vbnq/OHByJnG7RqPmwLafatUmuQVRHmMpQ9n2nuXcd0u FAqSyNbC4c5LjDQG1m0MEPe/3rRhDQSJiuSLOJNyDeUsZf1oMapFn9WzOKhGSiGeoUOp oF9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nvp0QBdvsSmesStK5a5Lqu/Bh5bY9p+Fsycs+WbU9nE=; b=tXaOZoNA+ILY8A4nqId46lmoIBHQaZPrrCtXdK29EwFjusMKV3efdNyqqxW8EZnK+v jBJBKO5K0ZIZGlRuGhKGXHWTeWguVfC/bnYkPa/KDLtejET+5gj/xzaY4nb/Dc1lLj2Q z1X5mMFxhNqhIDxTphRuXHrCBsi3UClM0Ei3ezYuWHjmpsBZ5hgMQ1BZqZ+Mys+ZOP1G QJsrPnQz00su3crutjW5NMe9AntKg6X8YNnSqAiZ9NMSQjAG87hi2/4F5mZMEc94VVhU StxXN3tlXo7HeRwVIGOR3+CX+WCH2M6hPbgaS0LYgDCoTS8afYH3tFRc1ZBIICEHsqvE /hVQ==
X-Gm-Message-State: AKGB3mLn/P8dYDJT5GWbl+A4s0bjkt6vbpglKTz25zVXq3SQZq9hhlfZ sAATeakBsKDVvdi6yqsriJwgcxYwUr7rEK58VjgoFc1U7iQ=
X-Google-Smtp-Source: ACJfBoulLQm60Fr3kKMeWXQN1bervAeB2EkSdVx9DR/fPIe1czZiMLsTnvQ/vITBuUZ07OhBwj2KteSqwJpuaIrYznY=
X-Received: by 10.31.199.129 with SMTP id x123mr12215685vkf.12.1513909920823;  Thu, 21 Dec 2017 18:32:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.178.204 with HTTP; Thu, 21 Dec 2017 18:31:40 -0800 (PST)
In-Reply-To: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com>
References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com>
From: Justin Uberti 
Date: Thu, 21 Dec 2017 18:31:40 -0800
Message-ID: 
To: Ben Campbell 
Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org,  RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Type: multipart/alternative; boundary="001a11484c9a0e34010560e49fd3"
Archived-At: 
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Dec 2017 02:32:08 -0000

--001a11484c9a0e34010560e49fd3
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 11, 2017 at 7:49 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-rtcweb-jsep-24: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting "yes", but I have some minor comments and nits:
>
> Substantive:
>
> - General:
> I still find the edges around where SDP is and isn't required a bit vague.
> Section 3.3 says that the JSEP implementation internal representation is
> SDP.
> While I have trouble imagining implementing this otherwise, do we really
> mean
> to mandate the internals? Is there an assumption that said internal
> representation is _serialized_ SDP vs some abstract internal
> representation?
>

I suppose this could be restated to say that we can *think* of
SessionDescriptions
as SDP containers, but the internal representation could be
anything, as long as it can roundtrip to SDP. Would that be preferable?

>
> Section 3.1 says that the signaling model is not specified. Is there an
> implicit assumption that, however things are signaled, the signaling
> process
> moves around serialized SDP? Or is it envisioned that one could write an
> application without serialized SDP occurring anywhere above the API?
>

The API does move around session descriptions, and, as mentioned above, they
can be thought of as SDP containers. However, the application signaling
protocol need not involve SDP at all, as mentioned:

     JSEP does not specify a particular signaling model or state
     machine, other than the generic need to exchange session
     descriptions in the fashion described by
      (offer/answer)

IOW, the app signaling model is not specified, but the API interaction
model does involve the use of SDP containers.

>
> -5, throughout: There are a number of normative keywords used in
> constructions
> like "... MUST foo, as described in RFCXXX". That construction is ambiguous
> about whether it defines a normative requirement to do something, and the
> doing
> of that something is described in the RFC, or if describes the referenced
> RFC
> as defining the MUST.


> In general, it's best to avoid using 2119/8174 keywords to talk about
> external
> requirements, except as a direct quote. I think this is especially true
> here
> given the interdependencies between drafts in cluster 238. If in the
> future we
> update a dependency to change a normative requirement, we risk creating
> conflicts, and we make it unclear which text is authoritative.
>

Generally, this is pointing the reader at a particular normative section,
   and saying that yeah, you MUST follow that section as written. Perhaps
   the use of 2119 language here isn't ideal, but I don't see this as
   confusing. Do you have a suggestion about how this should be handled
instead?

>
> -5.1.1: I think the operative requirement is "MUST support" rather than
> "MUST
> indicate support". (While indication may also be required, it seems a
> consequence of "MUST support".)
>

Session descriptions can't really support these specs, but they can
       indicate support by including the appropriate lines. I tend to think
       this is correct as written.

>
> -5.1.2: " Any profile in the offer matching one of the following MUST be
> accepted:" Isn't the real requirement that any of the following must be
> interpreted the same, or otherwise in some specified way? I assume there
> may be
> completely unrelated reasons to reject an m-section, but the "MUST be
> accepted"
> language seems to overrule that.
>

Yes, perhaps we could be clearer and say
       "MUST be considered valid" (in reference to the profile).

>
> -5.4: "The SDP returned from createOffer or createAnswer MUST NOT be
> changed
>    before passing it to setLocalDescription."
> Is that a requirement on the JSEP implementation, or the javascript
> application? If the latter, is it appropriate to put normative
> requirements on
> the application? It seems like it would be better to normatively state the
> JSEP
> implementations's behavior when the application does something incorrect.
> (Which seems to be done further down the page.)
>

This section is, as you mention, application guidance. Perhaps RFC2119
     language doesn't make sense here, but the guidance here seems like a
good
     summary for how the application should behave.

>
> -5.7: " The effect of rollback MUST be the same regardless of whether
> setLocalDescription or setRemoteDescription is called." Does that mean if I
> call setLocalDescription, then rollback with a call to
> setRemoteDescription,
> _both_ are rolled back?
>
> Well, there is only a pending local at this point, and it is rolled back
by setRD.


> -5.8.3: The MUSTs in this section seem to be putting requirements on the
> SDP
> being parsed. Shouldn't they instead describe the parser's behavior based
> on
> that SDP input? The correctness of the SDP being parsed seems beyond the
> control of the implementation.
>

Yes, the correctness of the SDP is beyond the control of the impl, but,
the handling of broken SDP is spelled out in the beginning of this section:

        If any line is not well-formed, or cannot be parsed as
        described, the parser MUST stop with an error and reject the
        session description, even if the value is to be discarded. This
        ensures that implementations do not accidentally misinterpret
        ambiguous SDP.

Saying that a specific line MUST have X and Y is then a shorthand for
repeatedly saying that if the line cannot be parsed properly, the impl MUST
stop with an error.

>
> -8, second paragraph: When describing how the javascript is untrusted, it
> may
> be worth mentioning that it may have been downloaded from an untrusted
> source.
>

yes, we could simply say that it is untrustworthy as a result of being
downloaded from an untrusted source


> Editorial and Nits:
>

Good catches here. Will fix these except for a few exceptions noted below.

>
> -1.1: Please expand ICE and MCU on the first mention.
> s/config/configuration
> Sentence starting with "Through its abstraction of signaling...": Should
> that
> say "Though it abstracts signaling..."
>
> -2: Please consider using the boilerplate from RFC 8174. There are a
> number of
> instances of lowercase versions of normative keywords.
>
> -3.2, paragraph 2: The MUST seems like a statement of fact.
>
> -3.4.1, 2nd paragraph: Please expand or explain "mid" on first mention.
> (It is
> explained 3.5.2.1)
>
> -3.5.1, last paragraph: Inconsistent capitalization: "MID"
>
> -3.5.2.1: Please expand (or define) "ufrag" on first mention.
>
> -3.6.1, first paragraph: is "intersect" the correct verb here? Missing
> conjunction in "hardware decoder capababilities, local policy".
>
> -3.6.2, 2nd paragraph: s/"may be producing"/"may produce"
>

"may be producing" seems OK to me. Did you have a specific concern?

>
> -4.1.2: Please expand LS on first mention. (I can guess from context.
> Please
> don't make me :-)  )
>
> - 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP"
> "for each SDP line, the generation of the SDP will follow the process
> defined
> for generating an initial offer from the document that specifies the given
> SDP
> line." While I worked out what that means, I found "document" to be
> ambiguous.
> At first I interpreted it as the "SDP document" rather than "the RFC".
> (Note
> this occurs several times in subsequent sections.)
>
> -4.1.8, third paragraph: ""pranswer" indicates that a description should be
> parsed as an
>    answer, but not a final answer"
> I think it would be more clear to say "... parsed as a provisional answer,
> rather than a final answer".
>

Parsing has only 2 modes, offers and answers; the provisionality of the
       answer only affects how it is handled once parsed. I think this
should
       stay as-is.

>
> -5.2.1: Paragraph starting with: " Each m= section, provided it is not
> marked
> as bundle-only, MUST generate..." The m= section is not the real actor
> here, is
> it?
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--001a11484c9a0e34010560e49fd3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 11, 2017 at 7:49 PM, Ben Campbell <ben@nostrum.com> wrote:
Ben Campb=
ell has entered the following ballot position for

draft-ietf-rtcweb-jsep-24: Yes



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/<=
wbr>statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-=
ietf-rtcweb-jsep/







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

COMMENT:

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



I'm balloting "yes", but I have some minor comments and nits:=




Substantive:



- General:

I still find the edges around where SDP is and isn't required a bit vag=
ue.

Section 3.3 says that the JSEP implementation internal representation is SD=
P.

While I have trouble imagining implementing this otherwise, do we really me=
an

to mandate the internals? Is there an assumption that said internal

representation is _serialized_ SDP vs some abstract internal representation=
?

I suppose this could be restated to s=
ay that we can *think* of SessionDescriptions
as SDP containers, =
but the internal representation could be
anything, as long as it =
can roundtrip to SDP. Would that be preferable?



Section 3.1 says that the signaling model is not specified. Is there an

implicit assumption that, however things are signaled, the signaling proces=
s

moves around serialized SDP? Or is it envisioned that one could write an
application without serialized SDP occurring anywhere above the API?

The API does move around session descriptions=
, and, as mentioned above, they
can be thought of as SDP containe=
rs. However, the application signaling
protocol need not involve =
SDP at all, as mentioned:

=C2=A0 =C2=A0 =C2=A0JSEP=
 does not specify a particular signaling model or state
=C2=A0 =
=C2=A0 =C2=A0machine, other than the generic need to exchange session
=

=C2=A0 =C2=A0 =C2=A0descriptions in the fashion described by
=C2=A0 =C2=A0 =C2=A0<xref target=3D"RFC3264"></xref>=
 (offer/answer)

IOW, the app signaling model is no=
t specified, but the API interaction
model does involve the use o=
f SDP containers.=C2=A0



-5, throughout: There are a number of normative keywords used in constructi=
ons

like "... MUST foo, as described in RFCXXX". That construction is=
 ambiguous

about whether it defines a normative requirement to do something, and the d=
oing

of that something is described in the RFC, or if describes the referenced R=
FC

as defining the MUST.



In general, it's best to avoid using 2119/8174 keywords to talk about e=
xternal

requirements, except as a direct quote. I think this is especially true her=
e

given the interdependencies between drafts in cluster 238. If in the future=
 we

update a dependency to change a normative requirement, we risk creating

conflicts, and we make it unclear which text is authoritative.

Generally, this is pointing the reader at a particu=
lar normative section,
=C2=A0 =C2=A0and saying that yeah, you MUS=
T follow that section as written. Perhaps
=C2=A0 =C2=A0the use of=
 2119 language here isn't ideal, but I don't see this as
=
=C2=A0 =C2=A0confusing. Do you have a suggestion about how this should be h=
andled instead?=C2=A0



-5.1.2: " Any profile in the offer matching one of the following MUST =
be

accepted:" Isn't the real requirement that any of the following mu=
st be

interpreted the same, or otherwise in some specified way? I assume there ma=
y be

completely unrelated reasons to reject an m-section, but the "MUST be =
accepted"

language seems to overrule that.

Yes, p=
erhaps we could be clearer and say
=C2=A0 =C2=A0 =C2=A0 =C2=A0&qu=
ot;MUST be considered valid" (in reference to the profile).=C2=A0



-5.4: "The SDP returned from createOffer or createAnswer MUST NOT be c=
hanged

=C2=A0 =C2=A0before passing it to setLocalDescription."

Is that a requirement on the JSEP implementation, or the javascript

application? If the latter, is it appropriate to put normative requirements=
 on

the application? It seems like it would be better to normatively state the =
JSEP

implementations's behavior when the application does something incorrec=
t.

(Which seems to be done further down the page.)

This section is, as you mention, application guidance. Perhaps RFC=
2119
=C2=A0 =C2=A0 =C2=A0language doesn't make sense here, bu=
t the guidance here seems like a good
=C2=A0 =C2=A0 =C2=A0summary=
 for how the application should behave.=C2=A0



-5.7: " The effect of rollback MUST be the same regardless of whether<=
br>
setLocalDescription or setRemoteDescription is called." Does that mean=
 if I

call setLocalDescription, then rollback with a call to setRemoteDescription=
,

_both_ are rolled back?


Well, there is only a pending local at this point, an=
d it is rolled back by setRD.
=C2=A0

-5.8.3: The MUSTs in this section seem to be putting requirements on the SD=
P

being parsed. Shouldn't they instead describe the parser's behavior=
 based on

that SDP input? The correctness of the SDP being parsed seems beyond the
control of the implementation.

Yes, the=
 correctness of the SDP is beyond the control of the impl, but,
t=
he handling of broken SDP is spelled out in the beginning of this section:<=
/div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If any line is not wel=
l-formed, or cannot be parsed as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 desc=
ribed, the parser MUST stop with an error and reject the
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 session description, even if the value is to be discar=
ded. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ensures that implementation=
s do not accidentally misinterpret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 am=
biguous SDP.

Saying that a specific line MUST have=
 X and Y is then a shorthand for
repeatedly saying that if the li=
ne cannot be parsed properly, the impl MUST
stop with an error.=
=C2=A0



-8, second paragraph: When describing how the javascript is untrusted, it m=
ay

be worth mentioning that it may have been downloaded from an untrusted sour=
ce.

yes, we could simply say that it is=
 untrustworthy as a result of being
downloaded from an untrusted =
source=C2=A0




Editorial and Nits:

Good catches here. =
Will fix these except for a few exceptions noted below.=C2=A0



-1.1: Please expand ICE and MCU on the first mention.

s/config/configuration

Sentence starting with "Through its abstraction of signaling...":=
 Should that

say "Though it abstracts signaling..."



-2: Please consider using the boilerplate from RFC 8174. There are a number=
 of

instances of lowercase versions of normative keywords.



-3.2, paragraph 2: The MUST seems like a statement of fact.



-3.4.1, 2nd paragraph: Please expand or explain "mid" on first me=
ntion. (It is

explained 3.5.2.1)



-3.5.1, last paragraph: Inconsistent capitalization: "MID"



-3.5.2.1: Please expand (or define) "ufrag" on first mention.



-3.6.1, first paragraph: is "intersect" the correct verb here? Mi=
ssing

conjunction in "hardware decoder capababilities, local policy".


-3.6.2, 2nd paragraph: s/"may be producing"/"may produce&quo=
t;




-4.1.2: Please expand LS on first mention. (I can guess from context. Pleas=
e

don't make me :-)=C2=A0 )



- 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP"

"for each SDP line, the generation of the SDP will follow the process =
defined

for generating an initial offer from the document that specifies the given =
SDP

line." While I worked out what that means, I found "document"=
; to be ambiguous.

At first I interpreted it as the "SDP document" rather than "=
;the RFC". (Note

this occurs several times in subsequent sections.)



-4.1.8, third paragraph: ""pranswer" indicates that a descri=
ption should be

parsed as an

=C2=A0 =C2=A0answer, but not a final answer"

I think it would be more clear to say "... parsed as a provisional ans=
wer,

rather than a final answer".

=C2=A0 =C2=A0 =C2=A0 =C2=A0answer only affects how it is handled once par=
sed. I think this should



-5.2.1: Paragraph starting with: " Each m=3D section, provided it is n=
ot marked

as bundle-only, MUST generate..." The m=3D section is not the real act=
or here, is

it?





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--001a11484c9a0e34010560e49fd3--


From nobody Fri Dec 22 05:24:15 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E412E871; Fri, 22 Dec 2017 05:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAvdYAp20MdY; Fri, 22 Dec 2017 05:24:06 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5E212E86E; Fri, 22 Dec 2017 05:24:06 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id j137so16933132qke.10; Fri, 22 Dec 2017 05:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EviKfF2LyuF3e39+msWPaoHf5SZm855KQK6pDc+NQhA=; b=gd2UFH+ELiYO+9Mh6N14tuLjfnYVgu4FEE4cekE/rDQompykmraft+389iPhyybfFY CtJiP0DzzF3QFFpLCXweQFqpYtmsVBs2QGMvqiNeiOH6KQZndSCR9q/WJUHyhm6Smu+9 +t1TPRg8ddTMKLaZ57yrcCsF0gobL0ZsJ8Pg2+kJ3xTEEpjDq1L/j7oVXfOA1+vjgb0b 1R6ZOPVd0/FnBkX3DVwQxDggJs/Fw/GjITP0GrDmq70BL1ShN4AoNQHe+kzc4VVpXDfR 2x+2wjmoYqedMhTIWAILSxWCUqm544wHaebfD2oeOKQQaK6cufwJ9cUtLNSUxwRHOEu4 010Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EviKfF2LyuF3e39+msWPaoHf5SZm855KQK6pDc+NQhA=; b=k/VoH5nRZoKQY4xPC4FwXcBarf0N30styNxLsza7iiEP/0xTB9zNUMilSv+bmVqJrD r2PVHC0VReW2dUWKMUDLgA1WO3Kg77jWq3mMHBsqU2h5cAEDiEgANFRNviFgzoUwz32L sFKqMwLPZGc25hOlBpCybNq45ZtHH4qWfDu13o9/Gj4wDSYqGQ7dmtEtyGcosofMDcCM OQeL+3yXhkpPC74Xvu1Wt1fH9LmSOT23IkIBdmAH78J3yvMs/5/aneuu7JhATLqd5J+q wuDOr5aaNHXHHf0cZYt42WY+c8B7ne4N955lBQaKwgMlMJarOFzMr7yixeFc4aU9PZaO mhNQ==
X-Gm-Message-State: AKGB3mIQMq7V6dThMwZWmucc1IrG8pFuS9igjut23DNoc+NnxLv59CxD GtwfLi9nHXyKqJ9E7N3qG15g0rUK
X-Google-Smtp-Source: ACJfBotMe0GcJaFrjWU3BGDx6W1GwlxEm04tG4c3qBW4NVyGCgdfPH0sG5r5cYUDgLgP6ix5ZLAWYQ==
X-Received: by 10.233.244.4 with SMTP id y4mr1142712qkl.289.1513949045708; Fri, 22 Dec 2017 05:24:05 -0800 (PST)
Received: from [10.0.1.6] (ool-ad021991.dyn.optonline.net. [173.2.25.145]) by smtp.gmail.com with ESMTPSA id c16sm14254598qtd.80.2017.12.22.05.24.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 05:24:04 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-73EB7ADA-80DA-4A10-982B-DF5E9E12B78E
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty 
X-Mailer: iPhone Mail (15C153)
In-Reply-To: 
Date: Fri, 22 Dec 2017 08:24:03 -0500
Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <151311562760.14100.8542671795905150712.idtracker@ietfa.amsl.com> 
To: Justin Uberti 
Archived-At: 
Subject: Re: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-jsep-24: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Dec 2017 13:24:09 -0000

--Apple-Mail-73EB7ADA-80DA-4A10-982B-DF5E9E12B78E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Thank you!

Sent from my mobile device

> On Dec 21, 2017, at 9:25 PM, Justin Uberti  wrote:
>=20
> Thanks, will fix in -25.
>=20
>> On Tue, Dec 12, 2017 at 1:53 PM, Kathleen Moriarty  wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-rtcweb-jsep-24: No Objection
>>=20
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>=20
>>=20
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html=

>> for more information about IESG DISCUSS and COMMENT positions.
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/
>>=20
>>=20
>>=20
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>=20
>> I'm sure the RFC editor would have caught this nit:
>>=20
>> 2nd paragraph of security considerations section:
>> While formally the JSEP interface is an API, it is better to think of
>>    it is an Internet protocol
>> s/is an Internet/as an Internet/
>>=20
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20

--Apple-Mail-73EB7ADA-80DA-4A10-982B-DF5E9E12B78E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

Thank you!

Sent from my mobile device

On Dec 21, 2017, at 9:25 PM, Justin Uberti <juberti@google.com> wrote:

Thanks, will fix in -25.

On Tue, Dec 12, 2017 at 1:53 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:
Kathleen Moriarty has entered the following ballot position for

draft-ietf-rtcweb-jsep-24: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



I'm sure the RFC editor would have caught this nit:



2nd paragraph of security considerations section:

While formally the JSEP interface is an API, it is better to think of

   it is an Internet protocol

s/is an Internet/as an Internet/





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb






--Apple-Mail-73EB7ADA-80DA-4A10-982B-DF5E9E12B78E--