爲什麼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邀請請求？

回答

相關問題