Andreas Byström wrote:
> I'm kind of in the middle of the stack provider and the UA provider here...
> But I guess I should interpret your responses that in case of a sip uri with
> the # error, there is no specification that says that the UAS (B2BUA in this
> case) MUST send a sip response?

IMO that is indeed the case.

        Paul

> // Andreas
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] 
> Sent: den 14 november 2007 22:43
> To: Andreas Byström
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Error in incoming req uri, what to do?
> 
> 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

Reply via email to