【问题标题】:Why sipml5 create webRTC invite request with same port for Audio RTP, Audio RTCP, Video RTP and Video RTCP?为什么 sipml5 为音频 RTP、音频 RTCP、视频 RTP 和视频 RTCP 创建具有相同端口的 webRTC 邀请请求?
【发布时间】:2023-07-11 11:13:02
【问题描述】:

之前我使用 Firefox 浏览器发起 webRTC 邀请请求。然后我观察到 sdp 具有不同的音频和视频通道端口号。而且我可以轻松获得候选人并完成 ICE 操作。在这里,我在 chrome 网络浏览器中附加了 webRTC 邀请请求消息。

INVITE sip:user1@myserver.demo.com SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK2d4AlD4kTtu3AvTbW7RZDD03H1Ex8MnB;rport
From: "user2"<sip:user2@myserver.demo.com>;tag=gy75qhB7Gxto2pakdTaT
To: <sip:user1@myserver.demo.com>
Contact: "user2"<sip:user2@df7jal23ls0d.invalid;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 检查?

【问题讨论】:

  • 默认情况下,chrome 只会使用一个端口来使 NAT 穿越更容易。
  • 我如何区分audioRTP、audioRTCP、videoRTP和videoRTCP数据,以便我可以使用这些数据与其他sip客户端交互。
  • 你可以通过包信息中包含的SSRC来判断,并与SDP中的信息进行比较。您需要阅读 RTP 和 RTCP 数据包标头。
  • 这是一个不错的解决方案。而 RTP 和 RTCP 数据包头将包含解复用数据的信息。但我不知道如何使用 SSRC 区分 RTP 和 RTCP 数据包。我必须使用有效负载类型和标记位在我的服务器中区分这些数据包。我还从 RFC 5761 中找到了这些信息。
  • 是否可以通过 4 个不同的端口从 webRTC 以某种方式获取 re-INVITE 消息?

标签: google-chrome webrtc sdp sipml


【解决方案1】:

导致浏览器只使用一个音频和视频连接的行是

a=group:BUNDLE audio video

您只需从提议/答案中删除此行,浏览器将继续使用多个连接。

【讨论】:

  • 感谢您的回答。实际上我想在 webRTC 和 SIP 客户端之间创建通信。当我向 chrome 发送 SIP 提供消息时删除两行“a=group:BUNDLE audio video”和“a=rtcp-mux”,然后 google chrome 会向我发送具有不同端口号的应答消息。它运行良好。但是当谷歌浏览器发送报价消息时,它总是使用相同的端口号。我可以在我的服务器中处理此优惠消息时删除这些行,但我认为这不是实际的解决方案。
  • 我实际上在我的 WebRTC Echo 服务器中为捆绑功能做类似的事情,它对我有用。如果答案不表示支持该功能,Chrome 不应该使用它。您需要从生成的答案中删除这些行。