[SIPForum-discussion] Processing a SIP message containing multiple Request-Lines

Santosh Iyer spi6281 at yahoo.com
Fri Jun 7 16:00:52 UTC 2013


Not sure what the RFC's take is on this. May be experts on this forum could comment. Clearly its an ambigous message. But still if you wanted to process it, check the CSeq method, whatever CSeq method is listed process the message as that method. for example if it says "CSeq: 123 UPDATE", process it as an UPDATE message.
Santosh

--- On Fri, 6/7/13, Jagan Mohan <jaganmk at gmail.com> wrote:

From: Jagan Mohan <jaganmk at gmail.com>
Subject: [SIPForum-discussion] Processing a SIP message containing multiple Request-Lines
To: "SIP Implementors" <sip-implementors at lists.cs.columbia.edu>, "discussion at sipforum.org" <discussion at sipforum.org>
Date: Friday, June 7, 2013, 2:55 PM

Hello,
    I'm having this scenario, where there are multiple Request-Lines in the received SIP message.
    INVITE sip:test at server.com SIP/2.0
    UPDATE sip:test at server.com SIP/2.0
    BYE sip:test at server.com 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   

-----Inline Attachment Follows-----

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130607/caa95304/attachment-0002.html>


More information about the discussion mailing list