Subject: [SIP] Questions on grammar and syntax

From: Szokoli Gabor <[email-masked]>
Date: Wed, 14 Mar 2001 12:03:57 +0100 (CET)

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.

We are working on a conformance test for SIP protocol entities, based on
RFC 2543 bis 2, and relying on the sip call flows RFC for examples.
I have went through the first several times already, but all RTFMs with
section numbers in it are welcome.

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...)
)

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?

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...

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.

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)

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...

Bonus question: Cseq freedome?

Has anyone ever seen an implementation that did not start from Cseq: 1 and
go up one by one? (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.

I would not be suprised to see this freedom of sequence numbering removed
in the ETSI standard, unless it can be justified as an anti-spoofing
mechanism like in TCP.

Thanks for any answers in advance:
Gabor Szokoli

Ps:
SIP is cool, keep it up! Telecoms people will have to give up on their
standard for standards if they want to use hot stuff, or wait a few
decades for things to mature. That would throw them out of business,
and I'd hate that, because I'd hate to get an error message from 911
complaining of a router misbehaving, but I'm not sure the phone Bell
invented had a "99.999%" label on it right away.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Nobuaki Tanaka" <[email-masked]>
Date: Wed, 14 Mar 2001 20:25:25 +0900

Hello.

----- Original Message ----- 
From: "Szokoli Gabor" <[email-masked]>

> state and tarnsaction state as two "layers" of SIP.

  Is there any formal description of SIP protocol using SDL, Estelle, 
LOTOS or so?

Nobuaki Tanaka
Panasonic, Tokyo, Japan.