18 Mar
2011
18 Mar
'11
12:48 p.m.
So, I've made resetup of network to run tests.
I've figured out, that one of the routers were changing SIP headers,
i.e. Contacts header to public IP. This caused UAC under this router not
to use STUN and gave one way audio.
Now I'm using fix_nated_contact and fix_nated_register. Location table
contains correct IPs. However, when I'm making a call, RTP is sent to
private IP. With STUN IP is correct. Where it comes from?
I tried also STUN and force_rtp_proxy() with 'r' flag. Nothing has
changed - destination port for RTP traffic differs from source port. As
result - complete silence.
Please advice, where to dig?
On Wed, 2011-03-02 at 09:53 +0100, Daniel-Constantin Mierla wrote:
On 3/2/11 9:32 AM, Spinov Evgeniy wrote:
Unfortunately ngrep is unavailable right now,
cause network was
configured to use public IPs. May be I'll can do that on development
network later. Right now development network using public`s also.
I'll try to sort out ngrep anyway.
I was giving FAEI to INVITEs from UAC to Asterisk and FAIE to INVITEs
from Asterisks to UAC. Everything was good except destination UDP port
to UAC 1. It was different then the source. As result UAC 1 didn't
received backflow.
You say about wrong port for RTP or for SIP?
For SIP be sure you call force_rport(). For RTP try eventually the flag
'r' in in parameters of force_rtp_proxy().
Also, may be this will help: Kamailio was unable
to identify that faulty
UAC 1 is behind the NAT. I've tried nat_uac_test("31"), however -
nothing, while SIP headers were containing NATed IPs.
By NATed ip you mean private class, like 10... or 192.168...? If yes,
that is strange, can you add debugger module with cfgtrace enabled to
see what lines in the config file are executed for that call? (this is
assuming you are using v3.1.x, if not add xlog() messages in the config
to be sure the nat handling part is executed).
Cheers,
Daniel
So during tests
I've just forced NAT always. Without that I didn't had audio at all.
While with it - one way audio with faulty UAC and normal call for all
others.
Also, on faulty UAC 1 I had to use STUN server, while all other clients
worked without it. After going Asterisks public and changing kamailio
configuration for it, STUN no longer needed anywhere.
Just assuming fact, that router has bad ALG implementation. Is there any
workaround for it, may be forcing destination ports to source ones?
On Wed, 2011-03-02 at 09:30 +0100, Daniel-Constantin Mierla wrote:
Hello,
one option might be a bad ALG implementation in the router.
Can you send a full ngrep of such case? You can obfuscate the IP
addresses, use different ones for each point in the network and leave
the ports. Seeing SIP headers and SDP can indicate the presence of an
ALG or something broken in config logic.
Also, what is the parameter you give to force_rtp_proxy(...)?
Cheers,
Daniel
On 3/2/11 8:38 AM, Spinov Evgeniy wrote:
> May be I miss some important details? No suggestions?
>
> Thank you.
>
>> Hello, all.
>> Using nathelper + rtpproxy for subj. Kamailio has public and private
>> network interfaces. Asterisk is only private. RTP Proxy is working in
>> bridge mode and relaying traffic from UAC to Asterisks.
>> Everything is working fine, except one configuration. When the client is
>> behind router ( a specific one, I do not have an access there to
>> check ), and this UAC is making a call to other public extension, which
>> is behind router, then RTP Proxy is relaying traffic to the caller,
>> using another UDP port, then the packets arrive.
>> For instance:
>> UAC 1 -> UAC 2
>> PUBLIC_IP:10> KAMAILIO_IP:5555
>> KAMAILIO_IP:5678> PUBLIC_IP:12
>> While for the UAC 2 it looks like:
>> PUBLIC_IP:20> KAMAILIO_IP:6767
>> KAMAILIO_IP:4564> PUBLIC_IP:20
>> The source and destination UDP ports are the same. As result, I can hear
>> UAC 1 and he cannot hear me.
>> In case of we have UAC 3, which is behind other router, call is working
>> fine with same configuration.
>> "It's routers fault" you can say, but in the same configuration ( I
mean
>> network, not kamailio ) it worked, but when RTPProxy was not in bridge
>> mode and Kamailio and Asterisks were in public network. Reinvites are
>> not allowed in both cases.
>> The question is, why the source and destination UDP ports are different?
>> Using STUN in first case, cause without it, private IP written in
>> contacts and as result, traffic relayed from Kamailio is incorrect,
>> cause heading to private network which is unreachable.
>> Any ideas where to dig?
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users