Nghiên cứu Giao thức Khởi tạo Phiên (SIP) trong Hệ thống Điện thoại qua Internet (VoIP)

MỤC LỤC

Kiến trúc các hệ thống chuyển mạch

Trong hệ thống chuyển mạch mềm các Media Gateway MG thực hiện chức năng giám sát trạng thái các đầu cuối, sau đó gửi thông tin về cho , Media Gateway Controller MGC xử lý, MGC xử lý cuộc gọi và điều khiển MG chuyển mạch vật lý để tạo kênh truyền thông lưu lượng. Tóm lại, công nghệ chuyển mạch truyền thống tách biệt hai phương thức chuyển mạch kênh và chuyển mạch gói, trong khi đó chuyển mạch mềm kết hợp và hoàn thiện chóng trong mạng hội tụ và tích hợp, do đó hệ thống chuyển mạch mềm đảm bảo tính đa năng, kinh tế, mềm dẻo và hiệu quả cao hơn so với hệ thống chuyển mạch truyền thống.

Hình 2.1: Mô hình các hệ thống chuyển mạch
Hình 2.1: Mô hình các hệ thống chuyển mạch

Các ưu điểm của chuyển mạch mềm Quan điểm của các nhà quản trị mạng

Mét đặc điểm rất quan trọng đó là nhờ việc ứng dụng các giao diện lập trình ứng dụng mở API nhà cung cấp dịch vụ không còn hoàn toàn bị phụ thuộc vào nhà sản xuất, do đó việc tạo ra và đa dịch vụ mà thị trường có thể thực hiện một cách nhích chóng, tiện Ých và hiệu quả cao. Ưu điểm này cũng tạo điều kiện kinh doanh cho những người có vốn hạn chế, với số Ýt khách hàng và đó cũng chính là khả năng chống độc quyền, khuyến khích phát triển đồng thời tạo điều kiện cho nhiều đối tác cùng khai thác, đầu tư và cạnh tranh.

Bảng : Những ưu việt nổi trội của công nghệ chuyển mạch mề
Bảng : Những ưu việt nổi trội của công nghệ chuyển mạch mề

CÁC GIAO THỨC CƠ BẢN CỦA CHUYỂN MẠCH MỀM

    Từ bảng thống kờ trờn đõy chỳng ta thấy rừ là giao thức chủ-tớ cho phộp tập trung phần trí tuệ ứng dụng vào một số Ýt các máy chủ .điều khiển, do đó có thể dễ nâng cao hiệu quả của các thiết bị cổng kết nối và có thể nhanh hơn trong việc đa dịch vụ ứng dụng mới váo thị trường vì chỉ cần cặp nhật mới cho phần tập trung như các máy chủ. • Bản tin ACK - Bản tin này khẳng định client (máy trạm) đã nhận được bản tin trả lời bản tin INVITE. • Bản tin BYE - Bắt đầu kết thúc cuộc gọi. • Bản tin CANCEL - Hủy yêu cầu đang nằm trong hàng đợi. • Bản tin REGISTER - Đầu cuôl SIP sử dụng bản tin nàỷ'để đăng ký với Registrar Server. • Bản tin OPTIONS - sử dụng để xác định năng lực của máy chủ. • Bản tin INFO - Sử dụng để tải các thông tin nh âm báo DTMF. Trong phiên hội thoại SIP, mỗi bên tham gia được gán một địa chỉ SIP, các user ngời sử dụng) sẽ đăng ký vị trí đăng nhập với máy chủ SIP.

    Hình 2.2. Các giao thức báo hiệu trong mạng chuyển mạch mềm
    Hình 2.2. Các giao thức báo hiệu trong mạng chuyển mạch mềm

    ĐỊNH NGHĨA VÀ CÁC THÀNH PHẦN CỦA HỆ THỐNG SIP 1.1. Các định nghĩa và khái niệm cơ bản

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

    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 khác chuyển đi. Trong nhiều trường hợp Registrar Server đảm nhiệm luôn một số chức năng an toàn nh xác nhận ngườisử dụng: Thông thường Registrar Server được cài đặt cùng với Proxy hoặc Redirecl ~n'er l.ặặc cung cấp các dịch vụ thuê bao.

    CHỨC NĂNG VÀ TÍNH NĂNG CỦA SIP

    Các chức năng của SIP

    SIP cũng có thể sử dụng 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à khi đó giao thức từ một địa chỉ gửi đến là giao thức độc lập.

    Cách tính năng của SIP

    Các phần ' mềm Proxy Server, Registrar Server, Redirect Server, Location Server… có thể chạy trên các máy chủ khác nhưau và việc cài đặt thêm máy chủ hoàn toàn không ảnh hưởng đến các máy chủ đã có. SIP hỗ trợ các dịch vụ thoại như: chê cuộc gọi (Call Waiting), chuyển tiếp cuộc gọi (Call Forwarding), chặn cuộc gọi (Call Blocking), hỗ trợ thông điệp thống nhất.

    HOẠT ĐỘNG CỦA SIP

      Ngườidùng được khuyến khích dùng tên của SIP Server là tên miền SIP (SIP.domainname). Theo truyền thống, nh chỉ ra trong RFC 2219, ngườidùng có thể chỉ biết một dịa chỉ email thay vì biết tất cả địa chỉ đầy đủ của SIP URL cho bị gọi. Tuy nhiên, trong nhiều trường hợp, việc thực hiện có thể được thực hiện một cách chắc chắn hơn khi làm việc với SIP Server) đối với miền đó nhờ cấu trúc của SIP URL được lấy từ địa chỉ email đó với phần tiền tố tên Host là "sip". Mét trong hai thành viên sẽ mời thành viên thứ ba tham gia với một địa chỉ đa hướng (Mullicast) mới và đồng thời gửi một bản tin INVLTE đến thành viên thứ hai với trường miêu tả phiên đa hướng nhưng có trường Call-LD cò.

      Bảng 5.2 Thống kê các vị trí các thành phần SIP URL được sử dụng.
      Bảng 5.2 Thống kê các vị trí các thành phần SIP URL được sử dụng.

      BẢN TIN SIP

      Trường tiêu đề trong bản tin SIP

      Tiêu đề dé dài nội dung (Content-length). Giá trị trường tiêu đề Contenl-length chỉ ra kích cỡ phần chính của bản tin. Là số Octet tính theo thập phân gửi đến phía nhận. Các ứng dụng nên dùng trường này để chỉ ra kích cỡ phần chính của bản tin đã truyền đi, bất kể kiểu phương tiện gì của thực thể. Giá trị Content-length > 0 đều được sử dụng giá trị bằng không khi phần thân trong bản tin không có). Trường tiêu dề .đáp ứng Unsupported (không được hỗ trợ) liệt kê các đặc điểm mà Server không hỗ trợ trong phiên truyền thông. Tiêu đề User-agent. Trường tiêu đề chung User-agent chứa thông tin về User Agent Client khởi tạo bản tin. Tiêu đề Via. Trường tiêu đề Via chỉ ra tuyến mà yêu cầu đi qua do đó ngăn chặn được các yêu cầu bị lặp và đảm bảo trả lời trên cùng đờng yêu cầu. Sau đây ta xét cụ thể đối với các trường tiêu đề Via:. a) Trường tiêu đề Via Request. Client khởi tạo yêu cầu phải chèn vào yêu cầu một trường Via. Một trường Via chứa tên trạm, địa chỉ mạng, số cổng mặc định hoặc số cổng để nhận được đáp ứng. Mét Proxy phải kiểm tra trường tiêu đề Via cao nhất để đảm bảo rằng nó chứa địa chỉ mạng chính xác của người gửi. Nếu địa chỉ người gởi là không chính xác, Proxy phải bổ sung thuộc tính "Received". Nếu Proxy nhận yêu cầu chứa tham sè "maddr" trong trường Via cao nhất thì nó phải gửi đáp ứng đến địa chỉ đa hướng đã liệt kê trong tham sè "maddr '. b) Trường tiêu đề Via Receiver-tagged.

      Mã đáp ứng của bản tin SIP

      Một Proxy tạo ra một yêu cầu đơn (không dấu) ứng với đáp ứng Một Proxy tạo ra một yêu cáu đơn có thể chèn tham sè "branch". Định danh này có giá trị đơn nhất chỉ với một tập các yêu cầu đẳng cấp. Tiêu đề Waming. Trường tiêu dề đáp ứng Warning được sử dụng để mang các thông tin bổ sung về trạng thái của đáp ứng. Một Server bất kỳ có thể bổ sung tiêu đề Waming vào đáp ứng, Server Proxy phải đặt tiêu đề Waming bổ sung vào trước tiêu đề nhận thức bất kỳ. Chó ý rằng đáp ứng 1 xx không có độ tin cậy truyền dán, có nghĩa là nó không phải là nguyên nhân khiến cho Client gửi một ACK. Server có thể tự do phát lại các đáp ứng Informational và Client có thể kiểm tra trạng thái hiện tại của việc xử lý gọi bằng cách gọi lại các yêu cầu Sau đây ta xét một số đáp ứng 1 xx cơ bản:. Một số hoạt dộng không xác định sẽ được đại diện cho cuộc gọi nhưng User không được định vị. UAS vừa định vị một vị tít có thể, nơi mà đầu cuối được đăng ký gần đây nhất và UAS cố gắng để báo cho User. 3) Đáp lóng 181 - Call is beillgforwarded (cllộc gọi sắp được chuyển tới) Mét Proxy Server dùng mã trạng thái để thông báo là cuộc gọi sắp tới đích. Phía bị gọi tạm thời không sẵn sàng, phía chủ gọi sẽ quyết định xếp hàng các cuộc gọi thay cho việc bỏ chúng đi. Khi chủ gọi trở nên sẵn sàng nó sẽ trả về một đáp ứng trạng thái cuối cùng thích hợp. Server có thể phát ra một số đáp ứng 1 82 để cập nhật phía chủ gọi và trạng thái của hàng đợi gọi. Mã đáp ứng 2xx. Yêu cầu đã được thực hiện thành công và kết thúc một tìm kiếm. Yêu cầu đã được thực hiện thành công. Thông tin được trả lại với đáp ứng tùy thuộc vào chỉ thị dùng trong yêu cầu. BYE: Cuộc gọi đã kết thúc, thân bản tin rỗng. CANCEL: Tìm kiếm bị hủy bỏ, thân bản tin rỗng. INVLTE: User được gọi đồng ý tham gia hội thoại, thân bản tin cho biết khả năng. của User được gọi. OPTION: Người gọi đồng ý chia sẻ khả năng. REGISTER: Việc đăng ký đã thành công. Mã đáp ứng 3xx. Các đáp ứng 3xx đa ra thông tin về vị trí mới của User hoặc về dịch vụ để hoàn thành cuộc gọi. Chúng có thể kết thúc tìm kiếm hiện tại và có thể tạo ra một tìm kiếm mới nếu nó phù hợp. Các đáp ứng 3xx không yêu cầu dịa chỉ trong trường Via yêu cầu trong trường tiêu dề "Contact". Để tránh lặp với các địa chỉ trước, UAC hay Proxy phải kiểm tra xem có địa chỉ trả lại nào của Redirect Server giống với một địa chỉ trước đó không. Một số đáp ứng Redirect 3xx cơ bản:. Địa chỉ trong yêu cầu có thể có vài lùa chọn ứng với các vị trí cụ thể của nó và User hay UA có thể lùa chọn một dịa chỉ wu tiên trong đó để gửi lại yêu cầu. Đáp ứng gồm một thực thể chứa danh sách về đặc điểm nguồn và vị trí mà từ đó User hay UA có thể lùa chọn một vị trí thích hợp nhất để đăng ký. Khuôn dạng của thực thể được chỉ định bởi kiểu truyền thông trong trường tiêu đề Content-type. Khác với HLTP, đáp ứng. SIP có thể gồm vài Contact hay mét danh sách địa chỉ trong trường Contact. ỤA có thể dùng các giá trị của trường Contact để tự động gửi lại hoặc yêu cầu User xác nhận một sự lùa chọn. User không dùa trên địa chỉ trong trường Request-url và yêu cầu Client để thử lại một địa chỉ mới trong trường tiêu đề Contact. Chủ gọi sẽ cập nhật danh sách cục bộ, danh sách địa chỉ và vị trí của User rồi gửi lại các yêu cầu đến danh sách địa chỉ. 3) Đáp ứng 302-Mved Temporarily (dịch chuyển tạm thời). Yêu cầu Client thử lại yêu cầu tại một địa chỉ mới trong trường Contact. Khoảng thời gian phát lại yêu cầu được trình bày trong tiêu đề expire. Nếu nh khụng cú thời gian kết thỳc rừ ràng thỡ địa chỉ đú chỉ sử dụng cho cuộc gọi hiện tại và không được dùng cho các cuộc gọi tiếp theo. Yêu cầu truy nhập tài nguyên thông qua Proxy. Trường Contact chứa URI của Proxy. Đáp ứng này chỉ được phát ra bởi UAS. 5) Đáp ứng 380-Alternalive Server (luân chnyển Server). Cuộc gọi cha hoàn thành nhưng dịch vụ lùa chọn (thay đổi) được sử dụng. Dịch vụ lùa chọn được miêu tả trong thân bản tin của đáp ứng. Mã đáp ứng 4xx. Đỏp ứng 4xx chỉ rừ cỏc đỏp ứng lỗi từ một Server riờng biệt. Client khụng thể gửi lại cùng một yêu cầu mà không có sự thay đổi. Tuy nhiên, yêu cầu giống nhau từ một Server khác thì có thể vẫn thành công. 2) Đáp ứng 401-unanthoried (Không được phép) Yêu cầu đòi hỏi xác nhận của User. Server hiểu yêu cầu nhưng từ chối thực hiện nã. Yêu cầu không được lặp lại khi có đáp ứng này. Server có thông tin là User không có mặt trong chỉ định vùng trọng trường Request-URL. Trạng thái này được trả lại khi vùng trọng trường Request-uri không khớp với vùng nhận được bởi yêu cầu. Chỉ thị trong Request-line không cho phép nhận biết địa chỉ thông qua trường Request-uri. Đáp ứng này gồm một trường tiêu đề Anow chứa một danh sách các chỉ thị có hiệu lực cho việc nhận biết các địa chỉ. 6) Đáp ứng 480-Temporarily Unavailble (tạm thời không sẵn sàng). Hệ thống đầu cuối bị gọi đã liên lạc thành công nhưng phía bị gọi lại không sẵn sàng. Đáp ứng này chỉ ra một thời gian tết hơn để cho cuộc gọi trong tiêu đề Retry- after. Reason Phrase có thể chỉ ra các nguyên nhân chính xác tại sao phía bị gọi lại không sẵn sàng. Giá trị này có thể được thiết lập bởi UA. Đáp ứng này được trả lại bởi một Redirect Server nhận diện được User thông qua Redirect-uri nhưng không có được vị trí hợp lý hiện nay của User đó. 7) Đáp ứng 481 -Can Le~transaction does noi exist Đáp ứng này được trả lại khi có hai diễn kiện sau:. Server nhận được,một yêu cầu BYE mà không phù hợp với các cuộc gọi nhánh "Can-leg" hiện tại. Server nhận được một yêu cầu CANCEL mà không phù hợp với các giao dịch hiện tại. Server nhận được một yêu cầu với địa chỉ đến To hoặc Request-uri mà không đầy đủ. Mã trạng thái này cho phép quay số chồng chéo. Với việc quay số chồng chéo thì Client không thể biết được độ dài của chuỗi số. Hệ thống dầu cuối bị gọi dã liên lạc thành công nhưng chủ gọi lại không thể tham gia thêm vào cuộc gọi. Đáp ứng này chỉ thị một thời gian tốt hơn cho cuộc gọi trong trường Retry-after. Mã đáp ứng 5xx. Đáp ứng 5xx là đáp ứng xuất hiện khi chính Server bị lỗi. Sau đây ta xét các đáp ứng lỗi Server hay xây ra:. Server gặp phải một tình huống bất ngờ ngăn cản nó hoàn thành yêu cầu. Aient có thể hiển thị trạng thái lỗi cụ thể và có thể thử lại yêu cầu sau vài giây. Server không thể hỗ trợ yêu cầu chức năng để hoàn thành yêu cầu. Đáp ứng là một đỏp ứng thớch hợp khi Server khụng nhận thức rừ về chỉ thị yờu cầu và khả năng hỗ trợ của nó cho các User. Server khi hoạt động nh mét Gateway hoặc Proxy, nhận một'đáp ứng không hợp lệ từ Downstream Server, nó sẽ cố gắng hoàn thành yêu cầu đồ. Server hiện không có khả năng xử lý yêu cầu do sự quá tải lạm thời hay do bảo dỡng. Server khi hoạt động nh mét cổng không thể nhận một đáp ứng kịp thời từ Server khác. Nã sẽ truy xuất vào để cố gắng hoàn thành yêu cầu. 6) Đáp ứng 505-version Not Snpported (phiên bản không hỗ trợ). Server không hỗ trợ cho phiên bản SIP dùng trong bản tin yêu cầu. Đáp ứng này chứa một thực thể miêu tả tại sao không hỗ trợ phiên bản đó và nêu ra các giao thức khác được hỗ trợ bởi Server. Mã đáp ứng 6xx. Đáp ứng 6xx chỉ ra rằng yêu cầu không được đáp ứng tại mọi Server. Hiện lại hệ thống đang gặp lỗi. Một số đáp ứng 6xx thường xây ra:. Hệ thống đầu cuối bị gọi đã liên lạc thành công nhưng phía bị gọi đang bận và không muốn thực hiện cuộc gọi tại thời diềm này. Đáp ứng này chỉ ra một thời. gian tốt hơn để tiến hành cuộc gọi trong tiêu đề Retry-after. Đáp ứng này chỉ trả lại khi biết rằng không có điểm đầu cuối nào sẽ trả lại đáp ứng tới yêu cầu. Máy bị gọi đã liên lạc thành công nhưng User dứt khoát không muốn hoặc không thể tham gia cuộc gọi. Đáp ứng này chỉ ra một thời gian tốt hơn để tiến hành cuộc gọi trong tiêu đề Retry-after. 3) Đáp ứng 604-Does Noi exist Anywhere (không tồn tại bất cứ nơi nào) Server có thông tin chính xác là User được chỉ ra trong trường yêu cầu "To ', không tồn tại ở bất cứ nơi nào.

      THÂN BảN TIN SIP VÀ KHUễN DẠNG BẢN TIN SIP

        Ở đây 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 đó.

        Bảng :Các từ viết tắt cho tiêu đề chung
        Bảng :Các từ viết tắt cho tiêu đề chung

        HOẠT ĐỘNG CỦA CÁC THÀNH PHẦN SIP

        Hoạt động của SIP Client và SIP Server

        Trong khoảng thời gian 200 ms, nếu một Stateful Proxy, UAS, Redirect Server hay Registrar Server không thể đa ra một đáp ứng cuối cứng cho yêu cầu, ngay lập tức nó sẽ phát ra một đáp ứng tạm thời loại lxx. Các đáp ứng được ánh xạ đến các yêu cầu bằng cách so sánh giá trị các trường tiêu đề To, From, Cau-ID, Cseq và các thông số phụ của trường tiêu đề Via đầu tiên.

        Hoạt động của Proxy Server, Location Server và Redirect Server

        Khi mét Statefull Proxy nhận được một yêu cầu, nó sẽ kiểm tra trường To, From, Call-ID và Cseq dùa vào bản ghi của yêu cầu hiện tại. Sau khi nhận được một yêu cầu khác yêu cầu CANCEL, nã thu thập các vị trí thay đổi nhờ thông tin từ Location Server và trả lại một đáp ứng cuối cùng loại 3xx hoặc là từ chối yêu cầu.

        Hoạt động của UA (User Agent)

        Không chú ý đến bị gọi hay chủ gọi phát yêu cầu mới, trường tiêu đề trong yêu cầu được thiết lập như sau: Với mỗi cuộc gọi giá trị trường tiêu đề To sẽ được thiết lập thành địa chỉ xa còn giá trị trường tiêu đề From sẽ thành địa chỉ nội bộ. Trường Request-uri thiết lập với giá trị của trường tiêu đề Contact nhận được trong một yêu cầu hay đáp ứng trước đó từ một thành viên xa hoặc tới giá trị của một địa chỉ xa.

        Hình III.1
        Hình III.1