Một phiên truyền dẫn ởđây được hiểu theo nghĩa của một giao dịch hoàn thiện tức là cả một quá trình từ khi UE bắt đầu tham gia tạo một phiên dịch vụ IMS (sau khi đã
được đăng ký, và trao quyền) đến khi kết thúc phiên dịch vụđó. Vì vậy quản lý phiên truyền dẫn sẽ liên quan đến cả quá trình tạo lập, nắm giữ và giải phóng phiên, nó gồm một loạt các vấn đề từ việc nhận dạng chủ gọi – bị gọi, định tuyến, chọn lựa mã truyền thông, điều khiển phương tiện truyền thông, tính cước, và giải phóng phiên. Để nắm
được thông suốt và cũng để gắn với thực tế, chúng ta sẽ trình bầy những điều này thông qua ví dụ về một phiên hoàn thiện được tạo lập giữa Tobias và Theresa (sau khi họđã đăng ký và được trao quyền - mục 2.2.1 đã đề cập), qua một loạt các bước:
• UE của Tobias tạo yêu cầu INVITE chứa nhận dạng public user (đã đăng ký ở
thủ tục đăng ký) của Theresa
• Tất cả các bản tin SIP cần phải đi qua P-CSCF và S-CSCF của cả hai user
• Tất cả các bản tin SIP được gửi qua IPsec ASs đã được thiết lập giữa UE và P- CSCF
Luận văn thạc sĩ kỹ thuật 82
• UE đồng ý dùng cùng một bộ mã hóa cho luồng truyền thông sẽđược truyền
• Các mạng sẽ trao quyền truyền thông cho phiên, vì thế các user có thể dự chữ
các tài nguyên liên quan
• Cả hai UE thực hiện Resource Reservation (nhưđã giới thiệu ở vấn đề QoS).
• Các thực thể mạng sẽ gửi thông tin tính cước đến hệ thống tính cước.
• UE của Theresa sẽ nhận được tín hiệu chuông, Theresa sẽ chấp nhận phiên, và phiên được thiết lập thành công.
Sau khi kết thúc cuộc gọi, UE của bên đặt máy trước (kết thúc trước) sẽ gửi yêu cầu BYE tới UE khia, và phiên sẽ kết thúc. Hình 2-45 là toàn bộ phiên này.
Luận văn thạc sĩ kỹ thuật 84
Hình 2-45: Phiên truyền dẫn 2.2.5.1 Các nhận dạng chủ gọi vài bị gọi
Sau khi đã được mạng nhận thực, đăng ký và trao quyền, UE sẽ có khả năng được tham gia dịch vụ. UE của Tobias sẽ gửi yêu cầu INVITE chứa nhận dạng public user của Tobias để đảm bảo cho mạng nhận dạng user và thực thi đúng các dịch vụ cho user. Nhận dạng này sẽ nằm ở mào đầu P-Asserted-Identity. Các nhận dạng public user của bị gọi cũng được chỉ định để mạng thực thi đúng các dịch vụ cho bị gọi, sẽ
nằm ở P-Asserted-Identity của phản hồi đầu tiên (trả lời yêu cầu INVITE).
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:theresa@sister.com> P-Preferred-Identity: <sip:tobias@home1.fr> Privacy: None
2.2.5.1.1 Sự nhận dạng user chủ gọi
UE chủ gọi gửi yêu cầu chứa mào đầu P-Preffered-Identity, có chứa thông tin nhận dạng public user đã được đăng ký. Đểẩn đi nhận dạng (của Tobias) thì cần đặt Privacy có giá trị “id”. Thực hiện điều này sẽ làm P-CSCF của Theresa xóa bỏ P-Preffered- Identity của Tobias trước khi gửi đến UE của Theresa, vì thế Theresa chỉ nhìn thấy nhận dạng của Tobisa ở mào đầu From.
P-CSCF phía chủ gọi sẽ nhận được yêu cầu INVITE, nó kiểm tra yêu cầu nhận được có qua IPsec SA hay không, nếu không thì P-CSCF sẽ từ chối yêu cầu. Sau đó P- CSCF sẽ chèn P-Assered-Identity ở INVITE thay cho P-Preffered-Identity.
Nếu P-Preffered-Identity chứa URI có là nhận dạng public user đã được đăng ký (bằng cách kiểm tra thông tin trạng thái đăng ký của user) đã được dùng từ trước hay không. Nếu đúng, P-CSCF sẽ thay nội dung của P-Perffered-Identity vào làm nội dung của P-Assered-Identity.
Nếu mào đầu P-Preffered-Identity không chứa nhận dạng public user đã đăng ký hiện thời (nhận dạng đã được đăng ký và vẫn đang dùng kể từ lần tham gia phiên trước đó) thì P-CSCF sẽ xóa mào đầu đó và chèn vào mào đầu P-Assered-Identity có chứa nhận dạng public user mặc định của user
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobias@brother.com> tag=veli P-Asserted-Identity: <sip:tobias@home1.fr>
Luận văn thạc sĩ kỹ thuật 85
Privacy: None
S-CCSF nhận được yêu cầu INVITE trên, nó sẽ thực hiện kiểm tra trạng thái đăng ký và trao quyền của các nhận dạng public user được chỉ ra ở mào đầu. S-CSCF có thể điền thêm thông tin cho mào đầu P-Asserted-Identity rồi tiếp túc gửi đi. Nếu S-CSCF và mạng của Theresa không cùng nằm trong một miền thì S-CSCF sẽ xóa mào đầu này nếu ở yêu cầu có Privacy là “id”.
INVITE sip:theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:Theresa@sister.com>
P-Asserted-Identity: <sip:tobias@home1.fr>, <tel:+44123456789> Privacy: None
P-CSCF của Theresa phải kiểm tra giá trị của mào đầu Privacy, nếu Privacy có giá trị
“id” thì nó sẽ xóa mào đầu này trước khi gửi bản tin đến UE của Theresa. Nếu UE của Theresa nhận được mào đầu này trong yêu cầu INVITE nó sẽ hiển thị tên thực của người gọi cho Theresa (tên thực của Tobias).
2.2.5.1.2 Sự nhận dạng của user bị gọi
Để ý đến yêu cầu INVITE, thấy request URI: INVITE sip: theresa@home2.hu SIP/2 .0. Dựa vào URI này, S-CSCF của Theresa sẽ kiểm tra sự tồn tại của nhận thực public user này có là nhận dạng hiện tại đã được đăng ký và trao quyền hay không. Nếu hiện tại Theresa không đăng ký bằng nhận dạng này, thì S-CSCF sẽ gửi lại phía chủ gọi bản tin 404 (Not Found) phản hồi cho yêu cầu INVITE và cuộc gọi sẽ bị hỏng. Lúc đó, tùy theo tiêu chuẩn lọc đối với user chưa đăng ký, bản tin INVITE sẽ được gửi forward
đến hộp thư thoại của Theresa.
S-CSCF của Theresa nhận được yêu cầu INVITE, nếu thỏa các điều kiện trên, nó sẽ
thay nhận dạng public user ở request URI cũ bởi địa chỉ liên lạc đã được đăng ký của Theresa, và để vẫn giữa được nhận dạng cũ, S-CSCF sẽ thêm vào mào đầu P-Called- Party-ID.
INVITE sip:[5555::5:6:7:8]:1006 SIP/2.0 P-Called-Party-ID: sip:Theresa@home2.hu
Sau khi nhận được yêu cầu INVITE, UE của Theresa sẽ gửi lại mào đầu P-Preffered- Identity (chứa nhận dạng public user của Theresa) ở phản hồi đầu tiên cho yêu cầu INVITE (gói 183 Session in Progress).
Luận văn thạc sĩ kỹ thuật 86
From: “Your Brother” <sip:tobi@brother.com>;tag=veli
To: “My beloved Sister” <sip:Theresa@sister.com>;tag=schwester P-Preferred-Identity: <sip:Theresa@home2.hu>
Privacy: None
Sau đó tiến trình thực hiện tương tụ như đã đề cập đối với hướng từ Tobias, nhưng theo chiều ngược lại.
2.2.5.2 Định tuyến
2.2.5.2.1 Phân biệt giữa phiên, dialog, các giao dịch và nhánh branch
Thuật ngữ “phiên” mô tả kết nối truyền thông giữa các user (ví dụ Tobias muốn gửi các luồng audio và video đến Theresa). Sự truyền thông này gọi là “bearer level”: các gói RTP được gửi từ hai UE đến GGSN và GGSN sẽ thực hiện truyền các gói này một cách trực tiếp qua mạng. Phiên ở đây được thiết lập dựa trên SIP và báo hiệu SDP (giao thức mô tả phiên) được truyền trên mặt bằng điều khiển “control plane”.
SIP dialog là báo hiệu giữa hai UE cần để thiết lập, điều chỉnh và giải phóng phiên đa phương tiện. Một dialog bắt đầu được thiết lập với yêu cầu INVITE và tồn tại đến hết kết thúc phiên bằng phản hồi 200 (OK) cho yêu cầu BYE. Mọi dialog đều được nhận dạng bằng giá trị chứa ở mào đầu Call-ID và các nhãn tag ở mào đầu To và From của các yêu cầu SIP
From: “Your Brother” <sip:tobi@brother.com>;tag=veli
To: “My beloved Sister” <sip:Theresa@home2.hu>;tag=schwester Call-ID:apb03a0s0s09dkjdfglkj49555
Một giao dịch SIP gồm một yêu cầu SIP và tất cả các phản hồi liên quan đến yêu cầu
đó. Ví dụ để thiết lập phiên, UE của Tobias gửi một yêu cầu INVITE đến UE của Theresa và sẽ nhận được phản hồi 100 (Trying) từ P-CSCF, phản hồi 183 (Session in Progress) và 180 (Ringing) và 200 (OK) từ UE của Theresa. Như vậy có năm bản tin cho giao dịch đó, và cả năm bản tin đêu thuộc một dialog và có cùng số Csep.
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister”
<sip:Theresa@home2.hu>;tag=schwester Call-ID:apb03a0s09dkfglkj49555
Luận văn thạc sĩ kỹ thuật 87
Mọi thực thể như UE và các CSCF dùng tham số Branch dùng để nhận dạng sự tương quan giữa các phản hồi và yêu cầu. Ví dụ P-CSCF sẽ thêm vào tham số này ở mào đầu Via để nhận dạng giao dịch INVITE ở P-CSCF:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb
2.2.5.2.2 Định tuyến yêu cầu INVITE
UE của Tobias sẽ chèn vào yêu cầu INVITE khởi tạo một số mào đầu liên quan đến
định tuyến:
INVITE sip :theresa@home2.hu SIP/2.0
Via : SIP/2.0/UDP [5555 ::1 :2 :3 :4] :1357 ;branch=8uetb Route : <sip :[5555 ::a :b :c :d] :7531 ;fr>
Route : <sop :orig@scscf1.home1.fr ;lr> Contact : <sip :[5555 ::1 :2 :3 :4] :1357>
Ta biết rằng ở quá trình đăng ký và nhận thực, UE sẽđặt địa chỉ của nó ở mào đầu Via
để nhận được tất cả các đáp ứng của giao dịch đó, UE đặt địa chỉ của nó ở mào đầu Contact để UE đằng xa có thể liên lạc với nhau.
Sau khi đã thiết lập được IPsec SAs, UE của Tobias sẽđặt địa chỉ port đã được bảo vệ
(1357) ở mào đầu Contact, đặt địa chỉ port đã được bảo vệ của nó tại mào đầu Via để
có thể nhận được tất cả các phản hồi qua port được bảo vệ đó. Địa chỉ của port được bảo vệ của P-CSCF (7531) được đặt ở mào đầu Route đầu tiên để P-CSCF có thể nhận
được tất cả các yêu cầu của UE qua cổng bảo kết hợp bảo mật đó. Các mào đầu To và From không được dùng cho mục đích định tuyến mà nó chỉ có mục đích nhận dạng. Khi nhận được yêu cầu, P-CSCF sẽ thực hiện: xóa mào đầu Route thứ nhất liên quan
đến địa chỉ của P-CSCF, kiểm tra xem thông tin định tuyến chứa ở trong yêu cầu có theo đúng như thông tin định tuyến P-CSCF đã lưu trữ trong quá trình đăng ký hay không, đặt thêm địa chỉ của nó ở mào đầu Via trên cùng (sẽ giúp nhận được các gói phản hồi), thêm vào mào đầu Record-Route và đặt địa chỉ của nó vào đó (giúp tất cả
các gói tin đều phải đi qua P-CSCF này), rồi gửi cho S-CSCF của Tobias:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Record-Route: <sip:pcscf1.visites1.fr;lr>
Luận văn thạc sĩ kỹ thuật 88
Route: <sio:org@scscf1.home1.fr.lr> Contact: <sip:[5555::1:2:3:4]:1357>
S-CSCF của Tobias nhận được yêu cầu đó, nó sẽ xóa mào đầu Route liên quan đến địa chỉ của chính S-CSCF đó và thực hiện các thủ tục (*). S-CSCF tiếp tục định tuyến yêu cầu INVITE sang I-CSCF của Theresa (S-CSCF của Tobias dựa vào DNS để tìm địa chỉ của I-CSCF). Nếu S-CSCF biết được khả năng định tuyến của I-CSCF thì nó sẽ
thêm địa chỉ của I-CSCF vào mào đầu Route và thực hiện gửi theo SIP, tuy nhiên vì S- CSCF của Tobias và I-CSCF của Theresa ở đây nằm ở hai mạng khác nhau nên S- CSCF sẽ không thực hiện được điều đó. S-CSCF của Tobias sẽ đóng gói UDP chứa yêu cầu INVITE đến I-CSCF.
I-CSCF mạng thường trú của Theresa cần tìm ra địa chỉ của S-CSCF sẽ phục vụ cho Theresa. Nếu Theresa chưa đăng ký, I-CSCF cần tìm ra địa chỉ của S-CSCF mặc định cho Theresa thuê bao dịch vụ như một user không đăng ký. Thông tin S-CSCF đã cấp cho user được lưu tại HSS, nếu có nhiều HSS thì I-CSCF cần truy vấn SLF để tìm ra HSS phù hợp chứa thông tin về S-CSCF cấp cho Theresa. Sau khi đã tìm ra địa chỉ S- CSCF, I-CSCF sẽ xóa địa chỉ của nó ở mào đầu Route và thêm vào yêu cầu INVITE
địa chỉ đó ở mào đầu Route trên cùng, và thêm vào địa chỉ của I-CSCF vào mào đầu Via trên cùng. Vì nhiệm vụ của I-CSCF chủ yếu để tìm S-CSCF do vậy những gói tin sau đó không cần thiết phải qua I-CSCF mà sẽ tới thẳng S-CSCF, do đó I-CSCF sẽ
không thêm địa chỉ của nó vào mào đầu Record-Route của yêu cầu INVITE này:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Route: <sip:scscf2.home2.hu;lr>
Record-Route: <sip:scscf1.home1.fr;lr> Record-Route: <sip:pcscf1.visited1.fi;lr> Contact: <sip:[5555::1:2:3:4]:1357>
S-CSCF của Theresa nhận được yêu cầu INVITE, nó sẽ xóa địa chỉ của nó tại mào đâu Route, thêm vào địa chỉ của nó ở mà đầu Via, và S-CSCF sẽ thực hiện thông tin với AS của Theresa tương tự các thủ tục (*). Bằng việc này, S-CSCF sẽ thay request URI bằng địa chỉ liên lạc đã đăng ký có cổng server bảo vệ là 1006 (cũng chính là port của UE Theresa), cùng với địa chỉ của P-CSCF (của Theresa) có được từ mào đầu Path của
Luận văn thạc sĩ kỹ thuật 89
yêu cầu REGISTER của Theresa. S-CSCF sẽ đặt địa chỉ của P-CSCF vào mào đầu Route:
INVITE sip:[5555::5:6:7:8]:1006 SIP/2.0
Via: SIP/2.0/UDP scscf2.home2.hu;branch=cscth Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Route: <sip:pcscf2.home2.hu;lr>
Record-Route: <sip:scscf2.home2.hu;lr> Record-Route: <sip:scscf1.home1.fr;lr> Record-Route: <sip:pcscf1.visited1.fi;lr> Contact: <sip:[5555::1:2:3:4]:1357>
P-CSCF của Theresa nhận được yêu cầu INVITE nó sẽ xóa tất cả mào đầu Route và thêm địa chỉ của nó vào mào đầu Record-Route và Via, đồng thời thêm địa chỉ port bảo vệ (1511) vào yêu cầu INVITE rồi gửi đến UE của Theresa.
Sau khi UE của Theresa nhận được yêu câu INVITE nó sẽ lưu lại giá trị của mào đầu Contact và danh sách mào đầu Record-Route để phục vụ cho việc định tuyến các bản tin tiếp sau.
INVITE sip:[5555::5:6:7:8]:1006 SIP/2.0
Via: SIP/2.0/UDP pcscf2.home2.hu:1511;branch=dpcth Via: SIP/2.0/UDP scscf2.home2.hu;branch=cscth Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Route: <sip:pcscf2.home2.hu:15511;lr>
Record-Route: <sip:scscf2.home2.hu;lr> Record-Route: <sip:scscf1.home1.fr;lr> Record-Route: <sip:pcscf1.visited1.fi;lr>
Luận văn thạc sĩ kỹ thuật 90
Contact: <sip[5555::1:2:3:4]:1357>
Khi S-CSCF nhận được yêu cầu INVITE khởi tạo, nó sẽ so sánh thông tin các tiêu chuẩn lọc. Nếu yêu cầu dịch vụ phù hợp với tiêu chuẩn nào đó, S-CSCF sẽ gửi yêu cầu đến AS của tiêu chuẩn ấy (tiêu chuẩn lọc được S-CSCF tải về từ HSS trong quá trình đăng ký và nhận thực, mã của tiêu chuẩn lọc có dạng XML và việc thực hiện tải về sẽ thông qua điểm tham chiếu Cx). Ở ví dụ này cho rằng có ba AS thuộc ba chuẩn bộ lọc:
Bảng 2-6: Tiêu chuẩn bộ lọc của S-CSCF của Tobias Element of filter
criteria
Filter criterion #1 Filter criterion #2 Filter criterion #3
SPT: session case
Originating Originating Terminating
SPT: public user identity Tel:+44-123-456- 789 sip: tobias@homel.fr tel:+44-123-456- 789 sip: tobias@homel.fr SPT: SIP method * INVITE SUBSCRIBE
Further SPT - - SIP header: event:
pres
Application server
sip:as1.homel.fr;lr sip:as2.homel.fr;lr sip:as3.homel.fr;lr
INVITE sip:Theresa@home2.hu SIP/2.0
Luận văn thạc sĩ kỹ thuật 91
Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Route: <sip:orig@scscf1.home1.fr;lr>
Form: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:Theresa@sister.com> P-Asserted-Identity: <sip:tobias@home1.fr>
Privacy: None
Như vậy so sánh ta thấy rằng yêu cầu INVITE sẽ hợp với tiêu chuẩn lọc số 2 vì: có chứa sip:tobias@hom1.fr, và yêu cầu là INVITE. Sau đó S-CSCF thông tin với AS:
Và S-CSCF nhận lại yêu cầu INVITE từ phía AS:
INVITE sip:Theresa@home2.hu SIP/2.0
Via: SIP/2.0/UDP sip:as2.home1.fr;bramch=vas2tb Via: SIP/2.0/UDP sip:scscf1.home1.fr;branch=9sc2as2tb Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Route: <sip:scscf1.home1.fr;lr>;dia-id=6574839201 Record-Route: <sip:as2.home1.fr;lr>
Luận văn thạc sĩ kỹ thuật 92
Record-Route: <sip:scscf1.home1.fr;lr> Record-Route: <sip:pcscf1.visited1.fi;lr>
2.2.5.2.3 Định tuyến gói phản hồi đầu tiên
UE của Theresa sau khi xử lý yêu cầu INVITE, nó gửi lại một phản hồi 183 (Session in Progress) có cấu trúc:
SIP/2.0 183 Session in Progress
Via: SIP/2.0/UDP pcscf2.home2.hu:1511;branch=dpcth Via: SIP/2.0/UDP scscf2.home2.hu;branch=cscth Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb Via: SIP/2.0/UDP pcscf1.visited1.fr;branch=9pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Record-Route: <sip:pcscf2.home2.hu:1511;lr> Record-Route: <sip:scscf2.home2.hu;lr> Record-Route: <sip:scscf1.home1.fr;lr> Record-Route: <sip:pcscf1.home1.fr;lr> Contact: <sip:[5555::5:6:7:8]:1006> Đáp ứng 183 đến P-CSCF của Theresa, P-CSCF sẽ thực hiện: xóa địa chỉ của nó tại mào đầu Via, ghi thêm địa chỉ của nó vào mào đầu Record-Route, Gửi gói tin đến thực