Dear Brett & Ankur,
What i understand is the call was not answered during ringing the user A cancels the call. Logically it should be followed by 487 from peer side, in this case it is not happening. Firstly what is the purpose of clearing an early dialog. In which cases this is suppose to happen. The transaction in the INVITE is branch=z9hG4bK59nh4500b8pgfqsrk541.1 The BYE transaction is branch=z9hG4bKqut31h00507g9l8hu341.1 and it associated 200 OK is received. If the BYE is the early dialog release then INVITE transaction clearing should be done using CANCEL using the branch=z9hG4bK59nh4500b8pgfqsrk541.1 . Also It’s absolutely crucial that Peer side 487 be sent. Otherwise,any stateful proxies will not properly release the session. Please correct if im wrong. On Thu, Apr 9, 2015 at 11:38 AM, Imran Saleem <imran....@gmail.com> wrote: > 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 > > -- 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
