reinvite media process error
Brought to you by:
csoutheren,
rjongbloed
Menu
▾
▴
1 Attachments
#600 reinvite media process error
open
5
2022-07-02
2021-09-12
No
When using opalvoip with 3.18, if UAS attempts to change the media through the REINVITE message, the REINVITE message does not carry SDP information, so opal will carry the media list information supported by UAC in the 200 OK message center of the response, and UAS will respond to the selected media information in the ACK message, but opal only sends a message with the newly selected media, and the time field of RTP will be set to 0, Then it switches to sending the message with the previously negotiated media. However, in the process of REINVITE, the previously selected media has been completely closed
When communicating with IMS system, IMS sometimes uses 3PCC protocol, so it will use REINVITE to renegotiate media
When using opalvoip with 3.18, if UAS attempts to change the media through the REINVITE message, the REINVITE message does not carry SDP information, so opal will carry the media list information supported by UAC in the 200 OK message of the response, and UAS will respond to the selected media information in the ACK message, but opal only sends a RTP package with the newly selected media, and the time field of RTP will be set to 0, Then it switches to sending the message with the previously negotiated media. However, in the process of REINVITE, the previously selected media has been completely closed
I looked at the log file you have provided, and the reason the media streams were closed and reopened was because the remote system changed the codec from G.729 to G.711 A-Law. This is correct operation.
Can you better explain what the problem is?
I believe I have clearly expressed my problem. It can be seen from the log file that the media negotiated by both parties is G.729, and then UAS initiates REINVITE for media negotiation and replaces it with G.711. However, after replacing it with G.711, UAS does always send G.711 RTP frames, and the opal program of UAC automatically sends G.729 messages after sending a G.711 RTP message, This is the problem, and the opal program of G.711 media sent by UAS can be decoded and heard normally. That's what I'm talking about.
My question is why opal sends only one G.711 message after G.729 is turned off and switched to G.711, and then changed to G.729.
I have tested it many times. As long as I modify and switch different media through REINVITE or update messages in the opal program, the opal program will always automatically change back to the previous media, resulting in no sound at the opposite end
At the same time, I have the record of intercepting messages through Wireshark, and I can clearly see the process.
line 6023
capture with tcpdump
We use the program developed by opalvoip as UAC. When UAC and UAS establish a call, the media negotiated for the first time is G.729, and the call between the two sides is normal. Later, UAS renegotiates the media through REINVITE. UAC selects G.711 and the negotiation is successful, but then the problem arises. UAC will successfully send a G.711 media message, and UAS (opposite end) will continue to send G.711 media message, However, UAC sends the first G.711 message and then sends the G.729 message. As a result, UAC can hear the media information sent by UAS, but UAS cannot receive the media information from UAC.
After renegotiating the media, UAC only sent a new frame of media and switched back to the old media format.
In fact, the attachment capture file I put on can clearly see this process
In the normal mode, opal library has no problem in handling media changes. However, if opalmixer is used for mixing in mcu mode, the currently used audio transcoder will be saved in cacheaudio due to the use of the cachedaudio mechanism. When changing to a new media through reinvite or update, the audio transcoder in cachedaudio will not be modified synchronously, Even after the entire protocol layer has been successfully negotiated as a new media, the previous audio transcoder will be used in cachedaudio for processing, resulting in problems.
I have modified it in the opal 3.18 branch, and the test passed. The void opalaudiostreammixer:: pushone function needs to be modified. The specific modification code is as follows:
// modify by byzhou 2022-06-26
if (cache.m_transcoder == NULL || cache.m_transcoder->GetPayloadType(false) != mediaFormat.GetPayloadType()) {
if(cache.m_transcoder != NULL) {
delete cache.m_transcoder;
cache.m_transcoder = NULL;
}
Original code is:
if (cache.m_transcoder == NULL) {
Opalmixer uses cache m_ Transcoder->convert (cache.m\u raw, cache.m\u encoded)) this line of code will convert the mixed voice transmission into voice transmission of different media. If opal converts the media, it will not synchronously modify the cache m_ Transcoder, then the old media converter negotiated earlier will be used to convert audio.
Don't you fix such obvious problems and bugs in time?