Re: [reSIProcate] Issue with contact URI of 200 OK for OPTIONS

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

I don’t think there should even be a Contact header in a out-of-dialog OPTIONS response.  The following code appears to be the culprit in Helper.cxx:

 

   // .bwc. If CSeq is malformed, basicCheck would have already attempted to

   // parse it, meaning we won't throw here (we never try to parse the same

   // thing twice, see LazyParser::checkParsed())

   if (responseCode/100 == 2 &&

         !response.exists(h_Contacts) &&

         !(response.header(h_CSeq).method()==CANCEL) )

   {

      // in general, this should not create a Contact header since only requests

      // that create a dialog (or REGISTER requests) should produce a response with

      // a contact(s).

     

      NameAddr contact;

      response.header(h_Contacts).push_back(contact);

   }

 

Does anyone know why this code is there?

 

Scott

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Mayur
Sent: Tuesday, November 06, 2007 4:39 PM
To: resiprocate-devel@xxxxxxxxxxxxxxx
Subject: [reSIProcate] Issue with contact URI of 200 OK for OPTIONS

 

Hi,

    I have a SIP client using the reciprocate stack. The problem I am facing is that when the client replies to OPTIONS request from the pbx, the 200 OK contains contact header with missing user part in the URI. It seems that the Helper method makeResponse() is not providing the proper contact URI. This causes the pbx to stop sending OPTIONS (used as keep alives) and ignore the client presence.

Is there a bug here in resip?

 

Regards,

Mayur