On Tue, Apr 19, 2011 at 11:55 AM, Michael Scheidell < michael.scheid...@secnap.com> wrote:
> On 4/19/11 11:53 AM, Michael Scheidell wrote: > > On 4/19/11 11:39 AM, Tony Graziano wrote: > > > what you you think of implementing an (optional) 'ping' (sip method > 'OPTIONS') at specified intervals? > > > There is an assumption that all itsp's support that... it would be > better to send it a keepalive, and observe the response, parse it and > send an alarm... > > > the RFC's, split stuff into 'CAN/SHOULD/ and MUST' > > this is a MUST. > > 5.2. Processing OPTIONS messages > > A SIP entity that receives an OPTIONS message MUST respond with a > status code indicative of its present ability to process SIP > signaling messages. Refer to section 6 > <http://tools.ietf.org/html/draft-jones-sip-options-ping-00#section-6> for > response codes. > > > if they don't respond (even to say they don't support options. ) > > oh, sipx responds that it doesn't support options when sent by a itsp > gateway to sipxproxy... > > but, guess what, it MUST respond with a 200 Ok if it is ready to receive > (must is not a should, must is not a can, must is a must. eg: sipx isn't > rfc compliant if it doesn't) > Pleae read the RFC carefully. Your "guess what, it MUST respond with 200 Ok" is precisely what it claims to be - i.e. a guess. It MUST respond but not necessarily with 200 OK. SipXbrige is NOT a phone. Out of dialog OPTIONS are responded to by returning the list of supported codecs. SipXbridge cannot respond with a 200 OK becuase it does not support its own codecs. It merely relays SDP Offers and Answers after suitably re-writing them. If the ITSP supports Sip Outbound then a CRLFCRLF will be responded to with a CRLFCRLF. That is what the keepalive is doing. Unfortunately, ITSPs do not necessarily support SIP outbound. Best to rely on standard SIP failover mechanisms (use DNS SRV and re-dispatch the INVITE to the redundant ITSP proxy server or redundant SIP trunk). You cannot track the state of the world. Do what I do -- be lazy. Ranga > > > 6. SIP Response Codes Handling > > A SIP entity MUST respond to an OPTIONS method with a 200 response > code when it is willing and able to process SIP messages. > > When a receiving SIP entity is unable to process SIP messages, it > SHOULD respond with a 503 response code. A 503 response code is > also used when a SIP entity is placed into a maintenance mode to > indicate that it SHOULD NOT accept new SIP dialogs. > > When a receiving SIP entity is experiencing heavy load, but still > willing to accept new dialogs, it SHOULD return a 486 response code. > In receipt of a 486, the querying SIP entity SHOULD make an effort > to avoid establishing new dialogs with the heavily loaded server > until it subsequently receives a 200 from that server. > > > -- > Michael Scheidell, CTO > o: 561-999-5000 > d: 561-948-2259 > ISN: 1259*1300 > > *| *SECNAP Network Security Corporation > > - Best Intrusion Prevention Product, Networks Product Guide > - Certified SNORT Integrator > - Hot Company Award, World Executive Alliance > - Best in Email Security, 2010 Network Products Guide > - King of Spam Filters, SC Magazine > > > ------------------------------ > > This email has been scanned and certified safe by SpammerTrap®. > For Information please see http://www.secnap.com/products/spammertrap/ > ------------------------------ > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- M. Ranganathan
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
