I don't agree with this. It's not a SIP entity's job to be "SIP police" to this extent.
If you require strict 3261-compliance then ok - reject the request with 400. If you don't, then process it normally. I feel all the others checks are unnecessary. For example, adding code to check for strict RFC 2543-compliance - I can't see any purpose in that. Checking the call-id? Why? If you are 3261-compliant then you won't care if it has a @ anyway. It's just overly officious. And the easiest way to check for RFC3261-intended-compliance is the from-tag in the INVITE request - if there isn't a from-tag, it's an RFC2543 implementation. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sourav Dhar Chaudhuri Sent: 25 September 2008 07:59 To: Navneet Gupta; [email protected] Subject: Re: [Sip-implementors] UA behaviour on recieving INVITE withoutmax-forwards header Hi Navneet, Sip UA(End Point) behavior on receiving INVITE without max-forwards header depends on implementation of backward compatibly with RFC 2543. If the Sip UA(End Point) backward compatible with RFC 2543 then it MUST follow step (d) said by you. RFC 2543 does mandate Max-Forwards in a request. it ia OPTIONAL header. "Refrence RFC 2543 table 4" Max-Forwards R n e o o o o o o Table 4: Summary of header fields, A--O But be sure remaining all the headers are following RFC 2543 strictly. Example Call-ID header MUST contain "@ "symbol with other value in that Request which is MUST condition for RFC 2543 ABNF grammar. RFC 3261 does not mandate it . ABNF of Call-ID in RFC 2543 Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host local-id = 1*uric ABNF of Call-ID in RFC 3261 Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] If the Sip UA(End Point) is compatible with only RFC 3261 then it MUST follow step (b) said by you. As table 2 of chapter 20 in RFC 3261 suggest Max-Forward is mandatory header which is marked by "m " under all the request. It is not marked by "m*" RFC 3261 chapter 20 m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If any of the header like Via, From, To, Call-Id & CSeq is not present in a request the way Sip UA(End Point) treat the request. The same way Sip UA(End Point) MUST that request which does not contain Max Forwards header. As all these headers are exactly same way represented in the table 2 of RFC 3261 Thanks Sourav ----- Original Message ---- From: Navneet Gupta <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, 24 September, 2008 3:12:05 PM Subject: [Sip-implementors] UA behaviour on recieving INVITE without max-forwards header Hi If a SIP UA (Endpoint), recieves an INVITE request which does not contain the mandatory Max-Forwards header, what should the UA do? Should it - a) respond with 483 (Too many hops) response b) respond with 400 Bad request response c) Stay quiet and Ignore the INVITE. d) Process the INVITE normally. Please help. Regards Navneet *****************************************************DISCLAIMER********* ******************************************** This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. ************************************************************************ ******************************************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/ _______________________________________________ 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
