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

Reply via email to