>>So UAS cannot implement [EMAIL PROTECTED] as a Call-ID validation & can claim
RFC 3261 compliant
As you say, the RFC 3261 grammar is...
>>Call-ID = ( "Call-ID" / "i" ) HCOLON callid
>>callid = word [ "@" word ]
This means that anything which complies with the above grammar is 100%
RFC3261-compliant.
The following are both examples of 100% RFC3261-compliant callid:
34n10ndfhn2339r3
[EMAIL PROTECTED]
Optional components are valid for "strict compliance".
If you believe optional components are not valid, then you will
encounter many interop problems.
Regards,
Attila
________________________________
From: Sourav Dhar Chaudhuri [mailto:[EMAIL PROTECTED]
Sent: 25 September 2008 12:15
To: Attila Sipos; Navneet Gupta; [email protected]
Subject: Re: [Sip-implementors] UA behaviour on recieving INVITE
withoutmax-forwards header
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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
