[OpenSIPS-Users] Mediaproxy not updating with new SDPs

[Saúl Ibarra Corretgé]

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