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

From: Michael Hammer <[email-masked]>
Date: Mon, 24 Sep 2001 18:38:04 -0400

Quick question:

Under 4.1 below, does ignore mean drop the MIME bodies or propagate them 
forward?

Mike

At 06:05 PM 9/24/2001 -0400, Igor Slepchin wrote:
>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

_______________________________________________
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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Sep 2001 02:05:18 +0300

Hello,

> Under 4.1 below, does ignore mean drop the MIME bodies or propagate them

A proxy does not have to parse the message body, so we are speaking
about a UAS (that may be a pure SIP endpoint or a PSTN gateway).
Therefore, we mean that the MIME part is dropped.

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: Michael Hammer <[email-masked]>
Date: Tue, 25 Sep 2001 10:35:17 -0400

Gonzalo,

So you are saying that:

if there is a proxy in the network between two PSTN Gateways, it will not 
parse the body, but will propagate an ISUP MIME attachment forward; but,

if there is any B2BUA in the network between two PSTN Gateways, it will 
drop the ISUP MIME attached.

That could potentially create problems.  Does that rely on the assumption 
of a specific implementation?

Then, I assume, for completeness, that an experimental form of SDP or any 
other new MIME body part would also be dropped, if it is not recognized.

Mike

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 25 Sep 2001 19:09:27 +0300

Hello,

One of the good things of SIP is that proxies do not have to care about
message bodies. Therefore, I can build a SIP infrastructure for VoIP and
use it to provide any type of service. All I have to do is to use two
UAs that undestand a new session description format.

However, the implementation of B2BUAs break this rule. I do not really
like B2BUAs, by the way.

So, if you build your network using B2BUAs you better make sure that
they do not drop the message body containing ISUP messages.

One use of B2BUAs is to enforce policy. That is, I do not want SIP
messages in my network with ISUP bodies. My B2BUA will then drop the
ISUP bodies. The same applies if you do not want any new session
description mechanism in the SIP messages that traverse your network.

So, the conclusion is that whether or not dropping MIMEs is performed
depends on policy.

Regards,

Gonzalo

---

From: Michael Hammer <[email-masked]>
Date: Tue, 25 Sep 2001 14:50:01 -0400

Fair enough.  But, it sounds like policy mis-matches can then affect 
inter-operability.

Mike