| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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] 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 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 |