Summary:ASTERISK-05326: [patch] Add Max-Forwards to all requests
Reporter:Olle Johansson (oej)Labels:
Date Opened:2005-10-19 13:19:17Date Closed:2008-01-15 15:52:01.000-0600
Versions:Frequency of
Environment:Attachments:( 0) maxforwards.txt
Description:This patch fixes interoperability issues reported at SIPit.
We need to add a Max-Forwards header to ALL requests.

The code for handling max-forwards in transfer today is wrong, we never forward a SIP message and should not change that header...
Comments:By: Mark Spencer (markster) 2005-10-22 21:38:10

Fixed in CVS head, thanks!

By: x martinp (martinp) 2005-10-26 16:08:05

This patch is wrong! Since we do 302 moved temporarity with Transfer app we _have_to keep track how many times the call _HAS_ALREADY_BEEN_TRANSFERED_

You can't simply say all the time that maxforwards its 70 (default value).
The maxforwards value should be read from the SIP message and decreased and placed back as it was ... it doesn't have to be in sip_pvt though ...

There is a chance now for the calls to loop forever if the Transfer app is used! Way to go ...

By: Olle Johansson (oej) 2005-10-27 15:20:12

A 302 is a final reply to a SIP message, not a forward of a SIP message... The SIP message is not put in a loop.

Proxies handle the forwarding counter. We're not a proxy.

But I might be wrong, please give me some references on where Max-Forwards is used this way and I'll fix it back.

By: x martinp (martinp) 2005-10-28 12:56:28


It's used with Transfer application. Consider a call coming to asterisk extensions and before it's answered the Transfer app is called which generates the 302 SIP message

Now the incoming call came with INVITE and can have a max-forwards line in the SIP nessage ... and if we *do*forward* that call further we should decrease it.

My concern only affects the Transfer app.

By: Olle Johansson (oej) 2005-10-29 07:40:05

THe max-forwards header as I understand it is for ONE sip MESSAGE, not a dialog. You are talking about a dialog, which is entirely different. But I might be wrong again, it's a complex standard. Can you please dig into this so we get clarification?

By: Olle Johansson (oej) 2005-10-30 03:12:32.000-0600

From the RFC:
"Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It
consists of an integer that is decremented by one at each hop."
...the 302 is a response to a request.

"Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit
on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-
Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many
Hops) error response.
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."
...we are the destination, not a hop.

"20.22 Max-Forwards
The Max-Forwards header field must be used with any SIP method to limit the number of proxies or
gateways that can forward the request to the next downstream server. This can also be useful when the client
is attempting to trace a request chain that appears to be failing or looping in mid-chain.
The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this
request message is allowed to be forwarded. This count is decremented by each server that forwards the
request. The recommended initial value is 70.
This header field should be inserted by elements that can not otherwise guarantee loop detection. For
example, a B2BUA should insert a Max-Forwards header field.
Max-Forwards: 6"
...We are not a proxy.

I can find no text that says that we should decrease a max-forwards header in the end pint (the UA) before sending a 302 response to a request. That is simply not correct. Or?

Please confirm your findings, Martin, so that we can agree and close this or fix the code back if I am wrong.

By: Olle Johansson (oej) 2005-10-30 03:16:13.000-0600

"The INVITE is Redirected If the UAS decides to redirect the call, a 3xx response is sent. A 300 (Multiple
Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact
header field containing one or more URIs of new addresses to be tried. The response is passed to the
INVITE server transaction, which will deal with its retransmissions."

...so I think it's up to the client that sends the INVITE to handle the number of redirections accepted.

By: Kevin P. Fleming (kpfleming) 2005-10-31 17:19:56.000-0600

I would agree... Max-Forwards is for use by SIP proxies, it has nothing to do with 'call forwarding' in spite of the header name.

By: Digium Subversion (svnbot) 2008-01-15 15:52:01.000-0600

Repository: asterisk
Revision: 6844

U   trunk/channels/chan_sip.c

r6844 | markster | 2008-01-15 15:52:00 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix max forwards interoperability (bug ASTERISK-5326)