SIP หมายถึง โพรโทคอลการเริ่มตนเชื่อมตอวงจรสนทนา (Session Initiation Protocol) ตาม RFC 3261 ของ IETF สําหรับเปนโพรโทคอลควบคุมการใหสัญญาณแบบระดับเดียวกัน (peer-to-peer)สําหรับเปด ปรับ และปดการเชื่อมตอวงจรสนทนา (session) ตาง ๆ อาทิโทรศัพทผานโครงขายอินเทอรเน็ตและการประชุมทางเสียงผานโครงขายอินเทอรเน็ต เปนตน
Credit : http://standard1.nbtc.go.th/getattachment/5aca8579-db09-464d-933d-3c9a5608a178/6201.aspx
-SIP ก็เป็น text-based protocol ที่ใช้ในการสร้างการเชื่อมต่อระหว่างโปรแกรมที่อยู่คนละเครื่องผ่านเครือข่าย (call setup & signaling) โดยตัวมันเองเป็น stateless (ในขณะที่โปรโตคอลอย่าง H.323 เป็น stateful ที่มีความซับซ้อนกว่า) ตัวอย่างการใช้ SIP คือ ใช้ในการ initiate session ในการส่งวีดีโอข้ามเครื่อง หรือในการสร้างคอนเนคชั่นในระหว่างการต่อสายโทรศัพท์ เนื่องจาก SIP เป็นโปรโตคอลในระดับ application layer (ในมุมมองของ OSI Network Stack) มันสามารถใช้บน network/transport protocol ใดๆก็ได้ เช่น ผ่านเวป (ด้วย TCP หรือ UDP) ผ่านระบบเครือข่ายมือถือ ฯลฯ
-ตัว SIP เน้นเฉพาะการเชื่อมต่อระบบสองฝั่งเท่านั้น พอต่อได้แล้ว จะรับส่งข้อมูลกันยังไงต่อ ขึ้นอยู่กับโปรโตคอลอื่นที่สองฝั่งใช้อีกที ซึ่งส่วนนี้จะไม่เกี่ยวกับ SIP แล้วครับ
Credit : http://www.narisa.com/forums/index.php?showtopic=17004
บทนำ
SIP เป็นโปรโตคอลที่ใช้ Create, Modify และ Terminate Session ในการติดต่อสื่อสาร ซึ่งมีการนำไปใช้ใน Internet Telephone Call, Multimedia Distribution, และ Multimedia Conference โปรโตคอลนี้ออกแบบโดย Henning Schulzrinne จากมหาวิทยาลัยโคลัมเบียและ Mark Handley จากมหาวิทยาลัยลอนดอนในปี 1996 (พ.ศ.2539) ต่อมาในเดือนพฤศจิกายนปี 2000 (พ.ศ.2543) ก็ได้รับการยอมรับจาก 3GPP และกลายเป็นส่วนหนึ่งของสถาปัตยกรรม IMS (IP Multimedia Subsystem), Voice over IP รวมถึง H.323 และอื่น ๆ
IMS เป็นแนวคิดเกี่ยวกับสถาปัตยกรรมของการให้บริการ IP Multimedia แก่ผู้ใช้ ซึ่งเป็นส่วนหนึ่งในการพัฒนาเครือข่ายมือถือของ GSM โดยเริ่มมาจาก 3GPP R5 นำเสนอวิธีส่ง Internet Services ผ่าน GPRS ต่อมาได้มีการปรับปรุงโดย 3GPP, 3GPP2, และ TISPAN เพื่อให้ครอบคลุมถึง Wireless LAN, CDMA2000, และ Fix Line โดยนำโปรโตคอลของ IETF มาใช้ เช่น SIP
SIP จะมีลักษณะทั่วไปคือ
- ขนาดเล็ก เพราะกำหนดวิธีติดต่อไว้เพียง 6 วิธีเพื่อลดความซับซ้อน
- มีความเป็นอิสระ สามารถใช้งานกับ UDP, TCP, ATM และอื่น ๆ ได้
- เป็นข้อความที่มนุษย์สามารถอ่านได้
การออกแบบโปรโตคอล
SIP client จะใช้ TCP หรือ UDP พอร์ต 5060 เชื่อมต่อกับ SIP server และ SIP อื่น ๆ ซึ่ง SIP จะใช้สำหรับตั้งค่าและยกเลิก Voice หรือ Video call แต่ก็สามารถนำไปใช้กับงานกับระบบอื่นที่ต้องการเปิด Session รวมถึง Event Subscription และ Notification ได้ การสื่อสารโดยใช้ภาพและเสียงสามารถทำได้โดยแบ่งโปรโตคอล Session ออกจากกัน เช่น RTP (Real-time Transport Protocol)
RTP ใช้กำหนดรูปแบบ packet ในการส่งภาพและเสียงผ่านอินเตอร์เน็ต ถูกพัฒนาโดย Audio-Video Transport Working Group ของ IETF และได้ตีพิมพ์ครั้งแรกในปี 1996 (พ.ศ.2539) โดย RTP จะไม่มีพอร์ต TCP หรือ UDP มาตรฐานในการสื่อสาร แต่จะใช้พอร์ต UDP ที่เป็นเลขคู่ในการสื่อสารและพอร์ต UDP เลขคี่ถัดไปเป็น RTP Control Protocol (RTCP) เลขพอร์ตมักจะอยู่ระหว่าง 16384-32767 RTP สามารถรับส่งข้อมูลอะไรก็ได้แบบ real-time เช่น ภาพและเสียง โดยใช้โปรโตคอล SIP ในการตั้งค่าและยกเลิก
SIP จะเป็นโปรโตคอลที่ใช้ส่งสัญญาณและตั้งค่าในระบบ IP สามารถใช้งานร่วมกับระบบโทรศัพท์ PSTN (Public Switched Telephone Network) ได้ ซึ่งมาตรฐาน SIP ไม่ได้ระบุไว้ SIP ทำได้เพียงสางสัญญาณและตั้งค่า อย่างไรก็ตาม SIP สามารถใช้งานในระบบเครือข่ายได้ เช่น Proxy Server และ User Agent ซึ่งจะเหมือนกับการทำงานของโทรศัพท์ คือ หมุนเบอร์, ทำให้โทรศัพท์ปลายทางส่งเสียง, ฟังเสียงตอบรับหรือสัญญาณไม่ว่าง
SIP ทำให้ระบบโทรศัพท์มีความสามารถในขั้นตอนโทรออกมากขึ้น ดูได้จาก Signalling System 7 (SS7) โดย SS7 จะเป็นโปรโตคอลที่รวมศูนย์, ใช้กับระบบรวมศูนย์ที่ซับซ้อน, และใช้งานกับเครื่องลูกข่ายที่ไม่เก่ง (โทรศัพท์บ้าน) SIP เป็นโปรโตคอลแบบ Peer-to-Peer ซึ่งใช้กับเครือข่ายที่ไม่ซับซ้อนและเครื่องลูกค้ามีความสามารถสูง
แม้ VoIP จะมีโปรโตคอลส่งสัญญาณเยอะอยุ่แล้ว แต่ SIP ก็ช่วยสร้างเครื่องหลักในการสื่อสารแบบ IP ได้มากกว่าระบบโทรคมนาคม SIP จะเป็นมาตรฐานของ IETF ขณะที่ H.323 เป็นโปรโตคอลของ ITU ซึ่งทั้งสององค์กรก็ให้เกียรติกัน
SIP สามารถทำงานร่วมกับโปรโตคอลอื่นได้โดยจะสร้างสัญญาณให้ Session ของการติดต่อสื่อสาร SIP จะทำงานเป็นพาหะของ Session Description Protocol (SDP) ใช้อธิบายรายละเอียดของเนื้อหาที่จะส่ง เช่น หมายเลขพอร์ตที่ใช้, Codec ที่ต้องการ
SIP จะคล้ายกับ HTTP เช่น การรับส่งข้อมูลใช้ภาษาที่มนุษย์อ่านได้, รหัสบอกสถานะจะคล้าย ๆ กัน บางคนกล่าวว่า SIP เป็นโปรโตคอลแบบ stateless ซึ่งสามารถตรวจสอบความผิดพลาดและเพิ่มเติมความสามารถได้มากกว่าโปรโตคอลแบบ stateful ซึ่งโปรโตคอลแบบ stateless จะส่งคำสั่งได้อย่างอิสระ โดยไม่ต้องสนใจว่าคำสั่งก่อนหน้าคือคำสั่งอะไร ในขณะที่โปรโตคอลแบบ stateful จะต้องมีการบันทึกสถานะการแลกเปลี่ยนข้อมูลไว้ตลอดเวลา
ส่วนประกอบของเครือข่าย SIP
Hardware ที่ใช้จะเหมือนกับโทรศัพท์บ้าน แต่ใช้ SIP และ RTP ในการสื่อสาร บางระบบจะใช้ Electronic Numbering (ENUM) หรือ DUDi ในการแปลงหมายเลขโทรศัพท์ให้เป็น SIP Address แล้วเรียก SIP อื่นในระบบเครือข่าย
ตัวอย่างโปรแกรมในปัจจุบันที่ใช้ SIP สื่อสาร เช่น Microsoft Windows Messenger, iChat AV, AIM ของ Apple ซึ่ง SIP จะอาศัย Proxy และอุปกรณ์เครือข่ายเพื่อทำงานแบบ peer-to-peer เหมือนระบบทั่วไป
SIP Request
RFC 3261 (SIP) มี 6 แบบ ได้แก่
- INVITE ใช้เมื่อ client ต้องการสร้าง session เพื่อติดต่อ
- ACK ใช้เมื่อ client ได้รับการตอบกลับจาก INVITE ภายในเวลาที่กำหนด
- BYE ใช้เมื่อต้องการสิ้นสุดการเชื่อมต่อ ซึ่งผู้ส่งและผู้รับสามารถส่งได้เหมือนกัน
- CANCEL ใช้เพื่อยุติการค้นหา แต่ไม่สามารถใช้ยกเลิกสายที่รับแล้วได้
- OPTIONS ใช้ตรวจสอบคุณสมบัติของ Server
- REGISTER ใช้ระบุ Address ของข้อมูล To ใน SIP Server
RFC 3262 เพิ่มความน่าเชื่อถือในการตอบกลับของ SIP
- PRACK
RFC 3265 เพิ่มเติม
- SUBSCRIBE แจ้ง Event ของ Notification จากผู้แจ้ง
- NOTIFY แจ้งเหตุการณ์ใหม่
SIP Response
1xx ข้อมูลการตอบกลับ / ข้อมูลทั่วไป
รหัสสถานภาพกลุ่มนี้หมายถึง "เครื่องให้บริการได้รับการร้องขอแล้ว สามารถดำเนินการต่อไปได้" ใช้เป็นข้อความตอบรับชั่วคราว ซึ่งจะประกอบด้วยส่วนหัว Status-Line กับส่วนหัวอื่น ๆ เพิ่มเติม และจบด้วยบรรทัดว่าง
เครื่องให้บริการได้รับการร้องขอแล้ว และเครื่องลูกข่ายควรจะส่งเนื้อหาตามออกไปกับข้อความร้องขอ (ในกรณีที่เนื้อหาจำเป็นต้องส่งไปกับการร้องขอ เช่นข้อความร้องขอแบบ POST) ถ้าเนื้อหาในข้อความร้องขอมีขนาดใหญ่ การส่งข้อมูลไปยังเครื่องแม่ข่ายอาจเกิดการชะงัก การร้องขออาจถูกตัดไปเสียก่อนเพราะไม่มีส่วนหัวที่เหมาะสม ดังนั้นเพื่อให้เครื่องแม่ข่ายสามารถตรวจสอบได้ว่าการร้องขอนั้นจะเป็นที่ยอมรับได้หรือไม่ เครื่องลูกข่ายจะต้องส่งส่วนหัว Expect: 100-continue ไปในข้อความร้องขอครั้งแรก และตรวจสอบว่ารหัสสถานภาพที่ได้มาจากข้อความตอบรับเป็น 100 Continue ก่อนดำเนินการส่งข้อมูลต่อไป (หากล้มเหลว จะได้รับรหัสเป็น 417 Expectation Failed และหยุดดำเนินการส่งข้อมูล)
- 180 กำลังเรียก (ring) / 180 Ringing
- 181 กำลัง forward / 181 Call is being forwarded
- 182 กำลังเข้าคิว / 182 Queued
- 183 ความคืบหน้าของ session / 183 Session Progress
2xx ได้รับการตอบกลับ / การร้องขอสำเร็จ
รหัสสถานภาพกลุ่มนี้หมายถึง "การดำเนินการที่ร้องขอได้รับแล้ว เป็นที่เข้าใจแล้ว และได้ยอมรับแล้ว" ใช้แสดงว่าการร้องขอจากเครื่องลูกข่ายได้ดำเนินการสำเร็จแล้ว
เป็นรหัสตอบรับมาตรฐานสำหรับการร้องขอที่สำเร็จ ข้อความตอบรับที่แท้จริงอาจแตกต่างกันออกไปตามคำสั่งร้องขอที่ใช้ ในการร้องขอแบบ GET เนื้อหาในข้อความตอบรับจะเป็นเนื้อหาที่เกี่ยวข้องกับทรัพยากรที่ร้องขอ ส่วนในการร้องขอแบบ POST เนื้อหาในข้อความตอบรับจะเป็นการอธิบายทรัพยากรหรือผลลัพธ์จากการดำเนินการดังกล่าว เป็นต้น
การร้องขอได้รับแล้วเพื่อดำเนินการ แต่การดำเนินการนั้นยังไม่เสร็จสิ้น ซึ่งไม่จำเป็นต้องส่งการร้องขอใหม่ในช่วงเวลาดังกล่าว เพราะว่าเครื่องแม่ข่ายอาจยังไม่รับการร้องขอในขณะนั้น
3xx Redirect / การเปลี่ยนทาง
รหัสสถานภาพกลุ่มนี้หมายถึง "เครื่องลูกข่ายอาจต้องมีการกระทำอื่นเพิ่มเติม เพื่อที่จะทำการร้องขอนั้นให้สำเร็จ" แสดงว่าโปรแกรมตัวแทนผู้ใช้จำเป็นต้องมีการดำเนินการอื่นเพิ่มเติม ซึ่งอาจทำได้เองโดยไม่จำเป็นต้องโต้ตอบกับผู้ใช้ ถ้าคำสั่งร้องขอครั้งที่สองเป็น GET หรือ HEAD นอกจากนี้ตัวแทนผู้ใช้ไม่ควรเปลี่ยนทางมากกว่าห้าครั้ง เพราะว่าการทำเช่นนั้นอาจถูกพิจารณาว่าเป็นวงวนไม่รู้จบ
- 300 มีหลายตัวเลือก / 300 Multiple Choices
แสดงตัวเลือกสำหรับทรัพยากรให้เครื่องลูกข่ายเลือกตามที่ต้องการ ตัวอย่างเช่น รูปแบบที่แตกต่างกันสำหรับวิดีโอ รายชื่อไฟล์ที่มีส่วนขยายแตกต่างกัน หรือการแก้ความกำกวมความหมายของคำ
- 301 ย้ายเป็นการถาวร / 301 Moved Permanently
บอกให้เครื่องลูกข่ายทราบว่า การร้องขอครั้งนี้และครั้งต่อ ๆ ไปควรจะเปลี่ยนทางไปยังตัวระบุแหล่งทรัพยากรสากล (URI) ที่ให้ไว้ เครื่องแม่ข่ายจะไม่เป็นผู้เปลี่ยนทางให้
- 302 ย้ายเป็นการชั่วคราว / 302 Found
รหัสนี้นิยมใช้เป็นการเปลี่ยนทางบนหน้าเว็บมากที่สุด แต่ก็เป็นตัวอย่างหนึ่งในทางปฏิบัติที่ขัดกับมาตรฐาน แต่เดิมใน HTTP/1.0 วลีดังกล่าวใช้ว่า "Moved Temporarily" เพื่อเป็นการเปลี่ยนทางชั่วคราว (RFC 1945) แต่หลายเบราว์เซอร์กลับนำไปทำเป็นรหัส 303 See Other แทน ดังนั้นในรุ่น HTTP/1.1 จึงเพิ่มรหัส 303 และ 307 เข้าไปเพื่อแยกแยะพฤติกรรมการใช้งานทั้งสอง แล้วเปลี่ยนวลีเหตุผลของรหัสนี้เป็น "Found" อย่างไรก็ตาม เว็บแอปพลิเคชันและเฟรมเวิร์กส่วนใหญ่ก็ยังใช้รหัส 302 ในลักษณะเดียวกับรหัส 303
- 303 See Other
เนื้อหาที่ร้องขอสามารถพบได้จากตัวระบุในแหล่งอื่นด้วยคำสั่ง GET แต่ถ้าหากแหล่งอื่นนั้นใช้ PUT เครื่องลูกข่ายจะต้องถือว่าเครื่องแม่ข่ายได้รับข้อมูลแล้ว และการเปลี่ยนทางควรจะกระทำโดยส่งข้อความ GET แยกออกไปต่างหาก
- 304 Not Modified
ทรัพยากรที่ร้องขอยังไม่มีการปรับปรุงเพิ่มเติมหลังจากการร้องขอครั้งล่าสุด โดยปกติแล้วเครื่องลูกข่ายเอชทีทีพีจะส่งส่วนหัว If-Modified-Since มาด้วยเพื่อให้เครื่องแม่ข่ายเปรียบเทียบเวลา การใช้ส่วนหัวนี้ให้เป็นประโยชน์ช่วยลดแบนด์วิดท์ และลดการประมวลผลซ้ำซ้อนทั้งทางฝั่งแม่ข่ายและลูกข่าย
- 305 ใช้ Proxy / 305 Use Proxy
แจ้งไปยังเครื่องลูกข่ายว่าควรใช้พร็อกซี ตัวแทนผู้ใช้หลายโปรแกรม อาทิเบราว์เซอร์ของมอซิลลา [5] และอินเทอร์เน็ตเอกซ์พลอเรอร์ ยังดำเนินการกับรหัสตอบรับนี้ไม่ถูกต้อง ด้วยเหตุผลหลักในด้านความปลอดภัย
- 306 Switch Proxy
แจ้งไปยังเครื่องลูกข่ายว่าควรเปลี่ยนพร็อกซีที่ใช้ ปัจจุบันเลิกใช้งานแล้ว
- 307 Temporary Redirect
ข้อความร้องขอที่ส่งเข้ามาในครั้งนี้ ควรจะส่งซ้ำไปยังตัวระบุแหล่งทรัพยากรสากลที่กำหนดให้ แต่ครั้งหน้าก็อาจสามารถส่งมายังที่เดิมได้ ต่างกับรหัส 303 ตรงที่ข้อความร้องขอจะไม่มีการเปลี่ยนแปลง นั่นคือข้อความร้องขอแบบ POST ควรจะเหมือนเดิม เพียงแค่ส่งไปยังแหล่งอื่นแทนเท่านั้น
- 380 บริการเสริม / 380 Alternative service
4xx การตอบกลับล้มเหลว / ความผิดพลาดจากเครื่องลูกข่าย
รหัสสถานภาพกลุ่มนี้หมายถึง "การร้องขอจากเครื่องลูกข่ายไม่เป็นที่ยอมรับ หรือไม่สามารถทำตามการร้องขอนั้นได้" เครื่องแม่ข่ายจะถือว่าเป็นความผิดพลาดของเครื่องลูกข่าย เครื่องให้บริการควรจะอธิบายสาเหตุของความผิดพลาดไปกับเนื้อหาด้วย เว้นแต่เมื่อข้อความร้องขอนั้นใช้คำสั่ง HEAD และควรระบุว่าเป็นปัญหาที่เกิดขึ้นชั่วคราวหรือถาวร รหัสสถานภาพเหล่านี้สามารถใช้ตอบรับกับคำสั่งร้องขอใดก็ได้ ซึ่งตัวแทนผู้ใช้ควรแจ้งข้อผิดพลาดเหล่านั้นให้ผู้ใช้งานทราบด้วย
ข้อความร้องขอที่ส่งมามีความผิดพลาดทางไวยากรณ์ หรือไม่สามารถทำตามการร้องขอนั้นได้
- 401 ไม่ได้รับสิทธิ ใช้กับ registrar เท่านั้น ส่วน Proxy ใช้ 407 / 401 Unauthorized
บอกไปยังเครื่องลูกข่ายว่าจำเป็นต้องทำการพิสูจน์ตัวตนก่อน คล้ายกับรหัส 403 Forbidden แต่ใช้เฉพาะเมื่อการพิสูจน์นั้นสามารถกระทำได้แต่กระบวนการล้มเหลว หรือยังไม่ได้เตรียมไว้ให้ ดูเพิ่มที่ การพิสูจน์ตัวจริงเพื่อเข้าถึงแบบพื้นฐาน (basic access authentication) และ การพิสูจน์ตัวจริงเพื่อเข้าถึงแบบย่อยข้อมูล (digest access authentication)
- 402 ต้องจ่ายเงิน (สงวนไว้ใช้ในอนาคต) / 402 Payment Required
จำเป็นต้องเสียค่าเข้าชมก่อน ความตั้งใจของรหัสสถานภาพนี้คือเพื่อใช้เป็นส่วนหนึ่งของระบบเงินอิเล็กทรอนิกส์หรือระบบที่ต้องบริจาคเพื่อให้ได้มาซึ่งเนื้อหา แต่ก็ยังไม่เคยเกิดขึ้นมาก่อน และรหัสนี้ก็ไม่เคยได้นำมาใช้เลย
- 403 ซ่อน / 403 Forbidden
ข้อความร้องขอที่ส่งเข้ามาถูกต้อง แต่เครื่องแม่ข่ายปฏิเสธที่จะให้บริการ ในกรณีนี้การพิสูจน์ตัวตนไม่ได้ให้ผลที่แตกต่างจากเดิม
- 404 ไม่พบ ไม่มีผู้ใช้ชื่อนี้ / 404 Not Found
ทรัพยากรที่ร้องขอไม่พบบนเครื่องแม่ข่าย แต่อาจสามารถกลับมามีได้ใหม่ในอนาคต การร้องขออื่น ๆ ที่ตามมายังสามารถดำเนินการได้ต่อไป
- 405 ไม่อนุญาตให้ใช้วิธีนี้ / 405 Method Not Allowed
เครื่องลูกข่ายใช้คำสั่งที่ทรัพยากรนั้นไม่รองรับ ตัวอย่างเช่น การส่งข้อมูลจากแบบฟอร์มด้วยคำสั่ง GET แต่ทรัพยากรปลายทางจำเป็นต้องเสนอด้วยคำสั่ง PUT หรือการใช้ PUT บนทรัพยากรที่อ่านได้อย่างเดียว เป็นต้น
- 406 ไม่สามารถรับได้ /406 Not Acceptable
ทรัพยากรที่ร้องขอซึ่งสามารถสร้างขึ้นได้ แต่เครื่องแม่ข่ายไม่ยอมรับให้ทำเช่นนั้น เนื่องจากส่วนหัว Accept ที่ส่งมากับข้อความร้องขอไม่สัมพันธ์กัน
- 407 ไม่ได้รับสิทธิจาก Proxy /407 Proxy Authentication Required
จำเป็นต้องมีการพิสูจน์ตัวจริงบนพร็อกซีก่อน
- 408 หมดเวลา ไม่สามารถค้นหาผู้ใช้ได้ในเวลาที่กำหนด / 408 Request Timeout
เครื่องให้บริการรอรับข้อความร้องขอจนหมดเวลา
- 409 ข้อขัดแย้งในข้อความร้องขอ / 409 Conflict
ใช้แสดงว่าการร้องขอนั้นไม่สามารถประมวลผลได้ เนื่องจากเกิดข้อขัดแย้งในข้อความร้องขอ เช่นการแก้ไขชนกัน
- 410 ไม่สามารถติดต่อผู้ใช้ได้ ณ เวลานี้ / 410 Gone
ทรัพยากรที่ร้องขอไม่มีอยู่ และจะไม่กลับมามีอีกต่อไป รหัสนี้ควรใช้เมื่อตั้งใจที่จะเอาทรัพยากรแหล่งหนึ่งออกไปอย่างถาวร อย่างไรก็ตามรหัสนี้ก็ไม่จำเป็นและสามารถใช้ 404 Not Found แทนได้ แต่ถ้าหากได้รับรหัส 410 เมื่อใด เครื่องลูกข่ายไม่ควรส่งการร้องขอทรัพยากรนั้นมาอีกในอนาคต เสิร์ชเอนจินควรลบทรัพยากรนี้ออกจากดัชนีเว็บไซต์
- 411 Length Required
ข้อความร้องขอไม่ได้ระบุขนาดของเนื้อหามาในส่วนหัว ซึ่งเป็นสิ่งที่จำเป็นโดยทรัพยากรปลายทาง
- 412 Precondition Failed
เครื่องแม่ข่ายไม่สามารถทำตามเงื่อนไขอย่างใดอย่างหนึ่งที่ให้ไว้โดยผู้ทำการร้องขอ
- 413 คำสั่ง Request ยาวเกินไป / 413 Request Entity Too Large
ทรัพยากรที่ร้องขอใหญ่เกินกว่าที่จะส่งด้วยโพรโทคอลปัจจุบันได้
- 414 Request-URI ยาวเกินไป / 414 Request-URI Too Long
ข้อความร้องขอไม่ได้ระบุแบบชนิดสื่ออินเทอร์เน็ตที่เครื่องแม่ข่ายหรือทรัพยากรนั้นรองรับ ตัวอย่างเช่นเครื่องลูกข่ายระบุว่าทรัพยากรรูปภาพควรจะส่งให้มาเป็น image/svg+xml แต่เครื่องแม่ข่ายไม่สามารถหาชนิดของรูปภาพที่ต้องการ
- 415 ประเภทสื่อไม่สนับสนุน / 415 Unsupported Media Type
ข้อความร้องขอไม่ได้ระบุแบบชนิดสื่ออินเทอร์เน็ตที่เครื่องแม่ข่ายหรือทรัพยากรนั้นรองรับ ตัวอย่างเช่นเครื่องลูกข่ายระบุว่าทรัพยากรรูปภาพควรจะส่งให้มาเป็น image/svg+xml แต่เครื่องแม่ข่ายไม่สามารถหาชนิดของรูปภาพที่ต้องการ
- 416 ไม่สนับสนุน URI แบบนี้ / 416 Requested Range Not Satisfiable
เครื่องลูกข่ายร้องขอเนื้อหาบางส่วนของไฟล์ แต่เครื่องแม่ข่ายไม่สามารถจัดหาช่วงข้อมูลนั้นได้ เช่นในกรณีที่ตัวแทนผู้ใช้ร้องขอด้วยช่วงข้อมูลที่เกินกว่าขนาดของไฟล์
- 421 ต้องการข้อมูลเพิ่มเติม / 421 Extension required
- 422 Unprocessable Entity
ข้อความร้องขอถูกจัดรูปแบบไว้อย่างดีแล้ว แต่ไม่สามารถทำตามนั้นได้เนื่องจากการตีความผิดพลาด
- 423 ช่วงเวลาน้อยเกินไป / 423 Locked
ทรัพยากรที่กำลังจะเข้าถึงนั้นถูกล็อกอยู่
- 479 ไม่สามารถใช้ URI นี้ได้
- 480 ปิดบริการชั่วคราว / 480 Temporarily unavailable
- 481 ติดต่อไม่ได้ / 481 Call/Transaction does not exist
- 482 เกิดการวน loop / 482 Loop detected
- 483 เชื่อมต่อมากเกินไป / 483 Too many hops
- 484 Address ไม่ถูกต้อง / 484 Address incomplete
- 485 สับสน / 485 Ambiguous
- 486 สายไม่ว่าง / 486 Busy here
- 487 ยุติการร้องขอ / 487 Request terminated
- 488 ไม่ได้รับ / 488 Not acceptable here
- 489 เหตุการณ์ไม่ถูกต้อง / 489 Bad event
- 491 ยุติการร้องขอ / 491 Request pending
- 493 ไม่ถูกกฎ ไม่สามารถถอดรหัส S/MIME ได้ / 493 Undecipherable
- 494 ต้องการความปลอดภัย / 494 Security agreement required
5xx server มีปัญหา / ความผิดพลาดจากเครื่องแม่ข่าย
รหัสสถานภาพกลุ่มนี้หมายถึง "เครื่องแม่ข่ายไม่สามารถให้บริการได้ แม้ว่าการร้องขอจะส่งมาอย่างถูกต้อง" เครื่องให้บริการพบกับข้อผิดพลาดบางประการซึ่งทำให้ไม่สามารถทำตามการร้องขอที่ส่งมา เครื่องแม่ข่ายควรอธิบายสาเหตุของความผิดพลาดลงในส่วนเนื้อหาในข้อความตอบรับ และควรระบุว่าเป็นปัญหาที่เกิดขึ้นชั่วคราวหรือถาวร ยกเว้นเมื่อตอบกลับจากคำสั่ง HEAD นอกจากนั้นตัวผู้ใช้ควรแจ้งข้อผิดพลาดให้ผู้ใช้ทราบ รหัสกลุ่มนี้สามารถใช้ตอบรับกับคำสั่งใดก็ได้
ข้อความแสดงความผิดพลาดแบบทั่วไป ใช้เมื่อไม่มีข้อความเฉพาะที่เหมาะสมในการแจ้งสาเหตุ
- 501 ยังไม่เปิดใช้วิธีนี้ / 501 Not Implemented
เครื่องให้บริการไม่เข้าใจคำสั่งร้องขอ หรือไม่ได้มีความสามารถให้ทำงานตามคำสั่งนั้น
- 502 Gateway ไม่ถูกต้อง / 502 Bad Gateway
เครื่องแม่ข่ายกำลังทำหน้าที่เป็นเกตเวย์หรือพร็อกซี และได้รับข้อความตอบรับที่ผิดพลาดจากเครื่องให้บริการเบื้องหลัง
- 503 ไม่สามารถให้บริการได้ / 503 Service Unavailable
เครื่องแม่ข่ายยังไม่ให้บริการในปัจจุบัน อันเนื่องจากการใช้งานเกินพิกัดหรืออยู่ในระหว่างการบำรุงรักษา โดยปกติแล้วสถานภาพนี้จะเป็นอยู่เพียงชั่วคราว
- 504 หมดเวลาติดต่อ Server / 504 Gateway Timeout
เครื่องแม่ข่ายกำลังทำหน้าที่เป็นเกตเวย์หรือพร็อกซี และไม่ได้รับข้อความตอบรับจากเครื่องให้บริการเบื้องหลัง ซึ่งรอรับข้อมูลจนกระทั่งหมดเวลา
- 505 Server ไม่สนับสนุนโปรโคตอล SIP รุ่นนี้ / 505 HTTP Version Not Supported
เครื่องแม่ข่ายไม่รองรับรุ่นของเอชทีทีพีที่ใช้ในข้อความร้องขอ
- 513 ข้อความยาวเกินไป / 513 Message Too Large
6xx ความผิดพลาดทั่วไป / Global Failure Responses
- 600 ยุ่งตลอดเวลา / 600 Busy Everywhere
- 603 ไม่รับ / 603 Decline
- 604 ไม่อยู่ตลอดเวลา / 604 Does Not Exist Anywhere
- 606 ไม่ยอมรับ / 606 Not Acceptable
อื่น ๆ เช่น
- INFO ส่งข้อมูลโดยไม่แก้ไข Session State
- REFER ใช้กับ call transfer
- MESSAGE ข้อความที่ต้องการส่ง
- UPDATE ส่งข้อมูลเพื่อแก้ไข Session State แต่ไม่เปลี่ยนสถานะการทำงาน
ตัวอย่าง SIP Request
REGISTER sip:seberino@switch-2.nufone.net SIP/2.0
Via: SIP/2.0/UDP 66.159.194.51:5060
CSeq: 3363 REGISTER
To: sip:seberio@switch-2.nufone.net
Expires: 900
Call-ID: 401507385@66.159.194.51
User-Agent: Shtoom/0.3alpha0
Contact: <sip:seberino@66.159.194.51:5060>
Contact-Length: 0
Credit : http://www.narisa.com/forums/index.php?showtopic=17004&st=0
Credit : http://th.wikipedia.org/wiki/Session_Initiation_Protocol
http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
http://en.wikipedia.org/wiki/Signalling_System_7
http://en.wikipedia.org/wiki/SIP_Requests
http://www.softpanorama.org/Net/Transport_layer/index.shtml
http://mail.python.org/pipermail/shtoom/2005-January/000087.html
http://search.cpan.org/~sullr/Net-SIP-0.23/
----------------------------
ความรู้ที่ได้เพิ่มเติมค่ะ(บางส่วนจาก paper ที่เขียน)
SIP Architectural Component
ในการที่จะสร้าง session การสื่อสารระหว่าง SIP server กับ SIP client ให้สำเร็จได้นั้นจะต้องมีองค์ประกอบในการเชื่อมต่อให้ครบอย่างน้อย 4 อย่างคือ
1.SIP User Agents(UAs) : เป็นอุปกรณ์ที่ทำงานอยู่ฝั่ง end-users เช่น cell phone , multimedia handsets , PCs , PDAs เป็นต้น โดยจะใช้ทำหน้าที่ในการสร้างและจัดการ SIP sessions
2.SIP Registar Servers : เป็นฐานข้อมูลที่เก็บตำแหน่ง(location) ของ UAs ทั้งหมดที่อยู่ภายใน domain เดียวกัน โดยทำหน้าที่เป็นผู้ให้บริการในการค้นหาและจัดส่ง IP Address ที่ได้ขึ้นทะเบียนไว้ไปให้แก่ Proxy Server เมื่อมีการร้องขอมา
3.SIP Proxy Servers : ทำหน้าที่เป็นตัวกลางระหว่างการติดต่อสื่อสารระหว่าง client กับ server โดยเมื่อได้รับ request session มาจาก UA ก็จะทำการ query ไปยัง Registar Servers เพื่อทำการขอข้อมูลเกี่ยวกับ UA ปลายทางและทำการส่ง session invitation ไปยัง UA ปลายทางด้วยในกรณีที่อยู่ภายใน domain เดียวกัน ส่วนถ้าอยู่ต่าง domain นั้นก็จะทำการส่งต่อไปยัง Proxy Server ของ domain ปลายทางนั้นๆ ต่อไป
4.SIP Redirect Servers : ทำหน้าที่ในการเชื่อมต่อระหว่าง SIP Proxy Server กับ session invitation ที่อยู่นอกคนละ domain โดยทั่วไปจะอยู่บน hardware เดียวกันกับ SIP Registar Servers และ SIP Proxy Servers
SIP address
SIP address มีลักษณะคล้ายกับ Domain Name Service(DNS) ใน web ทั่วๆ ไป เพื่อใช้ในการระบุตัวตนผู้ใช้ ซึ่งคล้ายกับการทำงานของระบบ e-mail ทำให้ผู้ใช้ไม่จำเป็นต้องยึดติดอยู่กับตัวอุปกรณ์
ตัวอย่าง SIP URL
sip:user@reskit.com => Basic SIP URL.
sip:user@reskit.com;transport=TCP => Basic SIP URL with the transport protocol designation of TCP. If the transport protocol is not designated it defaults to UDP.
sip:user@172.16.20.54 => SIP URL with an IP address.
sip:+1-425-707-9796@reskit.com;user=phone => SIP URL with a global phone number.
sip:marketing@reskit.com;maddr=225.0.2.1;ttl=64 => SIP URL with a multicast address, which overrides the previously specified host name. The time-to-live (TTL) value is set to 64 (0-255). The TTL must be set when using a multicast address and UDP as the transport protocol.
Reference:
http://www.avaya.com
http://www.cs.columbia.edu/sip
http://www.dataconne...voip/dc-sip.htm
http://dmoz.org/Comp...t/Protocols/SIP
http://elwsc673.rsjp...panese/products
http://www.en.wikipedia.org
http://get.live.com/...senger/overview
http://www.itef.org
http://www.isoc.org/seinit/portal~
http://www.narisa.co...showtopic=17004
http://news.softpedi...port-with-Avaya
http://www.platcomm....ktopEdition.pdf
http://www.p2psip.org
http://sipcenter.com
http://www.tech-invite.com
=========================================
หลักการทำงาน
ในหัวข้อนี้จะกล่าวถึงการทำงานเบื้องต้นของ Protocol ที่ใช้ในการติดต่อสื่อสารตัวนี้ซึ่งจะแสดงตัวอย่างการติดต่อสื่อสารอย่างง่ายๆ ให้ได้ดูกันเป็นตัวอย่าง ในหัวข้อนี้จะบอกถึงลักษณะการติดต่อสื่อสารกันระหว่างการเชื่อมต่อที่ต่างกัน และจะไม่จำกัดในทุกกฏเกณฑ์
ตัวอย่างแรกจะแสดงพื้นฐานการทำงานแสดงสัญญาณของการเชื่อมต่อการเจรจาสนทนาระหว่างกันของข้อมูลที่เป็นไปตามกฏเกณฑ์ของการเชื่อมต่อ และการสิ้นสุดการเชื่อมต่อ
รูปที่ 1 จะแสดงตัวอย่างของการแลกเปลี่ยนข้อมูล SIP Message ระหว่างผู้ใช้งานทั้งสองฝั่ง ในตัวอย่างนี้ A จะใช้ SIP Application บน PC เพื่อเชื่อมต่อกับ B โดยติดต่อไปยัง SIP Phone ซึ่งต่อผ่านระบบ Internet ดังนั้นดังรูปจะแสดงสอง SIP proxy servers ซึ่งจะแสดงเป็นตัวแทนของ A กับ B เพื่อ สะดวก ในการร่วมสนทนา นี่เป็นตัวอย่างการจัดการที่จะใช้อ้างอิงการทำงานให้เห็นได้บ่อยๆ ดังแสดงในรูปที่ 1
A จะติดต่อกับ B โดยเรียกผ่านทาง SIP ID ของ B ในรูปแบบของ URI โดยการเรียกเข้าไปที่ SIP URI โดย URI คือกลุ่มแล้ว มีความเหมือนกันกับ email address เป็นแบบฉบับที่ประกอบด้วย username และ host ในส่วนของตัวอย่างนี้ ก็คือ sip:B@biloxi.com . biloxi.com คือ domain ของ B โดยถูกจัดการรูปแบบโดย SIP และ SIP URI ของ A คือ sip:A@atlanta.com บางที A อาจจะมีข้อมูลของ B โดย click ผ่าน hyper link หรือเลือกจากสมุดโทรศัพท์ SIP จะถูกจัดการอย่างปลอดภัยโดย URI. โดยจะถูกเรียกผ่าน URI ในตัวอย่างนี้มี sip:B@biloxi.com โดยมี URI รับประกันในเรื่องความปลอดภัย จะเข้ารหัสก่อนส่งข้อมูล โดยจะนำ SIP Message ส่งไปถึงผู้เรียก จากสิ่งนี้ การร้องขอจะมีความปลอดภัยจนถึงผู้เรียก แต่กลไกนี้จะขึ้นอยู่กับวิธีการของ domain ผู้เรียก
SIP จะถูกส่งรวมกับ HTTP ดังเช่นการร้องขอและการรับ ซึ่งเป็นไปตามรูปแบบของ HTTP ในแต่ละการดำเนินการร้องขอจะก่อให้เกิดเหตุการณ์ต่างๆ หรือกระบวนการต่างๆ บน server และการตอบกลับอย่างน้อยสุด หนึ่งการตอบกลับ ในการร้องขอการ INVITE ตำแหน่งถึง SIP URI ของ B, INVITE คือตัวอย่างเหตุการณ์ของ SIP มันถูกระบุเป็นคำสั่งของการร้องขอเมื่อ A ต้องการร้องขอไปยัง server เพื่อติดต่อกับ B การร้องขอโดย INVITE จะประกอบไปด้วยหมายเลขของ header โดย header ถือว่าเป็นชื่อและเป็นข้อมูลที่ถูกเพิ่มเติมเข้ามาในส่วนของข้อมูล การเกิด INVITE ขึ้นหนึ่งครั้งจะเป็นการรวมทุกอย่างเป็นหนึ่งเดียวเพื่อใช้ในการเรียกไปยังปลายทาง, ที่อยู่ของ A, และข้อมูลต่างๆ ที่เกี่ยวกับรูปแบบการเชื่อมโยงเพื่อให้เชื่อมต่อกับ B ได้สำเหร็จ ซึ่ง INVITE จะมีลักษณะการทำงานคล้ายดังรูปที่ 1 นี
รูปที่ 1 ตัวอย่างการเริ่ม SIP Session กับ SIP trapezoid
INVITE sip:B@biloxi.com SIP/2.0 =จะอยู่ใน header fields นี่คือตัวอย่างการร้องขอขั้นต่ำ ในส่วนของ header fields คือ ส่วนที่อยู่ภายใต้การบรรยายของ package
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds =ส่วนที่บอกว่าจะส่งข้อความนี้ไปยังที่ไหนดังตัวอย่าง pc33.atlanta.com
Max-Forwards: 70 =เป็นการระบุตัวเลขสูงสุดที่จะให้ผ่านถ้าเกินจากนี้ package จะ lose
To: B <sip:B@biloxi.com> =เป็นการระบุว่าจะติดต่อใคร
From: A <sip:A@atlanta.com>;tag=1928301774 =เป็นการระบุว่าจากใคร
Call-ID: a84b4c76e66710@pc33.atlanta.com =เป็นการบอกหมายเลขที่ใช้ในการสร้างคอนเน็คชันนี้
CSeq: 314159 INVITE =เป็นการบอกลำดับของเหตุการณ์นี้
Contact: <sip:A@pc33.atlanta.com> =เป็นการระบุ SIP หรือ SIP URI ที่แสดงให้เห็นเส้นทางโดยตรงถึงผู้ที่ติดต่อในตัวอย่างนี้ A คือผู้ติดต่อ
Content-Type: application/sdp =เป็นการรวบรวมในส่วนของข้อมูล (ไม่แสดง) / บ่งบอกถึงประเภทสื่อของตัวข้อความที่ส่งไปยังผู้รับ
Content-Length: 142 =จะเพิ่มขึ้นเมื่อมีเหตุการณ์เกิดขึ้นในแต่ละครั้ง
ทั้งหมดนี้อยู่ในส่วนของ SIP header fields ซึ่งได้ถูกกำหนดเอาไว้แล้ว
รายละเอียดของการเชื่อมต่อดังเช่นรูปแบบของข้อมูล, เสียง, ตัวอย่างการส่ง จะไม่ปรากฏภายใต้ SIP ถ้าจะให้ถูกต้อง ในส่วนของข้อมูล SIP จะต้องรวบรวมข้อมูลของการเชื่อมโยง, การถอดเอาข้อมูลของกฏการเชื่อมโยงในรูปแบบอื่นดังเช่นตัวอย่างรูปแบบของ Session Description Protocol (SDP) (RFC 2327) นี่คือข้อมูลของ SDP ไม่แสดงในตัวอย่าง โดยที่มันจะถูกส่งไปโดย SIP Message ในทางที่คล้ายกันกับการแทรกเอกสารไปใน email หรือการเริ่มต้นของ HTTP Message
การที่จะรู้ว่าการเชื่อมต่อสำเหร็จหรือว่าไม่มีข้อผิดพลาดเกิดขึ้นมานั้นจะได้รับการตอบกลับมาว่า 200 OK ดังตัวอย่างโดย B จะเป็นคนส่งข้อความนี้กลับมาให้ยัง A
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: B <sip:B@biloxi.com>;tag=a6c85cf
From: A <sipA@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:B@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
โครงสร้าง IP Protocol
รูปที่ 2 โครงสร้างของ IP Protocol
IP Header
- Version ขนาด 4 บิต : แสดงรุ่นของโปรโตคอล รุ่นที่ใช้งานขณะปัจจุบันมีค่า 4
- Internet Header Length (IHL) ขนาด 4 บิต : บอกความยาวเฉพาะเฮดเดอร์ของ datagram โดยนับจาก version จนถึงไบต์สุดท้ายก่อนที่จะถึงข้อมูล หน่วยนับความยาวจะบอกเป็นจำนวนเท่าของ 4 ไบต์ (หรือ 32 บิตเวิร์ด) หาก IHL มีค่าเท่ากับ 5 จะหมายถึงส่วนหัวมีขนาด 20 ไบต์ซึ่งเป็นค่าที่บอกว่าไม่มี options และ padding อยู่ในเดทาแกรม
- Type of Service (TOS) ขนาด 8 บ : ฟิลด์นี้ใช้กำหนดรูปแบบการให้บริการตามลักษณะโปรโตคอลแอพลิเคชัน
- Total length มีขนาด 16 บิต : บอกถึงความยาวทั้งหมด datagram (เฮดเดอร์และข้อมูล) โดยมีหน่วยนับเป็นไบต์ เนื่องจากฟิลด์นี้มีขนาด 169 บิต ไอพีดาตาแกรมจึงมีขนาดใหญ่สุดเท่ากับ 216 -1 หรือ 65,535 ไบต์
- Identification ขนาด 16 บิต
- Flags ขนาด 3 บิต
- Fragment offset ขนาด 13 บิต
- Time to live (TTL) ขนาด 8 บิต : ฟิลด์นี้ใช้กำหนดจำนวนเร้าเตอร์ที่ datagramจะเดินทางผ่านได้หรืออีนัยหนึ่งคือกำหนดอายุของ datagram ซึ่งมีค่าได้สูงสุดตามขนาดฟิลด์ คือ 28-1 หรือ 255 สถานีที่ส่ง datagram จะตั้งค่า TTL ไว้ที่ค่าใดค่าหนึ่ง เร้าเตอร์ที่รับ datagram จะปรับลดค่านี้ลงหนึ่งหน่วย หากลดลงเป็น 0 เร้าเตอร์จะทิ้ง datagramนั้นและรายงานกลับไปด้วย ICMP วิธีนี้ช่วยป้องกันปัญหา datagramวนรอบ (routing loop) สถานีต้นทางต้องเลือกใช้ค่านี้ให้เหมาะสม เนื่องจากมีค่าน้อยเกินไปจะทำให้ datagram เดินทางไปไม่ถึงปลายทาง หรือตั้งค่ามากเกินไปก็จะสร้างภาระให้ระบบเมื่อมีความผิดผกติด้านการเลือกเส้นทาง ค่าโดยปกติที่ใช้ คือ 64
- Protocol ขนาด 8 บิต : ฟิลด์บอกชนิดของโปรโตคอลระดับบนที่ encapsulation ใน datagram เพื่อให้สถานีปลายทางและสามารถส่งข้อมูลไปยังโปรโตคอลระดับบนได้ถูกต้องค่าที่ใช้ประจำโปรโตคอลมีดังนี้
ICMP
TCP
- Header checksum ขนาด 16 บิต : ใช้ตรวจสอบความผิดพลาดเฉพาะ header โดยไม่รวมส่วนข้อมูล การคำนวณผลรวมตรวจสอบจะเริ่มต้นด้วยการให้ฟิลด์ checksum มีค่าเป็น 0 จากนั้นจึงบวก Header ครั้งละ 16 บิตแบบ (1’s complement) เมื่อได้ผลลัพธ์แล้ว จะนำใส่ในฟิลด์ checksum IP ปลายทางเมื่อได้รับ datagram แล้วก็เพียงแต่บวก Header ทั้งหมดครั้งละ 16 บิตแบบ (1’s complement) หากค่าที่ได้ไม่เท่ากับ 0 แสดงว่ามีข้อผิดพลาดใน Header
- Source IP address ขนาด 32 บิต : กำหนด IP address ต้นทาง
- Destination IP address ขนาด 32 บิต : กำหนด IP address ปลายทาง
- Option ขนาดไม่คงที่ : ใช้สำหรับกำหนดข่าวสารเพิ่มเติมสำหรับ datagram ค่าที่ใช้ในปัจจุบันจะเกี่ยวข้องกับการรักษาความปลอดภัย และการบันทึกผลลัพธ์จาการทำงานของคำสั่ง traceroute หรือ ping
- Padding ขนาด 0 ถึง 3 ไบต์ : ใช้สำหรับผนวกเพิ่มเพื่อให้จำนวนไบต์ของ option รวมกับ padding เป็นจำนวนเท่าของ 32 บิต ค่าในฟิลด์ padding จึงไม่มีความสำคัญใด
- Data ขนาดไม่คงที่ : ข้อมูลจากโปรโตคอลระดับบน
SIP Messages
SIP messages คือการร้องขอข้อมูลจากทางฝั่งใดฝั่งหนึ่ง Server ร้องขอจาก Client หรือ Client ร้องขอจาก Server
ทั้งสองฝั่งสามารถร้องขอและตอบกลับได้โดยในการทำงานนั้นจะใช้รูปแบบในการจัดการดังนี้
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
start-line, แต่ละ header , บรรทัดว่าง ต้องปิดด้วย carriage-return line-feed sequence (CRLF) สุดท้ายบรรทัดเปล่าจะต้องมีถ้าไม่มีส่วนของ Body
อย่างไรก็ตาม SIP ไม่ใช่ส่วนขยายเพิ่มเติมของ HTTP
- Requests
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Methode คือ ส่วนที่เป็นการบ่งบอกถึงเหตุการณ์ว่า ณ ตอนนี้ต้องการร้องขออะไรซึ่งจะมีข้อมูลดังนี้ INVITE, ACK, และ CANCEL สำหรับยกเลิกการเชื่อมต่อ, BYE สำหรับหยุดการเชื่อมต่อ, และส่วนเพิ่มเติมสำหรับเรียกดูความสามารถในการจัดการและส่วนขยายเพิ่มเติมของ SIP ข้อมูลมาตรฐานบางทีอาจจะมีเพิ่มเหตุการณ์ได้
Request-URI คือ จะแสดงในส่วนของผู้ใช้งานหรือตำแหน่งผู้ที่ร้องขอ
SIP-Version คือ การระบุเวอร์ชันของ SIP
- Responses
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
SIP-Version คือ การระบุเวอร์ชันของ SIP
Status-Code คือ เลขจำนวนเต็มสามตัวที่ใช้แสดงผลลัพท์ของการติดต่อเพื่อให้เข้าใจร่วมกันว่าการติดต่อสำเหร็จหรือไม่สำเหร็จและมีปัญหาในส่วนไหนซึ่งจะมีดังต่อไปนี้
1xx: Provisional -- request received, continuing to process the request;
2xx: Success -- the action was successfully received, understood, and accepted;
3xx: Redirection -- further action needs to be taken in order to complete the request;
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently valid request;
6xx: Global Failure -- the request cannot be fulfilled at any server.
Reason-Phrase คือ ข้อความสั้นๆ ที่แจ้งให้ทราบว่าปัญหาที่เกิดขึ้นเพราะอะไร หรือว่าไม่พบปัญหา
การดำเนินการ
Credit : http://www.msit.mut.ac.th/newweb/phpfile/show.php?Qid=2865
Credit : http://www.mind-tek.net/sip.php
