9 Jul
2008
9 Jul
'08
11:18 a.m.
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
9 Jul
9 Jul
5:31 p.m.
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
10 Jul
10 Jul
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
11 Jul
11 Jul
7:38 a.m.
New subject: [OpenSER-Users] Can openSER retransmit the request
Hi All,
Can openSER retransmit requests to the receiver(eg: UAS) on behalf of caller (eg: UAC)?
Regards
Vijay
-----Original Message-----
From: users-bounces(a)lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf
Of Jens Carl
Sent: Thursday, July 10, 2008 6:09 PM
To: users(a)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:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
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
14 Jul
14 Jul
10:21 a.m.
New subject: [OpenSER-Users] Can openSER retransmit the request
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(a)lists.openser.org [mailto:users-bounces@lists.openser.org] On Behalf
Of Jens Carl
Sent: Thursday, July 10, 2008 6:09 PM
To: users(a)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(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
>
>
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5984
days inactive
5989
days old
4 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Jens Carl -
Sundaramoorthy, Vijaianand