Update call.c #1126
Update call.c #1126
Conversation
If the consecutive answer is from different media endpoint, then we need to check if rtcp-mux was offered initially by the client
|
Can you describe a concrete case that this would fix? I would like to add it to the automated tests. |
|
Client sends the offer with rtcp-mux; RTPEngine does rtcp-demux and sends the new offer to peer 2nd answer back from the peer (200) with c=E.F.G.H; RTPEngine replies to client with rtcp-mux (after fix) |
|
Hm ok, can't really reproduce that... does the 200 answer also have a different to-tag than the 183? |
|
That's correct, 200 has got different to-tag than 183 |
|
Ok I see. I don't think this is the correct solution. In fact it breaks an existing test case. Is there any branching/forking going on in your routing logic, or do you simply get two answers with different to-tags unsolicited? |
|
I simply get two answers with different to-tags. btw. what is the scenario of test case "gh #793 b2"? |
Similar to your case, but for a deliberately branched call (using I'll have to think about how this can be fixed nicely. |
If the consecutive answer is from different media endpoint (e.g. early media scenario with different media endpoint used for 183), then we are loosing RTCP_MUX_OVERRIDE, as it was set for the previous answer. We need to explicitly check if rtcp-mux was initially offered by the client.