The current implementation of mediaproxy.c has a flag called skip_next_reply in structure ice_candidate_data.
// - skip_next_reply: flag for knowing the fact that the next reply with SDP must be skipped
// because it is a reply to a re-INVITE or UPDATE *after* the ICE negotiation
But this flag only ignores the first reply to re-INVITE, and resets to false after the first reply comes.
} else if (msg->first_line.type == SIP_REPLY) {
if (ice_data != NULL && ice_data->skip_next_reply) {
// we don't process replies to ICE negotiation end requests
// (those containing a=remote-candidates)
ice_data->skip_next_reply = False;
return -1;
}
In 2G or other low speed network, UAS may retransmit SIP reply more than once. Thus media-proxy may still process these replies and wrongly open new ports for relay or even close the ports that are being used. Here is my log for media-proxy in such situation. Is there any idea to fix this bug?
log of media proxy
Can you please attach a SIP trace of such a call?
CAPTURE of sip messages
Hi saghul,
I uploaded the captured sip messages. The dialog whose call-id is OUxwFrwW causes this problem. And log.txt is the log of media-proxy and media-relay. My IP of my Sip Server is 211.154.154.77. Is it enough?
My SIP flow may be a little complex. When callee is offline, my opensips will forward the call to another application which inform the callee to get online. And when the callee is online, opensips will tell my application, a 480 reply is generated, and opensips will forward to call to callee in FAILURE_ROUTE. But I think this flow do not affect media-proxy. The retransmition of replies of re-INVITE causes media-proxy not to work