Hi Attila, See my reply with >>>> in your attached mail But whatever I have given comments is strict implementation of RFC. To make call it can be neglected. But then it cannot be claimed as a full Compliance of RFC
Thanks Sourav ----- Original Message ---- From: Attila Sipos <[EMAIL PROTECTED]> To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>; Navneet Gupta <[EMAIL PROTECTED]>; [email protected] Sent: Thursday, 25 September, 2008 1:52:29 PM Subject: RE: [Sip-implementors] UA behaviour on recieving INVITE withoutmax-forwards header >> If a request does not contain From tag that does not means it is RFC 2543 compliant request. If it doesn't have a From tag then it isn't RFC3261. If I am wrong, can you give me an example of where RFC3261-compliant UAs send requests without a From tag. >>>> I am not saying a request without From tag is 3261 request. I am saying >>>> it is not 3261 request. but it does not mean it is a definitely RFC 2543 >>>> request. For cosidering a request as a RFC 2543 request you have to >>>> verify the request with ABNF grammar of RFC 2543 >>You have to then verify the Call-ID of the request to check it follows ABNF grammar of RFC 2543. If you believe "a request that does not contain From tag does not means it is RFC 2543 compliant request." then checking the call-ID will not help either. You could have an RFC3261-compliant UA which legally uses a call-ID of the form [EMAIL PROTECTED] . Then your detection principle does not work. So, using your beliefs, it is not possible to determine RFC2543-compliance. >>>>.As per RFC 3261 compliant UA(here UAS we are talking about UAS only) it MUST has to accept any request with or without "@" symbol in Call-ID header for any 3621 request. UAS wise it is RFC 3261 non compliant. ABNF grammar of Call-ID in RFC 3261.here [EMAIL PROTECTED] ] i.e it is optional for UAC to generate in "@" in Call-ID. So UAS cannot implement [EMAIL PROTECTED] as a Call-ID validation & can claim RFC 3261 compliant Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] As per RFC 2543 compliant UA(here UAS we are talking about UAS only) it MUST has to accept any request at least with a "@" symbol in Call-ID header for any 2543 request. other wise UAS is RFC 2543 non compliant. ABNF grammar of Call-ID in RFC 2543 Call-ID = ("Call-ID" | "i" ) ":" local-id "@" host local-id = 1*uric So any request came without From tag & with "@ " symbol in Call-ID can be considered as RFC 2543 request if the UAS implemetation of RFC 2543 So any request came without both From tag & "@ " symbol in Call-ID then the request MUST not be considered as neither as a RFC 2543 request nor RFC 3261 request. My logic is simple any time you are considering any request as RFC 2543 instead of a RFC 3261 request then Call-ID grammar MUST be validated with ABNF of RFC 2543 Regards, Attila ________________________________ From: Sourav Dhar Chaudhuri [mailto:[EMAIL PROTECTED] Sent: 25 September 2008 09:02 To: Attila Sipos; Navneet Gupta; [email protected] Subject: Re: [Sip-implementors] UA behaviour on recieving INVITE withoutmax-forwards header Hi Attila, I am also not agreeing with your point If a request does not contain From tag that does not means it is RFC 2543 compliant request. You have to then verify the Call-ID of the request to check it follows ABNF grammar of RFC 2543. You cannot verify with ABNF grammar of RFC 3261. then that request is a partial mixture of both RFC. You can claim a Product of either RFC 3261 complaint or RFC 2543 compliant or both RFC full compliant.. You cannot claim partial complaint with RFC 3261 and RFC 2543 to verify any request. If that Call-ID does not satisfied with ABNF grammar of RFC 2543 then that request Neither compliant to RFC 3261 nor RFC 2543. Because all the headers always validated on the ABNF grammar of that header for that type of request that is either RFC 3261 or RFC 2543 type request. Thanks Sourav ----- Original Message ---- From: Attila Sipos <[EMAIL PROTECTED]> To: Sourav Dhar Chaudhuri <[EMAIL PROTECTED]>; Navneet Gupta <[EMAIL PROTECTED]>; [email protected] Sent: Thursday, 25 September, 2008 1:01:19 PM Subject: RE: [Sip-implementors] UA behaviour on recieving INVITE withoutmax-forwards header 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 ________________________________ Add more friends to your messenger and enjoy! Invite them now. . Be the first one to try the new Messenger 9 Beta! Go to http://in.messenger.yahoo.com/win/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
