[asterisk-bugs] [JIRA] (ASTERISK-27139) ptime ignored when using pjsip
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Tue Jul 18 06:35:58 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=237728#comment-237728 ]
Asterisk Team commented on ASTERISK-27139:
------------------------------------------
Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.
A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.
Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
> ptime ignored when using pjsip
> ------------------------------
>
> Key: ASTERISK-27139
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27139
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_pjsip
> Affects Versions: 13.13.1, GIT
> Reporter: Lars Martensen
>
> When Asterisk bridges two channels of type pjsip which use different packetization intervals (set with ptime attribute in SDP) Asterisk switches to native_rtp bridge:
> {noformat}
> -- Called PJSIP/router00
> -- PJSIP/router00-00000003 is ringing
> -- PJSIP/router00-00000003 answered PJSIP/pbx-00000002
> -- Channel PJSIP/router00-00000003 joined 'simple_bridge' basic-bridge <ea10bc71-dd87-452e-995e-8dd7c811f449>
> -- Channel PJSIP/pbx-00000002 joined 'simple_bridge' basic-bridge <ea10bc71-dd87-452e-995e-8dd7c811f449>
> > Bridge ea10bc71-dd87-452e-995e-8dd7c811f449: switching from simple_bridge technology to native_rtp
> > Locally RTP bridged 'PJSIP/pbx-00000002' and 'PJSIP/router00-00000003' in stack
> {noformat}
> The channels then receive RTP packets with an unexpected size (e.g. 30ms instead of 20ms or vice versa). I would expect that Asterisk stays with simple_bridge because of the differences in packet size.
> It seems that the function {{native_rtp_bridge_compatible}} actively guards against this to happen:
> {noformat}
> read_ptime0 = ast_format_cap_get_format_framing(cap0, ast_channel_rawreadformat(bc0->chan));
> read_ptime1 = ast_format_cap_get_format_framing(cap1, ast_channel_rawreadformat(bc1->chan));
> write_ptime0 = ast_format_cap_get_format_framing(cap0, ast_channel_rawwriteformat(bc0->chan));
> write_ptime1 = ast_format_cap_get_format_framing(cap1, ast_channel_rawwriteformat(bc1->chan));
> if (read_ptime0 != write_ptime1 || read_ptime1 != write_ptime0) {
> ast_debug(1, "Packetization differs between RTP streams (%d != %d or %d != %d). Cannot native bridge in RTP\n",
> read_ptime0, write_ptime1, read_ptime1, write_ptime0);
> return 0;
> }
> {noformat}
> But the function {{get_codecs}} in {{res_pjsip_sdp_rtp.c}} uses {{ast_rtp_codecs_set_framing}}:
> {noformat}
> /* Get the packetization, if it exists */
> if ((attr = pjmedia_sdp_media_find_attr2(stream, "ptime", NULL))) {
> unsigned long framing = pj_strtoul(pj_strltrim(&attr->value));
> if (framing && session->endpoint->media.rtp.use_ptime) {
> ast_rtp_codecs_set_framing(codecs, framing);
> }
> }
> {noformat}
> In chan_sip this scenario works as expected, probably because function {{process_sdp_a_audio}} uses a different function to store the framing (which is what {{native_rtp_bridge_compatible}} expects):
> {noformat}
> if (framing && p->autoframing) {
> ast_debug(1, "Setting framing to %ld\n", framing);
> ast_format_cap_set_framing(p->caps, framing);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list