http://www.voip-info.org/wiki-SIP

On 3/2/2005, "Mohammad Khan" info@beeplove.com wrote:

Right, I dont have anything for 'MESSAGE' in my routes. Would you please suggest me, what I should have in my ser.cfg to handle 'MESSAGE'

Also, if possible, would you or anybody tell me: How can I learn more about methods What each methods do and what are their purpose. Any documentation out there without RFC?

Thank AJ, really appreciate your help.

MOhammad

AJ Grinnell wrote:

...

Looks to me that the method is MESSAGE, but you dont have a way to handle MESSAGE in your routes

On Wed, 02 Mar 2005 14:48:44 -0500, Mohammad Khan info@beeplove.com wrote:

...

What is wrong here?

beeplove@projukee.com -> behind NAT outside ser using Kphone mahfuz@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@projuktee.com SIP/2.0 Via: SIP/2.0/TCP 10.51.0.161;branch=z9hG4bK5FEAA78B;alias CSeq: 7658 MESSAGE To: sip:mahfuz@projuktee.com Content-Type: text/plain;charset=UTF-8 From: "Mohammad Khan" sip:beeplove@projuktee.com;tag=5208EA62 Call-ID: 1457236851@10.51.0.161 Content-Length: 9 User-Agent: kphone/4.1.0 Contact: "Mohammad Khan" sip:beeplove@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@projuktee.com;tag=76b43a3b01465a3cbddc081c4176c4c9-3a18 From: "Mohammad Khan" sip:beeplove@projuktee.com;tag=5208EA62 Call-ID: 1457236851@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers