3.8.1 Redirect Server
Một Redirect Server không thể phát ra các yêu cầu SIP cho chính nó. Sau khi nhận được một yêu cầu khác yêu cầu CANCEL, nó thu thập danh sách các vị trí thay đổi và trả lại một đáp ứng cuối cùng loại 3xxx hoặc là từ chối yêu cầu. Với các yêu cầu CANCEL có khuôn dạng hợp lệ, nó có thể trả lại một đáp ứng 2xx. Đáp ứng này sẽ kết thúc phiên giao dịch SIP. Redirect Server sẽ duy trì trạng thái giao dịch trong suốt phiên giao dịch SIP.
3.8.2 UAS
UAS hoạt động giống như Ridiect Server, chúng có thể chấp nhân các yêu cầu và gửi lại một đáp ứng loại 2xx.
3.8.3 Proxy Server 3.8.3.1 Proxy Request
Để tránh lặp lại, một Server phải kiểm tra xem địa chỉ của nó có thực sự nằm trong trường tiêu đề Via của yêu cầu đến không. Các giá trị của trường To, From, Call -ID và Contact đều được sao chép chính xác từ yêu cầu gốc. Proxy có thể thay đổi trường Request - URI để thông báo cho Server nơi nó muốn gửi yêu cầu đến. Một Proxy Server bao giờ cũng chèn một trường tiêu đề Via chứa địa chỉ của chính nó vào các yêu cầu. Các Proxy bao giờ cũng đưa vào các thông số branch.
3.8.3.2 Proxy Respone
Proxy chỉ xử lý một đáp ứng khi mà trường Via cao nhất phù hợp với một trong các địa chỉ của nó. Nếu không đáp ứng đó sẽ dừng lại ( không được xử lý ). 3.8.3.3 Stateless Proxy
Một Stateless Proxy sẽ loại bỏ trường Via của chính nó và kiểm tra địa chỉ trường Via tiếp theo. Trong trường hợp giao thức truyền là UDP, đáp ưng được gửi đến danh sách địa chỉ trong thẻ địa chỉ maddar hay received nếu chúng có mặt và cuối cùng đến địa chỉ trong trường “sent - by”. Proxy vẫn giữ nguyên trạng thái statefull khi thiết lập yêu cầu nhận thông qua TCP. Stateless Proxy không được phát ra yêu cầu tạm thời.
3.8.3.4 Statefull Proxy ( nhận yêu cầu )
Khi một Stateful 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ảng yêu cầu hiện tại. Nếu “ Tuple” không có mặt yêu, cầu tương ứng với một giao dịch mới và yêu cầu được uỷ quyền.
Một Statefull Proxy Server có thể phát đáp ứng tạm thời 1xx. 3.8.3.4 Stateful Proxy ( nhận ACK )
Khi nhận được một yêu cầu ACK, Statefull Proxy có thể xử lý cục bộ hay uỷ quyền. Các yêu cầu ACK được sử lý ủy quyền trừ khi giá trị các trường tiêu đề To, From, Cseq và Call - ID phù hợp với một đáp ứng ( không phải 200 ) được gửi bởi Proxy. Trong trường hợp đó, yêu cầu được sử lý cục bộ và ngừng việc truyền lại các đáp ứng.
3.8.3.5 Staeful Proxy ( nhận một đáp ứng )
Khi một Proxy Server nhận một đáp ứng đã thông qua sự kiểm tra trường Via, nó sẽ kiểm tra trường To ( không có Tag ), From ( kể cả Tag ), Call - ID và CSeq dựa trên các giá trị trong yêu cầu trước đó. Nếu không trùng nhau đáp ứng được trả. 3.8.3.6 Stateless, Non - Forking Proxy
Các Proxy thuộc loại này phát ra hầu hết là các yêu cầu unicast cho mỗi yêu cầu SIP tới, do đó chúng không thể “Fork” các yêu cầu. Tuy nhiên, Server có thể lựa chọn một kiểu hoạt động để phát ra các yêu cầu khác. Server có thể gửi các yêu cầu và đáp ứng. Nó không thể duy trì trạng thái của phiên giao dịch SIP. Proxy Server lưu trữ kết quả của việc biên dịch địa chỉ và lưu trữ các đáp ứng để nhanh chóng phát lại.
3.8.4 Forking Proxy
Server trả lại một yêu cầu ngay lập tức bằng đáp ứng 100. Đáp ứng thành công cho một yêu cầu INTIVE chứa trường tiêu đề Contact. Nếu Proxy đòi hỏi các yêu cầu trong tương lai phải được định tuyến qua nó thì nó sẽ bổ xung thêm một tiêu đề Record - Route vào yêu cầu. Quá trình xử lý các đáp ứng hoàn thành khi tất cả các yêu cầu đều nhận được trả lời bởi các đáp ứng trạng thái cuối cùng ( cho unicast ) hoặc sau 60s ( cho multicast ), một Proxy có thể gửi đáp ứng CANCEL tới tất cả các cuộc gọi và trả lại một đáp ứng 408 ( Time out ) tới Client.
1xx: Proxy gửi đáp ứng trả lại Client
2xx: Proxy gửi đáp ứng tới Client mà không gửi một yêu cầu ACK. Sau khi nhận một đáp ứng 2xx, Server kết thúc tất cả các yêu cầu sắp thực hiện bằng cách gửi một yêu cầu CANCEL và đóng kết nối TCP.
3xx: Proxy gửi một yêu cầu ACK và lặp lại các danh sách địa chỉ. Nếu không, đáp ứng có số thấp nhất sẽ được trả lại khi không có loại đáp ứng 2xx.
4xx, 5xx: Proxy gửi một yêu cầu ACK và ghi lại các đáp ứng có mã trạng thái nhỏ hơn 4xx và 5xx. Khi hoàn thành, đáp ứng có số mã nhỏ nhất sẽ được trả lại nếu như không có các đáp ứng 2xx, 3xx.
6xx: Proxy gửi một đáp ứng tới Client và gửi đi một yêu cầu ACK. Các yêu cầu sắp thực hiện khác có thể kết thúc với yêu cầu CANCEL.
Một Proxy có thể duy trì trạng thái trong một giai đoạn mà nó lựa chọn. Nếu một Proxy vẫn có danh sách các đích mà nó đã gửi yêu cầu INTIVE cuối cùng đến, nó có thể gửi trực tiếp yêu cầu ACK tới các Server
3.9 Liên vận SIP-PSTN
Như đã giới thiệu trong phần trước, mục tiêu ban đầu của SIP là hỗ trợ cho thoại IP. Khi SIP được phổ biến, thì yêu cầu mở rộng SIP cho các ứng dụng khác ngày càng tăng lên. Những mở rộng này tạo thêm các tính năng mới cho giao thức SIP cơ bản, ví dụ như sử dụng các MCU cho các hội nghị nhiều bên, chức năng chuyển cuộc gọi, …
Mặt khác mạng thoại VoIP không thể tách rời với mạng thoại truyền thống, vì vậy vấn đề cấp bách được đặt ra là phải liên vận được mạng thoại và mạng VoIP. Bài toán này có hai vấn đề cần giải quyết, vấn đề thứ nhất là phối hợp báo hiệu và vấn đề thứ hai là chuyển đổi phương tiện (mã hoá thoại) giữa hai mạng. Vấn đề thứ nhất sẽ được giải quyết với kỹ thuật tương tác hoạt động giữa SIP (giao thức báo hiệu trong mạng IP) và ISUP (giao thức báo hiệu trong mạng PSTN).
3.9.1 Cách tiếp cận
Có hai cách tiếp cận cho hoạt động tương tác SIP/ISUP. Đó là biên dịch và đóng gói. Biên dịch là ánh xạ trực tiếp các bản tin và tham số giữa hai giao thức ISUP và SIP. Theo phương pháp này, những thông tin chung (được định nghĩa trong cả hai giao thức) được ánh xạ trực tiếp, những thông tin còn lại được thiết lập bằng các giá trị mặc định. Theo cách tiếp cận này, một bản tin SIP là kết quả của sự biên dịch từ một cuộc gọi PSTN sẽ không được phân biệt với bản tin SIP của các cuộc gọi trong môi trường thuần SIP, do đó chúng sẽđược xử lý giống như nhau. Tuy nhiên không phải tất cả các tham số báo hiệu của ISUP đều có thành phần tương đương trong SIP, nên một số thông tin sẽ bị mất khi bản tin được định tuyến ngược trở lại môi trường PSTN. Như vậy mất thông tin là nhược điểm của cách tiếp cận này. Đóng gói là một cách tiếp cận khác thường được ứng dụng tại các gateway SIP/PSTN. Việc chuyển đổi ISUP sang SIP được thực hiện bằng cách đóng gói nội dung của bản tin ISUP vào phần thân của SIP. Cách tiếp cận này có ưu điểm là tạo ra một môi trường trong suốt để chuyển tải bản tin ISUP, kết quả là không mất thông tin, và giải quyết được nhược điểm của cách tiếp cận đầu tiên. Tuy nhiên cách
tiếp cận này cũng có những nhược điểm. Thứ nhất khi các mạng PSTN khác nhau sử dụng các biến thể ISUP khác nhau (điều này thường xảy ra trong các mạng PSTN), thì sẽ nảy sinh ra vấn đề không tương thích. Như vậy đòi hỏi phải có phần xử lý đặc biệt ở gateway PSTN. Một nhược điểm khác là do ISUP và SIP tuân theo mô hình tin cậy khác nhau, do đó nội dung của bản tin ISUP cần phải được mã hoá khi truyền trong môi trường SIP để bảo vệ các thông tin riêng. Để tránh rò rỉ thông tin, phần thân bản tin SIP cần được mã hoá tại gateway khởi tạo và giải mã tại gateway đích. Quá trình này làm tăng yêu cầu xử lý tại gateway và cũng làm tăng thời gian thiết lập cuộc gọi.
3.9.2 Mở rộng của SIP để phục vụ cho liên vận PSTN/SIP
Cả IETF và ITU-T đều tham gia nghiên cứu công tác liên vận PSTN/SIP, theo những công việc riêng. Nhóm làm việc SIPPING của IETF giới thiệu SIP-T (SIP cho mạng điện thoại). Nó bao gồm tài liệu hướng dẫn sử dụng SIP cho mạng điện thoại (RFC 3372, Session Initiation Protocol for Telephones (SIP-T): Context and Architectures) và tài liệu về ánh xạ thông tin giữa hai giao thức SIP và ISUP (RFC 3398 – Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping).
3.9.3 SIP-T
SIP-T (được định nghĩa trong IETF RFC 3372) là một mở rộng của SIP nhằm tạo ra một phương thức liên vận giữa mạng PSTN truyền thống với mạng gói. SIP-T hỗ trợ MGC trong việc thiết lập, xoá bỏ và quản lý các cuộc gọi thoại. SIP-T rất linh hoạt, nó bao gồm nhưng không bị hạn chế các giao thức báo hiệu SS7, ISDN, CAS. Trong phần này, chúng tôi chỉđể cập đến tương tác hoạt động giữa SS7 và SIP
.
Hình 3. 2 Sử dụng SIP-T cho báo hiệu liên MGC
Hình 3.2 minh hoạ cấu hình mạng cơ bản sử dụng SIP-T. Trong cấu hình này, các MG kết nối tới mạng SCN theo bằng báo hiệu SS7. Khối O_MGC (Originating Media Gateway Controller) nhận cuộc gọi bằng SS7. Thông tin báo hiệu SS7 cần được xử lý tại O-MGC để thực hiện call half phía khởi tạo xác định T_MGC (Terminating Media Gateway Controller). Vai trò của SIP-T ởđây là để vận chuyển thông tin cần thiết từ O_MGC tới T_MGC. T_MGC cần thực hiện nốt call half phía đích với báo hiệu SS7.
Như vậy SIP-T là mở rộng của SIP để thực hiện quản lý các bản tin PSTN giữa O_MGC và T_MGC. SIP-T đóng gói các bản tin báo hiệu PSTN sử dụng mã hoá MIME. Kỹ thuật này cho phép các bản tin báo hiệu PSTN được đi ngầm qua mạng báo hiệu SIP giữa các MGC. Như vậy phần thân của bản tin SIP-T sẽ mang cả thông tin ISUP đã được mã hoá và SDP. Ngoài ra SIP-T cũng định nghĩa ánh xạ cơ bản giữa các bản tin ISUP và SIP-T (được liệt kê trong Error! Not a valid bookmark self-reference.). Lưu đồ báo hiệu của một cuộc gọi cơ bản có tương tác báo hiệu giữa SS7 ISUP với SIP-T được minh hoạ trong Error! Reference source not found..
Bảng 3. 1 Ánh xạ một số bản tin cơ bản giữa ISUP và SIP_T Bản tin SS7 ISUP Bản tin SIP-T
IAM INVITE
ACM 180 RINGING
ANM 200 OK
REL BYE
RLC 200 OK
Tóm lại bản tin báo hiệu PSTN được đóng gói vào bản tin SIP-T (such as INVITE, ACK, BYE) bằng mã hoá nhị phân, sử dụng mã hoá MIME. Kiểu nội dung là APPLICATION cho phép các bản tin báo hiệu cho phép các bản tin báo hiệu PSTN được đi ngầm giữa các MGC. Việc sử dụng nội dung SUBTYPE cho phép các bản tin SS7 ISUP được phân biệt tại phái MGC nhận. Ví dụ bản tin IAM được mã hoá và chuyển tiếp từ O_MGC tới T_MGC trong phần thân của bản tin SIP-T INVITE. Các bản tin ACM và ANM tiếp theo được chuyển ngược trở lại tới O_MGC bằng bản tin SIP-T 180 RINGING và 200 OK. Tham số SUBTYPE cho MGC nhận biết loại bản tin đã được mã hoá.
3.9.4 SIP-I
.Do phạm vi ứng dụng khác nhau, TRQ.BICC-ISUP-SIP quy định 3 profile khác nhau. Error! Reference source not found. mô tả phạm vi hoạt động của mỗi profile.Profile A, được định nghĩa trong tài liệu TA 24.229 V5.1.1 ban hành tháng 06/2002, đáp ứng nhu cầu của 3GPP. Các nghiên cứu về giao thức này được định hướng bởi các nhà cung cấp và khai thác di động. Profile B bổ sung cho profile A với mục đích hỗ trợ lưu lượng kết cuốitrong mạng SIP. Profile B hỗ trợ cho các nhà cung cấp dịch vụ muốn phối hợp lưu lượng kết cuối trong mạng SIP với các dịch vụ được cung cấp trong mạng PSTN/ISDN. Profile C hỗ trợ việc chuyển tiếp lưu lượng thông qua các mạng chuyển tiếp SIP sử dụng kỹ thuật đóng gói bản tin ISUP vào MIME (SIP-I). Theo Profice C, SIP-I không thực hiện các thủ tục ISUP trong SIP
domain. Nó quy định sự tương quan giữa các bản tin ISUP được đóng gói với SIP. Hiện tại một số vấn đề còn tồn tại của SIP-I đang được các nhà nghiên cứu làm rõ, như: tương tác giữa các nhà khai thác dịch vụ quốc tế, hỗ trợ INFO Method theo RFC 2976, hỗ trợ các dịch vụ bổ sung,…
Hình 3. 4 Tương tác các profile của SIP
3.9.5 So sánh SIP-I và SIP-T
SIP-I có tính năng hơn so với SIP-T. Đó là:
- khả năng ánh xạ nhiều thông tin hơn từ bản tin ISUP sang các mào đầu của SIP
- thêm thủ tục gửi bản tin SIP overlap - quản lý một số dịch vụ bổ sung
- ánh xạ giữa SDP và các tham số ISUP - hỗ trợ SDP offer-answer
Mặt khác IETF ngày nay tập trung nguồn lực vào vấn đề phát triển Internet. Quan điểm của họ là “Chỉ tồn tại một mạng công cộng duy nhât: INTERNET, các mạng khác đều là mạng riêng.” IETF không còn tiếp tục giải quyết vấn đề phát triển mạng PSTN tới NGN. Vấn đề phát triển mạng PSTN tới NGN (trong đó bao gồm cả vấn đề liên vận PSTN/IP hay SS7/SIP) hiện đang được ITU-T nố lực thực hiện. Tóm lại có thể thấy tiềm năng của SIP-I được hỗ trợ tốt hơn so với SIP-T
Kết luận Chương 3 IWU IWU PSTN/ISDN PSTN/ISDN IWU IWU SIP Profile A SIP Profile B SIP Profile C ª mobile network SIP 3GPP
SIP Terminating network
Trong chương 3 đã trình bày các vấn đề cơ bản về chức năng, kiến trúc và hoạt động của giao thức SIP, từđó thấy được vai trò quan trọng của giao thức SIP trong mạng NGN.SIP là giao thức báo hiệu linh hoạt, mềm dẻo và rất thích hợp khi sử dụng trong mạng IP. SIP sẽ trở thành thành phần báo hiệu chính trong mạng hội tụ tương lai
SIP có phần mở rộng đồ sộ cho những tính năng, ứng dụng, dịch vụ và môi trường cụ thể. Vì vậy vấn đề quan trọng cần xác định trước tiên đối với nhà cung cấp dịch vụ là xác định phương hướng phát triển dịch vụ, trên cơ sởđó sẽ tiếp tục xây dựng tài liệu chuẩn cho các phần mở rộng liên quan.
Chương 4 Giao thức Megaco
4.1 Giới thiệu
- Mạng NGN. Điểm nổi bật của mạng đó là sự phân tách rõ ràng của các lớp : lớp truy nhập, truyền tải, điều khiển và ứng dụng dịch vụ (hình1). Sự tách biệt này giúp cho mạng dễ dàng mở rộng và quản lý và sự mở rộng mạng lưới trên cơ sở từng lớp không gây ảnh hưởng nhiều cho các lớp khác.
- Tại giao tiếp giữa lớp truy nhập và lớp truyền tải dịch vụ thông qua thiết bị là Cổng phương tiện (Mediagateway); giao tiếp giữa lớp truyền tải và lớp điều khiển là MGCP (MediaGateway Controller Protocol), Megaco/H.248.
- Giao thức Megaco/H.248 là một chuẩn mởđược chấp nhận rộng rãi. Nó là cách tiếp cận nhiều đặc tính và được phát triển đầy đủ cung cấp nhiều lựa chọn cho việc xây dựng các sản phẩm giá trị gia tăng với các đặc tính phân biệt. Còn MGCP là cách tiếp cận đóng, không phản ánh đúng sự nhất trí trong công nghiệp viễn thông và do đó giới hạn tiềm năng trong khả năng liên kết giữa nhiều nhà phân phối. MGCP có một số thiếu sót về mặt kỹ thuật mà đã được bổ sung trong Megaco/H.248.
So với MGCP thì MEGACO/H248 được cải thiện ở một số các điểm nhất định như sau : 9 Hỗ trợ các dịch vụđa phương tiện và điện thoại thấy hình hội nghị