Why sipml5 create webRTC invite request with same port for Audio RTP, Audio RTCP, Video RTP and Video RTCP?

Question

Previously I used firefox web browser to initiate webRTC invite request. Then I observed sdp with different port numbers for audio and video channel. And I could easily get the candidates and completed ICE operations. Here I am attaching webRTC invite request message in chrome web browser.

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

So, why they are using same port numbers and how to handle these for ICE check?

By default chrome will only use one port to make NAT traversal easier. — Benjamin Trent, Jan 21 '15 at 14:01
How I can distinguish audioRTP, audioRTCP, videoRTP and videoRTCP data so that I can use these data to interect with other sip client. — RajibTheKing, Jan 22 '15 at 03:06
You can tell by the SSRC contained in the packet information and compare it with the info in the SDP. You will need to read up on RTP and RTCP packet headers. — Benjamin Trent, Jan 22 '15 at 14:17
It's a nice solution. And RTP and RTCP packet headers will contain the information to demux data. But I don't know how to distinguish RTP and RTCP packet using SSRC. I have to distinguish these packets in my server using payload type and marker bit. I have also found this information from RFC 5761. — RajibTheKing, Jan 24 '15 at 05:35
Is it possible to get somehow re-INVITE message from webRTC with 4 different port? — RajibTheKing, Feb 23 '15 at 06:51
Now, SIP Client ---- > Chrome WebRTC Call procedure is Successfull But, Chrome WebRTC ------ > SIP Client Call procedure is not completed. Can anyone help me to figure out this problem? — RajibTheKing, Feb 23 '15 at 06:54
That sounds like a totally new question. Go ahead and ask a new one with pertinent debug output — Benjamin Trent, Feb 23 '15 at 13:44

score 4 · Accepted Answer · answered Jan 23 '15 at 10:45

4

The line which causes the browser to use only one connection for audio and video is

a=group:BUNDLE audio video

You can simply remove this line from the offer/answer and the browsers will continue to use multiple connections.

answered Jan 23 '15 at 10:45

thammi

444
1
4
17

3

Thanks for the answer. Actually I want to create communication between webRTC and SIP client. When I send SIP offer message to chrome removing two lines, "a=group:BUNDLE audio video" and "a=rtcp-mux" then google chrome send me answer message with different port numbers. It's working perfectly. But when google chrome send offer message, it always use same port numbers. I can remove these lines while processing this offer message in my server, but I think it will not be the actual solution. – RajibTheKing Jan 24 '15 at 05:20
3

I am actually doing something similar in my WebRTC Echo server for the bundle feature and it works for me. If the answer does not indicate support of the feature, Chrome should not use it. You need to remove the lines from the answer which you generate. – thammi Jan 24 '15 at 17:29

Why sipml5 create webRTC invite request with same port for Audio RTP, Audio RTCP, Video RTP and Video RTCP?

1 Answers1