Hello, Thanks for your answer. If I understand you correctly, the digest-uri should be treated as just another opaque string in the digest calculation and the uri-parameter but should match the actual Request-URI at least in the important fields (scheme, user and host should suffice I suppose) to aid in diagnosis or allow simple checks.
I'm a little bit worried about the SIP servers that DO require that both URIs are equal, though. Just out of curiosity, do you know if they actually drop a request when a mismatch occurs? If so, wouldn't that be a violation of RFC3261, sec. 22.4, point 6. Best regards, Peter On Sun, Apr 3, 2011 at 2:29 PM, Iñaki Baz Castillo <[email protected]> wrote: > 2011/4/1 Peter Krebs <[email protected]>: > > To clarify my question, let's consider that the URI in your > > example includes optional values, e. g. > > > > sip:user:[email protected] > > ;transport=udp;user=ip;method=INVITE;ttl=123&header=some%20header > > > > What value should be used in the calculation of str2 in the <sip uri> > part, > > the whole URI as string with all optional values in the exact order they > are > > given above or just the mandatory parts (which would be " > > sip:[email protected]" or the one in your example without the user)? > > Hi, AFAIK matching request URI and authorization "uri" field is mostly > used in HTTP world, but in SIP it makes no so sense. I know about some > SIP servers that doesn't require both fields to match. > > Probably, if SIP protocol would define a custom authentication > mechanism (rather than reusing HTTP digest) no "uri" field would exist > in the authentication exchange. > > > > -- > Iñaki Baz Castillo > <[email protected]> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
