ICS

ICS : IMS centralized services

นี้สามารถมองเห็นเป็นการเพิ่มประสิทธิภาพของข้อกำหนด VCC ด้วยการสนับสนุนของบริการเสริมใน ICS จุดมุ่งหมายที่จะให้การเข้าถึงบริการเดียวกันสิ่งที่เข้าถึงเครือข่ายที่ใช้ (CS หรือ PS) ด้วย ICS บริการทั้งหมดที่ให้บริการโดย IMS แอพพลิเคชันเซิร์ฟเวอร์และควบคุมโดย IMS บริการสถาปัตยกรรมควบคุม ดังนั้นผู้ใช้บริการลูกค้าจะได้รับประโยชน์จากการให้บริการใหม่ IMS ในขณะที่ยังคงใช้โดเมนสำหรับลูกค้าผู้ถือสื่อ ICS ถือว่าการประชุมผู้ถือ IMS กับลูกค้าอื่น ๆ เช่นเซสชั่นเต็มรูปแบบ IMS ด้วย ICS เซสชันของผู้ใช้ทั้งหมดจะถูกควบคุมโดยเครือข่ายหลักของ IMSสถาปัตยกรรม ICS อาจจะขึ้นอยู่กับการใช้งานของเซิร์ฟเวอร์ MSC เพิ่มขึ้นทำหน้าที่เป็นผู้ใช้ SIP ตัวแทนในนามของลูกค้า UE และทำให้การปรับตัวของการส่งสัญญาณระหว่างลูกค้าและ IMSSCC (รวบอำนาจการให้บริการและความต่อเนื่อง) AS เป็นผู้รับผิดชอบในการยึดเซสชันของผู้ใช้และการดำเนินการถ่ายโอนระหว่างลูกค้าและโดเมน PS

Credit : http://catis-blog.com/?p=227

Credit : https://conningtech.files.wordpress.com/2010/09/3gpp-ics-general-overview.pdf

Credit : http://mobilesociety.typepad.com/mobile_life/2008/08/ims-centralized-services-ics.html

Credit : https://www.safaribooksonline.com/library/view/voice-over-lte/9781119945765/9781119945765c06.xhtml

USCDB

USCDB : Unified Subscriber Center Database

          Unified Subscriber Center Database : ศูนย์รวมฐานข้อมูลลูกข่าย ช่วยจัดการข้อมูลลูกข่ายของผู้ให้บริการ อย่างไรก็ตาม การเจริญเติบโตอย่างรวดเร็วต้องให้ผู้ให้บริการปรับใช้ระบบการจัดการข้อมูลผู้ใช้บริการ ที่ประกอบด้วยคุณสมบัติดังต่อไปนี้

- ความน่าเชื่อถือสูง
- ความจุสูง
- รวบรวมการหลายแอพลิเคชั่นสูง

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

Credit : http://www.huawei.com/en/products/core-network/convergentdata/uscdb/index.htm

RCS

RCS : Rich Communication Suite

   การสร้างบริการแบบครบวงจรการสื่อสารจะช่วยให้การสื่อสารระหว่างผู้ใช้งานมีความสมบูรณ์ ยิ่งขึ้นบนพื้นฐานของ IP Multimedia Subsystem (IMS) การร่วมมือกับ Address Book, เสียง, วิดีโอ, แชท, ฯลฯ ที่จะเป็นไปได้ บริการที่สำคัญ ทั้งวิดีโอและภาพที่ใช้ร่วมกันใน 'Rich call', ข้อมูล เรียลไทม์ จากข้อมูลข้างเคียงอื่น ๆ ที่ปรากฏอยู่ใน “Rich address book” เลือกบุคคลหรือกลุ่มจาก address book และการถ่ายโอนไฟล์ใน ‘Rich messaging’ ฯลฯ

ไฟล์มัลติมีเดีย (รูปภาพ , ไฟล์วิดีโอ) สามารถใช้ร่วมกันในระหว่างการสนทนา ตัวอย่างเช่นใน ระหว่างการสนทนา ภาพสามารถถ่ายโดยกล้องโทรศัพท์และส่งไปยังด้านอื่น ๆ ในเวลาเดียวกัน

Credit : http://standard1.nbtc.go.th/getattachment/daf00528

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

        เป็นแพลตฟอร์มที่ช่วยให้การส่งมอบประสบการณ์การสื่อสารที่นอกเหนือจากเสียงและ SMS ให้ผู้บริโภคที่มีการส่งข้อความโต้ตอบแบบทันทีหรือการสนทนาวิดีโอสดและการแบ่งปันไฟล์ - ในอุปกรณ์ใน เครือข่าย RCS ใด ๆ เครื่องหมายการเปลี่ยนแปลงของการส่งข้อความและความสามารถด้านเสียงจากCS 2G/3G เทคโนโลยีใหม่ IP ทั้งหมด - และเป็นการใช้ระบบเหมือนกัน IMS และยกระดับความสามารถเดียวกัน IMS เป็น VoLTE และ Video call over LTE

Credit : http://www.gsma.com/network2020/rcs/
Credit : https://www.topdoggraphics.com/OtherSites/GSMA_RCS/chapter-1/ch1-p1.html

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

แอคซิชั่นจัดเก็บข้อมูล RCS บนระบบคลาวด์ ช่วยให้ผู้ให้บริการสามารถนำเสนอบริการรับ-ส่งข้อความที่หลากหลายได้โดยไม่ต้องติดตั้ง IMS Core วันที่ 27 ก.พ. 2556

รีดดิ้ง, อังกฤษ--26 ก.พ.--พีอาร์นิวส์ไวร์/อินโฟเควสท์ แอคซิชั่น (Acision) ผู้นำระดับโลกด้านการรับ-ส่งข้อความผ่านโทรศัพท์มือถือ ประกาศเปิดให้บริการ Rich Communication Suite (RCS) ชั้นนำของบริษัท ซึ่งเป็นโซลูชั่นบน Acision Cloud ที่ได้เปิดตัวครั้งแรกไปเมื่อเดือนตุลาคม 2554 และเป็นโมเดลที่ช่วยให้ผู้ให้บริการโทรศัพท์มือถือสามารถตอบโจทย์ด้านพัฒนาการทางเทคโนโลยีและความชื่นชอบของผู้ใช้งานที่เปลี่ยนแปลงไปตลอดเวลาได้อย่างรวดเร็วและประหยัดต้นทุน ด้วยความสามารถในการเข้าถึงและนำเสนอบริการใหม่ที่หลากหลายให้กับลูกค้าในขณะเดียวกันก็เพิ่มศักยภาพในการทำกำไรได้ในระดับสูงสุด การนำเสนอ RCS บนระบบคลาวด์ของแอคซิชั่นช่วยให้ผู้ให้บริการสามารถเปิดตัว Rich Messaging ได้อย่างรวดเร็วและด้วยต้นทุนที่มีอยู่อย่างจำกัด โดยไม่จำเป็นต้องติดตั้ง MIS Core ซึ่งนับตั้งแต่การเริ่มต้นในปี 2555 RCS ได้ถูกนำเสนอให้เป็นแพลตฟอร์มการให้บริการแบบครบวงจรที่สำคัญของแอคซิชั่นในชื่อ Acision Broadband Messaging Service Center (BMSC) ในปัจจุบัน ซึ่งมีการพุ่งเป้าความสนใจไปที่ไอพีนั้น การเปิดตัวในตลาดและการเพิ่มประสบการณ์ให้กับผู้ใช้บริการถือเป็นสิ่งที่สำคัญอย่างยิ่งยวด ผู้ให้บริการโทรศัพท์มือถือทั่วโลกกำลังลงทุนไปกับบริการที่หลากหลายและดีกว่าเพื่อเพิ่มประสบการณ์ให้กับผู้ใช้บริการบนแพลตฟอร์มต่างๆ เช่น IP Multimedia Subsystem (IMS) ซึ่งมีต้นทุนสูงและมีโครงสร้างที่ซับซ้อนในการติดตั้ง และด้วยการนำเสนอให้ผู้ให้บริการโทรศัพท์มือถือสามารถเข้าถึงโซลูชั่น RCS บนระบบคลาวด์ของแอคซิชั่นได้อย่างสะดวก ผู้ให้บริการสามารถเปิดตัวบริการที่หลากหลายในตลาดได้เร็วขึ้นด้วยการเชื่อมต่ออย่างง่ายดายและยืดหยุ่น ดังต่อไปนี้: - RCS5 ซึ่งครอบคลุมการเชื่อมโยงระหว่างเครือข่าย SMS และ MMS - การผนึกรวมสังคมออนไลน์ - การกระตุ้นการให้บริการลูกค้า - API แบบเปิดสำหรับคอนเทนท์และบริการสำหรับองค์กร ทั้งหมดเหล่านี้เป็นพื้นฐานสำหรับการสร้างรายได้ใหม่ๆผ่านการสร้างมูลค่าเพิ่มให้กับบริการของผู้บริโภคและแอพพลิเคชั่นขององค์กร "แอคซิชั่นนำเสนอทางเลือกและโมเดลธุรกิจที่มีความยืดหยุ่นสูงบน RCS สำหรับผู้ให้บริการที่ต้องการการนำเสนอภายในเครือข่าย เราสามารถติดตั้งฮาร์ดแวร์อิสระสำหรับโซลูชั่น RCS บนฮาร์ดแวร์ลูกค้าที่ทำเพื่อระบบนี้โดยเฉพาะ หรือบนคลาวด์ส่วนตัวของผู้ให้บริการ สำหรับผู้ให้บริการที่ต้องการเปิดตัวในตลาดโดยใช้เวลาและการลงทุนน้อยที่สุด รวมทั้งให้บริการ RCD ได้โดยที่ไม่ต้องติดตั้ง IMS Core เราสามารถนำเสนอ RCS ในฐานะบริการจากระบบคลาวด์ของแอคซิชั่น ซึ่งเป็นทางเลือกที่รวดเร็ว ง่าย และประหยัดต้นทุนในการนำเสนอ RCS โดยที่ไม่ต้องเพิ่มระบบ IMS ที่ซับซ้อน” จอร์เกน นิลส์สัน ประธานเจ้าหน้าที่บริหารของแอคซิชั่นกล่าว "การพัฒนาโซลูชั่นเสมือนจริงของเราช่วยให้ผู้ให้บริการสามารถเข้าถึงและติดตั้งบริการล่าสุดที่มีความหลากหลาย ตลอดทั้งขยายบริการได้อย่างง่ายดายโดยไม่ต้องใช้เงินลงทุนในการติดตั้งสูง อีกทั้งยังช่วยให้มีธุรกิจขยายตัวอย่างทั่วถึงทั้งกลุ่มผู้ให้บริการและพันธมิตร RCS บนระบบคลาวด์เพิ่มศักยภาพในการนำเสนอบริการรับส่งข้อความผ่านไอพีในปี 2556 ได้อย่างรวดเร็ว จากความเชี่ยวชาญกว่า 20 ปีของเราในเรื่องการรับ-ส่งข้อความและพัฒนาการของระบบการรับ-ส่งข้อความ” ผู้ให้บริการสามารถเข้าถึงโซลูชั่น RCS หรือการนำเสนอผ่านระบบเสมือนจริงของแอคซิชั่นจากเกือบทุกที่ทั่วโลกได้แล้ววันนี้ ศูนย์ข้อมูลของแอคซิชั่นจะนำเสนอการเชื่อมต่อที่สามารถขยายขนาดและการเชื่อมต่อที่ไว้ใจได้ไม่ว่าจะเป็นไซท์ภายในประเทศและต่างประเทศได้หลายแห่งพร้อมกันผ่านโครงข่ายไฟเบอร์และเคเบิ้ลใต้น้ำ ทั้งนี้เพื่อที่จะรับประกันว่า ผู้ให้บริการสามารถใช้ข้อได้เปรียบจาการสร้างรายได้ได้อย่างง่ายดายจากบริการรับ-ส่งข้อความที่มีประสิทธิภาพด้านต้นทุนและแบนด์วิธ นอกจากนี้ ศูนย์ข้อมูลยังสนับสนุนลูกค้าตลอด 24 ชั่วโมงที่มาพร้อมกับ KPI และบริการรายงานแบบครบวงจรที่ชาญฉลาดของแอคซิชั่น เพื่อทดสอบและประเมินผลบริการที่นำเสนอบนระบบคลาวด์ หมายเหตุบรรณาธิการ เกี่ยวกับ แอคซิชั่น แอคซิชั่น บริษัทผู้นำระดับโลกด้านบริการรับ-ส่งข้อความผ่านมือถือ ให้บริการรับ-ส่งข้อความแบบไร้รอยต่อ และมีประสิทธิภาพทั่วโลก ซึ่งช่วยเพิ่มประสิทธิภาพให้กับการติดต่อสื่อสารผ่านทางโทรศัพท์มือถือ และสร้างโอกาสใหม่ๆให้กับผู้ประกอบการ และบริษัทต่างๆทั่วโลก สำหรับข้อมูลเพิ่มเติมเกี่ยวกับแอคซิชั่น กรุณาเข้าไปที่เว็บไซต์ http://www.acision.com เกี่ยวกับศูนย์บริการรับ-ส่งข้อความบรอดแบนด์ของแอคซิชั่น ศูนย์บริการรับ-ส่งข้อความบรอดแบนด์ของแอคซิชั่น (BMSC) เป็นแพลตฟอร์มรับ-ส่งข้อความที่มีประสิทธิภาพ ซึ่งผสมผสานความสามารถในการรับ-ส่งข้อความในปัจจุบันเข้ากับเทคโนโลยีแห่งอนาคต เพื่อให้บริการติดต่อสื่อสารที่ใช้งานง่ายอย่างเต็มรูปแบบผ่านวิธีการที่ได้รับการปรับปรุงให้ดีขึ้น BMSC ของแอคซิชั่น ซึ่งทำงานร่วมกับทุกเครือข่ายตั้งแต่ 2G ไปจนถึง LTE ให้บริการรับ-ส่งข้อความเต็มรูปแบบ ประกอบด้วย SMS, MMS, ข้อความเสียง และบริการภายใต้ RCS ของ GSMA เช่น อินสแตนท์เมสเสจจิ้ง, การสนทนาแบบกลุ่ม, การส่งไฟล์ข้อมูล และการแบ่งปันวิดีโอ ในฐานะที่เป็นมูลค่าเสริมที่โดดเด่นให้แก่ผู้ให้บริการ BMSC ของแอคซิชั่นจึงทำงานภายใต้มาตรฐาน RCS โดยให้การบริการรับส่งข้อความที่เหมาะสมแก่ผู้ใช้งาน ได้แก่ - บุคคลที่ 3 และกิจการต่างๆจะได้รับผลประโยชน์จากบริการรับส่งข้อความที่ครบครันซึ่งใช้ความสามารถของ RCS ในการเพิ่มประสิทธิภาพบริการ SMS / MMS ดังเช่นที่เรารู้จักกันทุกวันนี้ - เพิ่มมูลค่าบริการส่วนบุคคล (การโต้ตอบอัตโนมัติ, การคัดลอกส่งต่อ, การควบคุม) ที่ใช้งานร่วมกับ SMS, MMS และ RCS - ทำงานร่วมกับโซเชียลเน็ตเวิร์ค และแอพพลิเคชั่นรับส่งข้อความผ่านทางอินเทอร์เน็ต และโทรศัพท์มือถือได้อย่างราบรื่น แหล่งข่าว: แอคซิชั่น Credit : http://www.prd.go.th/ewt_news.php?nid=44358 ---------------------------------- Introduction to RCS Market Opportunity Rich Communications Suite RCS) - Reports Corner

MMTel

MMTel : Multimedia Telephony Services

MMTel ให้บริการโทรศัพท์มัลติมีเดียขั้นพื้นฐานและลริการเสริม ไม่มีอีกต่อไปแนวคิดโทรศัพท์แบบดั้งเดิม แต่ด้วยแนวคิดใหม่ของบริการ หลายสื่อส่งไปยังที่ใดก็ได้ ในช่วงเวลาเดียวกันในเครือข่ายต่างๆ บนอุปกรณ์ต่างๆ โดยสื่อ Multimedia มีการทำโรมมิ่งข้อมูลต่างๆ ระบบ LTE และระบบ 2G/3G โดยใช้ IMS เป็นพื้นฐานเทคนิคการทำงาน

นิยามใหม่ของวิธีที่ผู้คนสื่อสารกับรูปแบบหารสื่อสารแบบอื่น ๆ
- จากเดิมที่สื่อสารแค่ " พูดคุย <> พูดคุย "  เปลี่ยนเป็น " สื่อสารต่างๆ <> สื่อสารต่างๆ "
- จากเดิม "ไม่เป็นที่รู้จักกันไม่ปรากฏตัว" เป็น "เปิดเผยแสดงตัวตน"

MMTel มีความสามารถต่างๆ ซึ่งทุกอย่างถูกรวมในโทรศัพท์มือถือของเรา สะดวกสบายในการพกพาไปในที่ต่างๆ แล้วยังติดกับอุปกรณ์ต่างๆ คอมฯ แท็ปแล็ต เป็นต้น
- การพิมพ์ข้อความโต้ตอบ
- การสนทนาพูดคุย
- การวีดีโอคอล
- โอนถ่ายข้อมูล ภาพ วีดีโอคลิป ไฟล์ข้อมูล

Cerdit : https://conningtech.files.wordpress.com/2010/09/3gpp-mmtel-general-overview.pdf
Cerdit : http://www.slideshare.net/amsboaventura/lte-latin-america

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

Ericsson Multimedia Telephony, MMtel

MRF

MRF : Multimedia Resource Function

เป็นอุปกรณ์ที่ใช้งานภายในเครือข่ายเท่านั้น โดยจะทำหน้าที่ให้บริการด้านมีเดียต่าง ๆ ภายใน เช่น Announcement ต่าง ๆ , การให้สัญญาณโทนเสียงต่าง ๆ , การเป็นตัวกลาง Telephone Conference รวมถึงการแปลงข้อมูลเสียงที่เข้ารหัสแบบหนึ่งให้เป็นรหัสเสียงอีกแบบหนึ่ง

    ส่วนประกอบของ MRF ได้แก่ MRFC (Multimedia Resource Function Controller) ซึ่งจะเป็นตัวประมวลผลและติดต่อสื่อสารกับ S-CSCF ผ่าน MR Interface และ MRFP (Multimedia Resource Function Processor) ที่จะทำหน้าที่แลกเปลี่ยนข้อมูลสัญญาณเสียง โดยได้รับการควบคุมผ่าน H.248 จาก MRFC

Credit : http://www.mvt.co.th

CSFB

CSFB : Circuit Switched fallback // CS Fallback

    Circuit Switch Fall Back (CSFB) คือ ถ้าจะคุยเสียงก็สั่งการให้โทรศัพท์มือถือ switch กลับไปใช้โครงข่าย 2G/3G แบบเก่าไป โดยยุค 2G/3G นั้น เมื่อผู้ใช้ต้องการโทรศัพท์หรือส่ง SMS หาผู้รับนั้น สัญญาณเสียงจะเดินทางผ่านระบบโครงข่ายสัญญาณเรียกว่า circuit switch แต่เจ้าระบบ LTE อันใหม่นี้กลับไม่รองรับ circuit switch เพราะมันเป็นระบบ packet switch แบบเพียวๆ ไม่ผสม ดังนั้นหากผู้ให้บริการโครงข่ายฯ อยากลงทุนระบบ LTE เพื่อให้บริการ high speed Internet แล้ว ก็ต้องมองหาแผนสำหรับรองรับการใช้งานโทรศัพท์แบบธรรมดาๆ เหมือนยุค 2G/3G ด้วย

Credit : https://www.facebook.com/impoaround/posts/188498607999306

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

LTE เป็นระบบที่สนับสนุนการใช้งานข้อมูลความเร็วสูงผ่าน PS(Packet Switch) Core Network ล้วนๆ ซึ่ง ณ ขณะปัจจุบัน LTE Network ที่ใช้กันอยู่ ก็จะอยู่บนมาตรฐานของ 3GPP Rel8 หรือ Rel9 เป็นส่วนใหญ่

ซึ่งโทรศัพท์มือถือที่มีออกมารองรับตัวอย่างเช่น Samsung Galaxy SII ในบางประเทศที่มีระบบ LTE แล้ว เจ้าโทรศัพท์รุ่นนี้ก็จะรองรับ LTE ด้วย

ปัญหามันก็คือ มันไม่ใช่ Aircard ที่ใช้งานดาต้าเพียงอย่างเดียว มันมีการใช้งานด้านเสียงเข้ามาเกี่ยวข้องด้วย ซึ่งระบบ LTE ที่เป็นอยู่ในตอนนี้ ก็จะมี EPC (Evolved Packet Core Network) เท่านั้นเป็นตัวควบคุม แต่การใช้งานด้านเสียงส่วนใหญ่ในวันนี้ ยังอยู่บน CS (Circuit Switch) Core

การแก้ปัญหาในขั้นต้นของระบบ LTE ก็จะทำโดยกระบวนการที่เรียกว่า CSFB (Circuit Swith Fall Back) คือ ตัดระบบเรดิโอบน LTE ไปก่อน แล้วทำการต่อสัญญาณใหม่บนระบบเดิมอย่าง 2G หรือ 3G อัตโนมัติ ซึ่ง User Experience จะสามารถรู้สึกได้ถึงการดีเลย์

ใน 3GPP Rel10 และหลังจากนี้ ซึ่งน่าจะมีการใช้งานอย่างเต็มรูปแบบช่วงปลายปี 2012 นี้เป็นต้นไป ก็จะมีระบบสนับสนุนเข้ามาใหม่อย่าง IMS (IP Multimedia Subsystem) ที่สามารถ map protocol ของ CS voice call ลงบน PS ได้ ทำให้การดีเลย์นั้น แทบจะไม่รู้สึก และไม่ต้องเปลือง Signaling ในการตัดต่อสัญญาณออกไปได้อีกด้วย โดยเจ้า IMS นี้ จะสามารถทำการ Anchoring call (เหมือนการ Handover ปกติ บน 2G/3G) ของเราบน LTE ลงไปบน CS Core Network ของ 2G/3G ได้เลย รวมถึงเวลาที่โทรศัพท์มือถือเคลื่อนออกจากพื้นที่ที่มีสัญญาณ LTE ก็จะทำการ Handover ลงไปยังระบบ 2G/3G ได้อย่างปกติอีกด้วย (ณ ปัจจุบัน ยังต้องพึ่งพา CSFB เพื่อลง 2G/3G ในการเริ่มต้น Voice Call อย่างเดียว Voice Call + Data ไม่สามารถอยู่บน LTE ได้)

*** จริงๆ IMS มีการเปิดตัวมาตั้งแต่สมัย Rel5 ที่เริ่มมี HSDPA แล้วแหละ เพียงแต่มันจะทำงานได้อย่างยอดเยี่ยม กับ Voice Call บน LTE โดยเฉพาะ Feature ที่มีเพิ่มมาใน Rel10 เหมือนเป็นเทวดามาโปรดยังงัยยังงั้น :)

แล้วทำไมต้อง Rel10?

ใน 3GPP Rel10 นี้ จะมีหนึ่งฟังก์ชั่นที่เข้ามาช่วยในการทำหน้าที่ นั่นก็คือ Single Radio Voice Call Continuity – SRVCC (Enhancement) ที่จะมาทำให้ Inter-RAT Handover จาก LTE สู่ระบบเดิมอย่าง 2G/3G เป็นได้อย่างดียิ่งขึ้นนั่นเอง

  

ปล. ไม่เคยแงะ Samsung Galaxy SIII มาดู Qualcomm Shipset ข้างในแฮะ แต่ถ้าเจอชิพ MDM9600 ก็คุ้มที่จะซื้อกัน เพราะว่าซัพพอร์ต Rel10 เรียบร้อย

Credit : http://mahalarp.com/2012/05/29/voice-over-lte-voims-srvcc
Credit : http://www.lte-tdd.org

MGCF

MGCF : Media Gateway Control Function

MGCF ทำงานเพื่อให้มีการแปลงการเข้ารหัสระบบ IP เป็น PCM ที่ใช้ในเครือข่ายยุคเก่าที่เป็นโทรศัพท์พื้นฐานและเชื่อมต่อกันกับโครงข่ายยุคใหม่LTE
และที่ทำหน้าที่เป็นสมองหลักของส่วน Media Gateway จะคอยดูด้าน Signaling ในการติดต่อ ทำหน้าที่แปลงโปรโตคอล SIP ให้เป็น ISUP ภายในเครือข่าย PSTN

Credit : http://www.mvt.co.th/viewarticle.php?cid=3&nid=128&page=2

FMC

FMC : fixed mobile convergence

จากความนิยมในโปรโตคอล IP ที่ถือกำเนิดจากอินเทอร์เน็ตที่เติบโตขึ้นอย่างมาก ทำให้เทคโนโลยีการสื่อสารในปัจจุบันเน้นการสื่อสารด้วยโปรโตคอล IP กันมากขึ้น และทำให้เกิดความคิดที่จะรวบรวมบริการต่าง ๆ ทั้งของเครือข่ายไร้สายและเครือข่ายมีสายเข้ามาอยู่ด้วยกัน ทั้งนี้เพื่อให้ลูกค้าของเครือข่ายทั้งสองชนิดจะเข้ามาใช้ได้ นั่นก็คือ คอนเซ็ปต์ของ FMC (Fixed Mobile Convergence) นั่นเอง

Credit : http://www.mvt.co.th/viewarticle.php?cid=3&nid=128&page=2

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

FMC หรือ Fixed Mobile Convergence คือการนำเอาระบบเครือข่ายโทรศัพท์มือถือกับโทรศัพท์พื้นฐานที่ใช้ตามบ้านหรือสำนักงานมารวมกันเป็นหนึ่งเดียว ซึ่งรวมถึงระบบโทรศัพท์อินเตอร์เน็ตหรือ IP Phone ด้วย ทำให้ผู้ใช้บริการสามารถสื่อสารได้หลายช่องทางบนโทรศัพท์มือถือเครื่องเดียว

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

ประโยชน์ที่จะได้รับจากเทคโนโลยี FMC

FMC ครอบคลุมการใช้งานร่วมกับระบบโทรศัพท์อินเตอร์เน็ตหรือ IP Phone หากโทรศัพท์มือถือของคุณรองรับเครือข่าย Wi-Fi และมีเทคโนโลยี FMC คุณสามารถเลือกที่ติดต่อไปหาเพื่อนผ่านระบบ IP Phone ได้ เพราะการสื่อสารผ่านโทรศัพท์อินเตอร์เน็ตไม่มีการเรียกเก็บค่าบริการ หรือ เรียกเก็บในอัตราที่ถูกกว่าค่าบริการโทรศัพท์มือถือ (ค่าบริการขึ้นอยู่กับผู้ให้บริการในแต่ละประเทศ) หรือผู้ใช้งานอาจจะติดต่อสื่อสารผ่านระบบโทรศัพท์พื้นฐานก็ได้ เพราะโทรศัพท์พื้นฐานมีข้อจำกัดด้านอุปกรณ์ที่ต้องวางอยู่กับที่ หรือถ้าเป็นแบบไร้สายก็อยู่ในรัศมีภายในบ้านเท่านั้น แต่ถ้าใช้โทรศัพท์มือถือที่มีเทคโนโลยี FMC ผู้ใช้งานสามารถติดต่อสื่อสารกับเพื่อนๆ ผ่านโครงข่ายพื้นฐานได้โดยไม่จำเป็นต้องใช้โทรศัพท์บ้านทำให้ข้อจำกัดเรื่องสถานที่การใช้งานหมดไป เทคโนโลยี FMC จึงเอื้อประโยชน์ให้กับผู้ใช้บริการได้มาก โดยเฉพาะค่าบริการโทรศัพท์ และ ความสะดวกสบาย

โทรศัพท์มือถือ LG LU4500 ติดตั้งเทคโนโลยี FMC มาให้ในตัว

เทคโนโลยี FMC ถูกนำไปใช้อย่างแพร่หลายในต่างประเทศ สำหรับประเทศไทยก็มีการนำมาใช้เช่นกัน เริ่มให้บริการตั้งแต่ปี พ.ศ. 2549 เกิดจากความร่วมมือกันของเอไอเอส, โนเกีย และ อวาย่า โดยโนเกียมีความพร้อมด้านอุปกรณ์การสื่อสารหรือโทรศัพท์มือถือ เอไอเอสมีความพร้อมด้านเครือข่าย อวาย่าเป็นผู้เชี่ยวชาญในการพัฒนาแอพลิเคชั่นเข้าไปใส่ในโทรศัพท์มือถือโนเกีย ที่รองรับระบบปฏิบัติการ Symbian S60 และเอไอเอสก็นำเทคโนโลยี FMC มาให้ลูกค้าได้ใช้บริการด้วยโซลูชั่น Enterprise Fixed Mobile Convergence โดยเจาะกลุ่มลูกค้าประเภทองค์กร ให้พนักงานในองค์กรสามารถใช้งานคุณสมบัติ และฟังก์ชั่นโทรศัพท์ของระบบโทรศัพท์ พื้นฐานได้สะดวกไม่ว่าจะอยู่ที่ใด โดยใช้โทรศัพท์มือถือหรือหมายเลขโทรศัพท์เพียงหมายเลขเดียว

Credit : http://news.siamphone.com/news-02906.html

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

Fixed Mobile Convergence 1 บทความที่เขียนลง นสพ Telecom&Innovation Journal

Fixed Mobile Convergence (FMC) ตอนที่ 1

Fixed Mobile Convergence หรือ เรียกย่อๆว่า FMC คือการรวมกันของเทคโนโลยีด้านการสื่อสารในปัจจุบันคือการสื่อสารไร้สาย (Wireless) และการสื่อสารแบบมีสาย (Wireline) อันเป็นผลสืบเนื่องมาจากการหลอมรวมของเทคโนโลยี (Technology Convergence) การหลอมรวมของเทคโนโลยีถือเป็นหนึ่งในห้าบริบทของการหลอมรวม (Convergence) ซึ่งมีอยู่ด้วยกัน 5 ประเภทคือ
1. Technology Convergence
2. Functional Convergence
3. Economical Convergence
4. Geographical Convergence
5. Political Convergence
แต่การหลอมรวมที่มีผลกระทบกับเรามากที่สุดและในขณะเดียวกันก็ก่อให้เกิดการหลอมรวมอื่นคือ Technology Convergence ความหมายที่แท้จริงของ Technology Convergence คือ Single Carrier หรือการร่วมกันใช้ช่องสัญญาณเดียวกันในทุกเทคโนโลยีและประเภทของข้อมูล ส่งผลให้เกิดผลกระทบต่อการออกแบบอุปกรณ์ที่สามารถรองรับบริการได้หลากหลายและเป็นที่มาของ Functional Convergence ที่หมายถึงการออกแบบอุปกรณ์ที่มีความสามารถในการรวมการทำงานที่หลากหลายไว้ในอุปกรณ์เดียวเช่น โทรศัพท์มือถือที่เป็นได้ทั้ง โทรศัพท์ วิทยุ กล้องถ่ายรูปและอื่นๆ เป็นต้น ส่วน Economical Convergence คือการหลอมรวมทางเศรษฐศาสตร์ Geographical Convergence คือการหลอมรวมทางภูมิศาสตร์และ Political Convergence คือการหลอมรวมทางนโยบาย โดยทั้งสามนี้เกิดขึ้นได้จากการหลอมรวมของเทคโนโลยีเป็นจุดเริ่มต้นเพราะการหลอมรวมทางเทคโนโลยีเริ่มต้นและส่งผลโดยตรงกับเทคโนโลยีการสื่อสาร ดังนั้นเมื่อวิวัฒนาการของการสื่อสารเกิดการเปลี่ยนแปลงทำให้โลกติดต่อสื่อสารได้แบบไร้พรมแดน (Geographical Convergence) การสร้างข้อกำหนดร่วม (Political Convergence) ของแต่ละภูมิภาคจึงถูกกำหนดขึ้นเพื่อให้การติดต่อสื่อสารมีมาตรฐานเดียวกันและทำให้รูปแบบการดำเนินธุรกิจเปลี่ยนรูปแบบไปจากเดิมและมีความรวดเร็วมากขึ้น (Economical Convergence)
FMC เป็นผลมาจากความต้องการใช้ Carrier ร่วมของเทคโนโลยีการสื่อสารทั้งสองชนิดและเป็นแนวคิดของระบบ Next Generation Network (NGN) ที่เราพูดถึงกันในปัจจุบัน FMC มีการดำเนินการกันในหลายประเทศที่พัฒนาการด้านเทคโนโลยีการสื่อสารสามารถรองรับการให้บริการแบบสื่อสารความเร็วสูงได้ เช่น ญี่ปุ่น อเมริกา เกาหลี อังกฤษ เป็นต้น และยังเป็นรูปแบบธุรกิจที่ผู้ให้บริการด้านโทรคมนาคมเดิม (Incumbent Operators) ใช้เป็นแนวทางในการดำเนินธุรกิจ เนื่องจากการให้บริการแบบเดิมของ Operators ต่างๆในอดีตจะเน้นการให้บริการบนโครงข่ายเดิม (Legacy) เพราะเป็นสิ่งที่ลงทุนไปแล้ว (Sunk Cost) และโดยมากจะเป็นโครงข่ายแบบมีสาย FMC จึงเป็นเหมือนความหวังของการดำเนินธุรกิจของ Operators เหล่านี้ ตัวอย่างของ FMC เช่น ระบบ IP Multimedia Subsystem (IMS) สำหรับในประเทศไทยบริษัท กสท.โทรคมนาคม จำกัด (มหาชน) เป็นหน่วยงานที่มีการประมูลและติดตั้งระบบนี้และยังมี กฟภ.อีกหนึ่งหน่วยงานที่เห็นมีการเปิดประมูลและยังอยู่ระหว่างดำเนินการ และล้วนแล้วแต่เป็นองค์กรที่มีโครงข่ายใยแก้วนำแสงเป็นโครงข่ายโทรคมนาคมหลัก

FMC คือการรวมบริการด้านโทรคมนาคมและการสื่อสารบน Fixed line และ Wireless เข้าด้วยกัน ในมุมของการให้บริการหรือในมุมมองด้านการตลาดและผลิตภัณฑ์คือการ Synergy สินค้าหรือบริการเข้าด้วยกันซึ่งเกิดขึ้นจากการที่เทคโนโลยีเกิดการหลอมรวม FMC โดยส่วนใหญ่จะเกิดจากความพยายามของ Incumbent Operators ที่ให้บริการโทรศัพท์พื้นฐาน รวมถึงบริการที่เกี่ยวเนื่องต่างๆเนื่องจากตลาดด้านนี้มีแนวโน้มลดลงทั้งจำนวนผู้ใช้บริการและรายได้เฉลี่ยต่อหัว (Average Revenue Per Unit: ARPU) ผู้ให้บริการเดิมเหล่านี้จึงพยายามที่จะสร้างตลาดใหม่ตามกระแสของเทคโนโลยีไร้สายที่เกิดขึ้นอย่างรวดเร็ว ภาพของการสร้างบริการที่ควบรวมทั้งมีสายและไร้สายจึงชัดเจนขึ้นอย่างมาก FMC มีการพูดถึงกันมานานไม่ต่ำกว่าสิบปี แต่เริ่มชัดเจนขึ้นเมื่อ ARPU ลดลงอย่างมากแต่ความพยายามในตอนแรกจะเป็นความพยายามจากฟากของ ผู้ให้บริการโทรศัพท์พื้นฐานเป็นส่วนใหญ่ แต่ปัจจุบัน ARPU ของผู้ให้บริการไร้สายเริ่มลดลงตลอดจนข้อจำกัดด้านนโยบายของประเทศด้าน ICT ส่งผลให้ผู้ให้บริการแบบไร้สายเริ่มหันมาสนใจ FMC มากขึ้น ในประเทศไทยการให้บริการFMC ที่เห็นชัดเจนคือการให้บริการ Data Roaming ของผู้ประกอบการบางรายที่ให้ลูกค้า 3G สามารถ Roaming มาใช้ Wi-Fi ได้ ดังเช่นกรณีของAIS กับ 3BB ที่เปิดบริการ Data Roaming นับว่าเป็นการเดินธุรกิจแบบ win-win และเป็นการให้บริการลักษณะแบบ FMC ที่มีสองบริษัทดำเนินการร่วมกัน นอกจากนี้ยังมีบริการอีกลักษณะที่เรียกว่า Synergy คือการรวมบริการหลายอย่างเข้าเป็น Package เช่น ใช้บริการ Cable TV แล้วได้เครดิตการใช้โทรศัพท์เป็นต้น ลักษณะแบบนี้ไม่ใช่ FMC แต่เป็นการรวมบริการเพื่อหวังผลด้านการตลาดและรายได้ หรือต้องการกระตุ้นบริการบางอย่างให้มีการใช้งานหรือให้ผู้ใช้บริการได้มีโอกาสใช้และเกิดความเคยชินและใช้ต่อไป ดังนั้น FMC จึงเป็นมุมมองทางเทคนิคอันเกิดจากการหลอมรวมของเทคโนโลยี แต่ Synergy คือการรวมกันของบริการเพื่อผลทางการตลาด

Credit : http://allaboutict.blogspot.com/2011/07/fixed-mobile-convergence

BGCF

BGCF : Breakout Gateway Control Function

   BGCF เป็น SIP proxy ส่วนนี้เป็นส่วนเชื่อมโยงโครงข่ายยุคเก่าเข้ามาใน IMS โดยเชื่อมโยงกับเครือข่ายยุคเก่าที่เป็นโทรศัพท์พื้นฐานหรือโครงข่ายที่ไม่มี IMS โดย BGCF จะได้รับการควบคุมจาก S-CSCF มาอีกทีหนึ่ง โดยจะวิเคราะห์เลขหมายปลายทางว่าเป็นเครือข่ายใดที่จะติดต่อด้วย และทำการเรียก MGCF เพื่อให้มีการแปลงการเข้ารหัสระบบ IP เป็น PCM ที่ใช้ในเครือข่ายยุคเก่าที่เป็นโทรศัพท์พื้นฐานและเชื่อมต่อกัน

Credit : http://www.mvt.co.th/viewarticle.php?cid=3&nid=128&page=2

Credit : http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

ATU-STI

ATU-STI : Access Transfer Update-Session Transfer Identifier

- ATU-STI เป็น SIP Message โดยกำหนดให้ SCC AS ส่งด้วยมาตรฐาน TS 23.237 และส่งมาจาก SCC AS เมื่อไปทำการลงทะเบียน IMS เสร็จไปจบที่ ATCF

- ATCF สามารถใช้ ATU-STI ที่จะคุยกับ SCC AS หลังจากนั้นเพื่อที่จะทำขั้นตอนการถ่ายโอนการเข้าถึง

Flow : SCC AS < > I-CSCF < > ATCF

Example :   sip: sccas@huawei.com

Credit : http://lteuniversity.com/get_trained

Credit : http://www.rtc-conference.com/wp-content/uploads/

SIP

SIP : Session Initiation Protocol

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 กับส่วนหัวอื่น ๆ เพิ่มเติม และจบด้วยบรรทัดว่าง

- 100 กำลังพยายาม / 100 Continue
เครื่องให้บริการได้รับการร้องขอแล้ว และเครื่องลูกข่ายควรจะส่งเนื้อหาตามออกไปกับข้อความร้องขอ (ในกรณีที่เนื้อหาจำเป็นต้องส่งไปกับการร้องขอ เช่นข้อความร้องขอแบบ 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 ได้รับการตอบกลับ / การร้องขอสำเร็จ
รหัสสถานภาพกลุ่มนี้หมายถึง "การดำเนินการที่ร้องขอได้รับแล้ว เป็นที่เข้าใจแล้ว และได้ยอมรับแล้ว" ใช้แสดงว่าการร้องขอจากเครื่องลูกข่ายได้ดำเนินการสำเร็จแล้ว

- 200 OK  (เน้น code นี้มาบ่อย) / 200 OK
เป็นรหัสตอบรับมาตรฐานสำหรับการร้องขอที่สำเร็จ ข้อความตอบรับที่แท้จริงอาจแตกต่างกันออกไปตามคำสั่งร้องขอที่ใช้ ในการร้องขอแบบ GET เนื้อหาในข้อความตอบรับจะเป็นเนื้อหาที่เกี่ยวข้องกับทรัพยากรที่ร้องขอ ส่วนในการร้องขอแบบ POST เนื้อหาในข้อความตอบรับจะเป็นการอธิบายทรัพยากรหรือผลลัพธ์จากการดำเนินการดังกล่าว เป็นต้น

- 201 Created

การร้องขอได้ดำเนินการแล้ว ซึ่งได้ผลลัพธ์เป็นทรัพยากรที่สร้างขึ้นใหม่บนเครื่องให้บริการ

- 202 ตกลง / 202 Accepted
การร้องขอได้รับแล้วเพื่อดำเนินการ แต่การดำเนินการนั้นยังไม่เสร็จสิ้น ซึ่งไม่จำเป็นต้องส่งการร้องขอใหม่ในช่วงเวลาดังกล่าว เพราะว่าเครื่องแม่ข่ายอาจยังไม่รับการร้องขอในขณะนั้น

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 และควรระบุว่าเป็นปัญหาที่เกิดขึ้นชั่วคราวหรือถาวร รหัสสถานภาพเหล่านี้สามารถใช้ตอบรับกับคำสั่งร้องขอใดก็ได้ ซึ่งตัวแทนผู้ใช้ควรแจ้งข้อผิดพลาดเหล่านั้นให้ผู้ใช้งานทราบด้วย

- 400 คำสั่ง Request ไม่ถูกต้อง / 400 Bad Request
ข้อความร้องขอที่ส่งมามีความผิดพลาดทางไวยากรณ์ หรือไม่สามารถทำตามการร้องขอนั้นได้

- 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
เครื่องลูกข่ายร้องขอเนื้อหาบางส่วนของไฟล์ แต่เครื่องแม่ข่ายไม่สามารถจัดหาช่วงข้อมูลนั้นได้ เช่นในกรณีที่ตัวแทนผู้ใช้ร้องขอด้วยช่วงข้อมูลที่เกินกว่าขนาดของไฟล์

- 417 Expectation Failed

ส่วนหัว Expect ที่ส่งมาจากเครื่องลูกข่าย ยังไม่เพียงพอต่อความต้องการของเครื่องให้บริการ

- 420 Server ไม่เข้าใจโปรโตคอล SIP ที่ส่งมา / 420 Bad extension
- 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 นอกจากนั้นตัวผู้ใช้ควรแจ้งข้อผิดพลาดให้ผู้ใช้ทราบ รหัสกลุ่มนี้สามารถใช้ตอบรับกับคำสั่งใดก็ได้

- 500 server มีปัญหาภายใน / 500 Internal Server Error
ข้อความแสดงความผิดพลาดแบบทั่วไป ใช้เมื่อไม่มีข้อความเฉพาะที่เหมาะสมในการแจ้งสาเหตุ

- 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