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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi,

yes, it can, if you use the TM module functions (Transaction functions) like t_relay()

Regards, Bogdan

Sundaramoorthy, Vijaianand wrote:

Hi All,

Can openSER retransmit requests to the receiver(eg: UAS) on behalf of caller (eg: UAC)?

Regards Vijay

-----Original Message----- From: users-bounces@lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf Of Jens Carl Sent: Thursday, July 10, 2008 6:09 PM To: users@lists.openser.org Subject: Re: [OpenSER-Users] T.38 and RTP Read too short

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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users