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
