| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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 able to 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. Jason
The 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?)
Best regards, Byron Campen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature