[Serusers] :-((
Mohammad Khan
info at beeplove.com
Wed Mar 2 21:16:34 CET 2005
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 at beeplove.com> 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