> -----Original Message----- > From: Lawrence, Scott (BL60:9D30) > Sent: Monday, April 27, 2009 7:58 PM > To: Joly, Robert (CAR:9D30) > Cc: Pawel Pierscionek; sipx-dev > Subject: Re: [sipX-dev] plugins and SIP transaction > > On Mon, 2009-04-27 at 14:34 -0400, Robert Joly wrote: > > > > > > Hi, > > > > > > With current plugin mechanism one can do a lot of cool > stuff with > > > SIP requests. > > > But can one tap into transaction responses ? > > > > > > I've just finished testing an installation for a > customer of mine > > > that requested Called Number support on his sipXecs + > polycom setup. > > > The quick hack involved adding OpenSIPs to the setup , > modifying > > > SRV records and and injecting RPID headers to > > > 180,183 and 200 while memcaching display names from successful > > > registration requests. > > > But that just seems awful. > > > > > > Any way to utilise current plugin infrastructure to inject > > > headers into 180,183 and 200 responses ? > > > > > > Pawel, > > > > The only way to get at the full set of responses at the application > > layer is to come in as a SipOutputProcessor (grep for it) > which will > > allow an application to see and modify a message before it > goes out on > > the wire. One warning though, this facility is quite > powerful but it > > can also be quite dangerous and you could mess up messages or slow > > down call processing path if you are not careful. Please read the > > comments and proceed with extreme caution. > > One other thing that this made me realize - if the > SipOutputProcessor modifies the message, then the actual > message sent does not match what we log - and the logs are > how we debug. This really scares me.
Logging outgoing SIP messages after SipOutputProcessor hooks was a design consideration when this feature was added. And a result, the logging accurately represents what gets sent. But I can see how one would have that impression from my post on the subject. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
