| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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] Hi Guys, I'm starting to try the Sip Forum Test Framework SFTF (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 |