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       =  Request-Line / Status-Line


Further to explain this, it is strict on that there must be one start 
line, followed by a number of message headers. Message headers are 
classified into the message headers and extension headers. Both of which 
have the same basic syntax. If a header does not comply with the SIP 
specified header requirements then such a header invalidates the whole 
message.

While parsing the received message, one would be going top-to-bottom 
parsing the message starting from the start line and going down. In your 
case the start line of the SIP message is "INVITE sip:[email protected] 
SIP/2.0", and any lines after that are SIP headers. Now the line 
following the start line is "UPDATE sip:[email protected] SIP/2.0", which 
does not comply to the SIP header syntax which is defined as:


     header  =  "header-name" HCOLON header-value *(COMMA header-value)
     extension-header  =  header-name HCOLON header-value


Therefore you should consider sending the 400 (Bad request) with the 
reason-phrase mentioning that "UPDATE..." is a header of malformed syntax.


Thank you,

Regards,

Brez


On 07/06/13 10:25, Jagan Mohan wrote:
> Hello,
>
>      I'm having this scenario, where there are multiple Request-Lines in the
> received SIP message.
>
>      INVITE sip:[email protected] SIP/2.0
>      UPDATE sip:[email protected] SIP/2.0
>      BYE sip:[email protected] SIP/2.0
>      From: ...
>      To: ...
>      Call-ID: ...
>      Via: ...
>       < Message Body>
>
>      Here, I see there are two possible solutions to handle this.
>
> 1) Just use the first request line and continue processing the SIP message
> as if it's an INVITE in this case.
> 2) Respond with a 400 Bad Request.
>
>       Though my preference is to go with the first solution, I would like to
> know which solution should be preferred.
>       I could not find any reference to this behavior, in any RFC. Is there
> any standard which talks about the same?
>
> Thanks,
> Jagan
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to