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.
2) 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="..."
3) clients seem to work on the address presented in Contact -
see OPTIONS and 200 OK packets #28-#31
4) 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....
5) INVITE from Avalanche to Ligaj packets #43-#53
session x-ms-message estabillished
well typicall MS way
6) 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(a)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(a)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(a)lists.iptel.org
> > > >
http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > >
> > _______________________________________________
> > Serusers mailing list
> > Serusers(a)lists.iptel.org
> >
http://lists.iptel.org/mailman/listinfo/serusers
>
>