[asterisk-dev] [Code Review] 3244: res_pjsip_sdp_rtp: Apply packetization rules on inbound SDP handling
Matt Jordan
reviewboard at asterisk.org
Thu Feb 27 06:30:58 CST 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3244/
-----------------------------------------------------------
(Updated Feb. 27, 2014, 6:30 a.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
Repository: Asterisk
Description
-------
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.
Diffs
-----
/branches/12/res/res_pjsip_sdp_rtp.c 408501
Diff: https://reviewboard.asterisk.org/r/3244/diff/
Testing
-------
The packetization test suite test that verifies 'use_ptime' now passes. Tests that cover 'use_ptime' being set to False continue to pass.
These tests will be put up for a review when more of them are done.
Thanks,
Matt Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140227/75d6e75d/attachment.html>
More information about the asterisk-dev
mailing list