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

Martin Koenig martin.koenig at toplink.de
Thu Sep 22 08:54:43 CEST 2005


Hello,

the only difference I see between this and the behaviour of rel_0_9_0 is
that the to-Tags of 200 and 487 are equal in the given case, and are
non-equal with rel_0_9_0. Maybe this helps.

Regards,
Martin 

> -----Original Message-----
> From: devel-bounces at openser.org 
> [mailto:devel-bounces at openser.org] On Behalf Of Tavis P
> Sent: Wednesday, September 21, 2005 7:49 PM
> To: devel at openser.org
> Subject: Re: [Devel] Structure of "487" and "200 Ok" reponses 
> to CANCEL requestwithout provisional response from second hop proxy
> 
> ngrep trace attached
> 
> I'm running the CVS HEAD version of OpenSER, checked out last week
> 
> Again i'm not certain that this is the problem, however it 
> was the only 
> issue i could find
> 
> Thanks!
> Tavis
> 
> 
> Daniel-Constantin Mierla wrote:
> 
> > 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
> >>
> >
> >
> 
> 




More information about the Devel mailing list