SIP - Hướng dẫn nhanh

Giao thức Khởi tạo Phiên (SIP) là một trong những giao thức phổ biến nhất được sử dụng trong công nghệ VoIP. Nó là một giao thức lớp ứng dụng hoạt động kết hợp với các giao thức lớp ứng dụng khác để điều khiển các phiên truyền thông đa phương tiện qua Internet.

Công nghệ VoIP

Trước khi đi sâu hơn, trước tiên chúng ta hãy hiểu một vài điểm về VoIP.

• VOIP là công nghệ cho phép bạn truyền tải nội dung thoại và đa phương tiện (video, hình ảnh) qua Internet. Đó là một trong những cách rẻ nhất để giao tiếp mọi lúc, mọi nơi với sự sẵn có của Internet.

• Một số ưu điểm của VOIP bao gồm:

  • Giá thấp

  • Portability

  • Không có thêm cáp

  • Flexibility

  • Hội nghị truyền hình

• Đối với cuộc gọi VOIP, tất cả những gì bạn cần là một máy tính / máy tính xách tay / điện thoại di động có kết nối internet. Hình sau mô tả cách một cuộc gọi VoIP diễn ra.

Với nhiều điều cơ bản này, chúng ta hãy quay lại với SIP.

SIP - Tổng quan

Dưới đây là một số điểm cần lưu ý về SIP -

• SIP là một giao thức báo hiệu được sử dụng để tạo, sửa đổi và kết thúc một phiên đa phương tiện qua Giao thức Internet. Một phiên không là gì ngoài một cuộc gọi đơn giản giữa hai điểm cuối. Điểm cuối có thể là điện thoại thông minh, máy tính xách tay hoặc bất kỳ thiết bị nào có thể nhận và gửi nội dung đa phương tiện qua Internet.

• SIP là một giao thức lớp ứng dụng được xác định theo tiêu chuẩn IETF (Internet Engineering Task Force). Nó được định nghĩa trongRFC 3261.

• SIP thể hiện kiến ​​trúc máy khách-máy chủ và việc sử dụng URL và URI từ HTTP và một lược đồ mã hóa văn bản và một kiểu tiêu đề từ SMTP.

• SIP nhờ sự trợ giúp của SDP (Giao thức mô tả phiên) mô tả một phiên và RTP (Giao thức truyền tải thời gian thực) được sử dụng để phân phối thoại và video qua mạng IP.

• SIP có thể được sử dụng cho các phiên hai bên (unicast) hoặc nhiều bên (đa hướng).

• Các ứng dụng SIP khác bao gồm truyền tệp, nhắn tin nhanh, hội nghị truyền hình, trò chơi trực tuyến và phân phối đa phương tiện hấp dẫn.

SIP phù hợp ở đâu?

Về cơ bản SIP là một giao thức lớp ứng dụng. Nó là một giao thức báo hiệu mạng đơn giản để tạo và kết thúc phiên với một hoặc nhiều người tham gia. Giao thức SIP được thiết kế để độc lập với giao thức truyền tải bên dưới, vì vậy các ứng dụng SIP có thể chạy trên TCP, UDP hoặc các giao thức mạng lớp thấp hơn khác.

Hình minh họa sau đây mô tả nơi SIP phù hợp trong sơ đồ chung của mọi thứ:

Thông thường, giao thức SIP được sử dụng cho điện thoại internet và phân phối đa phương tiện giữa hai hoặc nhiều điểm cuối. Ví dụ: một người có thể bắt đầu cuộc gọi điện thoại cho người khác bằng SIP hoặc ai đó có thể tạo một cuộc gọi hội nghị với nhiều người tham gia.

Giao thức SIP được thiết kế rất đơn giản, với một số lệnh hạn chế. Nó cũng dựa trên văn bản, vì vậy bất kỳ ai cũng có thể đọc một thông báo SIP được truyền giữa các điểm cuối trong một phiên SIP.

Có một số thực thể giúp SIP trong việc tạo mạng của nó. Trong SIP, mọi phần tử mạng được xác định bởiSIP URI(Định danh tài nguyên đồng nhất) giống như một địa chỉ. Sau đây là các phần tử mạng:

• Đại lý người dùng
• Máy chủ proxy
• Máy chủ đăng ký
• Máy chủ chuyển hướng
• Máy chủ vị trí

Đại lý người dùng

Nó là điểm cuối và là một trong những phần tử mạng quan trọng nhất của mạng SIP. Một điểm cuối có thể bắt đầu, sửa đổi hoặc kết thúc một phiên. Tác nhân người dùng là thiết bị hoặc phần tử mạng thông minh nhất của mạng SIP. Đó có thể là điện thoại mềm, điện thoại di động hoặc máy tính xách tay.

Tác nhân người dùng được chia hợp lý thành hai phần -

• User Agent Client (UAC) - Thực thể gửi yêu cầu và nhận phản hồi.

• User Agent Server (UAS) - Thực thể nhận yêu cầu và gửi phản hồi.

SIP dựa trên kiến ​​trúc máy khách-máy chủ trong đó điện thoại của người gọi hoạt động như một máy khách bắt đầu cuộc gọi và điện thoại của người gọi hoạt động như một máy chủ phản hồi cuộc gọi.

Máy chủ proxy

Nó là phần tử mạng nhận yêu cầu từ tác nhân người dùng và chuyển tiếp nó đến người dùng khác.

• Về cơ bản, vai trò của một máy chủ proxy giống như một bộ định tuyến.

• Nó có một số thông minh để hiểu một yêu cầu SIP và gửi nó trước với sự trợ giúp của URI.

• Một máy chủ proxy nằm giữa hai tác nhân người dùng.

• Có thể có tối đa 70 máy chủ proxy giữa nguồn và đích.

Có hai loại máy chủ proxy -

• Stateless Proxy Server- Nó chỉ đơn giản là chuyển tiếp tin nhắn nhận được. Loại máy chủ này không lưu trữ bất kỳ thông tin nào của cuộc gọi hoặc giao dịch.

• Stateful Proxy Server- Loại máy chủ proxy này theo dõi mọi yêu cầu và phản hồi nhận được và có thể sử dụng nó trong tương lai nếu được yêu cầu. Nó có thể truyền lại yêu cầu, nếu không có phản hồi từ phía bên kia kịp thời.

Máy chủ đăng ký

Máy chủ đăng ký chấp nhận yêu cầu đăng ký từ tác nhân người dùng. Nó giúp người dùng tự xác thực trong mạng. Nó lưu trữ URI và vị trí của người dùng trong cơ sở dữ liệu để giúp các máy chủ SIP khác trong cùng một miền.

Hãy xem ví dụ sau đây cho thấy quy trình Đăng ký SIP.

Ở đây người gọi muốn đăng ký với miền TMC. Vì vậy, nó sẽ gửi một yêu cầu ĐĂNG KÝ đến máy chủ Nhà đăng ký của TMC và máy chủ trả về phản hồi 200 OK khi nó đã ủy quyền cho máy khách.

Máy chủ chuyển hướng

Máy chủ chuyển hướng nhận yêu cầu và tìm kiếm người nhận yêu cầu dự kiến ​​trong cơ sở dữ liệu vị trí được tạo bởi nhà đăng ký.

Máy chủ chuyển hướng sử dụng cơ sở dữ liệu để lấy thông tin vị trí và phản hồi bằng 3xx (Phản hồi chuyển hướng) cho người dùng. Chúng ta sẽ thảo luận về các mã phản hồi sau trong hướng dẫn này.

Máy chủ vị trí

Máy chủ định vị cung cấp thông tin về các vị trí có thể có của người gọi đến các máy chủ chuyển hướng và proxy.

Chỉ máy chủ proxy hoặc máy chủ chuyển hướng mới có thể liên hệ với máy chủ định vị.

Hình dưới đây mô tả vai trò của mỗi phần tử mạng trong việc thiết lập một phiên.

SIP - Kiến trúc hệ thống

SIP được cấu trúc như một giao thức phân lớp, có nghĩa là hành vi của nó được mô tả dưới dạng một tập hợp các giai đoạn xử lý khá độc lập với chỉ một khớp nối lỏng lẻo giữa mỗi giai đoạn.

• Lớp thấp nhất của SIP là syntax and encoding. Mã hóa của nó được chỉ định bằng cách sử dụngBackus-Naur Form grammar (BNF).

• Ở cấp độ thứ hai là transport layer. Nó xác định cách Máy khách gửi yêu cầu và nhận phản hồi cũng như cách Máy chủ nhận yêu cầu và gửi phản hồi qua mạng. Tất cả các phần tử SIP đều chứa một lớp truyền tải.

• Tiếp theo là transaction layer. Giao dịch là một yêu cầu được gửi bởi giao dịch Khách hàng (sử dụng lớp truyền tải) tới giao dịch Máy chủ, cùng với tất cả các phản hồi cho yêu cầu đó được gửi từ giao dịch máy chủ trở lại khách hàng. Bất kỳ tác vụ nào mà máy khách tác nhân người dùng (UAC) hoàn thành đều diễn ra bằng cách sử dụng một loạt các giao dịch.Stateless proxies không chứa một lớp giao dịch.

• Lớp trên transaction layerđược gọi là người dùng giao dịch. Mỗi thực thể SIP, ngoại trừStateless proxies, là một người dùng giao dịch.

Hình ảnh sau đây cho thấy luồng cuộc gọi cơ bản của một phiên SIP.

Dưới đây là giải thích từng bước về luồng cuộc gọi ở trên -

• Yêu cầu INVITE được gửi đến máy chủ proxy có trách nhiệm bắt đầu phiên.

• Máy chủ proxy senda 100 Trying phản hồi ngay lập tức cho người gọi (Alice) để ngừng truyền lại yêu cầu INVITE.

• Máy chủ proxy tìm kiếm địa chỉ của Bob trong máy chủ vị trí. Sau khi nhận được địa chỉ, nó sẽ chuyển tiếp yêu cầu INVITE.

• Sau đó, 180 Ringing (Các câu trả lời tạm thời) do Bob tạo được trả lại cho Alice.

• A 200 OK phản hồi được tạo ngay sau khi Bob nhấc máy.

• Bob nhận được một ACK từ Alice, một khi nó được 200 OK.

• Đồng thời, phiên được thiết lập và các gói RTP (hội thoại) bắt đầu được truyền từ cả hai đầu.

• Sau cuộc trò chuyện, bất kỳ người tham gia nào (Alice hoặc Bob) đều có thể gửi BYE yêu cầu kết thúc phiên.

• BYE đến trực tiếp từ Alice đến Bob bằng cách bỏ qua máy chủ proxy.

• Cuối cùng, Bob gửi một 200 OK phản hồi để xác nhận BYE và phiên kết thúc.

• Trong luồng cuộc gọi cơ bản ở trên, ba transactions là (được đánh dấu là 1, 2, 3) có sẵn.

Lệnh gọi hoàn chỉnh (từ INVITE đến 200 OK) được gọi là Dialog.

Hình thang SIP

Proxy giúp kết nối người dùng này với người dùng khác như thế nào? Hãy để chúng tôi tìm hiểu với sự trợ giúp của sơ đồ sau.

Cấu trúc liên kết được hiển thị trong sơ đồ được gọi là hình thang SIP. Quá trình diễn ra như sau:

• Khi người gọi bắt đầu cuộc gọi, một tin nhắn INVITE sẽ được gửi đến máy chủ proxy. Khi nhận được INVITE, máy chủ proxy sẽ cố gắng giải quyết địa chỉ của thư viện với sự trợ giúp của máy chủ DNS.

• Sau khi nhận được tuyến tiếp theo, máy chủ proxy của người gọi (Proxy 1, còn được gọi là máy chủ proxy đi) chuyển tiếp yêu cầu INVITE đến máy chủ proxy của callee, máy chủ này hoạt động như một máy chủ proxy đến (Proxy 2) cho callee.

• Máy chủ proxy gửi đến liên hệ với máy chủ định vị để lấy thông tin về địa chỉ của người quản lý nơi người dùng đã đăng ký.

• Sau khi nhận được thông tin từ máy chủ định vị, nó sẽ chuyển tiếp cuộc gọi đến đích của nó.

• Một khi các tác nhân người dùng biết địa chỉ của họ, họ có thể bỏ qua cuộc gọi, tức là các cuộc trò chuyện được chuyển trực tiếp.

Thông điệp SIP có hai loại - requests và responses.

• Dòng mở đầu của một yêu cầu chứa một phương thức xác định yêu cầu và URI Yêu cầu xác định nơi gửi yêu cầu.

• Tương tự, dòng mở đầu của phản hồi chứa mã phản hồi.

Yêu cầu phương thức

SIP requestslà những mã được sử dụng để thiết lập giao tiếp. Để bổ sung cho chúng, cóSIP responses thường cho biết một yêu cầu thành công hay không thành công.

Các yêu cầu SIP này được gọi là PHƯƠNG PHÁP làm cho thông báo SIP có thể hoạt động được.

• METHODS có thể được coi là yêu cầu SIP, vì chúng yêu cầu một hành động cụ thể được thực hiện bởi tác nhân người dùng hoặc máy chủ khác.

• PHƯƠNG PHÁP được phân biệt thành hai loại -

  • Phương pháp cốt lõi

  • Phương pháp mở rộng

Phương pháp cốt lõi

Có sáu phương pháp cốt lõi như được thảo luận dưới đây.

MỜI GỌI

INVITE được sử dụng để bắt đầu một phiên với tác nhân người dùng. Nói cách khác, phương thức INVITE được sử dụng để thiết lập phiên truyền thông giữa các tác nhân người dùng.

• INVITE có thể chứa thông tin phương tiện của người gọi trong nội dung thư.

• Một phiên được coi là đã được thiết lập nếu INVITE nhận được phản hồi thành công (2xx) hoặc ACK đã được gửi.



• Yêu cầu INVITE thành công thiết lập dialog giữa hai tác nhân người dùng tiếp tục cho đến khi một BYE được gửi để kết thúc phiên.

• INVITE được gửi trong hộp thoại đã thiết lập được gọi là re-INVITE.

• MỜI lại được sử dụng để thay đổi đặc điểm phiên hoặc làm mới trạng thái của hộp thoại.

Ví dụ về INVITE

Đoạn mã sau đây cho thấy cách INVITE được sử dụng.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

TẠM BIỆT

BYE là phương thức được sử dụng để kết thúc một phiên đã thiết lập. Đây là một yêu cầu SIP có thể được gửi bởi người gọi hoặc người gọi để kết thúc một phiên.

• Nó không thể được gửi bởi một máy chủ proxy.

• Yêu cầu BYE thường các tuyến kết thúc để kết thúc, bỏ qua máy chủ proxy.

• BYE không thể được gửi đến một INVITE đang chờ xử lý hoặc một phiên chưa được thiết lập.

ĐĂNG KÝ

Yêu cầu ĐĂNG KÝ thực hiện việc đăng ký tác nhân người dùng. Yêu cầu này được gửi bởi một tác nhân người dùng đến một máy chủ đăng ký.

• Yêu cầu ĐĂNG KÝ có thể được chuyển tiếp hoặc ủy quyền cho đến khi nó đến được nhà đăng ký có thẩm quyền của miền được chỉ định.

• Nó mang AOR (Địa chỉ của Bản ghi) trong To tiêu đề của người dùng đang được đăng ký.

• Yêu cầu ĐĂNG KÝ chứa khoảng thời gian (3600 giây).

• Một tác nhân người dùng có thể gửi yêu cầu ĐĂNG KÝ thay mặt cho một tác nhân người dùng khác. Điều này được gọi làthird-party registration. Đây,From thẻ chứa URI của bên gửi đăng ký thay mặt cho bên được xác định trong To đầu trang.

HỦY

CANCEL được sử dụng để kết thúc một phiên không được thiết lập. Tác nhân người dùng sử dụng yêu cầu này để hủy một cuộc gọi đang chờ xử lý được thực hiện trước đó.

• Nó có thể được gửi bởi một tác nhân người dùng hoặc một máy chủ proxy.

• CANCEL là một hop by hop yêu cầu, tức là, nó đi qua các phần tử giữa tác nhân người dùng và nhận phản hồi do phần tử trạng thái tiếp theo tạo ra.

ACK

ACK được sử dụng để xác nhận các phản hồi cuối cùng đối với phương thức INVITE. ACK luôn đi theo hướng INVITE.ACK có thể chứa nội dung SDP (đặc tính phương tiện), nếu nó không có sẵn trong INVITE.

• ACK không được sử dụng để sửa đổi mô tả phương tiện đã được gửi trong INVITE ban đầu.

• Một proxy trạng thái nhận ACK phải xác định xem ACK có nên được chuyển tiếp xuôi dòng tới proxy hoặc tác nhân người dùng khác hay không.

• Đối với các phản hồi 2xx, ACK là kết thúc để kết thúc, nhưng đối với tất cả các phản hồi cuối cùng khác, nó hoạt động trên cơ sở từng bước khi các proxy trạng thái có liên quan.

TÙY CHỌN

Phương pháp OPTIONS được sử dụng để truy vấn tác nhân người dùng hoặc máy chủ proxy về khả năng của nó và khám phá tính khả dụng hiện tại của nó. Phản hồi cho một yêu cầu liệt kê các khả năng của tác nhân người dùng hoặc máy chủ. Một proxy không bao giờ tạo yêu cầu TÙY CHỌN.

Phương pháp mở rộng

Đăng ký

SUBSCRIBE được các tác nhân người dùng sử dụng để thiết lập đăng ký nhằm mục đích nhận thông báo về một sự kiện cụ thể.

• Nó chứa một Expires trường tiêu đề cho biết thời lượng của một đăng ký.

• Sau khi khoảng thời gian trôi qua, đăng ký sẽ tự động chấm dứt.

• Đăng ký thiết lập một hộp thoại giữa các tác nhân người dùng.

• Bạn có thể đăng ký lại một lần nữa bằng cách gửi một SUBSCRIBE khác trong hộp thoại trước khi hết hạn.

• 200 OK sẽ được nhận cho một đăng ký từ Người dùng.

• Người dùng có thể hủy đăng ký bằng cách gửi một phương thức SUBSCRIBE khác với giá trị Expires 0 (không).

THÔNG BÁO

NOTIFY được sử dụng bởi các tác nhân người dùng để nhận được sự xuất hiện của một sự kiện cụ thể. Thông thường, THÔNG BÁO sẽ kích hoạt trong hộp thoại khi có đăng ký giữa người đăng ký và người thông báo.

• Mỗi NOTIFY sẽ nhận được 200 phản hồi OK nếu nó được người thông báo nhận được.

• CHÚ Ý chứa một Event trường tiêu đề cho biết sự kiện và subscriptionstate trường tiêu đề cho biết trạng thái hiện tại của đăng ký.

• THÔNG BÁO luôn được gửi khi bắt đầu và kết thúc đăng ký.

CÔNG BỐ

PUBLISH được sử dụng bởi tác nhân người dùng để gửi thông tin trạng thái sự kiện đến máy chủ.

• PUBLISH hầu hết hữu ích khi có nhiều nguồn thông tin sự kiện.

• Yêu cầu PUBLISH tương tự như NOTIFY, ngoại trừ việc nó không được gửi trong hộp thoại.

• Yêu cầu PUBLISH phải chứa một Expires trường tiêu đề và một Min-Expires trường tiêu đề.

THAM KHẢO

REFER được tác nhân người dùng sử dụng để giới thiệu một tác nhân người dùng khác truy cập vào URI cho hộp thoại.

• REFER phải chứa một Refer-Tođầu trang. Đây là tiêu đề bắt buộc để THAM KHẢO.

• THAM KHẢO có thể được gửi bên trong hoặc bên ngoài hộp thoại.

• A 202 Accepted sẽ kích hoạt yêu cầu THAM KHẢO cho biết rằng tác nhân người dùng khác đã chấp nhận tham chiếu.

THÔNG TIN

INFO được sử dụng bởi một tác nhân người dùng để gửi thông tin báo hiệu cuộc gọi đến một tác nhân người dùng khác mà nó đã thiết lập một phiên truyền thông.

• Đây là một yêu cầu từ đầu đến cuối.

• Một proxy sẽ luôn chuyển tiếp một yêu cầu INFO.

CẬP NHẬT

UPDATE được sử dụng để sửa đổi trạng thái của một phiên nếu một phiên không được thiết lập. Người dùng có thể thay đổi codec với UPDATE.

NẾU một phiên được thiết lập, một Lời mời lại được sử dụng để thay đổi / cập nhật phiên.

PRACK

PRACK được sử dụng để xác nhận việc nhận được một chuyển phản hồi tạm thời đáng tin cậy (1XX).

• Nói chung PRACK được tạo bởi máy khách khi nó nhận được phản hồi tạm thời có chứa RSeq số thứ tự đáng tin cậy và một supported:100rel đầu trang.

• PRACK chứa giá trị (RSeq + CSeq) trong rack đầu trang.

• Phương pháp PRACK áp dụng cho tất cả các phản hồi tạm thời ngoại trừ 100 phản hồi Đang thử, không bao giờ được vận chuyển một cách đáng tin cậy.

• PRACK có thể chứa nội dung thư; nó có thể được sử dụng để trao đổi đề nghị / câu trả lời.

THÔNG ĐIỆP

Nó được sử dụng để gửi tin nhắn tức thì bằng SIP. IM thường bao gồm các tin nhắn ngắn được trao đổi trong thời gian thực bởi những người tham gia vào cuộc trò chuyện bằng văn bản.

• MESSAGE có thể được gửi trong hộp thoại hoặc bên ngoài hộp thoại.

• Nội dung của MESSAGE được đưa vào nội dung thư dưới dạng MIME tập tin đính kèm.

• A 200 OK phản hồi thường được nhận để cho biết rằng thông điệp đã được gửi đến đích của nó.

Phản hồi SIP là một thông báo được tạo bởi máy chủ tác nhân người dùng (UAS) hoặc máy chủ SIP để trả lời một yêu cầu do máy khách tạo ra. Nó có thể là một xác nhận chính thức để ngăn chặn việc UAC truyền lại các yêu cầu.

• Một phản hồi có thể chứa một số trường thông tin bổ sung của tiêu đề mà UAC cần.

• SIP có sáu phản hồi.

• 1xx đến 5xx đã được mượn từ HTTP và 6xx được giới thiệu trong SIP.

• 1xx được coi là một provisional phản hồi và phần còn lại là final phản hồi.

Không.	Mô tả chức năng
1	1xx: Phản hồi tạm thời / cung cấp thông tin Các phản hồi thông tin được sử dụng để chỉ ra call progress. Thông thường các câu trả lời đều có kết thúc (ngoại trừ 100 Đang thử).
2	2xx: Phản hồi thành công Loại phản hồi này có nghĩa là chỉ ra rằng một yêu cầu đã được chấp nhận.
3	3xx: Phản hồi chuyển hướng Nói chung, các phản hồi lớp này được gửi bởi các máy chủ chuyển hướng để phản hồi lại INVITE. Chúng còn được gọi là phản hồi lớp chuyển hướng.
4	4xx: Phản hồi lỗi của máy khách Phản hồi lỗi của máy khách cho thấy rằng yêu cầu không thể được thực hiện vì một số lỗi được xác định từ phía UAC.
5	5xx: Phản hồi lỗi máy chủ Phản hồi lớp này được sử dụng để chỉ ra rằng yêu cầu không thể được xử lý do lỗi với máy chủ.
6	6xx: Phản hồi lỗi toàn cầu Lớp phản hồi này chỉ ra rằng máy chủ biết rằng yêu cầu sẽ không thành công ở bất kỳ nơi nào nó được thử. Do đó, yêu cầu sẽ không được gửi đến các vị trí khác.

Tiêu đề là một thành phần của bản tin SIP truyền tải thông tin về bản tin. Nó được cấu trúc như một chuỗi các trường tiêu đề.

Các trường tiêu đề SIP trong hầu hết các trường hợp tuân theo các quy tắc giống như các trường tiêu đề HTTP. Các trường tiêu đề được định nghĩa làHeader: field, trong đó Header được sử dụng để đại diện cho tên trường tiêu đề và trường là tập hợp các mã thông báo chứa thông tin. Mỗi trường bao gồm một tên trường theo sau bởi dấu hai chấm (":") và giá trị trường (tức là,field-name: field-value).

Tiêu đề SIP - Dạng nhỏ gọn

Nhiều trường tiêu đề SIP phổ biến có dạng thu gọn trong đó tên trường tiêu đề được biểu thị bằng một ký tự chữ thường. Một số ví dụ được đưa ra dưới đây -

Tiêu đề	Dạng nhỏ gọn
Đến	T
Thông qua	V
Id cuộc gọi	Tôi
Tiếp xúc	M
Từ	F
Môn học	S
Thời lượng nội dung	Tôi

Định dạng tiêu đề SIP

Hình ảnh sau đây cho thấy cấu trúc của tiêu đề SIP điển hình.

Tiêu đề được phân loại như sau tùy thuộc vào cách sử dụng của chúng trong SIP -

• Yêu cầu và phản hồi
• Chỉ yêu cầu
• Chỉ phản hồi
• Nội dung Thư

SDP là viết tắt của Session Description Protocol. Nó được sử dụng để mô tả các phiên đa phương tiện ở một định dạng được hiểu bởi những người tham gia qua mạng. Tùy thuộc vào mô tả này, một bên quyết định có tham gia hội nghị hay không hoặc khi nào hoặc cách thức tham gia hội nghị.

• Chủ sở hữu của một hội nghị quảng cáo nó qua mạng bằng cách gửi các tin nhắn đa hướng có mô tả về phiên họp, ví dụ như tên của chủ sở hữu, tên của phiên họp, mã hóa, thời gian, v.v. Tùy thuộc vào những thông tin này, người nhận quảng cáo quyết định về việc tham gia phiên họp.

• SDP thường được chứa trong phần nội dung của Giao thức Khởi tạo Phiên thường được gọi là SIP.

• SDP được định nghĩa trong RFC 2327. Thông báo SDP bao gồm một loạt các dòng, được gọi là các trường, có tên được viết tắt bằng một chữ cái thường duy nhất và theo thứ tự bắt buộc để đơn giản hóa việc phân tích cú pháp.

Mục đích của SDP

Mục đích của SDP là truyền tải thông tin về các luồng phương tiện trong các phiên đa phương tiện để giúp người tham gia tham gia hoặc thu thập thông tin của một phiên cụ thể.

• SDP là một mô tả dạng văn bản có cấu trúc ngắn.

• Nó truyền đạt tên và mục đích của phiên, phương tiện, giao thức, định dạng codec, thời gian và thông tin truyền tải.

• Người tham gia dự kiến ​​sẽ kiểm tra những thông tin này và quyết định có tham gia một phiên hay không và cách thức và thời gian tham gia một phiên nếu họ quyết định làm như vậy.

• Định dạng có các mục nhập ở dạng <type> = <value>, trong đó <type> xác định một tham số phiên duy nhất và <value> cung cấp một giá trị cụ thể cho tham số đó.

• Hình thức chung của thông báo SDP là -

  x = parameter1 parameter2 ... parameterN

• Dòng bắt đầu bằng một chữ thường, ví dụ: x. Không bao giờ có bất kỳ khoảng trắng nào giữa chữ cái và dấu =, và có chính xác một khoảng trắng giữa mỗi tham số. Mỗi trường có một số tham số xác định.

Thông số mô tả phiên

Mô tả phiên (* biểu thị tùy chọn)

• v = (phiên bản giao thức)
• o = (chủ sở hữu / người tạo và mã định danh phiên)
• s = (tên phiên)
• i = * (thông tin phiên)
• u = * (URI của mô tả)
• e = * (địa chỉ email)
• p = * (số điện thoại)
• c = * (thông tin kết nối - không bắt buộc nếu có trong tất cả các phương tiện)
• b = * (thông tin băng thông)
• z = * (điều chỉnh múi giờ)
• k = * (khóa mã hóa)
• a = * (không hoặc nhiều dòng thuộc tính phiên)

Phiên bản giao thức

Trường v = chứa số phiên bản SDP. Vì phiên bản hiện tại của SDP là 0, một thông báo SDP hợp lệ sẽ luôn bắt đầu bằng v = 0.

Gốc

Trường o = chứa thông tin về người khởi tạo phiên và các định danh phiên. Trường này được sử dụng để xác định phiên duy nhất.

• Trường chứa -

  o = <tên người dùng> <session-id> <version> <network-type> <address-type>

• Các username tham số chứa thông tin đăng nhập hoặc máy chủ của người khởi tạo.

• Các session-id tham số là dấu thời gian Giao thức Thời gian Mạng (NTP) hoặc một số ngẫu nhiên được sử dụng để đảm bảo tính duy nhất.

• Các version là một trường số được tăng lên cho mỗi thay đổi đối với phiên, cũng được khuyến nghị làm dấu thời gian NTP.

• Các network-typeluôn IN cho Internet. Tham số kiểu địa chỉ là IP4 hoặc IP6 cho địa chỉ IPv4 hoặc IPv6 ở dạng thập phân chấm hoặc tên máy chủ đủ điều kiện.

Tên phiên và thông tin

Trường s = chứa tên cho phiên. Nó có thể chứa bất kỳ số ký tự khác không. Trường i = tùy chọn chứa thông tin về phiên. Nó có thể chứa bất kỳ số ký tự nào.

URI

Trường u = tùy chọn chứa chỉ báo tài nguyên thống nhất (URI) với nhiều thông tin hơn về phiên

Địa chỉ e-mail và số điện thoại

Trường e = tùy chọn chứa địa chỉ e-mail của máy chủ của phiên. Trường p = tùy chọn chứa một số điện thoại.

Dữ liệu kết nối

Trường c = chứa thông tin về kết nối phương tiện.

• Trường chứa -

  c = <network-type> <address-type> <connection-address>

• Các network-type tham số được định nghĩa là IN cho Internet.

• Các address-type được định nghĩa là IP4 cho địa chỉ IPv4 và IP6 cho địa chỉ IPv6.

• Các connection-address là địa chỉ IP hoặc máy chủ lưu trữ sẽ gửi các gói phương tiện, có thể là multicast hoặc unicast.

• Nếu phát đa hướng, trường địa chỉ kết nối chứa:

  connection-address = base-multicast-address / ttl / number-of-address

Ở đâu ttl là giá trị thời gian tồn tại và số lượng địa chỉ cho biết có bao nhiêu địa chỉ phát đa hướng liền kề được bao gồm bắt đầu bằng địa chỉ đa hướng cơ sở.

Băng thông

Trường b = tùy chọn chứa thông tin về băng thông cần thiết. Nó có dạng -

b = modifier: băng thông - giá trị

Thời gian, Thời gian lặp lại và Múi giờ

Trường t = chứa thời gian bắt đầu và thời gian dừng của phiên.

t = thời gian bắt đầu dừng lại

Trường r = tùy chọn chứa thông tin về thời gian lặp lại có thể được chỉ định trong NTP hoặc theo ngày ( d ), giờ ( h ) hoặc phút ( m ).

Trường z = tùy chọn chứa thông tin về chênh lệch múi giờ. Trường này được sử dụng nếu phiên đang diễn ra kéo dài sự thay đổi từ tiết kiệm ánh sáng ban ngày sang giờ chuẩn hoặc ngược lại.

Thông báo truyền thông

Trường m = tùy chọn chứa thông tin về loại phiên phương tiện. Trường chứa -

m = định dạng-danh sách vận chuyển cổng phương tiện

• Tham số phương tiện là âm thanh, video, văn bản, ứng dụng, tin nhắn, hình ảnh hoặc điều khiển. Tham số cổng chứa số cổng.

• Tham số truyền tải chứa giao thức truyền tải hoặc cấu hình RTP được sử dụng.

• Danh sách định dạng chứa thêm thông tin về phương tiện. Thông thường, nó chứa các loại tải trọng phương tiện được xác định trong cấu hình video âm thanh RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Một trong ba codec này có thể được sử dụng cho phiên phương tiện âm thanh. Nếu mục đích là thiết lập ba kênh âm thanh, ba trường phương tiện riêng biệt sẽ được sử dụng.

Thuộc tính

Trường a = tùy chọn chứa các thuộc tính của phiên phương tiện trước đó. Trường này có thể được sử dụng đểextend SDP to provide more information about the media. Nếu người dùng SDP không hiểu đầy đủ, trường thuộc tính có thể bị bỏ qua. Có thể có một hoặc nhiều trường thuộc tính cho mỗi loại tải trọng phương tiện được liệt kê trong trường phương tiện.

Các thuộc tính trong SDP có thể là

• cấp độ phiên, hoặc
• mức độ phương tiện.

Cấp độ phiên có nghĩa là thuộc tính được liệt kê trước dòng phương tiện đầu tiên trong SDP. Nếu đúng như vậy, thuộc tính sẽ áp dụng cho tất cả các dòng phương tiện bên dưới nó.

Mức phương tiện có nghĩa là nó được liệt kê sau một dòng phương tiện. Trong trường hợp này, thuộc tính chỉ áp dụng cho luồng phương tiện cụ thể này.

SDP có thể bao gồm cả thuộc tính cấp phiên và cấp phương tiện. Nếu cùng một thuộc tính xuất hiện như cả hai, thuộc tính cấp phương tiện sẽ ghi đè thuộc tính cấp phiên cho luồng phương tiện cụ thể đó. Lưu ý rằng trường dữ liệu kết nối cũng có thể là cấp phiên hoặc cấp phương tiện.

Ví dụ về SDP

Dưới đây là mô tả phiên ví dụ, được lấy từ RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

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à application/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 200 phản hồi OK đối với 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ữ cố định 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.

• Tải trọng đượ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 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ể được 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 SDP của INVITE ban đầu nhưng vớia = sendonly thuộc tính hiện tại.

Cuộc gọi được kích hoạt trở lại bằng cách gửi một INVITE khác với a = sendrecvthuộc tính hiện tại. Hình minh họa sau đây cho thấy luồng cuộc gọi của một cuộc gọi.

Personal mobilitylà khả năng có một số nhận dạng không đổi 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ợ service mobility - khả năng người dùng giữ các dịch vụ tương tự 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ị, đă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ụ, 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 -

• Đă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:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]: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:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

INVITE đầu tiên được thể hiện trong hình trên sẽ được gửi đến ngụm: registerrar2.in; INVITE thứ hai sẽ được gửi đến ngụm: nhâm nhi: [email protected], sẽ được chuyển tiếp tớisip:[email protected]. Nó đến được với Tom và cho phép thiết lập phiên. Định kỳ cả hai đăng ký sẽ cần được làm mới.

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 suốt phiên làm việc khi nó hoán đổi từ mạng này sang mạng khác. Basic SIP hỗ trợ kịch bản 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:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];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, bộ đị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 trung bình

Ví dụ: nếu một proxy là cần thiết 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ó.

Note - 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 sang hộp thoại mới 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 thông qua máy chủ proxy cũ đã truy cập 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 như dịch vụ chuyển tiếp cuộc gọi được triển khai trong một điểm cuối sẽ không thành công 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.

Đôi khi, một máy chủ proxy chuyển tiếp một cuộc gọi SIP đến nhiều điểm cuối SIP. Quá trình này được gọi là rèn. Ở đây một cuộc gọi có thể đổ chuông nhiều điểm cuối cùng một lúc.

Với SIP fork, bạn có thể để điện thoại bàn đổ chuông cùng lúc với điện thoại mềm hoặc điện thoại SIP trên điện thoại di động, cho phép bạn dễ dàng nhận cuộc gọi từ một trong hai thiết bị.

Nói chung, trong văn phòng, giả sử sếp không thể nhận cuộc gọi hoặc đi vắng, SIP fork cho phép thư ký trả lời các cuộc gọi đến số máy lẻ của anh ta.

Forking sẽ có thể thực hiện được nếu có sẵn một proxy trạng thái khi nó cần thực hiện và phản hồi trong số nhiều proxy nó nhận được.

Chúng tôi có hai loại rèn -

• Forking song song
• Forking tuần tự

Forking song song

Trong trường hợp này, máy chủ proxy sẽ phân chia INVITE đến, chẳng hạn, hai thiết bị (UA2, UA3) cùng một lúc. Cả hai thiết bị sẽ tạo ra 180 Đổ chuông và bất kỳ ai nhận cuộc gọi sẽ tạo ra 200 OK. Phản hồi (giả sử UA2) đến Bộ khởi tạo trước sẽ thiết lập một phiên với UA2. Đối với phản hồi khác, HỦY sẽ được kích hoạt.

Nếu người khởi tạo nhận được cả hai phản hồi đồng thời, thì dựa trên giá trị q, nó sẽ chuyển tiếp phản hồi.

Forking tuần tự

Trong trường hợp này, máy chủ proxy sẽ phân phối INVITE tới một thiết bị (UA2). Nếu UA2 không khả dụng hoặc bận vào thời điểm đó, thì proxy sẽ chuyển nó sang thiết bị khác (UA3).

Chi nhánh - ID và Thẻ

Các ID nhánh giúp proxy đối sánh phản hồi với các yêu cầu đã phân nhánh. Nếu không có ID chi nhánh, máy chủ proxy sẽ không thể hiểu phản hồi được phân nhánh. Branch-id sẽ có sẵn trong Via header.

Các thẻ được UAC sử dụng để phân biệt nhiều phản hồi cuối cùng từ các UAS khác nhau. UAS không thể giải quyết liệu yêu cầu đã được chia nhỏ hay chưa. Do đó, nó cần phải thêm một thẻ.

Proxy cũng có thể thêm thẻ nếu nó tạo ra phản hồi cuối cùng, chúng không bao giờ chèn thẻ vào các yêu cầu hoặc phản hồi mà chúng chuyển tiếp.

Có thể một yêu cầu duy nhất cũng có thể được phân nhánh bởi nhiều máy chủ proxy. Vì vậy, proxy sẽ phân nhánh sẽ thêm các ID duy nhất của riêng nó vào các nhánh mà nó đã tạo.

Chân cuộc gọi và ID cuộc gọi

Chân cuộc gọi đề cập đến mối quan hệ báo hiệu 1-1 giữa hai tác nhân người dùng. ID cuộc gọi là một mã định danh duy nhất có trong bản tin SIP đề cập đến cuộc gọi. Cuộc gọi là một tập hợp các chân cuộc gọi.

Một UAC bắt đầu bằng cách gửi một MỜI. Do bị phân nhánh, nó có thể nhận được nhiều 200 OK từ các UA khác nhau. Mỗi tương ứng với một chặng gọi khác nhau trong cùng một cuộc gọi.

Do đó, một cuộc gọi là một nhóm các chân gọi. Chân cuộc gọi đề cập đến kết nối end-to-end giữa các UA.

Các không gian CSeq trong hai hướng của một chân gọi là độc lập. Trong một hướng duy nhất, số thứ tự được tăng lên cho mỗi giao dịch.

Thư thoại

Thư thoại bây giờ rất phổ biến đối với người dùng doanh nghiệp. Đó là một ứng dụng điện thoại. Khi bên được gọi vắng mặt hoặc không thể nhận cuộc gọi, PBX sẽ thông báo cho bên gọi để lại tin nhắn thoại.

Tác nhân người dùng sẽ nhận được phản hồi 3xx hoặc chuyển hướng đến máy chủ thư thoại nếu không thể truy cập được số của bên được gọi. Tuy nhiên, một số loại phần mở rộng SIP là cần thiết để cho hệ thống thư thoại biết hộp thư nào sẽ sử dụng — nghĩa là lời chào sẽ phát và nơi lưu trữ tin nhắn đã ghi. Có hai cách để đạt được điều này -

• Bằng cách sử dụng phần mở rộng trường tiêu đề SIP

• Bằng cách sử dụng URI yêu cầu để báo hiệu thông tin này

Giả sử cho người dùng sip:[email protected] có hệ thống thư thoại tại nhâm nhi: voicemail.tutorialspoint.com đang cung cấp thư thoại, URI yêu cầu của INVITE khi nó được chuyển tiếp đến máy chủ thư thoại có thể trông giống như sau:

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

Hình minh họa sau đây cho thấy cách Request-URI mang mã định danh hộp thư và lý do (ở đây 486).

Như chúng ta đã biết, một máy chủ proxy có thể ở trạng thái không trạng thái hoặc trạng thái. Ở đây, trong chương này, chúng ta sẽ thảo luận thêm về máy chủ proxy và định tuyến SIP.

Máy chủ proxy không trạng thái

Một máy chủ proxy không trạng thái chỉ cần chuyển tiếp tin nhắn mà nó nhận được. Loại máy chủ này không lưu trữ bất kỳ thông tin nào của cuộc gọi hoặc giao dịch.

• Các proxy không trạng thái quên yêu cầu SIP khi nó đã được chuyển tiếp.
• Giao dịch sẽ nhanh chóng thông qua proxy không trạng thái.

Máy chủ proxy trạng thái

Một máy chủ proxy trạng thái theo dõi mọi yêu cầu và phản hồi mà nó nhận được. Nó có thể sử dụng thông tin được lưu trữ trong tương lai, nếu được yêu cầu. Nó có thể truyền lại yêu cầu nếu nó không nhận được phản hồi từ phía bên kia.

• Các proxy trạng thái ghi nhớ yêu cầu sau khi nó được chuyển tiếp, vì vậy họ có thể sử dụng nó để định tuyến trước. Các proxy trạng thái duy trì trạng thái giao dịch . Giao dịch ngụ ý trạng thái giao dịch,nottrạng thái cuộc gọi .

• Giao dịch không nhanh bằng proxy trạng thái không trạng thái.

• Các proxy trạng thái có thể fork và truyền lại nếu được yêu cầu. (Ví dụ: ví dụ: cuộc gọi chuyển tiếp bận).

Via và Record-route

Ghi-Lộ trình

Tiêu đề Record-Route được chèn vào các yêu cầu bởi proxy muốn nằm trong đường dẫn của các yêu cầu tiếp theo cho cùng một call-id. Sau đó, nó được tác nhân người dùng sử dụng để định tuyến các yêu cầu tiếp theo.

Thông qua

Thông qua các tiêu đề được máy chủ chèn vào các yêu cầu để phát hiện các vòng lặp và giúp các phản hồi tìm đường quay trở lại máy khách. Điều này rất hữu ích cho những câu trả lời chỉ đến đích.

• UA tự tạo và thêm địa chỉ của chính nó vào trường tiêu đề Qua khi gửi yêu cầu.

• Chuyển tiếp proxy yêu cầu thêm trường tiêu đề Qua có chứa địa chỉ của chính nó vào đầu danh sách các trường tiêu đề Qua.

• Một proxy hoặc UA tạo phản hồi cho một yêu cầu sẽ sao chép tất cả các trường tiêu đề Qua từ yêu cầu để đưa vào phản hồi, sau đó gửi phản hồi đến địa chỉ được chỉ định trong trường tiêu đề Qua trên cùng.

• Một proxy nhận được phản hồi sẽ kiểm tra trường tiêu đề Via trên cùng và khớp với địa chỉ của chính nó. Nếu không khớp, phản hồi đã bị loại bỏ.

• Sau đó, trường tiêu đề Qua trên cùng bị xóa và phản hồi được chuyển tiếp đến địa chỉ được chỉ định trong trường tiêu đề Qua tiếp theo.

Thông qua các trường tiêu đề chứa tên giao thức, số phiên bản và truyền tải (SIP / 2.0 / UDP, SIP / 2.0 / TCP, v.v.) và chứa các số cổng và các tham số như đã nhận, rport, nhánh.

• Thẻ đã nhận được thêm vào trường tiêu đề Qua nếu UA hoặc proxy nhận được yêu cầu từ một địa chỉ khác với địa chỉ được chỉ định trong trường tiêu đề Qua trên cùng.

• Tham số nhánh được thêm vào các trường tiêu đề Via bởi UA và proxy, được tính như một hàm băm của Request-URI và số To, From, Call-ID và CSeq.

SIP (Softphone) và PSTN (Điện thoại cũ) đều là các mạng khác nhau và nói các ngôn ngữ khác nhau. Vì vậy, chúng ta cần một trình dịch (Gateway ở đây) để giao tiếp giữa hai mạng này.

Hãy để chúng tôi lấy một ví dụ cho thấy cách một điện thoại SIP thực hiện cuộc gọi đến PSTN thông qua cổng PSTN.

Trong ví dụ này, Tom (sip:[email protected]) là một chiếc điện thoại nhâm nhi và Jerry sử dụng số điện thoại toàn cầu +91401234567.

SIP đến PSTN thông qua Cổng

Hình minh họa sau đây cho thấy luồng cuộc gọi từ SIP đến PSTN thông qua các cổng.

Dưới đây là phần giải thích từng bước về tất cả quy trình diễn ra trong khi thực hiện cuộc gọi từ điện thoại SIP tới PSTN.

• Trước hết, điện thoại (Tom) SIP quay số toàn cầu +91401234567 để liên lạc với Jerry. Tác nhân người dùng SIP hiểu nó như một số toàn cầu và chuyển nó thành request-uri bằng DNS và kích hoạt yêu cầu.

• Điện thoại SIP gửi INVITE trực tiếp đến cổng.

• Cổng kết nối bắt đầu cuộc gọi vào PSTN bằng cách chọn một trung kế ISUP SS7 tới tổng đài điện thoại tiếp theo trong PSTN.

• Các chữ số đã quay từ INVITE được ánh xạ vào IAM ISUP. Thông báo hoàn thành địa chỉ ISUP (ACM) được gửi lại bởi PSTN để chỉ ra rằng trung kế đã được tạo.

• Điện thoại tạo ra nhạc chuông và nó sẽ chuyển đến tổng đài điện thoại. Cổng ánh xạ ACM tới phản hồi Tiến trình phiên 183 có chứa SDP chỉ ra cổng RTP mà cổng đó sẽ sử dụng để kết nối âm thanh từ PSTN.

• Khi nhận được 183, UAC của người gọi bắt đầu nhận các gói RTP được gửi từ cổng vào và trình bày âm thanh cho người gọi để họ biết rằng callee đang tiến hành trong PSTN.

• Cuộc gọi hoàn tất khi bên được gọi trả lời điện thoại, điều này khiến tổng đài điện thoại gửi tin nhắn trả lời (ANM) đến cổng.

• Sau đó, cổng kết nối sẽ cắt kết nối âm thanh PSTN theo cả hai hướng và gửi phản hồi 200 OK đến người gọi. Khi đường dẫn phương tiện RTP đã được thiết lập, cổng trả lời SDP trong 183 nhưng không gây ra thay đổi đối với kết nối RTP.

• UAC gửi một ACK để hoàn thành việc trao đổi tín hiệu SIP. Vì không có thông báo tương đương trong ISUP, cổng vào sẽ hấp thụ ACK.

• Người gọi gửi BYE đến cổng kết thúc. Cổng ánh xạ BYE vào thông báo phát hành ISUP (REL).

• Cổng vào gửi 200OK đến BYE và nhận RLC từ PSTN.

Một codec, viết tắt của coder-decoder, thực hiện hai hoạt động cơ bản -

• Đầu tiên, nó chuyển đổi tín hiệu thoại tương tự sang dạng kỹ thuật số tương đương để có thể dễ dàng truyền đi.

• Sau đó, nó chuyển đổi tín hiệu kỹ thuật số đã nén trở lại dạng analog ban đầu để có thể phát lại.

Có rất nhiều codec có sẵn trên thị trường - một số miễn phí trong khi những codec khác yêu cầu cấp phép. Codec khác nhau về chất lượng âm thanh và khác nhau về băng thông.

Các thiết bị phần cứng như điện thoại và cổng hỗ trợ một số codec khác nhau. Trong khi nói chuyện với nhau, họ thương lượng codec nào họ sẽ sử dụng.

Ở đây, trong chương này, chúng ta sẽ thảo luận về một số codec âm thanh SIP phổ biến được sử dụng rộng rãi.

G.711

G.711 là một codec được ITU giới thiệu vào năm 1972 để sử dụng trong điện thoại kỹ thuật số. Codec có hai biến thể:A-Law đang được sử dụng ở Châu Âu và trong các liên kết điện thoại quốc tế, uLaw được sử dụng ở Mỹ và Nhật Bản.

• G.711 sử dụng nén logarit. Nó ép mỗi mẫu 16 bit thành 8 bit, do đó nó đạt được tỷ lệ nén 1: 2.

• Tốc độ bit là 64 kbit / s cho một hướng, do đó, một cuộc gọi tiêu thụ 128 kbit / s.

• G.711 là cùng một codec được mạng PSTN sử dụng, do đó nó cung cấp chất lượng thoại tốt nhất. Tuy nhiên nó tiêu tốn nhiều băng thông hơn các codec khác.

• Nó hoạt động tốt nhất trong các mạng cục bộ nơi chúng tôi có nhiều băng thông.

G.729

G.729 là một codec với yêu cầu băng thông thấp; nó cung cấp chất lượng âm thanh tốt.

• Codec mã hóa âm thanh trong các khung có độ dài 10 ms. Với tần số lấy mẫu là 8 kHz, khung hình 10 ms chứa 80 mẫu âm thanh.

• Thuật toán codec mã hóa mỗi khung hình thành 10 byte, do đó tốc độ bit thu được là 8 kbit / s theo một hướng.

• G.729 là một codec được cấp phép. Người dùng cuối muốn sử dụng codec này nên mua một phần cứng triển khai nó (có thể là điện thoại hoặc cổng VoIP).

• Một biến thể thường được sử dụng của G.729 là G.729a. Nó tương thích dây với codec gốc nhưng có yêu cầu CPU thấp hơn.

G.723.1

G.723.1 là kết quả của một cuộc thi mà ITU đã công bố với mục đích thiết kế một codec cho phép các cuộc gọi qua các liên kết modem 28,8 và 33 kbit / s.

• Chúng tôi có hai biến thể của G.723.1. Cả hai đều hoạt động trên khung âm thanh 30 ms (tức là 240 mẫu), nhưng các thuật toán khác nhau.

• Tốc độ bit của biến thể đầu tiên là 6,4 kbit / s, trong khi đối với biến thể thứ hai là 5,3 kbit / s.

• Khung được mã hóa cho hai biến thể dài lần lượt là 24 và 20 byte.

GSM 06.10

GSM 06.10 là một codec được thiết kế cho các mạng di động GSM. Nó còn được gọi là GSM Full Rate.

• Biến thể này của codec GSM có thể được sử dụng tự do, vì vậy bạn thường sẽ tìm thấy nó trong các ứng dụng VoIP mã nguồn mở.

• Codec hoạt động trên các khung âm thanh dài 20 ms (tức là 160 mẫu) và nó nén mỗi khung còn 33 byte, do đó tốc độ bit thu được là 13 kbit /.

Tác nhân người dùng hỗ trợ (B2BUA) là một phần tử mạng logic trong các ứng dụng SIP. Nó là một loại SIP UA nhận một yêu cầu SIP, sau đó định dạng lại yêu cầu và gửi nó đi dưới dạng một yêu cầu mới.

Không giống như máy chủ proxy, nó duy trì trạng thái hộp thoại và phải tham gia vào tất cả các yêu cầu được gửi trên hộp thoại mà nó đã thiết lập. B2BUA phá vỡ bản chất end-to-end của SIP.

B2BUA - Cách thức hoạt động?

Tác nhân B2BUA hoạt động giữa hai điểm cuối của cuộc gọi điện thoại và chia kênh liên lạc thành hai call legs. B2BUA là sự ghép nối của UAC và UAS. Nó tham gia vào tất cả các báo hiệu SIP giữa cả hai đầu của cuộc gọi, nó đã được thiết lập. Vì B2BUA có sẵn trong nhà cung cấp dịch vụ hộp thoại có thể triển khai một số tính năng giá trị gia tăng.

Trong chân cuộc gọi ban đầu, B2BUA hoạt động như một máy chủ tác nhân người dùng (UAS) và xử lý yêu cầu như một máy khách tác nhân người dùng (UAC) đến đầu cuối đích, xử lý tín hiệu giữa các điểm cuối liên tiếp.

B2BUA duy trì trạng thái hoàn chỉnh cho các cuộc gọi mà nó xử lý. Mỗi bên của B2BUA hoạt động như một phần tử mạng SIP tiêu chuẩn như được chỉ định trong RFC 3261.

Chức năng của B2BUA

B2BUA cung cấp các chức năng sau:

• Quản lý cuộc gọi (thanh toán, ngắt cuộc gọi tự động, chuyển cuộc gọi, v.v.)

• Kết nối mạng (có lẽ với sự thích ứng với giao thức)

• Ẩn nội bộ mạng (địa chỉ riêng, cấu trúc liên kết mạng, v.v.)

Thông thường, B2BUA cũng được triển khai trong các cổng truyền thông để kết nối các luồng phương tiện để kiểm soát toàn bộ phiên.

Ví dụ về B2BUA

Nhiều hệ thống điện thoại doanh nghiệp tổng đài chi nhánh tư nhân (PBX) kết hợp logic B2BUA.

Một số tường lửa được tích hợp sẵn chức năng ALG (Cổng lớp ứng dụng), cho phép tường lửa cho phép SIP và lưu lượng phương tiện trong khi vẫn duy trì mức độ bảo mật cao.

Một loại B2BUA phổ biến khác được gọi là Bộ điều khiển biên phiên (SBC).