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

[Byron Campen]

	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 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/137edf59/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080312/137edf59/attachment.bin>