[asterisk-bugs] [JIRA] (ASTERISK-28782) Add support for Content-Disposition header in multi-part INVITES

[Torrey Searle (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Torrey Searle updated ASTERISK-28782:
-------------------------------------

    Description: 
A certain carrier interconnect test requires us to reject certain invites containing content that is not currently supported by asterisk

This patch tries to implement the correct behavior as according to RFC5261

RFC 5621 says the following
8.1.  Background on Content and Disposition Types in SIP

   The Content-Disposition header field, defined in [RFC2183] and
   extended by [RFC3261], describes how to handle a SIP message's body
   or an individual body part.  Examples of disposition types used in
   SIP in the Content-Disposition header field are 'session' and
   'render'.

   [RFC3204] and [RFC3459] define the 'handling' parameter for the
   Content-Disposition header field.  This parameter describes how a UAS
   reacts if it receives a message body whose content type or
   disposition type it does not understand.  If the parameter has the
   value 'optional', the UAS ignores the message body; if the parameter
   has the value 'required', the UAS returns a 415 (Unsupported Media
   Type) response.  The default value for the 'handling' parameter is
   'required'.  The following is an example of a Content-Disposition
   header field:

       Content-Disposition: signal; handling=optional

  was:
A certain carrier interconnect test requires us to reject certain invites containing content that is not currently supported by asterisk

This patch tries to implement the correct behavior as according to RFC5261

RFC 5261 says the following
8.1.  Background on Content and Disposition Types in SIP

   The Content-Disposition header field, defined in [RFC2183] and
   extended by [RFC3261], describes how to handle a SIP message's body
   or an individual body part.  Examples of disposition types used in
   SIP in the Content-Disposition header field are 'session' and
   'render'.

   [RFC3204] and [RFC3459] define the 'handling' parameter for the
   Content-Disposition header field.  This parameter describes how a UAS
   reacts if it receives a message body whose content type or
   disposition type it does not understand.  If the parameter has the
   value 'optional', the UAS ignores the message body; if the parameter
   has the value 'required', the UAS returns a 415 (Unsupported Media
   Type) response.  The default value for the 'handling' parameter is
   'required'.  The following is an example of a Content-Disposition
   header field:

       Content-Disposition: signal; handling=optional


> Add support for Content-Disposition header in multi-part INVITES
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-28782
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28782
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_pjsip_session
>    Affects Versions: 13.28.1
>            Reporter: Torrey Searle
>            Assignee: Torrey Searle
>            Severity: Minor
>
> A certain carrier interconnect test requires us to reject certain invites containing content that is not currently supported by asterisk
> This patch tries to implement the correct behavior as according to RFC5261
> RFC 5621 says the following
> 8.1.  Background on Content and Disposition Types in SIP
>    The Content-Disposition header field, defined in [RFC2183] and
>    extended by [RFC3261], describes how to handle a SIP message's body
>    or an individual body part.  Examples of disposition types used in
>    SIP in the Content-Disposition header field are 'session' and
>    'render'.
>    [RFC3204] and [RFC3459] define the 'handling' parameter for the
>    Content-Disposition header field.  This parameter describes how a UAS
>    reacts if it receives a message body whose content type or
>    disposition type it does not understand.  If the parameter has the
>    value 'optional', the UAS ignores the message body; if the parameter
>    has the value 'required', the UAS returns a 415 (Unsupported Media
>    Type) response.  The default value for the 'handling' parameter is
>    'required'.  The following is an example of a Content-Disposition
>    header field:
>        Content-Disposition: signal; handling=optional



--
This message was sent by Atlassian JIRA
(v6.2#6252)