Giao thức khởi tạo phiên SIP.doc

Giao thức khởi tạo phiên SIP

CHƯƠNG III GIAO thức khởi tạo phiên sip3.1 Giới thiệu giao thức SIP

3.1.1 Chức năng của SIP

SIP là một giao thức điều khiển tầng ứng dụng có thể thiết lập, duy trì và giải tỏacác cuộc gọi hoặc các phiên truyền thông Các phiên truyền thông có thể là điện thoạihội nghị, học từ xa, điện thoại Internet và các ứng dụng tơng tự khác SIP có thể đemlại cho các thành viên cả các phiên đơn hớng và đa hớng (đơn phát hoặc đa phát) Ngờibắt đầu không cần thiết phải là một thành viên của phiên truyền thông Phơng tiện vàcác thành viên có thể bổ sung vào phiên hiện tại SIP cũng có thể đợc dùng để bắt đầucác phiên cũng nh mời các thành viên tới phiên hội thoại mà đã đợc thông báo và thiếtlập bởi các phơng tiện khác SIP hỗ trợ các dịch vụ ánh xạ tên và các dịch vụ gián tiếpmột cách trong suốt Vì thế nó cho phép thi hành một cách đầy đủ các dịch vụ trênISDN, mạng thoại thông minh và hỗ trợ các cuộc gọi di động của ngời dùng có địa chỉkhông cố định

SIP hỗ trợ 5 dịch vụ trong việc thiết lập và kết thúc các phiên truyền thông:

- Định vị ngời dùng: Xác định vị trí của ngời dùng tiến hành hội thoại.

- Năng lực ngời dùng: Xác định các phơng thức (phơng tiện) và các tham số

t-ơng ứng trong hội thoại

- Xác định những ngời sẵn sàng tham gia hội thoại.

- Thiết lập các tham số cần thiết cho cuộc gọi.

- Điều khiển cuộc gọi: Bao gồm cả quá trình truyền và kết thúc cuộc gọi.

SIP là một phần trong bộ giao thức chuẩn cho truyền dòng tin đa phơng thức doIETF khuyến nghị nh RSVP ( giao thức giữ trớc tài nguyên ), RTP ( giao thức truyềntải theo thời gian thực ), RTSP ( giao thức phân phối dòng tin đa phơng thức ), SAP( giao thức thông báo phiên ), SDF ( giao thức mô tả phiên ) Tuy nhiên SIP hoạt động

độc lập với các giao thức trên

SIP cũng có thể kết hợp với các giao thức báo hiệu và thiết lập cuộc gọi khác.Theo cách đó, một hệ thống đầu cuối dùng SIP để xác định địa chỉ hợp lệ của một hệthống và giao thức từ một địa chỉ gửi đến là giao thức độc lập Ví dụ, SIP có thể dùng

để chỉ ra rằng ngời tham gia có thể thông qua H323, cổng H245, địa chỉ ngời dùng rồidùng H225 để thiết lập cuộc gọi

3.1.2 Các thành phần của hệ thống SIP

3.1.2.1 Các định nghĩa

 Call: Một cuộc gọi gồm tất cả các thành viên trong phiên đợc mời bởi một tàinguyên chung Một cuộc gọi SIP đợc nhận biết bởi Call - ID

 Call leg: Call leg đợc nhận biết bởi sự kết hợp của Call - ID, To and from

 Client: Là một chơng trình ứng dụng gửi đi những yêu cầu SIP Client có thể

ảnh hởng trực tiếp hoặc không đến ngời sử dụng Client đợc chứa trong cácProxy và Uers Agent

 Conference: Hội nghị là một phiên hội thoại đa phơng Một hội nghịh có thểkhông có hoặc có nhiều thành viên và bao gồm các trờng hợp nh hội nghị đaphơng, hội nghị nhiều mắt lới ( full – mesh ), cuộc gọi hai thành viên, Mộtvài cuộc gọi có thể tạo ra một hội nghị

 Downstream: là yêu cầu gửi trực tiếp từ phía gọi đến ngời nghe ( từ UAC đếnUAS )

 Final Respone: là đáp ứng kết thúc một phiên giao dịch SIP, bao gồm các đápứng sau: 2xx, 3xx, 4xx, 5xx, 6xx

 Invitation: Là yêu cầu gửi từ User hoặc Service đề nghị tham gia vào một phiênhội thoại Một lời mời đầy đủ gồm một yêu cầu INVITE ngay sau một yêu cầuACK

 Parallel search: Trong một quá trình tìm kiếm song song một Proxy đa ra mộtvài yêu cầu tới ngời dùng hiện tại trong khi nhận một yêu cầu đến

 Provisional Respone: Đáp ứng tạm thời là đáp ứng đợc Server dùng để thôngbáo tiến trình gọi nhng cha kết thúc một phiên giao dịch SIP, đáp ứng 1xx làmột Provisional Respone

 Server: Là một chơng trình ứng dụng có nhiệm vụ nhận các yêu cầu hợp lệ từcác dịch vụ và gửi trả lại các đáp ứng Server có thể là Proxy, Redirect, UAS,Registrars

 Session: Theo đặc tả của SDP thì một phiên đa truyền thông là tập hợp nhữngngời gửi và nhận cùng với dòng dữ liệu từ nơi gửi đến nơi nhận Nó đợc xác

định bởi chuỗi các tên User, Session ID, kiểu mạng, kiểu địa chỉ và địa chỉ cácphần tử trong trờng nguồn

 SIP transaction: là quá trình xảy ra giữa một Client và một Server gồm tất cảcác bản tin từ yêu cầu đầu tiên gửi đi từ client đến server cho đến đáp ứng cuốicùng từ Server gửi trả lại Client Nó đợc nhận biết bởi số thứ tự CSeq Yêu cầuACK có cùng số CSeq với yêu cầu INVITE tơng ứng nhng chứa một giao dịchcủa riêng nó

 Upstream: Đáp ứng gửi trực tiếp từ UAS đến UAC

 URL - encoded: Là chuỗi ký tự mã hoá theo chuẩn RFC 1738

3.1.2.2 Các thành phần của kiến trúc SIP

Xét trên quan điểm khách hàng / phục vụ ( Client /Server ), các thành phần chínhcủa một hệ thống SIP đợc mô tả bởi hình vẽ sau:

Trong hình trên User Agent là thiết bị đầu cuối trong mạng SIP, có thể là một máy

điện thoại SIP, có thể là máy tính chạy phần mềm đầu cuối SIP

Proxy Server là phần mềm trung gian hoạt động cả nh server và client để thực hiệncác yêu cầu thay mặt các đầu cuối khác Tất cả các yêu cầu đợc xử lý tại chỗ bởi ProxyServer nếu có thể, hoặc đợc chuyển cho các máy chủ khác Trong trờng hợp ProxyServer không trực tiếp đáp ứng các yêu cầu này thì Proxy Server sẽ thực hiện khâuchuyển đổi hoặc dịch sang khuôn dạng thích hợp trớc khi chuyển đi

Location Server là phần mềm định vị thuê bao, cung cấp thông tin về những vị trí

có thể của phía bị gọi cho các phần mềm Proxy Server và Redirect Server

Redirect Server là phần mềm nhận yêu cầu SIP và chuyển đổi địa chỉ SIP sangmột số địa chỉ khác và gửi lại cho đầu cuối Không giống nh Proxy Server, RedirectServer không bao giờ hoạt động nh một đầu cuối, tức là không gửi đi bất cứ yêu cầunào Redirect Server cũng không nhận hoặc huỷ cuộc gọi

Registrar Server là phần mềm nhận các yêu cầu đăng ký REGISTER Trong nhiềutrờng hợp Registrar Server đảm nhiệm luôn một số chức năng an ninh nh xác nhận ng-

ời sử dụng Thông thờng Registrar Server đợc cài đặt cùng với Proxy hoặc RredirectServer hoặc cung cấp dịch vụ định vị thuê bao Mỗi lần đầu cuối đợc bật lên ( thí dụmáy điện thoại hoặc phần mềm SIP ) thì đầu cuối lại đăng ký với Server Nếu đầu cuốicần thông báo cho Server về địa điểm của mình thì bản tin REGISTER cũng đợc gửi đi.Nói chung, các đầu cuối đều thực hiện việc đăng ký lại một cách định kỳ

Hình 3.1 Cấu trúc của một hệ thống SIP

3.1.3 Khái quát về hoạt động của SIP

Trong hội thoại SIP, mỗi bên tham gia ( bên gọi và bị gọi ) đợc gắn một địa chỉSIP hay còn gọi là SIP URL Ngời sử dụng phải đăng ký vị trí của họ với SIP server Đểtạo một cuộc gọi SIP, phía gọi định vị tới máy phục vụ thích ứng và sau đó gửi đi mộtyêu cầu SIP Hoạt động SIP thờng xuyên nhất là mời các thành viên tham gia hội thoại.Thành phần Registrar đóng vai trò tiếp nhận các yêu cầu đăng ký từ UA ( User Agent )

và lu trữ các thông tin này tại một dịch vụ bên ngoài SIP ( Non – SIP )

3.1.3.1 Địa chỉ SIP

Các thành viên tham gia hội thoại đợc định danh bởi một địa chỉ SIP gọi là SIPURL SIP URL đợc dùng trong các bản tin SIP để thông báo về nơi gửi ( from ), đíchhiện thời ( Request – URI ) và nơi nhận cuối cùng ( to ) của một yêu cầu SIP và chỉ rõ

địa chỉ gián tiếp Một SIP URL có thể gắn vào một trang Web hoặc những hyperlinkkhác để thông báo rằng ngời dùng hoặc dịch vụ có thể gọi thông qua SIP

3.1.3.2 Giao dịch SIP

Khi có địa chỉ IP của SIP server yêu cầu đợc gửi đi theo tầng vận chuyển ( giaothức ) TCP hay UDP Khách hàng gửi một hàng nhiều yêu cầu SIP tới SIP server vànhận các phúc đáp từ Server Một yêu cầu cùng với những phúc đáp ứng cho nhữngnhu cầu đó tạo nên một giao dịch SIP Tất cả các đáp ứng cho một yêu cầu phải chứacùng các giá trị trong trờng Call - ID Cseq, To và From Điều đó làm cho các đáp ứngphù hợp với các yêu cầu Mỗi cuộc gọi trong SIP đợc định danh bởi một bộ định danhcuộc gọi ( Call - ID )

Yêu cầu đợc gửi đi từ đâu ( From ) tới đâu ( To ) Trờng From và To đều theokhuôn dạng SIP - URL Trờng CSeq lu trữ thông tin về phơng thức sử dụng trongphiên, có dạng:

CSeq="CSeq": "DIGIT Method"

DIGIT là số nguyên không dấu 32 bit

 Nếu giao thức TCP đợc sử dụng, các yêu cầu và đáp ứng trong một giao dịchSIP đơn giản đều đợc truyền qua cùng một kết nối TCP Một số yêu cầu SIP từcùng một khách hàng đến cùng một Server có thể dùng một kiểu nối TCP hoặc

có thể dùng một kiểu kết nối mới cho mỗi yêu cầu

 Nếu khách hàng gửi yêu cầu thông qua giao thức UDP đơn hớng, các đáp ứng

sẽ đợc gửi đến các địa chỉ nằm trong trờng mào đầu "Via" của đáp ứng nếu yêucầu đợc gửi qua giao thức UDP đa hớng thì các đáp ứng sẽ đợc đa tới cùng một

điạ chỉ quảng bá và cổng đích Khuôn dạng bản tin SIP không phụ thuộc vàogiao thức truyền

3.1.3.3 Lời mời SIP

Một lời mời SIP gồm hai yêu cầu INTIVE và ACK Yêu cầu INTIVE mời thànhviên tham gia hội thoại khi phía bị gọi đồng ý tham gia, bên gọi xác nhận đã nhận đ ợc

đáp ứng đó bằng cách gửi một yêu cầu ACK Nếu phía gọi không muốn mời thành viêntham gia cuộc gọi nữa nó sẽ gửi yêu cầu BYE thay cho ACK

Thông điệp INTIVE chứa thành phần mô tả phiên ( SDP ) và phơng thức tiến hànhtrao đổi ứng với phiên đó Với các phiên đa hớng, "mô tả phiên" liệt kê kiểu và khuôndạng của các phơng tiện để phân phối cho phiên hội thoại Với một phiên đơn hớng,

"mô tả phiên" liệt kê kiểu và khuôn dạng của các phơng tiện mà phía gọi muốn sửdụng và nơi những dữ liệu muốn gửi đi

Trờng hợp máy phục vụ muốn uỷ quyền ( PS: Proxy Server ) Tiến trình xảy ra nhsau:

 Proxy Server tiếp nhận lời mời INTIVE

 PS tra cứu thông tin ở dịch vụ định vị ngoài SIP

 PS nhận về thông tin để tạo ra địa chỉ chính xác

 PS tạo lại INTIVE trong trờng Request - URI và chuyển tiếp

 UAS ( User Agent Server ) cảnh báo phía bị gọi

 PS nhận đáp ứng chấp nhận 200 OK từ UAS

 PS trả về kết quả thành công cho phía gọi

 Phía gọi gửi thông báo xác nhận ACK

 Yêu cầu xác nhận đợc chuyển tiếp qua PS

Chú ý: Một ACK có thể đợc gửi trực tiếp đến ngời đợc gọi qua Proxy Tất cả cácyêu cầu và đáp ứng phải có cùng Call - ID

Trờng hợp máy phục vụ gián tiếp Tiến trình xảy ra nh sau:

 PS tiếp nhận lời mời INTIVE

 Liên lạc với dịch vụ định vị

 Trả lời địa chỉ phía gọi

 Phía gọi gửi thông báo xác nhận ACK đến PS

 Phía gọi tạo một yêu cầu mới với cùng một Call - ID nhng có CSeq cao hơn tới

địa chỉ trả lời bởi Server đầu tiên

 Phía bị gọi gửi đáp ứng chấp nhận 200 OK

 Phía gọi gửi thông báo xác nhận ACK

3.1.3.4 Định vị ngời dùng

Ngời đợc gọi có thể di chuyển giữa các hệ thống đầu cuối khác nhau tại các thời

điểm khác nhau Những vị trí đó đợc đăng kí với SIP server Một máy định vị( Location Server ) có thể sử dụng một hay nhiều giao thức nh finger ( RFC1288[17] ),rwhois (RFC2167[18]), LDAP(RFC1777[19], multicast - based[[20], để xác định hệthống đầu cuối mà User có thể tới Một Location Server có thể trả lại vài vị trí mà User

đã đăng kí đồng thời tại nhiều Host hoặc bởi Location Server có lỗi SIP server sẽ tổngkết các kết quả để đa ra danh sách các vị trí.

Đối với các loại SIP server thì hoạt động sau khi nhận đợc các vị trí là khác nhau.Một SIP Redirect Server sẽ trả lại danh sách cho khách hàng với tiêu đề Contact MộtSIP Proxy Server có thể liên tục thử các địa chỉ cho đến khi cuộc gọi thành công hayngời đợc gọi từ chối cuộc gọi với cách thử tuần tự các địa chỉ Một Proxy Server có thểthực hiện một dịch vụ "anycast" Nếu Proxy Server gửi một yêu cầu SIP, nó phải bổsung thêm địa chỉ của chính nó vào phần đầu danh sách của "forwardes noted" trongtiêu đề Via Dấu hiệu Via đảm bảo rằng bản tin trả lời có thể lấy ra từ cùng một đ ờng( hớng ) ở hớng đáp ứng, mỗi Host phải gỡ bỏ tiêu đề Via của chính nó, vì thế thôngtin đợc truyền nội bộ sẽ "ẩn " đối với phía bị gọi và mạng bên ngoài Proxy Server phảikiểm tra xem nó có phát yêu cầu tới danh sách Host (host listed) chứa trong các tham

số Via rent - by, Via received hay Via - maddr

3.1.3.5 Thay đổi một phiên hiện tại

Trong một vài trờng hợp cần phải thay đổi các thông số của một phiên hội thoạihiện tại Việc đó đợc thực hiện bởi việc phát lại các INTIVE Các INTIVE đó có cùngtrờng Call - ID nhng có trờng tiêu đề và thân bản tin khác để mang những thông tinmới Các bản tin INVITE đó phải có CSeq cao hơn các yêu cầu trớc

Ví dụ: Có hai thành viên đang hội thoại và muốn có thêm một ngời thứ ba Mộttrong các thành viên sẽ mời thành viên thứ ba tham gia với một địa chỉ "multicast" mới

và đồng thời gửi một bản tin INTIVE đến thành viên thứ hai với trờng miêu tả phiên

“multicast” nhng có Call - ID cũ

3.1.4 Các loại bản tin SIP

SIP là giao thức dạng TEXT sử dụng bộ kí tự ISO 10646 trong mã hoá Điều nàytạo cho SIP tính linh hoạt và mở rộng dễ thi hành các ngôn ngữ lập trình cấp cao nhJava, Tol, Perl Cú pháp của SIP gần giống với giao thức HTTP, cho phép dùng lại mã

và đơn giản hoá sự liên kết của các máy phục vụ SIP với các máy phục vụ Web

Một bản tin SIP có thể là một yêu cầu từ khách hàng tới một Server hay một đápứng từ Server gửi lại khách hàng Cả hai loại bản tin này đều sử dụng chung một địnhdạng cơ bản đợc quy định trong RFC 2822 với cấu trúc gồm một dòng khởi đầu( start - line ), một số trờng tiêu đề và và một phần thân bản tin tùy chọn Cấu trúc này

(general - header)Message - header = /Request - header /Respone - header

/(entity - header)Dòng khởi đầu, các dòng tiêu đề hay dòng trống phải đợc kết thúc bằng một kí tự xuống dòng ( CRLF ) và phải lu ý rằng dòng trống vẫn phải có để ngăn cách phần tiêu

đề và thân của bản tin ngay cả khi phần thân bản tin là rỗng

3.1.4.1 Bản tin Request

Các bản tin SIP đợc phân biệt với nhau dựa vào dòng đầu tiên ( Start - line ).Trong đó, các bản tin yêu cầu có dòng khởi đầu là một dòng yêu cầu ( Request - line ).Dòng này chứa tên phơng thức, một Request - URI, và một số phiên bản giao thức Cácthành phần đợc ngăn cách với nhau bằng một kí tự trắng ( SP ) Cũng nh các dòngkhác, dòng khởi đầu đợc kết thúc bằng một kí tự xuống dòng CRLF

Khuôn dạng bản tin Request:

Request = Request - line ( general - header/Request - header/entity - header ) CLRF

đã sẵn sàng tham gia bằng đáp ứng 200 OK - Respone

Nếu nh một UA ( User Agent ) nhận đợc một yêu cầu INVITE cho Call leg với sốCSeq cao hơn các INVITE trớc có cùng Call - ID, nó sẽ kiểm tra các từ định danhVersion thì nội dung của phần miêu tả phiên sẽ đợc xem xét nếu nó muốn thay đổi và

UA phải xem xét các trờng tiêu đề cho việc thay đổi Nếu nh có một sự thay đổi, UAphải cập nhật những trạng thái nội bộ hoặc những thông tin phát ra nh kết quả của tiêu

đề đó Nếu miêu tả phiên thay đổi, UAS phải điều chỉnh lại các thông số phiên hộithoại cho phù hợp sau khi yêu cầu User xác nhận Chỉ thị này đợc đa ra bởi SIP Proxy,Redirect Server và UAS cũng nh khách hàng

 ACK

Yêu cầu ACK xác nhận rằng khách hàng đã nhận đợc đáp ứng cuối cùng cho yêucầu INVITE ( ACK chỉ sử dụng cho yêu cầu INVITE ) Khi UAC chấp nhận đáp ứng2xx, tất cả các đáp ứng cuối cùng khác của Proxy đầu tiên hay của UAC đều nhận đợctrả lời Trờng Via đợc đa vào Host để phát ra yêu cầu ACK sau khi UAC nhận đợc một

đáp ứng 2xx hoặc Proxy đầu tiên nhận đợc một đáp ứng non - 2xx

Yêu cầu ACK có thể chứa một thân bản tin ( message body ) với phần miêu tảphiên cuối cùng dùng cho ngời đợc gọi Nếu nh thân bản tin ACK rỗng, ngời đợc gọi

sẽ sử dụng phần miêu tả phiên trong yêu cầu INVITE

Một Proxy Server nhận một yêu cầu ACK sau khi gửi đi các đáp ứng 3xx,4xx,5xxhay 6xx phải quyết định ACK là của nó hay là cho các UA hoặc Proxy Server phía bênkia Quyết định đó dựa vào việc xem xét thẻ địa chỉ trong trờng To Nếu thẻ địa chỉtrong trờng tiêu đề To của ACK phù hợp với thẻ địa chỉ trong trờng tiêu đề To của đápứng và các trờng tiêu đề From, Call - ID, CSeq của đáp ứng phù hợp với các trờng củaACK thì chứng tỏ rằng ACK là dành cho Proxy Server Chỉ thị này phải đợc đa ra bởiSIP Proxy, Redirect Server, UA cũng nh khách hàng

 OPTION

Chỉ thị OPTION dùng để hỏi về khả năng của SIP Server Nếu một Server có khảnăng liên lạc với User có thể đáp ứng lại yêu cầu OPTION bằng một tập hợp các khảnăng của nó Chỉ thị này đợc đa ra bởi SIP Proxy, Redirect Server, UA, Register,Client

Các trờng Call - ID, CSeq, To, From trong CANCEL đều giống nh trong yêu cầugốc ( yêu cầu mà nó muốn huỷ bỏ ) Tuy nhiên để khách hàng phân biệt đợc các đápứng cho CANCEL với các đáp ứng cho yêu cầu gốc thì thành phần CSeq Method sẽ đ-

ợc thiết lập trong CANCEL

Khi một UAS nhận đợc yêu cầu CANCEL, nó không phải phát ra một đáp ứng2xx cho yêu cầu huỷ bỏ

Redirect Server và UAS khi nhận đợc một yêu cầu CANCEL sẽ đáp ứng bằng mộttrạng thái là 200 nếu nh tồn tại giao dịch SIP và trạng thái là 481 nếu không tồn tạigiao dịch

 REGISTER

Chỉ thị REGISTER đợc dùng để đăng kí danh sách địa chỉ của ngời dùng trong ờng tiêu đề To với SIP server Nh vậy chỉ thị này dùng để đăng kí thông tin ngời dùng

tr-b) Request - URI

Trờng Request - URI có khuôn dạng theo SIP URL Nó thông báo cho ngời dùnghoặc dịch vụ về địa chỉ hiện tại Khác với trờng To, Request - URI có thể đợc ghi lạibởi Proxy (máy phục vụ uỷ quyền) Khi sử dụng nh một Request - URI, SIP URLphải chứa các tham số transport - param, maddr - param, ttl - param và các thành phầntiêu đề Một Server khi nhận đợc một SIP URL, địa chỉ SIP với những thành phần đó

sẽ huỷ bỏ chúng trớc khi tiến hành xử lí

Điển hình là, UAS thiết lập trờng Request - URI và trờng To trong cùng một SIPURL coi nh không thay đổi trong một khoảng thời gian dài Tuy nhiên, nếu nh UACdành cho phía bị gọi nhiều hớng trực tiếp, từ trờng tiêu đề Contact của một đáp ứng choyêu cầu trớc đó, trờng To sẽ vẫn chứa các thông số long - term, địa chỉ "public" trongkhi Request - URI có thể thiết lập các địa chỉ dự phòng Proxy Server và RedirectServer dùng những thông tin chứa trong trờng Request - URI và trờng tiêu đề của yêucầu để quản lí các yêu cầu và ghi lại trờng Request - URI

Host - port của Request - URI điển hình phù hợp với một trong các "host name"của Server nhận Nếu không, Server phải uỷ quyền cho yêu cầu tới địa chỉ "Indicate"hoặc trả lại đáp ứng 404 ( not found: không tìm thấy ) nếu nó không muốn hay khôngthể thực hiện đợc

Nếu SIP Server nhận đợc một yêu cầu với một URI "indicating" với một cấu trúckhác hơn SIP mà Server đó không hiểu đợc, Server phải gửi lại một đáp ứng 400 ( BadRequest ) Nó phải thực hiện việc đó ngay cả khi trờng tiêu đề To chứa một cấu trúc

mà nó không hiểu

 SIP Version

Cả bản tin Request và Repone đều chứa phiên bản của SIP đợc sử dụng tơng tự

nh trong bản tin HTTP Hiện nay, có hai phiên bản SIP đợc kí hiệu là SIP và SIP/2.0

 Option Tag

Option tag đợc dùng để chỉ định định rõ các lựa chọn mới trong SIP Các thể lựachọn đợc sử dụng trong trờng Supported, Unsupported và Require

Cú pháp: Option - tag = token

New Option đợc đăng kí bởi tổ chức IANA ( Internet Assigned Number Authority ).Khi đăng kí thì cần phải có các thông tin sau:

 Tên và mô tả của "Option" Tên có độ dài không quá 20 ký tự

 Thông báo về tổ chức có quyền thay đổi "Option"

 Thông tin liên lạc ( hòm th hay địa chỉ email )

 Đăng ký phải đợc gửi tới iana@iana.org

giải thích ý nghĩa của bản tin trả lời Mỗi thành phần cũng đợc phân biệt với nhau bằngmột kí tự trắng SP ở cuối dòng, kí tự xuống dòng CRLF đợc sử dụng để tách biệt nóvới dòng tiếp theo trong bản tin.

Khuôn dạng bản tin nh sau:

Respone = Status - line

( General - header/ Respone - header/ entity - header )

Status Phrase thì đa ra một bản yêu cầu ngắn theo đúng nguyên văn của Status Code Status - Code dùng cho máy còn Reason - Phrase là dùng cho ngời sử dụng.Khách hàng không thể yêu cầu hiển thị hay kiểm tra Status - Phrase

-Status - code gồm 3 digit Digit đầu tiên định nghĩa loại đáp ứng Hai digit saukhông có vai trò phân loại Bản SIP /2.0 cho phép 6 giá trị của digit đầu tiên nh sau:

 1xx: Informational : Nhận và xử lý yêu cầu

 2xx: Success : Thành công

 3xx: Redirect : Chuyển tiếp yêu cầu

 4xx: Client - Error : Lỗi ngời dùng, cú pháp của yêu cầu lỗi không thoả mãn Server

 5xx: Server - Error : Lỗi máy phục vụ

 6xx: Global - Farlure : Yêu cầu không đợc đáp ứng tại mọi ServerDới đây là ví dụ một số giá trị riêng của 6 digit đầu tiên của Response Code vàReason Phrase chú thích mã tơng ứng là đáp ứng gì:

Informational = "100" ; Trying

Success = "200" ; OK

Redirection = "300" ; Multiple Choices

Client - Error = "400" ; Bad Request

Server - Error = "500" ; Internal Server Error

Global - Failure = “ 600 “ ; Busy Everywhere

Mã đáp ứng SIP có thể mở rộng đợc Các ứng dụng SIP không yêu cầu phải hiểu

rõ về ý nghĩa của tất cả mã đáp ứng đợc đăng ký mà chỉ cần hiểu các loại mã đáp ứng,

ý nghĩa của digit đầu tiên

3.1.5 Thân bản tin SIP ( SIP Message Body )

3.1.5.1 Body Inclusion

Yêu cầu chứa các thân bản tin trừ khi có lu ý khác Trong đặc tả này, yêu cầuCANCEL không chứa một thân bản tin Còn đối với các chỉ thị ACK, INTIVE,OPTIONS, thân bản tin bao giờ cũng là một miêu tả phiên Việc sử dụng thân bản tincho yêu cầu REGISTER đang đợc nghiên cứu thêm

Với bản tin đáp ứng, chỉ thị yêu cầu và mã trạng thái đáp ứng xác định kiểu và sựthể hiện của các thân bản tin Tất cả các đáp ứng đều gồm một thân bản tin Thân bảntin cho đáp ứng 1xx chứa thông tin t vấn về tiến trình của yêu cầu Trong đáp ứng 2xxcho yêu cầu INTIVE thân bản tin chứa miêu tả phiên Trong đáp ứng 3xx thân bản tinchứa miêu tả về các đích chọn lựa hay dịch vụ Với các đáp ứng 4xx và lớn hơn, thânbản tin gồm các thông tin bổ sung, các thông tin con ngời có thể đọc đợc về cácnguyên nhân gây lỗi

3.1.5.2 Kiểu thân bản tin ( Message Body Type )

Kiểu truyền thông của thân bản tin đợc chỉ ra bởi trờng tiêu đề Content - Type Nếuthân bản tin đã qua mã hoá thì nó đợc chỉ ra bởi trờng tiêu đề Content - Encoding Tậphợp các kí tự của thân bản tin đợc chỉ ra bởi trờng tiêu đề Content - Type

3.1.5.3 Độ dài thân bản tin ( Message Body Length )

Độ dài thân bản tin tính theo Byte đợc đa ra bởi trờng tiêu đề Content - Length

3.1.6 Khuôn dạng thoả thuận ( Comfact From )

Khi SIP đợc truyền thông qua giao thức UDP với sự xác thực và một miêu tả phiênphức tạp thì độ dài của một yêu cầu hay đáp ứng SIP sẽ lớn hơn MTU Để giải quyếtvấn đề này, khuôn dạng thoả thuận của SIP đợc định nghĩa bằng cách sử dụng các từviết tắt cho các trờng tiêu đề chung, đợc miêu tả dới đây:

Tên trờng ngắn Tên trờng dài

3.2 Định nghĩa các trờng tiêu đề và mã trạng thái trong bản tin SIP 3.2.1 Định nghĩa các trờng tiêu đề

Các trờng tiêu đề của SIP giống với các trờng tiêu đề của HTTP về cả cú pháp vàngữ nghĩa Các trờng tiêu đề gồm tiêu đề chung, tiêu đề yêu cầu, tiêu đề đáp ứng, tiêu

 “m” (mandatory): bắt buộc Một trờng tiêu đề yêu cầu bắt buộc phải cómặt trong một yêu cầu, và trờng tiêu đề phải đợc UAC hiểu trong quá trình

xử lý đáp ứng

 “_” (not applicate): không sử dụng đợc Có nghĩa là các trờng tiêu đềkhông đợc tồn tải trong một yêu cầu Nếu một trờng nào đó có trong yêucầu do lỗi thì nó phải đợc UAS bỏ qua trong quá trình nhận yêu cầu

 “*”: chỉ ra rằng trờng tiêu đề chỉ cần thiết nếu thân bản tin không rỗng

 “m*”: chỉ thị một tiêu đề nên đợc gửi, nhng Server cần phải chuẩn bị nhậncác yêu cầu mà không có trờng tiêu đề đó

Cột “Where” miêu tả kiểu yêu cầu và đáp ứng mà trờng tiêu đề đợc sử dụng

 “g”: đặt tên trờng tiêu đề chung

 “e”: đặt tên trờng tiêu đề thực thể

 “c”: sao chép trờng tiêu đề từ yêu cầu đến đáp ứng

Cột “proxy” chỉ ra các Proxy có thể thêm các thành phần riêng biệt vào các tiêu

đề hay không

Trong đó:

 “c”: chỉ thị cho móc nối

 “m”: có thể thay đổi tiêu đề

 “a”: có thể thêm tiêu đề nếu không tồn tại

 “r”: đọc tiêu đề

Bảng 3.1 Tóm tắt các trờng tiêu đềHeader Field where proxy ACK BYE CAN INV OPT REG

Bảng 3.1 Tóm tắt các trờng tiêu đề (tiếp)

Retry - After

404,413,480,486,500,503,600,603

3.2.1.1 Khuôn dạng trờng tiêu đề

Các trờng tiêu đề kể trên thờng gồm tên trờng, sau đó là dấu ”:”, và giá trị của ờng

tr-Khuôn dạng của trờng tiêu đề bản tin nh sau:

message - header = field - name ":" [ field - value ] CRLF

field - name = token

field - value = *( field - content | LWS )

Trong đó field - content là các OCTET tạo nên giá trị trờng tiêu đề và bao gồm * TEXT - UTF8 hoặc sự kết hợp của token, separators và quoted - string

3.2.1.2 Các trờng tiêu đề chung

Các trờng tiêu đề chung áp dụng cho cả các bản tin yêu cầu và bản tin đáp ứng.Các tên trờng “general- header” có thể đợc mở rộng khi kết hợp với sự thay đổi vềphiên bản giao thức Tuy nhiên, trờng tiêu đề mới hoặc đang thử nghiệm có thể cónghĩa nh các trờng tiêu đề chung nếu tất cả các bên trong phiên truyền thông đều nhậnbiết đợc chúng là các trờng “tiêu đề chung” Các trờng tiêu đề không nhận biết đợc xử

lý nh các trờng “tiêu đề thực thể”

1) Tiêu đề Accept

Khi có sự xuất hiện của trờng Accept, Server sẽ phát đi một giá trị mặc định củaứng dụng /sdp Giống nh một trờng tiêu đề yêu cầu, nó chỉ đợc sử dụng trong các chỉthị có thân bản tin.

2) Tiêu đề Accept - Endcoding

Trờng tiêu đề yêu cầu Accept - Endcoding cũng giống nh tiêu đề Accept nhng hạnchế mã nội dung biểu diễn sự chấp nhận của đáp ứng

3) Tiêu đề Accept - Language

Cú pháp phần tiêu đề ngôn ngữ chấp nhận quy định về lệnh trong ngôn ngữ dựavào tham số q giống nh áp dụng vào SIP Trờng tiêu đề yêu cầu Accept - Language chophép Client thông báo cho Server ngôn ngữ nó mong muốn để nhận reason phrases,miêu tả phiên hay đáp ứng trạng thái đợc truyền tải nh thân bản tin Một Proxy có thể

sử dụng trờng này để trợ giúp việc lựa chọn đích đối với các cuộc gọi

4) Tiêu đề Call -ID

Trờng tiêu đề chung Call - ID xác định một lời mời thành viên hoặc tất cả các

đăng ký của một Client thành viên một cách duy nhất Chú ý rằng một hội nghị đa

ph-ơng tiện đơn giản có thể thêm vài cuộc gọi với các Call - ID khác nhau, nếu ngời sử dụng mời nhiều lần khác nhau đến cùng một hội nghị

Đối với một yêu cầu INVITE, một UAS bị gọi không nên cảnh báo với ngời sửdụng đó nếu ngời sử dụng đã đáp lại Call - ID trong yêu cầu INVITE Nếu ngời sửdụng đã là một thành viên của hội nghị và các tham số của hội nghị đã đợc chứa trongmiêu tả phiên không có thay đổi, thì UAS bị gọi này có thể chấp nhận cuộc gọi bấtchấp Call - ID Một lời mời cho Call - ID hoặc phiên hiện tại có thể thay đổi các tham

số của hội nghị Một ứng dụng của Client có thể đa ra một chỉ thị đơn giản tới ngời sửdụng về các tham số của hội nghị đã đợc thay dổi và chấp nhận cuộc gọi tự động hoặc

nó có thể yêu cầu ngời sử dụng xác nhận

Một ngời sử dụng có thể đợc mời đến cùng một hội nghị hoặc cuộc gọi sử dụngnhiều Call - ID khác nhau Client có thể loại những bản sao này nếu muốn bằng cách

sử dụng các nhận dạng trong miêu tả phiên

Chỉ thị REGISTER và OPTION sử dụng giá trị Call - ID để yêu cầu đợc giốnghoàn toàn với đáp ứng Tất cả các yêu cầu REGISTER đa ra bởi một Client phải cócùng một Call - ID

5) Tiêu đề Contact

Trờng tiêu đề chung Contact có thể xác nhận trong yêu cầu INVITE, OPTION,ACK, REGISTER và trong đáp ứng 1xx, 2xx, 3xx và 485 Thông thờng nó cung cấpURL để ngời sử dụng có thể có các giao tiếp xa hơn

 Các yêu cầu INVITE, OPTION và ACK: Các yêu cầu INVITE bắt buộc và yêucầu ACK có thể chứa tiêu đề Contact để chỉ ra vị trí khởi tạo yêu cầu Đối vớiOPTION, Contact đa ra gợi ý về địa chỉ các yêu cầu SIP có thể đợc gửi đến

 Các đáp ứng 2xx INVITE và OPTION: Một Server gửi đáp ứng 2xx có thể chènvào một tiêu đề đáp ứng Contact để chỉ ra địa chỉ SIP trong cùng một Call - ID Tr-ờng tiêu đề Contact chứa địa chỉ của Server hoặc của Proxy, nếu Host ở phíasau tờng lửa Giá trị tiêu đề đợc sao chép vào trờng Request - URI của yêu cầutiếp theo cho cuộc gọi này Nếu đáp ứng không chứa tiêu đề Record - Route thì

địa chỉ trong trờng tiêu đề Contact đợc bổ sung nh phần tử cuối cùng trong ờng tiêu đề Route Nếu một UA sử dụng cả TCP và UDP nó không nên chỉ thịmột tham số truyền tải trong URI

tr- Các đáp ứng INVITE 1xx: Một UAS gửi một đáp ứng 1xx có thể chèn vào tiêu

đề đáp ứng Contact Nó cũng có ý nghĩa nh đáp ứng 1xx và đáp ứng Invite 2xx.Chú ý rằng yêu cầu CANCEL phải không đợc gửi đến địa chỉ đó, đúng hơn là

nó cùng đờng dẫn nh yêu cầu ban đầu

 Các yêu cầu RIGISTER: Yêu cầu REGISTER có thể chứa trờng tiêu đề Contactchỉ ra vị trí ngời sử dụng có thể đến Yêu cầu RIGISTER định nghĩa trờngContact “*” chỉ đợc sử dụng với expire ‘0’ để loại bỏ tất cả các đăng ký ngời sửdụng đặc biệt Một tham số expire tuỳ chọn chỉ ra thời gian kết thúc của đăng

ký Nếu Contact nào không có tham số expire thì trờng tiêu đề expires đợc sửdụng nh giá trị mặc định

 Các đáp ứng 2xx REGISTER : Một đáp ứng REGISTER có thể quay về tất cảcác vị trí mà ngời sử dụng hiện tại có thể đạt đến Một tham số expire mặc địnhchỉ ra thời gian kết thúc của đăng ký

 Các đáp ứng 3xx và 405 : Trờng tiêu đề đáp ứng Contact có thể sử dụng chungvới mã đáp ứng 3xx và 485 để chỉ ra một hoặc nhiều địa chỉ thay thế Nó có thểxuất hiện trong các đáp ứng trong chỉ thị BYE, INVITE, OPTION Trờng tiêu

đề Contact chứa URIs đa ra vị trí mới hoặc tên của User để thử hoặc có thể làcác tham số truyền tải bổ sung đặc biệt

 Các đáp ứng 4xx, 5xx, 6xx: Trờng tiêu đề đáp ứng CONTACT có thể đợc sửdụng trong các đáp ứng 4xx, 5xx, 6xx để chỉ ra vị trí để bổ xung thông tin vềlỗi có thể tìm ra

Một trờng tiêu đề đáp ứng Contact có thể chứa bất kỳ URI thích hợp để chỉ ra bịgọi nào có thể đạt đợc, không hạn chế SIP URLs

Các tham số sau đợc định nghĩa:

- q: giá trị q chỉ ra u tiên tơng đối giữa vị trí cho trớc, 0<q<1, q càng lớn độ u tiêncàng cao

- Action: tham số “action” đợc sử dụng chỉ khi đăng ký với yêu cầu REGISTER.Nếu tham số này không đợc đặc tả hoạt động xảy ra phụ thộc vào cấu hìnhServer thì trong các đáp ứng của nó, các bản sao phải chỉ ra chế độ đợc sử dụng.Tham số này không đợc chú ý trong các yêu cầu khác nhau

- Expire : Tham số expire chỉ ra URI có giá trị trong bao lâu

6) Tiêu đề Date

Là một trờng tiêu đề chung phản ánh thời gian khi yêu cầu hoặc đáp ứng đợc gửi

đi lần đầu Vì vậy mà các bản tin truyền lại có cùng giá trị trờng tiêu đề dữ liệu nh bảntin đầu tiên

7) Tiêu đề Encryption

Trờng tiêu đề mã hoá chung đặc tả nội dung đợc mã hoá Trờng tiêu đề này thờng

sử dụng cho các yêu cầu và đáp ứng end - to - end Yêu cầu đợc mã hoá dựa trên khoácông cộng phụ thuộc vào thực thể đợc đặt tên trong trờng tiêu đề To Đáp ứng đợc mãhoá dựa trên khoá công cộng truyền trong trờng tiêu đề khoá đáp ứng Chú ý rằng bảnthân khoá công cộng không đợc sử dụng để mã hoá Điều này phụ thuộc vào từng thuậttoán đợc sử dụng

Đối với bất kỳ bản tin đã mã hoá nào, thì ít nhất có phần thân bản tin và có thể cáctrờng tiêu đề khác đợc mã hoá Một ứng dụng nhận một yêu cầu hay đáp ứng chứa mộttrờng tiêu đề Encrytion giải mã thân thực thể sau đó ghép bản tin gốc đến đờng dâyyêu cầu và đến các tiêu đề của bản tin ban đầu Tiêu đề bản tin cuả phần đã giải mãthay thế hoàn toàn tiêu đề bản trong phần bản tin gốc với các trờng có cùng tên

Mã hoá chỉ để cung cấp sự bí mật : phía đích không đảm bảo rằng yêu cầu hoặc

đáp ứng từ phía gửi đợc liệt kê trong tiêu đề bản tin From, mà chỉ đảm bảo rằng phíagửi sử dụng khóa công cộng của phía đích Tuy nhiên, các Proxy không có khả năngthay đổi yêu cầu hoặc đáp ứng

Vì các Proxy có thể dựa vào sự quy định trớc của chúng để kết hợp bất kỳ trờngtiêu đề SIP nào, nên không có sự đảm bảo rằng các yêu cầu đã mã hoá có các trờng tiêu

đề “ẩn” sẽ đạt đến cùng đích nh yêu cầu không mã hoá đợc định danh khác nhau.8) Tiêu đề From

Các đáp ứng và yêu cầu phải có trờng tiêu đề chung From để chỉ ra bộ khởi đầuyêu cầu Server sao chép trờng tiêu đề From từ yêu cầu vào đáp ứng Trờng From cóthể có tham số Tag Giá trị Tag thờng là duy nhất và đợc mã hoá ngẫu nhiên 32 bit.Một User duy trì giá trị Tag thông suốt trong một cuộc gọi đã định danh bằng Call - ID.9) Tiêu đề Organization

Trờng tiêu đề chung Organization hoặc truyền tên của tổ chức mà thực thể đa rayêu cầu hoặc đáp ứng phụ thuộc vào Trờng này có thể đợc sử dụng bằng phần mềmClient để lọc các cuộc gọi

10) Tiêu đề Record - route

Trờng tiêu đề đáp ứng và yêu cầu Record - Route đợc bổ sung vào một yêu cầubởi một proxy bất kỳ trong đờng các yêu cầu tiếp theo cho cuộc gọi cùng nhánh Nóchứa các SIP - URL có thể đến để xác định Proxy Server, gồm có một tham số địa chỉ( maddr ) xác định vị trí của nó Mỗi Proxy Server bổ sung Request - URI vào đầu củadanh sách Server sao chép trờng tiêu đề Record- route vào trờng tiêu đề Route của các