S-CSCF sẽ nhận tất cả các yêu cầu ban đầu được gửi đến Tobias, vì nó hoạt động như một công ty đăng ký của anh ta. Các thủ tục SIP thông thường cho phép nhà đăng ký gửi yêu cầu trực tiếp đến UE. Trong trường hợp IMS, điều này là khơng thể, vì P- CSCF cần được liên hệ trước; điều này là do P-CSCF đã thiết lập IPsec SA với UE để đảm bảo rằng tất cả các thông báo sẽ được gửi và nhận được bảo vệ tồn vẹn (xem Phần 1.10). Hơn nữa, P-CSCF có một vai trị quan trọng trong việc cấp phép phương tiện (xem Phần 1.10.2) vì nó là chỉ phần tử mạng trong IMS có kết nối trực tiếp với GGSN. Do đó, S-CSCF cần đảm bảo rằng mọi yêu cầu được gửi đến UE trước tiên đều đi qua P-CSCF. Để thực hiện điều này, P-CSCF bao gồm địa chỉ riêng của mình trong mọi yêu cầu ĐĂNG KÝ trong tiêu đề Đường dẫn:
REGISTER sip:home1.fr SIP/2.0 Path: sip:pcscf1.visited1.fi;lr
Hình 1.9 Định tuyến trong quá trình đăng ký
Sau khi người dùng đăng ký thành công, S-CSCF sẽ lưu địa chỉ P-CSCF này. Bất cứ khi nào nhận được yêu cầu Tobias, S-CSCF sẽ bao gồm tiêu đề Tuyến đường với địa chỉ đã nhận được trong tiêu đề Đường dẫn. Ví dụ về định tuyến một yêu cầu INVITE ban đầu đối với người dùng được phục vụ được nêu trong Phần 12.3.3.5.
1.14 Đăng ký tại S-CSCF
Sau khi nhận được yêu cầu REGISTER ban đầu, S-CSCF sẽ u cầu Tobias xác thực chính mình, như được mô tả trong Phần 10.6. Điều này sẽ dẫn đến một yêu cầu ĐĂNG KÝ khác từ Tobias. Yêu cầu REGISTER thứ hai này sẽ bao gồm cùng một thông tin liên quan đến đăng ký và cũng sẽ được định tuyến theo cách giống hệt như yêu cầu ĐĂNG KÝ ban đầu. Do đó, các số CSeq mới, thông số nhánh và thẻ FROM mới sẽ được bao gồm trong đó. REGISTER thứ hai mà S-CSCF nhận được sẽ giống như sau:
Giả sử rằng các thủ tục xác thực thành cơng, S-CSCF sau đó sẽ đăng ký Tobias. Điều này có nghĩa là S-CSCF sẽ tạo ràng buộc cho danh tính người dùng cơng khai đã được chỉ ra trong tiêu đề To của yêu cầu REGISTER (sip: tobias@home1.fr) và địa chỉ liên hệ (sip: [5555 :: a: b: c: d]). Liên kết này sẽ tồn tại trong đúng 600 000 giây, là giá trị mà UE đã nhập vào tham số ‘expires’ của tiêu đề Liên hệ, trừ khi S-CSCF quyết định giảm thời gian này do chính sách cục bộ.
S-CSCF cũng cập nhật thơng tin trong HSS để cho biết rằng Tobias hiện đã được đăng ký và để tải xuống hồ sơ người dùng của Tobias (xem Phần 3.12). Do đó, S-CSCF thực hiện các thủ tục Thông báo đăng ký Diameter S-CSCF qua giao diện Cx bằng cách gửi Yêu cầu chuyển nhượng máy chủ Diameter (SAR) tới HSS, bao gồm: • cờ lệnh ‘R’ được đặt thành ‘1’, cho biết đây là yêu cầu Diameter Request;
• Command-Code được đặt thành ‘301’, cho biết lệnh Diameter ‘Server Assignment’; • AVP ‘Public-Identity’ (600), cho biết danh tính người dùng cơng khai đang được đăng ký, tức là URI có trong tiêu đề To của yêu cầu REGISTER:
‘sip:tobias@home1.fr’;
• AVP ‘Server-Name’ (602) được đặt thành SIP URI của S-CSCF thực hiện SAR, tức là. ‘sip: scscf1.home1.fr’;
• AVP ‘User-Name’ (1) được đặt thành danh tính riêng của Tobias, được chỉ ra trong trường tên người dùng trong tiêu đề Cấp phép của yêu cầu ĐĂNG KÝ SIP (xem Phần 1.9.3), nghĩa là 'tobias private@home1.fr ';
• AVP ‘Server-Assignment-Type’ (614) được đặt thành giá trị ‘REGISTRATION’ (1) vì đây là đăng ký ban đầu. Các giá trị khác của AVP kiểu máy chủ chỉ định có thể ví
dụ như 'REGISTER' (2) khi điện thoại của Tobias gửi yêu cầu REGISTER khác để giữ cho đăng ký đang hoạt động (xem Phần 11.14) hoặc 'REGISTER USER' (5) khi
Tobias gửi một yêu cầu REGISTER khác với thời gian hết hạn được đặt thành ‘0’ (xem Phần 11.14.1); (xem Phần 11.14.1);
• AVP ‘UserData-Already-Available’ (624) được đặt thành ‘USER DATA NOT AVAILABLE’ (0), chỉ ra rằng S-CSCF khơng có sẵn hồ sơ dịch vụ của Tobias; • AVP ‘Origin-Host’ (264) đặt địa chỉ của S-CSCF, tức là ‘scscf1.home1.fr’;
• AVP ‘Origin-Realm’ (296) được đặt thành tên miền của mạng điều hành mà I-CSCF được đặt, tức là ‘home1.fr’;
• AVP ‘Destination-Realm’ (283) được đặt thành miền chính của HSS, tức là ‘home1.fr’, vì đây là miền mà thơng tin vị trí người dùng được truy vấn trong đó; • AVP ‘Destination-Host’ (293) được đặt thành địa chỉ của HSS, địa chỉ này cần được cấu hình cục bộ trong S-CSCF, vì khơng có truy vấn SLF nào được thực hiện.
HSS hiện chỉ định tên S-CSCF cho tập đăng ký danh tính người dùng cơng khai Tobiases. Điều này có nghĩa là, miễn là Tobias vẫn được đăng ký với S-CSCF này, mọi truy vấn vị trí được gửi đến HSS hỏi cách định tuyến các yêu cầu dành cho Tobias hơn nữa (xem ví dụ: Phần 12.3.3.4) sẽ được phản hồi bởi HSS với địa chỉ của S-
CSCF.
HSS cũng đặt hồ sơ người dùng của Tobias thành 'đã đăng ký', điều này có thể dẫn đến thơng báo Sh-Notification tới các Máy chủ ứng dụng được đính kèm (xem Phần 2.3.7). HSS gửi lại Diameter Server Assignment Answer (SAA) tới S-CSCF, chứa:
• cờ lệnh ‘R’ được đặt thành ‘0’, cho biết rằng đây là Diameter answer;
• Command-Code được đặt thành ‘301’, cho biết lệnh Diameter ‘Server Assignment’; • AVP ‘User-Name’ (1) được đặt thành danh tính riêng của Tobias, tức là thành ‘tobias private @ home1.fr’;
• AVP ‘Result-Code’ (268) được đặt thành ‘DIAMETER SUCCESS’ (2001), cho biết rằng yêu cầu đã thành cơng;
• AVP ‘User-Data’ (606), bao gồm hồ sơ người dùng của Tobias (xem Phần 3.12) • AVP ‘Charging-Information’ (618), chứa địa chỉ của các chức năng tính phí (xem Phần 11.12) trong các AVP sau:
- AVP ‘Primary-Event-Charging-Function-Name’ (619) bao gồm địa chỉ của chức năng tính phí trực tuyến chính (OCF - xem Phần 3.11) '5555 :: f66: e77: d88: c77', sẽ được phân phối trong tiêu đề P-Charging-Function-Address (xem Phần 3.11.4); - AVP ‘Secondary-Event-Charging-Function-Name’ (620) bao gồm địa chỉ của OCF thứ cấp, được lưu trữ tại S-CSCF;
- AVP ‘Primary-Charging-Collection-Function-Name’ (621) bao gồm địa chỉ của chức năng dữ liệu tính phí chính (CDF - xem Phần 3.11 '5555 :: a55: b44: c33: d22', sẽ được phân phối trong tiêu đề P-Charging-Function-Address (xem Phần 12.7.4);
- AVP ‘Secondary-Charging-Collection-Function-Name’ (622) bao gồm địa chỉ của CDF thứ cấp, được lưu trữ tại S-CSCF.
tùy chọn AVP ‘Associated-Identities’ (632), chứa danh tính riêng tư có liên quan (lưu ý: khơng phải danh tính cơng khai) của cùng một người dùng, trong trường hợp này là Tobias. Tobias có thể có một số điện thoại, mỗi điện thoại được trang bị USIM / ISIM và anh ta có thể có thêm tên người dùng HTTP Digest (danh tính riêng tư) và mật khẩu - trong những trường hợp này, danh sách nhận dạng cá nhân được gửi xuống S-CSCF.
1.15 Thông tin niên quan đến tính phí trong khi đăng ký
Khái niệm tính phí và các thực thể liên quan trong mạng được mô tả trong Phần 3,18. Phần hiện tại chỉ giải thích cách xử lý và nội dung của các tiêu đề SIP là liên quan đến việc tính phí trong q trình đăng ký. Tính phí các phiên IMS được mơ tả trong Phần 12,7. Khi P-CSCF nhận được yêu cầu ĐĂNG KÝ ban đầu, nó sẽ tạo ra một IMS Charging ID (ICID), có giá trị đối với tất cả các tín hiệu liên quan đến IMS miễn là người dùng vẫn đăng ký. Giá trị ICID được chuyển từ P-CSCF đến S-CSCF trong P- Charging-Vector tiêu đề:
REGISTER sip:home1.fr SIP/2.0
P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" S-CSCF khi nhận được tiêu đề này sẽ lưu trữ ICID và sẽ thực hiện sạc các thủ tục như được mô tả trong Phần 12.7. Tiêu đề P-Charging-Vector được định nghĩa trong
[RFC3455]. Các tiện ích mở rộng cho tiêu đề này và cách sử dụng nó trong IMS được mô tả trong [3GPP TS 24.229].
1.16 Danh tính người dùng 1.16.1 Tổng quát
Tobias cần đăng ký trong mạng gia đình của mình để có thể bắt đầu cuộc gọi cho em gái của mình. Trong một lần gần đây, anh ấy đã sử dụng SIP URI sip:
tobias@home1.fr để đăng ký. Đây là danh tính người dùng mà Tobias sử dụng khi anh ta sử dụng các dịch vụ IMS khơng liên quan đến cơng việc. Tuy nhiên, Tobias có tồn bộ danh tính người dùng được đăng ký tại nhà điều hành của mình ở Pháp, được thể hiện trong Bảng 11.3.
Bảng 11.3 Danh tính người dùng cơng khai của Tobias
Trong Bảng 11.3, một tập hợp đăng ký có thể bao gồm một số URI SIP và URL điện thoại. Đối với mỗi URL tel phải có sẵn một URI SIP liên quan trong mạng, tức là phần người dùng SIP URI lấy giá trị số của URL tel. Các URL điện thoại này và các URI SIP liên quan của chúng là Danh tính Người dùng Cơng cộng Bí danh (ID Bí danh), có nghĩa là chúng chia sẻ chính xác cùng một hồ sơ người dùng trong HSS. Trong thủ tục đăng ký ban đầu, Tobias chỉ có thể đăng ký rõ ràng một trong các URI này, trong ví dụ của chúng tôi là sip: tobias@home1.fr. Tuy nhiên, IMS cho phép đăng ký ngầm và rõ ràng các danh tính người dùng cơng khai khác:
• Một số danh tính được liệt kê ở trên có thể được mạng đăng ký tự động (ngầm) trong giai đoạn đăng ký ban đầu;
• Những người khác có thể vẫn chưa đăng ký cho đến khi Tobias yêu cầu họ được đăng ký một cách rõ ràng.
Khi nhận được phản hồi 200 (OK) cho yêu cầu REGISTER thứ hai, cả thiết bị đầu cuối của Tobias và P-CSCF đều phát hiện ra danh tính người dùng cơng khai mặc định của Tobias, nhận dạng này được nhận làm URI đầu tiên trong P-Associated-URI header.
Để tìm hiểu thêm về trạng thái đăng ký của các danh tính người dùng cơng khai khác được gán cho Tobias, UE tự động đăng ký thông tin sự kiện trạng thái đăng ký được cung cấp bởi S-CSCF trong mạng gia đình. Nó bắt buộc UE thực hiện đăng ký này ngay lập tức sau khi đăng ký ban đầu thành cơng, bởi vì:
• UE cần nhận được trạng thái đăng ký của các URI được liên kết;
• đăng ký cho phép mạng (S-CSCF) buộc UE thực hiện xác thực lại (xem Phần 11.14.2); • đăng ký cho phép mạng (S-CSCF) hủy đăng ký người dùng (xem Phần 11.14.3);
Song song đó, P-CSCF cũng thực hiện đăng ký thơng tin trạng thái đăng ký của người dùng, chủ yếu để được thông báo về việc hủy đăng ký do mạng khởi tạo (xem Phần 11.14.3).
1.16.2 Danh tính người dùng cơng khai và cá nhân để đăng ký
Các danh tính đi vào yêu cầu REGISTER đầu tiên được đọc từ ISIM, một trong những ứng dụng có trên UICC trong UE. Dữ liệu đọc từ ISIM bao gồm:
• danh tính người dùng riêng của người dùng;
• danh tính người dùng cơng khai của người dùng, được sử dụng để đăng ký; và • địa chỉ của nhà đăng ký SIP của người dùng.
Danh tính người dùng riêng tư chỉ được sử dụng để xác thực, được mơ tả trong Phần 11.6. Danh tính người dùng cơng khai là SIP URI mà Tobias sẽ đăng ký ban đầu. Có thể có nhiều danh tính người dùng cơng khai hơn cho Tobias, một số danh tính thậm chí có thể được lưu trữ trên ISIM; tuy nhiên, lúc đầu chỉ có một được đăng ký rõ ràng. Nếu UE khơng được trang bị ISIM, nó sẽ lấy danh tính và địa chỉ của nhà đăng ký từ ứng dụng USIM cũng nằm trong UICC. USIM bao gồm tất cả dữ liệu liên quan đến người dùng cần thiết cho việc đăng ký và xác thực miền chuyển mạch theo mạch (CS) và chuyển mạch gói (PS). Điều này được mô tả chi tiết hơn trong Phần 1.15.2
Được trang bị các tham số này, UE có thể điền vào các trường sau của yêu cầu REGISTER ban đầu:
REGISTER sip:home1.fr SIP/2.0
From: <sip:tobias@home1.fr>;tag=pohja To: <sip:tobias@home1.fr>
Authorization: Digest username="tobias private@home1.fr", realm="home1.fr",
nonce="",
uri="sip:home1.fr", response=""
Danh tính người dùng cơng khai, như được đọc từ ISIM, được đưa vào To và From header. Giá trị của trường tên người dùng của Authorization header nhận giá trị của danh tính người dùng riêng tư và địa chỉ của tổ chức đăng ký tên miền được đưa vào URI yêu cầu của yêu cầu cũng như trong các trường cảnh giới và tiểu của
Authorization header.
Khi Tobias đăng ký, UE của anh ta sẽ lấy SIP URI: tobias@home1.fr từ ứng dụng ISIM đang chạy trên UICC mà anh ta nhận được từ nhà điều hành của mình và đưa vào UE của mình. ISIM ln giữ ít nhất một danh tính người dùng cơng khai hợp lệ. Tuy nhiên, các dịch vụ IMS cũng có thể được cung cấp cho người dùng sở hữu thẻ UICC khơng có ứng dụng ISIM và do đó, 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ừ dữ liệu có sẵn từ ứng dụng USIM (xem Phần 3.5.4) và sử dụng danh tính tạm thời này để đăng ký. Vì danh tính người dùng cơng khai tạm thời được xây dựng từ dữ liệu liên quan đến bảo mật trên USIM, nên danh tính này khơng được tiết lộ với bất kỳ thực thể nào bên ngồi IMS. Do đó, nó được coi là "danh tính bị cấm": nghĩa là mạng đặc biệt nên từ chối bất kỳ việc sử dụng danh tính này bên ngồi đăng ký của người dùng.
Trong trường hợp này, danh tính người dùng riêng tư cũng sẽ được lấy từ dữ liệu USIM. Nó sẽ có định dạng Nhận dạng thuê bao di động quốc tế (IMSI) làm phần người dùng, tiếp theo là phần máy chủ, bao gồm Mã quốc gia di động (MCC) và Mã mạng di động (MNC), cả hai đều được bao gồm trong IMSI: ví dụ: danh tính người dùng riêng tư của Tobias có thể trơng giống như:
22330999999999@ims.mnc33.mcc222.3gppnetwork.org
Tên miền của mạng gia đình của Tobias cũng sẽ được lấy từ USIM và sẽ xuất hiện giống như phần miền của 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 của mình, thì bây giờ anh ấy sẽ gặp vấn đề là anh ấy sẽ được đăng ký nhưng không thể thực hiện bất kỳ hành động nào khác (ví dụ: gọi cho chị gái hoặc đăng ký dịch vụ), vì anh ấy đã đăng ký một danh tính mà anh ấy khơng được sử dụng thêm (danh tính bị cấm). Thiết bị đầu cuối của anh ta cần biết một danh tính đã được đăng ký ngầm. Bất cứ khi nào người dùng đã được xác thực và đăng ký thành cơng, S-CSCF, do đó, sẽ gửi phản hồi 200 (OK) cho yêu cầu REGISTER, P-Associated-URI header, tiêu đề này liệt kê tất cả các SIP URI và URL tel (tức là cơng khai danh tính người dùng), được liên kết nhưng không nhất thiết phải được đăng ký cho người dùng. Chỉ URI đầu tiên được liệt kê trong tiêu đề này ln là danh tính người dùng cơng khai hợp lệ, được đăng ký và có thể được sử dụng bởi UE và P-CSCF cho các hành động tiếp theo. P-Associated-URI trong phản hồi 200 (OK) đối với yêu cầu REGISTER của Tobias trông giống như sau:
SIP/2.0 200 OK
P-Associated-URI: <sip:tobias@home1.fr>, <sip:tobi@home1.fr>, <sip:gameMaster@home1.fr>,
<sip:+44123456789@home1.fr;user=phone>, <sip:+44123456111@home1.fr;user=phone>
Từ thơng tin này, Tobias biết rằng ít nhất danh tính người dùng cơng khai sip:
tobias@home1.fr đã được đăng ký. Anh ta cũng biết rằng có thêm hai SIP URI và hai URI điện thoại nữa mà anh ta có thể sử dụng, nhưng anh ta khơng biết liệu chúng hiện đã được đăng ký hay chưa.
Vì P-Associated-URI chỉ được xác định để vận chuyển các URI SIP, nó bao gồm các URL điện thoại được liên kết với Tobias (điện thoại: +44123456789 và điện thoại: +44123456111) ở định dạng URI SIP.
1.16.5 Chỉ định URI tác nhân người dùng có thể định tuyến tồn cầu
Cho đến nay, chúng tôi đã thấy hai loại danh tính, những danh tính có liên quan đến người dùng, ví dụ: danh tính người dùng cơng khai và sau đó là danh tính riêng tư, có liên quan đến thiết bị. Có những trường hợp mà điều quan trọng là không chỉ một người dùng cụ thể, mà cịn một thiết bị cụ thể có thể được giải quyết. Ví dụ cho trường hợp như vậy là ví dụ: khi người dùng muốn chuyển liên tục cuộc gọi đang diễn ra từ