| < Previous by Date | Date Index | Next by Date > |
| Thread Index |
|
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. Scott
Godin Research
and Development Computer
Talk Technology slgodin@xxxxxxxxxxxx 905-882-5000
and 'Say my name' or x127 |