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ệ toà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.visited1fi;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ẽ yê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:
REGISTER siprhomel.fr SIP/2.0
Vỉa: SIP/2.O/UDP sỉp; icscfl.homel.fr ;braacbF3ictỉ>
Via.: SIP/2.0/UDP sip:pcscf1.visitedl.fi;branch=2pctb Via: SIP/2.0/ƯDP [5555::a:b:c:d];branch =luetb
Raute: sip:scscf1.homel.fr;Ir
Max~Forwards: 68
From: <sip: tDOias@horr.el. fr> ; tag=ulkomaa To: <sip : tobiasộhomel. f r>
Contact: "Mobile Phone - Tobias"
<sip: [5555: :1:2:3:4] :13 57>;expires=6ũũ00ũ
Call-ID: apb03aũs09dkjdfglkj49111
CSeq: 47 REGISTER
Content-Length: ũ
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 quá 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
• 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ó toà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
• Rcgístr
ation sct • SÍP UR[ • tel URL and rclatcd SÍP UR1 (Alias)
• 1 •rfr iÌỊKlvbia ỏ' @ ho me ỉ • tel;1 44123456789 sip;-\
44123456789<àhom£ ỉ.fr • 2 • sip:tobi@ home Ị .fr • teỉ: +44ỉ234561 ỉ ỉ sỉp: +441234561 ỈỊ@homel.fr • 3 • $ip:gamtĩMa.ĩter& home ỉ -fr • •
• 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="tobiasprivate@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 luôn 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 ngoà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 ngoà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 luôn 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
• 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