Cơ chế SDP offer/answer cho phép hai UE thống nhất dùng tập các phương tiện truyền thông cho phiên và thống nhất dùng các mã hóa tương ứng được sử dụng cho mỗi loại phiên khác nhau. Quá trình dàn xếp truyền thông thực hiện qua mấy bước:
• UE chủ gọi gửi SDP offer đầu tiên trong yêu cầu INVITE. SDP này chứa danh sách tất cả các loại phương tiện truyền thông (như audio, video, các ứng dụng nào đó như chat hoặc whiteboard) mà chủ gọi muốn dùng cho phiên này, SDP còn chứa danh sách các mã hóa khác nhau mà UE chủ gọi hỗ trợ cho việc mã hóa những phương tiện truyền thông khác nhau này.
Luận văn thạc sĩ kỹ thuật 96
• UE bị gọi sẽ phản hồi bằng SDP answer đầu tiên, ởđó nó có thể từ chối một số
loại phương tiện truyền thông vừa được đề xuất ở SDP offer. UE đó cũng có thể bỏđi những mã mà nó không hỗ trợ.
• Sau khi nhận được SDP trả lời đầu tiên, UE chủ gọi cần quyết định sẽ dùng mã hóa nào. Nó sẽ gửi một đề xuất thứ hai đến UE bị gọi, sẽ chỉ ra mã nào sẽđược dùng cho loại truyền thông tương ứng sẽ dùng trong phiên.
• UE bị gọi sẽ chấp nhận đề xuất thứ hai và gửi lại UE chủ gọi một xác nhận. (hình 2-47).
Hình 2-47: SDP offer/answer trong IMS
SIP cho phép thiết lập phương tiện truyền thông sau khi offer/anser exchange đầu tiên (ở SDP answer có nhiều mã như ví dụ trên thì sự thiết lập phương tiện sẽ thực hiện ở
exchange thứ hai tức là sự chuyển thứ hai).
INVITE sip:Theresa@home2.hu SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister” <sip:Theresa@home2.hu> Supported: 100rel
CSeq: 1112 INVIE
Call-ID: apb03a0s09dkjdkj49555
Luận văn thạc sĩ kỹ thuật 97
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister”
<sip:Theresa@home2.hu>;tag=schwester Require: 100rel
RSeq: 1971
CSeq: 1112 INVITE
Call-ID: apb03a0s09dkjfglkj49555
Giá trị 100rel thông báo rằng có dùng cơ chế phản hồi tạm thời (chính là việc dùng phản hồi 183 ở trên). CSeq: 1112 INVITE cho thấy 183 phản hồi cho yêu cầu INVITE.
PRACK <sip:[5555::5:6:7:8]:1006 SIP/2.0
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister”
<sip:Theresa@home2.hu>;tag=schwester Rack: 1971 1112 INVITE
CSeq: 1113 PRACK
Call-ID: apb03a0s09dkjdfglkj49555
SIP/2.0 200 OK
From: “Your Brother” <sip:tobi@brother.com>;tag=veli To: “My beloved Sister”
<sip:Theresa@home2.hu>;tag=schwester CSeq: 1113 PRACK
Call-ID: apb03a0s09dkjdfhlk49555
Cơ chế SDP offer/answer cho phép các UE thống nhất dùng các phương tiện truyền thông và các loại mã hóa tương ứng trong phiên. Ở ví dụ này chúng ta cho rằng Tobias muốn thực hiện phiên với các loại phương tiện: luồng audio (để thoại), luồng video
Luận văn thạc sĩ kỹ thuật 98
thứ nhất (cho phép gửi ảnh của hai người), và luồng video thứ hai (dùng để gửi ảnh của gia đình). Dạng của thân SDP sẽ như:
v=0
o=- 2987933615 2987933615 IN IP6 IN IP6 5555::1:2:3:4 s=- c=IN IP6 5555::1:2:3:4 t=907165275 0 m=audio 3458 RTP/AVP 0 96 97 98 a=rtpmap:0 PCMU a=rtpmap:0 PCMU a=rtpmap:96 G726-32/8000 a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event m=video 3400 RTP/AVP 98 99 a=rtpmap:98 MPV a=rtpmap:99 H.261 m=video 3456 RTP/AVP 98 99 a=sendonly a=rtpmap:98 H.261 a=rtpmap:99 MPV Dòng v chỉ ra phiên bản giao thức
Dòng o chỉ ra các thông tin về Tobias (tên, nhận dạng phiên của Tobias, phiên bản phiên, và địa chỉ IPv6 của UE Tobias).
Dòng s chi ra chủđề của phiên.
Dòng c chỉ ra địa chỉ dùng cho các luồng truyền thông thực chứ không phải cho báo hiệu.
Dòng t chỉ ra thời điểm tạo phiên và thời gian phiên dược quan tâm. Ởđây đặt bằng 0 vì không có thời gian giới hạn cho phiên, phiên sẽ kết thúc khi có yêu cầu BYE. Thời
điểm bắt đầu phiên là giá trị 64 bit được tính bằng giây kể từ mốc là 00:00 ngày 1 tháng 1 năm 1900.
Luận văn thạc sĩ kỹ thuật 99
Dòng m chỉ ra luồng phương tiện truyền thông mà Tobias muốn dùng. Ví dụ m=audio 3458 RTP/AVP 0 96 97 98 chỉ ra Tobias sẽ dùng luồng audio gửi ra tại port 3458, Real Time Protocol/Audio Video Profile, và các luật mã hóa thoại theo định dạng (0, 96, 97, 98).
Dòng a chỉ ra định dạng của luồng truyền thông tương ứng. Có 35 định dạng hay luật mã thiết lập cho RTP/AVP, có đánh số từ 0 đến 34 [RFC3551] khi phân công tĩnh, khi phân công động cùng các mã mới thì được đánh số từ 96 đến 127.
Sau khi SDP offer của UE Tobias đến UE của Theresa, UE There sẽ phản hồi bằng SDP answer có dạng: v=0 o=- 1357924 1357924 IN IP6 5555::5:6:7:8 s=- c=IN IP6 5555::5:6:7:8 t=907165275 0 m=audio 4011 RTP/AVP 96 97 98 a=rtpmap:96 G726-32/8000 a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event m=video 4012 RTP/AVP 99 a=rtpmap:99 H.261 m=video 0 RTP/AVP 98
Chú ý dòng m=video 0 RTP/AVP 98 chỉ ra không thể cấp luồng video thứ hai cho UE Theresa vì không có port nhận luồng đó (ởđây do PDP phản hồi phải lặp lại các dòng m có ở PDP offer nên dòng đó không được xóa đi).
Nhận được SDP answer của UE Theresa, UE Tobias sẽ hợp lý hóa và đưa ra quyết
định trong việc dùng các luồng truyền thông với các mã hóa tương ứng. Sau đó UE Tobias sẽ gửi SDP offer thứ hai tới UE Theresa (trong yêu cầu PRACK):
v=0
o=- 1357924 1357924 IN IP6 5555::1:2:3:4 s=-
Luận văn thạc sĩ kỹ thuật 100 t=907165275 0 m=audio 3458 RTP/AVP 97 98 a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event m=video 3400 RTP/AVP 99 a=rtpmap:99 H.261 m=video 0 RTP/AVP 98
Sau Khi UE Theresa nhận được SDP offer thứ hai này, nó xác định được cả hai đã ứng thuận dùng các luồng truyền thông và mã phù hợp tưng ứng, và phản hồi UE Tobias một SDP answer có nội dung giống SDP offer thứ hai trên (tất nhiên mào đầu SDP answer thứ hai này sẽ giống SDP answer đầu tiên).