*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.*
*[Ankur]: Side A ideally should send CANCEL when user cancelled the call .BYE can be sent in this case but should be sent when side A got multiple early dialogs and side A is sure to terminate one specific early dialog and keep using other early dialog .* *As sending BYE in early dialog where single early dialog exists , increasing extra signalling messages and confusion too .* *Firstly what is the purpose of clearing an early dialog. In which cases this is suppose to happen.* *[Ankur]:As mentioned above, in case of forking when side A maintining multiple early dialogs and side A has some user preference to get call esatblished with sideB1 only and not with sideB2 so sideA can send BYE towards sideB2 with that to-tag.* *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.* *[Ankur : Right ,CANCEL and INVITE branch id will be same to tell UAS that CANCEL is to terminate which INVITE txn]* On Thu, Apr 9, 2015 at 3:05 PM, Imran Saleem <imran....@gmail.com> wrote: > 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
