[SR-Users] Re-invite problems with t.38?

Klaus Darilion klaus.mailinglists at pernau.at
Wed Apr 14 14:27:00 CEST 2010


Hi!

1. it is useful to find out if the problem happens due to a T.38 
reINVITE or with all reINVITEs. You could easily test this by just 
putting a call on-hold, and back off-hold (e.g. by pressing the line 
button in Xlite) and verify if audio works again.

more inline ...

Am 14.04.2010 11:28, schrieb Espen Berg:
> Hello all!
>
> I finally have something that I could call a working config (almost that
> is), the proxy works fine with voice and fax sent over g.711 (but I
> guess re-invites will cause problems in this scenario also). The
> problem occurs when I try to switch to T.38. Since it works with voice
> my guess is that the problem is caused by the re-invite to t.38. I
> guess it has to be solved by a if (loose_route()) section, but I am
> little bit clueless right now, I have tried multiple variants but with
> no success.
>
> RTP proxy is started with the -l flag to distinguish between local and
> public traffic.
> -l PUBLIC.IP.ETH0/LOCAL.IP.ETH1

I would reverse the interfaces as the first interface corresponds with 
the "internal" interface and the second with the "external". See 'ie' 
flags at
http://sip-router.org/docbook/sip-router/branch/master/modules_k/nathelper/nathelper.html#id2584057

When a call is routed from local IP to public IP I would like to name it 
internal-to-external, hence 'ie' flags instead of 'ei', but that s just 
a matter of naming and shouldn't cause problems.


> The setup:
> Sonus UAC/Trunk <-private ip-> (eth1)Kamailio/RTPProxy(eth0) <-public
> ip-> Asterisk
>
> IP.TO.TRUNK = Sonus IP, public address range, but only reachable by
> private net (from the range of LOCAL.IP.ETH1).
>
> LOCAL.IP.ETH1 = Local net, static route to IP.TO.TRUNK.
> PUBLIC.IP.ETH0 = Public routable address.
> IP.TO.ASTERISK = Public routable address.
>
> The purpose of Kamailio/RTPProxy are to proxy everything between the
> routable and the private net.
>
> Does anyone here have any idea of how I'm going to solve my issue? It
> would also be nice if anyone here have better solutions to my approach,
> and there could also be some other errors in my config that causes this
> behaviour.
>
>
>
> ####### Routing ########
>
> route {
>
> if (msg:len >= 2048) {
> sl_send_reply("513", "Message too big");
> exit;
> }
>
>
> if (method != "INVITE" && method != "ACK" && method != "BYE" &&
> method != "CANCEL") {
> sl_send_reply("503", "Service Unavailable");
> exit;
> }
>
> if (!has_totag()) {
> record_route();
> route("1");
> }
>
> if (has_totag()) {
>   if (!loose_route()) {
>     if (t_check_trans()) {
>       t_relay();
>       exit;
>     }
>     exit;
>   }
> }


That's strange. You shouldn't allow requests with totag but without 
loose-routing. But that's not related to your problem.

> if (has_body("application/sdp")) {
> if (method == "INVITE") {
> route("2");
> t_on_reply("2");
> } else if (method == "ACK") {
> rtpproxy_answer();
> }
> } else if (method == "INVITE") {
> t_on_reply("2");
> }
>
>
> if (method == "BYE" || method == "CANCEL") {
> unforce_rtp_proxy();
> }
>
> t_relay();
> }
>
> #RELAY BY SOURCE ROUTE
> route[1] {
> if (src_ip == "IP.TO.TRUNK" || dst_ip == "LOCAL.IP.ETH1") {
> force_send_socket("PUBLIC.IP.ETH0");
> rewritehost("IP.TO.ASTERISK");
> } else {
> force_send_socket("LOCAL.IP.ETH1");
> rewritehost("IP.TO.TRUNK");
> }
> }
>
> # RTP OFFER ROUTE
> route[2] {
> if (src_ip == "IP.TO.TRUNK" || dst_ip == "LOCAL.IP.ETH1")
> force_rtp_proxy("eir");
> else
> force_rtp_proxy("ier");
> }
>
> # RTP OFFER ONREPLY
> onreply_route[1] {
> if (has_body("application/sdp"))
> route("2");
> }
>
> # RTP ANSWER ONREPLY
> onreply_route[2] {
> if (has_body("application/sdp"))
> route("2");
>
> }
>
> ## END OF CONFIG
>
> Sorry for the long post, but I hope someone outthere are able to help
> med with this issue.


IMO the config is a bit strange but I couldn't spot an error.

Trace the scenario with ngrep and take a look at the SDPs if they are 
rewritten properly.

regards
klaus
>




More information about the sr-users mailing list