Hi, Jeff!
The main problem is that nor opensips neither rtpproxy can differentiate
between the first SDP streams and the second one. The reason is that
both OpenSIPS and RTPProxy only consider the order the streams are in
the SDP packet, and in your case, both of them are first.
Solving this on OpenSIPS side is quite challenging, since we have to
keep a state between the first SDP stream (remember it is an audio
session and mark it as stream no. 1) and when the second SDP stream
comes in, check whether it is a new one or not (in your case determine
it is a different one, T.38, and mark it as stream no. 2). We will
definitely not implement this in OpenSIPS, since it is not the correct
approach.
Ideally each SDP should have an unique identifier that is passed to
RTPProxy by OpenSIPS, but unfortunately this is not supported in RTPProxy.
So with the current code, I can't see how your issue can be solved. The
only think you can do is add a bug report for both projects, detailing
the problem.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 09/12/2014 04:11 AM, Jeff Pyle wrote:
List,
I was never able to truly solve this issue. Instead I worked around
it by preventing the ports from changing between the G711 and the T38
sessions. Well, now I've encountered situations I can't control. I
need to ask again if anyone has any thoughts on how to handle a
refused re-invite in rtpproxy when the proposed session was going to
use different RTP port numbers than the existing one.
All the details are in the thread.
Thanks in advance for any suggestions.
- Jeff
On Thu, Feb 6, 2014 at 7:57 PM, Jeff Pyle <[email protected]
<mailto:[email protected]>> wrote:
Just for grins I tried the engage_rtp_proxy() approach instead.
It has the same problem, using the newly indicated ports on the
old session. This sounds like a bug to me.
- Jeff
On Tue, Feb 4, 2014 at 10:06 AM, Jeff Pyle
<[email protected] <mailto:[email protected]>> wrote:
Hello,
This is on Opensips 1.10 and rtpproxy 1.2.1. I have them
dual-homed on public and private networks with rtpproxy in
bridge mode. Overall, things work well. I've recently
encountered a problem I don't know how to solve relating to a
T.38 reinvite that is rejected by the public side. rtpproxy
uses the new ports in the T.38 SDP even though it was
rejected, effectively killing the G.711 session that should be
maintained.
Here's a specific call flow. A call comes in from the public
side and is routed to the private side, having rtpproxy_offer
run on it. The private UA 10.1.30.219 answers the G.711 call
with this SDP in its 200 OK:
v=0.
o=userX 198 2 IN IP4 10.1.30.219.
s=-.
c=IN IP4 10.1.30.219.
t=0 0.
m=audio *50460* RTP/AVP 0.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
rtpproxy_answer happens on this; the call establishes with
two-way RTP and all is well. A few moments later the private
UA re-invites to T.38 with this SDP:
v=0.
o=userX 198 3 IN IP4 10.1.30.219.
s=-.
c=IN IP4 10.1.30.219.
t=0 0.
m=image *50462* udptl t38.
a=T38FaxVersion:0.
a=T38MaxBitRate:14400.
a=T38FaxRateManagement:transferredTCF.
a=T38FaxMaxBuffer:262.
a=T38FaxMaxDatagram:176.
a=T38FaxUdpEC:t38UDPRedundancy.
You'll notice the UA has changed its port from 50460 to 50462.
rtpproxy_offer("frocl") is called on this re-INVITE and
rtpproxy redirects the inbound RTP to 10.1.30.219
<http://10.1.30.219>:*50462*.
A few milliseconds later a 488 comes in from the public side.
We're left with our original G.711 session, which is fine,
but the RTP is now going to 50462 instead of 50460 and the UA
doesn't see it.
I'm struggling with an rtpproxy_offer/rtpproxy_answer
configuration to allow the session to revert in the event the
re-invite is rejected like this. I've tried rtpproxy_offer
without the "l" lookup flag - no effect. Any thoughts?
Another detail... I use rtpproxy_offer/rtpproxy_answer to
manage mixed early and late negotiation scenarios that
engage_rtp_proxy() cannot handle. The automatic function
isn't an option unfortunately.
- Jeff
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
