Ah yes, I think you're correct that a B2BUA fits my needs. I'll look at sippy too!<br><br>Thanks<br>Rob<br><br><br><div class="gmail_quote">On 3 April 2012 15:18, Stefan Sayer <span dir="ltr"><<a href="mailto:stefan.sayer@googlemail.com">stefan.sayer@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
o Rob Watkin on 04/03/2012 03:20 PM:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your remark about digest authentication explains why I have had<br>
difficulties. I was considering merging SIP interconnects with digest<br>
authenticated SIP trunks in a single gateway. I would prefer not to<br>
use a B2BUA as a PSTN gateway in order to avoid carrier media where<br>
possible. I suspect it might be better to separate out any digest<br>
</blockquote>
<br></div>
a B2BUA doesn't necessarily need to be in the media path.<br>
<br>
if SEMS SBC may fit your needs: you do not set enable_rtprelay in the SBC profile, you can set SEMS SBC to be signaling-only. you can enable SIP auth in the profile. you can use syslog CDR to write CDRs to syslog and then post-process from there; alternatively you can program your own CDR generation on top of call control interface (or, for 1.4, prepaid interface), adapt the rest module and use some web app server or similar. additionally you get stuff like session timers, codec filter, header manipulation etc.<span class="HOEnZb"><font color="#888888"><br>
<br>
Stefan<br>
</font></span></blockquote></div><br>