[Serusers] :-((
Steve Blair
blairs at isc.upenn.edu
Wed Mar 2 21:17:59 CET 2005
Mohammad:
I don't do NAT with my SER implementation so I cannot help with that.
In my opinion
I'd start with a little "simpler" configuration if I were you. Can you
get a working
configuration with one user on the "protected" side of the NAT box and
one on the
"public" side? Also look for articles about using Windows Messenger.
There are a
set of articles discussing the interoperability issues that may be helpful.
-Steve
Mohammad Khan wrote:
> What is wrong here?
>
> beeplove at projukee.com -> behind NAT outside ser using Kphone
> mahfuz at projuktee.com -> behind another NAT outside ser using Windows
> Messenger
>
> Could anybody show me where I am doing wrong?
>
>
> SipClient: Sending: 14:39:54.899
> --------------------------------
> MESSAGE sip:mahfuz at projuktee.com SIP/2.0
> Via: SIP/2.0/TCP 10.51.0.161;branch=z9hG4bK5FEAA78B;alias
> CSeq: 7658 MESSAGE
> To: <sip:mahfuz at projuktee.com>
> Content-Type: text/plain;charset=UTF-8
> From: "Mohammad Khan" <sip:beeplove at projuktee.com>;tag=5208EA62
> Call-ID: 1457236851 at 10.51.0.161
> Content-Length: 9
> User-Agent: kphone/4.1.0
> Contact: "Mohammad Khan" <sip:beeplove at 10.51.0.161;transport=tcp>
>
> helloooo
>
> SipClient: Sending to 'sip.projuktee.com:5060' (TCP)
> SipClient: Receiving message...
>
> SipClient: Received: 14:40:05.024
> ---------------------------------
> SIP/2.0 477 Unfortunately error on sending to next hop occurred (477/TM)
> Via: SIP/2.0/TCP
> 10.51.0.161;branch=z9hG4bK5FEAA78B;alias;rport=38973;received=66.105.xxx.yyy
>
> CSeq: 7658 MESSAGE
> To: <sip:mahfuz at projuktee.com>;tag=76b43a3b01465a3cbddc081c4176c4c9-3a18
> From: "Mohammad Khan" <sip:beeplove at projuktee.com>;tag=5208EA62
> Call-ID: 1457236851 at 10.51.0.161
> Server: Sip EXpress router (0.9.0 (i386/linux))
> Content-Length: 0
> Warning: 392 192.168.71.2:5060 "Noisy feedback tells: pid=9204
> req_src_ip=66.105.xxx.yyy req_src_port=38973
> in_uri=sip:mahfuz at projuktee.com
> out_uri=sip:192.168.1.54:10745;transport=tcp via_cnt==1"
>
>
>
> ser.cfg
> if (nat_uac_test("3")) {
> # Allow RR-ed requests, as these may indicate that
> # a NAT-enabled proxy takes care of it; unless it is
> # a REGISTER
> if (method == "REGISTER" || ! search("^Record-Route:")) {
> xlog("L_DBG", "LOG: Someone trying to register
> from private IP, rewriting\n");
> # This will work only for user agents that
> support symmetric
> # communication. We tested quite many ofhem and
> majority is
> # smart enough to be symmetric. In some phones
> it takes a configuration
> # option. With Cisco 7960, it is called
> NAT_Enable=Yes, with kphone it is
> # called "symmetric media" and "symmetric
> signalling".
> fix_nated_contact(); # Rewrite contact with
> source IP of signalling
> if (method == "INVITE" || method == 'NOTIFY') {
> fix_nated_sdp("1"); # Add
> direction=active to SDP
> };
> force_rport(); # Add rport parameter to topmost
> Via
> setflag(6); # Mark as NATed
> };
> };
>
>
>
>
> # if the request is for other domain use UsrLoc
> # (in case, it does not work, use the following command
> # with proper names and addresses in it)
> if (uri=~"projuktee.com") {
>
>
> if (method=="REGISTER") {
>
>
> if (!www_authorize("projuktee.com",
> "subscriber")) {
> www_challenge("projuktee.com", "1");
> break;
> };
>
>
> save("location");
> break;
> };
>
>
> if (method=="PUBLISH") {
> if (!t_newtran()) {
> xlog("L_DBG", "newtran error\n");
> sl_reply_error();
> };
> handle_publish("registrar");
> break;
> };
>
>
> lookup("aliases");
> if (!uri=~"projuktee.com") {
> append_hf("P-hint: outbound alias\r\n");
> route(1);
> break;
> };
>
>
>
>
> # native SIP destinations are handled using our USRLOC DB
> if (!lookup("location")) {
> sl_send_reply("404", "Not Found");
> break;
> };
> };
> append_hf("P-hint: usrloc applied\r\n");
> route(1);
> }
>
>
> route[1]
> {
>
>
> # !! Nathelper
> #if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"
> && !search("^Route:")){
> # sl_send_reply("479", "We don't forward to private IP >
> >addresses");
> # break;
> #};
>
>
> # if client or server know to be behind a NAT, enable relay
> if (isflagset(6)) {
> force_rtp_proxy();
> };
>
>
> ##################
> # NAT processing of replies; apply to all transactions (for
> example,
> # re-INVITEs from public to private UA are hard to identify as
> # NATed at the moment of request processing); look at replies
> #t_on_reply("1");
>
>
> if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
> fix_nated_contact();
> force_rtp_proxy();
> # otherwise, is it a transaction behind a NAT and we
> did not
> # know at time of request processing ? (RFC1918 contacts)
> } else if (nat_uac_test("1")) {
> fix_nated_contact();
> };
> ################
>
>
> # send it out now; use stateful forwarding as it works reliably
> # even for UDP2TCP
> if (!t_relay()) {
> sl_reply_error();
> };
> }
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list