Hi Paul, Paul Fremantle wrote: > Hehe This is cool. I didn't realize there was any SIP support in HTTPCore.
You didn't read the release notes for alpha6? I am *shocked*! ;-) http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt > I'd much rather use this than a servlet model because of the > non-blocking nature. > > I'll take a look over the holidays and maybe start in earnest in the new year. I've added some contrib code [1] that should save you some work, in particular the definition of the status codes and default reason phrases. Now it pays out that we have a dedicated reason phrase catalog. There are some funny little details about SIP (RFC 3261 and others) that you should keep in mind. SIP does explicitly NOT allow for chunked encoding. All entities must have a Content-Length. I think that even for messages without an entity, a Content-Length of 0 should/must be specified. I didn't check the defined methods though, maybe all of them allow for an entity. One approach to enforce this would be dedicated BasicSipRequest/Response classes that throw an exception if a chunked entity or one with unknown length is added. But we might still need additional checks for sending messages without an entity, or when the HTTP message implementations are used for sending. There is no expect-continue handshake. That can be disabled on the client side by setting the respective parameter. The server can trigger an error in the ExpectationVerifier. Some headers have a "compact form" using a single character as the name. Compact form and full form are equivalent and may be mixed in the same message. On the receiving side, this may be handled by a protocol interceptor that looks for compact forms and adds the respective full form header and/or vice versa. But keeping the headers in the correct order may become a problem. Maybe it's better/easier to modify the message parser and instantiate special SipHeader objects that know both forms of their header name. That would also help to re-use code that currently depends on the full name, like the content length strategies which check for the "Content-Length:" header but not the compact form "l:". On the sending side, I would delegate the responsibility to the application for starters. When digging into details, it may be necessary to switch between full and compact forms for example in the message formatter. Then it becomes interesting when and where the Content-Length header is set, and whether it is possible to create a SipHeader there. I can't promise that I'll soon find time and motivation to dig much further into this stuff. It's a can of worms. cheers, Roland [1] http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/contrib/src/main/java/org/apache/http/contrib/sip/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
