Việc sử dụng SDP với SIP được đưa ra trong câu trả lời đề nghị SDP RFC 3264. Loại nội dung thông báo mặc định trong SIP là ứng dụng / sdp .
- Bên gọi liệt kê các khả năng phương tiện mà họ sẵn sàng nhận được trong SDP, thường là trong INVITE hoặc trong ACK.
- Bên được gọi liệt kê các khả năng truyền thông của họ trong phản hồi 200 OK cho INVITE.
Việc sử dụng SIP thông thường của SDP bao gồm các trường sau: phiên bản, nguồn gốc, chủ đề, thời gian, kết nối và một hoặc nhiều phương tiện và thuộc tính.
- Các trường chủ đề và thời gian không được SIP sử dụng nhưng được đưa vào để tương thích.
- Trong tiêu chuẩn SDP, trường chủ đề là trường bắt buộc và phải chứa ít nhất một ký tự, được đề xuất là s = - nếu không có chủ đề.
- Trường thời gian thường được đặt thành t = 00. SIP sử dụng trường kết nối, phương tiện và thuộc tính để thiết lập phiên giữa các UA.
- Trường gốc được sử dụng hạn chế với SIP.
- Id phiên thường được giữ không đổi trong suốt phiên SIP.
- Phiên bản được tăng lên mỗi khi SDP được thay đổi. Nếu SDP được gửi không thay đổi so với đã gửi trước đó, thì phiên bản sẽ được giữ nguyên.
- Vì loại phiên phương tiện và codec được sử dụng là một phần của thương lượng kết nối, SIP có thể sử dụng SDP để chỉ định nhiều loại phương tiện thay thế và chấp nhận hoặc từ chối có chọn lọc các loại phương tiện đó.
Đặc tả phiếu mua hàng / câu trả lời, RFC 3264, khuyến nghị rằng một thuộc tính có chứa a = rtpmap: được sử dụng cho mỗi trường phương tiện. Luồng phương tiện bị từ chối bằng cách đặt số cổng thành 0 cho trường phương tiện tương ứng trong phản hồi SDP.
Thí dụ
Trong ví dụ sau, người gọi Tesla muốn thiết lập một cuộc gọi âm thanh và video với hai codec âm thanh có thể có và một codec video trong SDP có trong INVITE ban đầu –
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000
Các codec được tham chiếu bởi hồ sơ RTP / AVP số 97, 98.
Bên được gọi Marry trả lời cuộc gọi, chọn codec thứ hai cho trường phương tiện đầu tiên và từ chối trường phương tiện thứ hai, chỉ muốn phiên AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32
Nếu cuộc gọi chỉ có âm thanh này không được chấp nhận, thì Tom sẽ gửi ACK sau đó là BYE để hủy cuộc gọi. Nếu không, phiên âm thanh sẽ được thiết lập và các gói RTP được trao đổi.
Như ví dụ này minh họa, trừ khi số lượng và thứ tự của các trường phương tiện được duy trì, bên gọi sẽ không biết chắc chắn phiên phương tiện nào đang được bên được gọi chấp nhận và từ chối.
Các quy tắc chào hàng / câu trả lời được tóm tắt trong các phần sau.
Quy tắc tạo phiếu mua hàng
Phiếu mua hàng SDP phải bao gồm tất cả các trường SDP bắt buộc (bao gồm v =, o =, s =, c = và t =). Đây là những trường bắt buộc trong SDP.
Nó thường bao gồm một trường media ( m = ) nhưng nó không nhất thiết phải như vậy. Các dòng phương tiện chứa tất cả các codec được liệt kê theo thứ tự ưu tiên. Ngoại lệ duy nhất cho điều này là nếu điểm cuối hỗ trợ một số lượng lớn codec, thì mã có khả năng được chấp nhận cao nhất hoặc được ưu tiên nhất sẽ được liệt kê. Các loại phương tiện khác nhau bao gồm âm thanh, video, văn bản, MSRP, BFCP, v.v.
Quy tắc tạo câu trả lời
Câu trả lời SDP cho một phiếu mua hàng phải được xây dựng theo các quy tắc sau:
- Câu trả lời phải có cùng số dòng m = theo thứ tự như câu trả lời.
- Các luồng phương tiện riêng lẻ có thể bị từ chối bằng cách đặt số cổng thành 0.
- Các luồng được chấp nhận bằng cách gửi một số cổng khác không.
- Các trọng tải được liệt kê cho mỗi loại phương tiện phải là một tập hợp con của các trọng tải được liệt kê trong phiếu mua hàng.
- Đối với tải trọng động, không cần sử dụng cùng một số trọng tải động cho mỗi hướng. Thông thường, chỉ một trọng tải duy nhất được chọn.
Quy tắc sửa đổi phiên
Một trong hai bên có thể bắt đầu trao đổi phiếu mua hàng / câu trả lời khác để sửa đổi phiên. Khi một phiên được sửa đổi, các quy tắc sau phải được tuân theo:
- Số phiên bản dòng gốc ( o = ) phải giống với số cuối cùng được gửi, cho biết rằng SDP này giống với trao đổi trước đó hoặc nó có thể tăng lên một, cho biết SDP mới phải được phân tích cú pháp.
- Phiếu mua hàng phải bao gồm tất cả các dòng phương tiện hiện có và chúng phải được gửi theo cùng một thứ tự.
- Các luồng phương tiện bổ sung có thể được thêm vào cuối danh sách dòng m = .
- Một luồng phương tiện hiện có có thể bị xóa bằng cách đặt số cổng thành 0. Dòng phương tiện này phải vẫn còn trong SDP và tất cả các trao đổi đề nghị / trả lời trong tương lai cho phiên này.
Giữ máy
Một bên trong cuộc gọi có thể tạm thời đặt bên kia ở trạng thái chờ. Điều này được thực hiện bằng cách gửi một INVITE có SDP giống hệt với INVITE ban đầu nhưng có thuộc tính = sendonly .
Cuộc gọi được kích hoạt trở lại bằng cách gửi một INVITE khác có thuộc tính a = sendrecv . Hình minh họa sau đây cho thấy luồng cuộc gọi của một cuộc gọi.
SIP – Tính di động
Tính di động cá nhân là khả năng có một số nhận dạng liên tục trên một số thiết bị. SIP hỗ trợ tính di động cá nhân cơ bản bằng cách sử dụng phương thức ĐĂNG KÝ, cho phép thiết bị di động thay đổi địa chỉ IP và điểm kết nối với Internet mà vẫn có thể nhận cuộc gọi đến.
SIP cũng có thể hỗ trợ tính di động của dịch vụ – khả năng người dùng giữ các dịch vụ giống nhau khi di động
SIP Mobility trong khi bàn giao (Gọi trước)
Một thiết bị liên kết URI liên hệ của nó với địa chỉ của bản ghi bằng một đăng ký đơn giản. Theo địa chỉ IP của thiết bị, việc đăng ký cho phép thông tin này tự động cập nhật trong mạng nhâm nhi.
Trong quá trình chuyển giao, tác nhân Người dùng định tuyến giữa các nhà khai thác khác nhau, nơi nó phải đăng ký lại với một Liên hệ làm AOR với nhà cung cấp dịch vụ khác.
Ví dụ, chúng ta hãy lấy ví dụ về luồng cuộc gọi sau đây. UA đã tạm thời nhận được SIP URI mới với nhà cung cấp dịch vụ mới. UA sau đó thực hiện đăng ký kép –
- Lần đăng ký đầu tiên là với nhà khai thác dịch vụ mới, liên kết URI liên hệ của thiết bị với AOR URI của nhà cung cấp dịch vụ mới.
- Yêu cầu ĐĂNG KÝ thứ hai được chuyển trở lại nhà cung cấp dịch vụ ban đầu và cung cấp AOR của nhà cung cấp dịch vụ mới dưới dạng URI Liên hệ.
Như được trình bày sau trong luồng cuộc gọi, khi có yêu cầu đến mạng của nhà cung cấp dịch vụ ban đầu, INVITE sẽ được chuyển hướng đến nhà cung cấp dịch vụ mới, sau đó sẽ định tuyến cuộc gọi đến người dùng.
Đối với lần đăng ký đầu tiên, thông báo chứa URI thiết bị sẽ là:
REGISTER sip:visited.registrar1.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca
Max-Forwards: 70
To: Tom <sip:1@registrar1.in>
From: Tom <sip:1@registrar1.in>;tag = 72d65a24
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102
CSeq: 1 REGISTER
Contact: <sip:A@172.22.1.102:5060>
Expires: 600000
Content-Length: 0
Thông báo đăng ký thứ hai với URI chuyển vùng sẽ là –
REGISTER sip:home.registrar2.in SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u
Max-Forwards: 70
To: Tom <sip:1@registrar2.in>
From: Tom <sip:1@registrar2.in>;tag = 45375
Call-ID:87nr43i@172.22.1.102
CSeq: 6421 REGISTER
Contact: <sip:1@registrar2.in>
Content-Length: 0 Tính di động trong khi gọi (mời lại) Tác nhân Người dùng có thể thay đổi địa chỉ IP của nó trong phiên khi nó hoán đổi từ mạng này sang mạng khác. Basic SIP hỗ trợ tình huống này, vì có thể sử dụng lại MỜI trong hộp thoại để cập nhật URI Liên hệ và thay đổi thông tin phương tiện trong SDP. Hãy xem luồng cuộc gọi được đề cập trong hình bên dưới. •Tại đây, Tom phát hiện một mạng mới, •Sử dụng DHCP để lấy địa chỉ IP mới và •Thực hiện MỜI lại để cho phép luồng báo hiệu và phương tiện đến địa chỉ IP mới. Nếu UA có thể nhận phương tiện từ cả hai mạng, thì sự gián đoạn là không đáng kể. Nếu không đúng như vậy, một vài gói phương tiện có thể bị mất, dẫn đến cuộc gọi bị gián đoạn đôi chút.
MỜI lại sẽ xuất hiện như sau:
INVITE sip:Jerry@TTP.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a
Max-Forwards: 70
To: <sip:y@TTP.com>
From: sip:A@PPT.com;tag = 70133df4
Call-ID: 76d4861c19c
CSeq: 1 INVITE
Accept: application/sdp
Accept-Language: en
Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE
Contact: <sip:172.22.1.102:5060>;
Content-Type: application/sdp
Content-Length: 168
v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1
s = -
c = IN IP4 192.168.2.1
b = AS:49
t = 0 0
b = RR:0
b = RS:0
a = rtpmap:97 AMR/8000/1
m = audio 6000 RTP/AVP 96
a = fmtp:102 0-15
a = ptime:20
a = maxptime:240
INVITE lại chứa địa chỉ IP mới của Bowditch trong các trường tiêu đề Qua và Liên hệ và thông tin phương tiện SDP.
Tính di động trong Midcall (Với Header thay thế)
Trong tính di động giữa cuộc gọi, tập định tuyến thực tế (tập hợp các proxy SIP mà các bản tin SIP phải đi qua) phải thay đổi. Chúng tôi không thể sử dụng MỜI lại trong tính di động giữa cuộc gọi
Ví dụ: nếu cần proxy cho truyền NAT, thì URI liên hệ phải được thay đổi – một hộp thoại mới phải được tạo. Do đó, nó phải gửi một INVITE mới với tiêu đề Thay thế, xác định phiên hiện có.
Lưu ý – Giả sử cả A và B đều đang trong một cuộc gọi và nếu A nhận được một INVITE khác (giả sử từ C) với tiêu đề thay thế (phải khớp với hộp thoại hiện có), thì A phải chấp nhận INVITE và kết thúc phiên với B và chuyển tất cả tài nguyên đến hộp thoại mới được hình thành. Luồng cuộc gọi được hiển thị trong Hình sau. Nó tương tự như luồng cuộc gọi trước đó bằng cách sử dụng lại INVITE ngoại trừ một BYE được tạo tự động để kết thúc hộp thoại hiện có khi INVITE với Thay thế được chấp nhận
Dưới đây là những điểm cần lưu ý trong trường hợp này –
- Hộp thoại hiện có giữa Tom và Jerry bao gồm máy chủ proxy cũ đã truy cập.
- Hộp thoại mới sử dụng mạng không dây mới yêu cầu bao gồm máy chủ proxy mới đã truy cập.
- Do đó, Tom gửi một MỜI với Thay thế, hộp thoại này tạo ra một hộp thoại mới bao gồm máy chủ proxy đã truy cập mới nhưng không phải máy chủ proxy đã truy cập cũ.
- Khi Jerry chấp nhận INVITE, một BYE sẽ tự động được gửi để chấm dứt hộp thoại cũ định tuyến qua máy chủ proxy đã truy cập cũ hiện không còn tham gia vào phiên.
- Phiên truyền thông kết quả được thiết lập bằng địa chỉ IP mới của Tom từ SDP trong INVITE.
Dịch vụ di động
Các dịch vụ trong SIP có thể được cung cấp trong proxy hoặc UA. Việc cung cấp tính di động của dịch vụ cùng với tính di động của cá nhân có thể là một thách thức trừ khi thiết bị của người dùng được định cấu hình giống hệt nhau với cùng các dịch vụ.
SIP có thể dễ dàng hỗ trợ tính di động của dịch vụ qua Internet. Khi được kết nối với Internet, một UA được định cấu hình để sử dụng một tập hợp các proxy ở Ấn Độ vẫn có thể sử dụng các proxy đó khi chuyển vùng ở Châu Âu. Nó không có bất kỳ tác động nào đến chất lượng của phiên phương tiện vì phương tiện luôn truyền trực tiếp giữa hai UA và không truyền qua máy chủ proxy SIP. Các dịch vụ thường trú của điểm cuối chỉ khả dụng khi điểm cuối được kết nối với Internet. Một dịch vụ kết thúc chẳng hạn như dịch vụ chuyển tiếp cuộc gọi được triển khai trong một điểm cuối sẽ bị lỗi nếu điểm cuối tạm thời mất kết nối Internet. Do đó, một số dịch vụ được triển khai trong mạng bằng máy chủ proxy SIP.