docs: enhance README with detailed explanation of SIP and SDP architecture
Some checks failed
CodeQL / Analyze Go Code (go) (push) Has been cancelled
Some checks failed
CodeQL / Analyze Go Code (go) (push) Has been cancelled
This commit is contained in:
@ -11,3 +11,68 @@ docker compose up -d --force-recreate
|
|||||||
# TODO
|
# TODO
|
||||||
|
|
||||||
- [ ] let user choose whether use mirror (use which mirror) when building Dockerfile
|
- [ ] let user choose whether use mirror (use which mirror) when building Dockerfile
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Based on the logs and the **GB/T 28181-2022** standard you provided, here is the explanation:
|
||||||
|
|
||||||
|
Yes, this is **SIP**, but the content *inside* the SIP message is **SDP (Session Description Protocol)**.
|
||||||
|
|
||||||
|
While XML is used for *control* (like PTZ), **SDP** is used for **Media Negotiation** (setting up the video stream).
|
||||||
|
|
||||||
|
### The Architecture from your logs
|
||||||
|
1. **SIP (The Envelope):** Starts the conversation ("I want to watch video").
|
||||||
|
2. **SDP (The Letter inside):** Describes technical details ("Send video to IP X, Port Y, using Format Z").
|
||||||
|
3. **RTP (The result):** After this SIP/SDP handshake finishes, the actual binary video stream (PS/H.264) starts flowing over a separate TCP/UDP connection.
|
||||||
|
|
||||||
|
### Breakdown of your Log
|
||||||
|
This log shows a **Real-time Live View** handshake.
|
||||||
|
|
||||||
|
#### 1. The Request (SRS Server -> Camera)
|
||||||
|
The Server asks the Camera to send video.
|
||||||
|
|
||||||
|
```ini
|
||||||
|
INVITE sip:34020000001320000001@3402000000 SIP/2.0
|
||||||
|
Content-Type: application/sdp
|
||||||
|
|
||||||
|
s=Play # "Play" = Real-time Live View (Standard 9.2.2.1)
|
||||||
|
c=IN IP4 192.168.2.184 # The Media Server IP
|
||||||
|
m=video 9000 TCP/RTP/AVP 96 # "Send video to my Port 9000 via TCP"
|
||||||
|
a=recvonly # "I will only receive, not send"
|
||||||
|
y=0911024252 # **GB/T 28181 Special**: The SSRC (Stream ID)
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. The Response (Camera -> SRS Server)
|
||||||
|
The Camera agrees and tells the server its own details.
|
||||||
|
|
||||||
|
```ini
|
||||||
|
SIP/2.0 200 OK
|
||||||
|
Content-Type: application/sdp
|
||||||
|
|
||||||
|
c=IN IP4 192.168.2.64 # The Camera IP
|
||||||
|
m=video 15060 TCP/RTP/AVP 96 # "I am sending from Port 15060"
|
||||||
|
a=sendonly # "I will only send"
|
||||||
|
a=setup:active # "I will initiate the TCP connection to you"
|
||||||
|
y=0911024252 # Matches the SSRC provided
|
||||||
|
f=v/2/2560x1440/25/2/8192a/... # **GB/T 28181 Special**: Media Info
|
||||||
|
```
|
||||||
|
|
||||||
|
### Key Differences from Standard SDP
|
||||||
|
GB/T 28181 modifies standard SDP with two specific fields mandatory for this protocol:
|
||||||
|
|
||||||
|
1. **`y=` (SSRC)**:
|
||||||
|
* **Standard SDP:** Does not have a `y` line.
|
||||||
|
* **GB/T 28181:** Uses `y` to define the **SSRC** (Synchronization Source). This 10-digit number is crucial because it marks every binary video packet sent later. If the binary stream headers don't match this `y` value, the stream is rejected.
|
||||||
|
|
||||||
|
2. **`f=` (Media Info)**:
|
||||||
|
* **Standard SDP:** Does not have an `f` line.
|
||||||
|
* **GB/T 28181:** Uses `f` to describe video parameters. In your log: `v/2/2560x1440/25...` means:
|
||||||
|
* `v`: Video
|
||||||
|
* `2`: Coding format (likely H.264 or H.265 mapped)
|
||||||
|
* `2560x1440`: Resolution
|
||||||
|
* `25`: Frame rate
|
||||||
|
|
||||||
|
### Summary of Cooperation
|
||||||
|
1. **XML (SIP MESSAGE):** Used for "remote control" (PTZ, Query, Keepalive).
|
||||||
|
2. **SDP (SIP INVITE):** Used to *negotiate* the pipeline.
|
||||||
|
3. **Binary (RTP/PS):** The actual heavy video data that flows through the pipe created by the SDP.
|
||||||
|
|||||||
Reference in New Issue
Block a user