Hi,
oh, but it is in RFC3261!
In the example the invite arrives at Proxy-B with a max-forwards=1.
The behavior of a proxy should be (according to RFC3261):
<>For all new requests, including any with unknown methods, an element
intending to proxy the request MUST:
1. Validate the request (Section 16.3)
1. Reasonable Syntax
2. URI scheme
* --> 3. Max-Forwards: ... If the request contains a Max-Forwards
header field with a field value greater than zero, the check is passed.
Which will be the case in the example --> Max-forwards is 1, check is
passed!*
4. (Optional) Loop Detection
5. Proxy-Require
6. Proxy-Authorization<>
2. Preprocess routing information (Section 16.4)
3. Determine target(s) for the request (Section 16.5)
4. Forward the request to each target (Section 16.6)
<><> 1. Make a copy of the received request
2. Update the Request-URI
*--> 3. Update the Max-Forwards header field : If the copy contains a
Max-Forwards header field, the proxy MUST decrement its value by one. In
the example: the max-forwards becomes 0.*
4. Optionally add a Record-route header field value
5. Optionally add additional header fields
6. Postprocess routing information
7. Determine the next-hop address, port, and transport
8. Add a Via header field value
9. Add a Content-Length header field if necessary
10. Forward the new request
11. Set timer C
<>5. Process all responses (Section 16.7)
The UA has no intention to forward this request and it will not check
the max-forwards, but it will handle the request.
The max-forwards is one of the headers needed for *proxy processing.
*This is also stated in RFC3261(7.3.1)* :.. *However, it is RECOMMENDED
that header fields which are needed for proxy processing (Via, Route,
Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for
example) appear towards the top of the message to facilitate rapid parsing.
Regards,
Nadine.
Bin Chen wrote:
>Hi，
>Sorry, from the RFC3261 I can find any clue that the INVITE should be
>forwarded when mf = 0 on Proxy-B:
>
>If the request contains a Max-Forwards header field with a field value of zero
>(0), the element MUST
>NOT forward the request. If the request was for OPTIONS, the element MAY act
>as the final recipient
>and respond per Section 11. Otherwise, the element MUST return a 483 (Too many
>hops) response.
>
>Could you explain this?
>
>ABAI
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bogdan Pintea
>Sent: Tuesday, November 14, 2006 12:06 AM
>To: [EMAIL PROTECTED]
>Cc: sip-implementors@cs.columbia.edu; [EMAIL PROTECTED]
>Subject: Re: [Sip-implementors] Sip-implementors] Queryon max-forwards counts
>
>Correct! Only if
>- incoming request has mf=0 and
>- request should be proxied further
>must the Proxy-B generate the 483.
>
>
>[EMAIL PROTECTED] wrote:
>
>
>>Hello,
>>
>>This is not correct. As per RFC3261 chapter 16.3 bullet 3 and chapter
>>16.6 bullet 3
>>Proxy-B will forward the INVITE with Max-Forwards on zero to UA-B.
>>
>>Best regards,
>>
>> Ben.
>>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>
>>
>>>As per 3261: it should reject the request with 483.
>>>
>>>HTH,
>>>Sreeram.
>>>
>>>-----Original Message-----
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED] On Behalf Of
>>>[EMAIL PROTECTED]
>>>Sent: Monday, November 13, 2006 5:57 PM
>>>To: sip-implementors@cs.columbia.edu
>>>Subject: [Sip-implementors] Sip-implementors] Query on max-forwards
>>>counts
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Consider the following flow: (mf=max-forwards)
>>>>
>>>>
>>>>UA-A --- INVITE (mf=2) ---> Proxy-A ---- INVITE (mf=1) --->
>>>>Proxy-B ---- INVITE (mf=0) ---> UA-B
>>>>
>>>>
>>>>In the flow above, should Proxy-B forward the INVITE with
>>>>max-forwards=0 to UA-B or should it reject the request with 483?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Sip-implementors mailing list
>>>Sip-implementors@cs.columbia.edu
>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>>The information contained in this electronic message and any attachments to
>>>this message are intended for the exclusive use of the addressee(s) and may
>>>contain proprietary, confidential or privileged information. If you are not
>>>the intended recipient, you should not disseminate, distribute or copy this
>>>e-mail. Please notify the sender immediately and destroy all copies of this
>>>message and any attachments.
>>>
>>>WARNING: Computer viruses can be transmitted via email. The recipient should
>>>check this email and any attachments for the presence of viruses. The
>>>company accepts no liability for any damage caused by any virus transmitted
>>>by this email.
>>>
>>>www.wipro.com
>>>
>>>_______________________________________________
>>>Sip-implementors mailing list
>>>Sip-implementors@cs.columbia.edu
>>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Sip-implementors mailing list
>>Sip-implementors@cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>>
>>
>
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors@cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors@cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
