(TIỂU LUẬN) đề tài các thủ tục đăng ký trong IMS môn học báo HIỆU và điều KHIỂN kết nối

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG KHOA VIỄN THÔNG -o0o - ĐỀ TÀI: Các Thủ Tục Đăng Ký Trong IMS MÔN HỌC: BÁO HIỆU VÀ ĐIỀU KHIỂN KẾT NỐI Mã học phần : TEL 1402 Giảng viên: : Hoàng Trọng Minh Thời gian nộp : 10/12/2021 Sinh viên thực : Phạm Tiến Hưng - B18DCVT216 Trần Mạnh Hùng – B18DCVT192 Dương Tú Kiên – B18DCVT224 Trần Văn Lâm – B18DCVT240 Hà Nội, tháng 12/2021 MỤC LỤC MỤC LỤC……………………………………………… ….…………………… LỜI MỞ ĐẦU……………………………………………… …………………… …5 BẢNG THUẬT NGỮ VIẾT TẮT………………………………….……… …….6 DANH MỤC HÌNH VẼ VÀ BẢNG…………………………………… ……….8 1.1 Tổng Quát ………………………………………………………………….9 1.2 Các Tham Số Ban Đầu Và Đối Tượng Quản Lý IMS ……………… 12 1.3 Thiết Lập Ngữ Cảnh Báo Hiệu PDP ……………………………………13 1.4 Khám Phá P-CSCF ………………………………………………………13 1.4.1 Tổng Quát ………………………………………………………13 1.4.2 SIP Và Cấu Hình Máy Chủ DNS Qua DCHPv6……………….14 1.4.3 Phân giải Con Trỏ Cơ Quan Đặt Tên DNS (NAPTR)………….16 1.4.4 Giải Quyết Lựa Chọn Giao Thức Truyền Tải Và Dịch Vụ DNS 16 1.4.5 Phân Giải Địa Chỉ DNS IPv6 ………………………………… 17 1.4.6 Các Tiêu Chuẩn Liên Quan ……………………………………17 1.5 Từ UE Đến P-CSCF …………………………………………………18 1.6 Từ I-CSCF Đến S-CSCF ……………………………………………18 1.7 S-CSCF Tải Xuống Vectơ Xác Thực Từ HSS …………………….20 1.8 Thỏa Thuận Cơ Chế Bảo Mật SIP ………………………………….22 1.8.1 Tại Sao Cần Có Thỏa Thuận Cơ Chế Bảo Mật SIP …………… 22 1.8.2 Tổng Quát ………………………………………………………22 1.8.3 Tiêu Đề Sip-Sec-Agree-Related Trong Khởi Tạo Yêu Cầu Đăng Kí 23 1.8.4 Tiêu Đề Máy Chủ Bảo Mật Trong Phản Hồi 401 (Chưa Xác Thực) 24 1.8.5 Tiêu Đề Sip-Sec-Agree Trong ĐĂNG KÝ Lần Hai…………………25 1.8.6 Sip-Sec-Agree Và Đăng Ký Lại ………………………………… 26 1.8.7 Các Tiêu Chuẩn Liên Quan ……………………………………….28 1.9 Xác Thực …………………………………………………………… 28 1.9.1 Tổng Quát ………………………………………………………28 1.9.2 HTTP Digest 3GPP AKA ……………………………………30 1.9.3 Thông Tin Xác Thực Trong Yêu Cầu ĐĂNG KÝ Ban Đầu ……31 1.9.4 S-CSCF Thách Thức UE ………………………………………31 1.9.5 Phản Ứng Của UE Đối Với Thách Thức………………………32 1.9.6 Bảo Vệ Tính Tồn Vẹn Và Xác Thực Thành Cơng……………33 1.9.7 Các Tiêu Chuẩn Liên Quan……………………………………33 1.10 Bảo Mật Truy Cập - IPsec Sas ………………………………… 34 1.10.1 Tổng Quát ……………………………………………………34 1.10.2 Thiết Lập SA Trong Quá Trình Đăng Ký Ban Đầu …………34 1.10.3 Xử Lý Nhiều Bộ SA Trong Trường Hợp Xác Thực Lại……… 37 1.10.4 SA Lifetime …………………………………………………40 1.10.5 Thiết Lập Cổng Và Định Tuyến …………………………….41 1.10.6 Các Tiêu Chuẩn Liên Quan …………………………………42 1.11 Đàm Phán Nén ……………………………………………………46 1.11.1 Tổng Quát ……………………………………………………46 1.11.2 Thể Hiện Sự Sẵn Sàng Sử Dụng SigComp ………………….46 1.11.3 comp = Tham Số SigComp Trong Khi Đăng Ký ……………48 1.11.4 comp = Tham Số SigComp Trong Các Yêu Cầu Khác ………48 1.11.5 Các Tiêu Chuẩn Liên Quan……………………………………48 1.12 Tiêu Đề Tuyến Dịch Vụ ……………………………………………48 1.13 Tiêu Đề Đường Dẫn ………………………………………………49 1.14 Đăng ký S-CSCF ……………………………………… 50 1.15 Thơng Tin Liên Quan Đến Tính Phí Trong Khi Đăng Ký ….53 1.16 Danh Tính Người Dùng ………………………………………53 1.16.1 Tổng Quát ………………………………………………… 53 1.16.2 Danh Tính Người Dùng Công Khai Và Cá Nhân Để Đăng Ký…55 1.16.3 Nguồn Gốc Nhận Dạng Từ USIM …………………………… 55 1.16.4 Danh Tính Người Dùng Cơng Khai Mặc Định / Tiêu Đề PAssociated-URI ………………………………………………………….56 1.16.5 Chỉ định URI tác nhân người dùng định tuyến tồn cầu …57 1.16.6 Đăng Ký Của UE Đối Với Thông Tin Trạng Thái Đăng Ký …… 58 1.16.7 Đăng ký Của P-CSCF Với Thông Tin Trạng Thái Đăng Ký……61 1.16.8 Các Yếu Tố Của Thông Tin Đăng Ký-Trạng Thái ………62 1.16.9 Thông Tin Trạng Thái Đăng Ký Trong Phần Nội Dung Của Yêu Cầu Thông Báo…………………………………………………………… 63 1.16.10 Ví Dụ Về Đăng Ký-Thơng Tin Trạng Thái…………………65 1.16.11 Nhiều Thiết Bị Đầu Cuối Và Thông Tin Trạng Thái Đăng Ký ….68 1.16.12 Các Tiêu Chuẩn Liên Quan …………………………………69 KẾT LUẬN 70 TÀI LIỆU THAM KHẢO………………………………………………………… 71 Lời Mở Đầu Nội dung tiểu luận đưa ví dụ chi tiết thủ tục liên quan đến Giao thức khởi tạo phiên (SIP) Giao thức mô tả phiên (SDP) Hệ thống đa phương tiện giao thức Internet (IMS) Các thủ tục báo hiệu, thông điệp giao thức yếu tố chúng mơ tả giải thích dựa ví dụ đăng ký IMS phiên Điện thoại đa phương tiện IMS hai người dùng Ngoài ra, trình bày chi tiết cách thức hoạt động giọng nói, giới thiệu quy trình chi tiết tính liên tục gọi Người đọc thấy cách hoạt động tín hiệu IMS cách thực hóa khái niệm kiến trúc mô tả trước cấp độ giao thức Tuy nhiên, phần tập trung vào ví dụ đơn giản không xử lý chi tiết quy trình lỗi bất thường Để hiểu rõ thủ tục áp dụng, phần phần chia thành nhiều phần tập trung vào khái niệm khác nhau, chẳng hạn định tuyến, xác thực thương lượng phương tiện Mỗi phần mô tả phần thông điệp SIP SDP riêng lẻ cần thiết cho hiểu biết họ Phần tổng quan bao gồm phần để giới thiệu hoạt động Ở cuối chương, tiêu chuẩn thông số kỹ thuật liên quan liệt kê, phép người đọc quan tâm có thơng tin chi tiết cách đọc thông số kỹ thuật BẢNG THUẬT NGỮ VIẾT TẮT UE SIP SPD IMS OMA DM IMS MO GPRS ICSI IANA URN PDP FQDN NAPTR UDP DHCP UAR URL URI HSS S-CSCF UICC USIM CS PS MCC MNC GRUU SLF XML P-CSCF DNS I-CSCF AOR IARI STT Tên hình Hình 1.1 Hình 1.2 Hình 1.3 Hình 1.4 Hình 1.5 Hình 1.6 Hình 1.7 Hình 1.8 Hình 1.9 10 Hình 1.10 11 Hình 1.11 Đăng ký P-CSCF thông tin trạng thái đăng ký Tobias 1.1 Tổng Quan Đăng ký Giao thức khởi đầu phiên (SIP) thực để liên kết địa Giao thức Internet (IP) người dùng sử dụng danh tính người dùng cơng khai người dùng, SIP URI (định danh tài nguyên thống nhất) Nếu Tobias muốn gọi cho Theresa, anh gửi yêu cầu SIP INVITE đến địa cô - tức là, sip: theresa@home2.hu; không cần biết Theresa sử dụng thiết bị đầu cuối INVITE sau chuyển đến tổ chức đăng ký tên miền Theresa, đặt home2.hu Tổ chức đăng ký tên miền biết địa trạm cuối Theresa trình đăng ký cô thay địa sip: theresa@home2.hu địa liên hệ đăng ký, địa IP Sau đó, yêu cầu chuyển đến trạm cuối Theresa Do đó, trường hợp IMS, Theresa cần phải đăng ký quan đăng ký SIP để phát địa đầu cuối cô Hệ thống đa phương tiện IP (IMS) kết hợp nhiều chức với thủ tục đăng ký SIP, điều khiến Tobias cần đăng ký, trước gọi cho em gái Các quy trình sau thực trình đăng ký IMS Tobias (xem Hình 11.1): : U E đ ợ c c ấ u h ì n h v i c c t h ô n g s ố c ấ u h ì n h c h u n g li ê n quan đến IMS Cấu hình xảy lần cho UE khôn g cần lặp lại cho lần đăng ký Khi Tobias đăng ký, UE lấy SIP URI: tobias@home1.fr từ ứng dụng ISIM chạy UICC mà nhận từ nhà điều hành đưa vào UE ISIM ln giữ danh tính người dùng công khai hợp lệ Tuy nhiên, dịch vụ IMS cung cấp cho người dùng sở hữu thẻ UICC khơng có ứng dụng ISIM đó, khơng có danh tính người dùng cơng khai hợp lệ Do đó, UE cần tạo danh tính người dùng cơng khai tạm thời từ liệu có sẵn từ ứng dụng USIM (xem Phần 3.5.4) sử dụng danh tính tạm thời để đăng ký Vì danh tính người dùng cơng khai tạm thời xây dựng từ liệu liên quan đến bảo mật USIM, nên danh tính không tiết lộ với thực thể bên ngồi IMS Do đó, coi "danh tính bị cấm": nghĩa mạng đặc biệt nên từ chối việc sử dụng danh tính bên đăng ký người dùng Trong trường hợp này, danh tính người dùng riêng tư lấy từ liệu USIM Nó có định dạng Nhận dạng thuê bao di động quốc tế (IMSI) làm phần người dùng, phần máy chủ, bao gồm Mã quốc gia di động (MCC) Mã mạng di động (MNC), hai bao gồm IMSI: ví dụ: danh tính người dùng riêng tư Tobias trơng giống như: 22330999999999@ims.mnc33.mcc222.3gppnetwork.org Tên miền mạng gia đình Tobias lấy từ USIM xuất giống phần miền danh tính người dùng: tức là, ims.mnc33.mcc222.3gppnetwork.org 1.16.4 Danh tính người dùng công khai mặc định / P-Associated-URI header Nếu Tobias sử dụng danh tính người dùng cơng khai tạm thời cho đăng ký ban đầu mình, anh gặp vấn đề anh đăng ký thực hành động khác (ví dụ: gọi cho chị gái đăng ký dịch vụ), anh đăng ký danh tính mà anh khơng sử dụng thêm (danh tính bị cấm) Thiết bị đầu cuối cần biết danh tính đăng ký ngầm Bất người dùng xác thực đăng ký thành công, S-CSCF, đó, gửi phản hồi 200 (OK) cho yêu cầu REGISTER, P-Associated-URI header, tiêu đề liệt kê tất SIP URI URL tel (tức công khai danh tính người dùng), liên kết khơng thiết phải đăng ký cho người dùng Chỉ URI liệt kê tiêu đề ln danh tính người dùng cơng khai hợp lệ, đăng ký sử dụng UE P-CSCF cho hành động P-Associated-URI phản hồi 200 (OK) yêu cầu REGISTER Tobias trông giống sau: 56 SIP/2.0 200 OK P-Associated-URI: , , , , Từ thông tin này, Tobias biết danh tính người dùng cơng khai sip: tobias@home1.fr đăng ký Anh ta biết có thêm hai SIP URI hai URI điện thoại mà sử dụng, liệu chúng đăng ký hay chưa Vì P-Associated-URI xác định để vận chuyển URI SIP, bao gồm URL điện thoại liên kết với Tobias (điện thoại: +44123456789 điện thoại: +44123456111) định dạng URI SIP 1.16.5 Chỉ định URI tác nhân người dùng định tuyến tồn cầu Cho đến nay, chúng tơi thấy hai loại danh tính, danh tính có liên quan đến người dùng, ví dụ: danh tính người dùng cơng khai sau danh tính riêng tư, có liên quan đến thiết bị Có trường hợp mà điều quan trọng không người dùng cụ thể, mà cịn thiết bị cụ thể giải Ví dụ cho trường hợp ví dụ: người dùng muốn chuyển liên tục gọi diễn từ điện thoại cố định người dùng sang điện thoại di động cụ thể (ví dụ trình bày Phần 12.10) Mặc dù danh tính cá nhân xác định (ít trường hợp điện thoại trang bị UICC) thiết bị, khơng sử dụng bên ngồi bối cảnh đăng ký, tiết lộ thông tin liên quan đến bảo mật Để lấp đầy khoảng trống này, ‘URI tác nhân người dùng định tuyến toàn cầu’ (GRUU) giới thiệu GRUU cho phép nhận dạng thiết bị theo cách mà thiết bị xác định phương tiện SIP Có hai loại GRUU: • GRUU cơng khai làm lộ danh tính người dùng, tức địa SIP người dùng mà GRUU định, dễ dàng xác định từ GRUU, ví dụ :sip:tobias@home1.fr; gr = jklhzzqw7as9asfd; • GRUU tạm thời ẩn danh tính người dùng, tức GRUU có địa SIP khơng cho phép xác định địa SIP người dùng, người mà GRUU định, ví dụ: sip:98hzah4pmmn@home1.net; gr Một thiết bị đầu cuối IMS yêu cầu GRUU công khai tạm thời trình đăng ký GRUU S-CSCF định mà khơng có tham gia HSS, GRUU không lưu trữ HSS Để yêu cầu định GRUU, điện thoại Tobias bao gồm instance-id parameter Contact header yêu cầu REGISTER mà gửi: 57 REGISTER sip:home1.fr SIP/2.0 Contact: "Mobile Phone – Tobias" ;+sip-instance="";expires=600000 Nếu đăng ký thành công, S-CSCF định GRUU công khai tạm thời gửi chúng trở lại Contact header phản hồi 200 (OK) yêu cầu REGISTER: SIP/2.0 200 OK Contact: "Mobile Phone – Tobias" ;pubgruu="sip:tobias@home1.fr;gr=urn:uuid:jklhzzqw7as9asfd" ;temp-gruu="sip:98hzah4pmmn@scscf1.home1.net;gr" ;+sipinstance="";expires=600000 Như hiển thị đây, GRUU liên quan đến hai, danh tính người dùng công khai đăng ký địa liên hệ, tức địa thiết bị, đăng ký GRUU bị ràng buộc với người dùng thiết bị GRUU xác định tham số ‘gr’ SIP URI GRUU công khai định SIP URI Tobias, cộng với tham số ‘gr’ đặt thành ID phiên đăng ký Từ đó, người dùng, người mà GRUU định, dễ dàng đọc GRUU tạm thời sử dụng tên người dùng chuỗi, tạo S-CSCF không hiển thị mối liên hệ với Tobias điện thoại Tobias Để đảm bảo GRUU tạm thời định tuyến mà không cần phải lưu trữ địa HSS, GRUU tạm thời hiển thị địa định S-CSCF (scscf1.home1.fr) phần người dùng Điều đảm bảo v.d I-CSCF không cố gắng phân giải GRUU từ SLF / HSS (xem Phần 12.3.3.4), chuyển tiếp trực tiếp dựa thông tin phần máy chủ GRUU tới S-CSCF định GRUU Ngoài ra, GRUU tạm thời bao gồm tham số ‘gr’, lần trống chuỗi tên người dùng tồn cầu khơng cần phân biệt thêm Cả S-CSCF cửa hàng điện thoại Tobias, công cộng GRUU tạm thời 1.16.6 Đăng ký UE Thông tin trạng thái đăng ký Sau đăng ký xác thực ban đầu thành công, thiết bị đầu cuối Tobias gửi yêu cầu SUBSCRIBE với thông tin sau: SUBSCRIBE sip:tobias@home1.fr SIP/2.0 Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;comp=sigcomp;branch=4uetb Route: 58 Route: From: "Tobias" ;tag=sipuli To: "Tobias" P-Preferred-Identity: "Tobias" Event: reg Expires: 600000 Accept: application/reginfo+xml Contact: "Mobile Phone – Tobias" Content-Length:0 Một lần nữa, tất thơng tin có u cầu SUBSCRIBE hiển thị - tiêu đề thông tin cần thiết để hiểu chất đăng ký kiện trạng thái đăng ký định tuyến yêu cầu Đăng ký dành cho kiện có tên 'reg', gói kiện trạng thái đăng ký; xác định Event header yêu cầu URI yêu cầu xác định người dùng có thơng tin trạng thái đăng ký u cầu đó, phải đặt thành danh tính người dùng công khai đăng ký Tobias phải To header Để tự nhận dạng, Tobias’s UE đặt To header P-Preferred-Identity thành SIP URI mà biết đăng ký Đó là: • danh tính người dùng cơng khai mặc định nhận P-AssociatedURI header (xem Phần 1.15.4); • danh tính người dùng cơng khai đăng ký rõ ràng trình đăng ký ban đầu miễn khơng phải danh tính người dùng công khai tạm thời (xem Phần 1.15.3) Nếu danh tính người dùng cơng khai tạm thời sử dụng, người dùng cơng khai đăng ký rõ ràng danh tính giống với danh tính người dùng cơng khai mặc định Mối quan hệ P-Preferred-Identity header, P-Asserted-Identity header To header mô tả Phần 12.2 To header không bao gồm thẻ, SUBSCRIBE u cầu ban đầu đó, thẻ định đầu từ xa (tức trường hợp S-CSCF) Expires header đặt thành giá trị với thời gian hết hạn đăng ký ban đầu (tức 600 000 giây, tức khoảng ngày) Accept header cho biết thơng tin thuộc loại ‘reginfo + xml’ xử lý UE cho đăng ký này, định dạng Ngôn ngữ đánh dấu (XML) cho thông tin trạng thái đăng ký Contact header đặt thành thông tin liên hệ sử dụng q trình đăng ký: Địa IP UE mạng truy cập định (xem Phần 1.3) cổng máy chủ bảo vệ IPsec SA sử dụng ( xem Phần 1.10) Cuối cùng, Route headers Tuyến đáng xem xét: chúng bao gồm tập hợp tuyến nhận Service-Route header phản hồi 200 (OK) cho yêu cầu REGISTER (xem Phần 1.12) địa P-CSCF, hoạt động proxy gửi Điều buộc yêu cầu SUBSCRIBE trước tiên phải chuyển đến P-CSCF sau chuyển tiếp trực tiếp đến S-CSCF định trình đăng ký 59 P-CSCF, nhận yêu cầu SUBSCRIBE từ UE, kiểm tra xem thơng tin đặt P-Preferred-Identity header có phải danh tính người dùng cơng khai hợp lệ Tobias hay khơng Nếu vậy, thay P-PreferredIdentity header P-Asserted-Identity header: SUBSCRIBE sip:tobias@home1.fr SIP/2.0 PAsserted-Identity: "Tobias" S-CSCF, nhận yêu cầu SUBSCRIBE này, kiểm tra xem người dùng xác định P-Asserted-Identity header có đăng ký S-CSCF hay khơng Sau đó, kiểm tra xem cung cấp thông tin trạng thái đăng ký yêu cầu Tobias cho người dùng đăng ký (Hình 11.11) Vì Tobias đăng ký thơng tin trạng thái đăng ký trường hợp này, điều cho phép Do đó, SCSCF lập tức: • trả lại 200 phản hồi (OK) cho yêu cầu SUBSCRIBE, cho biết đăng ký thành cơng; • tạo tài liệu XML kiểu reginfo, bao gồm thông tin trạng thái đăng ký cho URI liên kết với Tobias; • gửi tài liệu XML tạo dạng tin nhắn NOTIFY tới người đăng ký (trong trường hợp Tobias’s UE) Vì phản hồi 200 (OK) yêu cầu NOTIFY gửi gần lúc, yêu cầu NOTIFY nhận thiết bị đầu cuối trước phản hồi 200 (OK) Trong trường hợp ngoại lệ này, UE phải tạo hộp thoại đăng ký liên quan dựa u cầu NOTIFY: nghĩa là, khơng hủy thơng tin nhận u cầu NOTIFY khơng nhận phản hồi 200 (OK) trước cho yêu cầu SUBSCRIBE 60 Hình 1.10 Đăng ký Tobias thông tin trạng thái đăng ký anh 1.16.7 Đăng ký P-CSCF Thông tin trạng thái đăng ký P-CSCF cần đăng ký thông tin trạng thái đăng ký Tobias đó, tạo u cầu SUBSCRIBE, trơng giống yêu cầu mà thiết bị đầu cuối tạo ra: SUBSCRIBE sip:tobias@home1.fr SIP/2.0 Via: SIP/2.0/UDP pcscf1.visited1.fi From: ;tag=retiisi To: "Tobias" PAsserted-Identity: Event: reg Expires: 600000 Accept: application/reginfo+xml Contact: Content-Length: Sự khác biệt P-CSCF đăng ký thông tin trạng thái đăng ký Tobias (Hình 11.12); đó, phải tự nhận dạng From header P-Asserted-Identity header Vì P-CSCF thực thể đáng tin cậy (xem Phần 3.21.4.2), đưa P-Asserted-Identity header vào u cầu Vì P-CSCF khơng lưu thông tin định tuyến giai đoạn đăng ký ban đầu cho mục đích định tuyến riêng nó, khơng có kiến thức S-CSCF định cho người dùng đó, bao gồm Route headers Do đó, định tuyến yêu cầu sở phần máy chủ URI yêu cầu, 'home1.fr' phân giải qua DNS tới nhiều địa I-CSCF mạng gia đình 61 Tobias Sau I-CSCF truy vấn HSS địa S-CSCF định cho URI sip: tobias@home1.fr gửi yêu cầu đến S-CSCF Lưu ý với yêu cầu SUBSCRIBE này, hộp thoại tạo, lần P-CSCF S-CSCF Hộp thoại không liên quan đến việc UE đăng ký thơng tin trạng thái đăng ký; đó, S-CSCF tạo NOTIFY yêu cầu, bao gồm thông tin trạng thái đăng ký Tobias, cho UE đăng ký P-CSCF Hình 1.11 Đăng ký P-CSCF thông tin trạng thái đăng ký Tobias 1.16.8 Các yếu tố thông tin trạng thái đăng ký S-CSCF tạo NOTIFY với thông tin trạng thái đăng ký Tobias sau nhận đăng ký thông tin trạng thái đăng ký thay đổi (ví dụ: danh tính người dùng cơng khai đăng ký) Trong phần này, xem xét yêu cầu NOTIFY thông tin trạng thái đăng ký mà thiết bị đầu cuối Tobias nhận sau đăng ký Thông tin giống với thơng tin mà P-CSCF nhận nhiều giống thời gian Yêu cầu NOTIFY mà UE Tobias nhận bao gồm tiêu đề sau: NOTIFY sip:[5555::1:2:3:4]:1357;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP scscf1.home1.fr;branch=nosctb Via: SIP/2.0/UDP pcscf1.visited1.fi:7531;branch=nopctb From: "Tobias" ;tag=peruna To: "Tobias" ;tag=sipuli> Subscription-State: active;expires=599999 Event: reg Content-Type: application/reginfo+xml 62 Contact: Content-Length: ( ) Những điều cần lưu ý yêu cầu NOTIFY là: • To header From header thay đổi yêu cầu gửi từ Người thông báo (SCSCF) đến Người đăng ký (Tobias’s UE) Mặc dù hai tiêu đề có nội dung gần giống thẻ chúng lại khác S-CSCF thêm thẻ ‘Too’ (‘peruna’), thẻ xuất From header; • Một Subscription-State header thêm vào, cho biết đăng ký hoạt động hết hạn sau 599 999 giây 1.16.9 Thông tin trạng thái đăng ký phần nội dung yêu cầu thông báo Thông tin trạng thái đăng ký cho URI liên kết với Tobias bao gồm phần nội dung yêu cầu NOTIFY thể chi tiết Phần 11.13.9 Thông tin trạng thái đăng ký danh sách phân cấp bao gồm: • Phần tử gốc ‘reginfo’, bao gồm thông tin trạng thái đăng ký liên kết với người dùng; • Một nhiều phần tử ‘contact’ phần tử gốc ‘reginfo’ Phần tử ‘registration’ bao gồm thông tin xác URI (tức danh tính người dùng cơng khai); • Khơng nhiều phần tử ‘contact’ phần tử ‘registration’ Một ‘contact’ phần tử phụ bao gồm thông tin địa đăng ký (đăng ký đăng ký) cho URI phần tử phụ ‘registration’; • Một phần tử ‘uri’ phần tử ‘contact’, cho biết địa liên hệ đăng ký; • Khơng phần tử ‘display-name’ phần tử ‘contact’, cho biết tên hiển thị đặt Contact header cho địa liên hệ có liên quan; • Khơng phần tử 'gr: pub-gruu' không phần tử 'gr: tempgruu' phần tử 'contact', cho biết GRUU công khai tạm thời gán cho thiết bị trình đăng ký ( xem Phần 1.15.5); • Khơng nhiều phần tử ‘unknown-parameter’ phần tử ‘contact’ Phần tử phụ ‘unknown-parameter’ bao gồm tham số khác có Contact header q trình đăng ký (các thẻ tính vậy) Mỗi phần tử đăng ký bao gồm thuộc tính sau: • Thuộc tính Address Of Record (AOR), theo sau URI cho danh tính người dùng cơng khai; • Thuộc tính ID, xác định phần tử phụ đăng ký số tất phần tử khác; • Thuộc tính trạng thái phần tử đăng ký, cho biết liệu định URI trạng thái sau: ◦ ‘active’ (tức đăng ký); ◦ ‘terminated’ (tức hủy đăng ký); ◦ ‘init’ (tức trình đăng ký, chẳng hạn nhận yêu cầu REGISTER ban đầu thủ tục xác thực chưa hoàn tất) 63 Mỗi phần tử phụ liên hệ bao gồm địa liên hệ đăng ký bao gồm thuộc tính sau: • Thuộc tính ID, xác định phần tử phụ liên hệ số tất phần tử khác; • Thuộc tính trạng thái phần tử liên hệ, cho biết liệu liên hệ định liên quan đến URI phần tử đăng ký - có trạng thái sau: ◦ ‘active’ (tức URI đăng ký với thông tin liên hệ này); ◦ ‘terminated’ (nghĩa ràng buộc URI thông tin liên hệ vừa gỡ bỏ) • Thuộc tính kiện phần tử phụ liên hệ, cho biết kiện gây thay đổi thuộc tính trạng thái liên hệ Các kiện là: ◦ đăng ký - kiện chuyển địa liên hệ từ trạng thái 'init' sang trạng thái ‘active’ AOR đăng ký rõ ràng (nghĩa là, yêu cầu REGISTER hợp lệ nhận cho AOR thông tin liên hệ liên quan ràng buộc với nó); ◦ tạo - kiện có ý nghĩa với kiện đăng ký, AOR đăng ký ngầm (tức là, liên kết tạo tự động, chẳng hạn nhận yêu cầu REGISTER cho AOR khác); ◦ làm - kiện xảy đăng ký lại AOR diễn xảy ngầm (tức đăng ký lại AOR liên kết thực hiện); ◦ rút ngắn - kiện xảy mạng rút ngắn thời gian hết hạn AOR (ví dụ: để kích hoạt xác thực lại mạng bắt đầu, xem Phần 11.14.2); ◦ vơ hiệu hóa - kiện xảy mạng bị xóa ràng buộc (ví dụ: hủy đăng ký mạng khởi tạo), cho phép người dùng thực lần đăng ký ban đầu sau đó; ◦ thời gian thử - với kiện này, mạng hủy đăng ký người dùng yêu cầu họ gửi đăng ký ban đầu sau thời gian định (phụ thuộc vào giá trị thử lại sau); ◦ chưa đăng ký - kiện xảy người dùng hủy đăng ký liên hệ cách rõ ràng; ◦ bị từ chối - kiện xảy mạng không cho phép người dùng đăng ký số liên lạc cụ thể • Các thuộc tính bổ sung, chẳng hạn như: ◦ thuộc tính expires - cho biết thời gian hết hạn lại đăng ký cho địa liên hệ cụ thể (nó phải đặt cho kiện rút gọn, đặt tùy ý cho kiện khác); ◦ thuộc tính đăng ký thời lượng - hiển thị thời gian liên hệ đăng ký; ◦ thuộc tính callid - cho biết giá trị Call-ID header yêu cầu REGISTER mà địa liên hệ đăng ký; ◦ thuộc tính cseq - cho biết giá trị số Cseq header yêu cầu REGISTER mà địa liên hệ đăng ký; ◦ thuộc tính thử lại sau - thuộc tính đặt cho kiện thử việc cho biết UE phải đợi trước thử đăng ký lại 64 1.16.10 Ví dụ Thơng tin Đăng ký-Trạng thái Thơng tin trạng thái đăng ký Tobias bao gồm phần nội dung yêu cầu NOTIFY mà S-CSCF gửi tới UE P-CSCF Trước hết, bao gồm XML tiêu đề tài liệu: Tiêu đề cho biết phiên XML sử dụng (1.0) Thông tin đăng ký bắt đầu phần tử gốc, có tên ‘reginfo’, bao gồm số thuộc tính: • Thuộc tính xmlns trỏ đến Tên nguồn đồng (URN) xác định tài liệu XML khơng gian tên XML; • Thuộc tính phiên bắt đầu giá trị ‘0’ tăng lên phiên (cập nhật) thông tin trạng thái đăng ký gửi đến người nhận; • Thuộc tính trạng thái thông tin trạng thái đăng ký sau danh sách đầy đủ tất AOR có liên quan đến Tobias Phiên ('0') tài liệu reginfo cần gửi dạng danh sách hồn chỉnh ('full') - thơng tin (bắt đầu từ '1') gửi dạng 'partial' bao gồm thơng tin có thay đổi kể từ lần thông báo cuối Tất danh tính người dùng cơng khai liên quan đến Tobias trạng thái đăng ký họ liệt kê tài liệu: sip:[5555::1:2:3:4]:1357 Mobile Phone – Tobias "INVITE,BYE,ACK,OPTIONS,CANCEL,NOTIFY,MESSAGE,PRACK,U PDATE" "urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel, urn%3Aurn-xxx%3Aother-vendor-service-ims.icsi.ongame" 65 "urn%3Aurn-xxx%3Aother-app-ims.iari.firefighter" "<urn:uuid: jklhzzqw7as9asfd>" AOR URI sip: tobias@home1.fr, mà biết từ ví dụ Nó đăng ký (trạng thái = ‘active’) Nội dung phần tử phụ đăng ký phần tử phụ liên hệ, hiển thị ràng buộc tạo S-CSCF sip: tobias@home1.fr thông tin liên hệ sip [55551234] (phần tử phụ ‘uri’) Thuộc tính kiện đặt thành "registered", cho biết AOR đăng ký rõ ràng với địa liên hệ Ngoài điều này, chúng tơi thấy số thuộc tính khác, cung cấp thêm thông tin địa liên hệ đăng ký, chẳng hạn ví dụ: thuộc tính thời lượng đăng ký, cho biết thời gian liên hệ đăng ký Tất thông tin khác thông số đăng ký rõ ràng với người liên hệ hiển thị đây, tức là: • tên hiển thị điện thoại Tobias đặt để dễ dàng nhận dạng điện thoại số tất đăng ký diễn khác; • khả callee đăng ký cho âm thanh, video, tính di động phương pháp, mô tả Phần 11.9.2 phần tử phụ tham số không xác định; • Nhận dạng Dịch vụ Truyền thơng IMS (ICSI) Nhận dạng Tham chiếu Ứng dụng IMS (IARI), mô tả Phần 11.9.3 phần tử phụ tham số khơng xác định; • id cá thể từ máy khách, mô tả Phần 1.16.5 phần tử phụ tham số khơng xác định; • GRUU công cộng tạm thời gán cho thiết bị mô tả Phần 1.15.5 phần tử gr: pub-gruu gr: temp-gruu sip:[5555::1:2:3:4]:1357 Mobile Phone – Tobias "INVITE,BYE,ACK,OPTIONS,CANCEL,NOTIFY,MESSAGE,PRACK,U 66 PDATE" "urn%3Aurn-xxx%3A3gpp-service-ims.icis.mmtel, urn%3Aurn-xxx%3Aother-vendor-service-ims.icsi.ongame" "urn%3Aurn-xxx%3Aother-app-ims.iari.firefighter" "<urn:uuid: 12jklhzzqw7as9asfd>>" AOR SIP URI khác đăng ký ngầm (sự kiện = ‘create’) với địa IP với AOR Đăng ký ngầm thực bởiS-CSCF, dựa hồ sơ người dùng Tobias Do đăng ký ngầm, tất khả callee (tức thẻ tính năng, bao gồm giá trị ICSI IARI) danh tính người dùng cơng khai đăng ký rõ ràng áp dụng cho tất danh tính người dùng đăng ký ngầm chúng chép dạng tham số khơng xác định Ngồi ra, GRUU cơng khai tạm thời gán cho URI, chúng khơng giống với danh tính người dùng cơng khai đăng ký rõ ràng GRUU công khai thêm instance-id vào SIP URI phần tử đăng ký GRUU tạm thời có giá trị khác Các giá trị GRUU riêng biệt định cho giá trị đăng ký ngầm định danh tính người dùng cơng khai Để phần dễ đọc hơn, tên hiển thị, tham số không xác định phần tử phụ liên quan đến GRUU số thuộc tính khơng hiển thị thêm ví dụ sip: [5555::1:2:3:4]:1357 AOR URL điện thoại đăng ký ngầm (event = ‘create’) với địa IP với AOR Đăng ký ngầm thực S-CSCF, dựa hồ sơ người dùng Tobias 67 Hai AOR chưa đăng ký (trạng thái = ‘terminated’) đó, phần tử phụ đăng ký hồn tồn khơng bao gồm thơng tin Cuối cùng, Tobias bậc thầy trò chơi game nhập vai trực tuyến Anh nhận công việc trị chơi nghiêm túc đó, ln đăng ký từ bảng điều khiển trị chơi có địa sip: [5555 :: 101: 102: 103: 104]: 1458 Địa liên hệ bảng điều khiển trò chơi đăng ký rõ ràng (sự kiện 14 "registered") Tuy nhiên, Tobias muốn thơng báo tình trạng diễn trị chơi anh trực tuyến với IMS UE mình; đó, AOR S-CSCF đăng ký ngầm (sự kiện = ‘create’) nhận yêu cầu REGISTER cho sip: tobias@home1.fr: sip:[5555::101:102:103:104]:1458 sip:[5555::1:2:3:4]:1357 Dịng cuối thơng tin trạng thái đăng ký hiển thị thẻ kết thúc tài liệu XML 1.16.11 Nhiều thiết bị đầu cuối thông tin trạng thái đăng ký Một nhiều danh tính người dùng cơng khai đăng ký từ thiết bị đầu cuối khác (tức UE khác nhau) Trong ví dụ chúng tơi, Tobias sở hữu thiết bị phân trang đơn giản sử dụng danh tính người dùng cơng khai mình: tobias@home1.fr Thiết bị cần phải thực thủ tục đăng ký trước sử dụng dịch vụ IMS Việc đăng ký thiết bị diễn qua P-CSCF khác, kết thúc S-CSCF với lần đăng ký Sau đó, S-CSCF thực đăng ký rõ ràng ngầm định Vì địa đăng ký thuộc tập hợp đăng ký gồm ba danh tính người dùng cơng khai khác nhau, nên ba danh tính đăng ký với địa liên hệ Sau thiết bị phân trang đăng ký, UE Tobias P-CSCF anh nhận thông báo NOTIFY khác cho biết thông tin liên hệ bổ sung cho danh tính người dùng cơng khai có: tức thơng tin liên quan đến AOR phần nội dung NOTIFY bao gồm thông tin sau: 68 sip: [5555::1:2:3:4]:1357 sip:[5555::171:171:172:173]:1579 sip:[5555::1:2:3:4]:1357 sip:[5555::171:171:172:173]:1579 sip:[5555::1:2:3:4]:1357 sip:[5555::171:171:172:173]:1579 Ln ln có nhiều thơng tin liên lạc thứ hai thông tin đăng ký liên quan đến thiết bị phân trang Lưu ý lô thông tin trạng thái đăng ký thứ hai mà UE nhận Để đảm bảo khơng có thơng tin trạng thái đăng ký bị mất, tham số ‘version’ đặt thành ‘1’ (lơ thơng tin có phiên = ‘0’) Trong NOTIFY bao gồm thông tin trạng thái đăng ký đầy đủ, UE nhận thông tin yếu tố đăng ký thay đổi, trường hợp AOR sip: tobias@home1.fr Do đó, thơng số trạng thái đặt thành 'partial' (trong lô thông tin đặt thành 'full') 1.16.12 Các tiêu chuẩn liên quan Các thông số kỹ thuật liên quan đến Mục 1.16 là: 3GPP TS 23.003: Đánh số, định địa nhận dạng RFC3265: Thông báo kiện cụ thể giao thức bắt đầu phiên (SIP) RFC3325: Tiện ích mở rộng riêng cho Giao thức bắt đầu phiên (SIP) cho Danh tính xác nhận Mạng tin cậy RFC3455: Phần mở rộng Tiêu đề Riêng (P-Header) cho Giao thức Khởi đầu Phiên (SIP) cho Dự án Đối tác Thế hệ thứ (3GPP) RFC3680: Gói kiện giao thức khởi đầu phiên (SIP) cho đăng ký 69 KẾT LUẬN Sau thời gian nghiên cứu với nỗ lực nhóm, đề tài “Các Thủ Tục Đăng Kí Trong IMS” nhóm sinh viên Dương Tú Kiên, Trần Văn Lâm, Trần Mạnh Hùng, Phạm Tiến Hưng hoàn thành với số kết sau Tiểu luận giúp chúng em hiểu rõ giao thức khởi tạo phiên (SIP), giao thức mô tả phiên (SDP) chi tiết q trình đăng kí IMS Do thời gian nghiên cứu có hạn nên tiểu luận khơng thể tránh khỏi thiếu sót, nhóm em mong nhận ý kiến đóng góp từ thầy cô giáo bạn Một lần em xin chân thành cảm ơn Thầy giáo TS Hoàng Trọng Minh giảng dạy môn Chuyên đề giúp cho nhóm em hồn thiện tiểu luận Nhóm em xin chân thành cảm ơn 70 ... trường hợp IMS, Theresa cần phải đăng ký quan đăng ký SIP để phát địa đầu cuối cô Hệ thống đa phương tiện IP (IMS) kết hợp nhiều chức với thủ tục đăng ký SIP, điều khiến Tobias cần đăng ký, trước... địa Chức điều khiển phiên gọi proxy (PCSCF), mà sử dụng làm proxy gửi SIP đăng ký cho tất báo hiệu SIP khác đăng ký 1.5: UE gửi tin nhắn ĐĂNG KÝ tới mạng gia đình Tobias để thực đăng ký SIP cho... Thiết lập bối cảnh báo hiệu PDP Trước Tobias’s UE bắt đầu quy trình đăng ký IMS, Tobias cần thiết lập kết nối IP với mạng Trong trường hợp GPRS, kết nối IP cung cấp ngữ cảnh PDP báo hiệu chun dụng