[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