[asterisk-bugs] [JIRA] (ASTERISK-29532) Issue with maxptime and VolTE (Voice Over LTE)

[Renato Ribas (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255708#comment-255708 ] 

Renato Ribas edited comment on ASTERISK-29532 at 7/27/21 5:30 PM:
------------------------------------------------------------------

Updated the maxptime for better clarification.  The sentence that
      previously read: "The time SHOULD be a multiple of the frame
      size." now says "The time SHOULD be an integer multiple of the
      frame size."  This should have no impact on interoperability.

maxptime: The maximum amount of media which can be encapsulated
               in a payload packet, expressed as time in milliseconds.
               The time is calculated as the sum of the time that the
               media present in the packet represents.  The time SHOULD
               be an integer multiple of the frame size.  If this
               parameter is not present, the sender MAY encapsulate any
               number of speech frames into one RTP packet.

On the other hand, the transcoding from G.711 to UEMCLIP is not
   entirely straightforward.  Since there are no means to generate
   enhancement sub-layers, a G.711 bitstream can only be converted to
   UEMCLIP Mode 0 bitstream.  If the original G.711 bitstream is encoded
   in A-law, it should first be converted to u-law to become the core
   layer.  Because a UEMCLIP frame size is 20 ms, a u-law-encoded G.711
   bitstream MUST be a 160-sample chunk to become a core layer.

I understand by definition that the maxptime value needs to be a multiple of 20.

https://datatracker.ietf.org/doc/html/rfc4566
https://datatracker.ietf.org/doc/html/rfc5686


was (Author: ribascr):
Updated the maxptime for better clarification.  The sentence that
      previously read: "The time SHOULD be a multiple of the frame
      size." now says "The time SHOULD be an integer multiple of the
      frame size."  This should have no impact on interoperability.

maxptime: The maximum amount of media which can be encapsulated
               in a payload packet, expressed as time in milliseconds.
               The time is calculated as the sum of the time that the
               media present in the packet represents.  The time SHOULD
               be an integer multiple of the frame size.  If this
               parameter is not present, the sender MAY encapsulate any
               number of speech frames into one RTP packet.

On the other hand, the transcoding from G.711 to UEMCLIP is not
   entirely straightforward.  Since there are no means to generate
   enhancement sub-layers, a G.711 bitstream can only be converted to
   UEMCLIP Mode 0 bitstream.  If the original G.711 bitstream is encoded
   in A-law, it should first be converted to u-law to become the core
   layer.  Because a UEMCLIP frame size is 20 ms, a u-law-encoded G.711
   bitstream MUST be a 160-sample chunk to become a core layer.

https://datatracker.ietf.org/doc/html/rfc5686
https://datatracker.ietf.org/doc/html/rfc5686

> Issue with maxptime and VolTE (Voice Over LTE)
> ----------------------------------------------
>
>                 Key: ASTERISK-29532
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29532
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Codecs/General
>    Affects Versions: 16.19.0
>         Environment: Sangoma Linux release 7.8.2003 (Core)
>            Reporter: Renato Ribas
>            Assignee: Unassigned
>
> Hello how are you?
> Some telecom providers have problems with outgoing calls over the SIP trunk if destines using VoLTE (Voice Over LTE).
> According to diagnosis, the value of maxptime=150, however, according to RFC 4566, it must be a multiple of 20.
> The parameter is fixed in the asterisk code in codec_builtin.c, when performing the manual compilation I lose some functionality of commercial modules like Sysadmin in FreePBX.
> Would it be possible in future versions for the parameter to be pre-compiled according to RFC?
> Thanks



--
This message was sent by Atlassian JIRA
(v6.2#6252)