[OpenSIPS-Users] mediaproxy and reinvites

[Dan Pascu]

On Friday 24 April 2009, Uwe Kastens wrote:
> Hello again,
>
> > If you use engage_media_proxy(), you need to do nothing. Every
> > re-INVITE and other in dialog messages are processed automatically. A
> > re-INVITE used to start T38 is part of the original dialog, so you
> > cannot call engage_media_proxy() again even if you want to, because
> > no new dialog is started to trigger a new media session.
> >
> > If the SDP is not modified, it may be a bug. We have tested T38 fax
> > support and it worked for us. You need to figure out from the
> > opensips and mediaproxy logs what is happening (i.e. is mediaproxy
> > contacted by opensips or is that the mediaproxy module is not even
> > seeing the re-INVITE?).
>
> This is what mediaproxy does. I will attach the opensips.log. Even with
> debug=9 I will noch catch any line with mediaproxy.
>
> The 2nd Invite on 08:36:02 is not handled by mediaproxy as far as I
> understand.
>

That can mean that mediaproxy was not called at all by the dialog module.
From the mediaproxy trace I see that after the session is established with 
audio, it only gets an update request (instead of two) to switch to t38. 
Every re-INVITE should trigger two updates in mediaproxy (one for the 
request and one for the reply). In your case one is missing. Further 
examining the opensips log reveals that the did param in the Route header 
is missing on several in dialog messages:

Apr 24 08:36:00 xxxe02 /usr/sbin/opensips[16850]: DBG:dialog:dlg_onroute: 
Route param 'did' not found
Apr 24 08:36:02 xxxe02 /usr/sbin/opensips[16849]: DBG:dialog:dlg_onroute: 
Route param 'did' not found
Apr 24 08:36:02 xxxe02 /usr/sbin/opensips[16850]: DBG:dialog:dlg_onroute: 
Route param 'did' not found

This means that one of the devices is stripping the did param which can 
result in the dialog module not being able to match the in-dialog request 
and consequently not call the mediaproxy callbacks to alter the SDP.

You should use DID_FALLBACK mode for matching dialogs, so if it can't find 
the did param in the Route header it falls back to SIP elements matching:

modparam("dialog", "dlg_match_mode",      1)

If this doesn't help either, you may need to use use_media_proxy() and 
end_media_session() explicitly on each request/reply as appropriate.

>
>
> Apr 24 08:35:59 xxxe02 media-relay[15183]: debug: Received new SDP
> offer Apr 24 08:35:59 xxxe02 media-relay[15183]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 5092
> Apr 24 08:35:59 xxxe02 media-relay[15183]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 5093
> Apr 24 08:35:59 xxxe02 media-relay[15183]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 5094
> Apr 24 08:35:59 xxxe02 media-relay[15183]:
> mediaproxy.mediacontrol.StreamListenerProtocol starting on 5095
> Apr 24 08:35:59 xxxe02 media-relay[15183]: debug: Added new stream:
> (audio) 99.99.207.101:7078 (RTP: Unknown, RTCP: Unknown) <->
> 20.20.142.152:5092 <-> 20.20.142.152:5094 <-> Unknown (RTP: Unknown,
> RTCP: Unknown)
> Apr 24 08:35:59 xxxe02 media-relay[15183]: debug: created new session
> E32739A33CEFD033 at 99.99.207.101: 1234503878 at external-domain.de
> (7BF429B86410D022) --> 7097555 at external-domain.de
> Apr 24 08:36:00 xxxe02 media-dispatcher[15200]: debug: Issuing "update"
> command to relay at 20.20.138.142
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: updating existing
> session E32739A33CEFD033 at 99.99.207.101: 1234503878 at external-domain.de
> (7BF429B86410D022) --> 7097555 at external-domain.de
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Received updated SDP
> answer
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Got initial answer
> from callee for stream: (audio) 99.99.207.101:7078 (RTP: Unknown, RTCP:
> Unknown) <-> 20.20.142.152:5092 <-> 20.20.142.152:5094 <->
> 20.20.138.102:13532 (RTP: Unknown, RTCP: Unknown)
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Got traffic
> information for stream: (audio) 99.99.207.101:7078 (RTP: Unknown, RTCP:
> Unknown) <-> 20.20.142.152:5092 <-> 20.20.142.152:5094 <->
> 20.20.138.102:13532 (RTP: 20.20.138.102:13532, RTCP: Unknown)
> Apr 24 08:36:00 xxxe02 media-dispatcher[15200]: debug: Issuing "update"
> command to relay at 20.20.138.142
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: updating existing
> session E32739A33CEFD033 at 99.99.207.101: 1234503878 at external-domain.de
> (7BF429B86410D022) --> 7097555 at external-domain.de
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Received updated SDP
> answer
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Unchanged stream:
> (audio) 99.99.207.101:7078 (RTP: Unknown, RTCP: Unknown) <->
> 20.20.142.152:5092 <-> 20.20.142.152:5094 <-> 20.20.138.102:13532 (RTP:
> 20.20.138.102:13532, RTCP: Unknown)
> Apr 24 08:36:00 xxxe02 media-relay[15183]: debug: Got traffic
> information for stream: (audio) 99.99.207.101:7078 (RTP:
> 99.99.207.101:7078, RTCP: Unknown) <-> 20.20.142.152:5092 <->
> 20.20.142.152:5094 <-> 20.20.138.102:13532 (RTP: 20.20.138.102:13532,
> RTCP: Unknown)
> Apr 24 08:36:05 xxxe02 media-relay[15183]: debug: Got traffic
> information for stream: (audio) 99.99.207.101:7078 (RTP:
> 99.99.207.101:7078, RTCP: Unknown) <-> 20.20.142.152:5092 <->
> 20.20.142.152:5094 <-> 20.20.138.102:13532 (RTP: 20.20.138.102:13532,
> RTCP: 20.20.138.102:13533)
>
>
>
> BR
>
> Uwe



-- 
Dan