Subject: [Sip] comments and nits on bis-07

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 12 Feb 2002 14:51:52 +0200

Hi,

Line numbers refer to the pdf version.

-line 568: should start in a new paragraph after the full stop.

- line 644: adress should be address

- line 722: "is" is repeated

- line 739: definition of UAS says that "If it generates a request later on,
it assumes the role of a user agent client for the processing of that
transaction". I think this confuses people who are trying to understand the
separate roles of a UAC and UAS. It is the UA that can act as a UAC or a
UAS, not the UAS. So a UAC is created (or something like that)

- line 788: definition of SIP-Version. "The SIP-Version string is
case-insensitive, but implementations MUST send upper-case". Maybe I missed
earlier discussion, but if its a MUST for uppercase, why make it
case-insensitive?

- line 855: "Proxy-Authorization" repeated.

- lines 1160 - 1161: same info is repeated in lines 1163 - 1165.

- line 1162: why is it a MUST to try ALL contacts until a server responds?
Can a user just choose to try a subset?

- line 1207: a closing bracket is missing after (Section 25.4.14

- line 1211: I think a should is too strong, a client puts a Require header
there for a reason, and possibly doesn't want to or can't retry without
these required extensions. A MAY could be sufficient there.

- line 1263: same as on line 1211. Actually, this statement is just a
duplicate of line 1211.

- line 1366 - 1368: "A redirect server does not issue any SIP requests of
its own. After receiving a request other than CANCEL, the server gathers the
list of alternative locations from the location service and either returns a
final
response of class 3xx or it refuses the request." Why is the request refused
after locations have been gathered? on some occasions, requests can be
rejected before any alternate locations have been gathered.

- line 1404: "CANCEL has no effect on a request to which a UAS has already
responded." should say "CANCEL has no effect on a request to which a UAS has
already responded to with a final response".

- line 1407: "a UAS that receives a CANCEL request for an INVITE, but has
not yet sent a response, would “stop ringing”" should say "a UAS that
receives a CANCEL request for an INVITE, but has not yet sent a final
response, would “stop ringing”"

-lines 1512 and 1527: line 1512 says "The following header fields MUST be
included:" and then lists the contact header in line 1527. Although it says
that zero or more contact headers, the above sentence gives the false
assumption that a contact is mandatory in a REGISTER request.

- line 1697: why is it a MUST for a contact header to contain an "expires"
parameter?

- line 1731 and line 1765: the call-id header in line 1731 is missing the
host part in the example (or the call-id in line 1765 has a host that
shouldn't be there).

- line 1757: "(application/sdp if the Accept header was not present)" should
say "(application/sdp is the default  if the Accept header was not present)"

- lines 1811 - 1813: are a repeat of line 1785 to 1789.

- line 1833: does say when the local sequence number would be set.

- line 1847: "(it is established when the UA sends a request within the
dialog)", this needs to be more specific; which UA are we exactly referring
to? how about "(it is established when the remote UA sends a request within
the dialog)"

- line 1861: open issue

- line 1872: "Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers" why MUST be contiguous? its
can be a SHOULD.

- line 1875: should say "MUST be placed into the Cseq header". ("be" is
missing).

- line 1888: should say "MUST add a Route header". ("add" is missing).

- line 1951 - 1953: this is a general statement about Requests within a
dialog and not just specific to UAS behaviour. I propose for it to be moved
to section 12.2 (before 12.2.1).

- line 1967: "When a dialog is established with INVITE, it is terminated
with a BYE". I propose "When a dialog is established with INVITE, it MUST be
terminated with a BYE".

- line 2021: "In this specification, offers and answers can only appear in
INVITE and PRACK requests and responses". What about ACK? an answer can be
there.

- line 2064: "excluding the tag" should be put in brackets instead of
between commas to show that this comment only belongs to the To header.

- line 2166: section 13.3.1.2 does not talk about what happens if a 3xx is
returned with no contacts.

- line 2189 - 2195: is that INVITE server transaction destroyed as soon as
it receives the final response or as soon as it sends the final response?
does the UAS core then directly pass retransmissions to the transport layer?

- line 2278: what would be the reason for a UAC to send a re-INVITE with no
SDP?

- line 2285: why terminate the session, this is just a re-INVITE. The UAC
can re-INVITE yet again.

- line 2296: Sections 13 and 12. Make it sections 12 and 13 :)

- line 2327: "Once the BYE is constructed, it creates a new non-INVITE
client transaction". Who is it? maybe it should say "Once the BYE is
constructed, the UAC core creates a new non-INVITE client transaction"

- line 2364: choose instead of chose.

- line 2375: "The proxy SHOULD NOT send a CANCEL." Does it really mean that
a proxy SHOULD NOT initiate a CANCEL?

- line 2394: in the .txt version, the numbers there are screwed up.

- line 2416: in the .txt version, the words "a request" are missing after
"forwarding".

- line 2454: "is" is repeated.

- line 2464: section number is missing.

- line 2475: "Otherwise, if the Request-URI contains an maddr parameter, the
Request-URI MUST be ..." could instead say "Otherwise, if the Request-URI
contains an maddr parameter the proxy is not responsible for, the
Request-URI MUST be ..."

- line 2712: this section 16.6 contains 5 then 3 processing points, yet the
details show 10. Also the numbers for detailed steps don't follow the
numbers above.

- line 2806: should say "1xx and 2xx responses may be involved in the
establishment of dialogs". ("of" is missing)

- line 2811: "Since a proxy may not..." should say "Since a proxy MUST NOT"
to be precise.

- line 2856: "to" is repeated.

- line 2910: should the reference be to section 9?

- line 2941: "The proxy examines the branch ID of the received request".
Which branch-id? the one in the top-most via header? there could be more
than 1 via header.

- lines 3099 to 3100: "The transaction exists between the UA or stateful
proxy on one side of the stateless proxy, and the UA or stateful proxy on
the other side. As far as SIP transactions are concerned, stateless proxies
are effectively transparent" doesn't make sense. Should it say "The
transaction exists between the UA or stateful proxy on one side, and the UA
or stateful proxy on the other side. As far as SIP transactions are
concerned, stateless proxies are effectively transparent"? (remove "of the
stateless proxy").

- line 3186: "transaction to" is repeated.

- line 3212: "Whenever a response is received by the transport, if the
transport layer finds no matching client transaction (using the rules of
Section 17.1.3), the response is passed directly to the core." Is this for a
2xx response only? If so, it should mention that. It should also mention
what happens if transport layer received a non-2xx final response and no
matching client transaction is found.

- line 3233: "These rules", which ones? all from the start of this section?
If so, this sentence starting from this line should be at the start of the
section. Other wise specify which rules.

- line 3258: "what" should be changed to "to"

- line 3275: "...SHOULD move to the “Proceeding” state." It should go on to
say that "Timer E MUST be reset to T2".

- line 3287: why is T4 so low at 5 seconds? (maybe I missed this
discussion).

- line 3464: "PRACK is a normal SIP message, like BYE. As such, its own
reliability is ensured hop-by-hop through each stateful proxy". I failed to
find where that is mentioned about BYE that it is hop-by-hop.

- line 3475: "...100rel. While this specification..." The .txt version ate
some of the words here. It says "100rel specification"

- line 3478: "option tag 100rel. If the UAS is unwilling to do so, it MUST
reject the initial request with a 420 (Bad Extension)". Again, the .txt
version ate some words. it says "option tag 100rel initial request with a
420 (Bad Extension)".

- line 3512: "It SHOULD cease retransmissions of the reliable provisional
response". Why isn't this a MUST?

That's all for now. More comments are in separate emails.

Regards,
Hisham Khartabil

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Sun, 17 Feb 2002 17:16:49 -0600

The points below have been addressed or are
being tracked. Responses for the 100rel comments
will come separately.

Comments inline (along with a request for Gonzalo and Jonathan
to answer a couple of the questions).

> earlier discussion, but if its a MUST for uppercase, why make it

CI is important (we don't want sip/2.0 to mean something else).
{\MUST} send uppercase improves robustness.

> Can a user just choose to try a subset?

A subset may be used - the text has been modified to reflect that.

> these required extensions. A MAY could be sufficient there.

We want to encourage a retry if the request can succeed ratcheting
down the requirements. In the case that a client doesn't want to or can't
retry without the extension, it's got a good reason not to (hence doesn't
violate the SHOULD).

> not yet sent a response, would "stop ringing"" should say "a UAS that
> response, would "stop ringing""
> 

This is how the registrar communicates how much longer the binding will last
back to the client.

> increasing and contiguous CSeq sequence numbers" why MUST be contiguous? its

I agree, but this has been brought up on the list several times and the
group has consistantly chosen to leave it as a MUST. Helps with debugging
I guess.

> with a BYE". I propose "When a dialog is established with INVITE, it MUST be

Ugh - not as easy as that. The text has been changed to reflect that BYE is
how termination is defined in this document, but extensions may define other
mechanisms. (sip-events is one such extension).

> returned with no contacts.

How would that happen? The sections on generating 3xx specify returning a
different response if there are no alternate URIs to try.

> - line 2278: what would be the reason for a UAC to send a re-INVITE with no

3pcc among others

> - line 2285: why terminate the session, this is just a re-INVITE. The UAC

Gonzalo - would you comment on this?

> - line 3275: "...SHOULD move to the "Proceeding" state." It should go on to

Jonathan - could you answer this one?

> find where that is mentioned about BYE that it is hop-by-hop.

The reliability for _all_ non-INVITE transactions is hop-by-hop. That's
covered in the transaction section.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Feb 2002 02:40:30 +0200

Hi,

> Gonzalo - would you comment on this?

We had some discussions about this some time ago. The result was that if
a transaction within a dialog fails, it means that the other end is
unreachable, and thus the UA terminates the session. Therefore, we treat
re-INVITE as any other mid-dialog request.

Trying to re-INVITE again would probably trigger the same error as the
first one (481, ICMP error ...), and we would only increase network
traffic.

Regards,

Gonzalo

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Feb 2002 17:21:28 +0200

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Monday, 18 February 2002 1:17 AM
> To: Hisham Khartabil
> Cc: [email-masked]; [email-masked]; gonzalo.camarillo
> Subject: Re: [Sip] comments and nits on bis-07

> This is how the registrar communicates how much longer the

You misunderstood my question. Anyway, from your comment, I gather that an
Expires header in a 200 response to a REGISTER is Optional. Is that correct?
Can an entry in table 2 be added to reflect that?

> mechanisms. (sip-events is one such extension).

Ok, with some sort of NOTIFY, I guess. So how about a SHOULD or a MAY
instead of "is"?

> different response if there are no alternate URIs to try.

I was referring to the "SHOULD", the spec in that line says "301 or 302
response SHOULD contain a Contact header field...". The SHOULD gives the
impression that a 3xx response with no contacts is possible, hence the
question, how does a UAC handle this?

Table 2 also specifies it as Optional.

In any case, it should read "301 or 302 response SHOULD contain at least one
Contact header field..."
                                                                ^^^^^^^^^^^^

Regards,
Hisham

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Feb 2002 17:21:01 +0200

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, 18 February 2002 2:41 AM
> To: Robert Sparks
> Cc: Hisham Khartabil; [email-masked]; [email-masked]

This scenario is not talking about a time out error, its talking about a
re-INVITE with no SDP from the UAC, a 200 with an SDP from the UAS. The SDP
in that 200 response is not acceptable by UAC. The UAC has nothing else to
do but to generate an answer with a valid SDP. The spec says then that the
UAC should send a BYE to terminate the session. My question is: why
terminate the session? UAs can continue with the session unaffected. It was
only a re-INVITE to an existing session.

Also, the UAC can re-INVITE with a new SDP acceptable for it?

I guess terminating the session is an option, but shouldn't be mandated.

> first one (481, ICMP error ...), and we would only increase network

Not if its a re-INVITE with SDP this time. Again, the scenario was about a
re-INVITE with no SDP.

Regards,
Hisham

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Feb 2002 18:11:33 +0200

Hello,

> only a re-INVITE to an existing session.

When a UAS receives a re-INVITE with no SDP, it has to generate an offer
that somehow overlaps with the one in use, so that it is acceptable for
the UAC. A UAS that fails to do so has probably crashed and re-started.

as you suggest, we could recommend that the UAC re-INVITEs again, this
time with SDP. However, our assumption was that if the UAC sent the
re-INVITE with no SDP to begin with, it was because it has a good reason
for doing so. Otherwise it could have included the SDP in the first
place.

Anyway, what this sentece means is that receiving an incompatible SDP in
an offer in a 200 OK for a re-INVITE implies that an error has occured
in the UAS. That's why the UAC SHOULD send a BYE. If you want to
implement some kind of recovery mechanism instead of terminate the
session, it is up to you.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Feb 2002 17:49:30 +0200

> Sent: Monday, 18 February 2002 6:12 PM
> To: Hisham Khartabil
> Cc: Robert Sparks; [email-masked]; [email-masked]

Ok, the text should be changed to say SHOULD, or MAY preferably. The current
text sounds like its mandatory to BYE.

Thanks for the califications on the assumptions. (Maybe they should be
mentioned :).

Regards,
Hisham

---

From: "Hisham Khartabil" <[email-masked]>
Date: Mon, 18 Feb 2002 17:51:37 +0200

Expires header is different that expires parameter.

br,
Hisham

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Monday, 18 February 2002 5:50 PM
> To: Hisham Khartabil
> Cc: Robert Sparks; [email-masked]; [email-masked];
> gonzalo.camarillo
> Subject: RE: [Sip] comments and nits on bis-07
> 
> 
> Hisham Khartabil writes:
> 
> no, it isn;t, line 1696:
> 8. The registrar returns a 200 (OK) response. The response MUST contain
>    Contact header fields enumerating all current bindings. Each
>    Contact value MUST feature an expires parameter indicating its
>    expiration interval chosen by the registrar.
> 
> -- juha
> 
> 
>

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 18 Feb 2002 17:50:02 +0200

no, it isn;t, line 1696:

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Mon, 18 Feb 2002 12:31:09 -0600

Hisham Khartabil wrote:

>>>- line 1697: why is it a MUST for a contact header to contain
>>>
>>an "expires"
>>
>>>parameter?
>>>
>>

The table already says that (and empty cell in the "where" column means
requests and responses.

Yes - the Expires header field in a 200 response to a REGISTER request is
allowed. It also has no meaning with respect to the Contacts in the response
since each provided Contact MUST contain an ;expires= parameter.
(Note to casual readers - this is a statement about the _response_, not
  the REGISTER request)

So - help me understand your original question. Is it "why don't you allow
the "use the expires parameter if present, otherwise use the Expires header
value in REGISTER responses like you do in REGISTER requests?".

I can't think of a good reason right now. Jonathan?

I will note that its critically important for Contact values in 3xx responses
to contain their own expires parameter (since proxies can aggregate contacts
from multiple 3xx's received at a fork-point).

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 18 Feb 2002 12:46:44 -0600

The 3xx may also contain no contacts the UAC is willing to try to use.
Through policy or asking the user or whatever, it determines that it has
nowhere else to go, so it just stops. This is what would happen in the
case that a 3xx with no contacts showed up (though again, that should never
happen).

Also remember that while we expect most URIs provided in 3xx responses
(to INVITE anyhow) to contain sip: URIs, other schemes (like mailto: and
http:) are allowed.

I will adjust 13.3.1.2 to reflect that a UAS won't be attempting to redirect
unless it has at least one URI to redirect towards and reflect that more than
one alternate locations may be provided.

RjS

Hisham Khartabil wrote:

>>>- line 2166: section 13.3.1.2 does not talk about what happens
>>>
>>if a 3xx is
>>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 19 Feb 2002 17:38:03 +0200

> Sent: Monday, 18 February 2002 8:31 PM
> To: Hisham Khartabil
> Subject: Expires heade field in REGISTER responses: (was Re: [Sip]
> comments and nits on bis-07)
>
>
>
>
> Hisham Khartabil wrote:
>
> >

Yes, that was exactly what I asked. If its not so, what does an Expires
header in a 200 OK for a REGISTER mean?

---

From: Robert Sparks <[email-masked]>
Date: Tue, 19 Feb 2002 10:04:34 -0600

(trimming)

> header in a 200 OK for a REGISTER mean?

As I note above, with the current text an Expire header field has no meaning
if it appears in a 200 response to a REGISTER request.