为什么sipml5为音频RTP，音频RTCP，视频RTP和视频RTCP创建具有相同端口的webRTC邀请请求？

以前我用firefox网页浏览器来发起webRTC邀请请求。然后我用音频和视频通道的不同端口号观察sdp。我可以轻松获得候选人并完成ICE操作。在这里，我在Chrome浏览器中附加了webRTC邀请请求消息。为什么sipml5为音频RTP，音频RTCP，视频RTP和视频RTCP创建具有相同端口的webRTC邀请请求？

INVITE sip:[email protected] SIP/2.0 
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK2d4AlD4kTtu3AvTbW7RZDD03H1Ex8MnB;rport 
From: "user2"<sip:[email protected]>;tag=gy75qhB7Gxto2pakdTaT 
To: <sip:[email protected]> 
Contact: "user2"<sip:[email protected];rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;language="en,fr" 
Call-ID: 1290ebe1-f59d-95c3-a91c-d714773ae56b 
CSeq: 37591 INVITE 
Content-Type: application/sdp 
Content-Length: 3709 
Max-Forwards: 70 
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.12.11 
Organization: Doubango Telecom 

v=0 
o=- 3376022867449415700 2 IN IP4 127.0.0.1 
s=Doubango Telecom - chrome 
t=0 0 
a=group:BUNDLE audio video 
a=msid-semantic: WMS Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 
m=audio 57008 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 
c=IN IP4 202.53.167.164 
a=rtcp:57008 IN IP4 202.53.167.164 
a=candidate:2068563606 1 udp 2122194687 192.168.10.148 57008 typ host generation 0 
a=candidate:2068563606 2 udp 2122194687 192.168.10.148 57008 typ host generation 0 
a=candidate:902314598 1 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0 
a=candidate:902314598 2 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0 
a=candidate:3083270405 1 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0 
a=candidate:3083270405 2 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0 
a=ice-ufrag:cinBWZB6tiSnOnf1 
a=ice-pwd:50yVBGm5WuKlbZeyRrmjOvMn 
a=ice-options:google-ice 
a=fingerprint:sha-256 7C:69:84:B5:D5:C1:86:D0:56:8F:22:BA:5F:61:AD:1E:55:21:5A:6A:50:35:0C:49:E2:43:E9:C0:03:CC:B5:31 
a=setup:actpass 
a=mid:audio 
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 
a=sendrecv 
a=rtcp-mux 
a=rtpmap:111 opus/48000/2 
a=fmtp:111 minptime=10; useinbandfec=1 
a=rtpmap:103 ISAC/16000 
a=rtpmap:104 ISAC/32000 
a=rtpmap:9 G722/8000 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:106 CN/32000 
a=rtpmap:105 CN/16000 
a=rtpmap:13 CN/8000 
a=rtpmap:126 telephone-event/8000 
a=maxptime:60 
a=ssrc:4060942202 cname:MV0YBQDo4IyYKk2T 
a=ssrc:4060942202 msid:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 8031161b-973f-4024-8f52-7bd33af05431 
a=ssrc:4060942202 mslabel:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 
a=ssrc:4060942202 label:8031161b-973f-4024-8f52-7bd33af05431 
m=video 57008 UDP/TLS/RTP/SAVPF 100 116 117 96 
c=IN IP4 202.53.167.164 
a=rtcp:57008 IN IP4 202.53.167.164 
a=candidate:2068563606 1 udp 2122194687 192.168.10.148 57008 typ host generation 0 
a=candidate:2068563606 2 udp 2122194687 192.168.10.148 57008 typ host generation 0 
a=candidate:902314598 1 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0 
a=candidate:902314598 2 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0 
a=candidate:3083270405 1 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0 
a=candidate:3083270405 2 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0 
a=ice-ufrag:cinBWZB6tiSnOnf1 
a=ice-pwd:50yVBGm5WuKlbZeyRrmjOvMn 
a=ice-options:google-ice 
a=fingerprint:sha-256 7C:69:84:B5:D5:C1:86:D0:56:8F:22:BA:5F:61:AD:1E:55:21:5A:6A:50:35:0C:49:E2:43:E9:C0:03:CC:B5:31 
a=setup:actpass 
a=mid:video 
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 
a=sendrecv 
a=rtcp-mux 
a=rtpmap:100 VP8/90000 
a=rtcp-fb:100 ccm fir 
a=rtcp-fb:100 nack 
a=rtcp-fb:100 nack pli 
a=rtcp-fb:100 goog-remb 
a=rtpmap:116 red/90000 
a=rtpmap:117 ulpfec/90000 
a=rtpmap:96 rtx/90000 
a=fmtp:96 apt=100 
a=ssrc-group:FID 992785727 3894832329 
a=ssrc:992785727 cname:MV0YBQDo4IyYKk2T 
a=ssrc:992785727 msid:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 85987089-827b-4f5a-a7ff-65afc1c23f88 
a=ssrc:992785727 mslabel:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 
a=ssrc:992785727 label:85987089-827b-4f5a-a7ff-65afc1c23f88 
a=ssrc:3894832329 cname:MV0YBQDo4IyYKk2T 
a=ssrc:3894832329 msid:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 85987089-827b-4f5a-a7ff-65afc1c23f88 
a=ssrc:3894832329 mslabel:Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b 
a=ssrc:3894832329 label:85987089-827b-4f5a-a7ff-65afc1c23f88

那么，他们为什么使用相同的端口号以及如何处理这些ICE检查？

来源

2015-01-21 RajibTheKing

默认情况下，chrome将只使用一个端口来简化NAT穿越。 – 2015-01-21 14:01:48

如何区分audioRTP，audioRTCP，videoRTP和videoRTCP数据，以便我可以使用这些数据与其他sip客户端进行交流。 – RajibTheKing 2015-01-22 03:06:10

您可以通过包含在包信息中的SSRC来判断，并将其与SDP中的信息进行比较。您需要阅读RTP和RTCP数据包标头。 – 2015-01-22 14:17:33

这会导致浏览器只使用一个用于音频和视频连接线是

a=group:BUNDLE audio video

你可以简单地从要约/应答删除此行，浏览器将继续使用多个连接。

来源

2015-01-23 10:45:38 thammi

谢谢你的答案。其实我想创建webRTC和SIP客户端之间的通信。当我发送SIP提供消息去除铬两条线， “a =组：BUNDLE音频视频”和 “a = rtcp-mux”，则Google Chrome向我发送带有不同端口号的应答消息。它的工作完美。但是，当谷歌Chrome发送提供消息时，它总是使用相同的端口号。在我的服务器中处理此优惠消息时，我可以删除这些行，但我认为这不会是实际的解决方案。 – RajibTheKing 2015-01-24 05:20:43

我实际上是在我的WebRTC Echo服务器中为捆绑功能做类似的事情，它适用于我。如果答案不表示支持该功能，Chrome就不应该使用它。您需要从您生成的答案中删除这些行。 – thammi 2015-01-24 17:29:48

为什么sipml5为音频RTP，音频RTCP，视频RTP和视频RTCP创建具有相同端口的webRTC邀请请求？

回答

相关问题