On 09/29/14 14:51, Marino Mileti wrote:

Without rtpproxy:

• A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted

client so no needs of rtpproxy)

• B offers port b1,b2 (183)
• C offers port c1,c2 (182).
• A starts to send audio/video RTP to B on port b1,b2
• A starts to send audio/video RTP to C on port c1,c2

With rtpproxy:

• A offers port a1,a2 (audio video) in INVITE to Kamailio....
• Kamailio contact rtpproxy because B&C are natted clients
• rtpproxy check callid and offer offers port k1,k2....
• Kamailio sends INVITE to B offering k1,k2
• Kamailio sends INVITE to C offering k1,k2
• B offers port b1,b2 (183)
• C offers port c1,c2 (182)
• Kamailio sends 183 to A (for B leg) offering p1,p2
• Kamailio sends 183 to A (for B leg) offering p3,p4
• A starts to stream on p1,p2,p3,p4 but only one receiver can see the video

(B or C depends who will be the first:))

I don't know if it depends on that B & C receives same ports; i don't know if rtpproxy is able to "duplicate" stream received from A to all "receiver"

If A sends two streams, there is no need for duplication. A sending to p1 should be forwarded to B (b1) and A sending to p3 should be forwarded to C (c1). Both should be able to receive media sent by A. I believe that's what rtpengine does (but I haven't tested it). The reverse direction might be more confusing, but a final 200 OK with SDP should fix that.

cheers