Hi, Following info might help you,
Refer rfc 6141 section 3.8, *3.8* <https://tools.ietf.org/html/rfc6141#section-3.8>*. Clarifications on Canceling Re-INVITEs* Section 9.2 of RFC 3261 <https://tools.ietf.org/html/rfc3261#section-9.2> [ RFC3261 <https://tools.ietf.org/html/rfc3261>] specifies the behavior of a UAS responding to a CANCEL request. Such a UAS responds to the INVITE request with a 487 (Request Terminated) at the SHOULD level. Per the rules specified in Section 3.3 <https://tools.ietf.org/html/rfc6141#section-3.3>, if the INVITE request was a re-INVITE and some of its requested changes had already been executed, the UAS would return a 2xx response instead. Regards, Anand On Feb 4, 2016 9:41 PM, "Roman Romenskyi" <rromen...@alrus-tele.com> wrote: > Hello, > > If anyone have an idea: > UAC sends RE-INVITE, than send CANCEL request, is this situation is > correct? Because dialog state is connected, and 200 OK for a first > INVITE are sent. > How We should process it? Please point me to rfc. > > Best regards, Roman. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
