I was having the same issue last night on a valip public ip.
BTW, I am using CVS HEAD version that I downloaded 1 or 2 weeks back.
Thanks
-----Original Message-----
From: listbot.br(a)gmail.com
Sent: Thu, 23 Jun 2005 15:45:45 -0300
To: chiahuey(a)genme.com, jcastro(a)instant.com.br, serusers(a)iptel.org
Subject: Re: [Serusers] SER losing SIP registrations
Jan,
We experience the same problems over here with some of our clients, only
here
some of them are actually on valid IPs (no NAT). Any ideas?
Thnx,
Fernando
On Thursday 23 June 2005 08:44, 'Jan Janak' wrote:
OK, the REGISTER message contains a private IP in
the contact. That
would force SER to rewrite the IP address with the public IP of the NAT
and the user agent is probably unable to match the contact and find out
what the expires value set by the server is. That explains why it works
with Expires: 60 header field parameter but does not work with
;expires=60 contact parameter.
There are two options:
1) Hack -- insert Expires: 50 header field into the reply using
append_to_reply function from textopts module. Note that the value
you
insert this way must be lower than the value
of expires parameter in
the
contact.
2) Use fix_nated_register instead of fix_nated_contact for REGISTER
messages. This function does not rewrite the IP in contact, instead
it would append the public IP and port used by the NAT as a
parameter
of Contact header field. The two values will
be stored separately in
the user location database. When forwarding a message to the
contact,
the Request-URI will contain the private IP of
the user agent, but
the message will be sent to the public IP of the NAT (destination
set
will be used). This way the Contact in 200 OK
reply will be not
modified and the user agent should be able to set the expires value
properly.
Jan.
On 23-06-2005 17:59, Chia Huey Lim wrote:
> Sure...
>
> SER:
> REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bKd9e688a70
> Max-Forwards: 70
> Content-Length: 0
> To: 5008 <sip:18182002@xxx.xxx.xxx.xxx>
> From: 5008 <sip:18182002@xxx.xxx.xxx.xxx>;tag=1f55b6cd5586c2d
> Call-ID: 928d75b5b6c7d128a0ccaf24e5b52c74(a)192.168.0.4
> CSeq: 1028949335 REGISTER
> Contact: 5008 <sip:18182002@192.168.0.4:5060;user=phone>;expires=60
> Allow: NOTIFY
> Allow: REFER
> Allow: OPTIONS
> Allow: INVITE
> Allow: ACK
> Allow: CANCEL
> Allow: BYE
> User-Agent: InterEdge-ieta200
>
> ASTERISK:
> REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.4;branch=z9hG4bKf91124aeb
> Max-Forwards: 70
> Content-Length: 0
> To: 603200661 <sip:603200661@xxx.xxx.xxx.xxx>
> From: 603200661 <sip:603200661@xxx.xxx.xxx.xxx>;tag=7f4a78971dd573b
> Call-ID: 59a4ee90d5fbe74f8de459fb2506acf0(a)192.168.0.4
> CSeq: 937060361 REGISTER
> Contact: 603200661
<sip:603200661@192.168.0.4;user=phone>;expires=1200
> Allow: NOTIFY
> Allow: REFER
> Allow: OPTIONS
> Allow: INVITE
> Allow: ACK
> Allow: CANCEL
> Allow: BYE
> Authorization:Digest
>
response="869ebcdfd4f83cfd805c0b03e768b9a5",username="603200661",realm="x
>xx"
,nonce="297966ac",uri="sip:xxx.xxx.xxx.xxx"
> User-Agent: InterEdge-ieta200
>
> Regards,
> Chia
>
>
> -----Original Message-----
> From: 'Jan Janak' [mailto:jan@iptel.org]
> Sent: Thursday, June 23, 2005 5:44 PM
> To: Chia Huey Lim
> Cc: 'Juan Carlos Castro y Castro'; serusers(a)iptel.org
> Subject: Re: [Serusers] SER losing SIP registrations
>
> Could send me also the REGISTER messages ?
>
> Jan.
>
> On 23-06-2005 17:36, Chia Huey Lim wrote:
> > I am facing the same problem too, one of the UA that I am testing
on
> > does not re-register itself. It has no
problem re-registering
itself to
>
> asterisk.
>
> > I compared the ethereal trace for the registration on SER and
Asterisk.
>
> And
>
> > I found that Asterisk append "Expires: xxx" above the "Contact:
"
while
>
> SER
>
> > does not. Anything that I can do to append "Expires: xxx" in the
200 ok
> > packet that SER is sending out?
> >
> > Below is the comparison:
> >
> > SER:
> > ?Ä?¸e`SIP/2.0 200 OK
> > Via: SIP/2.0/UDP
>
>
192.168.0.4:5060;branch=z9hG4bKef17e9623;rport=32914;received=xxx.xxx.xxx
>.xx
>
> > x
> > To: 5008
> >
<sip:18182002@xxx.xxx.xxx.xxx>;tag=856642a4d7f9f16db9502202a011388b.db9
> >a From: 5008
<sip:18182002@xxx.xxx.xxx.xxx>;tag=1f55b6cd5586c2d
> > Call-ID: 928d75b5b6c7d128a0ccaf24e5b52c74(a)192.168.0.4
> > CSeq: 1028949336 REGISTER
>
>
Contact:<sip:18182002@xxx.xxx.xxx.xxx:32914;user=phone>;expires=60;receiv
>ed=
>
> > "sip:xxx.xxx.xxx.xxx:32914"
> > Server: Sip EXpress router (0.9.0 (i386/linux))
> > Content-Length: 0
> >
> > ASTERISK:
> > Ä?Ä?
> > x9SIP/2.0 200 OK
> > Via: SIP/2.0/UDP
> >
192.168.0.4;branch=z9hG4bKf91124aeb;received=xxx.xxx.xxx.xxx;rport=3291
> >4 From: 603200661
<sip:603200661@xxx.xxx.xxx.xxx>;tag=7f4a78971dd573b
> > To: 603200661
<sip:603200661@xxx.xxx.xxxx.xxx>;tag=as4f0c60fe
> > Call-ID: 59a4ee90d5fbe74f8de459fb2506acf0(a)xxx.xxx.xxx.xxx
> > CSeq: 937060361 REGISTER
> > User-Agent: xxx
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
> > Expires: 1200
> > Contact: <sip:603200661@xxx.xxx.xxx.xxx;user=phone>;expires=1200
> > Date: Wed, 22 Jun 2005 04:36:20 GMT
> > Content-Length: 0
> >
> > Thanks.
> >
> > Regards,
> > Chia
> >
> >
> > -----Original Message-----
> > From: serusers-bounces(a)iptel.org
[mailto:serusers-bounces@iptel.org] On
> > Behalf Of Jan Janak
> > Sent: Thursday, June 23, 2005 4:39 PM
> > To: Juan Carlos Castro y Castro
> > Cc: serusers(a)iptel.org
> > Subject: Re: [Serusers] SER losing SIP registrations
> >
> > On 22-06-2005 17:57, Juan Carlos Castro y Castro wrote:
> > > Our company has a call center implementation on a client with up
to
> > > 100 support personnel using X-Lite
version 1050 softphones
running
> > > under Windows 98. Until a few days
ago, the softphones were
logged in
> > > directly on our PBXs. Now, they
log onto a separate SER 0.8.14
box
> > > and the PBXs forward calls to SER.
That was needed to unify queue
> > > management.
> > >
> > > It works. But some softphones are being randomly kicked out of
SER,
> > > it seems SER isn't receiving
the refresh REGISTER messages from
the
> > > softphones. The re-register
timeout is set to 500 seconds on the
> > > softphones. There's a lot of "removing spare zombie" and
"Binding
> > > '<user>','<url>' has expired" messages in
/var/log/messages.
> >
> > The message means that SER did not receive REGISTER re-fresh and
is
> > thus removing the contact from the
user location database.
> >
> > Pick one user agent that has this problem and install ngrep
monitor
> > on the server to monitor all REGISTER
messages from that user
agent.
> > This way you could find out if the
problem is in the user agent or
> > network (in this case you will not see REGISTER refresh messages on
the
> > server) or in SER (in that case you
will see them but SER probably
> > fails to process them).
> >
> > Also make sure that SER is not configured to shorten the
registration
> > period. When registrar receives a
REGISTER message, it is free to
use
> > shorter expires value for the Contac
than what was suggested by
the
> > user agent in the request. In this
case the real expires value of
the
> > contact will be in 200 OK and user
agents are suppose to pick it
up
> > from there and update the refresh
interval accordingly. This may
not
> > work in the case when Contact IP
address is rewritten by the
server
> > for the purpose of NAT traversal. In
this case the user agent
will be
> > unable to find its contact (because
it has been rewritten) and
will
> > not update the refresh interval
(resulting in expired
registrations).
> >
> > > For now, we're instructing the client to increase the timeout to
10
> > > hours on the softphones in which
the problem happens most often.
I
> > > don't know if that's
really the right thing to do, I think we
should
> > > somehow make sure the re-registers
are done in a timely fashion
and
> > > retried, but I could not find ant
SER configuration option
related to
> > > that. What should I do?
> >
> > You can configure the maximum allowed expires value in SER, if a
user
> > agent tries to REGISTER a contact
with longer expires value than
it
> > will be automatically updated by
registrar to the value of
> > max_expires parameter.
> >
> > There is also min_expires parameter in registrar module but that
one
>
should not be used because the current implementation violates
> RFC3261.
>
> If you are using any of the two parameter than it might be a good
> idea to retry without them (to see if the problem persists).
>
> Jan.
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://lists.iptel.org/mailman/listinfo/serusers