Почему sipml5 создает запрос приглашения webRTC с одним и тем же портом для Audio RTP, Audio RTCP, Video RTP и Video RTCP?

Раньше я использовал веб-браузер Firefox, чтобы инициировать запрос приглашения WebRTC. Затем я наблюдал sdp с разными номерами портов для аудио и видео канала. И я мог легко получить кандидатов и выполнить операции ICE. Здесь я прикрепляю сообщение с запросом на приглашение webRTC в веб-браузере Chrome.

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?


person RajibTheKing    schedule 21.01.2015    source источник
comment
По умолчанию Chrome будет использовать только один порт, чтобы упростить обход NAT.   -  person Benjamin Trent    schedule 21.01.2015
comment
Как я могу различать данные audioRTP, audioRTCP, videoRTP и videoRTCP, чтобы использовать эти данные для взаимодействия с другим sip-клиентом.   -  person RajibTheKing    schedule 22.01.2015
comment
Вы можете определить это по SSRC, содержащейся в информации пакета, и сравнить ее с информацией в SDP. Вам нужно будет прочитать заголовки пакетов RTP и RTCP.   -  person Benjamin Trent    schedule 22.01.2015
comment
Это хорошее решение. А заголовки пакетов RTP и RTCP будут содержать информацию для демультиплексирования данных. Но я не знаю, как отличить пакеты RTP и RTCP с помощью SSRC. Я должен различать эти пакеты на своем сервере, используя тип полезной нагрузки и маркерный бит. Я также нашел эту информацию в RFC 5761.   -  person RajibTheKing    schedule 24.01.2015
comment
Можно ли как-то получить повторное сообщение INVITE от webRTC с 4 разными портами?   -  person RajibTheKing    schedule 23.02.2015
comment
Теперь SIP-клиент ---- › Процедура вызова Chrome WebRTC выполнена успешно Но Chrome WebRTC ------ › Процедура вызова SIP-клиента не завершена. Может ли кто-нибудь помочь мне разобраться с этой проблемой?   -  person RajibTheKing    schedule 23.02.2015
comment
Это звучит как совершенно новый вопрос. Идите вперед и спросите новый с соответствующим выводом отладки   -  person Benjamin Trent    schedule 23.02.2015


Ответы (1)


Строка, которая заставляет браузер использовать только одно соединение для аудио и видео,

a=group:BUNDLE audio video

Вы можете просто удалить эту строку из предложения/ответа, и браузеры продолжат использовать несколько соединений.

person thammi    schedule 23.01.2015
comment
Спасибо за ответ. На самом деле я хочу создать связь между webRTC и SIP-клиентом. Когда я отправляю сообщение с предложением SIP в chrome, удаляя две строки, a=group:BUNDLE audio video и a=rtcp-mux, тогда google chrome отправляет мне ответное сообщение с разными номерами портов. Он работает отлично. Но когда Google Chrome отправляет сообщение с предложением, он всегда использует одни и те же номера портов. Я могу удалить эти строки при обработке этого сообщения с предложением на моем сервере, но я думаю, что это не будет реальным решением. - person RajibTheKing; 24.01.2015
comment
На самом деле я делаю что-то подобное на своем сервере WebRTC Echo для функции пакета, и это работает для меня. Если ответ не указывает на поддержку функции, Chrome не должен ее использовать. Вам нужно удалить строки из ответа, который вы генерируете. - person thammi; 24.01.2015