<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 6:14 AM, Vytis Valentinavičius <span dir="ltr"><<a href="mailto:xytis2000@gmail.com" target="_blank">xytis2000@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I am trying to resolve asterisk bug <a href="https://issues.asterisk.org/jira/browse/ASTERISK-22911" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-22911</a>, but I have some questions regarding existing code:</div>
<div><br></div><div>[ I am working on 11.5.1 version ]</div></div></blockquote><div><br></div><div>Hey Vytis -<br><br></div><div>For the patch that you're developing, feel free to attach it as a diff on the actual issue. You'll need to sign a license contributor agreement, but having the code on the issue would be the appropriate next step. I commented on the issue to that extent as well.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Currently ICE session is initialised on first SDP INVITE, during initialisation it pairs received remote candidates with known local candidates and effectively establishes a route from asterisk to requesting client.</div>
<div>When WebRTC client issues unhold reinvite, ICE session is not altered, thus rendering connection from asterisk to client broken.</div><div><br></div><div>How should I alter the ICE session?</div><div>Things I already tried:</div>
<div>1. Force asterisk to provide PJICE with completely fresh copy of remote candidates (not a concat of newly received and old candidates) (I think this is a separate bug.)</div><div>2. Force ICE session to recheck all available candidates by either reseting the check container or by removing them altogether. Both of these approaches failed, and I suspect the failures are related to async STUN checking, that use previously registered checks. I could not find any documentation/methods/help within PJSIP.</div>
</div></blockquote><div><br></div><div>Hm. Reading Section 9.1.1.1 of RFC 5245:<br><br><pre class="">These rules imply that setting the IP address in the c line to
0.0.0.0 will cause an ICE restart. Consequently, ICE implementations
MUST NOT utilize this mechanism for call hold, and instead MUST use
a=inactive and a=sendonly as described in [<a href="http://tools.ietf.org/html/rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>].
</pre><br></div><div>When you get a call hold, how is it indicating the media restriction?<br><br></div><div>In general, looking through section 9.1.2, I would suspect that any serious modification of the media streams would require ICE to be restarted completely. <br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div><br></div><div>Things I would like to try, yet may not find a logical approach to them:</div><div>1. Scrap the whole ICE session and reinitiate a new one. That was my first idea yet I can not determine where the ICE session was created in the first place. All the places I suspected were not executed over the whole lifetime of asterisk application.</div>
<div>2. Just forget the session when receiving and SDP reinvite and build a new one. This seems logical, yet I can not determine will it work for all cases, since I know only my own little case.</div><div><br></div><div>
Please help me, I am struggling for over a week...<br clear="all"></div></div></blockquote><div><br></div><div>So, the rtp_engine already has methods to start/stop the RTP instance in certain situations. This should include when chan_sip (or other channel drivers) need to hold the media. See ast_rtp_start/ast_rtp_stop in res_rtp_asterisk, which is what the virtual table for res_rtp_asterisk will use when the start/stop methods are called from the engine.<br>
<br></div><div>In those methods, have you tried stopping ICE and starting it using ast_rtp_ice_stop/ast_rtp_ice_start? <br></div></div><br>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div>
<div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>