Hello all,
We have here a SIP-provider that sometimes sends an INVITE w.SDP
immediately followed by reINVITE using the same SDP content. This
results into rebuilding of the media-stream, causing any started
players to interrupted.
I've adapted PJSIP such a way, that if it detects that the reINVITE
contains the same SDP, then updating of media is ignored.
However... now I'm running into a small issue on which I hope you can
point me in the right direction.
First my changes, taking the pjsua example as reference:
In pjsua_call.c i've added an additional test in the
pjsua_call_on_media_update()-callback. It compares the new SDP against
the stored SDP (I've stored it in the pjsua_call-structure). I do not
store the complete SDP, but only the remote IP+port+codec+ptime. Here
below I further mention this part as SDP.
If it detects that it differs, it stores this new SDP content and
normally executes the updating code after the last
pjmedia_sdp_neg_get_active_remote() (around line 3176). If the new SDP
equals the stored SDP, then it just returns from this callback not
doing any media update.
Now this seems to work, because I do see it detects an equal SDP in reINVITE.
However...
Very shortly after this (matter of ms), the application crashes in next code:
conference.c, get_frame() @ line: 1812
conf_port->mix_adj = NORMAL_LEVEL;
if (conf_port->transmitter_cnt) {
==> pj_bzero(conf_port->mix_buf,
conf->samples_per_frame*sizeof(conf_port->mix_buf[0]));
}
This because conf_port->mix_buf is illegal (0xFEEEFEEE)
I'm still hunting why this happens because as far as I see the
complete media-stream has been left untouched. Maybe I missed
something, but where?.... Do you have some suggestions where to look
or what to check?
Maybe I should also mention that the 2nd SDP is not 100% identical
compared to 1st... the 2nd session identifier differs but I ignore
this. Meaning that the "o=something 1234 9876 IN IP4 192.168.0.1" the
"9876" differs with +1 increment compared to 1st SDP.
Any suggestions are VERY welcome !!
EiSl
