Thanks Frank, But in this case, the call is matured and hence charged.
Also, if there is a need of some message like NACK which can be sent instead of ACK in SIP. Regards Sarju # 9810304396 ----- Original Message ----- From: "Frank Shearar" <[EMAIL PROTECTED]> To: "SIP Implementors (E-mail)" <[email protected]> Sent: Wednesday, June 14, 2006 3:40 PM Subject: Re: [Sip-implementors] Query Regarding Handling of Bad 200 Okmessage > Wouldn't it be better to send the ACK (the 200 OK is well-formed from the > SIP perspective), and then BYE the call immediately, with some appropriate > explanation (like, say, a Warning header)? As Sarju Garg says elsewhere, > the > callee's just going to keep resending that 200 OK until it times out > (typically in what? 64 seconds?). > > frank > > "Uttam Kumar Sarkar" <[EMAIL PROTECTED]> wrote: > >> If 200 OK of INVITE is bad, then you may choose not to send ACK. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Sarju >> Garg >> Sent: Tuesday, June 13, 2006 1:02 AM >> To: SIP Implementors (E-mail) >> Subject: [Sip-implementors] Query Regarding Handling of Bad 200 Ok >> message >> >> >> Hi all, >> >> I would request someone to let me know what should be the handling in >> case UAC receives a bad 200 Ok message. For example, in case SDP format >> is not ok. >> >> Thanks in advance >> >> Regards >> Sarju >> # 9810304396 >> ----- Original Message ----- >> From: Rayees Khan >> To: Stephen Paterson >> Cc: SIP Implementors (E-mail) >> Sent: Monday, June 12, 2006 11:57 PM >> Subject: Re: [Sip-implementors] Session timer - how to indicate the >> session hasnot changed >> >> >> >> Hi Stephen, >> >> This is a protocol violation, however, the handling of such things is >> highly local to the Endpoint. An EP can choose to just check the o-line >> and decide on the basis of this whether to process rest of SDP or not. >> >> >> regards >> Rayees >> >> >> >> [EMAIL PROTECTED] wrote: ----- >> >> >> To: "SIP Implementors (E-mail)" <[email protected]> >> From: Stephen Paterson <[EMAIL PROTECTED]> >> Sent by: [EMAIL PROTECTED] >> Date: 06/12/2006 11:31AM >> Subject: [Sip-implementors] Session timer - how to indicate the >> session hasnot changed >> >> Hi all, >> >> The last paragraph of section 7.4 of RFC 4028 states: >> >> 'It is RECOMMENDED that the UPDATE request not contain an offer [4], >> but a >> re-INVITE SHOULD contain one, even if the details of the session >> have not >> changed. In that case, the offer MUST indicate that it has not >> changed. In >> the case of SDP, this is accomplished by including the same value >> for the >> origin field as did previous SDP messages to its peer. The same is >> true for >> an answer exchanged as a result of a session refresh request; if it >> has not >> changed, that MUST be indicated.' >> >> What happens when the refresher sends an offer with an unchanged >> origin >> field, receives a 200 OK with an unchanged origin field but an 'm=' >> line >> that was present in the most recent offer/answer exchange is missing >> from >> the UAS response? >> >> My gut feeling is that the UAS is out of spec (and the entire SDP >> should be >> unchanged) but according to the quote above, only the origin field >> needs to >> be unchanged in order to indicate that the session details are also >> unchanged. >> >> At the moment this causes problem for our SIP implementation as it >> has no >> control over the media. It simply raises an event to the application >> that is >> controlling the media to indicate that the session parameters have >> changed. >> We don't want to be doing this for session refresh requests unless a >> genuine >> offer/answer exchange has been negotiated during the transaction. >> >> If the UAS is out of spec, how should the UAC behave? >> If not, is there anywhere in the RFCs that specifies more clearly >> how to >> identify that a media session is unchanged? I haven't been able to >> find >> anything in SIP, SDP, Session Timer or Offer Answer (which isn't to >> say the >> answers aren't there somewhere). >> >> It may well be the case that I just have to change our logic and >> ignore all >> of the SDP if the 'o=' is unchanged. Part of my query is to ensure >> that, if >> I do this, I don't break anything elsewhere. >> >> Cheers >> >> Steve >> >> Steve Paterson >> Software Engineer >> Aculab >> Tel: +44 (0) 1908 273866 >> Fax: +44 (0) 1908 273801 >> Email: mailto:[EMAIL PROTECTED] >> Website: http://www.aculab.com >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> >> *****FSS-Private *****" DISCLAIMER: This message is proprietary to >> Flextronics Software Systems Limited (FSS) and is intended solely for >> the use of the individual to whom it is addressed. It may contain >> privileged or confidential information and should not be circulated or >> used for any purpose other than for what it is intended. If you have >> received this message in error, please notify the originator >> immediately. If you are not the intended recipient, you are notified >> that you are strictly prohibited from using, copying, altering, or >> disclosing the contents of this message. FSS accepts no responsibility >> for loss or damage arising from the use of the information transmitted >> by this email including damage from virus." >> >> >> >> ------------------------------------------------------------------------ >> ------ >> >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
