[cisco-voip] Of Expressways and max-forwards...

[Lelio Fulgenzi]

Thanks for sharing. My expressways were set up by professional services with almost little to no “learning” involved. 

Also, I think we should follow in the footsteps of our scientific brothers and sisters and name these anomalies after the person that first finds them.  

;)

Sent from my iPhone

> On Nov 15, 2021, at 10:41 AM, Gary Parker <G.J.Parker at lboro.ac.uk> wrote:
> 
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp at uoguelph.ca
> 
> 
> 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.
> 
> 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.
> 
> I tried forcing max-forwards on the CUBEs to 70 but this didn’t change the outgoing calls that were already having problems.
> 
> 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.
> 
> 
> 
> 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?
> 
> 
> ---
> /-Gary Parker----------------------------------f--\
> |     Unified Communications Service Manager      |
> n      Loughborough University, IT Services       |
> |     tel:+441509635635 sip:gary at lboro.ac.uk      o
> |        https://www.osx.ninja/pubkey.txt         |
> \r----------------------------------------------d-/
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip