Hi Julian, If I unterstood correctly, your fix work for OPTIONS send whithin an existing session, right? -- you are right, i used only for an existing session
I had a carrier which sent OPTIONS instead RE-INVITE/UPDATE for keepalive. :) Regards, Ivan On Wed, Sep 11, 2013 at 11:59 AM, Julian Santer <[email protected]>wrote: > > Hi Alex, > > imho your alright if your purpose is to see if something is answering you. > But if you want to see if the host, which is pinged with OPTIONS, is ready > to receiving sip packets, it is better to check if we got a 200 OK. It > could be, that the host is misconfigured and therefore it answer with 404 > Not Found. And also all other sip request are responded with 404 Not Found. > > Regards, > Julian Santer > > > Am 11.09.2013 11:00, schrieb Alex Balashov: > > > On 09/11/2013 04:43 AM, Ivan Milivojevic wrote: > > > >> /* addon for OPTIONS */ > >> > >> } else if( req.method == "OPTIONS" ){ > >> > >> > >> dlg.reply(req,200,"OK"); > > > > Technically, neither of these behaviours is correct. The reply to be > > OPTIONS should be 200 OK if the request URI corresponds to a local > > resource that exists, and 404 Not Found if it does not correspond to > > such a resource. > > > > However, insofar as OPTIONS requests are used for keepalive / ping > > purposes, it should not matter which reply is sent. As long as some > > reply is received, that means the remote peer is alive, right? > > > > -- Alex > > > > > ______________________________**_________________ > Sems mailing list > [email protected] > http://lists.iptel.org/**mailman/listinfo/sems<http://lists.iptel.org/mailman/listinfo/sems> >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
