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ở 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 (active connection) là một kết nối TCP đợc khởi tạo bởi Proxy còn một kết nối thụ động (passive connection) là kết nối đợc chấp nhận bởi Proxy nhng đợ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 lxx khác có thể đợc gửi, sau khi Server loại bỏ các đáp ứng mà 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 ( non - 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 Ủpstream 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 (non — 200) đầ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 AŒK bị mất trên đờng tới UA bị gọi hoặc Stateful Proxy tiếp theo.
3.3.3. Địa chỉ nguồn, địa chỉ đích và các kết nối
3.3.3.1 Unicast UDP
Các đáp ứng đợc trả lại danh sách địa chỉ trong trờng mào đầu Via không có địa chỉ nguồn của đáp ứng. Với cuộc gọi về các đáp ứng không đợc phát ra bởi next-hop stateless server mà đợc phát ra bởi l proxy hay UAS. Do đó, stateless proxy có thể sử dụng trong trờng tiêu đề Via để gửi các đáp ứng.
3.3.3.2 Multicast UDP
Các yêu cầu có thể là quảng bá ( multicast ), yêu cầu multicast có thể đặc trng cho một Host và không phụ thuộc vào trờng Request - URI. Yêu cầu này đảm bảo rằng nó
không thể ra khỏi phạm vi của một hệ thống quản lí điều này có thể thực hiện với TTL hay phạm vi quản lí tuỳ theo sự thực hiện của nó trong mạng.
Một Client nhận đợc một yêu cầu multicast không phải kiểm tra xem thành phần Host của trờng Request -URI có giống với Host hay tên vùng của nó không. Nếu yêu cầu đợc nhận thông qua multicast thì đáp ứng trở lại phải thông qua multicast. Đáp ứng cho các yêu cầu multicast đợc phát quảng bá với cùng thông số TT nh trong yêu cầu. TTL, đợc lấy ra từ thông số ttÏ trong trờng tiêu đề Via.
Để tránh việc các đáp ứng bị “kép” ( implosion ), Server phải trả lời các yêu cầu multicast bằng một mã trạng thái khác với trạng thái 2xx và 6xx. Thời gian trễ của các đáp ứng nhỏ hơn hoặc bằng 1s. Server có thể ngừng các đáp ứng nếu nh nó nhận đợc các đáp ứng có số nhỏ hơn hay đáp ứng 6xx từ nhóm các thành viên u tiên khác. Server không trả lời các yêu cầu CANCEL nhận đợc thông qua phát quảng bá để tránh việc yêu cầu bị “kép”. Proxy hoặc UAC có thể gửi I yêu cầu CANCEL khi nhận đợc một đáp ứng 2xx hay 6xx đầu tiên cho một yêu cầu multicast. Server có thể ngừng đáp ứng nếu yêu cầu đòi hỏi Server phải vi phạm các nguyên tắc xử lí bản tin cơ bản.
3.3.4 Kết nối TCP
Một kết nối TCP đơn có thể lu 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 dữ 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 CHient đó 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 UA phải đợc xử lí đặc biệt để nhận cả các yêu cầu và đáp ứng trong cùng một kết nối thụ động ( passive connection ).
3.4 Hoạt động của UA ( User - Agent )
Phần này mô tả các nguyên tắc mà UAC và UAS dùng để tạo và xử lí các yêu
Đồ án tốt nghiệp đại học Chơng III. Giao thức khởi tạo phiên SIP
cầu và đáp ứng.
3.4.1 Phía gọi phát yêu câu Intive yêu câu
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ỉ ngời gọi. Trờng Request - URI chứa cùng địa chỉ
đó. Trờng From chứa địa chỉ của 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 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 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 với một branch đã biết, đáp ứng đợc xử lý bởi một Virtual CHent. Nếu khô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 nó đã có kết nối hiện tại nào tới địa chỉ của nó cha. Nếu có thì đáp ứng sẽ đợc gửi qua kết nối đó. Nếu không một kết nối TCP mới sẽ đợc thiết lập thông qua địa chỉ và cổng trong trờng Via và đáp ứng sẽ đợc gửi qua đó. Chú ý rằng một UAC hay Proxy đều đợc xử lý đặc biệt để nhận các đáp ứng tới qua một kết nối TCP. Các đáp ứng 2xx phải đợc truyền lại bởi các Proxy thậm chí qua cả một kết nối TCP.
3.4.2 Phía bị gọi phát đáp ứng
Khi phía bị gọi nhận đợc yêu cầu INTIVE, phía bị gọi có thể chấp nhận, gửi lại
hay huy 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