[OpenSIPS-Users] Mediaproxy not updating with new SDPs

[Richard Revels]

Saul,

Could you verify you got the trace file I sent?  I mailed it directly to you so I wouldn't have to worry about obfuscation on the IP addresses and want to make sure I didn't get caught in a spam filter or anything.

Richard

On Jul 27, 2010, at 7:48 AM, Richard Revels wrote:

> Re RFC4317, yes that is the scenario.  My complaint here has nothing to do with opensips.  I was just venting about the UA sending the reinvite so quickly after the ACK that it sometimes reaches the destination first.  Let's just say that not all endpoints handle this as gracefully as they could.  : >
> 
> Re reinvite, I thought I understood engage_media_proxy would handle reinvites automagically.  Just making sure.  Thank you for verifying that.
> 
> Re UA port, yes it is advertising one port and using another.  A picture is worth a thousand words.  I'll send the trace.
> 
> Richard
> 
> 
> On Jul 27, 2010, at 4:21 AM, Saúl Ibarra Corretgé wrote:
> 
>> Hi Richard,
>> 
>> On 24/07/10 23:05, Richard Revels wrote:
>>> 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...
>>> 
>> 
>> So, would this be RFC4317 section 2.2? THat is: user A invites user B 
>> with 3 codecs but he only supports one at a time. Then B answers with 2 
>> codecs and A reinvites with a single codec. Is this right?
>> 
>>> 5) reinvite is forwarded without any mediaproxy calls or anything from the script
>> 
>> If you are using engage_media_proxy this is done automatically by the 
>> dialog module.
>> 
>>> 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 UA said he is using port 1082, but is he actually using it? Or 
>> is he advertising one port and then using a different one?
>> 
>>> 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?
>>> 
>> 
>> Session information is updated with any reinvite that could take place. 
>> Could you provide me with a SIP trace for the whole call?
>> 
>> 
>> Regards,
>> 
>> -- 
>> Saúl Ibarra Corretgé
>> AG Projects
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>