[Serusers] :-((
Iqbal
iqbal at gigo.co.uk
Wed Mar 2 21:20:50 CET 2005
http://www.voip-info.org/wiki-SIP
On 3/2/2005, "Mohammad Khan" <info at 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 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
>>>
>>>
>>>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
More information about the sr-users
mailing list