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?
On RTP only. SIP works fine, except STUN server requirement as I've
mentioned below.
>
> For SIP be sure you call force_rport(). For RTP try eventually the flag
> 'r' in in parameters of force_rtp_proxy().
According to README, r flag affects IP addresses, so it will not solve
RTP issue, but I'll try it to get rid of STUN server requirement, hope
this will help.
>
> > 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...?
Yea, in my case this is 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).
This is Kamailio 3.0.4. I've added xlogs and seen that messages are
proceeded on SIP sessions ( ones for INVITE from UAC1 and once for
INVITE from Asterisk to UAC2 ) and for RTP, once for each session. RTP
Proxy is proxing all 4 flows ( 2 per each side ). May be I should take a
look at something else?
>
> 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@lists.sip-router.org
> >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
