SDP : Session Description Protocol
Session Description Protocol เป็นโปรโตคอลมาตฐานตาม RFC 4566
SDP มีเพื่ออธิบาย multimedia sessions สำหรับจุดประสงค์ในการ session announcement, session invitation และรูปแบบอื่นๆของ multimedia session initiation
SDP ถูกเรียกใช้จาก VoIP Signaling Protocol เช่น SIP, H.323 และบาง VoIP Protocol เพื่อ transfer media setup information เกี่ยวกับ multimedia client จาก A ไป B
SDP จะอยู่ใน SIP INVITE Message และ 183 Session Progress
ดูตัวอย่างต่อไปนี้นะครับ
INVITE sip:6621010000@192.168.5.123:5060;user=phone SIP/2.0..
Via: SIP/2.0/UDP 192.168.5.5:5060;branch=z9hG4bK1ca4589054b6666f2-4f525-0..
Max-Forwards: 70..
Contact: <sip:66851140000@192.168.5.5:5060>..
To: <sip:6621010000@192.168.5.123:5060>..
From: <sip:66851140000@192.168.5.5:5060>;tag=430c6c2-co3249-INS001..
Call-ID: 51246cf51886b6a652233787b8c7122c@192.168.5.15..
CSeq: 324901 INVITE..
Content-Type: application/sdp..
Date: Mon, 01 Feb 2010 05:30:26 GMT..
User-Agent: ENS2.5.31-IS1-RMRG23-RG100-CPO245..
Content-Length: 304....
v=0..
o=- 70305474 70305474 IN IP4 192.168.5.5..
s=ENSResip..
c=IN IP4 192.168.5.20..
t=0 0..
m=audio 12198 RTP/AVP 18 8 0 4 2 97..
a=fmtp:97 0-15..
a=rtpmap:18 G729/8000..
a=rtpmap:8 PCMA/8000..
a=rtpmap:0 PCMU/8000..
a=rtpmap:4 G723/8000..
a=rtpmap:2 G726-32/8000..
a=rtpmap:97 telephone-event/8000..
a=sendrecv..
===================================================
SIP/2.0 183 Session Progress..
Via: SIP/2.0/UDP 192.168.5.5:5060;branch=z9hG4bK1ca4589054b666b13-95b51-0..
Record-Route: <sip:192.168.5.123:5060;lr>..
From: <sip:6622480000@192.168.5.5:5060>;tag=452ede66-co6132-INS001..
To: <sip:6621010000@192.168.5.123:5060>;tag=as3d0e1c30..
Call-ID: 84269fbeb806626c47360b37955bb319@192.168.5.15..
CSeq: 613201 INVITE..
User-Agent: Asterisk PBX..
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..
Supported: replaces..
Contact: <sip:6621010000@192.168.5.123:5060>..
Content-Type: application/sdp..
Content-Length: 308....
v=0..
o=root 16003 16003 IN IP4 192.168.5.91..
s=session..
c=IN IP4 192.168.5.91..
t=0 0..
m=audio 16964 RTP/AVP 18 0 8 97..
a=rtpmap:18 G729/8000..
a=fmtp:18 annexb=no..
a=rtpmap:0 PCMU/8000..
a=rtpmap:8 PCMA/8000..
a=rtpmap:97 telephone-event/8000..
a=fmtp:97 0-16..
a=silenceSupp:off - - - -..
a=ptime:20..
a=sendrecv..
ฟิลด์ที่มีเครื่องหมายดอกจันทน์ * เป็นออปชั่นนะครับ มีหรือไม่มีก็ได้
Session description
v= เวอร์ชั่น
o= เจ้าของหรือผู้สร้างและตัวบ่งชี้เซสชั่น
s= ชื่อเซสชั่น
i=* ข้อมูลเซสชั่น
u=* เป็น URI ของ Description
e=* อีเมล์แอดเดรส
p=* เบอร์โทรศัพท์
c=* ข้อมูลการเชื่อมต่อ แต่ไม่ต้องใช้ถ้ามีข้อมูลอยู่ในทุกๆ media แล้ว
b=* ข้อมูลแบนวิดธ์
มี Description เกี่ยวกับเวลาด้วย ดังนี้
z=* ปรับแต่งเวลา time zone
k=* คีย์เข้ารหัส
a=* เป็น 0 หรือมี session attribute เพิ่มเติม
Time description
t= เวลาที่เซสชั่นแอ๊คทีฟ หรือเรียกว่า Session Timer ถ้ามีค่าเป็น 0 คือไม่กำหนดเวลาสูงสุดที่โทรได้ โทรได้ไปเรื่อยๆจนกว่าจะวางสาย ตามปกตินะครับเวลาเราคอนฟิกอุปกรณ์ VoIP จะมีให้ใส่ Session Timer ด้วย ซึ่งเป็นเวลาสูงสุดที่จะโทรได้ในแต่ละครั้ง และในระบบโทรแบบคิดเงิน จะใช้ฟิลด์นี้กำหนดว่าลูกค้าจะโทรได้นานเท่าไหร่ (ตามจำนวนเงินที่เหลืออยู่)
r=* เป็น 0 หรือซ้ำกันหลายๆครั้ง
Media description
m= ชื่อ media เช่น audio, video และหมายเลขพอร์ต RTP
i=* media title
c=* ข้อมูลการเชื่อมต่อ เช่น IP Address
b=* แสดงแบนวิดธ์
k=* คีย์เข้ารหัส
a=* เป็น Codec หรือขนาดแพ็กเก็ตของ Voice
RTP Payload Type Numbers
RTP Payload Type Numbers หรือ PT จะอยู่ในบรรทัด m= และ rtpmap ซึ่งจะบ่งบอก Codec ที่รองรับ ตัวอย่าง RTP Payload Type Number มีดังนี้ครับ
PT=0 G.711 ulaw (PCMU)
PT=3 GSM
PT=4 G.723.1
PT=8 G.711 alaw (PCMA)
PT=9 G.722
PT=18 G.729
PT=31 H.261 (Video)
PT=34 H.263 (Video)
Credit : http://www.voip4share.com/voip-f39/sdp-voip-t280.html
แสดงบทความที่มีป้ายกำกับ SIP แสดงบทความทั้งหมด
แสดงบทความที่มีป้ายกำกับ SIP แสดงบทความทั้งหมด
2.01.2559
6.26.2558
RFC
RFC : Request for Comments
หมายถึง เอกสารขอความเห็น ซึ่งเปนเอกสารที่เปนทางการจาก IETF โดยใชผลที่ไดจากคณะกรรมการรางและทบทวนจากกลุมงานที่สนใจ ทั้งนี้รางสุดทายของ RFC มีสถานะเปนมาตรฐาน และไมอนุญาตใหมีการเปลี่ยนแปลง เวนแตผานการเห็นชอบจากคณะกรรมการของ RFC ใหมีการปรับปรุง RFC ( ในระบบโทรคมนาคม เราให้ส่วนมากเป็น RFC 3261 มาตรฐานใน SIP ครับ )
Credit : http://standard1.nbtc.go.th/getattachment/5aca8579-db09-464d-933d-3c9a5608a178/6201.aspx
หมายถึง เอกสารขอความเห็น ซึ่งเปนเอกสารที่เปนทางการจาก IETF โดยใชผลที่ไดจากคณะกรรมการรางและทบทวนจากกลุมงานที่สนใจ ทั้งนี้รางสุดทายของ RFC มีสถานะเปนมาตรฐาน และไมอนุญาตใหมีการเปลี่ยนแปลง เวนแตผานการเห็นชอบจากคณะกรรมการของ RFC ใหมีการปรับปรุง RFC ( ในระบบโทรคมนาคม เราให้ส่วนมากเป็น RFC 3261 มาตรฐานใน SIP ครับ )
Credit : http://standard1.nbtc.go.th/getattachment/5aca8579-db09-464d-933d-3c9a5608a178/6201.aspx
5.13.2558
Soft Switch
Soft Switch
ในระบบสื่อสารแบบดั้งเดิมเช่นโครงข่ายโทรศัพท์สวิตช์สาธารณะ (PSTN : Public-Switched Telephone Network ) ซึ่งเป็นโครงข่ายแบบวงจรสวิตช์ถูกออกแบบมา เพื่อการสื่อสารประเภทเสียง ที่เป็นการส่งผ่านข้อมูลแบบ oriented switching ซึ่งมีการจองช่องสัญญาณตลอดการใช้งาน ทำให้สิ้นเปลืองแบนด์วิดธ์ แต่เนื่องจากเทคโนโลยีในปัจจุบันมีการสื่อสารประเภทไม่ ใช้เสียงอย่างเช่น อินเทอร์เน็ตที่มีการส่งข้อมูลในรูปแบบของเพ็กเกต ได้เข้ามามีบทบาทต่อชีวิตประจำวันมากขึ้น จะเห็นว่าโครงข่ายแบบแพ็กเกตสวิตช์ที่มีการส่งผ่านข้อมูลโดยไม่จำเป็นต้อง จองช่องสัญญาณในการส่ง ซึ่งจะเข้ามาแทนที่โครงข่ายแบบวงจรสวิตช์ที่มีอยู่ดั้งเดิม แต่ในปัจจุบันยังมีประเด็นที่สำคัญคือไม่สามารถเปลี่ยนแปลงโครงข่ายของเดิม ได้ทั้งหมดให้เป็นแบบเพ็กเกตสวิตช์ได้ อันเนื่องจากราคาค่าใช้จ่ายในการลงทุนสูง และอีกเหตุผลหนึ่งก็คือเทคโนโลยีเดิมยังใช้งานได้ดีอยู่ ดังนั้นจึงได้มีการนำเสนอโครงข่ายที่สามารถรองรับข้อมูลได้ทุกรูปแบบภายใต้ โครงข่ายเดียวกันและเป็นที่ยอมรับ กันก็คือโครงข่ายซอฟท์สวิตช์ (Soft switch network) ซึ่งเป็นเทคโนโลยีที่ทำให้อุปกรณ์ทำงานอยู่บนพื้นฐานของซอฟแวร์สามารถทำ หน้าที่หลักได้เช่นเดียวกันกับอุปกรณ์สวิตชิ่ง ในโครงข่ายโทรศัพท์สวิตช์สาธารณะ และยังสามารถรองรับบริการในการส่งผ่านข้อมูลแบบเพ็กเกตสวิตช์ที่มีอยู่ใน ปัจจุบันและอนาคตได้
โครงสร้างของโครงข่ายซอฟท์สวิตช์ประกอบด้วย 3 ส่วนหลักๆคือ
1. Media Gateway Controller (MGC) มีหน้าที่เชื่อมโครงข่ายต่างชนิดเข้าด้วยกัน เช่น โครงข่าย PSTN, IP และรองรับโปรโตคอลชนิดต่างๆ เช่น H.323,SIP,MGCP,SS7
2. Signaling Gateway (SGW) ทำงาน มีหน้าที่เป็นทางผ่านของสัญญาณ SS7 จากโครงข่าย PSTN และแปลงให้อยู่ในรูปแบบที่เหมาะสมเพื่อเชื่อมต่อกับโครงข่าย IP เข้าด้วยกัน
3. Media Gateway (MGW) หน้าที่หลักในการส่งผ่านสัญญาณชนิดต่างๆ เช่น เสียง,ข้อมูล,แฟกซ์,วีดีทัศน์ ระหว่างโครงข่าย PSTN กับโครงข่าย IP
1. Media Gateway Controller (MGC) มีหน้าที่เชื่อมโครงข่ายต่างชนิดเข้าด้วยกัน เช่น โครงข่าย PSTN, IP และรองรับโปรโตคอลชนิดต่างๆ เช่น H.323,SIP,MGCP,SS7
2. Signaling Gateway (SGW) ทำงาน มีหน้าที่เป็นทางผ่านของสัญญาณ SS7 จากโครงข่าย PSTN และแปลงให้อยู่ในรูปแบบที่เหมาะสมเพื่อเชื่อมต่อกับโครงข่าย IP เข้าด้วยกัน
3. Media Gateway (MGW) หน้าที่หลักในการส่งผ่านสัญญาณชนิดต่างๆ เช่น เสียง,ข้อมูล,แฟกซ์,วีดีทัศน์ ระหว่างโครงข่าย PSTN กับโครงข่าย IP
PSTN (Public-Switched Telephone Network) คือเครือข่ายโทรศัพท์ที่เปิดบริการแก่สาธารณชน ซึ่งการใช้งานจะมีการจองช่องสัญญาณตลอดการใช้งาน จะใช้ POT เป็นอุปกรณ์โทรศัพท์ โดย Signaling ที่ใช้งานคือ SS7 ( Signaling System 7)
ข้อดีของโครงข่ายซอฟท์สวิตช์
1. เปิดโอกาสให้ผู้ผลิตอุปกรณ์โครงข่ายทั้งหลายสามารถพัฒนาอุปกรณ์ที่ตั้งอยู่ บนมาตรฐานสากล เดียวกันซึ่งต่างจากเดิมที่ยังไม่มีมาตรฐาน ทำให้อุปกรณ์ที่ผลิตได้มีลักษณะเฉพาะเป็นของตัวเอง (Proprietary) ไม่สามารถใช้งานร่วมกับอุปกรณ์ของผู้ผลิตรายอื่นได้
2. ผู้ผลิตอุปกรณ์ไม่จำเป็นต้องมีความเชี่ยวชาญในทุกส่วนของโครงข่าย ซอฟท์สวิตช์
3. ผู้ให้บริการสามารถเลือกใช้อุปกรณ์ที่มาจากผู้ผลิตที่เชี่ยวชาญที่สุดในแต่ ละส่วนของโครงข่ายทำให้ไม่ จำเป็นต้องถูกผูกขาดโดยอุปกรณ์โครงข่ายจากผู้ผลิต รายใดรายหนึ่งเท่านั้น
1. เปิดโอกาสให้ผู้ผลิตอุปกรณ์โครงข่ายทั้งหลายสามารถพัฒนาอุปกรณ์ที่ตั้งอยู่ บนมาตรฐานสากล เดียวกันซึ่งต่างจากเดิมที่ยังไม่มีมาตรฐาน ทำให้อุปกรณ์ที่ผลิตได้มีลักษณะเฉพาะเป็นของตัวเอง (Proprietary) ไม่สามารถใช้งานร่วมกับอุปกรณ์ของผู้ผลิตรายอื่นได้
2. ผู้ผลิตอุปกรณ์ไม่จำเป็นต้องมีความเชี่ยวชาญในทุกส่วนของโครงข่าย ซอฟท์สวิตช์
3. ผู้ให้บริการสามารถเลือกใช้อุปกรณ์ที่มาจากผู้ผลิตที่เชี่ยวชาญที่สุดในแต่ ละส่วนของโครงข่ายทำให้ไม่ จำเป็นต้องถูกผูกขาดโดยอุปกรณ์โครงข่ายจากผู้ผลิต รายใดรายหนึ่งเท่านั้น
Softswitch กับหน้าที่สำคัญที่จะทำให้การรับส่งข้อมูลบนเลเยอร์ Circuit และ Packet รวมกันไปบนระบบเครือข่ายสาธารณะมีประสิทธิภาพสูงขึ้น ทั้งยังการันตีการเข้าถึงความสามารถและบริการที่มีคุณค่าได้ง่ายขึ้น
ความพยายามในการผลักดันเรื่อง Converged IP ยังคงดำเนินอยู่ ผู้ผลิตอุปกรณ์รับส่งข้อมูลทั้งรายเล็กรายใหญ่ ต่างพบกับความท้าทายประการเดียวกัน คือ พวกเขาต้องเพิ่มบริการที่ลูกค้าต้องการลงไปด้วย ในขณะที่ยังคงต้องลดความซับซ้อนในระบบเครือข่าย และไม่ใช่เรื่องง่ายเลย เมื่อบริการที่ถูกเรียกร้องเหล่านี้ต้องใช้เทคโนโลยีสูงในทั้งโครงสร้างระบบ เครือข่ายแบบ Circuit switching และ Packet switching สิ่งสำคัญสำหรับผู้ให้บริการคือ การทำงานบนสภาพระบบเครือข่ายที่เปิดกว้างอย่างแท้จริงที่อนุญาตให้รวมเอาการ ทำงานใดๆ เข้ามาในระบบได้ หรือถ้าพูดง่ายๆ ตามภาษาการจัดการ คือการเพิ่มหรือลดส่วนนั้นๆ ได้โดยสะดวก ซึ่งทำให้มีทั้งความซับซ้อนและได้ความเร็วที่เพิ่มขึ้น ฟังดูน่าสนใจมาก? แต่ไม่นานเกินรอ เหล่าผู้ให้บริการก็คงไม่วางเฉยอยู่อีกต่อไป ความต้องการที่จะนำ Softswitch มาใช้งานจริงจะเพิ่มขึ้นอย่างจริงจัง
หลายคนอาจสงสัยว่า Softswitch คืออะไรกันแน่? โดยพื้นฐาน Softswitch จะแยกฟังก์ชันการควบคุมการโทรศัพท์ออกจากมีเดียเกตเวย์ (ซึ่งอยู่ในเลเยอร์ทรานสปอร์ต) ซึ่งปกติทำหน้าที่นี้อยู่ สวิตช์เหล่านี้ใช้เทคโนโลยีที่น่าอัศจรรย์ใจ คือ อนุญาตให้ผู้ให้บริการสามารถควบคุมเส้นทางเสียงและข้อมูลให้เดินทางอยู่บน เครือข่ายเดียวกันได้ หน้าที่การควบคุมการโทรอาจแตกต่างกันไปได้ แต่ฟังก์ชันการทำงานอย่าง Call routing, Admission control, Connection control (เช่น การสร้างหรือตัด Session) และ Signalling interworking (เช่น สลับจาก SS7 ไปเป็น SIP) นั้นเป็นความสามารถขั้นพื้นฐาน เนื่องจาก Softswitch เป็นซอฟต์แวร์ที่จำเป็นจะต้องอยู่ในไม่เซิร์ฟเวอร์ก็อุปกรณ์เครือข่ายอื่น แต่ก็สามารถฝังหน้าที่ SS7 ไปด้วยกันหรือแยกไว้ต่างหากก็ได้ ตามกฎที่นิยมปฏิบัติโดยทั่วไป การรวมการทำงานไว้ด้วยกันจะดีกว่า Softswitch นั้นสร้างบนโครงสร้างแบบเปิด จึงทำให้ผู้ให้บริการไม่จำเป็นต้องผูกตัวเองติดอยู่กับเวนเดอร์ ทั้งยังสามารถควบคุมการสร้างบริการและลดค่าใช้จ่ายในการให้บริการข้อมูล ธรรมดาและข้อมูลเสียงได้มากยิ่งขึ้น และเนื่องจากว่าเป็นสวิตช์ที่มีฟังก์ชันการคิดคำนวณภายในมากกว่าสวิตช์แบบ เดิมๆ Softswitch จึงทำให้ผู้ให้บริการสามารถให้บริการส่งข้อมูลเสียงผ่านระบบเครือข่ายข้อมูล ได้ด้วยต้นทุนที่ต่ำลงอย่างมาก โดยไม่จำเป็นต้องไปลงทุน Circuit switching ใหม่ และปราศจากข้อจำกัดในการพัฒนาระบบเดิมที่เป็นของตนเองโดยเฉพาะ
“มุมมองโดยรวมของการรวมเอาเครือข่ายแบบ IP และ PSTN รวมเข้าด้วยกันโดยมีโปรโตคอลหลายๆ ตัวบน Softswitch”
Steve Byars ผู้อำนวยการของ Carrier Infrastructure for Current Analysis (Sterling, VA) กล่าวถึงแนวคิดสำคัญของ Softswitch ว่า “ไม่ให้มีการเชื่อมโยงระหว่างซอฟต์แวร์, Intelligence, ฮาร์ดแวร์, เลเยอร์ทรานสปอร์ตและสวิตช์ ดังนั้นเวนเดอร์จะสามารถซื้ออุปกรณ์ที่เหมาะสมกับเฉพาะส่วนที่เลือกได้”
Hilary Mine ประธานและผู้บริหารบริษัท Probe Research (Cedar Knolls, NJ) กล่าวว่า สิ่งที่ทำให้เรื่องยากขึ้นคือ อุตสาหกรรมรับส่งข้อมูลแบบแพ็กเกตทางโทรศัพท์นั้นเป็นระบบปิดและมีลักษณะ เฉพาะตัว Voice-over-IP Gateway นั้นเพิ่งจะเริ่มแสดงให้เห็นว่าสามารถทำงานร่วมกันได้เฉพาะบางกรณีเท่านั้น ยกตัวอย่างเช่น เมื่อไม่นานมานี้เอง ผู้ให้บริการได้นำโซลูชันด้านเกตเวย์จาก Clarent (Redwood City, CA – 650-306-7511) หนึ่งในเวนเดอร์ชั้นนำด้าน VoIP Trunking มาใช้งาน ซึ่งมีทางเลือกไม่มากนัก นอกจากจะนำ Gatekeeper และแอพพลิเคชันที่พัฒนาขึ้นจาก Clarent มาใช้ นอกจากนี้ การทำงานร่วมกันได้แบบปลั๊กแอนด์เพลระหว่างเกตเวย์เองนั้นก็ยากที่ทำได้จริง
สร้างสะพานเชื่อม
อย่างไรก็ดี เวนเดอร์ Softswitch อย่าง Marconi Communications (Warrendale, PA – 724-742-4444) ก็ยังเห็นโอกาสที่จะพัฒนาสถานการณ์ปัจจุบันให้ดียิ่งขึ้น โดยการตอบสนองความต้องการหลักๆ ของผู้ให้บริการที่พบเสียก่อน อย่างที่เป็นอยู่ในปัจจุบัน ส่วน Call Agent ของ Softswitch สามารถรองรับบริการที่มีให้บน Switched Circuit Network (SCN) และยังได้รับการพัฒนาเพื่อให้บริการได้มากขึ้น และ Bearer Channel Control Protocol สำหรับแอพพลิเคชัน IP elephony และมัลติมีเดียอื่นๆ อีกด้วย นอกจากนั้น ส่วน Call Agent ของ Softswitch ยังจัดการการสื่อสารทั้งภายในและภายนอก ในขณะเดียวกันก็ยังควบคุมการลงทะเบียน, การเข้าร่วมและสถานะของเทอร์มินอลและเกตเวย์ต่างๆ ด้วย ส่วนฟังก์ชันสำคัญอื่นๆ ยังรวมถึงการจัดการแบนด์วิดธ์, การควบคุมโพรไฟล์ของผู้ใช้, การเก็บบันทึกข้อมูลรายละเอียดการเรียกใช้และสถิติ และในระดับที่สูงกว่า Softswitch ของ Marconi ก็ยังรองรับฟังก์ชันเกี่ยวกับวิดีโอ, อีเมล์, การรับส่งไฟล์และการส่งข้อมูลเสียงอีกด้วย ซึ่งรวมถึงการดูทราฟฟิกบนโมเด็มพร้อมทั้งความสามารถเกือบทั้งหมดบน SCN
อย่างไรก็ดี เวนเดอร์ Softswitch อย่าง Marconi Communications (Warrendale, PA – 724-742-4444) ก็ยังเห็นโอกาสที่จะพัฒนาสถานการณ์ปัจจุบันให้ดียิ่งขึ้น โดยการตอบสนองความต้องการหลักๆ ของผู้ให้บริการที่พบเสียก่อน อย่างที่เป็นอยู่ในปัจจุบัน ส่วน Call Agent ของ Softswitch สามารถรองรับบริการที่มีให้บน Switched Circuit Network (SCN) และยังได้รับการพัฒนาเพื่อให้บริการได้มากขึ้น และ Bearer Channel Control Protocol สำหรับแอพพลิเคชัน IP elephony และมัลติมีเดียอื่นๆ อีกด้วย นอกจากนั้น ส่วน Call Agent ของ Softswitch ยังจัดการการสื่อสารทั้งภายในและภายนอก ในขณะเดียวกันก็ยังควบคุมการลงทะเบียน, การเข้าร่วมและสถานะของเทอร์มินอลและเกตเวย์ต่างๆ ด้วย ส่วนฟังก์ชันสำคัญอื่นๆ ยังรวมถึงการจัดการแบนด์วิดธ์, การควบคุมโพรไฟล์ของผู้ใช้, การเก็บบันทึกข้อมูลรายละเอียดการเรียกใช้และสถิติ และในระดับที่สูงกว่า Softswitch ของ Marconi ก็ยังรองรับฟังก์ชันเกี่ยวกับวิดีโอ, อีเมล์, การรับส่งไฟล์และการส่งข้อมูลเสียงอีกด้วย ซึ่งรวมถึงการดูทราฟฟิกบนโมเด็มพร้อมทั้งความสามารถเกือบทั้งหมดบน SCN
ทั้งหมดนี้ควบคุมด้วยซอฟต์แวร์ (IPN4120P) ที่รันอยู่บนฮาร์ดแวร์ของ Call Agent ของ Softswitch (IPN4120E) ซึ่งทั้งสองส่วนนี้ เป็นส่วนประกอบพื้นฐานที่จำเป็นต้องมี แต่ละส่วนจะประกอบไปด้วย COTS Hardware Platform ที่ใช้รันระบบปฏิบัติการยูนิกซ์แบบเรียลไทม์ เหตุผลที่จำเป็นจะต้องมี คือเพื่อให้แน่ใจถึงความยืดหยุ่นในระบบเครือข่าย สำหรับส่วนประกอบอื่นๆ ของ Call Agent ของ Softswitch นั้นจะเพิ่มเพื่อขยายขนาดของแพลตฟอร์มให้ได้ตามที่ต้องการหรือเพื่อให้เหมาะ สมกับอุปกรณ์การรับส่งข้อมูลได้ Marconi อ้างว่า ผลิตภัณฑ์ของตนนั้นสามารถขยายขอบเขตการทำงานและพร้อมใช้ ไม่ต้องจัดเตรียมมากและมีประสิทธิภาพในขณะที่มี ความสามารถในการควบคุม, ความน่าเชื่อถือและความสามารถในด้านต่างๆ สูงที่สุด
Concept ของ Softswitch เริ่มขึ้นช่วงปลายทศวรรษที่แล้วโดยเป็นความพยายามของผู้ผลิตอุปกรณ์ที่จะ สร้างทางเลือกใหม่นอกเหนือไปจากการผูกเรื่องของ call control และ service creation เข้ากับอุปกรณ์ TDM-based switch ในลักษณะของ integrated switch+applications+services อยู่ใน hardware platform เดียว ไปสู่การแยกส่วนของ call control functions ออกจาก switching platform ซึ่งจะทำให้ผู้ให้บริการสามารถสร้าง applications ที่หลากหลายได้โดยสะดวก และเป็นการ Offload พวก dial-up internet, voice VPN ออกจากอุปกรณ์พวก circuit switches หรือในที่สุดก็เป็นการทดแทนอุปกรณ์แบบดั้งเดิมได้ด้วย
เวลาที่เราพูดถึง Softswitch กันนั้น บางคนก็มักจะหมายรวมถึงอุปกรณ์ที่เกี่ยวข้องในการทำระบบ packet-based voice infrastructure ซึ่งก็ประกอบด้วย media server, media gateway, application server, service creation environment, signaling gateway, etc. แต่ที่จะพูดถึงในที่นี้ softswitch จะหมายถึงอุปกรณ์ที่ทำหน้าที่เกี่ยวกับ call control, media gateway control และหน้าที่อื่นๆที่เกียวข้องเช่น call admission, call routing เป็นต้น โดย protocols ที่อุปกรณ์ softswitch สนับสนุนก็มักจะได้แก่ signaling ของ PSTN (SS7/TCAP, ISUP, ISDN) และก็ signaling ที่เป็น next generation ได้แก่ H.323, MGCP, SIP, SIP-I, BICC, SIGTRAN และ H.248 อีกส่วนหนึ่งที่เป็นส่วนสำคัญของ softswitch ที่ต้องพูดถึงก็คือ APIs มาตรฐานและเครื่องมือ service creation tools เช่น JAIN, Parlay, XML และ SOAP ที่ให้สำหรับ developers ทำการพัฒนา applications ต่างๆขึ้นได้เอง
การ implement softswitch บางที่ก็มีความ flexible สำหรับ end users ให้สามารถเลือกใช้บริการได้เองผ่านทาง web browser ในลักษณะ on-demand ซึ่งก็จะทำให้ผู้ให้บริการสามารถลดเวลาในการนำบริการใหม่ๆออกสู่ตลาดได้ อย่างมาก นอกจากนี้ผู้ผลิตที่ทำ softswitch สำหรับโทรศัพท์พื้นฐานก็เริ่มหันมาพยายามที่จะทำระบบที่ไม่ขึ้นอยู่กับ เทคโนโลยีในการ access เข้ามา (access-agnostic) ไม่ว่าจะเป็นทาง wireline หรือ wireless โดยทำระบบที่เป็นพื้นฐานในการให้บริการ multimedia content delivery ไปยังทั้งสองเทคโนโลยี ซึ่งก็ทำให้ผู้ผลิตเหล่านี้เริ่มที่จะรับเอากรอบของ IMS หรือ IP Multimedia Subsystem ของทาง 3GPP เข้ามาใช้ โดยกรอบของ IMS ก็จะมีการแบ่งออกเป็นสามส่วนด้วยกันคือ application server layer, session control layer และ transport & endpoint layer
ในแง่ของส่วนแบ่งทางการตลาด ณ กลางปีที่แล้ว(2007) ผู้นำได้แก่ Italtel, Nokia-Siemens, Nortel, Alcatel-Lucent และ Huawei ตามลำดับด้วย Market Share 20.6, 18.3, 17.1, 10.1 และ 5.0 percent ตามลำดับ รวม 5 เจ้า ครอบครองส่วนแบ่งทางการตลาด 71.1% ทั่วโลก
ความเคลื่อนไหวในวงการนี้มีอยู่หลายส่วนด้วยกันผมขอสรุปบางส่วนดังนี้ครับ
•SIP กับ IMS คงจะเป็นอะไรที่ hot ที่สุดแล้วในเวลานี้ IMS framework ก็เลือก SIP เป็น protocol ที่จะใช้กันเนื่องจากความ simple ไม่สลับซับซ้อนและ support multimedia content
•Quadruple Plays และ MVNO ถ้าจะพูดถึง Triple Play ก็อาจจะเชยแล้วนะครับเพราะเดี๋ยวนี้มี factor ที่สี่แล้วคือ mobility ทำให้เราเริ่มเห็น fixed operator เริ่มรวมกับ mobile operator เพื่อจะให้ mobility เข้าไปด้วย สอดคล้องกับความเคลื่อนไหว FMC(Fixed Mobile Convergence) และก็ทำให้เกิด term MVNO หรือ Mobile Voice Network Operator เรียกว่าเป็นการติดตามผู้ใช้ไปทุกฝีก้าวเลยทีเดียว
•Presence และ Personalization ต่อไปผู้ให้บริการจะทราบได้ว่าผู้ใช้บริการนั้นอยู่ที่ไหนและ access เข้ามาใช้บริการด้วย device ประเภทไหนและมีความต้องการรูปแบบของการใช้บริการหรือ preference สำหรับ แต่ละ location และ device อย่างไร database ที่เก็บข้อมูลเหล่านี้จะเรียกว่า HSS(Home Subscriber Server)
•กลุ่มของ vendors ที่เป็นลักษณะ second class รองจากกลุ่มของผู้นำก็มีพวก Cirpack, Ericsson, GENBAND, Sonus Networks, Tekelec, Telica, Veraz, Vocaltec
•Quadruple Plays และ MVNO ถ้าจะพูดถึง Triple Play ก็อาจจะเชยแล้วนะครับเพราะเดี๋ยวนี้มี factor ที่สี่แล้วคือ mobility ทำให้เราเริ่มเห็น fixed operator เริ่มรวมกับ mobile operator เพื่อจะให้ mobility เข้าไปด้วย สอดคล้องกับความเคลื่อนไหว FMC(Fixed Mobile Convergence) และก็ทำให้เกิด term MVNO หรือ Mobile Voice Network Operator เรียกว่าเป็นการติดตามผู้ใช้ไปทุกฝีก้าวเลยทีเดียว
•Presence และ Personalization ต่อไปผู้ให้บริการจะทราบได้ว่าผู้ใช้บริการนั้นอยู่ที่ไหนและ access เข้ามาใช้บริการด้วย device ประเภทไหนและมีความต้องการรูปแบบของการใช้บริการหรือ preference สำหรับ แต่ละ location และ device อย่างไร database ที่เก็บข้อมูลเหล่านี้จะเรียกว่า HSS(Home Subscriber Server)
•กลุ่มของ vendors ที่เป็นลักษณะ second class รองจากกลุ่มของผู้นำก็มีพวก Cirpack, Ericsson, GENBAND, Sonus Networks, Tekelec, Telica, Veraz, Vocaltec
Credit : https://chayut512.wordpress.com
2.16.2558
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
การร้องขอได้ดำเนินการแล้ว ซึ่งได้ผลลัพธ์เป็นทรัพยากรที่สร้างขึ้นใหม่บนเครื่องให้บริการ
การร้องขอได้รับแล้วเพื่อดำเนินการ แต่การดำเนินการนั้นยังไม่เสร็จสิ้น ซึ่งไม่จำเป็นต้องส่งการร้องขอใหม่ในช่วงเวลาดังกล่าว เพราะว่าเครื่องแม่ข่ายอาจยังไม่รับการร้องขอในขณะนั้น
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 ที่ส่งมาจากเครื่องลูกข่าย ยังไม่เพียงพอต่อความต้องการของเครื่องให้บริการ
- 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
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
สมัครสมาชิก:
บทความ (Atom)