reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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

I would also not be surprised if there were implementations out there that would get upset if it was missing.

Best regards,
Byron Campen

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@xxxxxxxxxxxx] 
Sent: March 11, 2008 11:57 AM
To: Scott Godin
Cc: Mayur; resiprocate-devel@xxxxxxxxxxxxxxx
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@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
 
 
 
 
 
_______________________________________________
resiprocate-devel mailing list
 

Attachment: smime.p7s
Description: S/MIME cryptographic signature