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