Để xác định được vị trí hiện tại của thuê bao bị gọi tại thời điểm hiện tại mạng phải sử dụng dịch vụđịnh vị. Trong đĩ sử dụng một cơ sở dữ liệu chứa các liên kết địa chỉ
cho phép ánh xạ một địa chỉ SIP hay SIPS URI ở đầu vào, như sip:bob@biloxi.com chẳng hạn, với một hay nhiều URI gần hơn với user đích, ví dụ như
sip:bob@engineering.biloxi.com, ởđầu ra. Cứ như thế, cuối cùng ta sẽ xác định được vị trí hiện tại mà thuê bao bị gọi hiện đang cư trú.
Dịch vụđịnh vị hoạt động dựa trên các thuật tốn tìm kiếm các liên kết địa chỉ trong một cơ sở dữ liệu. Cĩ rất nhiều cách để xây dựng cơ sở dữ liệu cho dịch vụ định vị. Trong đĩ, SIP cung cấp một cơ chếđể cho một tác nhân người dùng thực hiện cập nhật cơ sở dữ liệu động được gọi là đăng ký.
Đểđăng ký, tác nhân người dùng phải gửi đi một bản tin đăng ký REGISTER tới một UAS đặc biệt gọi là registrar. Đây là một tiền trạm của dịch vụđịnh vị trong một miền. Nhiệm vụ của nĩ là đọc và ghi các ánh xạđịa chỉ dựa vào nội dung của bản tin REGISTER. Hình vẽ 2.9 dưới đây miêu tả tồn bộ quá trình đăng ký này.
Một bản tin REGISTER cĩ thể được sử dụng để bổ sung, xố bỏ hay truy vấn các liên kết địa chỉ. Các UA khơng được phép gửi một bản tin REGISTER mới nếu chúng chưa nhận được một đáp ứng cuối cùng từ registrar cho yêu cầu trước đĩ hoặc khi timeout xảy ra.
Hình 2. 9 Đăng ký
2.3.5.2 Truy vấn khả năng (Querying for Capabilities)
Phương thức OPTIONS cho phép một UA truy vấn tới một UA khác hay một proxy server để nhận được thơng tin về các phương thức được hỗ trợ, các kiểu nội dung và các thuộc tính mở rộng mà khơng cần phải thực hiện cuộc gọi tới phía bên kia. Ví dụ, trước khi một client chèn một trường tiêu đề "Require" chứa danh sách các tuỳ chọn mà nĩ khơng chắc chắn rằng UAS cĩ thể hỗ trợ vào một bản tin INVITE, nĩ cĩ thể
truy vấn tới UAS đích bằng một bản tin OPTIONS để hỏi xem tuỳ chọn này cĩ được hỗ trợ hay khơng. Kết quả các tuỳ chọn được hỗ trợ sẽ được lưu trong trường "Supported" của bản tin trả lời. Tất cả các UA phải hỗ trợ phương thức OPTIONS này. Khi cĩ nhu cầu biết được các khả năng của một tác nhân khác, UA sẽ tạo ra một bản tin OPTIONS và gửi tới tác nhân đĩ. Một yêu cầu OPTIONS cũng được cấu trúc theo chuẩn chung của các yêu cầu SIP.
Đáp ứng của một OPTIONS cũng được cấu trúc theo các quy tắc chuẩn của một đáp
ứng SIP. Trong đĩ, mã của đáp ứng được chọn giống với mã của đáp ứng khi trả lời một bản tin INVITE. Đĩ là đáp ứng 200 (OK) khi UAS sẵn sàng chấp nhận cuộc gọi, 486 (Busy Here) khi UAS bận… Điều đĩ cho phép một yêu cầu OPTIONS cĩ thể được sử dụng để xác định trạng thái cơ bản của một UAS rằng liệu UAS sẽ chấp nhận yêu cầu INVITE hay khơng.
Khi một yêu cầu OPTIONS được nhận ở bên trong một dialog thì một bản tin đáp
ứng 200 (OK) cũng được tạo ra giống như khi nĩ được nhận ở bên ngồi dialog và khơng cĩ bất kỳ một tác động nào tới dialog. Cĩ một sự khác nhau giữa INVITE và OPTIONS trong cách điều khiển của proxy. Đĩ là trong khi INVITE cĩ thể nhận được nhiều đáp ứng 200 (OK) thì OPTIONS chỉ cĩ nhận được một đáp ứng 200 (OK).
Nếu như đáp ứng của một bản tin OPTIONS được tạo ra bởi một proxy server, thì bản tin đáp ứng 200 (OK) sẽ mang một danh sách cho biết các khả năng của server này, và đáp ứng sẽ khơng cĩ phần thân bản tin.
2.3.5.3 Khởi tạo phiên (Initiating a Session)
Khi một đầu cuối của user muốn thiết lập một phiên (ví dụ như audio, video hay game), nĩ sẽ tạo ra một lời mời INVITE. Lời mời này được chuyển xuống lớp dưới và chuyển tiếp qua một số proxy để gửi đến một hay một số UAS cĩ khả năng chấp nhận lời mời. Những UAS này sẽ thường xuyên cần đến để truy vấn user về việc cĩ chấp nhận lời mời hay khơng. Sau một thời gian, những UAS này cĩ thể chấp nhận lời mời (cĩ nghĩa là một phiên được thiết lập) bằng cách gửi đi một đáp ứng 2xx. Nếu như lời mời khơng được chấp nhận, một đáp ứng 3xx, 4xx, 5xx hay 6xx sẽ được gửi đi tuỳ
thuộc vào lý do bị từ chối. Trước khi gửi đi đáp ứng cuối cùng, UAS cũng cĩ thể gửi
đi một số đáp ứng tạm thời (1xx) để hướng dẫn UAC trong quá trình liên lạc với thuê bao bị gọi (called user).
Sau khi nhận được một hay một số đáp ứng tạm thời, UAC sẽ nhận được một hay một số đáp ứng cuối cùng 2xx nếu lời mời được chấp nhận hoặc một đáp ứng cuối cùng khơng phải 2xx nếu lời mời khơng được chấp nhận. Do cĩ một cơ chế đảm bảo sự tin cậy trong việc giao dịch của bản tin INVITE khác với các yêu cầu khác (như
INVITE cĩ thể dài hơn. Một khi đã nhận được đáp ứng cuối cùng, UAC cần phải gửi
đi một bản tin ACK cho tất cả các đáp ứng mà nĩ nhận được. Những thủ tục cho việc gửi đi bản tin ACK này phụ thuộc vào kiểu của đáp ứng. Đối với các bản tin đáp ứng cĩ mã nằm trong khoảng từ 300 đến 699, việc xử lý ACK được thực hiện trong lớp transaction theo một tập các quy tắc. Với các đáp ứng là loại 2xx, ACK được tạo ra bởi lõi UAC.
Một đáp ứng 2xx cho một bản tin INVITE sẽ thiết lập ra một phiên, và nĩ cũng tạo ra một dialog giữa UA gửi bản tin INVITE và UA trả lời bằng đáp ứng 2xx này. Vì vậy, khi nhiều đáp ứng 2xx được nhận từ nhiều UA khác nhau, thì cứ một đáp ứng 2xx sẽ tạo ra một dialog khác nhau và tất cả các dialog này đều là thành phần của cùng một cuộc gọi.
2.3.5.4 Hiệu chỉnh phiên (Modifying an existing Session)
Một lời mời thành cơng sẽ thiết lập lên một số dialog và một số phiên giữa hai tác nhân người dùng sử dụng mơ hình đề nghị/trả lời nhưđã được trình bày ở trên. Trong quá trình truyền thơng cĩ thể xảy ra một số tình huống mà một trong hai bên tham gia muốn thay đổi các tham số hiện tại của phiên như: thay đổi địa chỉ, cổng, bổ sung một luồng phương tiện, xố một luồng phương tiện…Những thay đổi này được thực hiện bằng cách gửi đi một bản tin INVITE mới bên trong dialog đã thiết lập lên phiên hiện tại. Bản tin này được gọi là bản tin re-INVITE. Cùng một bản tin re-INVITE cĩ thể
thay đổi cả các tham số của dialog và phiên hiện tại và cả bên chủ gọi và bên bị gọi
đều cĩ thể gửi bản tin này để sửa đổi phiên hiện tại.
Khơng giống với INVITE bản tin re-INVITE chỉ được gửi tới một UAS đang tham gia vào phiên hiện tại và do đĩ chỉ cĩ một đáp ứng cho bản tin này. UAS này được xác
định trong trường "Request-URI" đang tham gia dialog cùng với UAC, hay nĩi đúng hơn là trường này sẽ chỉ thịđịa chỉ bản ghi của thuê bao phía bên kia. Tại phía bên kia, UAS phải phân biệt được bản tin re-INVITE với bản tin INVITE và điều khiển bản tin re-INVITE này để sửa đổi dialog và phiên hiện tại.
Để phân biệt giữa hai bản tin này, UAS sử dụng thẻ trong trường tiêu đề "To" để
như cĩ sự trùng hợp thì bản tin này là một bản tin re-INVITE, ngược lại thì nĩ là một bản tin INVITE.
Khi UAS nhận được bản tin re-INVITE trong một dialog đang tồn tại, nĩ phải kiểm tra số nhận dạng version trong miêu tả phiên của bản tin. Nếu khơng cĩ phần này, nĩ phải xem xét nội dung của phần miêu tả phiên để xác định xem cĩ sự thay đổi ở thuộc tính nào hay khơng. Nếu như cĩ sự thay đổi so với phiên đang tồn tại, UAS phải sửa lại các tham số cho đúng với các trạng thái mới của chúng sau khi đã hỏi ý kiến của người sử dụng để xác nhận những thay đổi này. Sau đĩ, UAS sẽ tạo ra một đáp ứng 2xx để báo cho UAC biết rằng đề nghị mới đã được chấp nhận.
Nếu như đề nghị mới về phiên khơng được chấp nhận, UAS phải loại bỏ nĩ bằng cách gửi cho UAC một đáp ứng 488 (Not Acceptable Here). Nếu UAS tạo ra một đáp
ứng 2xx và khơng nhận được một bản tin xác nhận ACK, nĩ sẽ tạo ra một bản tin BYE
để kết thúc dialog.
Nếu như chưa thể đưa ra quyết định cuối cùng về đề nghị mới này, UAS cũng sẽ
khơng tạo ra đáp ứng 180 (Ringing) bởi vì UAC sẽ khơng tạo ra tín hiệu chuơng tại thiết bị thuê bao khi nhận được đáp ứng này. Thay vào đĩ, UAS sẽ sử dụng một trường tiêu đề "Alert-Info" trong bản tin đáp ứng cho bản tin re-INVITE.
Nếu như bản tin re-INVITE khơng đưa ra lời đề nghịđể thay đổi các thuộc tính của phiên, UAS sẽ đưa ra một đề nghị về các thuộc tính này trong đáp ứng 2xx để gửi tới UAC. UAS phải đảm bảo rằng các đặc điểm mới này phải được thay thế cho các đặc
điểm của phiên hiện tại, ví dụ như các tham số về: dạng phương tiện; phương tiện truyền dẫn và các tham số khác. Điều đĩ sẽ giúp hạn chế phía bên kia từ chối các đặc
điểm mới này. Tuy nhiên, nếu như UAC vẫn khơng thể chấp nhận được đề nghị này thì nĩ sẽ tạo ra một câu trả lời với một miêu tả phiên hợp lệ và sau đĩ gửi một bản tin BYE để kết thúc phiên này.
UAC chờđể nhận được một đáp ứng cuối cùng cho bản tin re-INVITE, nếu nhưđây khơng phải là một đáp ứng 2xx thì các tham số của phiên khơng được thay đổi. Trong
đĩ, nếu đáp ứng này là một trong các bản tin 481 (Call/Transaction Does Not exit), 408 (Request Timeout) hay khơng cĩ đáp ứng nào nhận được thì UAC sẽ kết thúc
dialog này. Nếu UAC nhận được đáp ứng 491, nĩ sẽ khởi động một timer với giá trị T
được chọn như sau:
- Nếu UAC đã tạo ra trường Call-ID của dialog ID, T cĩ thể chọn giá trị trong khoảng từ 2,1 đến 4 giây với một đơn vị thời gian là 10 ms.
- Nếu UAC khơng tạo ra trường Call-ID của dialog ID, T cĩ thể chọn giá trị trong khoảng từ 0 đến 2 giây với một đơn vị thời gian là 10 ms.
Khi timer trở về 0, UAC cố gắng gửi lại bản tin re-INVITE một lần nữa nếu như nĩ vẫn muốn thay đổi các tham số của phiên hiện tại. Nếu như đáp ứng nhận được là đáp
ứng 2xx, các tham số của phiên sẽ được cập nhật lại theo các thơng số trong yêu cầu
đã được gửi đi.
2.3.5.5 Giải phĩng phiên (Terminating a Session)
Khi cĩ nhu cầu kết thúc phiên phương tiện, UAC tạo ra một bản tin BYE và gửi nĩ tới UAS để yêu cầu kết thúc phiên này. Bản tin BYE sẽ được gửi đi bên trong dialog kết hợp với phiên cần giải phĩng để tới UAS. Khi đĩ, UAC phải xem như phiên hiện tại đã kết thúc và do đĩ nĩ phải ngừng các hoạt động gửi và chờ dữ liệu trên phiên ngay khi BYE được gửi đi.
UA chủ gọi cĩ thể gửi bản tin BYE trong cả hai loại confirmed và early dialog cịn UA bị gọi chỉ được gửi bản tin BYE trong confirmed dialog. Tuy nhiên, UA chủ gọi khơng được gửi bản tin BYE trong confirmed dialog cho đến khi nĩ đã nhận được một bản tin ACK cho đáp ứng 2xx hay cho đến khi timeout xảy ra.
Khi UAS nhận được bản tin BYE, nĩ thực hiện các bước xử lý theo các quy tắc chung của bản tin được gửi bên trong dialog. Số nhận dạng cuộc gọi của bản tin sẽ được tính tốn và so sánh với số nhận dạng của các dialog đang tồn tại. Nếu như bản tin BYE khơng thuộc một dialog nào thì UAS sẽ tạo ra một đáp ứng 481 (Call/Transaction Does Exit) và gửi nĩ trở lại UAC. Nếu như bản tin ở trong một dialog, nĩ sẽđược xử lý. Khi hồn tất, UAS sẽ giải phĩng dialog và phiên liên quan tới dialog đĩ.
Kết luận chương II
Trong chương này khảo sát các giao thức được sử dụng trong việc truyền thoại trong mạng IP. Mục đích của các giao thức là đảm bảo thực hiện được các dịch vụ trên mạng gĩi. Trong chương sau sẽđề cập đến các yếu tốảnh hưởng đến chất lượng dịch vụđĩ và các phương pháp hỗ trợ chất lượng dịch vụ.
CHƯƠNG III. ĐÁNH GIÁ CHẤT LƯỢNG DỊCH VỤ TRONG VoIP
Cơng nghệ truyền thoại qua mạng IP sẽ phát triển rất nhanh trong vài năm tới. Tuy nhiên, người dùng đã quen với chất lượng tiếng nĩi do cơng nghệ hiện thời mang lại. Các nhà sản xuất đang cố gắng tạo ra các thiết bị theo cơng nghệ mới, thoả mãn yêu cầu của người sử dụng. Cái chúng ta cần là dịch vụ thoại với cước phí rẻ hơn, chất lượng chấp nhận được và cĩ độ tin cậy cao. Đa phần các nhà sản xuất sẽ khơng mạo hiểm về chất lượng đối với loại dịch vụ cơ bản và quan trọng nhưđiện thoại. Đây được xem như một tiêu chí quan trọng nhất để triển khai VoIP trong thực tế.
Chất lượng dịch vụ QoS là tập hợp các chỉ tiêu đặc trưng cho yêu cầu của từng loại lưu lượng cụ thể trên mạng bao gồm: độ trễ, jitter, tỷ lệ mất gĩi... Các chỉ tiêu này liên quan đến lượng băng thơng dành cho mạng.
3.1 Các yếu tốảnh hưởng tới chất lượng dịch vụ trong VoIP
Cơng nghệ truyền thoại qua mạng IP phải đảm bảo những chỉ tiêu cần thiết như
giảm thiểu các cuộc gọi bị từ chối, sự trễ trên mạng, mất gĩi, và đứt liên kết. Tuy nhiên, các yếu tố này đa phần thuộc về hạ tầng cơ sở mạng. Chức năng điều khiển chất lượng dịch vụ cho VoIP hết sức phức tạp và sẽđược đề cập ở chương sau.
Cĩ 3 yếu tố chính ảnh hưởng tới chất lượng dịch vụ cho thoại trên IP là : 1. Trễ
2. Jitter 3. Mất gĩi tin
Với việc sử dụng giao thức vận chuyển thời gian thực RTP cho phép ta giám sát một vài tham số này từđĩ đánh giá được chất lượng dịch vụ cho thoại trên IP.
3.1.1 Trễ
Khi xây dựng và triển khai một ứng dụng thoại trên IP , cĩ rất nhiều yếu tố làm ảnh h ng t i ch t l ng cu i cùng c a h th ng. ĩ cĩ th là ch t l ng ti ng nĩi qua
các bộ CODEC, giải thơng mạng, các khả năng kết nối mạng... Một yếu tố quan trọng
ảnh hưởng tới chất lượng dịch vụ là trễ.
Trễ được hiểu là khoảng thời gian tiêu tốn để người nghe nghe được âm thanh phát ra từ người nĩi trong một cuộc thoại (từ miệng tới tai). Trễ xuất hiện do rất nhiều nguyên nhân từ khi truyền tin qua mạng IP cho tới lúc phát lại tiếng nĩi tại bên nhận, cĩ thể do bộ xử lý tín hiệu số DSP, do thuật tốn nén và giải nén, jitter...Trễ là yếu tố
khơng thể tránh khỏi.
Thơng thường, trễ trong mạng điện thoại truyền thống vào khoảng 50÷70 ms. Để cĩ
được trễ trong hệ thống VoIP xấp xỉ với trễ trong mạng chuyển mạch kênh là lý tưởng nhưng điều đĩ khĩ cĩ thể thực hiện được. Ta chỉ cĩ thể xây dựng hệ thống VoIP cĩ độ
trễ chấp nhận được đối với người sử dụng. Theo khuyến nghị của ITU thì một hệ
thống VoIP đảm bảo chất lượng dịch vụ tốt khi độ trễ một chiều khơng được vượt quá 150 ms:
Hình 3.1: Quan hệ giữa độ trễ và mức chất lượng
Theo hình trên, độ trễ một chiều khơng được vượt quá 450 ms. Thơng thường trễ
chấp nhận được vào khoảng 200 ms. Các yếu tố gây trễđược tổng hợp ở hình 3.2. a. Trễ do mạng
Quá trình truyền các gĩi tin qua mạng IP tới đích phải qua nhiều thiết bị như