| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Comment inline
On Aug 8, 2006, at 2:10 PM, Jason Fischl wrote:On 8/8/06, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:You have missed my point; sometimes the TU can't send a failure response because the request is too garbled, and there is no other interface for terminating transactions. There is nothing the TU can do in this situation.If the request was too garbled to generate a response, how was it ableto make it through the SipStack? It should be possible to construct a failure response to any SipMessage that makes it to the TU. We may need to make the Helper method that generates a failure response more robust but I think that should be all that is required. Can you provide some more concrete issues that exist in the current implementation? Perhaps a test case. JasonThe fact that we lazily parse things makes it possible for really broken stuff to make it to the TU. We never check to see whether mandatory headers are well-formed in the stack.Now if we can make Helper robust enough to handle any and all possible cases of brokenness in the request, that should work fine, but we need to keep in mind that stuff can be very broken indeed. (For instance, what if the topmost via is garbage? We never check its validity in the stack, we just ensure that it is there. How do we respond to something with a bad topmost Via?)
Actually, this is a bad example; we end up parsing the topmost Via when we grab the transaction id. The point here is that really bizarre stuff can show up at the TU.
Best regards, Byron Campen_______________________________________________ repro-devel mailing list repro-devel@xxxxxxxxxxxxxxxxxxx https://list.sipfoundry.org/mailman/listinfo/repro-devel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature