This problem, with rc3, is related to some new NAT logic in chan_sip in rc3. client - nat - internet - nat - openpbx registrations fail with the new logic. See patch on the -dev list for a fix
roy On 18. jan. 2007, at 00.40, Werner Rades wrote: > Hi Marius, > > first, let me honor your bravery to use double NATed environments! ;-) > second, I guss that 192.168.20.4 is your local voice client!? > > I guess you problem comes from the SDP (Session Description Protocol) > used by SIP to set up the RTP communication beween the both endpoints. > Let's have a view on the communication that happens between the peers > for the call setup. > Lets assume the softphone starts the call and sends an INVITE to the > Proxy (PBX). The softphone will use your public IP to send the > INVITE (I > guess you have set your public IP as the Proxy address for the > softphone!?). In the SIP INVITE message there comes a SDP message to > describe the session. It informs the remote end about the media which > the client can support and at which IP address / port combination the > incoming media (incoming for the softphone) has to arrive. No were at > the problem. With the nat=yes switch you tell the pbx software to use > the source address of the IP header of the SIP packet to respond > to. In > the SDP the media port is of course still the internal IP address > of the > softphone. So pbx will send the stream to this port- but with less > success. > > The reason why you can hear the remote end is, because the pbx is > aware > of it's own external IP, so that it can place it instead of the > internal > one into the transmitted SIP and SDP packets - so the remote end is > capable to respont to the correct IP address and you get audio. > > To solve this issue you have more possibilitys: > 1. if you would be a custumer I would suggest to buy a Router (like a > Cisco 87x) that could translate the internal IPs to external IPs as > well > in SIP as in SDP (in my opinion is the second best solution after > globaly introducing IPv6 to solve all NAT issues ;-) ) > 2. you could try to use STUN - I can imagine this could deal well with > your problem, but because of the Ciscos and other application level > gateways for SIP I'm not very experienced with STUN > > At this time there is no spontanous idea about a third way to solve > the > problem... > > Maybe this helps you solving the problem... > > If you found an other solution please let us know! > > Best Regards, > Werner > > -- > Mit freundlichen Grüßen > --------------------------- > Werner Rades > BCA-Services Ltd. > IT-Department > > Dachauer Str. 20 > 80335 München > > eMail: [EMAIL PROTECTED] > > > Marius Flage wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I've been trying to figure out this problem for the last couple of >> days, >> but to no avail. My last resort being you guys. >> >> For my setup I'm using double NAT, that is, my OpenPBX server is >> running >> on my local network on a reserved ip 192.168.20.2. At my home >> router I >> have forwarded 5060/udp and the port range defined by rtp.conf >> (10000-19999/udp). All good. >> >> In sip.conf I've set nat=yes and canreinvite=no globally, so I will >> assume every peer is behind nat, and I want all rtp traffic to go >> through my server. In addition to that I've got >> localnet=192.168.20.0/255.255.255.0 and externhost set to my >> public ip. >> >> At the remote end I've got a NAT-ed setup with local ips in the >> range of >> 192.168.100.0/24. At the peer I'm using X-lite to test my setup. >> >> I can dial just fine, so the sip handshaking works. The problems >> comes >> when trying to send audio. I can receive audio from the remote >> end, but >> the remote end doesn't receive anything. When debugging this by using >> rtp debug, I got the following interesting output: >> >> Got RTP packet from <public address of remote peer>:45722 (type 8, >> seq >> 5620, ts 512440, len 160) >> Sent RTP packet to 192.168.20.4:10000 (type 8, seq 37874, ts >> 512440, len >> 160) >> Got RTP packet from 192.168.20.4:10000 (type 8, seq 3118, ts >> 587920, len >> 160) >> Sent RTP packet to 192.168.100.11:45722 (type 8, seq 3900, ts 587920, >> len 160) >> >> The fourth line being the interesting one and the one breaking >> everything. My server stupidly tries to send RTP data to >> 192.168.100.11 >> (which is the local ip for the remote peer) instead of using the >> public >> ip of the peer. Why does it do that? And what can I do to resolve >> this >> issue once and for all? >> >> Great thanks in advance, >> >> Marius >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.5 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFFreniWJlVZ0GegywRAs+YAJwJcfQpUvLodeb9KzICqOB269z84gCff+MJ >> AQ3scuxSAZJ6U8BoJgCj/6M= >> =kyMp >> -----END PGP SIGNATURE----- > _______________________________________________ > Openpbx-users mailing list > [email protected] > http://lists.openpbx.org/mailman/listinfo/openpbx-users > --- I encrypt all my email with ROT-13 - TWICE! Roy Sigurd Karlsbakk [EMAIL PROTECTED] _______________________________________________ Openpbx-users mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-users
