[Serusers] :-((
Mohammad Khan
info at beeplove.com
Wed Mar 2 21:51:44 CET 2005
Whenever two UAs are from two different netwok ... communication fails.
inside my network, two UA can communicate.
outside my network but withing same network two UA can communicate.
BTW, is this right way to run rtpproxy on an internet facing computer.
rtpproxy -s udp:192.168.71.1:22222 -l 66.92.xx.yyy
modparam("nathelper", "rtpproxy_sock", "udp:192.168.71.1:22222")
Thanks for replying me.
MOhammad
Steve Blair wrote:
>
> 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