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

Espen Berg espen at monsternett.no
Thu Apr 15 13:05:48 CEST 2010


Den 14.04.2010 14:27, skrev Klaus Darilion:

> 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 ...

Seems to be no problems there, xlite are able to pickup the call again 
after "on-hold".  But I have to do some more testing here.


>> 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.

As long as I use the ie/ei flags correct in the "RTP OFFER 
ROUTE"-section, everything should be fine?  The RTP offer and RTP answer 
onreply route both refer to route 2.

route[2] {
     if (src_ip == "IP.TO.TRUNK" || dst_ip == "LOCAL.IP.ETH1")
         force_rtp_proxy("eir");
     else
         force_rtp_proxy("ier");
}

But in my head that should be correct since i filter on the IP-address. 
  Correct?

>>
>> 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.

Could that cause some problems for me?  If it has totag and have a route 
it should exit, else it should check if the current request is 
associated to a request, if ok it should relay else exit.

How would you have written it?


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

I'd really hoped for an error here. :\

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

I'm not able to spot any errors, the only error I'm able to see is that 
it seems to work one way.

If A sends a fax to B

This works with T.38:
asterisk A <-> sipprovider <-> our trunk <-> kamailio/rtpp <-> asterisk 
<-> asterisk B (our asterisk)

This fails with T.38, but works with G.711:
asterisk B -> asterisk -> kamailio/rtpp -> our trunk -> asterisk -> 
asterisk A

Could also be an Asterisk (A: 1.6.2.5/tested with 1.6.2.7rc, B: 1.6.2.6) 
or FFA bug.  But if I try to send the FAX directly via SIP from A <-> B 
without the proxy everything works OK, so therefore I believe the 
problem are related to my kamailio configuration.


Appreciate all the help I can get.

Espen.




More information about the sr-users mailing list