channels/chan_sip: Respect outboundproxy setting when sending qualify requests

The outboundproxy setting is currently ignored when sending OPTIONS requests
as a result of the qualify setting. This means that if an Asterisk server is
unable to send the packet directly to a peer, it is unable to qualify any
non-inbound registered peer (e.g. a peer SIP Trunk).

This patch grabs the outboundproxy information for a peer when a qualify
attempt is being constructed and, if it finds the information, uses it
when sending the OPTIONS request.

Review: https://reviewboard.asterisk.org/r/3948

ASTERISK-24063 #close
Reported by: Damian Ivereigh
patches:
  outboundproxy-dai.patch uploaded by Damian Ivereigh (License 6632)
........

Merged revisions 425818 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 425819 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 425820 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425821 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@425822 f38db490-d61c-443f-a65b-d21fe96a405b
res_pjsip_keepalive: Add runtime configurable keepalive module for connection-oriented transports.

This change adds a module which is configurable using the keep_alive_interval setting in the
global section that will send a CRLF keep alive to all active connection-oriented transports at
the provided interval. This is useful because it can help keep connections open through NATs.
This functionality also exists within PJSIP but can not be controlled at runtime and requires
recompiling it.

Review: https://reviewboard.asterisk.org/r/4084/


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@425825 f38db490-d61c-443f-a65b-d21fe96a405b
res_pjsip_session/res_pjsip_sdp_rtp: Be more tolerant of offers

When an inbound SDP offer is received, Asterisk currently makes a few
incorrection assumptions:

(1) If the offer contains more than a single audio/video stream, Asterisk will
    reject the entire stream with a 488. This is an overly strict response;
    generally, Asterisk should accept the media streams that it can accept and
    decline the others.
(2) If the offer contains a declined media stream, Asterisk will attempt to
    process it anyway. This can result in attempting to match format
    capabilities on a declined media stream, leading to a 488. Asterisk should
    simply ignore declined media streams.
(3) Asterisk will currently attempt to handle offers with AVPF with
    use_avpf=No/AVP with use_avpf=Yes. This mismatch results in invalid SDP
    answers being sent in response. If there is a mismatch between the media
    type being offered and the configuration, Asterisk must reject the offer
    with a 488.

This patch does the following:
* Asterisk will accept SDP offers with at least one media stream that it can
  use. Some WARNING messages have been dropped to NOTICEs as a result.
* Asterisk will not accept an offer with a media type that doesn't match its
  configuration.
* Asterisk will ignore declined media streams properly.

#SIPit31

Review: https://reviewboard.asterisk.org/r/4063/

ASTERISK-24122 #close
Reported by: James Van Vleet

ASTERISK-24381 #close
Reported by: Matt Jordan
........

Merged revisions 425868 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425879 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@425881 f38db490-d61c-443f-a65b-d21fe96a405b