asterisk-snap:certified/13.1

Last commit made on 2016-08-17
Get this branch:
git clone -b certified/13.1 https://git.launchpad.net/asterisk-snap

Branch merges

Branch information

Name:
certified/13.1
Repository:
lp:asterisk-snap

Recent commits

8b7280d... by George Joseph <email address hidden>

res_pjsip: Add contact_user to endpoint

contact_user, when specified on an endpoint, will override the user
portion of the Contact header on outgoing requests. This may not work
on scheduled qualify requests where we haven't looked up the endpoint.

Change-Id: I7ce6b6c6678f66807885da1d42fb5fd6909ae55a

7ce04c1... by Mark Michelson <email address hidden>

ChangeLog: Updated for certified/13.1-cert8

53e1a26... by Mark Michelson <email address hidden>

Release summaries: Add summaries for certified/13.1-cert8

6837d58... by Mark Michelson <email address hidden>

Release summaries: Remove previous versions

81bda18... by Mark Michelson <email address hidden>

.version: Update for certified/13.1-cert8

8cfe7d9... by Mark Michelson <email address hidden>

.lastclean: Update for certified/13.1-cert8

cca43b1... by Mark Michelson <email address hidden>

realtime: Add database scripts for certified/13.1-cert8

690e234... by Joshua Colp <email address hidden>

chan_sip/res_pjsip_t38: Handle a request to negotiate T.38 after it is enabled.

Some T.38 implementations may send another re-invite after the initial
one which adds additional negotiation details (such as the max bitrate).
Currently this will fail when passthrough is being done in chan_sip as we
do nothing if T.38 is already active.

Other handlers of T.38 inside of Asterisk (such as res_fax) handle this
scenario so this change adds support for it to chan_sip and res_pjsip_t38.
If a request to negotiate is received while T.38 is already enabled a
new re-INVITE is sent and negotiation is done again.

ASTERISK-26179 #close

Change-Id: I0298494d3da6df3219bbfa4be9aa04015043145c

8b16e99... by Richard Mudgett <email address hidden>

pjsip_distributor.c: Ignore messages until fully booted.

We should not be processing any incoming messages until we are fully
booted. We may not have dialplan or other needed configuration loaded
yet.

ASTERISK-26089 #close
Reported by: Scott Griepentrog

ASTERISK-26088
Reported by: Richard Mudgett

Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264

f663263... by Joshua Colp <email address hidden>

Merge "udptl: Don't eat sequence numbers until OK is received" into certified/13.1