Andreas,
So this stack provider drops syntactically incorrect requests rather
than generating an error response. And you would like some reference to
3261 that says a response should be sent in this case.
IMO a response should always be sent unless the request is malformed in
a way that makes it impossible to send a syntactically correct response.
So, if the From, To, or Via were malformed then there is justification
for not sending a response, but since the R-URI doesn't appear in the
response that isn't an issue here. (But if the same value is in the To,
then maybe it does apply.)
But of course servers are permitted to drop requests for arbitrary
reasons, such as being overloaded. So I don't think there is anything
that says there is a *requirement* to respond to this request.
Paul
Andreas Byström wrote:
> 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
