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ỳ. 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à l−u 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 l−u 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 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. (adsbygoogle = window.adsbygoogle || []).push({});
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 nh−ng 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 nh−ng 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” nh−ng 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 đ−ợc tóm tắt nh− sau:
generic - message = start - line *message - header
CRLF
[message - body] Trong đó:
Start - line = Request - line/Status - line (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 l−u ý 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 ) CLRF (adsbygoogle = window.adsbygoogle || []).push({});
[ message - body ]
Request - line = Method SP Request - URIP SIP - Version CRF
a) Methods (Các chỉ thị)
SIP định nghĩa 6 chỉ thị sau:
Methods = INTIVE/ACK/OPTION/BYE/CANCEL/REGISTER
• INTIVE
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ỉ