| Summary: | ASTERISK-25484: [patch] autoframing=yes has no effect | ||
| Reporter: | Alexander Traud (traud) | Labels: | |
| Date Opened: | 2015-10-21 08:55:25 | Date Closed: | 2015-10-23 06:53:50 |
| Priority: | Major | Regression? | Yes |
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling |
| Versions: | 13.6.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) chan_sip_autoframing.patch | |
| Description: | When I write {{autoframing=yes}} into my {{sip.conf}} configuration file, Asterisk still does not honor the ptime of the callee. This happens, because the function {{ast_rtp_codecs_payloads_copy}} is called afterwards overwriting the saved framing with {{0}}. This was/is no issue in Asterisk 11.
Actually, this is worse than using the default {{autoframing=no}} because now in {{/res/res_rtp_asterisk}} the call {{ast_rtp_codecs_get_framing(ast_rtp_instance_get_codecs(instance)}} returns 0 always. | ||
| Comments: | By: Alexander Traud (traud) 2015-10-21 08:56:12.581-0500 The attached patch fixes this issue through saving the value within the capabilities. I hope, those are not shared between channels. Furthermore, hunk#2 and hunk#3 of the patch move the code to set the value to the ptime which is actually transmitted via SIP/SDP: Theoretically, an ast_format could have a lower *maximum* packetization time than the channel, for example if a ast_format does not allow packetization at all (min=default=maxptime). Therefore, any ptime (negotiated, configured, or default) has to be lower/equal than the lowest maxptime in the chosen set of ast_formats. This feature got lost with Asterisk 13 (the built-in maxptimes are not honored at all anymore), but this is out of scope of this issue here. | ||