[OpenSIPS-Users] Mediaproxy not updating with new SDPs

[Richard Revels]

Saul (and everyone) good afternoon.

I think I've come across a call flow that Mediaproxy would be expected to handle but is not.  Umm, it's like sacrilege I know; but I think Mediaproxy may have a bug.

1) The originator sends INVITE with a couple of codec choices.
2) engage_media proxy is called and the INVITE is forwarded
3) 200 comes back with a couple of codec choices and m line indicates rtp will source from port 35210 (and indeed rtp starts sourcing from there
4) The ACK comes back and for 10 milliseconds life is good

Then the Originator reinvites with only the single codec choice that it believes was negotiated.  Standard procedure for this device and allowed and all that but really, 10 milliseconds?? Anyway...

5) reinvite is forwarded without any mediaproxy calls or anything from the script
6) The destination sends back a 200 but this time claims it will source from port 1082.
7) The destination rtp continues to source from the original port 35210

So, the result here is that rtp comes from the origination and is forwarded, by Mediaproxy, to port 35210 at the destination where it is happily accepted.  Media also flows from the destination from port 35210 but it is not forwarded which results in one way audio on the call.

It will be Monday before I am able to request more calls to be made but I'm kind of thinking the firewall may be the cause of the port not changing and the UA is actually sending from a new port.  Maybe not though.  

In either case, should the Mediaproxy have waited for a rtp packet on any port from the (call) destination IP after the 200 to the reinvite and set a new connection track rule after it saw one?

I'm using Mediaproxy 2.4.2.

Richard



On Jul 21, 2010, at 5:14 PM, Saúl Ibarra Corretgé wrote:

> Hi Jeff,
> 
> On 21/07/10 21:50, Jeff Pyle wrote:
>> Hello,
>> 
>> I am using Mediaproxy 2.3.8 with Opensips 1.6 r6702.  I use the engage_media_proxy() function.  Most things work pretty well except for the following scenario:
>> 
>> Call comes in from CPE, hits the engage_media_proxy() function, and t_relay's to the far end.  The far-end sends a 503, but before they do, they send some media.  I'm working with them now to determine the true source of this unwanted media.  Anyway, Opensips does a serial fork to the next carrier, who sends a 183 w/ SDP, and finally a 200 OK.  But the media relay has already locked down to the media the first carrier sent.  How come the media relay doesn't learn about the new media information from the SDPs in the 183 and the 200?
>> 
> 
> MediaProxy uses the information from the SDP from both ends and then it 
> waits to receive a RTP packet from each endpoint. Once this happens it 
> inserts a conntrack rule in the kernel so that the relaying is performed.
> 
> I could judge better with a SIP trace but my guess is that the dialog 
> could get to an inconsistent state, so mediaproxy loses track.
> 
>> I'd like to be able to wait for an SDP to come back on a 18x or a 200 before starting the relay.  It appears the engage_media_proxy() function is available only from the REQUEST_ROUTE.  Perhaps it would be smarter in this case to use the use_media_proxy()/end_media_session() functions in the REPLY_ROUTE and FAILURE_ROUTEs.
>> 
> 
> You are right. Engage_media_proxy covers most general purpose scenarios 
> but it's not suitable for everyone, so in this case you may want yo call 
> the individual functions manually.
> 
> 
> Regards,
> 
> -- 
> Saúl Ibarra Corretgé
> AG Projects
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users