SIP คืออะไร? คู่มือโปรโตคอล SIP ฉบับวิศวกร

แยกชั้นก่อนวิเคราะห์ SIP: กรอบคิดสำหรับการแก้ปัญหา

ตัวอย่างเคสที่พบบ่อยในองค์กร: Extension 1001 ลงทะเบียนสำเร็จ รับสายเข้าได้ ผู้ใช้ได้ยินเสียงปลายทางชัดเจน แต่ฝั่งผู้โทรกลับไม่ได้ยินอะไรเลย สถานะการลงทะเบียนอธิบายอาการนี้ไม่ได้ เพราะ REGISTER ที่สำเร็จพิสูจน์เพียงว่า Signalling ของ SIP ไปถึง Registrar ได้ ไม่ได้บอกว่า RTP ถูกส่งไปที่ไหน Firewall ยอมให้ผ่านหรือไม่ หรือปลายทางถอดรหัสเสียงได้หรือเปล่า

SIP แยกการควบคุม Session ออกจากตัว Media ข้อความ SIP ใช้ตกลงว่าใครคุยกับใครและใช้คำอธิบาย Media แบบใด ส่วน SDP ที่อยู่ใน Body ของข้อความระบุที่อยู่ Port และ Codec จากนั้น RTP จึงส่งเสียงจริงแยกออกไป และบ่อยครั้งใช้เส้นทางเครือข่ายต่างจาก Signalling ปัญหาในชั้นหนึ่งจึงอาจดูเหมือนปัญหาของอีกชั้น หากไม่ตรวจแต่ละชั้นด้วยหลักฐานของชั้นนั้นเอง

แบบจำลองที่ใช้งานได้จริงแบ่งเป็น 4 ชั้น ชั้น Connectivity ครอบคลุม IP Routing การ Resolve DNS, Transport ที่เลือกใช้ (UDP, TCP, TLS หรือ WebSocket) และ State ของ Firewall ชั้น Signalling ครอบคลุม Request, Response, Transaction และ Dialog ชั้น Session Description ครอบคลุม SDP ได้แก่ Connection Address, Media Port, Payload Format และ Direction Attribute ส่วนชั้น Media และ Application ครอบคลุมการส่ง RTP/RTCP, Packet Loss, Jitter, การถอดรหัส และสิ่งที่ผู้ใช้ได้ยินจริง

บันทึกการวิเคราะห์ที่ดีควรเขียนเป็นข้อเท็จจริงรายชั้น ไม่ใช่ข้อสรุป เช่น INVITE ได้รับ 200 OK และปลายทางได้รับ ACK ที่ตรงกันแล้ว SDP Answer เลือก PCMA (Payload 8) ที่ 198.51.100.20:41000 RTP จาก 198.51.100.20 ไปถึง 192.0.2.10 แต่ RTP จาก 192.0.2.10 ไม่ผ่าน Firewall ของสาขาไปถึง 198.51.100.20 บันทึกลักษณะนี้ชี้ไปยังอุปกรณ์ที่ต้องแก้ได้ทันที

บทบาทของโปรโตคอล: SIP, SDP, RTP และ RTCP ในสาย VoIP

คำเหล่านี้มักถูกใช้ปนกันในเอกสารการขาย แต่แต่ละคำหมายถึงคนละชั้น VoIP คือแนวทางการส่งเสียงผ่าน IP โดยรวม SIP (RFC 3261) คือโปรโตคอลควบคุม SDP (RFC 8866) คือรูปแบบข้อความที่ใช้อธิบาย Media และ RTP (RFC 3550) คือโปรโตคอลที่ขนเสียงดิจิทัล ส่วน SIP Trunk คือบริการหรือการเชื่อมต่อที่ใช้ SIP ระหว่างระบบโทรศัพท์ ซึ่งส่วนใหญ่เป็นการเชื่อม PBX ขององค์กรกับผู้ให้บริการที่ต่อออกโครงข่ายโทรศัพท์สาธารณะ

หลักคิดคือ SIP ประสาน Session, SDP อธิบายพารามิเตอร์ของ Media และ RTP ขนเสียง เมื่อเป็นคนละ Flow ข้อความ SIP อาจผ่าน Proxy หนึ่งตัวหรือมากกว่า ขณะที่ RTP วิ่งตรงระหว่าง Endpoint หรือผ่าน Media Relay เช่น SBC ขึ้นอยู่กับการออกแบบ ดังนั้นอย่าสันนิษฐานว่าเส้นทาง Signalling กับเส้นทาง Media เป็นเส้นทางเดียวกัน

องค์ประกอบของระบบ SIP: User Agent, Proxy, Registrar, B2BUA และ SBC

User Agent (UA) คือฟังก์ชันปลายทางเชิงตรรกะ ทำหน้าที่เป็น User Agent Client (UAC) เมื่อส่ง Request และเป็น User Agent Server (UAS) เมื่อรับ Request แล้วสร้าง Response บทบาทนี้กำหนดตาม Transaction ไม่ได้ผูกกับอุปกรณ์ โทรศัพท์ IP เครื่องเดียวเป็น UAC ตอนส่ง INVITE และเป็น UAS ตอนได้รับ BYE จากอีกฝั่งในภายหลัง

Proxy Server รับ Request แล้วส่งต่อไปยังเป้าหมาย โดยตัดสินเส้นทางจาก Request-URI นโยบาย และ DNS Proxy ไม่ได้เป็นผู้เริ่มหรือผู้รับสายเอง Proxy แบบ Stateful เก็บ State ของ Transaction และสามารถ Fork Request ไปหลาย Contact พร้อมกันได้ รวมถึงใส่ Header Record-Route เพื่อให้ Request ถัดไปใน Dialog ยังคงผ่าน Proxy ตัวนั้น

Registrar รับ Request ประเภท REGISTER แล้วเก็บ Binding ระหว่าง Address of Record (AoR) กับ Contact Address หนึ่งรายการหรือมากกว่าไว้ใน Location Service จากนั้น Proxy จะค้นหาจาก Location Service ว่าผู้ใช้ติดต่อได้ที่ใดในขณะนั้น ในผลิตภัณฑ์จำนวนมาก Registrar, Location Service และ Proxy รวมอยู่ใน Server เดียว แต่ใน RFC 3261 ถือเป็นบทบาทเชิงตรรกะที่แยกกัน

Back-to-Back User Agent (B2BUA) รับสายด้านหนึ่งในฐานะ UAS แล้วเริ่มสายใหม่อีกด้านในฐานะ UAC แต่ละด้านเป็น Dialog อิสระที่มี Call-ID, Tag และลำดับ CSeq ของตัวเอง IP-PBX และ Session Border Controller (SBC) มักทำงานแบบ B2BUA จึงซ่อนโครงสร้างเครือข่ายภายใน ปรับ Header ให้เข้ากันระหว่างผู้ผลิต บังคับใช้นโยบายการรับสายและป้องกันการฉ้อโกง และยึด (Anchor) หรือแปลง Codec ของ Media ได้เมื่อการออกแบบต้องการ

บทบาทที่ห้าคือ Redirect Server ซึ่งไม่ส่ง Request ต่อ แต่ตอบกลับด้วย Response กลุ่ม 3xx ที่ระบุ Contact ทางเลือกให้ผู้ส่งติดต่อเอง

Transport, การระบุที่อยู่ และการค้นหา Next Hop ด้วย DNS (RFC 3263)

SIP ทำงานได้บน UDP, TCP, TLS บน TCP, SCTP และ WebSocket (RFC 7118 สำหรับ Client บน Browser) Port มาตรฐานของ URI แบบ sip บน UDP หรือ TCP คือ 5060 และสำหรับ TLS คือ 5061 ค่าเหล่านี้ใช้เฉพาะเมื่อไม่ได้ระบุ Port ไว้ชัดเจน ระบบจริงจะใช้ Port อื่นก็ได้

Transport ที่เลือกมีผลกับ Signalling เท่านั้น การใช้ SIP บน TCP หรือ TLS ไม่ได้ย้าย RTP ไปใช้ TCP ด้วย Media ยังใช้ Transport ตามที่ SDP ระบุ ซึ่งสำหรับ RTP/AVP และ RTP/SAVP คือ UDP เช่นเดียวกับ Client แบบ WebRTC ที่ส่ง SIP ผ่าน Secure WebSocket ก็ยังส่ง Media ผ่าน Flow แบบ DTLS-SRTP แยกต่างหาก ไม่ได้ส่งอยู่ภายใน WebSocket

UDP อ่อนไหวต่อขนาดข้อความ RFC 3261 กำหนดให้ Client ต้องใช้ Transport ที่มี Congestion Control เช่น TCP เมื่อ Request มีขนาดใกล้ Path MTU ไม่เกิน 200 Byte หรือใหญ่กว่า 1300 Byte ในกรณีที่ไม่ทราบ MTU ข้อความ INVITE ที่มี SDP ยาวจึงเป็นสาเหตุที่พบได้จริงของปัญหา IP Fragmentation บน UDP

โครงสร้างข้อความ SIP และ Header ที่สำคัญ

SIP เป็นโปรโตคอลแบบข้อความที่มีไวยากรณ์คล้าย HTTP ทุกข้อความประกอบด้วย Start-line ชุด Header บรรทัดว่างที่บอกจุดสิ้นสุดของ Header และ Body ที่มีหรือไม่มีก็ได้ Request เริ่มด้วย Request-Line (Method, Request-URI และเวอร์ชัน SIP) ส่วน Response เริ่มด้วย Status-Line (เวอร์ชัน SIP, Status Code สามหลัก และ Reason Phrase) ทุกบรรทัดจบด้วย CRLF ชื่อ Header ไม่สนตัวพิมพ์เล็กใหญ่ และมีรูปย่อ เช่น v แทน Via และ i แทน Call-ID

RFC 3261 หัวข้อ 8.1.1 ระบุ Header ที่ทุก Request ต้องมี ได้แก่ To, From, CSeq, Call-ID, Max-Forwards และ Via ส่วน Contact ต้องมีเพิ่มใน Request ที่สร้าง Dialog ได้ เช่น INVITE และใน REGISTER จะใช้ Contact ระบุ Binding ที่ต้องการเพิ่มหรือลบ

ต้องแยก Request-URI ออกจาก Header To ให้ชัด Proxy จะเปลี่ยนเป้าหมายใน Request-URI ระหว่างที่ Request เดินทางไปยังอุปกรณ์ที่จะรับสาย ขณะที่ To ยังเก็บเป้าหมายเชิงตรรกะตามที่ผู้โทรขอไว้แต่แรก ที่อยู่ของ Media ไม่เคยอยู่ใน Header เหล่านี้ แต่อยู่ในบรรทัด c= และ m= ของ SDP Body

Method และ Response Code ของ SIP

RFC 3261 กำหนด Method หลักไว้ 6 ตัว INVITE ใช้เริ่ม Session หรือแก้ไข Session เดิมเมื่อส่งภายใน Dialog ในรูปแบบ re-INVITE ส่วน ACK ใช้ยืนยัน Final Response ของ INVITE, BYE ใช้ยุติ Session, CANCEL ขอให้ Server หยุดประมวลผล Request ที่ยังค้างอยู่ ซึ่งในทางปฏิบัติคือ INVITE ที่ยังไม่มีคนรับ, REGISTER ใช้เพิ่ม ต่ออายุ หรือลบ Contact Binding และ OPTIONS ใช้สอบถามความสามารถ ซึ่งนิยมใช้เป็น Keepalive หรือ Health Probe ระหว่าง PBX, SBC และผู้ให้บริการ

Extension เพิ่ม Method อื่นอีก ได้แก่ PRACK สำหรับยืนยัน Provisional Response แบบ Reliable (RFC 3262), UPDATE สำหรับเปลี่ยนพารามิเตอร์ Session ได้ทั้งก่อนและหลังรับสายโดยไม่กระทบ State ของ Dialog (RFC 3311), REFER สำหรับขอให้ผู้รับติดต่อบุคคลที่สาม ซึ่งเป็นพื้นฐานของการโอนสาย (RFC 3515), INFO สำหรับส่งข้อมูลระดับแอปพลิเคชันภายใน Dialog (RFC 6086), SUBSCRIBE และ NOTIFY สำหรับแจ้งเหตุการณ์ (RFC 6665) และ MESSAGE สำหรับข้อความแบบทันที (RFC 3428)

Response แบ่งกลุ่มตามหลักแรก 1xx คือ Provisional, 2xx คือสำเร็จ, 3xx คือ Redirect, 4xx คือ Request ล้มเหลว, 5xx คือ Server ล้มเหลว และ 6xx คือล้มเหลวทุกปลายทาง ต้องอ่าน Response คู่กับ Method ใน Header CSeq เสมอ เช่น 200 OK ของ BYE หมายถึงการวางสายได้รับการยอมรับ ไม่ได้หมายความว่ามีคนรับสาย

Transaction, Dialog และ Session

วิศวกรใช้คำที่เกี่ยวข้องกัน 5 คำ Message คือ Request หรือ Response หนึ่งฉบับ Transaction คือ Request หนึ่งฉบับพร้อม Response ทั้งหมดของมันรวมถึงการส่งซ้ำ ทั้ง Client และ Server ระบุ Transaction ด้วยพารามิเตอร์ branch ของ Via บนสุด ซึ่งตาม RFC 3261 จะขึ้นต้นด้วย Magic Cookie z9hG4bK เสมอ ร่วมกับชื่อ Method ส่วน Dialog คือความสัมพันธ์แบบ Peer-to-Peer ระหว่าง User Agent สองฝั่งที่คงอยู่ช่วงเวลาหนึ่ง สร้างโดย INVITE หรือ SUBSCRIBE และระบุด้วย Call-ID, Local Tag และ Remote Tag

Session คือการแลกเปลี่ยน Media ตามที่ SDP อธิบาย และ Call Leg เป็นคำเรียกทั่วไปของ Dialog หนึ่งตัว เมื่อ B2BUA หรือ SBC แบ่งสายปลายถึงปลายออกเป็นหลาย Dialog

เมื่อ UAS ส่ง Provisional Response ที่ไม่ใช่ 100 Trying พร้อม To Tag จะเกิด Early Dialog และเมื่อได้รับ Final Response กลุ่ม 2xx Dialog จะกลายเป็น Confirmed Request ถัดมาใน Dialog เช่น re-INVITE, UPDATE หรือ BYE ใช้ Call-ID และ Tag เดิม แต่แต่ละฉบับเป็น Transaction ใหม่ที่มี branch ใหม่ และมีเลข CSeq สูงขึ้นตามฝั่งผู้ส่ง แต่ละฝั่งมีลำดับ CSeq ของตัวเอง เลขใน BYE ที่ส่งจากฝั่งผู้รับสายจึงไม่จำเป็นต้องต่อจากเลขของผู้โทร

การ Fork ทำให้ซับซ้อนขึ้น เมื่อ Proxy ส่ง INVITE ไปหลายเครื่องพร้อมกัน เครื่องที่ตอบด้วย To Tag ของตัวเองจะสร้าง Early Dialog แยกกันโดยใช้ Call-ID เดียวกัน Proxy อาจ CANCEL Branch ที่ยังไม่รับสายเมื่อได้รับ 2xx แรก แต่หากหลาย Branch ส่ง 2xx ก่อนการยกเลิกจะสำเร็จ จะเกิด Confirmed Dialog หลายตัว UAC ต้องส่ง ACK ให้แต่ละ 2xx และส่ง BYE ใน Dialog ที่ไม่ต้องการ

การลงทะเบียน (REGISTER) และการยืนยันตัวตนแบบ Digest

REGISTER ใช้สร้าง ต่ออายุ หรือลบ Contact Binding ของ Address of Record อายุที่ขอระบุได้ทั้งในพารามิเตอร์ expires ของ Contact หรือใน Header Expires และ Registrar จะแจ้งอายุที่อนุญาตจริงกลับมาใน 200 OK ซึ่งอาจสั้นกว่าที่ขอ Client ต้องต่ออายุก่อนหมดเวลาที่ได้รับ และ REGISTER ที่ระบุอายุเป็นศูนย์คือการลบ Binding

การลงทะเบียนกับการยืนยันตัวตนเป็นคนละเรื่อง การลงทะเบียนตอบคำถามว่าตอนนี้ติดต่อผู้ใช้ได้ที่ไหน ส่วนการยืนยันตัวตนตอบว่าผู้ส่งพิสูจน์ตัวตนได้หรือไม่ Binding ที่หมดอายุทำให้สายเรียกเข้าใหม่ไม่ถูกส่งไปยัง Contact นั้น แต่ไม่ได้ตัด Dialog ที่สร้างไว้แล้ว

การถูก Challenge ใน Request แรกเป็นเรื่องปกติ Registrar ที่ต้องการข้อมูลยืนยันตัวตนจะตอบ REGISTER ฉบับแรกด้วย 401 Unauthorized พร้อม Header WWW-Authenticate จากนั้น Client จะส่ง REGISTER ฉบับใหม่ที่มี Header Authorization

ลำดับการลงทะเบียนเมื่อถูก Challenge

ในตัวอย่าง UA 1001 ที่ 192.0.2.10 ส่ง REGISTER สำหรับ sip:1001@example.com ด้วย CSeq 1 และ branch z9hG4bK-reg-1 โดยขอ Binding อายุ 3600 วินาที Registrar ตอบ 401 ที่มี CSeq 1 REGISTER พร้อม Challenge จากนั้น UA ส่ง REGISTER ฉบับที่สองโดยใช้ Call-ID และ From Tag เดิม แต่เป็น CSeq 2 ใช้ branch ใหม่ z9hG4bK-reg-2 และแนบ Header Authorization แล้ว Registrar ตอบ 200 OK ที่มี CSeq 2 REGISTER พร้อมแสดง Contact ปัจจุบันและอายุที่อนุญาต

เนื่องจาก REGISTER ไม่ใช่ INVITE จึงไม่มี ACK ตามหลัง 401 หรือ 200 การส่งซ้ำพร้อมข้อมูลยืนยันตัวตนคือ Transaction ใหม่ทั้งหมด เลข CSeq และค่า branch จึงเปลี่ยนทั้งคู่

ตัวอย่างประกอบ: ไล่ข้อความของสายหนึ่งสายทีละฉบับ

ตัวอย่างนี้ใช้ที่อยู่สำหรับเอกสาร (Documentation Address) เพื่อให้ติดตามทุกค่าได้ UA 1001 อยู่ที่ 192.0.2.10 และ UA 1002 อยู่ที่ 198.51.100.20 ทั้งคู่อยู่ในโดเมน example.com เพื่อให้กระชับ ข้อความจะวิ่งตรงระหว่าง User Agent ทั้งสอง หากมี Proxy ที่ทำ Record-Route อยู่ในเส้นทาง แต่ละ Request จะมี Via เพิ่มหนึ่งรายการต่อหนึ่ง Hop และมี Header Route ที่ได้จาก Record-Route

สายนี้ใช้ Call-ID call-a-1001-1002@example.com โดย UA 1001 ใส่ Tag a1001 ใน From และ UA 1002 เพิ่ม Tag b1002 ใน To ของ Response ทั้งสามค่านี้คือตัวระบุ Dialog INVITE Transaction ใช้ branch z9hG4bK-call-a-invite และ CSeq 1 INVITE ส่วน ACK ของ 200 OK ใช้ branch ใหม่ z9hG4bK-call-a-ack แต่ยังคงเลข CSeq 1 พร้อม Method ACK และ BYE เป็น Transaction ใหม่ที่ใช้ branch z9hG4bK-call-a-bye และ CSeq 2 BYE

SDP Offer ใน INVITE ประกาศ Media ที่ 192.0.2.10 Port 40000 พร้อม Payload Type 0, 8, 111 และ 101 ส่วน SDP Answer ใน 200 OK ประกาศ Media ที่ 198.51.100.20 Port 41000 และคงไว้เพียง Payload Type 8 กับ 101 หลัง ACK แล้ว RTP จะวิ่งระหว่าง 192.0.2.10:40000 กับ 198.51.100.20:41000

SDP Offer/Answer และการเจรจา Codec (RFC 3264, RFC 8866)

SDP กำหนดไว้ใน RFC 8866 ซึ่งแทนที่ RFC 4566 SIP ใช้ SDP ร่วมกับโมเดล Offer/Answer ของ RFC 3264 ฝั่งหนึ่งส่ง Offer ที่อธิบาย Media ที่ต้องการแลกเปลี่ยน อีกฝั่งตอบด้วย Answer ที่ยอมรับ ปรับภายในกติกาที่อนุญาต หรือปฏิเสธ Media Stream แต่ละรายการ

Offer ในตัวอย่างประกอบด้วย v=0 บรรทัด o= ที่ระบุผู้สร้าง Session ID เวอร์ชัน และที่อยู่ 192.0.2.10 ชื่อ Session บรรทัด c=IN IP4 192.0.2.10 บรรทัด t=0 0 บรรทัด m=audio 40000 RTP/AVP 0 8 111 101 บรรทัด a=rtcp:40001 บรรทัด rtpmap ที่จับคู่ 0 กับ PCMU/8000, 8 กับ PCMA/8000, 111 กับ opus/48000/2 และ 101 กับ telephone-event/8000 บรรทัด fmtp ของ 101 ที่ระบุ 0-15 และ a=ptime:20 กับ a=sendrecv ส่วน Answer ใช้ c=IN IP4 198.51.100.20 และ m=audio 41000 RTP/AVP 8 101 คือเลือก PCMA และ telephone-event

Payload Type 0 (PCMU หรือ G.711 mu-law) และ 8 (PCMA หรือ G.711 A-law) เป็นค่าคงที่จาก RTP Audio/Video Profile (RFC 3551) ส่วน Opus และ telephone-event ใช้ Dynamic Payload Type ในช่วง 96 ถึง 127 และต้องประกาศด้วย a=rtpmap ทุกครั้ง Opus จะระบุใน rtpmap เป็น Clock 48000 Hz และ 2 Channel เสมอ แม้จะใช้กับเสียงพูดแบบ Mono ก็ตาม (RFC 7587)

Offer เรียง Format ตามลำดับที่ต้องการ Answer ต้องมีบรรทัด m= จำนวนเท่ากันและเรียงลำดับเดียวกัน สำหรับ Unicast Stream ที่ยอมรับต้องมีอย่างน้อยหนึ่ง Format ที่ร่วมกับ Offer และอาจระบุ Format เพิ่มที่ไม่ได้อยู่ใน Offer ได้ แต่จะยังใช้ Format เพิ่มนั้นส่ง Media ไม่ได้จนกว่าจะมี Offer ภายหลังที่รองรับ ปฏิเสธ Stream ใดก็ได้ด้วยการตั้ง Port เป็นศูนย์ ถ้าไม่มี Format ที่ยอมรับได้เลย UAS มักปฏิเสธ INVITE ด้วย 488 Not Acceptable Here หรือ 606 เมื่อปฏิเสธในทุกปลายทาง

Call Flow พื้นฐาน: การตั้งสายและวางสายที่สำเร็จ

สายที่สำเร็จระหว่าง UA 1001 กับ UA 1002 มี 4 ขั้นตอน ขั้นแรก UA 1001 ส่ง INVITE ที่มี SDP Offer และ CSeq 1 อาจได้รับ 100 Trying กลับมาเพื่อหยุดการส่ง INVITE ซ้ำบน UDP ซึ่ง 100 Trying เป็นแบบ Hop-by-Hop และส่วนใหญ่สร้างโดย Proxy ตัวถัดไปหรือ UAS จากนั้น UA 1002 แจ้งเตือนผู้ใช้และส่ง 180 Ringing

ขั้นที่สอง เมื่อผู้ใช้รับสาย UA 1002 ส่ง 200 OK พร้อม SDP Answer และ UA 1001 ยืนยันด้วย ACK ถึงจุดนี้ Dialog อยู่ในสถานะ Confirmed

ขั้นที่สาม RTP วิ่งสองทิศทางระหว่างที่อยู่และ Port ตาม SDP คือ 192.0.2.10 Port 40000 กับ 198.51.100.20 Port 41000 ในตัวอย่าง ขึ้นอยู่กับการออกแบบ PBX หรือ SBC อาจยึด Media ไว้ที่ตัวเองแทนที่จะให้วิ่งตรง

ขั้นที่สี่ ฝั่งใดฝั่งหนึ่งวางสายด้วยการส่ง BYE ภายใน Dialog ในตัวอย่างคือ UA 1001 ส่งด้วย CSeq 2 และอีกฝั่งตอบ 200 OK ลำดับ INVITE, 180, 200, ACK, Media, BYE, 200 นี้คือเส้นฐานที่ใช้เปรียบเทียบกับ Flow อื่นทั้งหมด

เสียง Ringback ใน Flow นี้เครื่องผู้โทรสร้างขึ้นเองเมื่อได้รับ 180 ที่ไม่มี SDP ส่วนเสียงหรือประกาศจากผู้ให้บริการที่ได้ยินก่อนรับสายใช้ Early Media ซึ่งอธิบายในหัวข้อถัดไป

Flow กรณีล้มเหลวและยกเลิก: Proxy Challenge, CANCEL และ 486 Busy Here

ระบบจริงเจอ Flow เหล่านี้ทุกวัน และทุก Flow ยังต้องเป็นไปตามกฎของ Transaction คือ Final Response ของ INVITE ทุกฉบับต้องได้รับ ACK และ Request ใหม่คือ Transaction ใหม่เสมอ

ยกเลิกก่อนรับสายด้วย CANCEL

ถ้าผู้โทรวางสายขณะที่ปลายทางยังดังอยู่ UA 1001 จะส่ง CANCEL ซึ่งคัดลอก Request-URI, Call-ID, From, To และเลข CSeq ของ INVITE (แต่ Method เป็น CANCEL) และใช้ branch ของ Via บนสุดเดียวกัน เพื่อให้แต่ละ Hop จับคู่กับ INVITE ที่ค้างอยู่ได้ UAC ต้องไม่ส่ง CANCEL ก่อนได้รับ Provisional Response

Server ตอบ CANCEL เองด้วย 200 OK จากนั้นยุติ INVITE ด้วย 487 Request Terminated และ UA 1001 ส่ง ACK CSeq 1 ยืนยัน 487 ดังนั้นในลำดับนี้มี Final Response สองฉบับคือ 200 OK ของ CANCEL และ 487 ของ INVITE ต้องดู Method ใน CSeq เสมอ เพราะ 200 ของ CANCEL ไม่ได้หมายความว่ามีคนรับสาย

Early Media, 183 Session Progress และ PRACK (RFC 3262)

ผู้โทรมักได้ยินเสียงจากเครือข่ายก่อนมีคนรับสาย เช่น Ringback จากผู้ให้บริการ ประกาศว่าเลขหมายไม่สามารถติดต่อได้ หรือเสียงเมนู IVR สิ่งนี้เรียกว่า Early Media และส่วนใหญ่ส่งสัญญาณด้วย 183 Session Progress ที่มี SDP ทำให้ RTP เริ่มได้ก่อน 200 OK

180 Ringing มักทำให้เครื่องผู้โทรสร้าง Ringback เองตามนโยบายของอุปกรณ์ ส่วน SDP ใน Provisional Response อาจสร้าง Early Media Session ได้ แต่ไม่ได้ยืนยันว่าจะมีเสียง RTP มาถึงหรือสั่งให้หยุด Ringback ทันที ตาม RFC 3960 เครื่องผู้โทรควรพิจารณา Media ที่ได้รับจริงร่วมกับนโยบายท้องถิ่น เช่น เล่นเสียงจากปลายทางและหยุด Ringback เมื่อ RTP มาถึง การตัดสินใจผิดอาจทำให้ Ringback เงียบหรือดังซ้อนบน Trunk

ปกติ Provisional Response ไม่ Reliable คือบน UDP จะไม่ถูกส่งซ้ำ 183 ที่หายไปจึงอาจทำให้ SDP ช่วงก่อนรับสายหายไปด้วย RFC 3262 เพิ่มความ Reliable ให้ UAC ประกาศว่ารองรับด้วย Supported: 100rel ใน INVITE จากนั้น UAS จึงส่ง 183 พร้อม Require: 100rel และค่า RSeq ได้ เช่น RSeq 71 และจะส่งซ้ำจนกว่าจะได้รับการยืนยัน UAC ยืนยันด้วย PRACK ซึ่งเป็น Request ใหม่ใน Early Dialog ที่มี CSeq ของตัวเอง (ในตัวอย่างคือ CSeq 2 PRACK) และมี RAck: 71 1 INVITE หมายถึง RSeq 71 ของ CSeq 1 INVITE แล้ว UAS ตอบ PRACK ด้วย 200 OK

เมื่อมีคนรับสาย 200 OK ของ CSeq 1 INVITE จะปิด INVITE Transaction และได้รับการยืนยันด้วย ACK CSeq 1 ถ้า SDP Answer ถูกส่งไปแล้วใน 183 แบบ Reliable การทำ Offer/Answer ของ INVITE ถือว่าเสร็จแล้ว SDP ที่ส่งซ้ำใน 200 OK ต้องเหมือนเดิมทุกประการ ไม่ใช่ Answer ใหม่ และ BYE ภายหลังจะใช้ CSeq 3

การทำงานระหว่าง Dialog: Hold, โอนสาย และ Session Timer

เมื่อมี Dialog แล้ว ทั้งสองฝั่งเปลี่ยนแปลงสายได้โดยไม่ต้องโทรใหม่ งานที่สำคัญที่สุดในระบบองค์กรมี 3 อย่าง คือ Hold และ Resume การโอนสาย และการต่ออายุเป็นระยะ ทุกงานใช้ Transaction ใหม่ภายใน Dialog เดิม Call-ID และ Tag จึงคงเดิม แต่ branch และ CSeq เปลี่ยน

ชั้น Media: RTP, RTCP, SRTP และ DTMF

RTP (RFC 3550) ขน Media ที่เข้ารหัสแล้ว ส่วนใหญ่บน UDP ทุก Packet มี Payload Type ที่อ้างถึงการจับคู่ Codec จาก SDP มี Sequence Number ให้ผู้รับตรวจ Packet หายหรือสลับลำดับ มี Timestamp สำหรับกำหนดจังหวะการเล่นและคำนวณ Jitter และมี SSRC ที่ระบุแหล่งกำเนิด

RTCP (อยู่ใน RFC 3550 เช่นกัน) ส่ง Sender Report และ Receiver Report ที่มีจำนวน Packet, Packet Loss สะสม, Interarrival Jitter และข้อมูลสำหรับคำนวณ Round-Trip Time ตามธรรมเนียม RTP ใช้ Port เลขคู่และ RTCP ใช้ Port เลขคี่ถัดไป เช่น 40000 และ 40001 SDP สามารถประกาศ Port ของ RTCP ที่ต่างออกไปด้วย a=rtcp (RFC 3605) และระบบสมัยใหม่จำนวนมากรวม RTP กับ RTCP ไว้บน Port เดียว (RFC 5761)

SRTP (RFC 3711) ให้การรักษาความลับ การยืนยันความถูกต้องของข้อความ และการป้องกัน Replay แก่ RTP และ RTCP Transform ปริยายคือ AES แบบ Counter Mode สำหรับการเข้ารหัส และ HMAC-SHA1 สำหรับการยืนยันความถูกต้อง ส่วน AES-GCM ถูกเพิ่มภายหลังใน RFC 7714 กุญแจของ SRTP มาจากกลไกจัดการกุญแจแยกต่างหาก ที่พบบ่อยคือ SDES ซึ่งใส่ crypto attribute ใน SDP (RFC 4568) และปลอดภัยเฉพาะเมื่อ Signalling ของ SIP ถูกป้องกันด้วย TLS หรือใช้ DTLS-SRTP (RFC 5764) แบบที่ WebRTC ใช้

NAT, Firewall และบทบาทของ SBC

NAT และ Stateful Firewall ก่อปัญหากับ SIP มากกว่าฟังก์ชันเครือข่ายอื่นใด SIP และ SDP บรรจุ IP Address และ Port ไว้ภายในข้อความ ทั้งใน Via, Contact และบรรทัด c= กับ m= ของ SDP อุปกรณ์ NAT แก้ไขเฉพาะ Header ชั้น IP และ Transport ภายนอก โทรศัพท์หลัง NAT จึงอาจประกาศที่อยู่ Private ที่ปลายทางเข้าถึงไม่ได้ Signalling อาจยังทำงาน เพราะ Response เดินตาม Via แต่ Media ล้มเหลวหรือไปได้ทางเดียว

ลองพิจารณา Extension 1003 ที่ทำงานนอกสำนักงาน มีที่อยู่ Private 192.168.1.50 อยู่หลัง NAT ที่มีที่อยู่ Public 203.0.113.80 REGISTER ของเครื่องนี้มาถึงจาก 203.0.113.80 บน Port ที่ถูกแปลงแล้ว แต่ Contact และ SDP ยังระบุ 192.168.1.50 Registrar, PBX หรือ SBC ต้องตัดสินใจว่าจะเชื่อที่อยู่ใดในแต่ละชั้น และต้องยืนยันเส้นทาง Media ด้วย Packet Capture แทนการอนุมานจาก SIP

ในการออกแบบระดับองค์กร SBC ที่ขอบเครือข่ายคือเครื่องมือหลัก SBC ทำงานแบบ B2BUA ใช้ที่อยู่ Public ของตัวเองใน SIP และ SDP ยึด Media เมื่อจำเป็น และซ่อนโครงสร้างภายใน แต่ยังต้องตั้งค่าให้ถูกต้อง SBC ไม่ได้รับประกัน Routing ที่ถูกต้อง การรองรับ Codec หรือความปลอดภัยด้วยตัวมันเอง

ความปลอดภัยของ SIP: TLS สำหรับ Signalling และ SRTP สำหรับ Media

Signalling และ Media ถูกป้องกันแยกกัน SIP over TLS ซึ่งปกติใช้ Port 5061 จะเข้ารหัสและรักษาความถูกต้องของ Signalling แบบ Hop-by-Hop ระหว่าง Client กับ Proxy หรือระหว่าง Server สองตัว ป้องกันหมายเลขที่โทร ตัวตน Digest Challenge และกุญแจ SRTP ที่อยู่ใน SDP URI แบบ sips ขอให้ใช้ TLS ทุก Hop ไปจนถึงปลายทางรวม Hop สุดท้ายตาม RFC 5630 แนวทางปัจจุบันเลิกใช้ TLS 1.0 และ 1.1 (RFC 8996) และแนะนำ TLS 1.2 หรือ TLS 1.3 (RFC 9325)

TLS ไม่ได้ป้องกัน Media เสียงจะถูกเข้ารหัสเฉพาะเมื่อเจรจา SRTP บน Media Leg แต่ละช่วง และจะได้รับการป้องกันแบบปลายถึงปลายเฉพาะเมื่อไม่มี B2BUA หรือ SBC ตัวใดบนเส้นทางถอดรหัสแล้วเข้ารหัสใหม่ TLS Connection และ SRTP Context แต่ละชุดจึงมีจุดสิ้นสุดของตัวเอง ซึ่งควรระบุไว้ในเอกสารการออกแบบ

เนื่องจาก TLS เป็นแบบ Hop-by-Hop ทุก Proxy หรือ SBC ที่เป็นปลายของ TLS สามารถอ่านและแก้ไขข้อความ SIP ได้ ความน่าเชื่อถือของเครือข่าย SIP จึงขึ้นกับว่าไว้วางใจอุปกรณ์ใดบ้างด้วย ไม่ใช่แค่เรื่องการเข้ารหัส

SIP Trunk, Microsoft Teams Direct Routing และ Voice AI

SIP Trunk เชื่อม PBX กับผู้ให้บริการผ่าน IP แทนสาย Analog หรือวงจร ISDN Primary Rate หมายเลข DID (Direct Inward Dialling) ถูกจับคู่กับ Extension และควรแปลงหมายเลขให้อยู่ในรูปแบบ E.164 ก่อนตัดสินเส้นทาง เช่น +66 ตามด้วยหมายเลขในประเทศที่ตัดเลข 0 นำหน้าออก Trunk ยืนยันตัวตนได้ทั้งแบบลงทะเบียนด้วย Digest Credential หรือแบบ IP Address ที่เชื่อถือได้ ขึ้นกับผู้ให้บริการ

Microsoft Teams Direct Routing เชื่อม Teams Phone เข้ากับ SIP Trunk ผ่าน SBC ที่ Microsoft รับรองสำหรับงานนี้ ฝั่ง Teams ใช้ SIP over TLS และ SRTP และ SBC ทำหน้าที่แปลงระหว่าง Interface นั้นกับ Trunk หรือ PBX รวมถึงการจัดการ Header, Codec และ Media

แพลตฟอร์ม Voice AI เช่น พนักงานรับสายอัตโนมัติและระบบวิเคราะห์เสียงสนทนา มักเชื่อมเข้ากับสายผ่าน SIP Interface หรือการ Fork Media หลักการเดียวกันยังใช้ได้ คือแยกการเชื่อม Signalling ออกจาก Media Stream ยืนยัน Codec และวิธีส่ง DTMF และวัด Latency บนเส้นทาง Media ซึ่งมีผลโดยตรงต่อความเป็นธรรมชาติของบทสนทนา

SIPPER ออกแบบและดูแลการเชื่อมต่อ SIP Trunk, SBC และ Teams Direct Routing สำหรับองค์กร รายละเอียดการเลือกบริการ SIP Trunk อยู่ในบทความที่เกี่ยวข้องด้านล่าง

แนวทางแก้ปัญหา SIP ทีละชั้น

เริ่มจากหลักฐานที่เก็บจากจุดที่ถูกต้อง คือ Packet Capture ฝั่งโทรศัพท์ PBX, SBC และ Interface ที่ต่อกับผู้ให้บริการ โดยจับคู่กันด้วย Call-ID และเวลา บน B2BUA ค่า Call-ID จะเปลี่ยนระหว่าง Leg จึงต้องบันทึกเวลา หมายเลข และ Header สำหรับจับคู่ที่ระบบเพิ่มไว้ด้วย

ตารางนี้จับคู่อาการที่พบบ่อยกับสาเหตุที่เป็นไปได้และหลักฐานแรกที่ควรเก็บ ไล่ตรวจตามลำดับชั้น ได้แก่ Connectivity, Transaction, Dialog และ Route, SDP, RTP และ RTCP แล้วจึงดูพฤติกรรมของแอปพลิเคชัน

เอกสารอ้างอิงและมาตรฐาน

รายการด้านล่างคือมาตรฐานหลักที่ใช้ในบทความนี้ กรณีที่ RFC เดิมถูกแทนที่แล้ว จะระบุเอกสารฉบับปัจจุบันไว้ก่อน

• RFC 3261: SIP โปรโตคอลหลัก
• RFC 3262: ความ Reliable ของ Provisional Response (100rel และ PRACK)
• RFC 3263: การค้นหา SIP Server ด้วยระเบียน NAPTR, SRV และ A หรือ AAAA
• RFC 3264: โมเดล Offer/Answer ร่วมกับ SDP
• RFC 8866: SDP ซึ่งแทนที่ RFC 4566
• RFC 3550: RTP และ RTCP และ RFC 3551: Audio/Video Profile ที่กำหนด Static Payload Type
• RFC 3711: SRTP, RFC 7714: AES-GCM สำหรับ SRTP, RFC 4568 และ RFC 5764: การจัดการกุญแจของ SRTP
• RFC 3581: rport, RFC 5626: SIP Outbound, RFC 5923: Connection Reuse, RFC 4961: Symmetric RTP
• RFC 8445, RFC 8489 และ RFC 8656: ICE, STUN และ TURN
• RFC 3311: UPDATE, RFC 3515: REFER, RFC 3891: Replaces, RFC 4028: Session Timer, RFC 6086: INFO
• RFC 4733: DTMF แบบ telephone-event ซึ่งแทนที่ RFC 2833 และ RFC 7587: RTP Payload ของ Opus
• RFC 3325: P-Asserted-Identity, RFC 3323: Privacy, RFC 5630: SIPS, RFC 8760: Digest แบบ SHA-2 สำหรับ SIP, RFC 8996 และ RFC 9325: แนวทางเวอร์ชัน TLS
• RFC 7118: SIP over WebSocket, RFC 6026: การแก้ไขการจัดการ INVITE Transaction, RFC 6665: SUBSCRIBE และ NOTIFY, RFC 3428: MESSAGE, RFC 3966: tel URI, RFC 3605: RTCP Attribute, RFC 5761: การรวม RTP กับ RTCP บน Port เดียว