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
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
