gb28181点播流程中INVITE消息需要注意的点

1. Content-Length必须正确，否则设备会报415。

2. sip 服务器给设备发 INVITE 消息时，sdp 携带的是媒体服务器的能力描述，正确的报文示例如下

INVITE sip:{camera_id}@3402000000:{local_port} SIP/2.0 Via: SIP/2.0/TCP {local_ip}:{local_port};rport;branch={branch} From: <sip:{client_id}@3402000000>;tag={from_tag} To: <sip:{camera_id}@3402000000> Call-ID: {random.randint(0,1<<31)}@{local_ip} CSeq: {cseq} INVITE Contact: <sip:{client_id}@{local_ip}:{local_port}> Content-Type: application/sdp Max-Forwards: 70 Subject: {camera_id}:0,{client_id}:0 Content-Length: {sdp_len} v=0 o=34020000002000000001 0 0 IN IP4 123.57.58.166 s=Play c=IN IP4 123.57.58.166 t=0 0 m=video 9000 TCP/RTP/AVP 96 a=recvonly a=setup:passive a=connection:new a=rtpmap:96 PS/90000 a=fmtp:96 profile-level-id=420028;packetization-mode=1 y=0000000001 f=

其中,a=recvonly,a=setup:passive,a=connection:new,这几个字段是需要注意的,不要写错,这几个字段的值都是因为描述的是媒体服务器要做的事才这么写的,服务器是收流，所以写 recvonly，如果是设备，应该是 sendonly，然后服务器是等待设备连接的，所以是 passive，如果是设备，那么 应该是 active，connection:new设备可以没有。

3. 给设备回 ACK 时，to_tag、call_id,要照抄设备回的200里的消息的。

4. sip 服务器给设备发 invite，设备回的200消息，from 和 to 是原样保留的，不会颠倒，而如果是设备新发的消息，比如 BYE，那么 from是设备，to 是 sip 服务器。

5. 由于我也是第一次接触网络媒体协议方面的开发，不是特别熟悉，所以经常咨询AI，但貌似 AI 对具体细节有时也把握不好，导致一会这样说，一会又那样说，把我也搞蒙了，所以当发现 AI 自我矛盾的时候，就可以先把它放一边了，说明它也不是很懂，所以会一本正经的胡说八道。