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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
