Thank you. I will try it asap, and let you know.

Thanks, ilker

-----Original Message----- From: Ladislav Andel [mailto:ladaan@iptel.org] Sent: Sunday, April 15, 2007 10:04 PM To: İlker Aktuna (Koç.net) Cc: serusers@iptel.org Subject: Re: [Serusers] interesting 2 way SIP signalling problem

Hi, Ok, I know now that you are using version SER 2.1 :). (the CVS version) I have changed the ser config file which can be used with mediaproxy. Please try it out since I don't use mediaproxy.. The change is not that much different from using RTP proxy. You can find it here http://www.iptel.org/ser/howtos/optimizing_the_use_of_rtp_proxy File is called <ser_config_2_0_mediaproxy.txt> Or directly from http://www.iptel.org/files/ser_config_2_0_mediaproxy.txt

I will move it later to its section if it will be working for you.

Regarding nat_flag in SER 2.0 and 2.1. There are used 2 nat flags . save_nat_flag and load_nat_flag.

This way it is in modparam section.

modparam("registrar", "save_nat_flag", "FLAG_NAT_UAC") modparam("registrar", "load_nat_flag", "FLAG_NAT_UAS")

As an example look at the config file mentioned above.

Let me know if it is working.. I'll help you to start up SER with this config if you find any problems. It should work though.

Lada

İlker Aktuna (Koç.net) wrote:

Hi,

I tried adding force_rport() for INVITEs. But that didn't solve the problem. Then I checked the "getting started ser configs" from the ftp URL you sent.

This one should be fine: ftp://siprouter.onsip.org/pub/gettingstarted/configs/nat-mediaproxy.cf g

However, this config includes the following line:

modparam("registrar", "nat_flag", 6)

But my new compiled ser installation (and its registrar module) does not accept this parameter. Which source/build would have this parameter ?

If this parameter is not important I can ignore it...

Please show me a way.

Thanks, ilker

-----Original Message----- From: Ladislav Andel [mailto:ladaan@iptel.org] Sent: Tuesday, April 10, 2007 7:13 PM To: İlker Aktuna (Koç.net); 'serusers@iptel.org' Subject: Re: [Serusers] interesting 2 way SIP signalling problem

Hi, Looks like you are mixing together nathelper and mediaproxy module. You need to call force_rport() even for INVITEs. Look at Getting started ser configs ftp://siprouter.onsip.org/pub/gettingstarted/configs/

Lada

İlker Aktuna (Koç.net) wrote:

...

Hi,

Did you receive my reply yesterday ?

Thanks, ilker

-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of İlker Aktuna (Koç.net) Sent: Monday, April 09, 2007 11:29 AM To: Ladislav Andel Cc: serusers@iptel.org Subject: RE: [Serusers] interesting 2 way SIP signalling problem

Hi,

This is under my method=="REGISTER" section:

    if (nat_uac_test("1")) {
            setflag(6);
            fix_nated_contact();
            force_rport();
    };

I also have this under method=="INVITE" :

if (method=="INVITE" || method=="ACK") {

                    if (client_nat_test("19")) {
                            fix_nated_contact();
                    };

And this one under a onreply route :

onreply_route[2] { if (status=~"(183)|(2[0-9][0-9])") { use_media_proxy();

    if (nat_uac_test("19")) {
            fix_nated_contact();
    };
  }
};

Thanks for your reply...

ilker

-----Original Message----- From: Ladislav Andel [mailto:ladaan@iptel.org] Sent: Monday, April 09, 2007 11:31 AM To: İlker Aktuna (Koç.net) Cc: serusers@iptel.org Subject: Re: [Serusers] interesting 2 way SIP signalling problem

Hi,

do you call force_rport() function for NATed clients? Can you paste in the NAT section of your ser.cfg here? Paste in NAT detecting section too.

Lada

İlker Aktuna (Koç.net) wrote:

...

Hi,

I have a working configuration on my SER server. Most of the users can make calls (both way incoming and outgoing) with no problem. However, I have some clients that can't make calls. When I analyze these by ngrep and/or tcpdump, I see that the SER server does not reply the packet on the correct port.

For example, I have a testing client which is behind NAT. The client sends INVITE message from UDP port 3023 to port 5061 of my SER. (cseq number is 1) SER exchanges the message with the uplink sip gateway and when it receives a "OK" response it forwards this message to the client's NAT IP address BUT on a different port (14640) with correct cseq number (1)

Of course, this new port is not open on the NAT router and it does not reach the client.

I see that the first INVITE message has Contact field with internal IP address of the client and the port number as 14640. So the SER server sends the returning message to the external IP address with internal port number.

How can I fix this issue ?

I can send the configuration of my SER server if that would help to find the problem.

---

---

_ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. ______________________________________________________________________ ______________________________________________________________________ _