Subject: [SIP] draft-jfp-sip-isup-header-00.txt - comments and questions

From: Jean-Francois Mule <[email-masked]>
Date: Thu, 15 Mar 2001 19:26:02 -0800

Hi,
As you may know, we're trying to work on sip-t testing in the ISC SIP
WG.  Find below my own personal comments on your draft re: IAM-INVITE
header mapping.  I also include some questions the group has come
across;  I would appreciate your input on those.

Also, as you publish new or updated drafts in IETF on this topic (sip-t,
isup-mime, etc.), we would appreciate if you could forward the ID
announcement to the [email-masked]...

Best regards,
Jean-Francois Mule
------------------
- naming of the sip-t gateway:
in the isc terminology, we proposed to call this beast sip-t Functional
Grouping as it mainly refers to the functional entity responsible for
the sip legs and it can be composed of MG+MGC+SG.  What do you think
about using the same terminology in your draft?  sip-t FG rather than
sip-t GW?

- section 1, paragraph 3:
   "Hence, the problem of parameter-to-header mapping in SIP- T is
confined more or less to the IAM and the INVITE."
The case of call release seems to be forgotten as a mapping issue (BYE
reason header?).

- section 2 - page 2:
   "The most common format used in SIP for the representation of
   telephone numbers is the tel URL, defined in [2806]. "
Based on draft-ietf-sip-call-flows-03.txt, page 6 and based on my
experience with sip gw testing, I would strongly disagree with that
statement.  The advantage of using sip urls is that they are understood
and routable the sip cloud.  Many gw vendors today use the sip url in
the To:, From: and requestURI; it is the format sip:+e164@host, isn't?
In any case, and you state it on page 3, the sip-t header draft should
allow both and the mapping of phone numbers should be independent from
where you get the e164 in the sip msg.

- section 2 - page 3:
  "A gateway should accept either tel or SIP URIs from its peers."
  this requirement should specify "A SIP-T gw" or a "SIP-T FG"
  another interesting question is not what the gw should be able to
accept from its peers but what the gw should send to its peers?  this
may impose requirements on proxy and other sip entities in the network.

- questions on what msgs should be carried over the sip network:
Even though i understand the draft only deals with IAM-INVITE in its
current version, several isup msgs have some importance for the sip
cloud.  For e.g., circuit blocking BLO or other maintenance oriented
msg:  when a circuit is blocked for subsequent calls, the sip-t FG may
want to warn the SIP proxy that calls cannot be routed to it (sometimes
it may just be able to handle it at the FG gw level):  are any of these
options bad?  should the sip-t FG wait to receive calls it cannot handle
to respond with a 4xx....
Another question has to do with the sip INFO: what ISUP msgs would you
consider to map to INFO?

- editorial comment:
in the copyright statement, it should be 2001

_______________________________________________
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: [email-masked]
Date: Fri, 16 Mar 2001 00:00:25 -0700

Some comments below, marked up with <JFP>. I've pasted the stray comment
from your second mail onto the bottom.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 8:26 PM
To: Peterson, Jon; [email-masked]
Cc: [email-masked]
Subject: draft-jfp-sip-isup-header-00.txt - comments and questions

Hi,

<JFP> We'll try to do just that. </JFP>

Best regards,
Jean-Francois Mule
------------------

<JFP> If it seems the term is gaining traction then it could possibly be
adopted later. There are many more specific synonyms for gateways or their
logical components (MGCs, Call Agents, Softswitches, etc) which are used in
certain communities but which did not seem necessarily to be the best choice
for this document. 'Gateway' is pretty neutral. </JFP>

<JFP> As the document says, and as Venkatesh pointed out, this problem is
covered in a different draft (namely the Roach/Camarillo document). </JFP>

- section 2 - page 2:

<JFP> I don't find the cited assertion controversial, especially in light of
the fact that the user portion of a SIP URI can be a tel URL. </JFP>

- section 2 - page 3:

<JFP> Again, I'm not sure I'm ready to adopt your nomenclature. The reasons
why a SIP URI or tel URL might be sent by a particular entity are recorded
in the document (namely, it seems to be an administrative decision). I don't
see any immediate need for this to be mandated by the standard. Personally,
I'd like to see configurable gateways which could generate either. </JFP>

<JFP> Firstly, our document does indeed focus on parameter-to-header mapping
rather than message-to-message mapping. But moreover I disagree strongly
with the contention that circuit maintenance messages should be translated
into SIP. The receipt of a BLO, for example, indicates that a single TCIC
(possibly among thousands) is blocked, and therefore any SIP proxy that
happens to be in the network probably shouldn't take its cues from the
receipt of a BLO. If information about the number of available circuits at a
gateway needs to be fed to a proxy server, then I would recommend using
intradomain TRIP (which has CircuitCapacity attributes, etc), rather than
sending a SIP message every time a BLO arrives. Clearly, BLO does not
indicate that some sort of session is taking place, nor does it occur during
the lifetime of an existing session. There are some things one shouldn't do
with SIP. 

On the INFO matter, well, there have been a number of threads lately about
the use of INFO for overlap dialing, INFO before 200 OK, etc. Personally, I
think there are many ISUP messages which do not require encapsulated
transmission over a SIP network (such as circuit maintenance messages) since
their usage does not work towards the preservation of feature transparency.
So I would reserve INFO for a very limited set of messages; INR and INF come
to mind, and maybe there are a few others.
</JFP>

- editorial comment:

<JFP> Thanks, noted. </JFP>

Another comment:
this draft seems to make a recommendation on how to translate the
presentation indicators into the sip From: address of record at the
far-end gateway only.  It is not clear however, how the indicators are
propagated along the sip entity chain, from the sip ua originating the
session to the far end, passing by multiple sip proxies...
Indeed, within the calling party's domain, some sip proxies may make use
of the ANI or A number to apply some routing rules...
Is this specified somewhere?

<JFP> Well, I agree this is a problem; the problem is that the calling-party
information must be secured from untrusted hosts and presented to trusted
hosts. When your network is a mixture of the two (which is the SIP-T
assumption) then you pretty much have to cater to the lowest common
denominator. Encapsulated ISUP (which should be encrypted to prevent
inspection by untrusted hosts) could be accessed for routing information by
any privileged entity determined enough to parse ISUP - a function that
admittedly one wouldn't commonly ascribe to proxies. 

Working on the assumption that some non-ISUP MIME mechanism is needed, I
have some small aversion to proposing a whole separate header to carry the
actual calling party's number, especially since this header would also have
to be encrypted to prevent a privacy breach. Maybe a subfield of the From
header is the right approach. This issue has certainly proven to be a
subject of some debate; any thoughts about this?</JFP>