Hello,
I'm using most recent revision from media-update branch.
SipUserAgent::prepareContact() seems to behave strangely when dealing
with request resent with credentials (in response to 401). Well, it
seems to work incorrectly in general. Here is the example:
1. Send REGISTER request with Contact specifying LINEID as url-param
Contact: <sip:[EMAIL PROTECTED]:5078;LINEID=c3ba12b98bd9>
2. Receive 401
3. Request is being resent by sipX with Contact, which now specifies
LINEID as header field parameter:
Contact: <sip:[EMAIL PROTECTED]:5078>;LINEID=c3ba12b98bd9>
4. Receive 200 OK with bindings specifying
<sip:[EMAIL PROTECTED]:5078> instead of
<sip:[EMAIL PROTECTED]:5078;LINEID=c3ba12b98bd9>,
which is an obvious error.
Similar situation is when during unregister, but now it is even more
dangerous, as Expires=0 header field parameter is now removed from the
resent request, so registrar interprets it as a REGISTER refresh, and
the resulting 200 OK shows it clearly - it still contains the binging.
I have found the cause of error to lay in
SipUserAgent::prepareContact(), and the exact error location is here:
// Update contact if we know anything about the target and our NAT binding
if (message.getContactUri(0, &contact))
{
Url urlContact(contact) ;
UtlString contactIp ;
getContactUri() returns only addr-spec part of the Contact field,
stripped from the braces. This is dangerous thing due to 2 reasons:
1. Header field params are removed and do not appear in Contact header
rewritten later,
2. as according to RFC3261 URI must not be presented in the addr-spec
form if it contains semicolons (which is the case here). Due to this
violation Url parsing treats url-params as header field params and
they are formatted as such when Url is rewritten later.
The bug is very easy to fix by changing:
if (message.getContactUri(0, &contact))
to:
if (message.getContactField(0, contact))
However, I'm not sure whether this is correct solution. Please,
anybody who knows the code in question verify my fix.
Best Regards,
Andrzej Ciarkowski
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
