[Serusers] SER losing SIP registrations

Thu Jun 23 11:59:29 CEST 2005

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 at xxx.xxx.xxx.xxx>
From: 5008 <sip:18182002 at xxx.xxx.xxx.xxx>;tag=1f55b6cd5586c2d
Call-ID: 928d75b5b6c7d128a0ccaf24e5b52c74 at 192.168.0.4
CSeq: 1028949335 REGISTER
Contact: 5008 <sip:18182002 at 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 at xxx.xxx.xxx.xxx>
From: 603200661 <sip:603200661 at xxx.xxx.xxx.xxx>;tag=7f4a78971dd573b
Call-ID: 59a4ee90d5fbe74f8de459fb2506acf0 at 192.168.0.4
CSeq: 937060361 REGISTER
Contact: 603200661 <sip:603200661 at 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="xxx"
,nonce="297966ac",uri="sip:xxx.xxx.xxx.xxx"
User-Agent: InterEdge-ieta200

Regards,
Chia

-----Original Message-----
From: 'Jan Janak' [mailto:jan at iptel.org] 
Sent: Thursday, June 23, 2005 5:44 PM
To: Chia Huey Lim
Cc: 'Juan Carlos Castro y Castro'; serusers at lists.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 at xxx.xxx.xxx.xxx>;tag=856642a4d7f9f16db9502202a011388b.db9a
> From: 5008 <sip:18182002 at xxx.xxx.xxx.xxx>;tag=1f55b6cd5586c2d
> Call-ID: 928d75b5b6c7d128a0ccaf24e5b52c74 at 192.168.0.4
> CSeq: 1028949336 REGISTER
>
Contact:<sip:18182002 at xxx.xxx.xxx.xxx:32914;user=phone>;expires=60;received=
> "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=32914
> From: 603200661 <sip:603200661 at xxx.xxx.xxx.xxx>;tag=7f4a78971dd573b
> To: 603200661 <sip:603200661 at xxx.xxx.xxxx.xxx>;tag=as4f0c60fe
> Call-ID: 59a4ee90d5fbe74f8de459fb2506acf0 at xxx.xxx.xxx.xxx
> CSeq: 937060361 REGISTER
> User-Agent: xxx
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
> Expires: 1200
> Contact: <sip:603200661 at 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 at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> Behalf Of Jan Janak
> Sent: Thursday, June 23, 2005 4:39 PM
> To: Juan Carlos Castro y Castro
> Cc: serusers at lists.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.
> 