10 Jul
2008
10 Jul
'08
2:39 p.m.
Hey Bogdan,
if I use a scenario like this
SIP-FAX1 (Public IP) <-> RTPProxy+OpenSER <-> Asterisk <-> Carrier
I didn't get the warning from the Asterisk and the T.38 is transfered
without any problems. The RTPproxy is not used in this scenario. So
there must be difference between the these both cases.
If I use the function force_rtp_proxy( 'l' ) will the RTPproxy create a
new session with new ports? This important because the Asterisk uses a
different port-range for T.38 then for the normal RTP stream.
Regards,
Jens
Bogdan-Andrei Iancu schrieb:
Hi Jens,
RTPproxy does not change anything in the RTP stream (not event the size
of the packages), so I think the guilty one is not the rtpproxy - it
just a transparent relay.
Have you tried this directly, with no rtpp in the middle?
Regards,
Bogdan
Jens Carl wrote:
Hey everybody,
I use OpenSER (openser 1.3.2-tls (x86_64/linux), svnrevision: 2:4420)
and the RTPproxy (1.1) and everything works fine expect for one thing.
If I try to use T.38 with following scenario:
SIP-FAX1 (NAT) <-> RTPProxy+OpenSER <-> Asterisk <-> Carrier
the Asterisk always produce this kind of warning:
'WARNING[1493]: rtp.c:1145 ast_rtp_read: RTP Read too short'.
The SIP-signaling with the re-INVITE works fine. If I get an re-INVITE
I call the force_rpt_proxy( 'l' ).
Has anybody an idea what I should change in the RTPproxy to get this
scenario working?
Thanks for your help,
Jens
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users