<div dir="ltr"><br><div class="gmail_extra">Hi Alex,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On 22 August 2013 12:46, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 08/22/2013 06:25 AM, Steve Davies wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ordinary outbound and inbound calls<br>
Holding / unholding<br>
"Blind" transfers<br>
"Attended" transfers<br>
mid-call reINVITEs (session timers?)<br>
T.38<br>
Subscriptions<br>
</blockquote>
<br></div>
The specificity of almost all of these scenarios lies in the user agents that are the endpoints of the call, and not the proxy.<br>
<br>
So, while they might be useful end-to-end tests of your entire service delivery platform, they are broken down according to a taxonomy that differs from the proxy's state machine and functional orientation.<br>
<br></blockquote><div><br></div><div>I do take your point.  </div><div><br></div><div>So since I correctly handle initial requests and the replies, and can handle in-dialog requests and replies, and deal with those hop-by-hop requests, I can just relax and be happy?</div>
<div><br></div><div>As you say, my different end-user scenarios boil down to the same "elements", but in practice my tests did find a problem with the way my Enswitch proxy was handling loose-routed NOTIFYs.</div>
<div><br></div><div>Users are very good at finding odd corner-cases, so it seems helpful to consider in advance flows that exercise unusual paths through the proxy config.</div><div><br></div><div>Regards,</div><div>Steve</div>
<div><br></div><div><br></div></div>
</div></div>