[OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified

[Dan Pascu]

On Friday 13 February 2009, Carlo Dimaggio wrote:
> Il giorno 13/feb/09, alle ore 13:56, Dan Pascu ha scritto:
> > The Patton device seems to be faulty. In its answer it strips all
> > params
> > from the Record-Route header except from lr=on. Similarly it strips
> > all
> > params from the Record-Route headers except lr=on when converting the
> > Record-Route headers to Route headers on subsequent re-INVITEs. Among
> > these params is the did (dialog-id) which is used to identify the
> > dialog
> > the message belongs to. My guess is that those re-INVITEs are not
> > matched
> > against their dialogs anymore so no mediaproxy callbacks are called
> > for
> > them to modify their SDP.
> >
> > You can try to use use_media_proxy() and end_media_session() instead
> > of
> > engage_media_proxy() to manually call on mediaproxy to handle the
> > SDP for
> > every INVITE/reply during the dialog. The dialog based method of
> > using engage_media_proxy can only work if the devices work properly
> > and do not
> > prevent the dialog module from recognizing an in-dialog message
> > because
> > its identification elements were altered.
>
> Thank you Dan/Adrian/Ruud for your quick and expert answers :-)
>
> I understand. Do you think I can write to tech support of Patton and
> explain the problem? It is a bug in their firmware or a "particular"
> behaviour?
> I would like to continue using engage_media_proxy...

It is a bug. Any UA should return the Record-Route headers in the 200 OK, 
exactly as they were received. Also all Record-Route headers should be 
copied exactly, but in reverse order into Route headers in subsequent 
dialog requests. All params present in the Record-Route headers must be 
preserved exactly, including their case.

However I belienve that this is not all there is to this problem. The 
dialog module is able to fallback to matching SIP elements to identify 
the dialog if the did is not present. If the missing dialog-id would have 
been the only issue then it would have not been able to match the BYEs 
either, but it does. Also with the call made in one direction, it always 
works, even when the did is missing, but when the call is made in the 
other direction it fails to match the re-INVITEs to the dialog and call 
the mediaproxy callbacks.

There is a bug in the dialog module where it somethimes doesn't match 
messages because there is a race in saving the to-tag internally. I have 
seen many times how ACKs are not matches to the dialog and sometimes even 
BYEs fail to match. It may be that what you have is a combination of all 
these, not just the broken Record-Route headers.

One thing that I'm certain about is that mediaproxy is not called for 
those messages because for some reason the dialog module fails to match 
them as part of the dialog. Maybe someone who knows better how the 
matching is done inside the dialog module, may shed some more light why 
this happens, and more importantly why it only happens in one direction 
(only when the patton initiates the call).

-- 
Dan