GB28181

序文

GB28181 プロトコルはビデオ監視の分野における国家標準です。この記事では、FFmpeg に GB28181 プロトコルのサポートを追加して、GB28181 プロトコルをサポートするデバイスと通信および制御し、デバイスの登録、保持を実現する方法を分析します。ライブおよびストリーミングメディア送信。

1. 背景の紹介

GB28181 プロトコルは、国家標準 GB/T 28181-2016「公共セキュリティビデオ監視ネットワーキングシステム情報の送信、交換、および制御の技術要件」を指します。

この規格は、公共防犯ビデオ監視ネットワークシステムの相互接続構造、伝送、交換、制御の基本要件とセキュリティ要件、制御、伝送プロセス、プロトコルインターフェースの技術要件を規定した国家標準である。ビデオ監視の分野で。GB28181 プロトコル信号レベルでは、SIP (セッション開始プロトコル) プロトコルが使用されます。
ストリーミングメディア伝送層は、リアルタイムトランスポートプロトコル (RTP) プロトコルを使用します。
したがって、GB28181 は、ビデオ監視ネットワーキングシステムの相互接続と伝送に関する標準化された要件を満たすために、国際一般標準に基づいて民営化およびカスタマイズされていることが理解できます。この記事の目的は、FFmpeg における GB28181 プロトコルのサポートの追加について説明し、GB28181 プロトコルをサポートするデバイスと通信および制御し、デバイスの登録、キープアライブ、ストリーミングメディア送信を実現できるようにすることです。

2.国家標準GB28181プロトコル：シグナリングプロセス

2.1 国家標準 GB28181 協定

GB28181 プロトコルセッションチャネルは実際には SIP プロトコルを使用しており、SIP プロトコルに基づいて一部の民営化が行われています。SIP は、IETF MMUSIC ワーキンググループによって開発され、ビデオ、音声、インスタントメッセージング、オンラインゲーム、仮想現実などの複数のマルチメディア要素を含む対話型ユーザーセッションを作成、変更、終了するための標準として提案されたプロトコルです。

SIP の比較的重要な概念はユーザーエージェント (ユーザーエージェント) です。これは、SIP メッセージを作成、送信、受信し、SIP セッションを管理するための SIP 論理ネットワークエンドポイントを指します。

SIP ユーザーエージェントは、ユーザーエージェントクライアント UAC (User Agent Client) とユーザーエージェントサーバー UAS (User Agent Server) に分けることができます。UAC は SIP 要求を作成して送信し、UAS は SIP 要求を受信して処理し、SIP 応答を送信します。

SIP プロトコルは、SIP メッセージコンテンツを送信するためのセッション記述プロトコル (SDP) など、他の多くのプロトコルと連携して動作します。SDP プロトコルは、使用する IP ポート、どの IP ポート、どの IP ポートを使用するかなど、セッションで使用されるストリーミングメディアの詳細を記述します。デコーダを使用するためのエンコーディングなど。

SIP の一般的な使用法は次のとおりです。SIP セッションはメッセージを通じていくつかの単純なリアルタイムトランスポートプロトコルストリームを送信し、RTP 自体は音声またはビデオのキャリアです。GB28181 プロトコルでは、ネットワークシステムは、ビデオとオーディオの送信と制御を実行するときに、セッションチャネルとメディアストリームチャネルという 2 つの送信チャネルを確立する必要があります。セッションチャネルはデバイス間のセッションを確立し、システム制御コマンドを送信するために使用され、メディアストリームチャネルはビデオおよびオーディオデータを送信するために使用され、圧縮されたビデオおよびオーディオストリームはストリーミングメディアプロトコル RTP/RTCP を使用して送信されます。GB28181 プロトコルにおける具体的な通信プロトコル構造図を次の図 (通信プロトコル構造図) に示します。

詳細については、国家標準 GB28181 要件文書を参照してください: リンク: https://pan.baidu.com/s/1aqlF6mQPNUE4KMIUf3JU8A?pwd=jb6v 抽出コード: jb6v

セッションチャネルでは、SIP プロトコル IETF RFC3261 で規定されている REGISTER や INVITE などの要求メソッドと応答メソッドを使用して、登録、リアルタイムビデオとオーディオオンデマンド、履歴ビデオとオーディオの再生などのアプリケーションのセッション制御が実装されます。 SIP拡張プロトコルIETF RFC29765を利用した履歴映像・音声再生制御と、指定されたINFOメソッドを実装し、フロントエンド機器制御、情報問い合わせ、アラームイベント通知・配信などのアプリケーションのセッション制御をMESSAGEメソッドで実装SIP 拡張プロトコル IETF RFC34287 で指定されています。以下は、登録、キープアライブ、リアルタイムビデオとオーディオオンデマンドの SIP メッセージ構造の詳細な紹介です。

2.2 国家規格 28181:登録

登録とは、デバイスまたはシステムがネットワーク化されたシステムに入るときに、SIP サーバー (SIP UAS) に登録する動作モードを指します。この記事では、FFmpeg は SIP サーバーです。デバイスは FFmpeg に登録要求を送信し、FFmpeg は登録を受け取りますデバイスの要求対応する応答メッセージを返信すると、デバイスの登録処理が完了します。GB28181 プロトコルのデジタルアブストラクトに基づくチャレンジ/レスポンスセキュリティテクノロジの登録プロセスを次の図 (基本的な登録プロセスの概略図) に示します。

詳細については、State Grid の技術要件文書を参照してください。 [付録 B.1 登録] リンク: https://pan.baidu.com/s/1_bn-K2CML_OPxQRO4VDdhQ?pwd=6sb9 抽出コード: 6sb9

GB28181 の実装に関する他の優れた記事については、ホームページの記事を参照してください。

1. GB28181 ストリーミングメディアシリーズの記事

2.最初の章は上位プラットフォームへの登録に関する一連の記事です

3. sip (gb28181) シグナリングインタラクション - ビデオオンデマンドと再生

登録プロセスは次のように説明されています。

SIP プロキシは、SIP サーバーに登録リクエストを送信します。
SIP サーバーは応答 401 を SIP プロキシに送信し、応答メッセージヘッダーの WWW_Authenticate フィールドで SIP プロキシに適した認証システムとパラメータを指定します。
SIP プロキシは REGISTER リクエストを SIP サーバーに再度送信し、リクエストの Authorization フィールドに認証情報を含む信頼レターを与えます。
SIP サーバーはリクエストを検証し、SIP エージェントの ID が正当であることが判明した場合は、成功応答 200 OK を SIP エージェントに送信します。ID が正当でない場合は、サービス拒否応答を送信します。

登録されるリクエストメッセージの内容例は以下のとおりです。

REGISTER sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273
From: sip:34020000001320000003@3402000000;tag=2043466181
To: sip:34020000001320000003@3402000000
Call-ID: 1011047669
CSeq: 1 REGISTER
Contact: sip:[email protected]:5060
Max-Forwards: 70
User-Agent: IP Camera
Expires: 3600
Content-Length: 0

登録要求ヘッダーフィールドのパラメーターは次のように説明されます。

第1行表明这条SIP消息的方法（Method）是REGISTER，34020000002000000001是SIP服务器的国标ID，国标ID指的是由中心编码(8位) 、行业编码(2位) 、类型编码(3位)和序号(7位)四个码段共20位十进制数字字符构成，具体国标ID的编码方法可以参考GB/T 28181—2016中的附录D。3402000000指的是SIP服务器的域国标ID，SIP/2.0指的是SIP协议版本。 
第2行为Via头，Via头中包含了发送请求方的相关信息，后续需要使用这些信息进行回复。SIP/2.0/UDP表示使用的是2.0版本的SIP协议，使用的传输协议是UDP，也可以使用TCP协议。192.168.137.11:5060为请求发送方的IP地址和端口号。Via头中必须包含branch参数，具体值是一个在整个SIP通信过程中不重复的数值。branch是一个事务ID（Transaction ID），用于区分同一个UA所发起的不同Transaction，它不会对未来的request或者是response造成影响，对于遵循IETF RFC3261规范的实现，这个branch参数的值必须用”z9hG4bK”打头. 其它部分是对To， From, Call-ID头域和Request-URI按一定的算法加密后得到。rport字段表示使用rport机制路由响应，即发送的响应时，按照rport中的端口发送SIP响应，也就是说IP和端口均完全遵照从哪里来的，发回哪里去的原则，如果没有rport字段时，服务端的策略是IP使用UDP包中的地址，即从哪里来回哪里去，但是端口使用的是via中的端口，详情见IETF RFC35818。  
第3行为From头，From头中包含了请求发送方的逻辑标识，在GB28181协议中是发送请求的设备国标ID和域国标ID信息。tag参数是为了身份认证的，值为随机数字字符。  
第4行为To头，To头在SIP协议中是为了标明请求接收方的逻辑标识的，在GB28181协议中填写的是发送请求的设备国标ID和域国标ID信息。  
第5行为Call-ID头，Call-ID头是全局唯一的，在同一个session中保持一致，在不同session中不同。  
第6行为CSeq头，CSeq头又叫Command Seqence（命令队列），用于标识命令顺序，值为序号+Method，序号部分为无符号整数，最大值为2^31。序号起始值是随机的，后续在同一个session中依次递增，比如发1 REGISTER没返回--->再发2 REGISTER--->没返回--->再发3 REGISTER--->这时返回了2 REGISTER就知道是第2个请求得到了响应。对于ACK和CANCLE中的CSeq与INVITE中的Cseq保持一致。  
第7行为Contact头，Contact头包含源的URI信息，用来给响应消息直接和源建立连接用。在GB28181协议中为SIP设备编码@源IP地址端口。  
第8行为Max-Forwards头，Max-Forwards头用于设置包最大中转次数，默认是70。  
第9行为User-Agent头，User-Agent头用于设置关于UA的信息，用户可以自定义。  
第10行为Expires头，Expires头表示超时时间。  
第11行为Content-Length头，Content-Length头表示SDP消息的长度，因为REGISTER消息不需要SDP，因此为0。

登録される応答メッセージの内容は以下のとおりであり、各ヘッダ情報の意味は上記の通りです。

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1371463273
From: sip:34020000001320000003@3402000000
To: sip:34020000001320000003@3402000000
CSeq: 1 REGISTER
Call-ID: 1011047669
Contact: sip:[email protected]:5060
User-Agent: FFmpeg GB28181 v1.0
Expires: 3600
Content-Length: 0

2.3 国标28181：保活

UA は、業務の異常を検知した場合には、直ちにステータス情報を SIP 監視ドメイン内の SIP サーバに送信し、異常がない場合には定期的にステータス情報を SIP 監視ドメイン内の SIP サーバに送信する必要がある。ステータス情報レポートは、IETF RFC3427 で定義されているメソッド MESSAGE を使用して実装されます。定期的なステータス情報報告により、登録サーバーとソースデバイス間のステータス検出、つまりハートビート機構が実現されます。

ハートビートの送信者と受信者は、「ハートビート間隔」パラメータを一律に設定し、「ハートビート間隔」に従って定期的にハートビートメッセージを送信する必要があります。デフォルトのハートビート間隔は 60 秒です。ハートビートの送信者と受信者は、「ハートビートタイムアウト時間」パラメータを均一に設定する必要があります。ハートビートメッセージが継続的にタイムアウトし、「ハートビートタイムアウト時間」に達すると、相手はオフラインとみなされます。デフォルトのハートビートタイムアウト時間は 3 回です。ハートビート送信者がオンラインのときに、ハートビートメッセージが合意された回数連続してタイムアウトになったことをハートビート受信者が検出すると、ハートビート送信者はオフラインとみなされ、受信者はオフラインになります。具体的なコマンドフローは次のとおりです (キープアライブコマンドフローチャート)。

コマンドフローは次のように説明されます。

(a) ソース機器は、機器状態情報報告コマンドを SIP サーバに送信します。デバイスステータス情報レポートコマンドは、MESSAGE メソッドによって実行されます。

(b) SIP サーバーはコマンド受信後、200 OK を返します。

キープアライブメッセージの内容の例は次のとおりです。

MESSAGE sip:34020000002000000001@3402000000 SIP/2.0
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804
From: sip:34020000001320000003@3402000000;tag=1925919231
To: sip:34020000002000000001@3402000000
Call-ID: 1185236415
CSeq: 20 MESSAGE
Content-Type: Application/MANSCDP+xml
Max-Forwards: 70
User-Agent: IP Camera
Content-Length: 175

<?xml version="1.0" encoding="UTF-8"?>
<Notify>
<CmdType>Keepalive
<SN>1
<DeviceID>34020000001320000003
<Status>OK
<Info>
</Info>
</Notify>

MESSAGE メッセージの Content-type ヘッダーは、Content-type: Application/MANSCDP+xml です。状態情報報告コマンドは MANSCDP (Monitoring and Alarming Network System Control description Protocol) プロトコル形式定義を採用しており、詳細な説明は「A.2.5 GB/T 28181-2016 における状態情報報告」を参照してください。ステータス情報報告コマンドには、コマンドの種類(CmdType)、デバイス/システムコード(DeviceID)、正常に動作しているかどうか(Status)などが含まれ、MESSAGEメソッドのメッセージボディに組み込まれます。Message メッセージの成功応答とエラー応答にはメッセージ本文がなく、Message 応答メッセージの内容は次のとおりです。

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.137.11:5060;rport;branch=z9hG4bK1066375804
From: sip:34020000001320000003@3402000000
To: sip:34020000002000000001@3402000000
CSeq: 20 MESSAGE
Call-ID: 1185236415
User-Agent: FFmpeg GB28181 v1.0
Content-Length: 0

2.4 国家規格 28181: リアルタイムビデオ再生

ビデオストリーム形式

GB28181 では、送信されるビデオストリームの形式が PS ストリーム、H264 ストリーム、または MP4 形式である必要があります。

Wireshark を使用してパケットをキャプチャでき、データグラムタイプは RTP PS ストリームです

実際には、国家標準のストリーミングメディアサーバーは、GB28181 デバイスまたはプラットフォームによってプッシュされた PS ストリームを ES ストリームに変換し、配信用に RTSP、RTMP、FLV、HLS などの形式を提供する役割を果たします。

PSストリームとESストリームの違い

P データグラムは、ヘッダーとデータ、およびヘッダーの前の部分の 2 つの部分で構成されます。

分は 20 バイトの固定長で、すべての IP データグラムに必須です。ヘッダーには、全長、ロゴ、MF、DF、スライスオフセットが含まれます。

デジタル信号が実際に伝送するものはデータストリームであり、一般的なデータストリームには次の 3 種類があります。

ES ストリーム (エレメンタリーストリーム): エレメンタリーストリームとも呼ばれ、ビデオ、オーディオ、またはデータの連続ストリームが含まれます。
PESストリーム（パケットエレメンタリーストリーム）：パッケージ化された基本コードストリームとも呼ばれ、必要に応じて基本コードストリームESストリームを異なる長さのデータパケットに分割し、パケットヘッダを追加してパッケージ化された基本コードストリームPESストリームを形成します。
TS ストリーム: トランスポートストリームとも呼ばれ、188 バイトの固定長のパケットで構成され、独立したタイムベースを持つ 1 つ以上のプログラムが含まれます。プログラムには、複数のビデオ、オーディオ、およびテキスト情報の ES ストリームを含めることもできます。各 ES ストリームこれらの ES ストリームを分析するために、TS はプログラムと ES ストリーム情報テーブル (PAT テーブルと PMT テーブル) を一定間隔で送信するためのいくつかの固定 PID を持っています。ビットエラーが多い環境に最適

ES はエンコーダから直接のデータストリームであり、エンコードされたビデオデータストリーム、オーディオデータストリーム、またはその他のエンコードされたデータストリームにすることができます。ESストリームはPESパッケージャーを通過した後、PESパッケージに変換され、RTSP、RTMP、FLV、HLS形式で配信され、WEB、携帯電話、PC、WeChatなどの多端末ブロードキャストを実現します。

伝播モード

GBT28181 プロトコルでは、コードストリームは RTP パケットロードを使用することが規定されており、PS ストリームまたは ES ストリームが推奨されており、メディアストリームの送信には、元の UDP 送信をベースにアクティブ tcp 方式とパッシブ tcp 方式が追加されています。

UDPパッシブ

これは一般的な送信方法です。GB28181 ストリーミングメディアサーバーは、単一の UDP ポートをリッスンし、SIP シグナリング (INVITE) を送信します。それに含まれる SDP には、メディアを受信するポートが含まれています。サーバーがリッスンするポートでビデオストリームを送信します。

TCPパッシブ

アクティブとパッシブの2種類があります

アクティブ: デバイスはサーバーに独自のメディアストリーム TCP ポートを通知し、サーバーはデバイス上のポートにアクティブに接続してデータを取得します。。このシナリオはめったに使用されないため、無視してかまいません

パッシブの場合: ストリーミングメディアサーバーは単一の TCP ポートをリッスンし、SIP シグナリング (INVITE) を通じてデバイスポートに通知し、デバイスは現在のストリーミングメディアサーバーにビデオストリームをアクティブに送信します。これは基本的に UDP ストリームと同等です。

ライブビデオプロセス

前提条件: 登録が成功した >>>>>> ハートビートが成功した >>>>>> デバイスカタログクエリ >>>>> リアルタイムビデオ表示

サーバーの手順

TCP または UDP のどちらで表示されるかに関係なく、手順は次のとおりです:
(1) ビデオポートを開きます
(2) リアルタイムビデオ要求を送信します
(3) デバイスが 200OK を応答するのを待ちます
(4) ACK を送信します
(5)コードストリームを再生します
(6) ビデオ要求を停止します
(7) ビデオポートを閉じます
(8) 通常の待機

パケット解析

テスト機器 IP: 192.168.0.9 (Hikang NVR 機器)
サーバー IP: 192.168.0.28 (ローカル IP)

リアルタイムビデオ作成_UDP

ステップ 0: [サーバー] ビデオポートを開きます

ステップ 1: [サーバー >> クライアント] ビデオの再生リクエスト

INVITE sip:34020000001310000002@4401020049 SIP/2.0
Call-ID: helloVideo
CSeq: 1 INVITE
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>
Max-Forwards: 70
Contact: <sip:34020000001310000002@4401020049>
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
Content-Type: application/sdp
Content-Length: 225

v=0
o=34020000001310000002 0 0 IN IP4 192.168.0.60
s=Play
c=IN IP4 192.168.0.60
t=0 0
m=video 6000 RTP/AVP 96 98 97
a=recvonly
a=rtpmap:96 PS/90000
a=rtpmap:98 H264/90000
a=rtpmap:97 MPEG4/90000
y=0100000001
f=

ステップ 2: [クライアント >> サーバー]

まずは 100 まで返信してください

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>;tag=5f906952
Call-ID: helloVideo
CSeq: 1 INVITE
Server: Happytime Agent Ver 1.0
Content-Length: 0

返信200

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-bff9-4f3000002
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>;tag=5f906952
Contact: <sip:34020000001110000001@4401020049>
Call-ID: helloVideo
CSeq: 1 INVITE
Max-Forwards: 70
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,UPDATE,INFO
Supported: timer
Session-Expires: 200;refresher=uac
Server: Happytime Agent Ver 1.0
Content-Type: application/sdp
Content-Length: 153

v=0
o=34020000001110000001 0 0 IN IP4 192.168.0.107
s=Play
c=IN IP4 192.168.0.107
t=0 0
m=video 19002 RTP/AVP 96
a=rtpmap:96 PS/90000
a=sendonly

ステップ 3: [サーバー>>クライアント] ACK を応答する

ACK sip:34020000001310000002@4401020049 SIP/2.0
Call-ID: helloVideo
CSeq: 1 ACK
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: <sip:34020000001110000001@4401020049>
Max-Forwards: 70
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00003
Content-Length: 0

ステップ 4: コードストリームを再生する

ステップ 5: [サーバー >> クライアント] ビデオ要求を停止します。

BYE sip:34020000001310000002@4401020049 SIP/2.0
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: sip:34020000001110000001@4401020049;tag=5f906952
CSeq: 2 BYE
Call-ID: helloVideo
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004
Max-Forwards: 70
Content-Length: 0

ステップ 6: [クライアント] 応答 200

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.107:5060;branch=z9hG4bKee5c5d98-00004
From: <sip:44010200492000000001@4401020049>;tag=bccedfd0111
To: sip:34020000001110000001@4401020049;tag=5f906952
Call-ID: helloVideo
CSeq: 2 BYE
Server: Happytime Agent Ver 1.0
Content-Length: 0

ステップ 7: [サーバー] ビデオポートを閉じる

3.SIPプロトコル

SIP（セッション初期化プロトコル、Session Initiation Protocol）は、IETF（Internet Engineering Task Force、インターネットエンジニアリング特別委員会）によって策定されたマルチメディア通信プロトコルです。

これは、1 人以上の参加者とのセッションを作成、変更、解放するためのテキストベースのアプリケーション層制御プロトコルです。SIP はインターネット由来の IP 音声セッション制御プロトコルであり、柔軟性が高く、実装が容易で、拡張も容易です。SIP (セッション開始プロトコル) は、http プロトコルに似たプレーンテキストのアプリケーション層プロトコルです。SIP を使用して、セッションの確立、キャンセル、終了などの操作を制御できます。主に以下の機能が実現できます。

ユーザーの位置:通信するエンドユーザーの位置を確認します。
ユーザーの有効性:ユーザーがセッションに参加する意欲をチェックします。
ユーザー機能:メディアとメディアパラメータを確認します。
セッションの確立：「Ring」、発信側と着信側で同時にセッションを確立するためのパラメータ。
セッション管理:セッションの送信と終了、セッションパラメータの変更、サービスの要求など

現在、関連する機器サプライヤーとビジネスサプライヤーは共同で SIP に関するフォーラムhttp://www.sipforum.orgを設立し、SIP 開発のための自由な議論と新しい考え方のための開発プラットフォームを提供しています。

3.1 概念の説明

3.1.1 SIPリクエスト

リクエストは SIP の最も基本的な概念の 1 つであり、SIP に関するすべての操作ではリクエストを送信する必要があります。

3.1.2 SIP 応答

SIP では通常、応答と要求はペアで表示され、応答の内容はピア側で要求を処理した結果です。

3.1.3 トランザクション

SIP プロトコルはトランザクションプロトコルです。トランザクションの概念はリクエストとリプライに基づいており、リクエストとそれに関連する最終リプライがトランザクションを構成します。(ACKの処理は含まない) 通話の確立から終了までの過程で複数のトランザクションが存在するため、トランザクションを一意にマークする必要がある SIPではブランチパラメータでトランザクションを一意にマークする

3.1.4 TU

トランザクションという概念があった後、トランザクションをベースにしてトランザクションを管理できるトランザクションユーザーという概念が登場しました。

3.1.5 クライアントトランザクションとサーバートランザクション

トランザクションの概念では、リクエストとリプライの違いとしてクライアントトランザクションとサーバートランザクションが登場します。CT はリクエストの開始者が所有するトランザクション部分を指し、ST はリクエストの受信者が所有する部分を指します。

3.1.6 ユーザーエージェントUA（ユーザーエージェント）

UA はユーザーエンティティを指します。

3.1.7 UAC および UAS ユーザーエージェントサーバー (ユーザーエージェントサーバー)

実際にリクエストを開始するユーザーエンティティは UAC であり、処理リクエストを実際に受信するユーザーエンティティは UAS です。

3.1.8 招待

特別なリクエスト。SIP プロトコルで最も重要なリクエスト。セッションを開始するために使用されます。

3.1.9 セッション

セッションは、対応する INVITE リクエストの 2xx レスポンスを受信した後に確立されます。次の INVITE リクエストの 2xx レスポンスは送受信後に変更されますので、終了するには bye リクエストを送受信するしかありません。

3.2.0ダイアログ

ダイアログの概念はセッションの概念と似ていますが、ダイアログがシグナリング対話の概念であるのに対し、セッションは実際のメディアの送受信プロセスを記述する点が異なります。ダイアログの確立時間もシグナリングの 200 OK リプライ受信後であり、終了も Bye リクエストの送受信後です。

3.2 SIPの構造

SIP プロトコルには主に、UA、プロキシサーバー、登録/ロケーションサーバー、およびリダイレクトサーバーの論理的な役割が含まれています。

UA:ユーザーエージェント (User Agent) は、http プロトコルにおけるブラウザの役割に似ています。ユーザーが操作する端末インターフェイスです。ユーザーエージェントは、SIP プロトコルの要件を満たす必要がありますが、それに応じて他のプロトコルと組み合わせられます。アプリケーションシナリオが異なれば、実装ロジックも異なります。例えば、SIP プロトコルと H.323VoIP プロトコルを組み合わせることで、ソフトウェアフォン機能を実現できます。ユーザーエージェントは、UAC (UA Client) と UAS (UA Server) の 2 つの論理エンティティに分かれており、UAC は SIP リクエストを送信してレスポンスを受信し、UAS は SIP リクエストを受信してレスポンスを返します。物理デバイスは UAC と UAS の両方になることができます。
プロキシサーバー:プロキシサーバーの役割は主に、リクエストとレスポンスを他のプロキシサーバーまたは UA に転送することです。プロキシサーバーはステートフルプロキシとステートレスプロキシに分けられます。前者は通信トランザクションを保持します。転送動作は有限状態によって制御されます。後者は状態を保存せず、透過的な転送操作のみを実現します。
登録/ロケーションサーバー:登録およびロケーションサーバーは、UA の登録と位置特定に使用されます。オンライン UA は、定期的に SIP メッセージを登録サーバーに送信して、UA の現在の位置 (IP アドレス、ポート番号など) を示します。）、登録サーバーはデータベース（またはハッシュテーブル）に保存されている情報を送信し、他のUAがそのUAにリクエストを送信すると、そのUAの位置を取得できます。
リダイレクトサーバー:リダイレクトに使用され、特別な機能を持つ UA と論理的に同等です。

3.3 SIP方式

SIP の REQUEST では、INVITE、ACK、BYE、CANCEL、OPTIONS、REGISTER の 6 つのコアメソッドが定義されています。

INVITE メッセージは、新しいセッションを開始するために使用されます。
ACK メッセージは、セッションの確立を完了するために使用されます。
BYE メッセージはセッションを終了するために使用されます。
CANCEL メッセージは、リクエスト (通常は INVITE) をキャンセルするために使用されます。
OPTIONS メッセージは、サーバーの機能を問い合わせるために使用されます。
REGISTER メッセージは、登録要求メッセージを送信するために使用されます。

SIP リクエストのタイプ。SIP メソッドとも呼ばれます。RFC3261では6つのメソッドが定義されています。他の 8 つのメソッドには、独立した RFC 拡張記述があります。INFO、NOTIFYなど。

各メソッドの意味については、SIPリクエストメソッドを参照してください。

SIP 開発マニュアルに移動することもできます: リンク: https://pan.baidu.com/s/1GFCHYqumPrd5ORhyCfJAew?pwd=yxj1 抽出コード: yxj1

3.4 SIPプロトコルフォーマット

SIP メッセージは [ISO 10646] テキストでエンコードされ、要求メッセージと応答メッセージの 2 つのカテゴリに分類されます。

リクエストメッセージ: 特定の操作をアクティブにするためにクライアントからサーバーに送信される SIP メッセージ。

応答メッセージ: 要求メッセージに応答するために使用され、通話の成功または失敗のステータスを示します。

各 SIP メッセージは、スタートライン (Start Line)/ステータスライン (Status-Line)、SIP ヘッダー、メッセージボディの 3 つの部分で構成され、要求メッセージと応答メッセージの両方に SIP ヘッダーフィールドと SIP メッセージフィールドが含まれます。

スタートライン/ステータスライン

各 SIP メッセージは開始行で始まります。開始行は、メッセージタイプ (リクエストのメソッドタイプ、レスポンスの応答コード) とプロトコルのバージョンを伝えます。開始行はリクエスト行 (リクエスト) またはステータス行 (応答) です。

リクエストメッセージ

リクエストメッセージの全体的な形式は次のとおりです。

その中には、開始行の形式があります。命令名称+目标URI+sip协议版本

リクエストメッセージには次のリクエストコマンドが含まれます。

応答メッセージ

応答メッセージの初期動作はステータス行 (Status-Line) であり、ステータス行はプロトコルバージョン、ステータスコード、ステータス理由句で構成され、各部分はスペース文字で区切られます。ステータスコードについては以下で説明します。

SIP プロトコルでは 6 種類のステータスコードが定義されており、ステータスコードの最初の 1 桁は応答の種類を示し、最後の 2 桁は特定の応答を示します。以下では、「1xx」を使用して、「100 ～ 199」のステータスコードを持つ応答を識別します。

1xx: 暫定応答。要求メッセージが処理中であることを示します。
2xx: 成功応答。要求が正常に受信され、完全に理解され、受け入れられたことを示します。
3xx: リダイレクト応答。要求を完了するにはさらなる手順が必要であることを示します。
4xx: クライアントエラー。要求メッセージに構文エラー情報が含まれているか、サーバーがクライアント要求を完了できないことを示します。
5xx: サーバーエラー。サーバーが正当なリクエストを完了できないことを示します。
6xx: グローバル障害。どのサーバーもリクエストを完了できないことを示します。

応答メッセージの全体的な形式は次のとおりです。

その中には、開始行の形式があります。sip协议版本+响应返回码+描述性短句

応答メッセージは 100 ～ 699 のリターンコードであり、それぞれ意味が異なります。

メッセージのリターンコードを表示できます: SIP プロトコル形式

SIPヘッダー

SIP ヘッダーフィールドの詳細については、https: //blog.csdn.net/qui910/article/details/122683453を参照してください。

これは、メッセージのプロパティを転送し、メッセージの意味を変更するために使用されます。これらは、構文的にも意味的にも HTTP ヘッダーフィールドと同一であり (実際、一部のヘッダーは HTTP から借用されています)、常に <name>:<value> の形式を維持します。

例：

次の表は、SIP ヘッダー形式のさまざまな Key 値を説明しています。これらは、General 一般ヘッダーフィールド、Request リクエストヘッダーフィールド、Response レスポンスヘッダーフィールド、Entity エンティティフィールドの 4 つのカテゴリに大別できます。

全般的	リクエスト	応答	実在物
受け入れる	認可	許可する	コンテンツエンコーディング
エンコーディングの受け入れ	コンタクト	プロキシ認証	コンテンツの長さ
受け入れ言語	再試行後の非表示	コンテンツタイプ
コールID	マックスフォワード	サーバ
コンタクト	組織	サポートされていません
シーク	優先順位	警告
日にち	代理承認	WWW認証
暗号化	プロキシが必要
有効期限が切れます	ルート
から	必須
レコードルート	応答キー
タイムスタンプ	主題
に	ユーザーエージェント
経由

詳細については、「SIP プロトコル-04 SIP ヘッダーフィールド」を参照してください。

メッセージ本文

開始されるセッションを記述するために使用されます (たとえば、オーディオおよびビデオのエンコードタイプ、サンプリングレートなどを含むマルチメディアセッションで)。メッセージ本文はリクエストとレスポンスに表示できます。

SIP は、SIP 開始行およびヘッダーで伝達されるシグナリング情報を、SIP の範囲外のセッション記述情報から明確に区別します。考えられるメッセージ本文の種類には、この記事で説明されている SDP セッション記述プロトコルと XML ベースのメッセージ本文が含まれます。

4. SDP協定

SDP の正式名は Session description Protocol で、翻訳するとセッションを記述するプロトコルになります。これは主に 2 つのセッションエンティティ間のメディアネゴシエーションに使用されます。

SDP の説明は多くのテキスト行で構成され、テキスト行の形式は <type>=<value> で、key=value として表されます。

SIP はセッションの確立と解放を担当し、通常、セッションにはビデオやオーディオなどの関連メディアが含まれます。メディアデータはSDPで記述されます。SDP は通常、単独で使用されません。SIP と組み合わせて使用される場合は、SIP プロトコルの本体に組み込まれます。セッションが確立されると、双方が互いのメディア機能を決定し、メディアデータを交換できるように、メディアネゴシエーションが必要になります (これは SDP の仕事です)。

では、なぜこの説明文を送信するのでしょうか? 主に、会話に参加しているメンバー間の能力の不平等の問題を解決するためです。この通話に参加しているメンバーが高品質の通話をサポートしているが、合意はされていない場合、互換性セックスのために、それらはすべて通常品質の通話形式を使用しており、リソースの無駄です。したがって、SDPの役割は依然として非常に必要です。

SIP プロトコルに含まれるコンテンツが SDP の場合、Content-Type は application/sdp に設定する必要があります。SDP プロトコルは RFC4566 でリリースされました。

例：

4.1 SDP の概要

SDP は、Session description Protocol の略称で、ストリーミングメディアの初期化パラメータを記述するための形式であり、IETF によって RFC 4566 として公布されています。ストリーミングメディアとは、送信中に見たり聞いたりするものを指し、SDP パケットには通常、次の情報が含まれます。

セッション情報

セッション名と目的。
セッションのアクティブ時間。

セッションに参加するためのリソースは限られているため、次の追加情報を含めると便利です。

セッションで使用される帯域幅情報。
セッションリーダーの連絡先情報。

メディア情報

ビデオやオーディオなどのメディアの種類。
RTP/UDP/IP や H.320 などのトランスポートプロトコル。
H.261 ビデオや MPEG ビデオなどのメディア形式。
マルチキャストアドレスとメディアトランスポートポート (IP マルチキャストセッション)。
メディアのリモートアドレスと、そのアドレスに接続するために使用されるトランスポートポート (IP ユニキャストセッション)。

SDP 記述は多くのテキスト行で構成され、その形式は <type>=<value> です。<type> は文字、<value> は <type> に依存する形式の構造化テキスト文字列です。「=」の両側にスペースを使用することはできません。また、値内の複数のパラメータはスペースで区切られます。

4.2 SDPプロトコルフォーマット

SDP セッション記述は、セッションレベルの記述 (session_level 記述) と複数のメディアレベルの記述 (media_level 記述) で構成されます。セッションレベル (session_level) のスコープはセッション全体です。その位置は、「v=」行から最初のメディア記述までです。メディアレベル (media_level) の説明は、単一のメディアストリームの説明です (たとえば、単一のオーディオまたはビデオを送信する vlc sdp ファイルには、m= で始まる短い文がいくつか含まれているだけですが、これは実際にはメディアの説明です) machine)、その場所は「m=」行から次のメディア記述までです。つまり、メディア部分がオーバーロードされない限り、セッションレベルの値は各メディアのデフォルトのデフォルト値になります（つまり、メディアレベルの説明は実際にはセッションレベルの説明ですが、セッションレベルの説明パラメータは、書き出されず、デフォルト値が使用されます)。

詳細は「SDPフォーマットの詳しい解説」を参照してください。

v= （协议版本）
o= （所有者/创建者和会话标识符）
s= （会话名称）
i=* （会话信息）
u=* （URI 描述）
e=* （Email 地址）
p=* （电话号码）
c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b=* （带宽信息）
一个或更多时间描述（如下所示）：

z=* （时间区域调整）
k=* （加密密钥）
a=* （0个或多个会话属性线路）
0个或多个媒体描述（如下所示）
时间描述

t= （会话活动时间）
r=* （0或多次重复次数）
媒体描述

m= （媒体名称和传输地址）
i=* （媒体标题）
c=* （连接信息 — 如果包含在会话层则该字段可选）
b=* （带宽信息）
k=* （加密密钥）
a=* （0个或多个会话属性线路）

4.3 SDPインスタンス

# 请求视频流
INVITE sip:[email protected]:7100 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>
Call-ID: 821763613                // Call-ID：使用该字段标识一路视频
CSeq: 20 INVITE
Contact: <sip:[email protected]:7100>
Content-Type: Application/SDP
Max-Forwards: 70
User-Agent: NCG V2.6.0.299938
Subject: 00000000001310018021:0,120105110228023020:0
Content-Length:   239

v=0
o=00000000001310018021 0 0 IN IP4 192.168.40.55
s=Play                        //Play标识为点播请求   Playback标识回播请求
c=IN IP4 192.168.40.55            //192.168.40.55:音视频流目的地址
t=0 0                        //t行第一参数为视频开始时间  第二个参数为结束时间    t = 0 0表示实时视音频点播
m=video 5552 RTP/AVP 96 97 98   //video:表示请求音视频流  audio：表示请求音频流  5522:音视频流目的端口  RTP/AVP:视频流使用协议 96 97 98:客户端支持码流格式
a=rtpmap:96 PS/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly
a=streamMode:MAIN
y=0999999999

# 返回100 trying
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>
Call-ID: 821763613
CSeq: 20 INVITE
User-Agent: NCG V2.6.0.299938
Content-Length: 0

# 携带sdp返回 200
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.40.55:7100;rport=7100;branch=z9hG4bK2480933505
From: <sip:[email protected]:7100>;tag=2249831759
To: <sip:[email protected]:7100>;tag=2885333649
Call-ID: 821763613
CSeq: 20 INVITE
Contact: <sip:[email protected]:7100>
Content-Type: Application/SDP
User-Agent: NCG V2.6.0.299938
Content-Length:   165

v=0
o=00000000001310018021 0 0 IN IP4 192.168.40.55
s=Play                
c=IN IP4 192.168.40.66    //192.168.40.66:音视频流源地址      注：视音频源与目的地址不局限于级联服务器本身
t=0 0
m=video 5268 RTP/AVP 96     // video:表示请求视频流  audio：表示请求音频流  5268:音视频流源端口  RTP/AVP:视频流使用协议 96:服务端所选择的码流格式   音视频所使用端口统一使用偶数端口   port+1为rtcp端口
a=rtpmap:96 PS/90000
a=sendonly
y=0100005268

SDP字段说明：

v字段：协议版本
o字段：-
a字段：a=rtpmap:<payload type> <encoding name>/<clock rate>  [/<encoding parameters>] 中的<encoding name>,利用该属性携带编码器厂商名称。该属性表明该流为某厂商编码器编码且是不符合gb28181规定的媒体流，符合国标的媒体流不需要该属性。
例如：a=rtpmap:96 DAHUA/90000
    a=rtpmap:96 HIKVISION/90000
a字段有下列格式：
a字段可携带倍数参数，用于文件下载时控制下载速度。格式： a=downloadspeed：下载倍数（整型）
a字段可携带文件大小参数，用于文件下载时的进度计算。格式： a=filesize:文件大小 （单位：Byte）
a字段可携带setup、connection作为TCP连接协商参数。 a=setup：TCP连接方式（表示本SDP发送者在建立RTP over TCP连接时是主动还是被动发起TCP连接，“active”为主动，“passive”为被动）
a字段可携带SVC参数，用于视频传输时的分辨率或者帧频控制。a=svcspace：空域编码方式 【取值整型。 0：不使用  1：1级增强  2：2级增强  3：3级增强 】  a = svctime：时域编码方式

s字段：表示请求媒体流的操作类型，“Play”标识为点播请求   “Playback”标识回播请求   “Download”表示文件下载  “Talk”表示语音对讲；
u字段：u行应填写视音频文件的URL。该URL的取值有两种：简捷方式和普通方式。简捷方式直接采用产生该历史媒体的媒体源（如某个摄像头）的设备ID以及相关参数，参数用“：”分隔；普通方式采样http://储存设备ID[/文件夹]*/文件名；
m字段：描述媒体的媒体类型、端口、传输层协议、负载类型等内容。媒体类型采样“video”标识视频或者视音频混合内容，采样“audio”标识传输音频内容；传输方式采用“RTP/AVP”标识传输层协议为 RTP over UDP，采用“TCP/RTP/AVP”标识传输层协议为RTP over TCP；
t字段：当回放或者下载时，t行值为开始时间，结束时间，采样“ ”分隔；
y字段：十进制整数字符串，标识SSRC值。其中第一位为历史或者实时媒体流的标识位，0为实时，1为历史；第2位到第6位取20位SIP监控域ID之中的4-8位作为域标识；第7-10位作为域内媒体流标识，是一个与当前域内产生的媒体流SSRC值后4位不充分的四位十进制整数；
f字段：f=v/编码格式/分辨率/帧率/码率类型/码率大小  a/编码格式/码率大小/采样率    其中v表示video   a表示audio

5. シグナリングサービス、ストリーミングメディアサービス参照アドレス

シグナリングサービス: https://github.com/648540858/wvp-GB28181-pro

ストリーミングメディアサービス: GitHub - ZLMediaKit/ZLMediaKit: WebRTC/RTSP/RTMP/HTTP/HLS/HTTP-FLV/WebSocket-FLV/HTTP-TS/HTTP-fMP4/WebSocket-TS/WebSocket-fMP4/GB28181/SRT サーバーおよびクライアントC++11ベースのフレームワーク

参考文献_

[1] GB/T 28181—2016. セキュリティおよび予防ビデオ監視ネットワークシステムの情報送信、交換、および制御の技術要件 [D]. 、2016。

[2] Rosenberg J、Schulzrinne H、Camarillo G、他。RFC3261: SIP: セッション開始プロトコル[J]。2002年。

[3] Casner S、Frederick R、Jacobson V、他。RFC 3550、RTP: リアルタイムアプリケーションのためのトランスポートプロトコル[J]。ネットワークワーキンググループ、2003 年。

[4] Handley M、Jacobson V、Perkins C. RFC 4566: SDP: セッション記述プロトコル [J]。2006年。

[5] Donovan S. IETF RFC 2976 SIP INFO メソッド[J]。2000年。

[6] RFC3428 I. インスタントメッセージング用の SIP 拡張 [J]。2002年。

[7] Rosenberg J、Schulzrinne H. IETF RFC 3581[J]。セッション開始の拡張、2003 年。

[8] Rec IH 222.0| ISO/IEC 13818-1: 2000[J]。情報技術 - 動画および関連オーディオの一般的なコーディング - パート、1.

[9] ホフマン D、フェルナンド G、ゴヤル V、他。RFC2250: MPEG1/MPEG2 ビデオの RTP ペイロード形式[J]。1998年。

序文