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

[Scott Godin]

I agree.  On one hand if the contact header serves no purpose in a
non-dialog creating request (other than REGISTER) and is causing
interoperability issues, perhaps we should remove it.   On the other hand it
is perfectly legal for it to be in the OPTIONS (or other) request, so I'm
fine with leaving the resip code as is.  : )

 

Scott

 

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: March 11, 2008 11:57 AM
To: Scott Godin
Cc: Mayur; resiprocate-devel at resiprocate.org
Subject: Re: [reSIProcate] Issue with contact URI of 200 OK for OPTIONS

 

            I don't think anything should care, first off. Second, a contact
with no user-part is perfectly valid; "Contact: <sip:192.168.0.12>" is fine.

 

Best regards,

Byron Campen





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

 

 

 

 

 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

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