I also agree that for this specific case I dont want to forward the request since that means that the B2BUA application needs to send out a request that it know is wrong but cant be 100% sure that it should escape the # sign to make it correct.
The thing is that I'm building the B2BUA application on top of a SIP stack (from another supplier). Now our customer has some UAs that does not escape #, and our customer agrees that it is wrong and that the UA should be updated (and it will in time). However, the stack I'm using does not send any response (no response at all) and does not even trigger my application (so I have no real option to try to forward the message) when it gets an INVITE with # . The customer wants the B2BUA to send an 4xx response, while the stack provider says it does not consider it to be needed. I do agree with the customer in this case but I really need to point out to the provider that "look at rfc3261, page X section Y" to really convince them that they MUST send a response. Even though I think it is obvious that the stack should send a response (or send it up to the application so that I can reject it with 4xx myself), I have tried to find such a statement in the RFC but failed. Sending no answer at all means that the UA will retransmit until timeout and as you already have said that is not a good solution. Hope that you can help me out on this :) // Andreas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: den 15 november 2007 15:30 To: [EMAIL PROTECTED] Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Error in incoming req uri, what to do? I agree with Dale, especially about not forwarding a malformed URI. OTOH, I don't believe that forwarding nodes are *obligated* to verify the validity of everything in a message they forward. So for instance if a node notices that the domain is not its own, and so forwards based on the domain name it might just not validate the user part at all. Or if it forwards based on the Route header it may barely notice the R-URI. So, I think 400 is certainly acceptable in this case, but other error responses are also acceptable. Thanks, Paul [EMAIL PROTECTED] wrote: > From: Paul Kyzivat <[EMAIL PROTECTED]> > > The UA receiving this must (by definition) be the UAS. It *ought* to be > the intended recipient of the request (leaving aside some B2BUAs which > have different issues). As the intended recipient, the URI ought to be > one it knows about. Since this one is malformed (and the UA probably > wouldn't *intend* to support malformed ones) this URI must be something > unknown to the UAS. In that case a good response is 404 Not Found. > > I would say that 400 is acceptable also, because the UA may not be > even able to parse the incoming message enough to decide what > precisely it didn't like about. > > If the UA is one that never forwards messages, it seems plausible that > it might take a liberal interpretation of an un-escaped character that > should be escaped but otherwise has no interpretation. If the UA is > considering sending the message on, I would argue strongly that it > should reject the message, because it can't forward the message in a > strictly compliant way without making guesses as to what the sender > meant, and it does not have the implicit information "if I received > it, it must have been intended for me". > > Dale > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
