Hi Jagan,
To your message below.
SIP explicitly specifies the format of the message which is:
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = R
> > Because the message is malformed, you can basically act
> > however you want. A common philosophy is to be strict
> > sending and lenient receiving. Thus unless you have a
> > reason to do otherwise, you might want to allow the
> > message to continue.
>
> While I generally agree with th
On 6/7/13 6:02 AM, Brett Tate wrote:
> Because the message is malformed, you can basically act however you want. A
> common philosophy is to be strict sending and lenient receiving. Thus unless
> you have a reason to do otherwise, you might want to allow the message to
> continue.
While I ge
Thanks, Brett.
I completely agree with you that we should be lenient receiving and
process the message.
I did go through RFC 4475 and did not find any reference to a SIP message
containing multiple Request-Lines.
On Fri, Jun 7, 2013 at 3:32 PM, Brett Tate wrote:
> > I'm having this scenario,
> I'm having this scenario, where there are multiple
> Request-Lines in the received SIP message.
I assume that it would typically decode as 1 request-line and malformed
extension-header. More specifically, the header-name "UPDATE sip" contains a
space.
extension-header = header-name HCOLON h
Hello,
I'm having this scenario, where there are multiple Request-Lines in the
received SIP message.
INVITE sip:t...@server.com SIP/2.0
UPDATE sip:t...@server.com SIP/2.0
BYE sip:t...@server.com SIP/2.0
From: ...
To: ...
Call-ID: ...
Via: ...
< Message Body>
