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ư
Gateway liên mạng, bộ chọn đường, máy phục vụủy quyền…Mỗi quá trình xử lý trên các thiết bị này đều gây ra một lượng trễ đáng kể. Đây là lượng trễ cố hữu của mạng chuyển mạch gĩi. Thơng thường, trễ qua mạng vào khoảng 50 ms là chấp nhận được. Ngồi ra nĩ cịn phụ thuộc rất nhiều vào lưu thơng trên mạng và tốc độ kết nối của modem. Tổ chức IETF khuyến nghị về giao thức giữ trước tài nguyên Resource Reservation Protocol (RSVP), cho phép quá trình kết nối giữa các thiết bị Gateway
chọn đường và Gateway. Nhờ vậy, thời gian để phân phối gĩi tin giảm và tăng chất lượng truyền dữ liệu.
Hình 3.2: Các yều tố gây trễ
b. Trễ do bộ CODEC
Quá trình mã hĩa và giải mã qua các bộ CODEC cũng gây ra một lượng trễ. Thơng thường, lượng trễ này hồn tồn xác định đối với từng bộ CODEC:
Bảng 3.1: Trễ của các bộ mã hố TÊN T(Kbps) ốc độ nén TÀI NGUYÊN CPU CẦN THIẾT Chất lượng tiếng nĩi Độ trễ thuật tốn (ms) G.711 PCM 64 Khơng cần Rất tốt <<1 G.722 ADPCM 48/56/64 Thấp Rất tốt (64) <<2 G.723.1 MP- MLQ 6,4/5,3 Trung bình Tốt (6,4) Khá tốt (5,3) 67-97
G.726 ADPCM 40/32/24 Thấp Tốt (40) Khá tốt (24) 60 G.728 LD- CELP 16 Rất cao Tốt <<2 G.729 CS- ACELP 8 Cao Tốt 25-35
Để đánh giá chất lượng nén tiếng nĩi qua bộ CODEC, người ta đưa vào tham số
MOS (Mean Opinion Score) như trong hình 3.3. Giá trị MOS nằm trong khoảng 1÷5, cho biết chất lượng tiếng nĩi được nén so với tiếng nĩi tự nhiên. Bộ CODEC cĩ giá trị
MOS càng cao thì chất lượng càng tốt.
Hình 3.3: Điểm đánh giá trung bình cho các bộ mã hố c. Trễ do hiện tượng Jitter
Quá trình xử lý hiện tượng Jitter bên nhận cũng gây ra trễ. Lượng trễ này thường vào khoảng 10% của trễ truyền lan.
d. Trễ do đĩng gĩi dữ liệu
Quá trình gắn tiêu đề RTP vào mỗi gĩi tin trước khi truyền đi cũng gây ra trễ. Thơng thường lượng trễ này xấp xỉ 15 ms.
Tại bên gửi các gĩi tin được sắp xếp đúng thứ tự trước khi gửi. Vì một lý do nào
đĩ, thứ tự này cĩ thể bị xáo trộn khi tới đích:
Hình 3.4 : Trễ do thứ tự gĩi tin bịđảo
Bên nhận phải sắp xếp lại đúng thứ tự các gĩi tin trước khi giải mã. Quá trình này cũng gây ra trễ.
3.1.2 Jitter
Là hiện tượng sai lệch thời gian, gĩi tin đến đích khơng đúng thời điểm :
Hình 3.5 : Hiện tượng giao động pha
Tiếng nĩi qua bộ CODEC được số hĩa và chia thành các gĩi tin theo một tốc độ xác
định. Để khơi phục lại tiếng nĩi tại phía thu thì tốc độ thu phải bằng với tốc độ phía phát.
Phía thu phải cĩ bộ đệm đủ lớn để chứa được gĩi tin tới muộn nhất rồi sắp xếp lại trước khi khơi phục tiếng nĩi. Tồn bộ cơng việc xử lý này gây ra một trễ. Thơng thường, lượng trễ này vào khoảng 50 ms là chấp nhận được.
Đây là tham số riêng biệt của tiếng nĩi. Để giải quyết hiện tượng này, ta phải xác
định kích thước bộđệm hợp lý, thường qua 2 cách :
Đo các mức gĩi tin khác nhau của bộ đệm trên tồn bộ thời gian và điều chỉnh kích thước bộđệm thích hợp. Cách này chỉ phù hợp với loại mạng ổn định như
Đếm số lượng gĩi tin đến muộn và tính tỷ lệ của chúng trên tổng số gĩi tin nhận
được trong suốt tiến trình. Từ tỷ lệ này, ta cĩ thể sửa lại kích thước bộ đệm. Cách này rất thơng dụng.
3.1.3 Mất gĩi tin
Thực ra Internet là mạng của các mạng và khơng cĩ cơ chế giám sát đầy đủ nào
đảm bảo chất lượng thơng tin truyền. Hiện tượng mất gĩi tin là kết quả của rất nhiều nguyên nhân :
Quá tải lượng người truy nhập cùng lúc mà tài nguyên mạng cịn hạn chế. Hiện tượng xung đột trên mạng LAN. Lỗi do các thiết bị vật lý và các liên kết truy nhập mạng. Mặt khác, quá trình truyền tiếng nĩi phải đáp ứng yêu cầu thời gian thực nên các gĩi tin tiếng nĩi chỉ cĩ ý nghĩa khi thời gian tới đích của chúng khơng được vượt quá thời gian trễ cho phép. Do vậy, khi thời gian này vượt quá trễ thì cũng được hiểu như là mất gĩi tin. Tất cả các điều kiện cĩ thể gây ra hiện tượng mất gĩi tin và thậm chí mất cuộc gọi nếu như số gĩi tin bị mất là quá lớn.
Hiện tượng mất gĩi tin gây ảnh hưởng nghiêm trọng tới chất lượng cuộc gọi, nhất là
đối với mạng IP vì các dịch vụ trên đĩ thường khơng được bảo đảm. Trong mạng IP, gĩi tin thoại cũng giống như gĩi tin dữ liệu thơng thường, nhưng trong trường hợp dữ
liệu thì cĩ cơ chế phát lại. Đồng thời, do tính đặc thù của tín hiệu tiếng nĩi liên quan tới thời gian thực nên hiện tượng mất gĩi tin thoại gây ra các sự cố nghiêm trọng trong quá trình khơi phục tiếng nĩi.
Với việc sử dụng giao thức RTP để vận chuyển và giám sát luồng thơng tin thì hiện tượng mất gĩi tin được phát hiện kịp thời. Ta cĩ thể giám sát số lượng gĩi tin bị mất. Tại mỗi bên tham gia hội thoại cĩ thể tính tương đối chính xác tỷ lệ gĩi tin bị mất
được gửi từ một nguồn. Thơng thường tỷ lệ này vào khoảng 5-10%. Tỷ lệ này được trao đổi qua trường fraction lost trong các bản tin thống kê được gửi một cách định kỳ. Trên thực tế, mỗi gĩi tin tiếng nĩi chỉ khoảng vài chục byte nên ta vẫn cĩ cơ chế
Hình 3.6 : Mơ tả hiện tượng mất gĩi tin
Một số cách để giải quyết vấn đề trên :
Tựđộng gửi lại gĩi tin cuối cùng khi phát hiện cĩ hiện tượng mất gĩi tin. Đây là