Hello List,
I have problem with T.38 and the RTPproxy by one of mine scenarios. The first one works flawless and looks like that:
Linksys ATA -> NAT -> OpenSer/RTPproxy -> T.38-GW (Asterisk)
The second one on the other hand don't work how it should and looks like this one:
T.38-GW -> SIP-Proxy -> Openser/RTPproxy -> NAT -> Linksys ATA.
The normal RTP stream is opened and they switch over to T.38, but the RTPproxy isn't sending out the received T.38 packets from the ATA.
If the OpenSER is getting a re-INVITE I call the function force_rtp_proxy(). I already tried the function with 'l' parameter but then none of the scenarios are working.
Why is the RTPproxy not relaying like in the 1st scenario?
Which flag should I use to get the things working?
Why is RTPproxy using the same ports like it used for the normal RTP traffic? I thought when I call force_rtp_proxy() a 2nd time I create a new session with different ports? Can I force the RTPproxy to use different ports?
If someone needs a PCAP-trace I can provide this.
Many thanks Jens
Hello jens,
OpenSER is pure signaling to end to ends, Can you see any T.38 header in SDP session in Linksys ATA , in invite method
Thanks &Regards Ravi Prakash Sunkara VoIP Development Tech Lead 91-9999882776 Josh Billings - "There's a great power in words, if you don't hitch too many of them together." 2008/8/1 Jens Carl ml04@reventix.de
Hello List,
I have problem with T.38 and the RTPproxy by one of mine scenarios. The first one works flawless and looks like that:
Linksys ATA -> NAT -> OpenSer/RTPproxy -> T.38-GW (Asterisk)
The second one on the other hand don't work how it should and looks like this one:
T.38-GW -> SIP-Proxy -> Openser/RTPproxy -> NAT -> Linksys ATA.
The normal RTP stream is opened and they switch over to T.38, but the RTPproxy isn't sending out the received T.38 packets from the ATA.
If the OpenSER is getting a re-INVITE I call the function force_rtp_proxy(). I already tried the function with 'l' parameter but then none of the scenarios are working.
Why is the RTPproxy not relaying like in the 1st scenario?
Which flag should I use to get the things working?
Why is RTPproxy using the same ports like it used for the normal RTP traffic? I thought when I call force_rtp_proxy() a 2nd time I create a new session with different ports? Can I force the RTPproxy to use different ports?
If someone needs a PCAP-trace I can provide this.
Many thanks
Jens
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
LetMeKnow schrieb:
Hello jens,
OpenSER is pure signaling to end to ends, Can you see any T.38 header in SDP session in Linksys ATA , in invite method
Yes, I see the T.38 header and also the Linksys starts the T.38 transmission to RTPproxy, but the proxy don't sent it to T.38-GW.
T.38 is not RTP, so I am not sure why one would expect them to be relayed.
Jens Carl wrote:
Hello List,
I have problem with T.38 and the RTPproxy by one of mine scenarios. The first one works flawless and looks like that:
Linksys ATA -> NAT -> OpenSer/RTPproxy -> T.38-GW (Asterisk)
The second one on the other hand don't work how it should and looks like this one:
T.38-GW -> SIP-Proxy -> Openser/RTPproxy -> NAT -> Linksys ATA.
The normal RTP stream is opened and they switch over to T.38, but the RTPproxy isn't sending out the received T.38 packets from the ATA.
If the OpenSER is getting a re-INVITE I call the function force_rtp_proxy(). I already tried the function with 'l' parameter but then none of the scenarios are working.
Why is the RTPproxy not relaying like in the 1st scenario?
Which flag should I use to get the things working?
Why is RTPproxy using the same ports like it used for the normal RTP traffic? I thought when I call force_rtp_proxy() a 2nd time I create a new session with different ports? Can I force the RTPproxy to use different ports?
If someone needs a PCAP-trace I can provide this.
Many thanks
Jens
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
rtpproxy works very well with T.38 (the transport protocol for T.38 is udptl built on top of udp just like rtp). Jens, which version of rtpproxy do you use?
On Fri, Aug 1, 2008 at 2:49 PM, Alex Balashov abalashov@evaristesys.com wrote:
T.38 is not RTP, so I am not sure why one would expect them to be relayed.
Jens Carl wrote:
Hello List,
I have problem with T.38 and the RTPproxy by one of mine scenarios. The first one works flawless and looks like that:
Linksys ATA -> NAT -> OpenSer/RTPproxy -> T.38-GW (Asterisk)
The second one on the other hand don't work how it should and looks like this one:
T.38-GW -> SIP-Proxy -> Openser/RTPproxy -> NAT -> Linksys ATA.
The normal RTP stream is opened and they switch over to T.38, but the RTPproxy isn't sending out the received T.38 packets from the ATA.
If the OpenSER is getting a re-INVITE I call the function force_rtp_proxy(). I already tried the function with 'l' parameter but then none of the scenarios are working.
Why is the RTPproxy not relaying like in the 1st scenario?
Which flag should I use to get the things working?
Why is RTPproxy using the same ports like it used for the normal RTP traffic? I thought when I call force_rtp_proxy() a 2nd time I create a new session with different ports? Can I force the RTPproxy to use different ports?
If someone needs a PCAP-trace I can provide this.
Many thanks
Jens
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Ovidiu Sas wrote:
rtpproxy works very well with T.38 (the transport protocol for T.38 is udptl built on top of udp just like rtp).
I wasn't aware rtpproxy supported udptl. Since when?
On Fri, Aug 1, 2008 at 4:30 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
rtpproxy works very well with T.38 (the transport protocol for T.38 is udptl built on top of udp just like rtp).
I wasn't aware rtpproxy supported udptl. Since when?
long time ago ... can't remember exactly ...
Ovidiu Sas wrote:
On Fri, Aug 1, 2008 at 4:30 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
rtpproxy works very well with T.38 (the transport protocol for T.38 is udptl built on top of udp just like rtp).
I wasn't aware rtpproxy supported udptl. Since when?
long time ago ... can't remember exactly ...
Ah, well - at any rate, thank you, I stand corrected!
-
Alex Balashov -
Jens Carl -
LetMeKnow -
Ovidiu Sas