Florent,

Many thanks for the reply - I have now solved this issue thanks to your suggestions.

The plot thickened with client logging for QuteCom. This occurs every time an INVITE is received 

(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:414: Could not set header: "from" "None
(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:695: End of header Not found
(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osipparser2/osip_message_parse.c:932: error in msg_headers_parse()
(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/libosip2/src/osip2/osip_event.c:79: could not parse message
(error) 14:04:04 [PhApi] : osip: /build/qutecom-u8vPAW/qutecom-2.2.1+dfsg1/wifo/eXosip/src/udp.c:2569: Could not parse SIP message

Looking at the first few lines of the INVITE, I see this:

INVITE sip:106@192.168.41.198:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.196.101:5080;rport;branch=z9hG4bK0DN82p3e63jZm
Max-Forwards: 67
From: "None
" <sip:07951357XXX@freeswitch.bashton.eu>;tag=7ZjyU00tv7mFr

That makes sense now since the "None" is split over two lines causing the parse error. I then went back to the dialplan and remembered that I set up

       <action application="set" data="effective_caller_id_name=${cidlookup(${caller_id_number})}"/>

where the cidlookup service was a small Python CGI script running on localhost. As it turned out, the output from this service included a line-feed after the caller name, and this was directly fed into the INVITE headers, confusing the SIP client.

Cheers,
Gavin.