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 <[email protected]> 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 > [email protected] > > > 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:[email protected] o > | https://www.osx.ninja/pubkey.txt | > \r----------------------------------------------d-/ > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
