Hi Alex, >SIP has no notion of "ON_HOOK" -- is this some constant identifier in >the code you're working on? To remove any misconceptions: Yes, rfc3261 indeed does'nt have any notion of "ON_HOOK". The only reason for writing in capitals was to emphasize on the action the user was performing. Besides, if I may rephrase, my doubt was that if you have already started receiving RTP from remote after sending a 200 OK, then you know that your call has been established. In such case, why do we need to terminate such a call if we have not reeceived an ACK?? Is it only to enforce the reliability of the 200 OK??
Thanks & Regards, Goutam On Tue, Jul 6, 2010 at 11:51 AM, Alex Balashov <[email protected]>wrote: > On 07/06/2010 02:04 AM, goutam kumar wrote: > > > 1) If for an incoming call, the callee dosen't receive an ACK for a 200 > OK, > > should the call fail?? > > Yes, by some notion of "fail," I suppose. > > As someone new to SIP implementation, I recommend that you internalise > early on the importance of living and dying by unambiguous semantics. > What does it mean for a call to "fail" in this scenario? If the > specification itself were written in this equivocal language, no > interoperable real-world implementation would be possible. > > See RFC 3261 13.3.1.4 "The INVITE is Accepted" in the general section > 13.3 "UAS Processing": > > If the server retransmits the 2xx response for 64*T1 > seconds without receiving an ACK, the dialog is confirmed, > but the session SHOULD be terminated. This is accomplished > with a BYE, as described in Section 15. > > > 2) In an outgoing call, if the end-user hangs-up a call, i.e. goes > ON_HOOK > > while the remote party has still not answered the call, should the local > SIP > > UA send a CANCEL message to the callee??? > > SIP has no notion of "ON_HOOK" -- is this some constant identifier in > the code you're working on? > > To answer your question: yes. That is precisely the purpose of the > CANCEL request in the context of telephony signaling applications of > SIP. You seem to already know that this is the intended purpose of > CANCEL, so why do you ask whether the UAC _should_ send it? Would the > message exist if it were not intended to be used in the context > referenced in its definition? This is akin to asking if BYE should be > sent to terminate an established dialog. > > -- > Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Luv n Laf g...@m _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
