<div dir="ltr">Adrian:<br><br>Thanks for the response. I don't understand all of it, but I did contact the provider. Here is their response:<div><br></div><div>"<span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Unfortunately our scope of support is very limited for BYOD setups (with the exception of troubleshooting VOIPo-network related matters). You may try checking codec settings the softphone and ensure they are set to PCMU (a misconfiguration of this settings has caused issues with some users and their softphones), but if the service works with other softphones it's could possibly be just a misconfigured setting in the softphone."</span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I didn't find any misconfigured settings in the softphone, so I assume they have a misconfigured server. That doesn't explain why Bria and the JK Audio device work perfectly now, but I'm sure there's an explanation. </span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Adrian, if you have any interest in testing a VOIPo account, send me an email, and I'll provide you with the credentials for an account I'm not using at the moment. It's a US-based number. </span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-family:Verdana,Arial,Helvetica;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Mike</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 28, 2018 at 2:43 PM, Adrian Georgescu <span dir="ltr"><<a href="mailto:ag@ag-projects.com" target="_blank">ag@ag-projects.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Mike,<div><br></div><div><div>Blink does not have an explicit keep-alive mechanism, but it does respond to keep alive packets like an OPTIONS packet sent by a SIP server.</div></div><div><br></div><div>As a rule of thumb, a SIP provider should not depend on clients for keeping their registrations alive. Their infrastructure could be missing some logic if they need clients to do stuff to stay connected.</div><div><br></div><div>If the client registration is lost you could try lowering the registration time (again the server could force that as well without any configuration in the client) or you can switch to a reliable transport like TCP or TLS, again is up to the server to force these as well.</div><div><br></div><div>Another culprit could be a broken NAT router, google for "SIP ALG problem” whereby a router can break the SIP signalling  by mangling packets. The solution is found in the search result.<br><div><br></div><div>If you have more specific information about the type of keep alive required by the server we could perhaps formulate a more accurate answer.</div><div><br></div><div>Regards,</div><div><div><div>Adrian</div><div><div><br></div><div><div><div><blockquote type="cite"><div>On 28 Aug 2018, at 15:28, Mike Phillips <<a href="mailto:patlaw@gmail.com" target="_blank">patlaw@gmail.com</a>> wrote:</div><br class="m_-7962045735730114361Apple-interchange-newline"><div><div dir="ltr">

<span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I tried using Blink with a VOIPo account, but the results were unpredictable. Callers complained that they received busy signals or that no one answered. When we switched to another SIP client, the problem went away. We then started using the JK Audio IP2 interface, and the problems returned. Enabling "Keep Alive" in the JK box solved the problem. </span><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Is there a way to tell Blink to Keep Alive? I've read that forwarding a port to the client might help. </div>

<br></div>
______________________________<wbr>_________________<br>Blink mailing list<br><a href="mailto:Blink@lists.ag-projects.com" target="_blank">Blink@lists.ag-projects.com</a><br><a href="http://lists.ag-projects.com/mailman/listinfo/blink" target="_blank">http://lists.ag-projects.com/<wbr>mailman/listinfo/blink</a><br></div></blockquote></div><br></div></div></div></div></div></div></div><br>______________________________<wbr>_________________<br>
Blink mailing list<br>
<a href="mailto:Blink@lists.ag-projects.com">Blink@lists.ag-projects.com</a><br>
<a href="http://lists.ag-projects.com/mailman/listinfo/blink" rel="noreferrer" target="_blank">http://lists.ag-projects.com/<wbr>mailman/listinfo/blink</a><br>
<br></blockquote></div><br></div>