RE: [reSIProcate] Smarter accept header validation in dum?
Yup - I agree, I missed that problem from your original email - I'll fix it.
This whole accept header validation thing is poorly spec'ed out in RFC3261.
For reference I've included some attachments from previous discussions.
Do you think that Content-Encoding and Content-Language validation should
also be per Request Method? I'm thinking they should be request specific.
Thanks,
Scott
-----Original Message-----
From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
Sent: Wednesday, February 02, 2005 4:54 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Smarter accept header validation in dum?
I haven't tried out the new code yet, but from the commit diff it looks like
the situation I described in my original post will still occur, although it
is now solvable.
In DialogUsageManager::validateAccept() the for loop that checks the Accept
values will sill bail with a 406 the first time it sees an unacceptable
value. Of course it had to be this way with the old code, but now that your
fix relates mimes to request types I think the loop should only send a 406
if
zero Accept header values match. The request should be acceptable if only
one mime type matches even if all the rest don't, correct?
Thanks,
~Scott
On February 2, 2005 1:15 pm, Scott Godin wrote:
> I've completed making changes for this and have committed to the teltel
> branch. Supported MimeTypes are now Request specific.
>
> -----Original Message-----
> From: Scott Godin
> Sent: Friday, January 21, 2005 4:08 PM
> To: 'Scott Zuk'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Smarter accept header validation in dum?
>
> I agree with you, and I like your suggestion. I will add this to my task
> list.
>
> For now - you could just disable Accept validation completely - by calling
> profile method:
> validateAcceptEnabled() = false;
>
> -----Original Message-----
> From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> Sent: Thursday, January 20, 2005 1:23 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] Smarter accept header validation in dum?
>
> Hi,
>
> I'm trying to get my dum based program to talk with windows messenger,
> however
> the way the dum handles accept header validation causes all subscribe
> requests sent by windows messenger to be rejected.
>
> WM sends subscribes with an Accept header containing the mime types
> "text/xml+msrtc.pidf" "application/xpidf+xml" and "application/pidf+xml"
in
> that order. My app is set to reply using only "application/pidf+xml" so
in
> theory this should be fine. The problem though is that
> DialogUsageManager::validateAccept() sends a 406 failure on the first
> unrecognized mime type it sees, even if there is a valid one later in the
> list. Is this the intended behaviour?
>
> I think the dum should take into account the message type when determining
> valid accept mime types. Adding a method to Profile that would allow
> something like
> addSupportedMimeType(Mime("application", "pidf+xml"), SUBSCRIBE) might be
> usefull. Are there any current plans to implement something like this in
> resiprocate?
>
> Thanks,
> ~Scott
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--- Begin Message ---
DUM Design Team:
OK - I'm coming to realize that the Accept headers are not actually an
advertisement of capabilities, but are actually a request for a body type in
the response. This means that the following DUM Profile options should
actually be different for each dialog/session type:
addSupportedMimeType
addSupportedEncoding
addSupportedLanguage
For example: Let's say we support application/sdp mime type for Invites (as
required by 3261) - so we add it as a supported MimeType to the DUM Profile.
We should not be doing things like adding an Accept header to other request
types, such as PUBLISH and MESSAGE. (this is the current behaviour).
This problem also applies request validation. For instance if we support
application/sdp for Invites and text/plain for MESSAGE requests - we
currently should add both as supported Mime types to the DUM Profile. But
text/plain is not a valid mime type in an Invite Session - so that
ValidateRequest function should be rejecting such a request.
So it sounds like we can't really generalize "SupportedMimeTypes" across
requests. I'm thinking maybe we should be splitting these settings up -
maybe something like:
addSupportedInviteSessionMimeTypes
addSupportedInviteSessionEncodings
...
addSupportedMessageMimeTypes
...
addSupportedSubscribeMimeTypes
This seems pretty messy though.
Any thoughts on how to handle this better in the DUM profile? Or am I way
off base here?
Thanks,
Scott
_____
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Friday, September 17, 2004 11:22 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Question on Accept Header Validiation...
Hi Guys,
I'm starting to try the Sip Forum Test Framework SFTF (
http://www.sipfoundry.org/sftf/index.html
<http://www.sipfoundry.org/sftf/index.html> ) against reSIP/DUM. I'll post
my results shortly, but I have a quick question:
Test case 216 describes that a Server is supposed to deny a request with an
unknown body type in the Accept header field.
This just doesn't seem quite right to me. If a UAC advertises that it
accepts a certain body type - why would a UAS reject the request just
because it doesn't support that body type? I can't find a definitive RFC
reference to support this behviour.
If there is a consensus that this IS a valid test case - I'll be sure to add
this check into the DUM validateRequest code (currently commented out).
Any thoughts?
Thanks,
Scott
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--- End Message ---
--- Begin Message ---
Hello Scott,
(cc'ed the cretification mailing list, because this is a question which I do
not want to answer just on my own.)
In my opinion the Accept header is not an offer, it contains a requirement.
The other UA is signaling that it is only able to understand bodies of the
type listed in the Accept header. Thus if your UA do not support one of the
types in the Accept header it should not try to establish a call because it
will not be successfull (the other UA will very likely terminate the call
immediately again).
Obviously it is an in-consistency that the INVITE with the Accept header
text/unacceptablesubtype contains a body and Content-Type application/sdp.
But if the Content-Type (and the body) would contain
text/unacceptablesubtype
as well I fear that the INVITE could be rejected by some implementations
because of the Content-Type header, and thus the test would not really test
the Accept header field check.
Any comments are welcome.
Greetings
Nils Ohlmeier
On Friday 17 September 2004 16:04, you wrote:
> case216 - Is this really a valid test. Should UA's really be checking the
> inbound Accept headers and returning an error if they don't support one of
> the Mime types. This seems too restrictive to me. The Accept header
> doesn't really seem like a requirements identifier.
>
>
>
>
>
> Scott Godin
>
> Research and Development
>
> Computer Talk Technology
>
> slgodin@xxxxxxxxxxxx
>
> 905-882-5000 and 'Say my name' or x127
--- End Message ---