[reSIProcate] Adding Allow/Supported/Accept header to Invitesand Responses to Invites in DUM

Tue Sep 14 14:27:00 CDT 2004

Your changes in Profile.cxx, BaseCreator.cxx and ServerInviteSession.cxx
don't compile for me under linux.

Profile.cxx: In constructor `resip::Profile::Profile()':
Profile.cxx:19: `resip::Headers::Type' is not an aggregate type

  -----Original Message-----
  From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org]On Behalf Of Scott
Godin
  Sent: Tuesday, September 14, 2004 10:09 AM
  To: resiprocate-devel at list.sipfoundry.org
  Cc: 'Derek at xten.com'
  Subject: RE: [reSIProcate] Adding Allow/Supported/Accept header to
Invitesand Responses to Invites in DUM

  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 at xten.com]
  Sent: Wednesday, September 08, 2004 1:07 PM
  To: 'Scott Godin'
  Subject: RE: [reSIProcate] Adding Allow/Supported/Accept header to Invites
and Responses to Invites in DUM

  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: Scott Godin [mailto:slgodin at icescape.com]
  Sent: Monday, August 09, 2004 1:47 PM
  To: resiprocate-devel at list.sipfoundry.org
  Subject: [reSIProcate] Adding Allow/Supported/Accept header to Invites and
Responses to Invites in DUM

  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 at icescape.com

  905-882-5000 and 'Say my name' or x127

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20040914/4bde44c7/attachment.htm>