Hi Richard, 

this is more or less the same problem that I am experiencing. To understand it better, just assume one branch needs to do SRTP, and the other simple RTP.

To make this happen, you will have to enable rtpengine differently for the same call, and this is where the crash/error happens.

Regards,
Carlos

On Tue, Sep 30, 2014 at 2:51 AM, Marino Mileti <marino.mileti@alice.it> wrote:
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



_______________________________________________
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




--
Carlos
http://caruizdiaz.com