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

[Scott Godin]

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 at resiprocate.org
[mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of Mayur
Sent: Tuesday, November 06, 2007 4:39 PM
To: resiprocate-devel at resiprocate.org
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

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20071106/4974a3dd/attachment.htm>