Re: 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