[Devel] Structure of "487" and "200 Ok" reponses to CANCEL request without provisional response from second hop proxy

[Daniel-Constantin Mierla]

Hello,

coud you post the network grep for such situation? Be aware that 487 is 
for initial INVITE while the 200 is for CANCEL. Also, in this case, the 
UA has to ACK the 487, not the 200.

An the snippet you posted from RFC states that the reply for initial 
INVITE and the reply for the CANCEL should have the same To tag. Are you 
experiencing something else (I am not able to do a test right now, so, 
if you can post some network traces, would really help to get you a 
faster respose).

To make it a bit clear, 487 is the response for the original request.

Cheers,
Daniel

On 09/15/05 23:27, reticent wrote:

> Recently a feature was added to OpenSER where it would work around 
> most UACs lack of implementing section 9.1 of RFC3261 (which states 
> "If no provisional response has been received, the CANCEL request MUST 
> NOT be sent;) in that it would wait for the second hop entity to 
> repond to the INVITE request before generating a CANCEL request and 
> sending it on.
>
> I'm working with a Cisco 7960 sw-ver7.5 and i'm experiencing some 
> issues regarding the "487" and "200 ok" response to the CANCEL message 
> sent before SER receives a provisional response from the second hop 
> routing entity.
> SER sends the 487 and than the 200 ok but the cisco 7960 does not 
> acknowlege the 200 ok with an ACK.
> Reading RFC3261 i found the section that describes the behaviour of 
> the UAS (SER) in this situation and the recommended behaviour isn't 
> followed by SER, which is (Section 9.2): "Regardless of the method of 
> the original request, as long as the CANCEL matched an existing 
> transaction, the UAS answers the CANCEL request itself with a 200 (OK) 
> response. This response is constructed following the procedures 
> described in Section 8.2.6 noting that the To tag of the response to 
> the CANCEL and the To tag in the response to the original request 
> SHOULD be the same. The response to CANCEL is passed to the server 
> transaction for transmission."
>
> In the response (487 and 200 ok) SER generates and adds a "tag=" 
> argument to the "To:" header function where the response to the 
> original request did not have that tag.
>
> Now i don't know if this is an issue(as, in the spec, it is a SHOULD, 
> not a MUST), but i am having a problem with the interaction and came 
> across this in the specification so i thought i would mention it here.
>
>
> tavis
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>