<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Pete,<br>
<br>
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?<br>
<br>
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".<br>
<br>
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.<br>
<br>
Hope all is well,<br>
-Eric<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 09/23/2015 02:44 AM, Pete Kelly
wrote:<br>
</div>
<blockquote
cite="mid:CAEWH9M-sfcGGQL1T6y4k=cQ4dPa-US=W+2PikSO1dt_zx_Ad4Q@mail.gmail.com"
type="cite">
<div dir="ltr">I am using rtpproxy with parallel fork and noticed
some interesting behaviour (by rtpproxy).
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Reading the rtpproxy docs I think it is because of this:</div>
<div><br>
</div>
"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"
<div><br>
</div>
<div>Is there a known way round this issue, other than stopping
A from sending media to rtpproxy or using late offer INVITEs?</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>