Change maxptime parameter

Is it possible to change manually maxptime parameter for SIP trunk in Asterisk?
Or at least, is it possible not to put this parameter into SDP?

BR

There is no ability to modify the maxptime or disable it for either the chan_sip or chan_pjsip module. You would need to modify the source code in order to do so.

OK, but could you give me a peace of advice about my issue.
I have next scheme:

(SIP-Phone A)----{friend}----[Asterisk]----{peer}----[PBX]—(SIP-Phone B)

If I place a call from A to B, B replies with 488 Not Acceptable Here immediately after INVITE.

I asked a developer, who developed firmware for this phone, he replied that parameter a=maxptime:150 is a reason of such phone’s behavior.

Otherwise, if I place call from B to A, call establishes, but finishes immediately after begining because of BYE (without reason) from the Phone B.

Is there any possibility to find workaround for it without changing code?

BR

If the problem is truly because of the maxptime attribute then no, as there is no way to remove it without altering the code.

This really needs fixing in the peer. 150ms is a long time,and I think it is a reasonable requirement that a SIP implementation should be able to accept a maxptime as low as 20ms. It is only a maximum, so the standard 20ms is perfectly acceptable.

What they seem to be saying is that their implementation requires them to be able to send packets with a 150ms serialisation delay. If both sides negotiated and took advantage of 150ms ptimes, the round trip delay would be at least 300ms, which most people would consider unaccetable, so it seems unlikely that they really considered 150ms too small.

Hi korneff,

Did you fix this issue ? Did you recompile Asterisk ?
I have the same issue on maxptime .[1]

[1] : Can not make an outbound

Thanks .

488 Not Acceptable is very often a codec issue…

Korneff and others: This may probably help. I too was searching ways to set or change values or be able to set maxptime and annexb parameters and came across this documentation from Asterisk pages. While it doesn’t talk directly about ability to set maxptime, but does mention a parameter that governs its behaviour, which I believe could be a good workaround without having to modify code.

Add autoframing=yes in sip.conf in the global section or add this as additional sip setting in FreePBX.

Let me qualify that I have not tried it yet.

Reference: https://wiki.asterisk.org/wiki/display/AST/RTP+Packetization

Jcolp hello, I will change maxptime at /main/codec_builtin.c, then just run in the asterisk make && make install && make config folder?

1 Like

“make config” isn’t really needed if you’re just doing that, but the code change sounds about right. I haven’t done it, so I don’t know.

I though you could set Ptime as part of the codec setup as well.

Document at RTP Packetization - Asterisk Project - Asterisk Project Wiki

ptime and maxptime are separate things, there is no ability to set maxptime

1 Like

True.
& thanks. Your knowledge is incredible.

Hi,

The telephone carrier Vivo (Grupo Telefônica no Brasil), the largest in Brazil, in its SIP service, fails to complete calls to Apple phones (iPhone) when the maxptime is not a multiple of 20. Rightly or wrongly, Vivo and Apple are giants and do not care to solve this problem. This is how I managed to solve the problem on my PBX. The only codec accepted by them is alaw but in some countries ulaw is used. I changed only what was necessary. Version 16 is used in FreePBX 15.

I also had this need. I made 2 pull requests to resolve this for everyone.
1st was for all codecs.

2nd was only for the alaw and ulaw condecs the most used in interconnections.

The only solution is to recompile asterisk itself and it is not a specific module, it is asterisk itself. I thought this was a codec module but the result was added to the asterisk file.

138 / 5.000

Resultados de tradução

Resultado da tradução

star_border

My pull request gave an error because I was successful. But the automated test expects maxptime equal to 150 and I successfully changed it to 140.

Can someone review and defend me on this idea?