Asterisk
  1. Asterisk
  2. ASTERISK-26982

chan_sip: rtcp_mux setting may cause ice completion failure/delay if client offers rtcp-mux as negotiable

    Details

    • Frequency of Occurrence:
      Constant

      Description

      When asterisk (chan_sip) receives a SDP offer with rtcp_mux capabilities announced as optional in the sense that the SDP offer contains ice candidates for both RTP and RTCP components (this is the default case for firefox), it seems the resulting check_list that asterisk creates fails. Both parties support RTCP mux and do end up using RTCP MUX, but asterisk builds its ice-check-list with the ice->rcand structure containing candidates for both components.

      I hope you can reproduce this issue in a proper test environment. At this time I only have my test notes:

      Test scenario:
      A chan_sip webrtc client makes an outgoing call

      Description of general setup:
      Webrtc client uses SIPml and matches a registered chan_sip peer A.x in asterisk configured as in https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5

      Test case 1.1
      Webrtc client uses firefox (which by default has rtcpmuxpolicy negotiate). Peer A.x has rtcp_mux=yes. X sends a SDP offer like the following to asterisk:

      	INVITE 333
      	...
      	a=candidate:0 1 UDP 2122252543 192.168.1.114 62470 typ host
      	a=candidate:0 2 UDP 2122252542 192.168.1.114 62471 typ host
      	a=candidate:1 1 UDP 1686052863 111.111.111.111 62470 typ srflx raddr 192.168.1.114 rport 62470
      	a=candidate:1 2 UDP 1686052862111.111.111.111 62471 typ srflx raddr 192.168.1.114 rport 62471
      	a=ice-pwd:468f8e9af5e2a3cb57391f164fc245e2
      	a=ice-ufrag:935fa149
      	a=rtcp:62471 IN IP4 111.111.111.111
      	a=rtcp-mux
      	...
      

      Result: Asterisk sends a 200 OK within a second, but ast_rtp_on_ice_complete fires after 8 seconds and consequently 2-way audio is delayed 8 seconds in the corresponding call.

      Internal notes: By using gdb and inserting a breakpoint in ast_rtp_on_ice_complete I could inspect the ice session attributes and I could verify "(gdb) p ice->clist" that none of the tests in the ice_checklist had succeeded, moreover the ice->rcand was populated with candidates for both components RTP and RTCP.

      Test case 1.2
      As 1.2 but using chrome with rtcpmuxpolicy require.
      X then sends a SDP offer like the following:

      	INVITE 333
      	...
      	a=rtcp:9 IN IP4 0.0.0.0
      	a=candidate:2469292855 1 udp <some ipv6> 57513 typ host generation 0 network-id 2 network-cost 50
      	a=candidate:27784895 1 udp 2122194687 192.168.1.114 57514 typ host generation 0 network-id 1
      	a=candidate:2163208203 1 udp 1685987071 111.111.111.111 57514 typ srflx raddr 192.168.1.114 rport 57514 generation 0 network-id 1
      	a=candidate:3719141319 1 tcp 1518275327 <some ipv6> 9 typ host tcptype active generation 0 network-id 2 network-cost 50
      	a=candidate:1327761999 1 tcp 1518214911 192.168.1.114 9 typ host tcptype active generation 0 network-id 1
      	a=ice-ufrag:H+L8
      	...
      	a=rtcp-mux
      

      Result: success, ice completion within a second, and there is only one component in the ice->rcand.

      Test case 1.3
      As 1.1 but webrtc client uses chrome with rtcpMuxPolicy explicitly set to "negotiate"
      Result: same result as 1.1

      Test case 1.4
      As 1.1 but A.x has rtcp_mux=no,

      Result, success, rtcp_mux is not used, ice->rcand contains seperate RTP and RTCP candidates and the ice check_list succeseds.

        Issue Links

          Activity

          Hide
          Friendly Automation added a comment -

          Change 5651 merged by Jenkins2:
          chan_sip: Better ICE handling for RTCP-MUX

          https://gerrit.asterisk.org/5651

          Show
          Friendly Automation added a comment - Change 5651 merged by Jenkins2: chan_sip: Better ICE handling for RTCP-MUX https://gerrit.asterisk.org/5651
          Hide
          Friendly Automation added a comment -

          Change 5711 merged by Jenkins2:
          chan_sip: Better ICE handling for RTCP-MUX

          https://gerrit.asterisk.org/5711

          Show
          Friendly Automation added a comment - Change 5711 merged by Jenkins2: chan_sip: Better ICE handling for RTCP-MUX https://gerrit.asterisk.org/5711
          Hide
          Friendly Automation added a comment -

          Change 5712 merged by Jenkins2:
          chan_sip: Better ICE handling for RTCP-MUX

          https://gerrit.asterisk.org/5712

          Show
          Friendly Automation added a comment - Change 5712 merged by Jenkins2: chan_sip: Better ICE handling for RTCP-MUX https://gerrit.asterisk.org/5712
          Hide
          Friendly Automation added a comment -

          Change 5652 merged by Jenkins2:
          chan_sip: Better ICE handling for RTCP-MUX

          https://gerrit.asterisk.org/5652

          Show
          Friendly Automation added a comment - Change 5652 merged by Jenkins2: chan_sip: Better ICE handling for RTCP-MUX https://gerrit.asterisk.org/5652
          Hide
          Friendly Automation added a comment -

          Change 5650 merged by Joshua Colp:
          chan_sip: Better ICE handling for RTCP-MUX

          https://gerrit.asterisk.org/5650

          Show
          Friendly Automation added a comment - Change 5650 merged by Joshua Colp: chan_sip: Better ICE handling for RTCP-MUX https://gerrit.asterisk.org/5650

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development