Andreas,
The catchall response for this is 400. If the uri is syntactically
invalid (which is the case if the user part contains #) then you are
justified in returning that response. But IMO that is over zealous.
If you are just a pass-through (a proxy or a B2BUA that doesn't care
about this) then I think I would just ignore it.
If you are the intended recipient, or are say a proxy authoritative for
the domain of the URI that is expected to route based on the user part,
and the user part isn't acceptable to you, then the 404 response seems
appropriate to me. In that case it makes little difference if the user
part has a syntactically invalid character, or has a value that
syntactically valid but is semantically invalid to you.
Paul
Andreas Byström wrote:
> Thanks Paul,
>
> The actual case I'm talking about is a B2BUA which in this particular case
> acts as an AS. For some cases, the # is needed for the AS application
> (controlling the subscribers Call Forward settings by sending commands like
> *21*123456#) but other cases could be that the subscriber that placed the
> call just happened to press the # sign in the middle of a number.
>
> Anyway, for both cases I guess there should be a client (4xx) error
> triggered? My main question is really if there are some defined behavior
> somewhere that says that the B2BUA _must_ send a response for an incoming
> request with erroneous sip uri in request line, or if it is ok just to
> ignore it? It might be that the reqln uri is soo messed up that it will be
> hard to identify this as an SIP request... I don’t know if a # could have
> such effect
>
> // Andreas
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: den 14 november 2007 21:18
> To: Andreas Byström
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Error in incoming req uri, what to do?
>
> 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.
>
> Paul
>
> Andreas Byström wrote:
>> What should a UA do in case it receives an request with an malformed
> sipuri
>> in the request line? For example if there is an incoming INVITE
>> [EMAIL PROTECTED] sip/2.0 (ie the sender has not escaped the #
>> character).
>>
>>
>>
>> I guess there would be good to respond with maybe 400 Bad Request or some
>> other 4XX response, but I cant find something that supports this in the
>> RFCs. Does anyone know if there is some specifications that defines what
> to
>> do in a case with malformed uri in the requestline or is it up do the
>> developer of the UAS to decide? If no answer at all the UAC will probably
>> retransmit…
>>
>>
>>
>> Regards,
>>
>> // Andreas
>>
>>
>>
>>
>>
>> _______________________________
>>
>>
>>
>> Andreas Byström
>>
>> Software Engineer
>>
>>
>>
>> Teligent AB
>>
>> Konsul Jonssons väg 17
>>
>> P.O. Box 213
>>
>> SE 14923 Nynäshamn
>>
>>
>>
>> mail: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
>>
>> web: <http://www.teligent.se/> www.teligent.se
>>
>> phone: +46 (0)8 4101 7221
>>
>> mobile: +46 (0)733 1172 21
>>
>> fax: +46 (0)8 520 193 36
>>
>> _______________________________
>>
>>
>>
>> _______________________________________________
>> 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
