<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/3256/">https://reviewboard.asterisk.org/r/3256/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 24th, 2014, 10:51 p.m. UTC, <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://reviewboard.asterisk.org/r/3256/diff/1/?file=54416#file54416line554" style="color: black; font-weight: bold; text-decoration: underline;">/branches/11/res/res_rtp_asterisk.c</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static void ast_rtp_ice_start(struct ast_rtp_instance *instance)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">554</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cm"><span class="tb"> </span> * handle. Wipe the existing candidates out if that's the case. */</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">555</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="k">if</span> <span class="p">(</span><span class="n">ao2_container_count</span><span class="p">(</span><span class="n">rtp</span><span class="o">-></span><span class="n">remote_candidates</span><span class="p">)</span> <span class="o">+</span> <span class="n">rtp</span><span class="o">-></span><span class="n">ice</span><span class="o">-></span><span class="n">rcand_cnt</span> <span class="o">></span> <span class="n">PJ_ICE_MAX_CAND</span><span class="p">)</span> <span class="p">{</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">556</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">ao2_ref</span><span class="p">(</span><span class="n">rtp</span><span class="o">-></span><span class="n">remote_candidates</span><span class="p">,</span> <span class="o">-</span><span class="mi">1</span><span class="p">);</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">557</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">rtp</span><span class="o">-></span><span class="n">remote_candidates</span> <span class="o">=</span> <span class="nb">NULL</span><span class="p">;</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">558</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="n">rtp</span><span class="o">-></span><span class="n">ice</span><span class="o">-></span><span class="n">rcand_cnt</span> <span class="o">=</span> <span class="n">rtp</span><span class="o">-></span><span class="n">ice</span><span class="o">-></span><span class="n">clist</span><span class="p">.</span><span class="n">count</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">559</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="tb"> </span><span class="k">return</span><span class="p">;</span></pre></td>
</tr>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">560</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="tb"> </span><span class="p">}</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Agreed, and pjnath does not provide a mechanism to do just that without destroying/re-creating as Matt says.
What would also be useful is to further look at the SDPs involved - are the candidates really changing? Do we really need to restart the ICE negotiation?</pre>
</blockquote>
<p>On February 24th, 2014, 11:17 p.m. UTC, <b>Jonathan Rose</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No, the candidates offered aren't changing. I think the reason it tries to add them anyway is because we never reached a point where the ICE session was tracked as having started (because the check list compliation is failing).
First Invite (SIPML5 client to desk phone)
<--- SIP read from WS:10.24.16.82:60366 --->
INVITE sip:1201@10.24.18.246 SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKMKg6LeUkDugGr9B1CnyHICANfn8JwRVR;rport
From: "sipml_bot"<sip:sipml_bot@10.24.18.246>;tag=W42MEkWLdFTUiIaaw8iy
To: <sip:1201@10.24.18.246>
Contact: "sipml_bot"<sip:sipml_bot@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 97982d1a-15e5-cd55-9122-07b3cc20cb7d
CSeq: 20907 INVITE
Content-Type: application/sdp
Content-Length: 1840
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.01.27
Organization: Doubango Telecom
v=0
o=- 3044420497219628500 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3
m=audio 56984 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 216.207.245.1
a=rtcp:56984 IN IP4 216.207.245.1
a=candidate:474352566 1 udp 2113937151 10.24.16.82 56984 typ host generation 0
a=candidate:474352566 2 udp 2113937151 10.24.16.82 56984 typ host generation 0
a=candidate:3038348387 1 udp 1845501695 216.207.245.1 56984 typ srflx raddr 10.24.16.82 rport 56984 generation 0
a=candidate:3038348387 2 udp 1845501695 216.207.245.1 56984 typ srflx raddr 10.24.16.82 rport 56984 generation 0
a=candidate:1388705606 1 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=candidate:1388705606 2 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=ice-ufrag:LeGzZojC7gQNvl7o
a=ice-pwd:VfqsY2VVKr3xg/mgvdPtcxhp
a=ice-options:google-ice
a=fingerprint:sha-256 3A:BA:F5:44:53:CD:99:6C:D1:32:9F:80:53:D4:B5:BA:AE:CF:98:54:71:7F:D6:CB:14:7F:D8:94:30:98:89:62
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:ZQQ2MjApfbPlEAmWe52FRkbKUVH4rXt5p5QnpObB
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JljeDW3NiakHNYn+bu+vje3cD77nNPytUW79J2Vz
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:3822531142 cname:YE/Lm1aHvDjHxwH0
a=ssrc:3822531142 msid:nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3 b50d1acc-19eb-455c-8a4b-40263a2d1a9b
a=ssrc:3822531142 mslabel:nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3
a=ssrc:3822531142 label:b50d1acc-19eb-455c-8a4b-40263a2d1a9b
second invite (SIPML5 client putting the call on hold)
INVITE sip:1201@10.24.18.246:5060;transport=WS SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK6QhlVcXuVSUNyTewJBtU0KIZzL9mMqCE;rport
From: "sipml_bot"<sip:sipml_bot@10.24.18.246>;tag=W42MEkWLdFTUiIaaw8iy
To: <sip:1201@10.24.18.246>;tag=as269c229d
Contact: "sipml_bot"<sip:sipml_bot@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 97982d1a-15e5-cd55-9122-07b3cc20cb7d
CSeq: 20908 INVITE
Content-Type: application/sdp
Content-Length: 1840
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.01.27
Organization: Doubango Telecom
v=0
o=- 3044420497219628500 3 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3
m=audio 56984 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 216.207.245.1
a=rtcp:56984 IN IP4 216.207.245.1
a=candidate:474352566 1 udp 2113937151 10.24.16.82 56984 typ host generation 0
a=candidate:474352566 2 udp 2113937151 10.24.16.82 56984 typ host generation 0
a=candidate:3038348387 1 udp 1845501695 216.207.245.1 56984 typ srflx raddr 10.24.16.82 rport 56984 generation 0
a=candidate:3038348387 2 udp 1845501695 216.207.245.1 56984 typ srflx raddr 10.24.16.82 rport 56984 generation 0
a=candidate:1388705606 1 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=candidate:1388705606 2 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=ice-ufrag:LeGzZojC7gQNvl7o
a=ice-pwd:VfqsY2VVKr3xg/mgvdPtcxhp
a=ice-options:google-ice
a=fingerprint:sha-256 3A:BA:F5:44:53:CD:99:6C:D1:32:9F:80:53:D4:B5:BA:AE:CF:98:54:71:7F:D6:CB:14:7F:D8:94:30:98:89:62
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendonly
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:ZQQ2MjApfbPlEAmWe52FRkbKUVH4rXt5p5QnpObB
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JljeDW3NiakHNYn+bu+vje3cD77nNPytUW79J2Vz
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:3822531142 cname:YE/Lm1aHvDjHxwH0
a=ssrc:3822531142 msid:nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3 b50d1acc-19eb-455c-8a4b-40263a2d1a9b
a=ssrc:3822531142 mslabel:nqy2BUfoo7yn1YeWLNBeED2rqMGSb1y8Ypv3
a=ssrc:3822531142 label:b50d1acc-19eb-455c-8a4b-40263a2d1a9b
third invite (SIMPL5 resumes the call)
INVITE sip:1201@10.24.18.246:5060;transport=WS SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKGAwGP8mOJ7Kd9TuUw4Ac7T1Pc3eVTQgE;rport
From: "sipml_bot"<sip:sipml_bot@10.24.18.246>;tag=W42MEkWLdFTUiIaaw8iy
To: <sip:1201@10.24.18.246>;tag=as269c229d
Contact: "sipml_bot"<sip:sipml_bot@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 97982d1a-15e5-cd55-9122-07b3cc20cb7d
CSeq: 20909 INVITE
Content-Type: application/sdp
Content-Length: 1838
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.01.27
Organization: Doubango Telecom
v=0
o=- 11625312205988492 4 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS HpcmWGwoVidQ57oRzreLCtEzVKYzRkuGXCzS
m=audio 43821 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 216.207.245.1
a=rtcp:43821 IN IP4 216.207.245.1
a=candidate:474352566 1 udp 2113937151 10.24.16.82 43821 typ host generation 0
a=candidate:474352566 2 udp 2113937151 10.24.16.82 43821 typ host generation 0
a=candidate:3038348387 1 udp 1845501695 216.207.245.1 43821 typ srflx raddr 10.24.16.82 rport 43821 generation 0
a=candidate:3038348387 2 udp 1845501695 216.207.245.1 43821 typ srflx raddr 10.24.16.82 rport 43821 generation 0
a=candidate:1388705606 1 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=candidate:1388705606 2 tcp 1509957375 10.24.16.82 0 typ host generation 0
a=ice-ufrag:bBLoaKGIBC2OBJK/
a=ice-pwd:zJD7a+9Pd54bh3WuLfQEiJRx
a=ice-options:google-ice
a=fingerprint:sha-256 3A:BA:F5:44:53:CD:99:6C:D1:32:9F:80:53:D4:B5:BA:AE:CF:98:54:71:7F:D6:CB:14:7F:D8:94:30:98:89:62
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:4QyVPss3/XPkqz2AcnDioqOwLO+BLQe1T41L8POW
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:dNDtygwacR+DTEppJTmZR4sjLQ/99yIDCBXbZwvJ
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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:1421740875 cname:vyMP5//bMmdw/mZH
a=ssrc:1421740875 msid:HpcmWGwoVidQ57oRzreLCtEzVKYzRkuGXCzS d99b2db8-4043-427e-b5b6-6a608f186190
a=ssrc:1421740875 mslabel:HpcmWGwoVidQ57oRzreLCtEzVKYzRkuGXCzS
a=ssrc:1421740875 label:d99b2db8-4043-427e-b5b6-6a608f186190
</pre>
</blockquote>
<p>On February 25th, 2014, 1:19 p.m. UTC, <b>Matt Jordan</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ah ha. They do change on the third INVITE request.
We could do this one of two ways:
(1) Compare the candidates that were received to what we currently have. If any differ, destroy the ICE session and re-create it.
(2) Say damn the torpedoes, full speed ahead - and always destroy the ICE session and re-create it.
I'd actually lean to (2), since (1) feels like an optimization you make when you're spending a lot of time destroy/re-creating things.</pre>
</blockquote>
<p>On February 25th, 2014, 1:53 p.m. UTC, <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">WELL... it depends if in the case of (1) the ICE negotiation was actually done again with the same candidates. If not and you destroy/re-create I'm not sure how the other side will handle the ICE negotiation.</pre>
</blockquote>
<p>On February 25th, 2014, 4:45 p.m. UTC, <b>Jonathan Rose</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Well, the candidates aren't changing on the second INVITE which is the one that is actually causing the assertion. If nothing else, if the ice session hasn't started yet we should probably be destroying/recreating it as well.</pre>
</blockquote>
<p>On February 25th, 2014, 4:47 p.m. UTC, <b>Joshua Colp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Was it not started?</pre>
</blockquote>
<p>On February 25th, 2014, 4:55 p.m. UTC, <b>Jonathan Rose</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">ast_rtp_ice_start was ran on the first INVITE, but failed during pj_ice_sess_create_check_list and returned PJNATH_EICENOHOSTCAND instead of PJ_SUCCESS:
if (pj_ice_sess_create_check_list(rtp->ice, &ufrag, &passwd, ao2_container_count(rtp->remote_candidates), &candidates[0]) == PJ_SUCCESS) {
pj_ice_sess_start_check(rtp->ice);
pj_timer_heap_poll(timerheap, NULL);
rtp->ice_started = 1;
rtp->strict_rtp_state = STRICT_RTP_OPEN;
return;
}
As I was saying before, we don't finish getting ICE started in this case. With kharwell's patch in place, we also blow out the remote candidates list in the RTP instance and that has caused the one way audio issue.</pre>
</blockquote>
<p>On February 25th, 2014, 5:10 p.m. UTC, <b>Matt Jordan</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Right. So what needs to be determined is why pj_ice_sess_create_check_list is returning PJNATH_EICENOHOSTCAND.
Looking at that particular code, that would occur in prune_checklist when there is no local candidate that has the same address as the SRFLX candidate's base address:
if (clist->checks[i].lcand->type == PJ_ICE_CAND_TYPE_SRFLX) {
/* Find the base for this candidate */
unsigned j;
for (j=0; j<ice->lcand_cnt; ++j) {
pj_ice_sess_cand *host = &ice->lcand[j];
if (host->type != PJ_ICE_CAND_TYPE_HOST)
continue;
if (sockaddr_cmp(&srflx->base_addr, &host->addr) == 0) {
/* Replace this SRFLX with its BASE */
clist->checks[i].lcand = host;
break;
}
}
if (j==ice->lcand_cnt) {
/* Host candidate not found this this srflx! */
LOG4((ice->obj_name,
"Base candidate %s:%d not found for srflx candidate %d",
pj_inet_ntoa(srflx->base_addr.ipv4.sin_addr),
pj_ntohs(srflx->base_addr.ipv4.sin_port),
GET_LCAND_ID(clist->checks[i].lcand)));
return PJNATH_EICENOHOSTCAND;
}
}
When this occurs, what are your local candidates? Is there a local candidate that should match?</pre>
</blockquote>
<p>On February 25th, 2014, 5:35 p.m. UTC, <b>Jonathan Rose</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">From my debug of the local candidate list, I got the following:
0 - host address: 10.24.18.246 (type host)
1 - host address: 216.207.245.1 (type srflx)
2 - host address: 10.24.18.246 (type host)
3 - host address: 216.207.245.1 (type srflx)
And the check list addresses they are being compared to:
0 - 10.24.18.246 (type host)
1 - 10.24.18.246 (type host)
2 - 10.24.18.246 (type host)
3 - 10.24.18.246 (type host)
4 - 216.207.245.1 (type srflx)
5 - 216.207.245.1 (type srflx)
6 - 216.207.245.1 (type srflx)
7 - 216.207.245.1 (type srflx)
8 - 10.24.18.246 (type host)
9 - 10.24.18.246 (type host)
10 - 216.207.245.1 (type srflx)
11 - 216.207.245.1 (type srflx)
All of the ones that would match against the clist members are of type srflx and get ignored by:
if (host->type != PJ_ICE_CAND_TYPE_HOST)
continue;
The base_addr for each local candidate is the same as addr.</pre>
</blockquote>
<p>On February 25th, 2014, 5:41 p.m. UTC, <b>Jonathan Rose</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Let me ammend that data to include port numbers...
Local Candidates:
0 - host address: 10.24.18.246:3640 (type host)
1 - host address: 216.207.245.1:3896 (type srflx)
2 - host address: 10.24.18.246:3640 (type host)
3 - host address: 216.207.245.1:3896 (type srflx)
Check List:
0 - 10.24.18.246:3640 (type host)
1 - 10.24.18.246:3896 (type host)
2 - 10.24.18.246:3640 (type host)
3 - 10.24.18.246:3896 (type host)
4 - 216.207.245.1:3640 (type srflx)
5 - 216.207.245.1:3640 (type srflx)
6 - 216.207.245.1:3640 (type srflx)
7 - 216.207.245.1:3640 (type srflx)
8 - 10.24.18.246:3640 (type host)
9 - 10.24.18.246:3896 (type host)
10 - 216.207.245.1:3640 (type srflx)
11 - 216.207.245.1:3640 (type srflx)</pre>
</blockquote>
<p>On February 25th, 2014, 7:22 p.m. UTC, <b>Matt Jordan</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I have a suspicion that the reason this is happening is due to the lack of a STUN/TURN server being used by the rtp configuration.
If I'm interpreting RFC 5242 4.1.1.2/4.1.1.3 correctly, the remote candidate is saying 'hey, you can use a STUN server to reach me via 216.207.245.1' - but the local connection has no STUN server that can reach that address. So the computing of the check list fails.
What is unfortunate is that the implementation doesn't just remove the candidate from the check list, it instead blows away the entire check list. That may be appropriate, but it feels like it would be nicer to just drop the candidate.
I do think, however, that there isn't much you can do with that candidate if you can't compute a foundation.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">After further discussion with jrose the above issue was isolated and fixed. Further patches should include the fix.</pre>
<br />
<p>- Joshua</p>
<br />
<p>On February 24th, 2014, 6:36 p.m. UTC, Jonathan Rose wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, Joshua Colp, Kevin Harwell, and Matt Jordan.</div>
<div>By Jonathan Rose.</div>
<p style="color: grey;"><i>Updated Feb. 24, 2014, 6:36 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-22911">ASTERISK-22911</a>,
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-23213">ASTERISK-23213</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Let me start by saying this is almost certainly not the complete answer to solving these problems. This patch is simply an alternative to backing out the patch from r405234 and leaving the existing aborts in place. I've written a test to make sure the new patch (and likely a later patch which can resolve these problems with ICE more comprehensively) does not crash Asterisk and that can be view here: https://reviewboard.asterisk.org/r/3255/
In my reproduction of this regression, I noticed a few things. The first was that when starting a call with ICE from SIPML5 that Asterisk would not be able to full initialize the ICE session. Instead when creating the candidate checklist via pj_ice_sess_create_check_list, PJNATH would be unable to associate the srflx candidates with any host pairs when pruning the checklist. The SRFLX candidates would have the addresses used internally on my LAN while the addresses it would be matched up against would mirror those of my external IP (in other words, they just didn't match by address). The overall return from pj_ice_sess_create_check_list would be PJNATH_EICENOHOSTCAND and while the ICE session wouldn't get flagged as started, I still continued to receive two way audio on both ends in Asterisk 11.7
Asterisk 11.8 however would clear the candidate lists at this point and I would get one way audio instead.
The crash in 11.7 from holding was caused because upon holding the call, the SDP would contain the same list of ICE candidates, so Asterisk would attempt to start the ICE session again. This time when it entered the create check list function, the maximum ICE candidates in the session would be exhausted causing PJNATH to assert and abort (which visibly appears more or less the same as a crash). This work around patch checks to see if a create checklist call will cause that value to expand above the maximum and if it would, we abandon starting ICE back up and we clear the current candidate list on the ICE session. In my own tests this seemed to work quite well (I had two way audio, Asterisk didn't terminate suddenly, and I was able to hold and resume the call while still maintaining two way audio and music on hold for all expected ends). According to Vytis though, neither this patch nor the original patch to resolve ASTERISK-22911 by kharwell actually fixed his audio problems anyway. Kharwell's patch fixed the assertions that were occurring because the candidate list would be cleared on any error including the PJNATH_EICENOHOSTCAND which most of the people in ASTERISK-23213 were most likely experiencing as well. I draw that conclusion because when they used this patch they reported that it fixed their issues without introducing any new crashes.
At this point, I'm not entirely sure that audio actually should be allowed to work when building the ICE session check list fails like it has been in this scenario. But we need to finalize a new Asterisk 11 release soon and we can't have this apparent regression in when we do so. In the future we need to find out more comprehensively why pj_ice_sess_create_check_list is failing and how to fix that.
Props to Lott Caskey for providing some improvements to the patch that I wrote.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested calls and holds with a SIPML5 call to a desk phone. Confirmed two way audio and music on hold.
Requested that the reporter and participants of ASTERISK-23213 test the patch. Everyone who tested it confirmed that it fixed their problems.
Ran https://reviewboard.asterisk.org/r/3255/ and checked the log files to see what was happening</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/11/res/res_rtp_asterisk.c <span style="color: grey">(408284)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/3256/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>