> -----Original Message----- > From: WORLEY, DALE R (DALE) > Sent: Wednesday, March 31, 2010 1:24 AM > To: Beeton, Carolyn (Carolyn); sipX-dev > Subject: RE: Sending NOTIFY before subscription is accepted > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Beeton, > Carolyn (Carolyn) [[email protected]] > > As of 18224, SipSubscribeServer.cpp is sending a NOTIFY > before a new subscription has been accepted. The code that > used to send the response "ASAP" was moved down below where > NOTIFY is sent. This causes problems for the Polycom sets, > which reject the NOTIFY with 500 Internal Server Error, thus > triggering a bunch of subscription retries which eventually > do succeed, but much later than would have happened if we had > just sent things in the correct order. Can I move this > sending of the response back up to where it was? > ________________________________________ > > The notifier is allowed to send the NOTIFY and the 202 > response to SUBSCRIBE in either order; that's been > established since RFC 3265, and is being reaffirmed in the > new revision to RFC 3265. Indeed, given that the network may > change the order of messages, the subscriber can't tell in > which order the two messages were sent. And so any > subscriber which depends on the order is buggy and needs to > be fixed, or it won't work reliably. > > OTOH, given that Polycoms don't like the new order, it's > probably worth changing the order. I don't think that's a > complicated change. > > The more mysterious question is why does the new code > *eventually* work? If the phone requires the two messages in > a particular order, and the code generates them in the other > order, why does it ever work? > > Dale >
OK. Maybe the problem is somewhere else. Something new is happening that is making SAA subscription reestablishment after a restart take a lot longer than it used to. Still digging through logs to see what it might be. Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
