I agree with Attila. No need for extra checks here. As long as the UAS is the correct recipient of the INVITE, why would it reject the call based on the the absence of a header that will not affect proper call function? Except of course if the UA mentioned in by the OP is a B2BUA in which case I think the proxy rule applies and the B2BUA must add the missing header with a value of 70.
Attila Sipos wrote: > 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 > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.7.2/1689 - Release Date: 9/24/2008 > 6:51 PM > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
