<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi Matthew,</div><div><br></div><div>Thanks for Your response.</div><br><div><div>On 05 Dec 2013, at 19:56, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></div></div></div></blockquote><div><br></div><div>I checked the logs of SipMl5, to issue the hold it sends an INVITE with a=sendonly and receives 200 OK with a=recvonly.</div><div>To resume it negotiates a=sendrecv with m= line containing the new port.</div><div>Imho Asterisk correctly negotiates the resume AND calls ast_rtp_remote_address_set() with new address.</div><div>So I just need to restart the ice session, but ...</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto;"><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></div></div></blockquote><div><br></div><div>It would be great if ast_rtp_start existed. I checked both 11.5.1 and trunk versions. Neither of them has a field in ast_rtp_engine which at least resembles ‘start’ method. Closest one is ast_rtp_activate, but it seems unconnected to ice sessions. This is one of the reasons I could not determine the location where should I restart ICE.</div><div><br></div><div>Another reason is that ast_rtp_ice_start does not actually create an ice session, where ast_rtp_ice_stop destroys one. Thus this pair should not be used for restarting as far as I can tell. (Unless ice session is spawned in other code, which is guaranteed to be run in between of those two calls. But then again — I have no proof for that.)</div><div><br></div><div>That being said — what I wrote is more of a hack than a solution.</div><div>1. I force ast_rtp_ice_start to provide only the newest candidates to pj_ice_sess_create_check_list by discarding existing list after it was given to pj.</div><div>2. I force pj_ice_sess_create_check_list to reset all existing checks when called with new candidate list.</div><div><br></div><div>I am unsure about correctness of my patch, since I am not really fond of neither asterisk nor pj internal architectures and I just took a guess how should I dispose the containers in both sides, thus I may have created a memory leak in asterisk. PJ seems to use static arrays for checklists, so that kind of makes it easier, yet another thread might be using the checklist thus when I reset the counter I force the threads to race on checks array.</div><div><br></div><div>I will attach the patch to the issue.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><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>
-- <br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br></body></html>