[SR-Users] R: Re: R: Re: RTPPROXY & BRANCH

[Richard Fuchs]

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