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.