Hoạt động đăng kí với registrar

1.5 Hoạt động của SIP

1.5.2 Hoạt động đăng kí với registrar

SIP đưa ra khả năng phát hiện. Nếu như một người dùng muốn khởi tạo phiên với một người dùng khác, SIP phát hiện host tại đích người dùng là có thể tới được. Việc xử lý phát hiện thường được thực hiện bởi các phần tử mạng như là proxy server và redirect server. Các phần tử này chịu trách nhiệm về yêu cầu mà chúng nhận được và xác định địa chỉ để gửi dựa trên thông tin nội bộ người dùng, và sau đó gửi tới đó. Để làm được điều này, các phần tử mạng SIP tra dịch vụ viết tắt tên miền như là dịch vụ location (nội hạt), nó cung cấp địa chỉ tên miền, địa chỉ tên miền nằm trong SIP hoặc là SIPS URI. Cuối cùng thì proxy sẽ tham khảo dịch vụ location. Việc đăng kí được thực hiện thông qua registrar.

Khi nhận được một yêu cầu đăng kí, một registrar thực hiện các bước sau:

1. Registrar kiểm tra Request-URI để xác định xem có thể truy nhập vào tên miền chỉ ra trong URI hay không. Nếu không được, thì server sẽ hoạt động giống như một proxy server, và nó sẽ chuyển yêu cầu tới tên miền được đánh địa chỉ.

2. Để chắc chắn rằng registrar hỗ trợ những đặc điểm mở rộng này, registrar phải xử lý header Require.

3. Registrar có thể nhận thực UAC. Nếu như kỹ thuật nhận thực mà UAC đưa ra là không có thì registrar cso thể kiểm tra lại bộ định nhận dạng của nơi khởi phát yêu cầu.

4. Registrar sẽ kiểm tra nếu như người dùng nhận thực là được trao quyền để chỉnh sửa đăng ký bản ghi địa chỉ. Registrar có thể tra cứu cơ sở dữ liệu trao quyền, tên người dùng được ghi trong bản ghi địa chỉ. Nếu như người dùng nhận thực không được trao quyền thì registrar sẽ gửi lại đáp ứng 403 (Forbidden: không cho phép) và bỏ qua các bước còn lại.

5. Registrar lấy bản ghi địa chỉ từ header To của yêu cầu. Nếu như bản ghi địa chỉ có tên miền trong Request-URI là không hợp lệ, thì registrar sẽ gửi về với đáp ứng 404 (Not Found: không tìm thấy) và bỏ qua các bước còn lại. Nếu như hợp lệ thì sau đó URI sẽ chuyển sang dạng chuẩn.

6. Registrar kiểm tra yêu cầu có chứa header Contact hay không. Nếu như không có thì nó bỏ qua bước trước đó. Nếu như có header Contact, registrar sẽ kiểm tra. Nếu như Contact rỗng hoặc là thời hạn là 0 thì server sẽ gửi về một đáp ứng 400 (Invalid Request: yêu cầu không hợp lệ), và bỏ qua các bước còn lại. Nếu như Contact và thời hạn của nó là hợp lệ, thì registrar kiểm tra xem Call-ID có khớp với giá trị lưu trữ trong mỗi liên kết hay không. Nếu khớp thì nó chỉ gỡ bỏ liên kết khi mà CSeq của yêu cầu cao hơn giá trị lưu trữ với liên kết đó, còn nếu không thì việc cập nhập sẽ bị bỏ qua và yêu cầu lỗi.

7. registrar xử lý với mỗi địa chỉ liên hệ trong header Contact. Nếu như hạn thời gian của Contact thỏa mãn điều kiện của registrar thì nó gửi đáp ứng 423 (Interval Too Brief: thời gian quá ngắn) và đáp ứng này có thể chứa header Min-Expires chứ giá trị khoảng thời gian tối thiểu mà registrar có thể chấp nhận được. Khi không thỏa mãn thì nó bỏ những bước còn lại.

Với mỗi địa chỉ, registrar tìm danh sách liên kết hiện tại thông qua việc so sánh URI. Nếu chưa có thì nó sẽ thử thêm vào. Còn nếu như liên kết đã tồn tại thì registrar kiểm tra giá trị Call-ID. Nếu như giá trị Call-ID tồn tại trong liên kết khác với giá trị Call-ID trong yêu cầu, thì liên kết cũ sẽ bị gỡ bỏ và được cập nhật. Nếu chúng giống nhau thì registrar so sánh giá trị CSeq, nếu lớn hơn thì mới cập nhật, còn nếu không thì registrar sẽ bỏ qua và yêu cầu đó là lỗi.

8. Registrar đáp ứng với đáp ứng 200 OK. Đáp ứng này phải chứa giá trị header Contact đưa ra. Mỗi Contact có giá trị thông số “expires” chỉ ra khoảng thời hạn được chọn bởi registrar.

Sau đây là một thí dụ đơn giản về hoạt động đăng kí REGISTER sip: dtvt.vt1.vn SIP/2.0

Via: SIP/2.0/UDP 192.168.1.13: 5060; brand = z9hG4bKusvn19 Max-Forwards: 70

From: Minh Ngoc <sip: minhngoc@vt1.com>; tag=3431 Call-ID: 23@192.168.1.13

CSeq: 1 REGISTER

Contact: sip: <minhngoc@192.168.1.13>; expires=3600 Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.13 : 5060 ; branch= z9hG4bKusvn19 ; received = 192.168.1.13

To: Minh Ngoc <sip: minhngoc@vt1.com>; tag=8771 From: Minh Ngoc <sip: minhngoc@vt1.com>; tag=3431 Call-ID: 23@192.168.1.13

CSeq: 1 REGISTER

Contact: sip: minhngoc@192.168.1.13 Content-Length: 0

Hình 1.7 Hoạt động đăng kí1.5.3 Khởi tạo mợt phiên 1.5.3 Khởi tạo một phiên

Khi một UAC muốn khởi tạo một phiên (có thể là thoại, video), nó tạo yêu cầu INVITE. Yêu cầu INVITE thông báo tới server để thiết lập phiên. Yêu cầu này được chuyển tiếp bởi proxy, tới UAS và thực hiện lời mời. UAS sẽ hỏi người dùng để quyết định có chấp nhận lời mời hay không. Sau khi xử lý, nếu UAS này chấp nhận lời mời (có nghĩa là phiên được thiết lập) thì nó gửi đáp ứng 2xx. Nếu như lời mời không được chấp nhận thì tùy thuộc vào lý do không chấp nhận lời mời mà nó gửi các đáp ứng 3xx, 4xx, 5xx hoặc là 6xx. Trước khi gửi đáp ứng kết thúc, UAS có thể đáp ứng tạm thời 1xx để thông báo cho UAC. Say đây là phần miêu tả hoạt động thiết lập một phiên

i. Tạo bản tin INVITE bắt đầu

Khi UAC thực hiện khởi tạo yêu cầu với các header cần thiết như đã trình bày phần hoạt động động chung của các UA. Ngoài ra nó còn có các khai báo khác nữa đó là:

Trường header Allow được thực hiện trong bản tin INVITE. Nó chỉ ra các chỉ thị mà liên quan tới đoạn thoại. Header Supported được thực hiện trong INVITE, nó liệt kê tất cả những phần mở rộng của UAC. Header Accept, Content-Type có thể được thực hiện trong bản tin INVITE để chỉ thị kiểu nội dung của phần thân bản tin. UAC cũng có thể thêm header Expires để giới hạn thời gian lời mời có hiệu lực. UAC cũng có thể tìm các thông tin hữu dụng khác để thêm vào, thông qua các header Subject, Organization và User-Agent, các header này chứa thông tin liên quan tới yêu cầu INVITE. UAC có thể thêm phần thân bản tin cho INVITE nếu như nó có header Content-Type để mô tả phần thân bản tin.

ii. Xử lý đáp ứng trả lời cho bản tin INVITE: tùy theo các mã đáp ứng mà UAC có hoạt động khác nhau, chẳng hạn đáp ứng 100 thì UAC chờ.

b) Hoạt động của UAS

Xử lý bản tin INVITE: UAS nhận yêu cầu INVITE từ lớp giao tác. Nó sẽ xử lý bản tin INVITE theo thứ tự như đã thực hiện ở phần hoạt động của UAS(các thao tác kiểm tra). Nếu như UAS chưa thể trả lời ngay lập tức thì nó trả lời bằng tín hiệu chuông hồi âm (bằng các đáp ứng 1xx). UAS có một khoảng thời gian hồi âm để tránh tình trạng proxy có thể hủy cuộc giao dịch do thời gian chờ quá lâu.

Nếu phía UAS bận và không thể thêm cuộc gọi ở đầu cuối, thì nó trả lời với đáp ứng 486 (Busy Here: Đang bận). UAS cũng có thể từ chối lời mời với đáp ứng 488 (Not Acceptable Here: không được chấp nhận).

UAS chấp nhận bản tin INVITE: Khi UAS chấp nhận lời mời nó gửi đáp ứng 2xx.

1.5.4 Sửa đổi một phiên

Một yêu cầu INVITE thành công thiết lập thoại giữa hai UA. Việc chỉnh sửa có thể làm thay đổi địa chỉ của cổng, thêm hoặc xóa một luồng phương tiện. Việc chỉnh sửa có thể được thực hiện bằng cách gửi một yêu cầu INVITE mới trong phạm vi cùng đoạn thoại mà đã thiết lập. Bản tin INVITE mới này còn được gọi là re-INVITE.

i. Hoạt động của UAC

Để chỉnh sửa phiên UAC sẽ gửi yêu cầu re-INVITE. Trong yêu cầu này các header To, From, Call-ID, CSeq, và Request-URI giống như của yêu INVITE ban đầu của đoạn

Disposition (có giá trị “alert”). Nếu như UAC nhận đáp ứng đáp ứng kết thúc không phải là 2xx thì các thông số của phiên vẫn không thay đổi, nếu như nó nhận được đáp ứng kết thúc là 408 (Request timeout: yêu cầu hết thời hạn), hoặc là 481 (cuộc gọi/giao dịch không tồn tại) thì UAC sẽ kết thúc đoạn thoại.

ii. Hoạt động của UAS

Trong cùng một đoạn thoại, khi mà UAS nhận được yêu cầu INVITE thứ hai trước khi nó gửi đáp ứng kết thúc cho yêu cầu INVITE thứ nhất (có số CSeq thấp hơn), thì nó gửi trả đáp ứng 500 (lỗi về yêu cầu) để trả lời cho yêu cầu INVITE thứ hai đó. Nếu như UAS nhận một yêu cầu INVITE trong đoạn thoại trong khi một yêu cầu INVITE khác mà nó đang trong quá trình xử lý thì nó sẽ đáp trả lại với đáp ứng 491 (yêu cầu đang chờ xử lý).

Nếu một UA nhận re-INVITE cho một đoạn thoại đang diễn ra, nó sẽ phải kiểm tra phiên bản trong phần mô tả phiên, nếu như trong phần mô tả phiên đã thay đổi, thì nó sẽ thông báo cho người dùng rồi sau đó mới chỉnh thông số phiên một cách tương ứng. Nếu mô tả phiên mới không được chấp nhận thì UAS có thể từ chối bằng cách trả lời re-INVITE với đáp ứng 488 (Not Acceptable Here: không được chấp nhận). Nếu như UAS gửi đáp ứng 2xx nhưng nó không nhận được bản tin ACK thì nó gửi yêu cầu BYE để kết thúc đoạn thoại.

1.5.5 Kết thúc phiên

Yêu cầu BYE dùng để kết thúc một phiên. Khi nhận được yêu cầu BYE trong đoạn thoại, thì bất kỳ phiên nào kết hợp với đoạn thoại đó đều bị kết thúc. Yêu cầu BYE không được gửi khi mà nó chưa nhận bản tin ACK cho đáp ứng 2xx. Khi UAC khởi tạo yêu cầu BYE, nó tạo một giao dịch client mới, và gửi yêu cầu BYE qua đó. Ngay sau khi gửi yêu cầu BYE, UAC sẽ coi phiên như là đã kết thúc. Nếu như sau khi gửi yêu cầu BYE đi mà UAC nhận được đáp ứng là 481 (Call/Transaction Does Not Exist: Cuộc gọi hoặc là giao dịch không tồn tại) hoặc là 408 (Request Timeout: yêu cầu đã hết thời hạn), hoặc là nó không nhận được bất kỳ đáp ứng nào thì UAC vẫn xem như là phiên đã kết thúc.

UAS sẽ xử lý yêu cầu BYE sau đó nó trả lời bằng các mã đáp ứng. UAS nhận yêu cầu BYE và kiểm tra trong đoạn thoại đang tồn tại: nếu như yêu cầu BYE không tồn tại trong đoạn thoại UAS sẽ đáp trả bằng đáp ứng 481, còn nếu như yêu cầu có tồn tại thì nó sẽ kết thúc phiên. UAS cũng có thể đáp trả lại những yêu cầu đang chờ để xử lý với đáp ứng 487 để kết thúc.

Lớp truyền tải đảm nhiệm nhiệm vụ truyền các yêu cầu và đáp ứng. Nó bao gồm cả việc xác định kết nối được dùng cho yêu cầu và đáp ứng trong trường hợp truyền tải kết nối có hướng. Lớp truyền tải chịu trách nhiệm cho việc quản lý các kết nối với các giao thức như là TCP, SCTP hoặc là TLS. Các kết nối do client hoặc là server đưa ra, do đó các kết nối được chia sẻ những chức năng truyền tải giữa client và server. Khi lớp truyền tải được xác định, nó thiết lập địa chỉ IP đích, số cổng, và truyền tải. Hai proxy trong mối quan hệ ngang hàng sẽ sử dụng truyền tải kết nối có hướng và sẽ có hai kết nối khi sử dụng, mỗi kết nối cho một giao tác giữa proxy và client

1.5.6.1 Client

Phía client của lớp truyền tải chịu trách nhiệm gửi yêu cầu và nhận các đáp ứng. Người sử dụng lớp truyền tải phía client truyền yêu cầu, địa chỉ IP, cổng, cách thức truyền tải, và có thể có ttl cho địa chỉ đích đa hướng. Khi mà kích thước bản tin q lớn thì nên chọn UDP. Khi mà phần tử chọn truyền tải là TCP nhưng kích thước bản tin q lớn, khi đó nếu vẫn cố gắng thiết lập kết nối thì khởi tạo hoặc là giao thức ICMP không được hỗ trợ hoặc là TCP sẽ bị reset, phần tử có thể thử lại yêu cầu với UDP.

Client gửi địa chỉ multicast phải thêm vào thông số maddr vào trong header Via của nó chứa địa chỉ đích multicast. Với IPv4 thơng số ttl thường có giá trị là 1. Giá trị cổng mặc định là 5060 cho UDP, TCP và SCTP và 5061 cho TLS.

Để cho việc truyển tải tin cậy, thông thường các đáp ứng gửi trong kết nối mà vừa nhận được yêu cầu. Do đó truyền tải client phải được chuẩn bị để nhận đáp ứng trong cùng kết nối dùng để gửi yêu cầu. Nếu như có lỗi xảy ra, server sẽ thử mở một kết nối mới để gửi đáp ứng.

Nếu yêu cầu được gửi dùng địa chỉ multicast, nó gửi nhóm địa chỉ, cổng, và thông số ttl. Nếu địa chỉ là unicast thì nó chỉ gửi một địa chỉ IP và cổng.

Khi client nhận đáp ứng, nó kiểm tra giá trị phần đầu của header Via. Nếu thông số được gửi trong giá trị header không tương ứng với giá trị mà truyền tải ở client đã cấu hình chèn vào trong yêu cầu, đáp ứng sẽ bị loại bỏ.

1.5.6.2 Server

1. Nhận yêu cầu

Server sẽ nhận đáp ứng với địa chỉ IP, cổng và kiểu truyền tải mà nó tìm thấy trong SIP hoặc là SIPS URI mà muốn giao tiếp với server. Khi server nhận một yêu cầu nó kiểm tra thơng số ở phần đầu của giá trị của header Via. Để phân biệt với gói tin nguồn, server thêm thông số “received” vào trong giá trị header Via.

Thí dụ: Khi server nhận được yêu cầu INVITE nó có dạng sau INVITE sip:tien@d04vt1.org SIP/2.0

Via: SIP/2.0/UDP tien.d04vt1.org: 5060

Yêu cầu được nhận với địa chỉ IP nguồn là 192.0.2.4. Trước khi cho yêu cầu đi qua, truyền tải thêm thông số “received”, do đó nó sẽ như sau:

INVITE sip:tien@d04vt1.com SIP/2.0

Via: SIP/2.0/UDP tien.d04vt1.org: 5060; received=192.0.2.4

Kế tiếp server cố gắng gắn yêu cầu với giao tác server. Chú ý rằng sau khi UAS chủ gửi đáp ứng 2xx đáp trả INVITE, giao tác server sẽ chấm dứt. Khi ACK tới, nó sẽ không gắn với giao tác, ACK sẽ được đi qua UAS lõi khi mà nó đã được xử lý.

2. Gửi đáp ứng

Server sử dụng giá trị phần đầu trong header Via để xác định nơi mà đáp ứng được gửi tới. Nó diễn ra như sau:

• Nếu như giao thức được dùng là giao thức truyền tải tin cậy thì nó là TCP hoặc là SCTP, hoặc là TLS. Đáp ứng phải được gửi tới nguồn trong kết nối mà yêu cầu ban đầu đã tạo giao tác, khi mà kết nối vẫn mở. Để kết nối vẫn mở, đòi hỏi phía server phải duy trì sự kết hợp giữa giao tác server với các kết nối truyền tải. Nếu kết nối đóng, server có thể mở một kết nối với địa chỉ IP trong thơng số “received”, cịn giá trị cổng thì nó dùng giá trị cổng của phía gửi, hoặc là dùng cổng mặc định cho truyền tải trong trường hợp nếu như cổng không được khai báo. Nếu như việc thực hiện kết nối không thành, server dùng thủ tục để xác định địa chỉ IP và cổng để mở kết nối và gửi đáp ứng.

• Trong trường hợp, nếu như header Via chứa thông số “maddr”, đáp ứng phải được chuyển tiếp tới địa chỉ được ghi ra, dùng cổng được chỉ định ở phía gửi, nếu như khơng có mặt thơng số này thì cổng mặc định là 5060. Nếu như địa chỉ là multicast, đáp ứng có thể được gửi bằng cách dùng thơng số ttl đã đưa ra.

• Với trường hợp truyền tải unicast không tin cậy, nếu như phần phần đầu của Via có chứa thơng số “received”, thì đáp ứng được gửi tới địa chỉ mà thông số “received” đã chỉ ra, hoặc dùng cổng được chỉ định bởi phía bên gửi, trong trường hợp cổng khơng được đưa ra thì nó dùng giá trị mặc định là 5060. Nếu khơng thực hiện được, nó đưa ra đáp ứng ICMP “port unreachable” (khơng tới được cởng).

• Trong trường hợp nếu như khơng gắn thơng số “received”, đáp ứng sẽ gửi tới địa chỉ chỉ định trong giá trị bên gửi.

cầu và đáp ứng.

a. 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