crosstyan/srs-spi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: enhance README with detailed explanation of SIP and SDP architecture
Some checks failed
CodeQL / Analyze Go Code (go) (push) Has been cancelled
Details

Browse Source
This commit is contained in:
crosstyan
2026-01-13 15:06:52 +08:00
parent ff4ddfacba
commit e80164f5be
1 changed files with 65 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
README_cross.md
View File

@ -11,3 +11,68 @@ docker compose up -d --force-recreate
# TODO
- [ ] 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.