Subject: [Sipping] nit review of draft-ietf-sip-isup-03.txt

From: Igor Slepchin <[email-masked]>
Date: Mon, 24 Sep 2001 18:05:33 -0400

Here are the notes from my nit review of draft-ietf-sip-isup-03.txt. Most of
them are just that - nits.

A general comment: lots of references are made to IETF drafts, some of which
are expired (e.g., [17]).

4.1 SIP clients and servers which do not understand ISUP are permitted to
   ignore these (and other) optional MIME bodies.

Do you mean proxies and/or B2BUAs here? Gateways would normally play the
roles of UAC and UAS in the PSTN internetworking scenarios under
consideration.

4.4 "PSTN interoperating nodes should ..."

These are never defined. It may be useful to explain what entities are
involved into the call flow and which of them need to be aware that PSTN
internetworking is taking place. This would also clear up some confusion
from 4.1. Same comment applies to section 4.5

6.1 "100 Trying" acknowledgements to INVITE requests are not
   displayed, since their presence is optional.

They are not really optional. SIP spec is quite explicit about when they
need to be sent:

A server SHOULD send a 1xx response if it expects to take more than 200ms to
obtain a final response.

In general, I think that sending a 100 response is quite advisable and
should be recommended.

6.2 State diagram is missing transitions triggered by ACK timing out (e.g.,
as described in 6.1.4)

6.2.1 "100 Trying" response may be sent back to ...

I suggest changing "may" to "should".

6.2.3. CANCEL or BYE received

State diagram has no corresponding transition for BYE.

6.2.4.1 This kind of cause value indicates a non permanent situation. A
     `Retry-After' header has to be added to the response.

What should the value of Retry-After be? Note that setting it to a non-0
value is likely to take the whole gateway out of service as the upstream SIP
entity will not know what specific resource is unavailable. In general, I'd
recommend against sending back a 503 unless the gateway itself is
unavailable as opposed to unavailability of some resource for this specific
call. E.g., "user not member of CUG" and invalid message should probably not
be mapped to 503 response code.

7.1.1 The call flow diagram contains two consecutive 200 responses (10 and
11). One of them is the response to PRACK, the other to INVITE. It would be
nice to mark them as such on the diagram. For example, the first may be
marked as 200 PRACK, the other as 200 INVITE. Same goes for the diagram in
7.1.6

7.1.4 When T11 expires, an ACM message will be sent to the ISUP
      node to prevent (???) the from being torn down by the remote node's
      ISUP T7.

"the call" is probably omitted where (???) is inserted above.

7.1.6 The gateway sends a CPG with event indication that the call
      is being forwarded upon receipt of the 3xx message.

It's worth noting that a 3xx may contain Contacts that cannot be reached by
the gateway, e.g., a call may be redirected to an http URL.

7.2 The state diagram is missing the transition for T9 timer expiry (section
7.1.4)

7.2.1.1 However, if the destination number
   has been ported (see [x]) 

[x] needs to be replaced with a real reference.

in some
   ISUP variants includeD ANSI

"d" is missing in "included".

7.2.6.1 By default, the cause location associated with the CAI parameter
   should be encoded such 6xx codes are given the location 'user',
   whereas 4xx and 5xx codes are given a 'network' location.

I can't parse this sentence.

	483 Too many hoops

Should say "too many hops" (an extra "o" in hoops)

8.1 ...rather than substituting the
   'null' SDP used to put calls on hold (i.e. in which the c= line or
   port in the m= line indicates '0').

These are not the same! Only setting the connection address to 0.0.0.0 puts
the other party on hold.

8.2 This re-INVITE
   will have an SDP indicating that the originator of the re-INVITE no
   longer wishes to receive media.

Specifically, it will have c=0.0.0.0 in the SDP.

9.2.2 It would be nice to explain why reINVITE is sent and how it is formed
(a reference to 8.1 may be sufficient).

11. When the '+' sign is not present, but a telephone number is
   represented by the user portion of the URI, the SIP URI should
   contain the optional ';user=phone' parameter

I'd change "should contain" to "may contain". There is no guarantee
user=phone will be present in INVITES received from the SIP network.

pg.46:  should be appended unmodified to a
   'tel:+' string.

Or 'sip:+' string.

	Any non-standard or proprietary mechanisms used to
   communicate further context for the call in ISUP are outside the
   scope OF this document.

"of" is missing

	this information should be useD to populate the display-
   name portion of the From field.

"D" is missing in "used".

Thank you,
Igor Slepchin

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