Summary: | ASTERISK-27139: pjsip: SDP attribute ptime ignored when Asterisk bridges two PJSIP channels with different ptime | ||
Reporter: | Lars Martensen (lmar) | Labels: | |
Date Opened: | 2017-07-18 06:35:28 | Date Closed: | |
Priority: | Major | Regression? | No |
Status: | Open/New | Components: | Resources/res_pjsip |
Versions: | 13.13.1 GIT | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Attachments: | ||
Description: | 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} | ||
Comments: | By: Asterisk Team (asteriskteam) 2017-07-18 06:35:29.981-0500 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]. |