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 <[email protected]> wrote: > > 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 header-value > header-name = token > header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) > > As you mentioned, you have the option to reject it or allow the request to > proceed. > > 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. > > > > Is there any standard which talks about the same? > > RFC 4475 may be of interest; however I'm not sure if it discusses a > similar malformed request. > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
