<div dir="auto">Isn't Calmanager Service Parameter for max-forwards 12? Says if QSIG set to 15. Nothing about if SIP set to 70. <div dir="auto"><br></div><div dir="auto">is the value reset at CUBE to PSTN to 70 on outgoing? that is what logs seems to show. Makes sense if CUBE is IP-IP gateway. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021, 10:48 AM Gary Parker <<a href="mailto:G.J.Parker@lboro.ac.uk">G.J.Parker@lboro.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Afternoon all, my team and I just got to the bottom of a particularly gnarly problem with a pair of new SIP trunks which I’ll explain in case it’s of use to others, but I have a question at the end regarding SIP configuration on Expressways, particularly in traversal/MRA zones.<br>
<br>
In summary, a small but reproducible volume of calls were silently failing when routed over our new SIP trunks rather than our legacy ISDN30 circuits. We were getting a "483 Too Many Hops" error back from the TSP indication we’d reached the hop limit specified for connecting the call. Most calls were being set up with max-forwards=70 (the default) but certain calls were exiting our network through our CUBES with it set to 12 or 13. Calls from both physical and Jabber softphones where affected, although notably only newer 8800 series SIP handsets.<br>
<br>
I tried forcing max-forwards on the CUBEs to 70 but this didn’t change the outgoing calls that were already having problems.<br>
<br>
Eventually we narrowed it down to calls from MRA registered devices on our expressways (mostly Jabber but with a small number of 8845s in staff home offices), as all failed calls had the same source IP address when we looked at the corresponding CDRs; although this wasn’t visible in the SIP traces which made diagnosis harder (source IP address is the subscriber when looking at the CUBE’s SIP ). A quick look at edge and core expressways showed that “max hops” was to set to 15 in the relevant zones. Cisco documentation says this is the default, but suggests to set it higher if calls are failing with a 483 code. So we set the max hops to 70 and calls are now connecting as expected.<br>
<br>
<br>
<br>
So…question: why is the max hops set so low (15) on expressway zones by default when it’s set to 70 on CUBEs, and is there anything this is likely to break/that I should look out for now I’ve made the change?<br>
<br>
<br>
---<br>
/-Gary Parker----------------------------------f--\<br>
| Unified Communications Service Manager |<br>
n Loughborough University, IT Services |<br>
| tel:+441509635635 <a href="mailto:sip%3Agary@lboro.ac.uk" target="_blank" rel="noreferrer">sip:gary@lboro.ac.uk</a> o<br>
| <a href="https://www.osx.ninja/pubkey.txt" rel="noreferrer noreferrer" target="_blank">https://www.osx.ninja/pubkey.txt</a> |<br>
\r----------------------------------------------d-/<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" rel="noreferrer">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>