res_pjsip_sdp_rtp: Apply packetization rules on inbound SDP handling

The setting 'use_ptime' is supposed to tell Asterisk to honour the ptime
attribute in an offer, preferring it to whatever packetization
preferences have been set internally. Currently, however, something
rather quirky will happen:

(1) The SDP answer will be constructed in create_outgoing_sdp_stream.
    This will use the preferences from the endpoint, such that the 200 OK
    response will add the packetization preferences from the endpoint, and
    not what was offered.
(2) When the 200 response is issued, apply_negotiated_sdp_stream is called.
    This will call apply_packetization, which will use the ptime attribute
    from the offer internally.

We end up telling the offerer to use the internal ptime attribute, but we end
up using the offered ptime attribute. Hilarity ensues.

This patch modifies the behaviour by calling apply_packetization from
negotiate_incoming_sdp_stream, which is called prior to
create_outgoing_sdp_stream. This causes the format preferences on the
session's media object to be set to the inbound ptime value (if 'use_ptime'
is enabled), such that the construction of the answer gets the right value
immediately.

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@408999 f38db490-d61c-443f-a65b-d21fe96a405b
Blocked revisions 409002

Note that this is blocked in 12 as channels are no longer masqueraded out
of bridges. The channel cannot be replaced with a ZOMBIE channel in the
affected routine.

........
rtp_engine: fix crash during remote native bridging when calling get_codecs

When two RTP channels are in a remote bridge, the remote bridging loop in
rtp_engine will periodically check to see if the two channels can still be
bridged. One of the many things it checks is whether or not the codecs have
changed on the channel. If the codec has changed, it will break out of the
loop to re-determine which type of bridge is appropriate.

In order to perform this check, the ast_rtp_glue virtual table's get_codec
callback is called for each channel. The callback implementations assume
that the channel tech private is valid when called; as such, there has
always been some code in place to check whether or not the channel pvt is
NULL before calling. However, this check is insufficient.

The channels are unlocked during the remote bridging loop. It is possible
for a channel to get masqueraded between the check for the pvt being NULL and
the actual call to get_codec. When this occurs, the callback is called with a
ZOMBIE channel, which now has a NULL pvt. Crash.

While this has always been possible in Asterisk 1.8, it is much more likely to
occur in Asterisk 11 and later versions due to the timing changes that occur
when getting the codec from a channel. Note that this is much more likely to be
reproduced on slow, boggy hardware running Asterisk 11 - but fairly rarely
otherwise.

Also Note: This crash was also caught by the various SIP blind transfer tests,
in addition to the bug report Alec filed.

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

(closes issue ASTERISK-21737)
Reported by: Alec Davis
Tested by: Alec Davis
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@409003 f38db490-d61c-443f-a65b-d21fe96a405b