[Serusers] Sample SER + Asterisk conf?

[Bart J. Smit]

I can make calls from a public UA registered with SER to an internal UA
registered with Asterisk. The problem is the call tear-down; when I hang
up from the public side, the call is torn down properly but when I hang
up from the private side, the public UA never gets the BYE packet.

When I capture the sip packets from the public UA I get this:

192.168.20.242 -> 65.126.236.148 SIP/SD Request: INVITE
sip:0509 at pbx.nexusmgmt.com, with session description
65.126.236.148 -> 192.168.20.242 SIP Request: OPTIONS
sip:nexphone.nexusmgmt.com
65.126.236.148 -> 192.168.20.242 SIP Status: 100 trying -- your call is
important to us
65.126.236.148 -> 192.168.20.242 SIP Status: 404 User Not Found
65.126.236.148 -> 192.168.20.242 SIP 180 Ringing
65.126.236.148 -> 192.168.20.242 SIP/SD Status: 200 OK, with session
description
192.168.20.242 -> 65.126.236.148 SIP Request: ACK
sip:65.126.236.148;r2=on

When I hang up from the outside I get:
192.168.20.242 -> 65.126.236.148 SIP Request: BYE :65.126.236.148;r2=on
65.126.236.148 -> 192.168.20.242 SIP Status: 200 OK

I am most worried about the 404 packet; my guess is that it is where the
session breaks. It has these headers:
From: <sip:admin at nexphone.nexusmgmt.com>
To:	<sip:nexphone.nexusmgmt.com>

Warning: 392 65.126.236.148:5060 "Noisy feedback tells: pid=23798
req_src_ip=80.176.149.91 req_src_port=5060
in_uri=sip:nexphone.nexusmgmt.com out_uri=sip:nexphone.nexusmgmt.com
via_cnt==1"

I can't work out why the public UA should send a packet to
sip:nexphone.nexusmgmt.com instead of sip:0509 at pbx.nexusmgmt.com.

I attach my config files and the SIP packets from the network sniffer.

Thanks,

Bart...

-----Original Message-----
From: Brett N [mailto:brettlist at nemeroff.com] 
Sent: 14 March 2006 16:03
To: Vitaly Nikolaev
Cc: Bart J. Smit; serusers at lists.iptel.org
Subject: RE: [Serusers] Sample SER + Asterisk conf?

That really shouldn't be necessary. Make sure the approproate domains or
IPs are listed as "aliases" in ser.cfg.

What is the problem you are having? Perhaps if you tell us what is
wrong,
we can help fix it?


On Tue, March 14, 2006 9:03 am, Vitaly Nikolaev wrote:
> I had a problem long time ago with 0.8.14m that ser and asterisk (or
any
> b2bua) can not work on same IP address on different ports, somewhere
in
> the logic of ser it mistakes in "if myself" function, and since then I
> always have them on same server but different IP addresses....
>
> You might try it
>
>
> -----Original Message-----
> From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org]
On
> Behalf Of Bart J. Smit
> Sent: Tuesday, March 14, 2006 9:59 AM
> To: serusers at lists.iptel.org
> Subject: [Serusers] Sample SER + Asterisk conf?
>
> I'm still having problems with ser and asterisk on the same public
> server.
>
> Could anybody send me a tarball of their ser.cfg and sip.conf
off-list,
> so I can do a sanity check against my files?
>
> Much appreciated.
>
> Bart...
>
> _______________________________________________
> 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
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: BYE 404 SIP packets
Type: application/octet-stream
Size: 5791 bytes
Desc: BYE 404 SIP packets
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060314/11c310c0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ser.cfg
Type: application/octet-stream
Size: 4013 bytes
Desc: ser.cfg
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060314/11c310c0/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip.conf
Type: application/octet-stream
Size: 19857 bytes
Desc: sip.conf
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060314/11c310c0/attachment-0002.obj>