In our application, we are using getting a SIP invite that has SDP for 2 separate audio streams with a label included, to identify which RTP stream in the SDP data represents the caller and the callee. We are then splitting taking the SDP and splitting it into separate SDP and passing the "caller" SDP data along with the "offer" NG protocol function, then passing a "label:caller" tag in the metadata for the start forwarding call. After this, we are invoking "answer" and passing the "callee" SDP fields. After answer is successful, we are passing "label:callee" to the start forwarding function here.
However, on our client side, when we get the RTP data, it seems we are receiving the "caller" metadata along with the "callee" audio data and vice versa. I have uploaded RTP engine and RTP engine recorder logs
rtpengine-recorder.logrtpenginelog.log
In our application, we are using getting a SIP invite that has SDP for 2 separate audio streams with a label included, to identify which RTP stream in the SDP data represents the caller and the callee. We are then splitting taking the SDP and splitting it into separate SDP and passing the "caller" SDP data along with the "offer" NG protocol function, then passing a "label:caller" tag in the metadata for the start forwarding call. After this, we are invoking "answer" and passing the "callee" SDP fields. After answer is successful, we are passing "label:callee" to the start forwarding function here.
However, on our client side, when we get the RTP data, it seems we are receiving the "caller" metadata along with the "callee" audio data and vice versa. I have uploaded RTP engine and RTP engine recorder logs rtpengine-recorder.log rtpenginelog.log