SIP Trunk: 483 too many hops and Max-Forward:13

[ictservicedesk]

Hi, looking for a steer.  Having problems with some, but not all, outgoing calls to specific numbers.  I've traced this and we can see "483 Too many hops" messages coming from the SIP trunk provider.  I can see that CUCM is placing "Max-forwards:13" in the INVITE header to the provider which seems low - in other community posts I've seen reference to 70 being the usual value?

Questions:

- where can I check \ change the Max-Forwards value?  I can't see a setting on the trunks or the SIP profile?

- does 13 Max Forwards seem right, or is that very low?

Thanks

Lee

[b.winter]

If you are using CUBE between CUCM and your SIP Trunk provider, use sip-profiles to modify the "max-forward" header.

13 is way to low...

[Roger Kallberg]

13 is as you mention the standard value that CM sets for this and it can AFAIK not be altered in CM. However as @b.winter pointed out you can modify this by a SIP profile in your SBC (Cube). This would be an example of how to do that.

voice class sip-profiles 10
 request ANY sip-header Max-Forwards modify "Max-Forwards:(.*)" "Max-Forwards: 70" 

[ictservicedesk]

Thanks all.  Unfortunately it's a direct trunk between CUCM (12.0) and the SIP provider, we don't have CUBE.   I guess I'm going to have to resort to Normalisation Scripts?  I saw this post but don't really want to start hacking around with code unless essential: https://community.cisco.com/t5/ip-telephony-and-phones/sip-trunk-integration-isp/m-p/3337989#M358490

Lee

[b.winter · Accepted solution]

Yes, then you have to use SIP normalization scripts in CUCM and bind it to the SIP trunk.

[cehr_itsupport]

Thanks - I'll give that a try!

[ictservicedesk]

Update: added the example code to the SIP Normalisation Script and I can now see 70 max-forwards in the outoging INVITE headers.  Thanks everyone. Lee

[Roger Kallberg]

Connecting like you have done is an absolutely terrible thing to do. It will expose your whole internal infrastructure to your service provider.

[cehr_itsupport]

Thanks Roger - good to know and to add, there are other mitigations in place I believe

[kaftab001]

As per RFC 3261, setting Max-Forwards is not forced to make it 70. It uses the term Should.

A UAC MUST insert a Max-Forwards header field into each request it
   originates with a value that SHOULD be 70.  This number was chosen to
   be sufficiently large to guarantee that a request would not be
   dropped in any SIP network when there were no loops, but not so large
   as to consume proxy resources when a loop does occur.  Lower values
   should be used with caution and only in networks where topologies are
   known by the UA.

Thanks