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 sip 3.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ỏa cá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ại hộ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ể đem lạ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ời bắ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 đầu cá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ết lậ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ếp mộ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ên ISDN, 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 do IETF khuyến nghị nh RSVP ( giao thức giữ trớc tài nguyên ), RTP ( giao thức truyền tả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ồi dù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ài nguyê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ác Proxy 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ị đa phơng, hội nghị nhiều mắt lới ( full – mesh ), cuộc gọi hai thành viên, Một và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 đến UAS ).

 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ên hộ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ầu ACK

 Parallel search: Trong một quá trình tìm kiếm song song một Proxy đa ra một và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ông bá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ững ngờ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ác phầ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ối cùng từ Server gửi trả lại Client Nó đợc nhận biết bởi số thứ tự CSeq Yêu cầu ACK có cùng số CSeq với yêu cầu INVITE tơng ứng nhng chứa một giao dịch củ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ính củ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ện cá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 Proxy Server nếu có thể, hoặc đợc chuyển cho các máy chủ khác Trong trờng hợp Proxy Server 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âu chuyể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 sang một số địa chỉ khác và gửi lại cho đầu cuối Không giống nh Proxy Server, Redirect Server 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ầu nà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ều trờ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 Rredirect Server 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ối cầ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ột yê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à SIP URL SIP URL đợc dùng trong các bản tin SIP để thông báo về nơi gửi ( from ), đích hiệ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 hyperlink khá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 ( giao thứ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ững nhu 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ứa cùng các giá trị trong trờng Call - ID Cseq, To và From Điều đó làm cho các đáp ứng phù 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 danh cuộ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 theo khuôn dạng SIP - URL Trờng CSeq lu trữ thông tin về phơng thức sử dụng trong phiê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ịch SIP đơ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êu cầ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ào giao 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ành viê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ên tham 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ành trao đổ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ôn dạ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 nh sau:

 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ác yê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ổng kế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ột SIP Proxy Server có thể liên tục thử các địa chỉ cho đến khi cuộc gọi thành công hay ngờ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" trong tiê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ông tin đợ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ải kiể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ại hiệ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ùng trờng Call - ID nhng có trờng tiêu đề và thân bản tin khác để mang những thông tin mớ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ột trong 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ày tạ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 nh Java, 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 định dạ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ác thà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òng khá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 )

Chỉ thị INTIVE thông báo rằng User hoặc dịch vụ đợc mời tham gia vào một phiên hội thoại Một Server sẽ tự động trả lời một lời mời tham gia hội thoại nếu User đã 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 danh Version 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, UA phả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ội thoạ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êu cầu INVITE ( ACK chỉ sử dụng cho yêu cầu INVITE ) Khi UAC chấp nhận đáp ứng 2xx, 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 đợc trả 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,5xx hay 6xx phải quyết định ACK là của nó hay là cho các UA hoặc Proxy Server phía bên kia 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ủa ACK thì chứng tỏ rằng ACK là dành cho Proxy Server Chỉ thị này phải đợc đa ra bởi SIP 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.

 BYE

UAC sử dụng chỉ thị BYE để thông báo cho Server rằng nó muốn giải phóng cuộc gọi Yêu cầu BYE cũng giống nh một yêu cầu INTIVE chứa một tiêu đề Contact, ngời đợc gọi phải gửi yêu cầu BYE tới địa chỉ Chỉ thị này phải đợc đa ra bởi một Proxy Server và không hỗ trợ bởi Redirect Server và UAS.

 CANCEL

Yêu cầu CANCEL đợc dùng để huỷ bỏ một yêu cầu sắp đợc thực hiện với cùng giá trị trong các trờng Call - ID, From, To và CSeq của yêu cầu đó.

UAC hay Proxy khách hàng có thể phát ra một yêu cầu CANCEL tại mọi lúc Proxy trong trờng hợp đặc biệt có thể gửi một yêu cầu CANCEL tới đích mà không trả lại một đáp ứng cuối cùng sau khi nó đã nhận đợc các đáp ứng 2xx hay 6xx cho một hay nhiều yêu cầu tìm kiếm song song ( paralled – seach ).

Các trờng Call - ID, CSeq, To, From trong CANCEL đều giống nh trong yêu cầu gố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 ứng 2xx 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ột trạ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ại giao dịch

 REGISTER

Chỉ thị REGISTER đợc dùng để đăng kí danh sách địa chỉ của ngời dùng trong tr-ờ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.

b) Request - URI

Trờng Request - URI có khuôn dạng theo SIP URL Nó thông báo cho ngời dùng hoặ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ại bởi Proxy (máy phục vụ uỷ quyền) Khi sử dụng nh một Request - URI, SIP URL phải chứa các tham số transport - param, maddr - param, ttl - param và các thành phần tiê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 SIP URL coi nh không thay đổi trong một khoảng thời gian dài Tuy nhiên, nếu nh UAC dà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 cho yêu cầu trớc đó, trờng To sẽ vẫn chứa các thông số long - term, địa chỉ "public" trong khi Request - URI có thể thiết lập các địa chỉ dự phòng Proxy Server và Redirect Server dùng những thông tin chứa trong trờng Request - URI và trờng tiêu đề của yêu cầ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ông thể 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úc khác hơn SIP mà Server đó không hiểu đợc, Server phải gửi lại một đáp ứng 400 ( Bad Request ) 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ựa chọ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.

3.1.4.2 Bản tin Respones

Các bản tin đáp ứng đợc phân biệt với các bản tin yêu cầu bằng một dòng trạng thái ( Status -line ) đợc đặt ở dòng khởi đầu của bản tin Dòng trạng thái của bản tin đáp ứng bao gồm tên phiên bản giao thức SIP, một mã trạng thái và một cụm văn bản

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ằng mộ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 ) CRLF

[ message - body ] Trong đó:

Status - Line = SIP - Version SP status - Code SP Reason - Phrase CRLF Status - Code là một mã kết quả nguyên gồm 3 digit chỉ ra kết quả của việc cố gắng hiểu và đáp ứng yêu cầu.

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 sau khô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 Server Dớ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ầu CANCEL 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 tin cho 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ản tin 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 2xx cho 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 tin chứ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ân bả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ác nguyê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ếu thân bản tin đã qua mã hoá thì nó đợc chỉ ra bởi trờng tiêu đề Content - Encoding Tập hợ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ên phứ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ết vấ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

Client có thể dùng cả tên trờng ngắn và tên trờng dài trong cùng một yêu cầu và Server cũng chấp nhận điều đó.

3.2 Định nghĩa các trờng tiêu đề và mã trạng thái trong bản tin SIP3.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 đề thực thể.

Các trờng tiêu đề yêu cầu và tùy chọn, không dùng đợc cho mỗi chỉ thị đợc liệt kê trong bảng 3.1.

Trong đó:

 “o” (optional): chỉ ra tùy chọn Tùy chọn có nghĩa rằng một UA có thể chứa trờng tiêu đề trong một yêu cầu và đáp ứng và UA có thể bỏ qua tr-ờng tiêu đề nếu nó tồn tại trong một yêu cầu và đáp ứng.

 “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êu cầ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ận

cá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 Trong đó:

 “R”: đề cập đến các trờng tiêu đề đợc sủ dụng trong các yêu cầu (đó là các trờng tiêu đề chung và yêu cầu).

 “r”: chỉ định một trờng tiêu đề chung hay đáp ứng, áp dụng cho tất cả các đáp ứ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)

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 tr-ờng.

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ận biế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ạn chế 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ựa vào tham số q giống nh áp dụng vào SIP Trờng tiêu đề yêu cầu Accept - Language cho phé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 trong miê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ất chấ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ụng nhiề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ống hoà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ấp URL để 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êu cầu ACK có thể chứa tiêu đề Contact để chỉ ra vị trí khởi tạo yêu cầu Đối với OPTION, 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èn và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ía sau tờng lửa Giá trị tiêu đề đợc sao chép vào trờng Request - URI của yêu cầu tiế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 tr-ờ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.

 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 đề Contact chỉ ra vị trí ngời sử dụng có thể đến Yêu cầu RIGISTER định nghĩa trờng Contact “*” 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 định chỉ 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 chung vớ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ên cà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ình Server 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ản tin đầ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ản thâ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ật toá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ác trờ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ột trờng tiêu đề Encrytion giải mã thân thực thể sau đó ghép bản tin gốc đến đờng dây yê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ía gử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ăng thay đổ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ờng tiê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 đầu yê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 ra yê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ềm Client để 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ầu bở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ủa danh sách Server sao chép trờng tiêu đề Record- route vào trờng tiêu đề Route của các