Khả năng nén các bản tin SIP qua giao diện không khí là điều cần thiết đối với IMS. Thế nào hoạt động của Nén tín hiệu (SigComp) được mô tả trong Phần 3.18 Phần này cho thấy cách UE và P-CSCF chỉ ra rằng họ hỗ trợ SigComp và cả hai đều sẵn sàng sử dụng nó. P-CSCF và IMS UE phải hỗ trợ SIP SigComp, nhưng chúng không bắt buộc để dùng nó. Do đó, họ cần một cơ chế để thể hiện liệu họ có sẵn sàng áp dụng
SigComp. [RFC3486] xác định tham số URI mới ‘comp’, có thể được đặt thành ‘comp = Sig Comp’ bởi UE hoặc proxy SIP (trong trường hợp IMS, điều này chỉ áp dụng cho P-CSCF) để bày tỏ sự sẵn sàng gửi hoặc nhận các thông điệp SIP nhất định bị nén. Tobias’s UE sẽ bày tỏ sự sẵn lòng sử dụng SigComp với P-CSCF đã trong yêu cầu REGISTER ban đầu. P-CSCF sẽ đưa ra một chỉ báo tương tự trong 401 Phản hồi (trái phép). Khi hai bản tin SIP này được gửi đi mà không có bất kỳ biện pháp bảo vệ nào, P-CSCF và UE sẽ không tạo trạng thái (ngăn) cho SigComp tại thời điểm này trong thời gian; điều này là để đảm bảo rằng người dùng độc hại - người muốn bắt đầu từ chối dịch vụ (DOS) tấn công chống lại P-CSCF - không thể làm quá tải P-CSCF bằng cách buộc nó phải dự trữ bộ nhớ cho một số lượng lớn các ngăn SigComp không cần thiết. Việc tạo trạng thái sẽ chỉ được thực hiện sau một IPsec SA (xem Phần 1.10) giữa UE và P-CSCF đã được thành lập.
1.11.2 Thể hiện sự sẵn sàng sử dụng SigComp Tham số 'comp' có thể được đặt:
• bởi UE trong tiêu đề Liên hệ của yêu cầu REGISTER - điều này có nghĩa là UE sẵn sàng nhận mọi yêu cầu ban đầu dành cho nó được nén lại, như các yêu cầu ban đầu được gửi đến UE được định tuyến dựa trên địa chỉ liên hệ đã đăng ký địa chỉ
• bởi UE trong tiêu đề Liên hệ của bất kỳ yêu cầu ban đầu nào khác hoặc phản hồi đầu tiên cho một yêu cầu ban đầu - điều này có nghĩa là UE sẵn sàng nhận mọi yêu cầu tiếp theo trong hộp thoại này được nén, vì các yêu cầu tiếp theo được định tuyến dựa trên địa chỉ trong tiêu đề Liên hệ của yêu cầu ban đầu (từ đầu cuối) hoặc phản hồi đầu tiên đến một yêu cầu ban đầu (từ cuối kết thúc);
• bởi UE trong tiêu đề Via của bất kỳ yêu cầu nào - điều này có nghĩa là UE sẵn sàng nhận tất cả các phản hồi cho yêu cầu này được nén, vì các phản hồi được định tuyến dựa trên qua tiêu đề trong yêu cầu liên quan;
• bởi P-CSCF trong mục nhập của chính nó vào tiêu đề Tuyến đường Bản ghi được gửi
đến UE - điều này có nghĩa là P-CSCF sẵn sàng nhận các yêu cầu tiếp theo trong hộp thoại được nén, vì các yêu cầu tiếp theo được chuyển đến proxy SIP dựa trên các mục nhập trong tiêu đề Tuyến đường (được tạo từ tiêu đề Bản ghi-Tuyến đường)
• bởi P-CSCF trong tiêu đề Qua của bất kỳ yêu cầu nào - điều này có nghĩa là P-CSCF sẵn sàng để nhận tất cả các phản hồi cho yêu cầu này được nén, vì các phản hồi được định tuyến dựa trên tiêu đề Via trong yêu cầu liên quan.
1.11.3 comp = Tham số SigComp trong khi đăng ký
Yêu cầu REGISTER ban đầu của UE sẽ bao gồm các yêu cầu liên quan đến nén sau thông tin:
REGISTER sip:home1.fr SIP/2.0
Via: SIP/2.0/UDP sip:[5555::1:2:3:4]:1357;comp=SigComp ;branch=0uetb Route: sip:[5555:: a:b: c:d];lr
Contact: "Mobile Phone - Tobias"
<sip:[5555::1:2:3:4]: 1357; comp=SigComp > ;expires=600000
Tham số comp = SigComp được bao gồm trong tiêu đề Via và chỉ ra rằng UE sẵn sàng nhận tất cả các phản hồi cho yêu cầu này được nén. Do đó, P-CSCF có thể gửi phản hồi 401 (Trái phép) đã được nén, nhưng nó sẽ không tạo ra trạng thái (tức là một ngăn) vì điều này.
Tham số comp = SigComp cũng có thể được tìm thấy trong tiêu đề Liên hệ. Tham số ter này sẽ được đưa vào mọi yêu cầu ban đầu mà UE nhận được, như S-CSCF sẽthay thế URI yêu cầu (trỏ đến sip: tobias@home1.fr) của mọi yêu cầu ban đầu với địa chỉ liên hệ đã đăng ký (tức là sip: [5555 :: 1: 2: 3: 4]: 1357; comp = SigComp) Phản hồi 401 (Trái phép) từ P-CSCF không bao gồm bất kỳ thông tin nào khác về khả năng thực hiện SigComp của P-CSCF. Địa chỉ P-CSCF là được phát hiện trước khi đăng ký ban đầu (xem Phần 11.4) không thể được phát hiện với tham số comp = SigComp. Vì tin nhắn SIP chỉ nên được nén khi Tham số comp = SigComp được đặt trong địa chỉ của bước tiếp theo, do đó UE sẽ không gửi bất kỳ yêu cầu ban đầu nào đến P-CSCF đã nén.
Các yêu cầu tiếp theo (chẳng hạn như ACK, PRACK, UPDATE hoặc BYE) có thể được nhấn com, vì định tuyến từ UE đến P-CSCF sẽ dựa trên Record-Route mục nhập của P-CSCF (xem Phần 12.3.3.2), trong đó P-CSCF có thể bao gồm = Tham số
SigComp. Điều này cũng đúng đối với các phản hồi được gửi từ UE tới P-CSCF, vì chúng được định tuyến dựa trên mục nhập tiêu đề Via của P-CSCF, cũng được đặt bởi P-CSCF chính nó. Mặc dù nó là điều kiện cần để tham số comp cho biết liệu nén có đã sử dụng, 3GPP TS 24.229 không đưa ra yêu cầu rõ ràng về việc nén bản gốc thông điệp. Một khả năng là UE chỉ gửi mọi yêu cầu ban đầu được nén, vì P-CSCF phải hỗ trợ Sigcomp trong mọi trường hợp. Do đó, UE thêm tham số comp = SigComp vào địa
chỉ P-CSCF mà đã được phát hiện trước đây. Do đó, nó có thể gửi yêu cầu REGISTER
thứ hai đã được nén:
REGISTER sip:home1.fr SIP/2.0
Via: SIP/2.0/UDP sip:[5555:1:2:3:4]:1357;comp=SigComp;branch=1uetb Route: sip:[5555:a:b:c:d]:7531;lr;comp=SigComp
Contact: "Mobile Phone - Tobias"
<sip:[5555:1:2:3:4]:1357;comp=SigComp>; expires=600000
Yêu cầu REGISTER này được định tuyến dựa trên tiêu đề Tuyến đường trên cùng, bao gồm địa chỉ P-CSCF và tham số comp = SigComp. Như tham số là đã có, UE có thể gửi yêu cầu đã được nén. Phản hồi 200 (OK) cho yêu cầu REGISTER này sẽ được gửi từ P-CSCF tới UE trên cơ sở tiêu đề Via, và vì UE cũng bao gồm comp = SigComp , P-CSCF sẽ gửi nó được nén.
1.11.4 comp = Tham số SigComp trong các yêu cầu khác
Việc xử lý tham số comp = SigComp trong các yêu cầu không phải là REGISTER là được mô tả trong Phần 12.4.
1.11.5 Các tiêu chuẩn liên quan
Tham số comp được xác định trong [RFC3486]: Nén phiên khởi đầu Giao thức (SIP).
1.12 Tiêu đề tuyến dịch vụ
Chúng tôi thấy rằng cả UE và P-CSCF đều không biết địa chỉ của S-CSCF trong quá trình đăng ký; do đó, phải liên hệ với I-CSCF để phát hiện ra địa chỉ S-CSCF từ HSS. Để tránh I-CSCF như một bước nhảy bổ sung cho mọi thư ban đầu được gửi từ UE, S- CSCF sẽ trả về địa chỉ của nó trong tiêu đề Tuyến dịch vụ trong phản hồi 200 (OK) cho yêu cầu REGISTER:
SIP/2.0 200 OK
Service-Route: sip:orig@,scscf1 .home1.fr;lr
UE, khi nhận được phản hồi 200 (OK), sẽ lưu trữ các mục nhập trong tiêu đề ServiceRoute. Bất cứ khi nào UE gửi bất kỳ yêu cầu ban đầu nào ngoài thông báo REGISTER, nó sẽ:
• bao gồm các địa chỉ đã nhận được trong tiêu đề Tuyến dịch vụ trong tiêu đề Tuyến của yêu cầu ban đầu; và
• bao gồm địa chỉ P-CSCF làm mục nhập Tuyến trên cùng trong yêu cầu ban đầu. Ví dụ về cách các yêu cầu ban đầu được định tuyến được đưa ra trong Phần 1.16.6 cho một yêu cầu SUBSCRIBE và trong Phần 0 cho một yêu cầu INVITE. S-CSCF trong ví dụ này đặt một phần người dùng (‘orig’) trong mục nhập Tuyến dịch vụ vì nó cần phân biệt giữa hai loại yêu cầu:
• các yêu cầu bắt nguồn từ người dùng được phục vụ (tức là Tobias); và • yêu cầu dành cho UE của Tobias
Bất cứ khi nào S-CSCF nhận được yêu cầu ban đầu (ví dụ: yêu cầu INVITE), S-CSCF cần xác định xem yêu cầu này được bắt nguồn từ hay được chuyển đến người dùng được phục vụ. Mục nhập phần người dùng trong tiêu đề Route giúp S-CSCF dễ dàng phát hiện xem một yêu cầu đã nhận có phải bắt nguồn từ người dùng được phục vụ hay không, vì UE của Tobias sẽ bao gồm mục nhập Tuyến dịch vụ của S-CSCF làm mục nhập Tuyến trong tất cả các yêu cầu nó bắt nguồn
1.13 Tiêu đề đường dẫn
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ủ