Thank you Michal, I added fix_rport() in the INIT block, and it fixed the problem of storing messages as offline. Thanks!! And yes, I also noticed there's no maddr in the messages, I will try to recompile SER.
Kumar
On 6/9/07, Michal Matyska michal@iptel.org wrote:
Hi Kumar,
I have finally some time to look at the traces.
1)user ligaj - you wrote not behind NAT check packet #1: Internet Protocol, Src: 192.168.2.5, Dst: 192.168.2.2 User Datagram Protocol, Src Port: 1078 (1078), Dst Port: sip (5060) Via: SIP/2.0/UDP 192.168.2.5:15538
Port translation done somewhere or broken client.
- no problem with user kumar - behind NAT - OK
packet #5 Internet Protocol, Src: 192.168.2.4, Dst: 192.168.2.2 User Datagram Protocol, Src Port: 1469 (1469), Dst Port: sip (5060) Via: SIP/2.0/UDP 192.168.80.129:14926 Contact: sip:192.168.80.129:14926;methods="..."
- clients seem to work on the address presented in Contact -
see OPTIONS and 200 OK packets #28-#31
- INVITE from Ligaj to Kumar
starting packet #9 start is correct, then UAS replies with 488 (really hard to guess why) and reply proxied back. Reply received at UAC, acknowledged by ACK BUT the UAC retransmitts the INVITE for next 30 seconds. Eventhough it has CSeq 2, it does not contain the Proxy-Authorization header, so SER replies with 407....
- INVITE from Avalanche to Ligaj packets #43-#53
session x-ms-message estabillished
well typicall MS way
- MESSAGE from Avalanche to Ligaj
the client uses STRICT routing (RFC2543) which does SER is able to handle, but is becoming obsoleted especially in 3g networks.
Note that the MESSAGE goes INSIDE of the INVITE dialog (has to tag).
You should add force_rport() somewhere at beginning of your ser script, the request came from different ip:port than is listed in Via header, the ip was catched into the received parameter, but rport has not, so the 200 OK reply is sent to wrong port, thus you see the ICMP port unreachable.
Michal
P.S. I don't see sny maddr in the messages....
On Pá, 2007-06-08 at 10:27 +0545, KUMAR wrote:
Michal, It did not work. The MESSAGE sent from the UA behind NAT is being stored as offline messages, and sent a while later, even though the other user is online. I did not have this problem with the old SER. With the old SER, the only problem that I was having was that MESSAGE did not work with TCP, but with UDP, it worked. I have also tried to make changes to the registry as mentioned in the list. But that too did not work. I'm including the packet capture at the server.
The user kumar is behind NAT. While the user ligaj is outside NAT.
I am using VMWare to simulate user behind NAT, could that cause problems ?? I am having no problems at all with Xlite. Thanks kumar
On 6/7/07, Michal Matyska michal@iptel.org wrote:
Hi,
yes you did it correctly. In the time I prepared the option, I did not put it into the flags, as you then have to recompile all the modules (they are used to match the core-module version).... but anyway if you compile core, you can compile the modules too... so I'll put it there.
Did it help?
I don't have any obvious clue for the log message no UAC support.
Michal
On Ne, 2007-06-03 at 11:58 +0545, KUMAR wrote:
Thanks Michal, I tried to recompile SER with HONOR_MADDR. Can you please tell me how do I do it. I changed the Makefile.defs to include -DHONOR_MADDR, and compiled, but I'm not sure if the option is actually included. Here's what i get when I do a ser -V version: ser 2.0.0-rc1 (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_DST_BLACKLIST ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. @(#) $Id: main.c,v 1.228.2.2 2007/03/01 13:53:37 andrei Exp $
As you can see, there's no HONOR_MADDR, though it showed up while compiling. I have attached the Makefile.defs that I've used. Do I need to do something else to compile with this option? Also, what I failed to mention last time is that when I log on using M$ client, I get the message
Warning: run_failure_handlers: no UAC support (0, 0)
Can you please tell me what is this supposed to mean? Thank you Kumar
On 5/31/07, Michal Matyska michal@iptel.org wrote:
Hi,
the M$ messenger is know to misuse maddr parameter in the uri. You can check your message if it does contain maddr and then try compile ser with HONOR_MADDR option. It should work; if not attach network capture of the sip traffic.
Michal
On Čt, 2007-05-31 at 11:32 +0545, KUMAR wrote:
hi all, I've started using SER 2.0 rc1 and am having a bit of problems with UA behind NAT. I'm using Windows Messenger 5.1 as the UA. Everything works fine when both UAs are not behind NAT. But when I place one of the UAs behind NAT, then, here's what happens, in this order
UA Behind Nat ----------MESSAGE------>UA outside NAT..............ok UA outside NAT-----------MESSAGE------->UA behind NAT.............OK UA behind NAT------------MESSAGE------->UA outside NAT.............message is stored by msilo module and sent after some time.
The log shows: MSILO: the downstream UA doesn't support MESSAGEs
Notice that this only happens once a message from outside of NAT is sent to UA inside NAT. I am using RTP Proxy for NAT solution which is on the same system as SER. Moreover, I also cannot signout using the Windows Messenger.
However, when I tested using XLite, None of the above mentioned problems arose. Can anyone please suggest me as to where the problem might be.
The ser.cfg that I'm using is the one from the iptel site, the one with NAT & RTPproxy. I am also attaching the ser.cfg. Thank you in advance. Kumar _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers