Dear Ankur and Brett & paul thanks for sending in valuable advise. I will go through the details.
Many thanks, On Thu, Apr 9, 2015 at 11:25 AM, ankur bansal <abh.an...@gmail.com> wrote: > Hi Imran > > I assume Side B is not compliant to standards. > 1. On getting BYE ,side B should clear dialog associated with INVITE > transaction but INVITE transaction should be alive . > In your case side B has not sent any final response for INVITE to > complete the INVITE transaction . > It seems Side B dont have handling of BYE in early-dialog so clearing > Invite trxn internally without any final response . > > 2. But worst thing from side B is not sending response to CANCEL .Even if > INVITE transaction is cleared ,side B should send 481 to CANCEL atleast > .Its like side B getting cancel as out of dialog request so dont have any > clue what to respond. > > Ideal behavior is to keep Invite txn alive and respond 200ok to Cancel and > then 487 response to INVITE to gracefully clear the invite transaction . > > > On Wed, Apr 8, 2015 at 6:48 PM, Brett Tate <br...@broadsoft.com> wrote: > >> > The call is dropped by the peering end (Side-B) using >> > the 200OK for the BYE. but still the Side A continue >> > sending the CANCEL messages. >> > >> > I want to know in which circumstances the side A keeps >> > sending the CANCEL messages. and which side is >> > complaint to RFC standards,I have been to the RFC3261 >> > and feel that both sides are complaint to the RFC. >> >> Sending BYE over an early dialog is allowed; however, it is useless extra >> messaging unless truly only desiring to release a specific early dialog. >> >> I assume that the UAS (or a middle box) does not know how to act upon >> receiving a BYE for an early dialog (or has a software error). The BYE >> only >> released the specific early dialog; the INVITE transaction >> continues/completes separately. Upon receiving the BYE, the UAS should >> have >> completed the INVITE transaction (such as by sending a 487) if there >> wasn't >> a reason to allow the INVITE transaction to continue. >> >> Since the BYE only released a specific early dialog (and no INVITE final >> response was received to indicate otherwise), the UAC still needed to send >> CANCEL. The receiver should have processed the CANCEL according to RFC >> 3261 >> section 9.2. >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > -- Br, Imran Saleem +966-533-414475 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
