SIP 到 WebRTC 呼叫。 SIP sdp body/message 内容异常
SIP to WebRTC call. SIP sdp body/message content anomalies
所以，下面是我从 x.x.x.x (webRTC) 从 y.y.y.y 调用时得到的响应（啜）。呼叫建立，但是只有视频而不是音频，具有 100% 的一致性。
我的问题是有谁知道 body 中的最后两个 sdp headers 是什么意思？为什么 x.x.x.x 最初会使用正确的端口和可用的编解码器进行响应，但随后又提出相反的建议：
"m=视频 0 RTP/AVP
m=应用程序 0 RTP/AVP"
任何帮助将不胜感激:)
出价：
2015-04-20 18:54:32,291 : Inbound Message
Transport: TCP: ip=x.x.x.x, port=60118, secure=false
INVITE sip:1234@x.x.x.x SIP/2.0
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11
To: <sip:1234@x.x.x.x>
Contact: <sip:2312@y.y.y.y;transport=tcp>
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y
CSeq: 1 INVITE
Supported: timer,sip-stun,outbound,replaces
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY,UPDATE,MESSAGE
Max-Forwards: 69
User-Agent: M
X-FS-Support: update_display
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
MSS_Initial_Remote_Addr: y.y.y.y
MSS_Initial_Remote_Port: 49528
MSS_Initial_Remote_Transport: tcp
Content-Length: 1304
v=0
o=Magor 1429539042 1429539044 IN IP4 y.y.y.y
s=Magor
c=IN IP4 y.y.y.y
b=TIAS:2048000
b=AS:2048
b=CT:2048
t=0 0
m=audio 20052 RTP/AVP 115 9 120 6 70 0 8 99 97 112 101
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:120 SILK/24000
a=fmtp:120 useinbandfec=1; usedtx=0
a=rtpmap:6 DVI4/16000
a=rtpmap:70 L16/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:99 isac/32000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:112 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 20056 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:main
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=video 20060 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:slides
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=application 20064 UDP/BFCP *
a=floorctrl:c-only
a=setup:passive
a=connection:new
a=bfcpver:1
响应：
2015-04-20 18:54:35,523 : Outbound Message
Transport: TCP: ip=x.x.x.x, port=60118, secure=false
SIP/2.0 200 OK
To: <sip:1234@x.x.x.x>;tag=7-mobi-15398169_ada14cd5_e63f04c4-9dbc-4e91-b908-fa42b01af3e4_3
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194;rport=60118
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528
CSeq: 1 INVITE
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11
Contact: <sip:x.x.x.x:5060;transport=tcp>
Content-Type: application/sdp
Min-SE: 400
Session-Expires: 1800;refresher=uac
Allow: UPDATE,ACK,INVITE,PRACK,CANCEL
Require: timer
Supported: timer,100rel
Content-Length: 542
v=0
o=- 2017325266 1 IN IP4 z.z.z.z (internal IP of server x.x.x.x)
s=-
c=IN IP4 x.x.x.x
t=0 0
m=audio 17050 RTP/AVP 112 101
a=rtpmap:112 opus/48000/2
a=fmtp:112 minptime=10
a=rtpmap:101 telephone-event/8000
a=sendrecv
m=video 17002 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0;level-asymmetry-allowed=1
a=rtcp-fb:97 nack
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm tmmbr
a=sendrecv
a=imageattr:97 send [x=480,y=640] recv [x=480,y=640]
m=video 0 RTP/AVP
m=application 0 RTP/AVP
----------------------------
For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up
based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" line
和
An offered stream MAY be rejected in the answer, for any reason.
If a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least
one MUST be present, as specified by SDP.
Existing media streams are removed by creating a new SDP with the
port number for that stream set to zero. The stream description MAY
omit all attributes present previously, and MAY list just a single
media format.
所以我猜你提供
- 一个音频流（被接受）
- 一个视频流（被接受）
- 第二个视频流（被拒绝）
- 一个申请流（被拒绝）
不完全确定为什么拒绝第二个视频流会导致第一个视频流不显示或不被使用。
@jsantander，感谢您提供更多信息。这让我意识到音频编解码器的报价和响应实际上并不匹配，分别是 opus 和 PCMU，因此没有建立该流。我知道问题表明情况并非如此，但是当通过媒体经纪人在基本层面上查看电话时，它变得很明显。
设置 opus priority 编解码器用于在客户端之间建立音频流已导致在几十个调用中 100% 建立音频流.
所以，下面是我从 x.x.x.x (webRTC) 从 y.y.y.y 调用时得到的响应（啜）。呼叫建立，但是只有视频而不是音频，具有 100% 的一致性。
我的问题是有谁知道 body 中的最后两个 sdp headers 是什么意思？为什么 x.x.x.x 最初会使用正确的端口和可用的编解码器进行响应，但随后又提出相反的建议：
"m=视频 0 RTP/AVP
m=应用程序 0 RTP/AVP"
任何帮助将不胜感激:)
出价：
2015-04-20 18:54:32,291 : Inbound Message
Transport: TCP: ip=x.x.x.x, port=60118, secure=false
INVITE sip:1234@x.x.x.x SIP/2.0
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11
To: <sip:1234@x.x.x.x>
Contact: <sip:2312@y.y.y.y;transport=tcp>
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y
CSeq: 1 INVITE
Supported: timer,sip-stun,outbound,replaces
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY,UPDATE,MESSAGE
Max-Forwards: 69
User-Agent: M
X-FS-Support: update_display
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
MSS_Initial_Remote_Addr: y.y.y.y
MSS_Initial_Remote_Port: 49528
MSS_Initial_Remote_Transport: tcp
Content-Length: 1304
v=0
o=Magor 1429539042 1429539044 IN IP4 y.y.y.y
s=Magor
c=IN IP4 y.y.y.y
b=TIAS:2048000
b=AS:2048
b=CT:2048
t=0 0
m=audio 20052 RTP/AVP 115 9 120 6 70 0 8 99 97 112 101
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:120 SILK/24000
a=fmtp:120 useinbandfec=1; usedtx=0
a=rtpmap:6 DVI4/16000
a=rtpmap:70 L16/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:99 isac/32000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:112 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 20056 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:main
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=video 20060 RTP/AVP 96 97
b=TIAS:2048000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e016; max-fs=8192; max-mbps=244800
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=64e016; max-fs=8192; max-mbps=244800
a=content:slides
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
m=application 20064 UDP/BFCP *
a=floorctrl:c-only
a=setup:passive
a=connection:new
a=bfcpver:1
响应：
2015-04-20 18:54:35,523 : Outbound Message
Transport: TCP: ip=x.x.x.x, port=60118, secure=false
SIP/2.0 200 OK
To: <sip:1234@x.x.x.x>;tag=7-mobi-15398169_ada14cd5_e63f04c4-9dbc-4e91-b908-fa42b01af3e4_3
Via: SIP/2.0/TCP x.x.x.x:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl-1194;rport=60118
Via: SIP/2.0/TCP y.y.y.y:5060;branch=z9hG4bKa877nh3hd5624lJ1o2E-pc16vl;rport=49528
CSeq: 1 INVITE
Call-ID: -119405323313131523-c16c-B2BUA@y.y.y.y
From: "Alacrity City" <sip:2312@y.y.y.y>;tag=14295560721021025240-F--5c-4f-6a-11
Contact: <sip:x.x.x.x:5060;transport=tcp>
Content-Type: application/sdp
Min-SE: 400
Session-Expires: 1800;refresher=uac
Allow: UPDATE,ACK,INVITE,PRACK,CANCEL
Require: timer
Supported: timer,100rel
Content-Length: 542
v=0
o=- 2017325266 1 IN IP4 z.z.z.z (internal IP of server x.x.x.x)
s=-
c=IN IP4 x.x.x.x
t=0 0
m=audio 17050 RTP/AVP 112 101
a=rtpmap:112 opus/48000/2
a=fmtp:112 minptime=10
a=rtpmap:101 telephone-event/8000
a=sendrecv
m=video 17002 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0;level-asymmetry-allowed=1
a=rtcp-fb:97 nack
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm tmmbr
a=sendrecv
a=imageattr:97 send [x=480,y=640] recv [x=480,y=640]
m=video 0 RTP/AVP
m=application 0 RTP/AVP
----------------------------
For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" line
和
An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP.
Existing media streams are removed by creating a new SDP with the
port number for that stream set to zero. The stream description MAY
omit all attributes present previously, and MAY list just a single
media format.
所以我猜你提供
- 一个音频流（被接受）
- 一个视频流（被接受）
- 第二个视频流（被拒绝）
- 一个申请流（被拒绝）
不完全确定为什么拒绝第二个视频流会导致第一个视频流不显示或不被使用。
@jsantander，感谢您提供更多信息。这让我意识到音频编解码器的报价和响应实际上并不匹配，分别是 opus 和 PCMU，因此没有建立该流。我知道问题表明情况并非如此，但是当通过媒体经纪人在基本层面上查看电话时，它变得很明显。
设置 opus priority 编解码器用于在客户端之间建立音频流已导致在几十个调用中 100% 建立音频流.