[OpenSIPS-Users] rtpproxy and parallel forking

[Eric Tamme]

Hi Pete,

To the best of my knowledge no rtp proxy: mediarelay, rtpengine, 
rtpproxy deals with forking and early media "well".  I believe this is 
more a failing of the 183 draft than anything else.  For example If I 
parallel fork a call to A and B, A sends 183 with an IVR but then B 
sends a 200 it is not clear what should be done - send a CANCEL to A and 
terminate any IVR?

RTPEngine does have ... sort of a work around in that it will allow you 
to specify whether or not to automatically "train" to a rtp source - 
this allows you to set up a call with early media to A, but then if B 
starts sending RTP to the same allotted ports RTPEngine will simply 
switch to those ports.  This has several security implications - 
Freeswitch has a similar feature which allows the rtp source to change 
within a given allotted "buffer".

To answer your question directly - no, I do not know of a way to do 
parallel forking with rtpproxy where one leg may send early media. We 
have experienced this as well when our customers put multiple pstn phone 
numbers in a ring group and have advised them that it will not work 
should one of those numbers provide early media.

Hope all is well,
-Eric



On 09/23/2015 02:44 AM, Pete Kelly wrote:
> I am using rtpproxy with parallel fork and noticed some interesting 
> behaviour (by rtpproxy).
>
> If the INVITE is forked to 2 destinations (A and B), one of them (A) 
> may send a 183 with media, meaning there is media being sent to the 
> rtpproxy.
>
> However if it is B that answers, rtpproxy will still only be set up to 
> send and receive media to A, and will continue to do so which means 
> there is no media on the call.
>
> Reading the rtpproxy docs I think it is because of this:
>
> "After the session has been created, the proxy listens on the port it 
> has allocated for that session and waits for receiving at least one 
> UDP packet from each of two parties participating in the call. Once 
> such packet is received, the proxy fills one of two ip:port structures 
> associated with each call with source ip:port of that packet"
>
> Is there a known way round this issue, other than stopping A from 
> sending media to rtpproxy or using late offer INVITEs?
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150923/b52060c7/attachment.htm>