Hi Sampat , Please find my answers inline :
*If you look at the trace , we can say that INVITE message is being sent 7 times while SBG returning with 504 error 11 times.However my source node i.e MSS is expecting 487 response from the SBG while it receives 504 from it.May be this is the reason why my MSC i.e source node is not giving an ACK. * ** As a client ,it should not wait for specific message(487) for sending ACK ..As RFC-2543 compliant UAS will never send 487 for cancel. So your Source node MUST reply with ACK for any error response . *Is it possible that the issue gets resolved if we can make sure that the SBG doent send that 7th REINVITE message towards destn.* Ist thing ..let me clarify its not Re-INVITE ..Its same INVITE getting retransmitted .And I don't think this issue will get resolved even if SBG don't send 7th INVITE towards Destination . Anyhow your Source node has to send ACK. *Also i would like to know what things need to be verified from source side so as to troubleshoot the missing ACK mesg. * You can check that after sending CANCEL ,your source node should be ready to accept any final response and send ACK . Your source node should not be waiting only for 487 response .If that is the case ,then fix your source node. Thanks & regards Ankur Bansal On Fri, Sep 20, 2013 at 2:44 PM, sampat patnaik <[email protected]>wrote: > Hi, > > If you look at the trace , we can say that INVITE message is being sent 7 > times while SBG returning with 504 error 11 times.However my source node > i.e MSS is expecting 487 response from the SBG while it receives 504 from > it.May be this is the reason why my MSC i.e source node is not giving an > ACK. > > Is it possible that the issue gets resolved if we can make sure that the > SBG doent send that 7th REINVITE message towards destn. > > Also i would like to know what things need to be verified from source side > so as to troubleshoot the missing ACK mesg. > If you want i can share the required wireshark traces too. > > Thanking all and expecting a quick response > > Regards > Sampat > > > > > ------------------------------ > *From:* ankur bansal <[email protected]> > *To:* sampat patnaik <[email protected]> > *Cc:* "[email protected]" < > [email protected]> > *Sent:* Friday, 20 September 2013 2:12 PM > *Subject:* Re: [Sip-implementors] Fw: SIP ISSUE > > Hi Sampat, > > 1. I guess there is no problem with SBG node as timer value on SBG is > configured in way that it retransmit message > 11 times . That's why SBG sending INVITE 11 times to Destination > before Timer B fires and then after timeout it > starts posting error response 504 (11 times again) to Source as ACK > not coming . > > 2. SBG not forwarding CANCEL to Destination as SBG never got even 100 > trying from Destination so CANCEL cannot > be sent out from SBG . > > 3. Yes there is scope of improvement on SBG side ,it can stop > retransmitting INVITE to Destination after getting Cancel from Source and > should send 487 response to Source . > > *Problem here seems to be with Source* : As its expected from Source to > gracefully send ACK for every final response . > > > > Thanks & Regards > Ankur Bansal > > > On Fri, Sep 20, 2013 at 11:08 AM, sampat patnaik <[email protected]>wrote: > > Hi, > > Greetings of the day!!! > > > Can anyone help me on this ongoing issue. > > Regards > Sampat > > > ----- Forwarded Message ----- > From: sampat patnaik <[email protected]> > To: Rupesh Mothe <[email protected]>; " > [email protected]" < > [email protected]> > Sent: Thursday, 19 September 2013 11:50 PM > Subject: Re: [Sip-implementors] SIP ISSUE > > > > Hi Rupesh, > > 1)Incase that case what is expected out of source node..i.e the SBG(proxy) > must be expecting an ACK message to the error 504 sent..right? > 2) second query would be why not this CANCEL message is forwarded to next > hop i.e destination node .should the flow mentioned below be followed: > > SOURCE SBG(Proxy 1) DESTINATION > | | | > | INVITE F1 > | | > |--------------->| INVITE F2 | > | 100 F3 |--------------->| > |<---------------| INVITE F4 > | |--------------> | > INVITE F5 > | |--------------> | > | > | INVITE F6 | > | --------------->| > INVITE F7 > ---------------> > INVITE F8 > ---------------> > | > | | > | CANCEL F9 | | > |--------------->| | > | 200 F10 | | > |<---------------| CANCEL F11 | > | |--------------->| > | | 200 > F12 | > | |<---------------| > | | | > | | 487 F17 | > | |<---------------| > | | ACK F18 | > > | |--------------->| > | | | > | | | > | | | > | | > | > | | | > | 487 F19 | | > |<---------------| | > | ACK F20 | | > |--------------->| | > | > | > > 3) i would suspect that the INVITE in F11 message(trailing mail) is becoz > the cancel request is not being sensed by the SBG and is busy > in resending the REINVITE message to the destination(maximum 7 invites due > to timer issue of 64*T1 i.e 32secs) .Also i thing the error > 504 is populated because there is time out error generated after destn > server failed to respond to 7th(F11) reinvite request and is > flooded to sorce side expecting an ACK before ending the entire process. > > 4)what would have happened had there not been that F11 invite message? > > Thanks in advance. > > Regards > Sampat > > > > > ________________________________ > From: Rupesh Mothe <[email protected]> > To: sampat patnaik <[email protected]> > Sent: Thursday, 19 September 2013 11:28 PM > Subject: RE: [Sip-implementors] SIP ISSUE > > > Hi Sampat- > > This is expected behaviour , 504 should get retransmitted no issues , you > need to set the retransmit value in proxy to minimize the flooding > Issue i am seeing here is the 11th INVITE getting transmitted from proxy , > once it sent 200OK for CANCEL it should not send retransmitted INVITE any > more > > > Thanks & Regards, > Rupesh Mothe | NPA | Tech Mahindra > Mobile: +91 9960727012 , +233-263597627 > > > -----Original Message----- > From: sampat patnaik [mailto:[email protected]] > Sent: 19 September 2013 23:21 > To: [email protected] > Subject: [Sip-implementors] SIP ISSUE > > Hi, > > I am currently facing an issue that as follows :..my question is why > PROXY1 is unable to process the CANCEL message in this case. > > CASE: REMOTE NODE IS COMPLETELY DOWN and we need to understand why > flooding of 504 sip error is happening towards source side while it is not > responding withACK mesg > > > SOURCE Proxy 1 REMOTE NODE > > | | | > | INVITE F1 | | > |--------------->| INVITE F2 | > | 100 F3 |--------------->| > |<---------------| INVITE F4 > | |--------------> | > INVITE F5 > > | |--------------> | > | | INVITE F6 | > | --------------->| > INVITE F7 > ---------------> > INVITE > F8 > ---------------> > | | | > | CANCEL F9 | | > |--------------->| | > | 200 F10 | | > |<---------------| INVITE F11 | > > | |--------------->| > | | | > | | | > | 504 F19 | | > |<---------------| | > > | 504 F20 | | > |<---------------| | > | 504 F21 | | > |<------------- | | > | | | > > | | | > > > > 504 message is sent 11 times from proxy to source..why this abnormal > behavior? > > Thanks in advance > > Regards > Sampat > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ============================================================================================================================Disclaimer: > This message and the information contained herein is proprietary and > confidential > and subject to the Tech Mahindra policy statement, you may review the > policy at <a href="http://www.techmahindra.com/Disclaimer.html";> > http://www.techmahindra.com/Disclaimer.html</a> externally and <a href=" > http://tim.techmahindra.com/tim/disclaimer.html";> > http://tim.techmahindra.com/tim/disclaimer.html</a> internally within > Tech > Mahindra.============================================================================================================================ > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
