2 Mar
2005
2 Mar
'05
10:16 p.m.
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(a)beeplove.com> wrote:
>What is wrong here?
>
>beeplove(a)projukee.com -> behind NAT outside ser using Kphone
>mahfuz(a)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(a)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(a)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(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>