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

Re: [reSIProcate] A couple more minor issues from torture-tests


I think checking both will work well.

> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Monday, August 14, 2006 10:10 AM
> To: Scott Godin
> Cc: resiprocate-devel
> Subject: Re: [reSIProcate] A couple more minor issues from torture-
> tests
> 
>       Okay, I can see what you're getting at, although I wonder
whether
> we
> can assume that we support the same set of schemes on the Req-Uri as
> we do on an AOR (ie, a proxy/registrar is likely to support tel: in
> the request Uri, but not in an AOR it is responsible for) I don't
> think it is valid to support anything other than sip or sips in this
> case. Perhaps we can check to see whether it fits both criteria.
> 
> Best regards,
> Byron Campen
> 
> > I was just suggesting that you use the isSchemeSupported method on
> the
> > master profile to check the To scheme.  I think it is appropriate
> > to use
> > the profile setting for both requeste uri scheme and To header
> scheme.
> >
> >> -----Original Message-----
> >> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> >> Sent: Monday, August 14, 2006 10:01 AM
> >> To: Scott Godin
> >> Cc: resiprocate-devel
> >> Subject: Re: [reSIProcate] A couple more minor issues from torture-
> >> tests
> >>
> >>    But this code is for the request-uri; the code I was writing was
> >> for
> >> the AOR (To header).
> >>
> >> Best regards,
> >> Byron Campen
> >>
> >>> Hi Byron,
> >>>
> >>> I've been away for the last week - so I'm just catching on emails
> >> now!
> >>> Thanks for all your work on this stuff.
> >>>
> >>> For problem 1  - I saw your commit.  You should be checking the
> >> scheme
> >>> against the profile setting, instead of hard coding sip and sips.
> >> For
> >>> example the following code is from validateRequestURI in
> >>> DialogUsageManager.cxx
> >>>
> >>>    // RFC3261 - 8.2.2
> >>>    if
> >>> (!getMasterProfile()->isSchemeSupported(request.header
> >>> (h_RequestLine).ur
> >>> i().scheme()))
> >>>    {
> >>>       InfoLog (<< "Received an unsupported scheme: " <<
> >>> request.brief());
> >>>       SipMessage failure;
> >>>       makeResponse(failure, request, 416);
> >>>       sendResponse(failure);
> >>>
> >>>     return false;
> >>>    }
> >>>
> >>>> -----Original Message-----
> >>>> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >>>> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of
> >>>> Byron Campen
> >>>> Sent: Tuesday, August 08, 2006 11:19 AM
> >>>> To: resiprocate-devel
> >>>> Subject: [reSIProcate] A couple more minor issues from
> > torture-tests
> >>>>
> >>>> 1. Currently ServerRegistration succeeds when the aor has a
scheme
> >>>> other than sip or sips. This is a pretty easy fix (in
> >>>> ServerRegistration::dispatch, we check the scheme, and send a 400
> > if
> >>> it
> >>>> isn't correct).
> >>>>
> >>>> 2. Currently, the authentication functions in Helper do not check
> >>>> whether the authentication scheme is "Digest" (they assume that
> >>>> "Digest" is being used without verifying whether this is true).
> > This
> >>> is
> >>>> also easily fixed.
> >>>>
> >>>> Unless anyone has objections, I will be applying fixes for these
> to
> >>> the
> >>>> main trunk.
> >>>>
> >>>> Best regards,
> >>>> Byron Campen
> >