| < Previous by Date | Date Index | Next by Date > |
| Thread Index | Next in Thread > |
|
I've added support to DUM for
this. There are now three new
Profile methods: void addAdvertisedCapability(const Headers::Type header); bool isAdvertisedCapability(const
Headers::Type header); void clearAdvertisedCapabilities(); These methods allow you to enable/disable
sending of Allow/Supported/Accept/Accept-Language/Accept-Encoding headers on initial outbound requests (ie. Initial
INVITE, REGISTER, SUBSCRIBE, - those created by the BaseCreator)
and 200 responses to inbound INVITES. The Profile default is to advertise Headers::Type::Accept and Headers::Type::Supported,
since these used to added by default in BaseCreator
before I did this change. Use clearAdvertisedCapabilities to remove these if you don't
want them sent. Currently implemented header values are: Headers::Type::Accept, Headers::Type::Allow,
Headers::Type::AcceptEncoding, Headers::Type::AcceptLanguage,
Headers::Type::Supported. The values added to the message are
those set from the addSupportedxxxx profile
functions. Example: UA's
wishing to advertise as much as possible should include something like: sipProfile.addSupportedMethod(....);
// Allow header ... sipProfile.addSupportedMethod(....);
// Allow header sipProfile.addSupportedOptionTags(....); // Supported header sipProfile.addSupportedMimeType(....);
// Accept header sipProfile.addSupportedEncoding(....); // Accept-Encoding header sipProfile.addSupportedLanguage(....); // Accept-Language header sipProfile.addAdvertisedCapability(Headers::Type::Accept); // Not really required since enabled by
default sipProfile.addAdvertisedCapability(Headers::Type::Supported); // Not really required
since enabled by default sipProfile.addAdvertisedCapability(Headers::Type::Allow); sipProfile.addAdvertisedCapability(Headers::Type::AcceptEncoding); sipProfile.addAdvertisedCapability(Headers::Type::AcceptLanguage); Scott From: Derek MacDonald
[mailto:derek@xxxxxxxx] I think a setting in the profile is the
way to go for this. The question is which requests these should appear
in? If it's just outbound invites, this can be done in the
InviteSessionCreator. If it's all requests(re-invites/etc) this
could be done in Dialog::makeRequest. Dialog::makeResponse could be used for
responses. --Derek From: Hello DUM Design Team, I was thinking we should add the
insertion of the Allow, Supported and possibly Accept on outbound INVITES and
success INVITE responses to support suggestions made in RFC3261. These
would be based off of the settings in the Profile. Are there cases you don't want to
add these? ie. I'm not sure if a proxy server should add an Allows header
- it definitely is not supposed to for OPTIONS responses (3261 section 11.2) -
but I'm not sure about other messages. Even if there are cases where it
is undesirable - the developer still has the chance to remove them if they are
inserted automatically by the DUM. Early dialogs present some
complication. (for
example, an Allow header field in a provisional response contains the methods that can be
used in the dialog while this is in the early state). I would suggest the following: 1. makeInviteSession will add
the Allow, Supported and Accept headers to the newly generated message. 2. ServerInviteSession will
add Allow, Supported and Accept headers to 200 responses to INVITES. 3. Do not automatically add
these headers to any provisional responses. Any thoughts? For reference I have included some
relevant notes from RFC3261 below. Scott Section 13.2.1 - An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog,
on the UA sending the INVITE, for the duration of the dialog. For example, a UA capable of receiving INFO
requests within a dialog [34] SHOULD include an Allow header field listing the INFO method. A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC. An Accept (Section 20.1) header field MAY be present in the INVITE. It indicates which Content-Types are acceptable to the UA, in
both the response received by it, and in any subsequent requests sent to it
within dialogs established by
the INVITE. The Accept header field is especially useful for indicating
support of various session
description formats. 13.2.2 - The early dialog will
only be needed if the UAC needs to send a request to its peer within the dialog
before the initial INVITE transaction completes. Header fields present
in a provisional response are applicable as long as the dialog is in
the early state (for example, an Allow header field in a provisional response contains the methods that can be
used in the dialog while this is in the early state). 13.3.1 - A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these header fields allows the
UAC to determine the features and extensions
supported by the UAS for the duration of the call, without probing. 20.5 - Supplying an Allow header field in responses to methods
other than OPTIONS reduces the number of messages needed. Research
and Development Computer
Talk Technology slgodin@xxxxxxxxxxxx 905-882-5000
and 'Say my name' or x127 |