Re: Rejecting message due to parse error

Michael,

I guess the stack could send a 400 Bad Request, would that help you?

Regards,

Jeroen

PS Ranga, I'll add this if it's ok with you

----- Original Message ----- 
From: "Michael kr" <[email protected]>
To: "Jeroen van Bemmel" <[email protected]>; <[email protected]>
Sent: Sunday, September 17, 2006 1:25 PM
Subject: Re: [nist-sip] Rejecting message due to parse error


> 
> Hi Jeroen van Bemmel,
> 
> I can't control what name users picks up for their
> computer.
> 
> I do need a solution for this scenario where a user
> makes an invite, and the call does not appear to
> trigger a response. Only "post mortem" analysis reveal
> what happened in the trace file (*only!*). If one does
> not generate trace file information he want be able to
> find it at all, without diving into the stack code.
> 
> As application layer programmer I have two problems
> here:
> a. "Black box" - calls are not handled and no
> information is visible. I had to use ethereal to track
> the message path into the stack. The log file does not
> show anything and only peeking in the trace file revel
> the problem.
> 
> b. "Uptime" or success rate - in the PSTN world person
> picking up the phone expects his call to come through,
> and this is exactly what happens. We need to get there
> too. Calls that are not passing should not be
> acceptable. The frustration level of the programmer
> should be also reduced. 
> How do we solve the conflict between the RFC and
> "reality"?
> 
> Thanks,
> 
> Michael
> 
> 
> 
> 
> --- Jeroen van Bemmel <[email protected]> wrote:
> 
>> Michael,
>> 
>> According to RFC3261, the hostname must conform to
>> 
>> toplabel         =  ALPHA / ALPHA *( alphanum / "-"
>> ) alphanum
>> 
>> So '_' is not allowed. This is also true for
>> hostnames registered in DNS 
>> (see eg rfc3696). It may be allowed in certain local
>> environments (eg 
>> Windows NETBIOS, not sure); recommended is to use
>> only names that match the 
>> above rule
>> 
>> (a) No, cannot be tolerated
>> (b) would be possible, but would require a change to
>> the API (eg 
>> processParseError). As you have seen, it will
>> currently show in the logs. 
>> That is the best we can do at the moment
>> 
>> Is the message also generated by a JAIN stack? If
>> so, it should report a 
>> ParseError upon construction of the From header.
>> This is something we could 
>> fix
>> 
>> Regards,
>> 
>> Jeroen
>