[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-developers] linphone not generating "400 Bad Request" for bad

From: Robert Dyck
Subject: [Linphone-developers] linphone not generating "400 Bad Request" for bad body length
Date: Thu, 24 Feb 2011 13:37:31 -0800
User-agent: KMail/1.13.5 (Linux/; KDE/4.5.5; i686; ; )

I am not a developer but this seems to be the appropriate channel for 
reporting bugs.
While making test calls through various ISPs into linphone-3.4.1 I ran into a 
situation where the INVITE was being retransmitted but there was no response 
from linphone. With Wireshark I confirmed that the messages were actually 
reaching linphone. I opend the debug window and found the following --

error: Message was not receieved enterely. length=310 osip_body_len=311
error: error in msg_osip_body_parse()
error: could not parse message
error: Could not parse SIP message

RFC3261 has this to say on the subject --
In the case of message-oriented transports (such as UDP), if the message has a 
Content-Length header field, the message body is assumed to contain that many 
bytes. If there are additional bytes in the transport packet beyond the end of 
the body, they MUST be discarded. If the transport packet ends before the end 
of the message body, this is considered an error. If the message is a 
response, it MUST be discarded. If the message is a request, the element 
SHOULD generate a 400 (Bad Request) response. If the message has no Content-
Length header field, the message body is assumed to end at the end of the 
transport packet.

Although not mandatory I think it would be a good idea if linphone sent back 
an error message in this circumstance.

Oddly, Content-Length is not required in UDP. If I patch libosip2 to ignore 
the error, the call goes through. The parser calculates the length for itself 
and does not require Content-Length from the message.

By the way, the bad length was not inserted by the UAC but by the proxy when 
it mangled the Owner line in the SDP to account for NAT. Assuming that the 
registrar and the proxy where the same node, the proxy appears to be ser 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]