CHƯƠNG 2: CÁC DỊCH VỤ TRÊN NỀN IP
2.2 VoIP Giao thức thiết lập - phiên - SIP
2.2.5 Hoạt động của SIP
Một kết nối TCP đơn giản có thể lưu trữ một hay nhiều giao dịch SIP. Một giao dịch SIP không chứa hay chứa nhiều đáp ứng tạm thời theo sau là một hay nhiều đáp ứng cuối cùng. Client có thể kết nối khi mà đáp ứng cuối cùng đầu tiên tới. Nếu Client đóng hoặc xác lập lại kết nối TCP ưu tiên để nhận được các đáp ứng cuối cùng đầu tiên, server sẽ coi hoạt động này như một yêu cầu CANCEL. Hoạt động này phải được hạn chế và có thể khiến client làm việc sai chức năng dẫn đến một Proxy Server sẽ chiếm giữ một kết nối vô thời hạn.
Server không được đóng kết nối TCP cho đến khi nó gửi đi một đáp ứng cuối cùng. Tuy nhiên, bình thường thì client chịu trách nhiệm đóng kết nối. Nếu như một server muốn trả lại một đáp ứng cho client mà không muốn mở một kết nối dành cho client đó thì nó sẽ mở một kết nối khác tới danh sách địa chỉ trong trường Via.
Theo cách đó, một proxy hay một UA phải được xử lý đặc biệt để nhận cả yêu cầu và đáp ứng trong cùng một kết nối thụ động (pasive connection).
2.2.5.2 Hoạt động của SIP server, SIP client
SIP có thể sử dụng cả giao thức UDP (User Datagram Protocol) và TCP (Transmision Control Protocol) như những giao thức truyền.
Đối với các yêu cầu, Server loại bỏ những yêu cầu giống nhau và truyền lại những đáp ứng thích hợp. Sau khi nhận một yêu cầu CANCEL từ Upstream Client, một Stateful Proxy Server sẽ gửi một yêu cầu CANCEL tới tất cả các nhánh nơi nó không nhận được đáp ứng cuối cùng. Khi một UA nhận được một yêu cầu, nó sẽ kiểm tra lại trường Call ID dựa trên cuộc gọi đang diễn ra.-
- Nếu như Call-ID được tìm thấy, nó sẽ só sánh giá trị “tag” của trường To với “tag” của user và sẽ từ chối yêu cầu nếu hai giá trị đó không giống. Nếu giá trị của tiêu đề From (kể cả các giá trị tag) giống với giá trị của cuộc gọi hiện tại, Server sẽ so sánh đến giá trị của trường Cseq. Nếu giá trị đó nhỏ hơn hoặc bằng giá trị Cseq hiện tại thì yêu cầu đó là yêu cầu phát lại, nếu không bằng thì đó là yêu cầu mới. Nếu tiêu đề From không giống tiêu đề From của cuộc gọi hiện tại, một cuộc gọi mới đã được thiết lập.
- Nếu giá trị Call-ID không tìm thấy, một cuộc gọi mới đã được thiết lập với các giá trị được ghi vào các trường mào đầu To, From, và Call ID. Trong trường - hợp này, trường tiêu đề To không chứa một thẻ địa chỉ (Tag). Server trả lại một đáp ứng chứa cùng một giá trị của trường To nhưng với một thẻ địa chỉ duy nhất được thêm vào thẻ địa chỉ có thể được bỏ qua nếu yêu cầu chỉ chứa một trường tiêu đề Via.
Đối với đáp ứng, một Server có thể phát ra một hay nhiều đáp ứng tạm thời trước khi gửi một đáp ứng cuối cùng nếu như một Stateful Proxy, UAS, Redirect Server hay Registrar không thể trả lời một yêu cầu cho đáp ứng cuối cùng trong vòng 200ms, nó sẽ phát ra một đáp ứng tạm thời loại 1xx càng sớm càng tốt.
Stateful Proxy không thể phát các đáp ứng tạm thời cho bản thân chúng.
Các đáp ứng là ánh xạ của các yêu cầu bằng cách sao chép lại các giá trị trong các trường tiêu đề To, From, Call ID, Cseq và các thông số nhánh của các tiêu đề - Via từ yêu cầu. Nếu như trường tiêu đề Via chỉ ra rằng Upstream Server sử dụng giao thức truyền TCP thì Proxy phải nhanh chóng mở ra một kết nối TCP tới địa chỉ
đó. Như vậy Proxy phải được xử lý đặc biệt để nhận các yêu cầu đến từ các kết nối TCP thụ động mặc dù hầu hết các đáp ứng đều sẽ đến một kết nối TCP chủ động.
Một kết nối TCP chủ động là kết nối được chấp nhận bởi Proxy nhưng được khởi tạo bởi một thực thể khác. Đáp ứng 100 không được gửi đi, còn các đáp ứng 1xx khác có thể được gửi sau khi Server loại bỏ các đáp ứng mã trạng thái đã được gửi đi sớm hơn. Đáp ứng 2xx được gửi đi theo tiêu đề Via. Khi Stateful Proxy nhận được một đáp ứng 2xx nó phải gửi đi một đáp ứng cuối cùng không phải là loại 2xx.
Các đáp ứng với trạng thái 300 và lớn hơn được phát lại bởi các Stateful Proxy cho đến khi Upstream Proxy tiếp theo gửi đi một yêu cầu ACK hay CANCEL. Một Stateful Proxy phải duy trì trạng thái ít nhất là 32s kể từ khi nhận được đáp ứng không phải loại 2xx đầu tiên để điều khiển việc phát lại các đáp ứng. 32s là khoảng thời gian phát lại lớn nhất của một đáp ứng 200 sử dụng thời gian mặc định trong trường hợp yêu cầu ACK bị mất trên đường tới UA bị gọi hoặc Stateful Proxy tiếp theo.
2.2.5.3 Hoạt động của SIP proxy, 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 3xx hoặc 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.
UAS hoạt động giống như Redirect 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.
Với Proxy Server, để tránh lặp lại yêu cầu, 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. 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.
Với đáp ứng của Proxy, nó 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 và không được xử lý.
Một Stateless Proxy sẽ loại bỏ trường Via của chính nó và kiểm tra trường đị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.
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ả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 ủy quyền. Một Statefull Proxy Server có thể phát đáp ứng tạm thời 1xx.
Một Statefull Proxy nhận được yêu cầu ACK, nó có thể xử lý cục bộ hay ủy quyền. Các yêu cầu ACK được xử lý ủy quyền 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 tới bởi Proxy. Trong trường hợp đó, yêu cầu được xử lý cục bộ và ngừng việc truyền lại các đáp ứng.
Khi một Statefull 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 thì đáp ứng được trả.
-
Các Proxy thuộc loại Stateless, Non Forking Proxy 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 yêu cầu và đáp ứng, nó không thể duy 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.
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 INVITE chứa trong 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ổ sung 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 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 được 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 INVITE cuối cùng đến, nó có thể gửi trực tiếp yêu cầu ACK tới các Server.
2.2.5.4 Hoạt động của UA
Phần này mô tả các nguyên tắc mà UAC, UAS dùng để tạo và xử lý các yêu cầu và đáp ứng.
Khi một UAC muốn khởi tạo một cuộc gọi, nó sẽ đưa ra một yêu cầu INVITE.
Trường To trong yêu cầu chứa địa chỉ chủ gọi. Trường Request-URI chứa cùng địa chỉ đó. Trường From chứa địa chỉ phía bị gọi. Nếu địa chỉ From có thể xuất hiện trong yêu cầu phát ra từ UAC cho cùng một cuộc gọi thì phía chủ gọi chủ gọi phải cài thông số Tag trong trường From. UAC có thể nhập thêm trường Contact chứa một địa chỉ mà nó muốn liên lạc sau khi người bị gọi kết thúc hội thoại với phía chủ gọi.
Về danh sách địa chỉ trong trường địa chỉ Via, nếu giống nhau thì địa chỉ branch trong trường Via được kiểm tra. Nếu nó giống một branch đã biết, đáp ứng được xử lý bởi một Virtual client. Nếu không giống, đáp ứng đó sẽ bị loại bỏ.
Nếu một yêu cầu cần được nhận thông qua giao thức TCP, Proxy sẽ kiểm tra xem đã có kết nối hiện tại nào đó tới địa chỉ của nó chưa. Nếu có đáp ứng sẽ được gửi qua kết nối đó. Nếu không có, một kết nối mới sẽ được lập thông qua địa chỉ và cổng trong trường Via và đáp ứng sẽ được gửi qua đó.
Khi phía bị gọi nhận được yêu cầu INVITE, phía bị gọi có thể chấp nhận, gửi lại hay hủy bỏ cuộc gọi. Trong tất cả các trường hợp trên nó phát ra một đáp ứng.
Đáp ứng này phải sao chép lại các giá trị trong trường To, From, Call-ID Cseq và Via từ yêu cầu. Thêm vào đó, đáp ứng UAS phải bổ sung tham số Tag vào trường To nếu yêu cầu chứa nhiều hơn một trường tiêu đề Via. UAS có thể nhập thêm một trường Contact vào đáp ứng. Nó chứa một địa chỉ mà phía bị gọi muốn liên lạc cho giao dịch tiếp theo bao gồm cả ACK cho INVITE hiện tại. UAS lưu giữ giá trị của trường To và From kể cả các thẻ Tag, chúng sẽ trở thành địa chỉ nội bộ hay địa chỉ xa của các Call leg tương ứng.-
Nhiều đáp ứng có thể đến cùng một UAC cho một yêu cầu INVITE, mỗi đáp ứng được phân biệt bằng tham số Tag trong trường tiêu đề To và đại diện cho một
Call-leg riêng. Phía chủ gọi có thể công nhận hay kết thúc với mỗi đáp ứng UAS.
Để thừa nhận nó thì gửi một yêu cầu ACK, để kết thúc nó thì gửi yêu cầu Bye.
Trường tiêu đề To, From trong đáp ứng 200 bao gồm cả các thẻ Tag. Trường Request-URI của ACK hay Bye có thể thiết lập bất cứ địa chỉ nào được tìm thấy trong trường tiêu đề Contact nếu nó tồn tại. Lần lượt UAC sẽ sao chép các địa chỉ từ trường tiêu đề To vào trường Request URI. UAC cũng lưu ý đến giá trị của trường - tiêu đề To và From trong mỗi đáp ứng với mỗi Call-leg, trường tiêu đề To sẽ trở thành địa chỉ ánh xạ, trường From trở thành địa chỉ nội bộ.
Khi một cuộc gọi được thiết lập, phía chủ gọi hay bị gọi phát ra yêu cầu tiếp theo INVITE hay Bye để thay đổi hay kết thúc cuộc gọi mà không cần chú ý đến phía kia có phát ra yêu cầu gì mới, trường tiêu đề trong yêu cầu được thiết lập như sau: với mỗi Call leg, giá trị trường tiêu đề To sẽ được thiết lập thành địa chỉ xa, - trường From sẽ thành địa chỉ nội bộ. Trường tiêu đề Contact có thẻ khác với trường Contact được gửi đi trong yêu cầu hay đáp ứng trước đó. Trường Request URI thiết - lập 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.
Khi một yêu cầu tiếp theo được nhận, các kiểm tra sau được thực hiện:
- Nếu như Call ID là mới, yêu cầu đó là cho cuộc gọi mới. Không chú ý đến - trường tiêu đề To, From.
- Nếu Call-ID hiện có, yêu cầu đó là dành cho cuộc gọi hiện tại. Nếu các giá trị To, From, Call-ID và Cseq thực sự phù hợp với các yêu cầu nhận được trước đó (kể cả Tag) thì yêu cầu đó là một yêu cầu phát lại.
- Nếu không có sự phù hợp với bước trước đó, trường To và From tương phản với Call-leg hiện tại và địa chỉ xa. Nếu như có sự phù hợp và giá trị Cseq trong yêu cầu lớn hơn giá trị Cseq nhận được trong leg trước đây, yêu cầu đó là một giao dịch mới cho Call leg hiện tại.-