RTP / RTCP、 TCP、 UDP、 RTMP、 RTSP (2)

เอกสารอ้างอิง RFC2326
โปรโตคอลการสตรีมแบบเรียลไทม์ (Real Time Streaming Protocol) เป็นโปรโตคอลการสตรีมมัลติมีเดียที่ใช้ในการควบคุมเสียงหรือวิดีโอและช่วยให้สามารถควบคุมความต้องการสตรีมมิงพร้อมกันได้หลายรายการ โปรโตคอลการสื่อสารเครือข่ายที่ใช้ระหว่างการส่งไม่อยู่ในช่วงที่กำหนด ฝั่งเซิร์ฟเวอร์คุณสามารถเลือกใช้ TCP หรือ UDP เพื่อส่งเนื้อหาสตรีมมิ่ง ไวยากรณ์และการทำงานคล้ายกับ HTTP 1.1 แต่การซิงโครไนซ์เวลาไม่ได้เน้นเป็นพิเศษดังนั้นจึงสามารถทนต่อความล่าช้าของเครือข่ายได้ การควบคุมความต้องการแบบหลายสตรีมมิ่ง (Multicast) ที่กล่าวถึงก่อนหน้านี้ไม่เพียงลดการใช้งานเครือข่ายทางฝั่งเซิร์ฟเวอร์เท่านั้น แต่ยังรองรับการประชุมทางวิดีโอแบบหลายฝ่าย (Video Conference) อีกด้วย เนื่องจากทำงานคล้ายกับ HTTP1.1 ฟังก์ชันแคช "แคช" ของพร็อกซีเซิร์ฟเวอร์ "พร็อกซี" จึงใช้ได้กับ RTSP เช่นกันและเนื่องจาก RTSP มีฟังก์ชันการเปลี่ยนเส้นทางเซิร์ฟเวอร์ที่ให้บริการจึงสามารถสลับได้ตามโหลดจริง สถานการณ์เพื่อหลีกเลี่ยงการโหลดที่มากเกินไปในเซิร์ฟเวอร์เดียวกันและทำให้เกิดความล่าช้า

　　 ได้รับการเสนอร่วมกันโดย Real Networks และ Netscape โปรโตคอลกำหนดวิธีการที่แอปพลิเคชันแบบหนึ่งต่อหลายสามารถส่งข้อมูลมัลติมีเดียผ่านเครือข่าย IP ได้อย่างมีประสิทธิภาพ RTSP มีเฟรมเวิร์กที่ขยายได้ซึ่งทำให้สามารถควบคุมและข้อมูลเรียลไทม์ตามความต้องการเช่นเสียงและวิดีโอ แหล่งข้อมูลประกอบด้วยข้อมูลสดและข้อมูลที่จัดเก็บในคลิป
วัตถุประสงค์ของโปรโตคอลนี้คือเพื่อควบคุมการเชื่อมต่อการส่งข้อมูลหลายช่องทางเพื่อให้มีวิธีการเลือกช่องทางการส่งเช่น UDP, UDP แบบหลายผู้รับและ TCP และเพื่อจัดเตรียมวิธีการในการเลือกกลไกการส่งตาม RTP

RTP: โปรโตคอลการขนส่งแบบเรียลไทม์

　　RTP / RTCP คือโปรโตคอลการส่งข้อมูลจริง

RTP ส่งข้อมูลเสียง / วิดีโอ หากเป็น PLAY เซิร์ฟเวอร์จะส่งไปยังไคลเอนต์ หากเป็น RECORD ไคลเอ็นต์สามารถส่งไปยังเซิร์ฟเวอร์ได้ โปรโตคอล RTP ทั้งหมดประกอบด้วยสองส่วนที่เกี่ยวข้องกันอย่างใกล้ชิด ได้แก่ โปรโตคอลข้อมูล RTP และโปรโตคอลควบคุม RTP (เช่น RTCP)；

　　 RTCP: RTCP รวมถึงรายงานผู้ส่งและรายงานผู้รับซึ่งใช้สำหรับการซิงโครไนซ์เสียง / วิดีโอและวัตถุประสงค์อื่น ๆ และเป็นโปรโตคอลควบคุม

RTSP: โปรโตคอลการสตรีมแบบเรียลไทม์ (RTSP)

　　คำขอ RTSP ส่วนใหญ่ ได้แก่ DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, OPTIONS ฯลฯ ตามที่ชื่อมีความหมายสามารถเรียกได้ว่าเป็นบทสนทนาและฟังก์ชั่นการควบคุม

　　 ในระหว่างการสนทนา RTSP การตั้งค่าสามารถกำหนดพอร์ตที่ใช้โดย RTP / RTCP, PLAY / PAUSE / TEARDOWN สามารถเริ่มหรือหยุดการส่ง RTP ฯลฯ

　　 TCP ชื่อเต็มคือ โปรโตคอลควบคุมการถ่ายโอนและชื่อภาษาจีนคือ Transmission Control Protocol มันทำงานบนเลเยอร์การขนส่ง OSI และให้บริการการส่งสัญญาณที่เชื่อถือได้ที่เน้นการเชื่อมต่อ

　　 งานของ TCP ส่วนใหญ่เป็นการสร้างการเชื่อมต่อจากนั้นรับข้อมูลจากโปรแกรมเลเยอร์แอปพลิเคชันและส่ง TCP ใช้การเชื่อมต่อวงจรเสมือนในการทำงาน ก่อนที่จะส่งข้อมูลจำเป็นต้องสร้างการเชื่อมต่อระหว่างผู้ส่งและผู้รับ หลังจากส่งข้อมูลแล้วผู้ส่งจะรอให้ผู้รับตอบกลับเพื่อยืนยันมิฉะนั้นผู้ส่งจะคิดว่าข้อมูลนี้สูญหายและส่งข้อมูลนี้อีกครั้ง

RTP ไม่เหมือนกับ http และ ftp ที่สามารถดาวน์โหลดไฟล์ภาพยนตร์ทั้งหมดได้อย่างสมบูรณ์ ส่งข้อมูลบนเครือข่ายด้วยอัตราข้อมูลคงที่ ไคลเอนต์ยังดูไฟล์ภาพยนตร์ด้วยความเร็วนี้ หลังจากเล่นหน้าจอภาพยนตร์แล้วจะไม่สามารถเล่นซ้ำได้ เว้นแต่คุณจะร้องขอข้อมูลจากเซิร์ฟเวอร์อีกครั้ง

　　 ความแตกต่างที่ใหญ่ที่สุดระหว่าง RTSP และ RTP คือ RTSP เป็นโปรโตคอลการส่งข้อมูลแบบเรียลไทม์สองทางซึ่งช่วยให้ไคลเอนต์สามารถส่งคำขอไปยังเซิร์ฟเวอร์เช่นการเล่นการกรอไปข้างหน้าและการดำเนินการย้อนกลับ

　　 แน่นอนว่า RTSP สามารถส่งข้อมูลตาม RTP และยังสามารถเลือก TCP, UDP, UDP แบบหลายผู้รับและช่องทางอื่น ๆ เพื่อส่งข้อมูลซึ่งมีความสามารถในการปรับขนาดได้ดี
เป็นโปรโตคอลเลเยอร์แอปพลิเคชันเครือข่ายคล้ายกับโปรโตคอล http

พอร์ตต้นทาง: ระบุพอร์ตของผู้ส่ง

พอร์ตปลายทาง: ระบุหมายเลขพอร์ตของจุดสิ้นสุดการรับ

หมายเลขลำดับ: ระบุตำแหน่งของเซ็กเมนต์ในลำดับของเซ็กเมนต์ที่จะส่ง

หมายเลขยืนยัน: ระบุหมายเลขลำดับของส่วนที่ได้รับสำเร็จหมายเลขลำดับการยืนยันประกอบด้วยหมายเลขลำดับถัดไปที่ผู้ส่งการยืนยันคาดว่าจะได้รับ

TCP offset: ระบุความยาวของส่วนหัวเซ็กเมนต์ ความยาวของส่วนหัวขึ้นอยู่กับตัวเลือกที่ตั้งไว้ในฟิลด์ตัวเลือกส่วนหัวของส่วน

สงวนไว้: ฟิลด์ที่สงวนไว้ถูกกำหนดไว้สำหรับการใช้งานในอนาคต

PSH: ระบุว่าข้อมูลจะถูกส่งไปยังกระบวนการรับโดยเร็วที่สุด

RST: ระบุการเชื่อมต่อที่รีเซ็ต

FIN: ระบุว่าผู้ส่งทำการส่งข้อมูลเสร็จสิ้น

หน้าต่าง: ระบุคำสั่งเกี่ยวกับขนาดของเซ็กเมนต์ถัดไปที่ผู้ส่งสามารถส่งได้

Checksum: การตรวจสอบประกอบด้วยส่วนหัวของส่วน TCP และส่วนข้อมูลที่ใช้ในการตรวจสอบความน่าเชื่อถือของส่วนหัวของส่วนและส่วนข้อมูล

ฉุกเฉิน: ระบุว่าส่วนนั้นมีข้อมูลฉุกเฉินและตัวชี้เหตุฉุกเฉินจะใช้ได้ก็ต่อเมื่อตั้งค่าสถานะ URG เป็น 1

ตัวเลือก: มีการระบุขนาดเซ็กเมนต์การประทับเวลาจุดสิ้นสุดของฟิลด์อ็อพชันที่รู้จักและระบุตัวเลือกขอบเขตของฟิลด์อ็อพชัน

การสร้างการเชื่อมต่อ TCP: กระบวนการสร้างการเชื่อมต่อ TCP เรียกอีกอย่างว่า TCP three-way handshake ขั้นแรกโฮสต์ผู้ส่งจะเริ่มการร้องขอการซิงโครไนซ์ (SYN) เพื่อสร้างการเชื่อมต่อกับโฮสต์เครื่องรับ โฮสต์ผู้รับตอบกลับด้วยการตอบสนองการซิงโครไนซ์ / รับทราบ (SYN / ACK) ไปยังโฮสต์ผู้ส่งหลังจากได้รับคำขอนี้ โฮสต์ผู้ส่งได้รับสิ่งนี้หลังจากที่ส่งแพ็กเก็ตการตอบรับ (ACK) ไปยังโฮสต์ผู้รับแล้วในขณะนี้การเชื่อมต่อ TCP ถูกสร้างขึ้นสำเร็จแล้ว

การปิดการเชื่อมต่อ TCP: หลังจากโฮสต์ผู้ส่งและโฮสต์ปลายทางสร้างการเชื่อมต่อ TCP และทำการส่งข้อมูลเสร็จสิ้นแพ็กเก็ตข้อมูลที่ตั้งค่าแฟล็กสิ้นสุดเป็น 1 จะถูกส่งไปปิดการเชื่อมต่อ TCP และปล่อยพื้นที่บัฟเฟอร์ที่มีการเชื่อมต่อที่ ในเวลาเดียวกัน การตั้งค่าการรีเซ็ต TCP: TCP อนุญาตให้การเชื่อมต่อถูกขัดจังหวะอย่างกะทันหันระหว่างการส่งซึ่งเรียกว่าการรีเซ็ต TCP

การเรียงลำดับและการยืนยันข้อมูล TCP: TCP เป็นโปรโตคอลการส่งข้อมูลที่เชื่อถือได้ ใช้หมายเลขลำดับและหมายเลขยืนยันเพื่อติดตามการรับข้อมูลระหว่างการส่ง

TCP retransmission: ในกระบวนการส่ง TCP หากโฮสต์ผู้รับไม่ได้รับการตอบกลับการตอบรับไปยังแพ็กเก็ตข้อมูลภายในระยะหมดเวลาการส่งข้อมูลซ้ำโฮสต์ผู้ส่งจะพิจารณาว่าแพ็กเก็ตข้อมูลสูญหายและส่งแพ็กเก็ตข้อมูลไปยังผู้รับอีกครั้งด้านนี้ เรียกว่า TCP retransmission;

การยืนยันการหน่วงเวลา TCP: TCP ไม่ได้ยืนยัน d . เสมอไปทันทีหลังจากได้รับ อนุญาตให้โฮสต์ส่งข้อความยืนยันของตนเองไปยังอีกฝ่ายหนึ่งขณะรับข้อมูล

การป้องกันข้อมูล TCP (การตรวจสอบ): TCP เป็นโปรโตคอลการส่งข้อมูลที่เชื่อถือได้ซึ่งให้การคำนวณการตรวจสอบเพื่อให้ทราบถึงความสมบูรณ์ของข้อมูลระหว่างการส่ง

　　 โปรโตคอล UDP เป็นคำย่อของ UserDatagramProtocol ภาษาอังกฤษนั่นคือโพรโทคอลดาต้าแกรมผู้ใช้ซึ่งส่วนใหญ่ใช้เพื่อสนับสนุนแอปพลิเคชันเครือข่ายที่ต้องการส่งข้อมูลระหว่างคอมพิวเตอร์ แอปพลิเคชันเครือข่ายไคลเอนต์ / เซิร์ฟเวอร์จำนวนมากรวมถึงระบบการประชุมทางวิดีโอบนเครือข่ายจำเป็นต้องใช้โปรโตคอล UDP โปรโตคอล UDP ถูกนำมาใช้เป็นเวลาหลายปีตั้งแต่เริ่มต้น แม้ว่าความสามารถขั้นต้นของมันจะถูกบดบังด้วยโปรโตคอลที่คล้ายกันบางอย่าง แต่ในปัจจุบัน UDP ก็ยังคงเป็นโปรโตคอลเลเยอร์การขนส่งเครือข่ายที่ใช้งานได้จริงและเป็นไปได้

　　 เช่นเดียวกับโปรโตคอล TCP (Transmission Control Protocol) ที่รู้จักกันดีโปรโตคอล UDP จะอยู่ที่ด้านบนของโปรโตคอล IP (Internet Protocol) ตามโมเดลอ้างอิง OSI (Open System Interconnection) UDP และ TCP ต่างก็เป็นโปรโตคอลเลเยอร์การขนส่ง

　　 หน้าที่หลักของโปรโตคอล UDP คือการบีบอัดทราฟฟิกข้อมูลเครือข่ายให้อยู่ในรูปของดาต้าแกรม ดาตาแกรมทั่วไปคือหน่วยการส่งข้อมูลไบนารี 8 ไบต์แรกของแต่ละดาต้าแกรมถูกใช้เพื่อเก็บข้อมูลส่วนหัวและไบต์ที่เหลือจะใช้เพื่อเก็บข้อมูลการส่งเฉพาะ

7. RTP/RTCP, RTMP, TCP, การเปรียบเทียบโปรโตคอล UDP

　　 TCP เป็นโปรโตคอลแบบจุดต่อจุดซึ่งหมายความว่าไคลเอนต์แต่ละรายจำเป็นต้องแยกการเชื่อมโยงไคลเอนต์ / เซิร์ฟเวอร์ดังนั้นการกระจายข้อมูลไปยังไคลเอนต์หลายตัวจึงไม่สามารถรับรู้ได้ในระดับเครือข่าย หากสตรีมข้อมูลต้องถูกส่งไปยังไคลเอนต์หลายตัวในเวลาเดียวกันเซิร์ฟเวอร์จะต้องส่งสำเนาของสตรีมข้อมูลไปยังไคลเอนต์แต่ละราย TCP สามารถปรับความเร็วในการรับส่งข้อมูลแบบไดนามิกตามแบนด์วิดท์เครือข่ายและระดับความแออัดและส่งแพ็กเก็ตข้อมูลที่สูญหายอีกครั้ง มั่นใจในความน่าเชื่อถือของการส่งข้อมูล แต่ทรัพยากรเซิร์ฟเวอร์มีราคาแพงและเป็นการยากที่จะรับประกันประสิทธิภาพการส่งสตรีมข้อมูลแบบเรียลไทม์เมื่อสตรีมข้อมูลมีขนาดใหญ่

UDP เป็นโปรโตคอลการส่งข้อมูลที่ไม่น่าเชื่อถือ เมื่อสิ้นสุดการส่งความเร็วที่ UDP ส่งข้อมูลจะถูก จำกัด ด้วยความเร็วที่แอปพลิเคชันสร้างข้อมูลความจุของคอมพิวเตอร์และแบนด์วิธในการรับส่งข้อมูล ในตอนท้ายของการรับ UDP จะทำให้แต่ละส่วนของข้อความอยู่ในคิว แอปพลิเคชันอ่านส่วนข้อความจากคิวในแต่ละครั้ง โปรโตคอล UDP ไม่จำเป็นต้องรักษาสถานะการเชื่อมต่อและไม่คิดว่าทุกแพ็กเก็ตข้อมูลจะต้องถึงจุดสิ้นสุดการรับดังนั้นโหลดเครือข่ายจึงมีขนาดเล็กกว่า TCP และความเร็วในการรับส่งข้อมูลเร็วกว่า TCP ยิ่งเครือข่ายมีความแออัดมากเท่าใดแพ็กเก็ตข้อมูลก็จะสูญหายไปมากขึ้นเท่านั้น

　　 ความแตกต่างหลักระหว่างโปรโตคอล UDP และ TCP คือวิธีการส่งข้อมูลที่เชื่อถือได้ โปรโตคอล TCP ประกอบด้วยกลไกการรับประกันการส่งมอบพิเศษ เมื่อผู้รับข้อมูลได้รับข้อมูลจากผู้ส่งข้อมูลจะส่งข้อความยืนยันไปยังผู้ส่งโดยอัตโนมัติ ผู้ส่งจะส่งข้อมูลอื่นต่อไปหลังจากได้รับข้อความยืนยันเท่านั้น มิฉะนั้นจะรอจนกว่าจะได้รับข้อความยืนยัน

　　 ดังนั้น TCP จึงมีเวลาในการสร้างการเชื่อมต่อมากกว่า UDP เมื่อเทียบกับ UDP แล้ว TCP มีความปลอดภัยและความน่าเชื่อถือสูงกว่า ขนาดของการส่งโปรโตคอล TCP ไม่ จำกัด เมื่อสร้างการเชื่อมต่อแล้วทั้งสองฝ่ายสามารถส่งข้อมูลจำนวนมากในรูปแบบหนึ่งได้ในขณะที่ UDP เป็นโปรโตคอลที่ไม่น่าเชื่อถือโดยมีขีด จำกัด ขนาดซึ่งแต่ละครั้งต้องไม่เกิน 64K

　　 เมื่อเปรียบเทียบกับโปรโตคอล TCP ข้อแตกต่างอีกประการหนึ่งของโปรโตคอล UDP คือวิธีการรับดาต้าแกรมหลายรายการที่ไม่คาดคิด ซึ่งแตกต่างจาก TCP ตรงที่ UDP ไม่รับประกันลำดับการส่งและรับข้อมูล

RTP อยู่เหนือ UDP แม้ว่า UDP จะไม่น่าเชื่อถือเท่า TCP และไม่สามารถรับประกันคุณภาพของบริการได้ของบริการแบบเรียลไทม์ RTCP จำเป็นต้องตรวจสอบการรับส่งข้อมูลและคุณภาพการบริการแบบเรียลไทม์ อย่างไรก็ตาม เนื่องจากความล่าช้าในการส่งข้อมูลของ UDP นั้นต่ำกว่า TCP จึงสามารถใช้งานร่วมกับวิดีโอและเสียงได้เป็นอย่างดี เข้ากันดี. ดังนั้น ในการใช้งานจริง RTP/RTCP/UDP จะใช้สำหรับสื่อเสียง/วิดีโอ และใช้ TCP สำหรับการส่งข้อมูลและการส่งสัญญาณควบคุม

โปรโตคอล RTMP เป็นโปรโตคอลที่ออกแบบมาโดยเฉพาะสำหรับการส่งวิดีโอเสียงและข้อมูลอย่างมีประสิทธิภาพ รับรู้การส่งวิดีโอและเสียงแบบเรียลไทม์โดยการสร้างการเชื่อมต่อ TCP แบบไบนารีหรือเชื่อมต่ออุโมงค์ HTTP

　　RTMP รองรับโปรโตคอลสื่อมากกว่าเซิร์ฟเวอร์สื่อแบบเดิม สนับสนุนการส่งข้อมูลแบบไดนามิกของหลายบรรทัดที่อาจมีข้อมูลเสียงวิดีโอและสคริปต์จากเซิร์ฟเวอร์ไปยังไคลเอนต์และจากไคลเอนต์ไปยังเซิร์ฟเวอร์ RTMP ประมวลผลข้อมูลเสียงวิดีโอและสคริปต์แยกกัน

　　ข้อมูลเสียงและวิดีโอจะถูกบัฟเฟอร์แยกกันในเซิร์ฟเวอร์ หากข้อมูลเสียงถึงขีด จำกัด ที่กำหนดในบัฟเฟอร์เสียงข้อมูลทั้งหมดในบัฟเฟอร์จะถูกทิ้งและข้อมูลที่มาถึงล่าสุดจะได้รับอนุญาตให้เริ่มรวบรวมในบัฟเฟอร์และส่งไปยังไคลเอนต์แต่ละราย ข้อมูลวิดีโอได้รับการประมวลผลในลักษณะเดียวกันความแตกต่างคือเมื่อมีคีย์เฟรมใหม่เข้ามาข้อมูลในบัฟเฟอร์จะถูกล้าง เมื่อทิ้งข้อมูลเฟรมเก่าหากพบว่าข้อมูลของไคลเอนต์ไม่ถูกต้องให้ใส่เฟรมใหม่และเก่า

　　RTMP ให้ระดับความสำคัญของข้อมูลที่แตกต่างกัน ในการสนทนาแบบเรียลไทม์เสียงเป็นสิ่งสำคัญที่สุดวิดีโอมีลำดับความสำคัญต่ำและข้อมูลสคริปต์จะให้ความสำคัญระหว่างเสียงและวิดีโอ

　　 โปรโตคอล RTMP สามารถสร้างสตรีมข้อมูลได้หลายสตรีม แต่สตรีมข้อมูลแต่ละสตรีมสามารถมีทิศทางเดียวเท่านั้น การใช้ RTMP สามารถสร้างระบบดังกล่าวไคลเอนต์สามารถโต้ตอบกับเซิร์ฟเวอร์ RTMP และแอ็พพลิเคชันเซิร์ฟเวอร์ในเวลาเดียวกันเพื่อให้โหลดบนเซิร์ฟเวอร์สามารถกระจายได้แม้ว่าในโครงสร้างระบบที่ปรับปรุงนี้ข้อกำหนดด้านประสิทธิภาพของเซิร์ฟเวอร์ RTMP ค่อนข้างสูง

　　 โปรโตคอล HTTP ชื่อเต็มคือ HyperText Transfer Protocol และชื่อภาษาจีนคือ HyperText Transfer Protocol;

　　โปรโตคอล MMS ชื่อเต็มคือ Microsoft Media Server Protocol และชื่อภาษาจีนคือ Microsoft Media Server Protocol

　　 โปรโตคอล HLS ชื่อเต็ม HTTP Live Streaming คือโปรโตคอลการส่งผ่านสื่อแบบสตรีมมิ่งที่ใช้ HTTP ที่ Apple Inc. ใช้;

ไกลเท่าไหร่ (ยาว) ฝาครอบเครื่องส่งสัญญาณหรือไม่

ช่วงส่งขึ้นอยู่กับปัจจัยหลายอย่าง ระยะทางจริงจะขึ้นอยู่กับการติดตั้งเสาอากาศสูงที่ได้รับเสาอากาศโดยใช้สภาพแวดล้อมเช่นอาคารและสิ่งกีดขวางอื่น ๆ , ความไวของตัวรับสัญญาณ, เสาอากาศของเครื่องรับ การติดตั้งเสาอากาศสูงมากขึ้นและใช้ในชนบทระยะทางจะไกลมากขึ้น

ตัวอย่าง 5W FM Transmitter ใช้ในเมืองและบ้านเกิด:

ฉันมีการใช้งานของลูกค้า 5W ส่งสัญญาณ FM ประเทศสหรัฐอเมริกาที่มีเสาอากาศ GP ในบ้านเกิดของเขาและเขาทดสอบกับรถมันครอบคลุม 10km (6.21mile)

ผมทดสอบการส่งสัญญาณ FM 5W กับเสาอากาศ GP ในบ้านเกิดของฉันมันครอบคลุมเกี่ยวกับ 2km (1.24mile)

ผมทดสอบการส่งสัญญาณ FM 5W กับเสาอากาศ GP ในเมืองกวางโจวมันครอบคลุมเกี่ยวกับเพียง 300meter (984ft)

ด้านล่างนี้เป็นช่วงโดยประมาณของเครื่องส่งสัญญาณ FM อำนาจที่แตกต่างกัน (ช่วงมีเส้นผ่าศูนย์กลาง)

0.1W ~ 5W FM Transmitter: 100M ~ 1KM

5W ~ 15W FM Ttransmitter: 1KM ~ 3KM

15W ~ 80W FM Transmitter: 3KM ~ 10KM

80W ~ 500W FM Transmitter: 10KM ~ 30KM

500W ~ 1000W FM Transmitter: 30KM ~ 50KM

1KW ~ 2KW FM Transmitter: 50KM ~ 100KM

2KW ~ 5KW FM Transmitter: 100KM ~ 150KM

5KW ~ 10KW FM Transmitter: 150KM ~ 200KM

วิธีการติดต่อเราเพื่อส่งสัญญาณหรือไม่

โทรหาฉัน + 8618078869184 หรือ
ส่งอีเมลถึงฉัน [ป้องกันอีเมล]
1.How ไกลคุณต้องการที่จะครอบคลุมในเส้นผ่าศูนย์กลาง?
2.How สูงของหอคุณ?
3.Where คุณมาจาก?
และเราจะให้คำแนะนำมืออาชีพมากขึ้น

เกี่ยวกับเรา

FMUSER.ORG เป็น บริษัท บูรณาการระบบที่เน้นการส่งสัญญาณไร้สาย RF / อุปกรณ์สตูดิโอวิดีโอเสียง / สตรีมมิ่งและการประมวลผลข้อมูลเราให้บริการทุกอย่างตั้งแต่คำแนะนำและคำปรึกษาผ่านการรวมเข้ากับแร็คจนถึงการติดตั้ง

เรานำเสนอเครื่องส่งสัญญาณ FM, เครื่องส่งสัญญาณโทรทัศน์อะนาล็อก, เครื่องส่งสัญญาณโทรทัศน์ดิจิตอล, เครื่องส่งสัญญาณ VHF UHF, เสาอากาศ, ช่องเสียบสายโคแอกเชียล, STL, การประมวลผลทางอากาศ, ผลิตภัณฑ์ออกอากาศสำหรับสตูดิโอ, การตรวจสอบสัญญาณ ผลิตภัณฑ์ IPTV, Video / Audio Encoder / Decoder ออกแบบมาเพื่อตอบสนองความต้องการของทั้งเครือข่ายออกอากาศระหว่างประเทศขนาดใหญ่และสถานีส่วนตัวขนาดเล็กเหมือนกัน

โซลูชันของเรามีสถานีวิทยุ FM / สถานีโทรทัศน์อะนาล็อก / สถานีโทรทัศน์ดิจิตอล / อุปกรณ์สตูดิโอวิดีโอเสียง / ลิงค์เครื่องส่งสัญญาณสตูดิโอ / ระบบส่งสัญญาณโทรมาตร / ระบบโทรทัศน์ของโรงแรม / การแพร่ภาพสด IPTV / สตรีมมิงถ่ายทอดสด / การประชุมทางวิดีโอ / ระบบกระจายเสียง CATV

เราใช้ผลิตภัณฑ์เทคโนโลยีขั้นสูงสำหรับทุกระบบเพราะเรารู้ว่าความน่าเชื่อถือสูงและประสิทธิภาพสูงเป็นสิ่งสำคัญสำหรับระบบและโซลูชั่น ในเวลาเดียวกันเรายังต้องให้แน่ใจว่าระบบผลิตภัณฑ์ของเราในราคาที่สมเหตุสมผล

เรามีลูกค้าของผู้แพร่ภาพกระจายเสียงภาครัฐและเชิงพาณิชย์ผู้ประกอบการด้านการสื่อสารและหน่วยงานกำกับดูแลและเรายังนำเสนอโซลูชั่นและผลิตภัณฑ์ให้กับผู้กระจายสัญญาณขนาดเล็กท้องถิ่นและชุมชนหลายร้อยราย

FMUSER.ORG ส่งออกมานานกว่า 15 ปีและมีลูกค้าทั่วโลก ด้วยประสบการณ์ 13 ปีในด้านนี้เรามีทีมงานมืออาชีพเพื่อแก้ปัญหาทุกประเภทของลูกค้า เราทุ่มเทในการจัดหาผลิตภัณฑ์และบริการระดับมืออาชีพในราคาที่สมเหตุสมผล อีเมลติดต่อ: [ป้องกันอีเมล]

โรงงานของเรา

เรามี สร้างสรรค์สิ่งใหม่ ๆ ของโรงงาน คุณจะยินดีที่จะเข้าเยี่ยมชมโรงงานของเราเมื่อคุณมาถึงประเทศจีน

ในปัจจุบันมีอยู่แล้ว ลูกค้า 1095 ทั่วโลกเข้าเยี่ยมชมสำนักงานกวางเจาของเรา ถ้าคุณมาถึงประเทศจีนคุณจะยินดีที่จะมาเยี่ยมชม

ในงาน

นี่คือการมีส่วนร่วมของเราในแหล่งที่มาทั่วโลก 2012 ฮ่องกง Electronics Fair . ลูกค้าจากทั่วทุกมุมโลก ในที่สุดก็มีโอกาสที่จะได้พบปะกัน

Fmuser อยู่ที่ไหน

คุณสามารถค้นหาหมายเลขนี้ " 23.127460034623816,113.33224654197693 "ใน google map จากนั้นคุณจะพบสำนักงาน fmuser ของเรา

สำนักงาน FMUSER กว่างโจวอยู่ใน Tianhe District ซึ่งเป็น ศูนย์กลางของแคนตัน . มาก ใกล้ ไป แคนตันแฟร์ , กว่างโจวสถานีรถไฟ, ถนน xiaobei และ dashatou จะต้อง 10 นาที ถ้าใช้เวลา TAXI . ยินดีต้อนรับเพื่อน ๆ ทั่วโลกเพื่อเยี่ยมชมและเจรจาต่อรอง

ติดต่อ: บลูสกาย
โทรศัพท์มือถือ: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-mail: [ป้องกันอีเมล]
QQ: 727926717
skype: sky198710021
ที่อยู่: No.305 ห้อง Huilan อาคาร No.273 Huanpu ถนนกว่างโจวประเทศจีนไปรษณีย์: 510620

ภาษาอังกฤษ: เรายอมรับการชำระเงินทั้งหมดเช่น PayPal, Credit Card, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer หากคุณมีคำถามใด ๆ โปรดติดต่อฉัน [ป้องกันอีเมล] หรือ WhatsApp + 8618078869184

PayPal www.paypal.com

เราขอแนะนำให้คุณใช้ PayPal เพื่อซื้อสินค้าของเราที่ PayPal เป็นวิธีการที่ปลอดภัยที่จะซื้อบนอินเทอร์เน็ต

ทุกด้านล่างของหน้าในรายการของเราด้านบนมีโลโก้ PayPal จะจ่าย

บัตรเครดิต.หากคุณไม่ได้มี PayPal แต่คุณมีบัตรเครดิตคุณยังสามารถคลิกที่ปุ่มสีเหลือง PayPal ชำระเงินด้วยบัตรเครดิตของคุณ

-------------------------------------------------- -------------------

แต่ถ้าคุณยังไม่ได้บัตรเครดิตและไม่ได้มีบัญชี PayPal หรือยากที่จะมี Accout PayPal คุณสามารถใช้ต่อไปนี้:

เวสเทิร์นยูเนี่ย

www.westernunion.com

ชำระเงินผ่าน Western Union กับฉัน:

ชื่อ / ชื่อจริง: Yingfeng
นามสกุล / นามสกุล / นามสกุล: จาง
ชื่อเต็ม: Yingfeng Zhang
ประเทศ: China
เมืองกว่างโจว

-------------------------------------------------- -------------------

T / T ชำระเงินด้วย T / T (โอน / โอน / โอนเงินผ่านธนาคาร)

ข้อมูลธนาคารแรก (บัญชีบริษัท):

SWIFT BIC: BKCHHKHHXXX
ชื่อธนาคาร: ธนาคารแห่งประเทศจีน (ฮ่องกง) จำกัด ฮ่องกง
ที่อยู่ธนาคาร: BANK OF CHINA TOWER, 1 GARDEN ROAD, CENTRAL, HONG KONG
รหัสธนาคาร: 012
ชื่อบัญชี: FMUSER INTERNATIONAL GROUP LIMITED
เลขที่บัญชี : 012-676-2-007855-0

-------------------------------------------------- -------------------
ข้อมูลธนาคารที่สอง (บัญชีบริษัท):
ผู้รับผลประโยชน์: Fmuser International Group Inc
หมายเลขบัญชี: 44050158090900000337
ธนาคารผู้รับผลประโยชน์: China Construction Bank สาขากวางตุ้ง
SWIFT Code: PCBCCNBJGDX
ที่อยู่: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, China
**หมายเหตุ: เมื่อคุณโอนเงินเข้าบัญชีธนาคารของเรา โปรดอย่าเขียนอะไรในช่องหมายเหตุ มิฉะนั้น เราจะไม่สามารถรับการชำระเงินได้เนื่องจากนโยบายของรัฐบาลเกี่ยวกับธุรกิจการค้าระหว่างประเทศ

* มันจะถูกส่งไปใน 1 2-วันทำการเมื่อชำระเงินที่ชัดเจน

* เราจะส่งไปยังที่อยู่ของ PayPal หากคุณต้องการเปลี่ยนที่อยู่กรุณาส่งที่อยู่ที่ถูกต้องและหมายเลขโทรศัพท์อีเมลของฉัน [ป้องกันอีเมล]

* ถ้าแพคเกจที่อยู่ด้านล่าง 2kg เราจะถูกส่งผ่านทางไปรษณีย์ทางอากาศก็จะใช้เวลาประมาณ 15-25days ถึงมือของท่าน

ถ้าแพคเกจเป็นมากกว่า 2kg เราจะจัดส่งทาง EMS, DHL, UPS, Fedex ส่งด่วนรวดเร็วก็จะใช้เวลาประมาณ 7 ~ 15days ถึงมือของท่าน

ถ้าแพคเกจมากกว่า 100kg เราจะส่งผ่าน DHL หรือขนส่งสินค้าทางอากาศ จะใช้เวลาประมาณ 3 ~ 7days ถึงมือของท่าน

แพคเกจทั้งหมดที่มีรูปแบบจีนกวางโจว

* แพคเกจจะถูกส่งเป็น "ของขวัญ" และแจ้งให้ทราบน้อยที่สุดเท่าที่จะเป็นไปได้ผู้ซื้อไม่จำเป็นต้องจ่าย "ภาษี"

* หลังจากเรือเราจะส่ง E-mail และให้คุณติดตามตัวเลข

สำหรับการรับประกัน
ติดต่อเรา --- >> ส่งคืนสินค้าให้เรา --- >> รับและส่งเปลี่ยนใหม่

ชื่อ: หลิว Xiaoxia
ที่อยู่: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu กว่างโจวประเทศจีน
ไปรษณีย์: 510620
โทรศัพท์: + 8618078869184

โปรดกลับไปอยู่นี้และเขียนที่อยู่ของ PayPal ชื่อปัญหาของคุณบนหมายเหตุ: