Unfortunately rtpengine doesn't work in this way. At the end of the calls this is the output log:
Final packet stats:
Tag 'Fw3D7R0', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30224 <> 192.168.10.20:7078 , 540 p, 92880 b, 0 e
Media #1, port 30225 <> 192.168.10.20:7079 (RTCP), 3 p, 324 b, 0 e
Media #2, port 30256 <> 192.168.10.20:9078 , 0 p, 0 b, 0 e
Media #2, port 30257 <> 192.168.10.20:9079 (RTCP), 3 p, 264 b, 0 e
Tag 'qWE6Gsh', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30140 <> 192.168.10.50:7078 , 533 p, 91068 b, 0 e
Media #1, port 30141 <> 192.168.10.50:7079 (RTCP), 5 p, 444 b, 0 e
Media #2, port 30170 <> 192.168.10.50:9078 , 0 p, 0 b, 0 e
Media #2, port 30171 <> 192.168.10.50:9079 (RTCP), 1 p, 88 b, 0 e
Tag 'TTPyT~Hdw', created 0:41 ago, in dialogue with 'Fw3D7R0'
Media #1, port 30206 <> 172.20.11.208:7078 , 1070 p, 183736 b, 0 e
Media #1, port 30207 <> 172.20.11.208:7079 (RTCP), 4 p, 496 b, 0 e
Media #2, port 30240 <> 172.20.11.208:9078 , 4188 p, 1435946 b, 0 e
Media #2, port 30241 <> 172.20.11.208:9079 (RTCP), 4 p, 400 b, 0 e
192.168.10.x clients are natted..it seems that rtpengine open 2 ports (for example video) for each receiver (30256 & 30170) and 1 port for the caller (30240). But on the INVITE of Kamailio only video port 30170 is offered to receivers, instead on caller side there are 2 distinct 183s message that offer 30190 & 30240. It's a little bit strange because some of these port doesn't appear in the log of rtpengine. At the end I can see video only on one receiver
I don't know if the problem is on Kamailio (rtpproxy-ng module) or in the rtpengine :)
> 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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users