<div dir="ltr"><div>We aren't translating called numbers. Our current configuration worked until last week. Only thing I did was change an outbound dial peer' destination pattern from an exact match of the UK tech's cell phone to match all UK numbers </div>
<div> </div><div>Our second trunk that only handles outbound UK calls to their PSTN is the only thing I added on CUCM.</div><div> </div><div>I have a TAC caseopen now as well.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Apr 9, 2013 at 11:00 AM, Kenneth Hayes <span dir="ltr"><<a href="mailto:kennethwhayes@gmail.com" target="_blank">kennethwhayes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>Should but how are you translating inbound? 4 as well?<br><br>Sent from my iPhone</div><div><br>On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div>We expect + followed by 11 digits, which we receive. We rely on the inbound trunk settings to strip it to 4 digits. Would traces show if it is being stripped to 4 digits? </div>
<div> </div><div>RTMT isn't giving any clues either.</div>
<div> </div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 10:52 AM, Kenneth Hayes <span dir="ltr"><<a href="mailto:kennethwhayes@gmail.com" target="_blank">kennethwhayes@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="auto"><div>Have you ran RTMT? Also on the trunk have you checked what you are expecting inbound?<br>
<br>Sent from my iPhone</div>
<div><br>On Apr 9, 2013, at 11:49 AM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>There is no carrier involved.</div>
<div> </div><div>The call is UK CUCM -> UK CUBE -> Global Network -> US CUBE -> US CUCM</div><div> </div><div>All of the branches are part of the whole but operate independently which is why it is set up like this.</div>
<div> </div><div>The US CUCM is sending the 503 to the UK caller. The only thing I can think of is that for some reason the trunk isn't acknowledging the set significant digits. </div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 10:26 AM, Kenneth Hayes <span dir="ltr"><<a href="mailto:kennethwhayes@gmail.com" target="_blank">kennethwhayes@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div dir="auto"><div>503 is a carrier issue with the service.<br><br>Sent from my iPhone</div><div><br>On Apr 9, 2013, at 11:05 AM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div>We got that working but I think we have another issue that I'm not sure how to verify.</div><div> </div><div>I didn't change any of the dial-peers pointing to the CUCM yet, I have only modified the one trunk to use port 5070 so it will not interfere with the current trunk for inbound.</div>
<div> </div><div>Now we get a 503 service unavailable for calls from the remote system. Will I need to change my existing dial-peers to xxx.xxx.xxx.xxx:5060 before I add any dial-peers for use on the new trunk that uses 5070? All inbound worked fine until I added this second trunk.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 9:28 AM, Nick Matthews <span dir="ltr"><<a href="mailto:matthnick@gmail.com" target="_blank">matthnick@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr"><div>I've seen this configuration before - sometimes certain call flows require MTP for devices/integrations on the CUCM side. You don't have to set up multiple listening ports on CUBE, as it's indifferent. On CUCM the two trunks have different source ports. If it's outbound from CUCM only that matters, no CUBE changes are required. If you need inbound calls to have MTP only for certain calls changing the port is the best way.<br>
<br></div>I believe with SIP trunks CUCM will not allow two trunks to the same address with the same source port, but it will allow you with H.323 gateways. However, the choice of which of those gateways is basically random and you may think there are two but it's only using one, but that's a H.323 caveat.<br>
<br>-nick<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 1:02 PM, Erick Wellnitz <span dir="ltr"><<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr"><div>Doh. I forgot about changing the port.</div>
<div> </div><div>I think that answers my question. I can have one trunk on 5060 for site to site calls w/ MTP and one trunk to 5061 for least cost routing from/to other sites.</div>
<div> </div><div>This seems like it will suit our needs perfectly.</div><div> </div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 11:09 AM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr"><div><div><div>What's your ultimate goal that you want/need two trunks to a single CUBE?<br>
<br></div>
So in CUBE you would do something like this:<br><br><div style="margin-left:40px"><span style="font-family:courier new,monospace">dial-peer voice 1 voip</span><br>
<span style="font-family:courier new,monospace"></span></div><div style="margin-left:40px"><span style="font-family:courier new,monospace"> description Trunk 1<br></span></div><div style="margin-left:40px"><span style="font-family:courier new,monospace"> session protocol sipv2</span><br>
<span style="font-family:courier new,monospace"></span></div></div><div style="margin-left:40px"><span style="font-family:courier new,monospace"> destination-pattern 1...$<br></span></div><div style="margin-left:40px"><span style="font-family:courier new,monospace"> session-target ipv4:<a href="http://10.1.1.1:5061" target="_blank">10.1.1.1:5061</a><br>
!<br>dial-peer voice 2 voip<br></span><div><span style="font-family:courier new,monospace"> description Trunk 2<br></span></div><span style="font-family:courier new,monospace"> session protocol sipv2<br></span></div><div style="margin-left:40px">
<span style="font-family:courier new,monospace"> destination-pattern 2...$<br></span></div><div><div style="margin-left:40px"><span style="font-family:courier new,monospace"> session-target ipv4:<a href="http://10.1.1.1:5062" target="_blank">10.1.1.1:5062</a></span><br>
<span style="font-family:courier new,monospace">!</span><br></div><div style="margin-left:40px"><span style="font-family:courier new,monospace"></span></div><br></div><div>And then in CUCM you would need to create two new SIP Trunk Security Profiles (Found under System > Security in 8.6), specifying the port in which CUCM should expect to receive the messages. Create your two trunks pointing to the CUBE, using respective SIP Trunk security profiles, and that's how you force an inbound trunk.<br>
<br></div><div>As for the MTP question: You can require MTP for all calls, which can be good and bad. That's no different from H323 trunks to gateways. The require only when needed comes in to play for SIP Early Offer only. And that's a matter of the calling device and whether or not CUCM receives its capabilities or has to make something up using an MTP's capbilities. DTMF relay mismatch (Out of band versus In band) is a different story, and there's no check box for that. That's simply a function of the Media Manager and the MRGL on the SIP trunk, which will correct DTMF mismatches automatically by dynamically using an MTP as needed. So, three different things going on there.<br>
<br></div><div>I hope that helped explain it a bit more. Maybe someone else will fill in some of my gaps.<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 10:22 AM, Erick Wellnitz <span dir="ltr"><<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div dir="ltr"><div> </div><div>If I have two sip trunks from CUCM to CUBE (one which requires MTP and one which does not) how does the CUBE or CUCM know which trunk settings to use for inbound calls to CUCM? </div>
<div> </div>
<div>Is it best to make all of the inbound settings the same and do all of the translations on the CUBE or CUCM translation patterns instead of setting the significant digits?</div><div> </div><div>I'm also remembering someone telling me a while back that if you uncheck the MTP Required that th etrunk will still allocate MTP if needed. Is that correct? It would allow me to only use the one trunk with translations.</div>
<div> </div><div>As always, thanks for the help!</div><div> </div><div> </div></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cisco-voip mailing list</span><br><span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br></div></blockquote></div>
</blockquote></div><br></div>
</div></blockquote></div>
</blockquote></div><br></div>
</div></blockquote></div>
</blockquote></div><br></div>