<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sun, 23 Aug 2020 at 18:23, Antony Stone <<a href="mailto:Antony.Stone@asterisk.open.source.it">Antony.Stone@asterisk.open.source.it</a>> wrote:<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Saturday 22 August 2020 at 22:51:48, Sebastian Nielsen wrote:<br>
<br>
> I had a similiar problem, but with calls dropping after 30 sec.<br>
> It turned out that Android didn't support RP-CID (Reverse Party Caller ID)<br>
> so when I sent the name of the callee to the caller (as some sort of<br>
> "centralized phonebook function") it caused calls to be dropped as android<br>
> refused to reply on the packets or sent rejections back.<br>
<br>
I can see the point you're making here, but what's going to do this after 30 <br>
*minutes* of normal call?<br></blockquote><div><br></div><div>Have seen plenty of ALGs do weird things like this. 30 minutes is a nice number, and nice enough that I'd go hunting for ALG issues. It's a good multiple of 3 minutes, and quite possibly is some big number someone thought to set in something that "no one would ever hit".</div><div><br></div><div>A tcpdump would probably show you what's going on if the logs are otherwise unclear, and you could also make sure you have sensible RTP timeout rules.</div><div><br></div><div>Andrew</div><div><br></div><div> </div></div></div>