Comments inline... Regards, Nataraju A.B.
-----Original Message----- From: [EMAIL PROTECTED] on behalf of Sarju Garg Sent: Wed 6/14/2006 9:04 PM To: Frank Shearar; SIP Implementors (E-mail) Subject: Re: [Sip-implementors] Query Regarding Handling of Bad 200 Okmessage 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. [ABN] we can't avoid (caller would be changed since signalling completed (INV/200)), if the other user willing to accept the call, but sent a wrong SDP information, we have to gracefully terminate the signalling procedures by INV/200/ACK followed by BYE/200. 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 The information contained in this message may be confidential to Kodiak Networks, Inc. and its subsidiaries and protected from disclosure. If this message did not reach the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby informed that any distribution or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of the message and then delete the message. Thank you. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
