Questions on sip belong on the sip-implementors list. Comments below. > -----Original Message----- > From: Szokoli Gabor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 14, 2001 6:04 AM > To: SIP mailing list > Subject: [SIP] Questions on grammar and syntax > > > Hello! > > I'm new to the list, so excuse any repeat questions, I have tried to > browse the archive but failed to find the "serach" option if > there is any. You can look at the entire quarter's archives in one file and then use your browsers search capabilities. > 1, header syntax > > When the RFC sais to copy certain header fields, like To: and > From: from > request to response, or in case of a proxy, from incoming message to > proxied message, does it mean "copy byte by byte", possibly > inserting or > modifying a field or tag in it, or does it mean "copy all > field and tag > values, using your own output syntax"? > (e.g. should extra white spaces be passed on? Is changing > from long from > to short form allowed? Is the reordering of "unordered" tags OK? > Is an implementation with an inner SIP message representation not > keeping formatting, ordering and other meta-information, and a > parser/encoder to it appropriate? (not too efficient, but suppose...) > ) It is allowed to modify things like white space. After copying, the To/From must be the same based on standardized comparison rules, but these are not byte by byte. > > 2, header ordering > > When no header encription is used, is there any rule for > header ordering? > Should the ordering in a response follow the order in a request? > May a proxy reorder headers? (like for tags above) > (except for the via: order that gets corrupted, of course) > I don't care why, I have to know if it is conform or > non-conform operation > to do so. Just suppose you get your hands on an > implementation that does > this, would you return it demanding your money back saying > "this is a bad > proxy, it reorders my headers" or not? Excepting Via and RR, reordering of headers is permitted. > > 3, BNF trouble > > We have thought of the BNF fragments in the RFC more like of a kind of > illustration, not as a cohesive grammar, but the Contact > parameters still > give us headaches: > The Contact may contain a SIP-URL (not <> enclosed) ";" > contact-params. > The URL may end with a list of url-parameters, separated by ";". > > It would be OK, but the last url-parameter may be other-param > and the first contact-param may be extension-attribute, and a > parser not > familiar with a contact parameter extension may mistake it to be an > unknown url-parameter. > I hope I just missed something here... The text states that if the URL contains a semicolon, the bracketed form must be used. So: Contact: sip:u@h;foo=bar foo is a contact parameter Contact: <sip:u@h;foo=bar>foo=bar there is an inner URL parameter foo=bar and a contact parameter foo=bar Contact: <sip:u@h>;foo=bar foo is a contact parameter Contact: <sip:u@h;foo=bar> foo is a url parameter So, there is no ambiguity. > > 4, State machine? > > Is there any other definition for call states of a SIP state > machine from > figures 12 and 13 in 2543? > We do not need an exact state machine with all possible > events and state > transitions, only a short definition of states. > We can make one up pretty quick, of course, but it would be nice to be > compatible with the rest of the world. > That was a lie, we are having philosophycal debates over > separating call > state and tarnsaction state as two "layers" of SIP. call states are separate from transaction states. SIP does not define a call state machine per se; there is a simple one implicit in the usage of sip, whereby there is at least an active state you enter upon invite, and leave upon bye. > > 5, Cseq method for unknown methods? > > Proxies should forward unknow method requests just like an OPTIONS > request. Should they enforce a matching method field in the > Cseq header? > (penalising incorrect unknown requests by 4xx) It is not a requirement to reject requests that are malformed in this way. A proxy could possibly correct the cseq method name, in this case. > > 6, Cseq of an INVITE from the called party? > > When the called UA initiates a change of the call, sending an > INVITE, what > Cseq: should it use? It's the same call leg, but this is his first > request... random initial value. > > > Bonus question: Cseq freedome? > > Has anyone ever seen an implementation that did not start > from Cseq: 1 and > go up one by one? Yes. Ours starts with a random number as specifeid in the spec. (Using a 2^31 seconds timer clashes with round-trip > times below 1 second, or did I miss somethig about that argument?) > The only reasonable jumping in the numbering I can think of is using a > single counter for a call leg, not a separate one for all methods. Selecting the CSeq based on values of the system clock (which is what the spec talks about) has nothing at all to do with round trip times. You would select the INITIAL value when you want to make a call, based on whatever the current time is. Subsequent values then always bump by one indepdenent of the system clock. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
