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

29 Sep 2014

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