On Thu, 2006-11-09 at 08:17 +0100, Andrzej Ciarkowski wrote: > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:sipxtapi-dev- > > [EMAIL PROTECTED] On Behalf Of Charlie Hedlin > > Sent: Thursday, November 09, 2006 5:28 AM > > To: [email protected] > > Subject: [sipxtapi-dev] Register reponse not handled properly if no expire > set. > > > > I have been using the sipXtapi-branch head revision (as of an hour ago > > at least) to register against a SER installation. A protocol analyzer > > shows SER is not setting an expire in the register response even though > > it is returning 200 OK. X-Lite handles this and still reports that it > > is registered, but sipXtapi-branch fails to fire the event. It apears > > that the code was meant to. > > > > The problem is in SipRefreshMgr::processOkRepsponse. On line 993. On > > LIne 1012 it calls rescheduleAfterTime, which never fires the event. > > Hello, I was debugging similar problem and AFAIR I found out that it appends > expires= parameter to Contact header field on returned response. The problem > is, that returned Contact header sometimes differs from the sent one in case > of NATs - request Contact has "public" IP obtained via STUN and response > > has "private" IP, what is somewhat strange still. In such case sipX seems > to silently ignore the Contact header and consequently its "expires" > parameter.
Which would be correct - the REGISTER response is supposed to contain _all_ contacts for the AOR, including those registered by others, but you should only be trying to refresh your own. OpenSER really should be returning the Contact as it was received, but remembering internally that it must be mapped before being used. There is no way that the UA can sort this out on its own. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:[EMAIL PROTECTED] sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
