Mã đáp ứng ( Respone - Code ) của SIP được mở rộng từ mã đáp ứng trong HTTP/1.1, chỉ có những mã phù hợp của HTTP /1.1 mới được đưa vào trong SIP. 3.4.2.1 Informational 1xx
Đáp ứng Informational cho biết Server hoặc Proxy liên lạc đang thực hiện vài hoạt động và vẫn chưa nhận được một đáp ứng cuối cùng. Khách hàng phải đợi một đáp ứng xa hơn từ Server. Server gửi một đáp ứng 1xx nếu như nó muốn đợi một khoảng thời gian lớn hơn hoặc bằng 200ms để nhận được một đáp ứng cuối cùng. Một Server có thể phát ra nhiều đáp ứng 1xx. Chú ý rằng, đáp ứng 1xx không có độ tin cậy truyền dẫn, có nghĩa là nó không phải là nguyên nhân khiến cho khách hàng gửi một ARC. Các Server có thể tự do phát lại các đáp ứng Informational và khách hàng có thể kiểm tra trạng thái hiện tại của việc xử lý gọi bằng cách gọi lại các yêu cầu.
3.4.2.2 Successful 2xx
3.4.2.3 Redirection 3xx
Các đáp ứng 3xx đưa ra thông tin về vị trí mới của User, hoặc về dịch vụ để hoàn thành cuộc gọi. Chúng có thể kết thúc tìm kiếm hiện tại và có thể tạo ra một tìm kiếm mới nếu nó phù hợp.
3.4.2.4 Request Failure 4xx
Đáp ứng 4xx chỉ rõ các đáp ứng lỗi từ một Server riêng biệt. Khách hàng không thể gửi lại cùng một yêu cầu mà không có sự thay đổi
Tuy nhiên yêu cầu giống nhau từ một Server khác thì có thể vẫn thành công. 3.4.2.5 Server Failure 5xx
Đáp ứng 5xx là đáp ứng lỗi khi chính Server bị lỗi. 3.4.2.6 Global Farlures 6xx
Đáp ứng 6xx chỉ ra rằng yêu cầu không được đáp ứng tại mọi Server. 3.5 Hoạt động của SIP Client và SIP Server
SIP có thể sử dụng cả giao thức UDP ( User Datagram Protocol ) và TCP ( Transmission Control Protocol ) như những giao thức truyền.
3.5.1 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ẽ so 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 như hai giá trị đó không giống nhau. 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 tiêu đề 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 đó là một yêu cầu mới. Nếu như tiêu đề From không giống với 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.
3.5.2 Đá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 200 ms, nó sẽ phát ra một đáp ứng tạm thời loại 1xx càng sớm càng tốt. Stateless Proxy không thể phát các đáp ứng tạm thời cho bản thân chúng.
3.6 Địa chỉ nguồn, địa chỉđích và các kết nối 3.6.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 1 proxy hay UAS. Do đó, stateless proxy có thể sử dụng trong trường tiêu đề Via để gửi các đáp ứng.
3.6.2 Multicast UDP
Các yêu cầu có thể là quảng bá ( multicast ), yêu cầu multicast có thểđặc trưng 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ố TTL như trong yêu cầu. TTL được lấy ra từ thông số ttl 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 1 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.6.3 Kết nối TCP
Một kết nối TCP đơ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 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 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 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.7 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 cầu và đáp ứng.
3.7.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 Client. 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ó chưa. 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.7.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 huỷ 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 tiêu đề 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.
3.7.3 Phía gọi nhận được đáp ứng ban đầu
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 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ó gửi một yêu cầu ACK còn để kết thúc nó 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ỉ xa còn trường From trở thành địa chỉ nội bộ.
3.7.4 Phía gọi hay bị gọi phát ra yêu cầu tiếp theo
Khi một cuộc gọi được thiết lập cả phía gọi hoặc bị gọi có thể phát ra yêu cầu INTIVE hay BYE để thay đổi hay kết thúc cuộc gọi không chú ý đến phía gọi hay bị gọi phát ra yêu cầu 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 còn 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 đề Contract 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.
3.7.5 Nhận các yêu cầu tiếp theo
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 giá trị của trường tiêu đề To và 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ả các thẻ 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.
3.8 Hoạt động của SIP Proxy và Redirect Server 3.8.1 Redirect Server 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 đề