Subject: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

From: "Jesske, R" <[email-masked]>
Date: Thu, 6 Jun 2002 13:50:22 +0200

Hello all,

 In <draft-ietf-sipping-isup-02>, §6.2.1.1.,
p.21 it is said:
 
 "When a SIP INVITE arrives at a PSTN gateway, the gateway should 
 attempt to make use of any encapsulated ISUP (see [4]) to assist in 
 the formulation of outbound PSTN signaling. However, three 
 conditions can complicate this process: 

 o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE 
 originated at a device other than an ISUP-SIP gateway. 
 
 o There is encapsulated ISUP, but the gateway cannot understand the 
 ISUP variant and therefore the ISUP must be discarded. 
 
 o There is encapsulated ISUP, but there is more recent session 
 context information available in the SIP headers, and consequently
 the SIP headers must 'overwrite' the encapsulated ISUP."

For me it is not clear what "'overwrite' the encapsulated ISUP" really means. Is it a overwriting of parameters within the ISUP -take the encapsulated ISUP message and update parameters regarding the SIP headers- or is it a overwriting of the whole message -map the whole SIP message to the ISUP Message e.g. INVITE --> IAM- ? 

Best Regards

Roland

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked]

_______________________________________________
Sipping mailing list  https://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: "Mark Watson" <[email-masked]>
Date: Fri, 7 Jun 2002 10:47:05 +0100

> 
> For me it is not clear what "'overwrite' the encapsulated 
> ISUP" really means. Is it a overwriting of parameters within 
> the ISUP -take the encapsulated ISUP message and update 
> parameters regarding the SIP headers- or is it a overwriting 
> of the whole message -map the whole SIP message to the ISUP 
> Message e.g. INVITE --> IAM- ? 
> 

In my view it is the former. Actually, it would be overwriting of the
individual indicators, rather then the whole parameter. For example if there
were some information in the SIP message which leads to a particular setting
of one of the Forward Call Indicators, then only that indicator should be
changed, the rest should be left as received in the encapsulated IAM.

The process on receipt of an INVITE should be first to obtain a 'template'
IAM to start off with. This 'template' is either a statically stored
default, or the IAM received in the INVITE.

Then the mapping procedures are used to map from information in the SIP
headers to ISUP information, overwriting each individual indicator which can
be mapped from SIP information.

The mapping procedures should be the same whether the initial 'template' IAM
was taken from the INVITE or from the static default.

...Mark

---

From: [email-masked]
Date: Fri, 7 Jun 2002 14:20:53 EDT

> was taken from the INVITE or from the static default.

Mike comments:

Going through this discussion and the latest draft-ietf-sipping-isup-02, I 
believe there is significant confusion between the two scenarios of operation 
mentioned in the draft for interworking between ISUP and SIP, when they can 
be used, and the interaction between them. From the draft, I get the 
following understanding of the two scenarios:

1. Encapsulation: ISUP messages are encapsulated unchanged into the body of 
the corresponding SIP messages. For example, IAM and all following SAMs are 
put into an INVITE for overlap. Absolutely no modification to the 
encapsulated fields from the ISUP message can occur inside the SIP network. 
This also requires that the originating and terminating points (gateways) 
understand the same variant of ISUP. (See RFC 3204 for details on format.)

2. Mapping (translation): Individual parameters of the ISUP messages are 
"mapped" into headers in SIP messages. For example, the called party number 
is mapped to a tel:url in the To-header and the Request-URI. The draft 
indicates that only some parameters are mapped and notes that Q.763 lists 29 
parameters in the IAM alone, and the draft states that "the problem of 
parameter-to-header mapping in SIP-T is confined more or less to the IAM and 
the INVITE". In fact, there must be appropriate mapping for every parameter, 
whether in the IAM or in other ISUP messages if this scenario is to be used 
to interwork between ISUP and SIP.

To see the difference between these scenarios, consider the case of the 
egress GW receiving a REL with either the cause code 1, unallocated number, 
or 3, no route to destination. With encapsulation, this cause code is sent 
back to the ingress GW which can forward the exact same cause code to the 
originator. In the case of mapping, the egress GW must map both of these 
cause codes to 404, not found. When the ingess GW gets the 404, it maps it to 
1, unallocated number. The information intended by the cause code 3 is lost.

There are a number of statements that imply that the Gateway may do both 
encapsulation and mapping when forming SIP messages from ISUP messages, and a 
proxy may then modify the headers that resulted from the mapping, thereby 
resulting in possibly conflicting information at the destination. The 
description in Section 6.2.1.1 concerning what the egress Gateway may do with 
encapsulated vs mapped information (including to "overwrite" some) indicates 
a serious problem with this approach. It should be obvious that all the 
combinations and exceptions would make it impossible to fully define the 
procedures.

It seems to me that there needs to be a basic clarification of the scenarios 
to be covered by "ISUP to SIP Mapping" and some clear architectural concept 
of how they are used. Section 3 provides two architectural scenarios (single 
MGC for ISUP to/from SIP and "SIP bridging"). Clearly, in the first case, 
encapsulation can not be done. But it is not clear whether in the second case 
both encapsulation and mapping can be done at the same time. It is unclear 
how the ingress Gateway would know which case applies.

Mike Pierce
Artel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 7 Jun 2002 14:36:15 -0400

Just on the issue of when the ingress gateway knows to use encapsulation:
if it does not know through configuration, I would suggest it try attaching
the content.  If at some point in the subsequent routing path it becomes
clear that the attached ISUP is inappropriate, a 606 Not Acceptable could be
returned.  The gateway could then resend without the ISUP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 07, 2002 2:21 PM
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

...Mark 

Mike comments: 

Going through this discussion and the latest draft-ietf-sipping-isup-02, I
believe there is significant confusion between the two scenarios of
operation mentioned in the draft for interworking between ISUP and SIP, when
they can be used, and the interaction between them. From the draft, I get
the following understanding of the two scenarios: 

To see the difference between these scenarios, consider the case of the
egress GW receiving a REL with either the cause code 1, unallocated number,
or 3, no route to destination. With encapsulation, this cause code is sent
back to the ingress GW which can forward the exact same cause code to the
originator. In the case of mapping, the egress GW must map both of these
cause codes to 404, not found. When the ingess GW gets the 404, it maps it
to 1, unallocated number. The information intended by the cause code 3 is
lost. 

There are a number of statements that imply that the Gateway may do both
encapsulation and mapping when forming SIP messages from ISUP messages, and
a proxy may then modify the headers that resulted from the mapping, thereby
resulting in possibly conflicting information at the destination. The
description in Section 6.2.1.1 concerning what the egress Gateway may do
with encapsulated vs mapped information (including to "overwrite" some)
indicates a serious problem with this approach. It should be obvious that
all the combinations and exceptions would make it impossible to fully define
the procedures. 

It seems to me that there needs to be a basic clarification of the scenarios
to be covered by "ISUP to SIP Mapping" and some clear architectural concept
of how they are used. Section 3 provides two architectural scenarios (single
MGC for ISUP to/from SIP and "SIP bridging"). Clearly, in the first case,
encapsulation can not be done. But it is not clear whether in the second
case both encapsulation and mapping can be done at the same time. It is
unclear how the ingress Gateway would know which case applies. 

Mike Pierce 
Artel

---

From: [email-masked]
Date: Sun, 9 Jun 2002 20:36:28 EDT

> returned.  The gateway could then resend without the ISUP.

All I can say is that this is not an acceptable way to do telephony! While an 
error return (e.g., 606) could occur in fault conditions such as incorrect 
configuration data (a human made a mistake), it should not be considered as 
the acceptable way to resolve situations in which the ingress gateway does 
not have enough info. Setup of sessions can not be by trial-and-error.

The point I'm trying to make in the comment is that the Gateway operation at 
the ingress should be independent of the configuration at the egress if we 
want flexible interworking. Which says that pure encapsulation of ISUP 
messages doesn't work unless one is dealing with a very specific case of 
"tunneling" through a SIP part to get between two ISUP parts. But in that 
case, I would not want SIP to do anything else, like "redirecting" the call. 
It is a pure point-to-point session with no fancy stuff.

That says there are two cases:

1. The ingress Gateway is doing "interworking" and maps all ISUP parameters 
into SIP headers (no encapsulation). Full SIP capabilities are possible.

2. The ingress Gateway set ups a session to a specific egress Gateway and 
encapsulates the ISUP messages in the SIP bodies. (No redirection, etc, in 
SIP)

Mike Pierce

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jun 2002 09:04:08 +0100

When my co-authors and I wrote draft-elwell-sipping-qsig2sip we wrestled
with exactly the same problem and came to a similar conclusion to Mike: keep
the two scenarios separate. Therefore this draft covers only interworking
between QSIG and SIP. Encapsulation (tunnelling) of QSIG over SIP is being
investigated separately, based on RFC3204.
-------------------------------------------------------------- 
John Elwell ([email-masked]) 
Siemens Communications Limited, 
Technology Drive, Beeston, 
Nottingham NG9 1LA, UK 
Tel: +44 115 943 4989   Fax: +44 115 943 4969 
-------------------------------------------------------------- 

	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the contents
of this message. Any views or opinions presented are solely those of the
author and do not necessarily represent those of Siemens Communications
Limited unless otherwise specifically stated.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10 June 2002 01:36
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

All I can say is that this is not an acceptable way to do telephony! While
an error return (e.g., 606) could occur in fault conditions such as
incorrect configuration data (a human made a mistake), it should not be
considered as the acceptable way to resolve situations in which the ingress
gateway does not have enough info. Setup of sessions can not be by
trial-and-error. 

Mike Pierce

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Jun 2002 10:53:51 +0100

Mike,
 
If all you are going to do with ISUP encapsulation is send messages directly
from one gateway to another, then you do not need SIP at all - you might as
well do something much simpler like send the ISUP over SCTP with an SDP
block tacked on the side (hmm, sounds a bit like BICC to me).
 
The point of ISUP encapsulation in SIP is that it allows calls from the ISUP
network to access services in the SIP network, including being routed to
real SIP endpoints, with the property that if the call *does* return to the
PSTN, then transparency of certain PSTN services can be maintained.
 
So, the ISUP to SIP and SIP to ISUP mapping task must take place at the
gateways independently of whether encapsulation is used. If there is a
conflict at the SIP->ISUP point between information derived from a mapping
and encapsulated information, then the mapped values take precedance.
 
This does mean that the ISUP to SIP gateway must have configuration
information as to where it can send encapsulated ISUP - it's actually very
similar to the Trust Domain model for Network Asserted Identity. The key
property of SIP nodes in this 'ISUP Trust Domain' is that they do not send
ISUP information outside the Trust Domain. This means that they *do* have to
recognise the Application/ISUP MIME body, but they *do not* have to actually
understand the ISUP message inside.
 
An important question, which we will be addressing in the SG11 work, is what
such a node should do when the message is to be routed outside the Trust
Domain: either remove the ISUP body and send the message on, or reject the
request with a cause which will make the gateway retry without ISUP.
 
I actually prefer the former, since serial forking in the SIP network may
mean that other endpoints have already been tried. In this case, dropping
back to the gateway would cause a retry of those earlier destinations.
 
Please note that the 'drop the ISUP' approach does NOT mean that ISUP
information is being sent to 'untrusted' nodes which do not understand what
ISUP is - rather the ISUP is removed *before* sending the message to such
nodes, but we make a distinction between 'understanding what ISUP is' and
'understanding the ISUP message itself'.
 
An additional consideration is that ISUP allows information to be marked as
'essential for the call' - i.e, the call should fail rather than discard
that information. Since it is the Gateway which actually understands the
ISUP message, I would suggest that the gateway mark the ISUP body
appropriately using the 'handling=required' (which I think is in the
Content-Disposition: header ?). Again, all tbd in the SG11 work.
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10 June 2002 01:36
To: Taylor, Tom-PT [CAR:B602:EXCH]; Watson, Mark [MDN05:EP10:EXCH];

Mike Pierce

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Jun 2002 16:24:57 -0400

If the first case meets your requirements, you can easily build a
gateway that doesn't even attempt ISUP encapsulation. My office
phone goes through such a node, and it works just fine.

If the second case meets your requirements, you want M3UA, not
SIP. You're in the wrong forum.

The document we wrote address a third scenario, which is (I beleive)
detailed clearly enough in the existing draft.

/a

-----Original Message-----

Mike Pierce

---

From: [email-masked]
Date: Mon, 10 Jun 2002 18:23:27 EDT

In a message dated 6/10/02 5:53:51 AM Eastern Daylight Time, 
[email-masked] writes:

> Mike,
>  
> If all you are going to do with ISUP encapsulation is send messages 
> directly from one gateway to another, then you do not need SIP at all - you 
> might as well do something much simpler like send the ISUP over SCTP with 
> 

I was presuming the case was one in which the session was needed to transfer 
media once the connection is set up. So it requires the basic functionality 
of SIP. (Yes, sounds like BICC.)

> PSTN, then transparency of certain PSTN services can be maintained.

I agree, but I'm suggesting that allowing things like redirection, forking, 
and other complex features in SIP would cause too many interactions at the 
egress GW.

> conflict at the SIP->ISUP point between information derived from a mapping 

Yes, I understood this would be the concept of interoperation between the 
mapping and the encapsulation. It's just that I believe that when all the 
combinations are considered, there will be an endless number of exceptions 
and special cases of "In such-and-such case, the encapsulated value takes 
precedence over the mapped value." Your last paragraph below could be one of 
those cases.

> ISUP information outside the Trust Domain. This means that they *do* have 
> to recognise the Application/ISUP MIME body, but they *do not* have to 
> actually understand the ISUP message inside.
>  
> An important question, which we will be addressing in the SG11 work, is 
> what such a node should do when the message is to be routed outside the 
> Trust Domain: either remove the ISUP body and send the message on, or 
> reject the request with a cause which will make the gateway retry without 
> 

I don't believe that "trial-and-error" should ever be the accepted procedure 
for call setup. If it doesn't work the first time due to this type of error, 
a human should be notified to fix the configuration data.

> nodes, but we make a distinction between 'understanding what ISUP is' and 

Not clear what the "trust" boundaries are here. Encapsulating ISUP requires 
that all Gateways make up a "trust" domain", since the ingress GW needs to 
trust the egress GW to discard parts of the ISUP (like caller identity info). 
On the other hand, I would certainly hope that the egress GW "trusts" the 
PSTN it is interworking to. I think of the egress GW as being a part of that 
destination network. The question of when/where to drop the ISUP is different 
from where the "trust" boundary is. There can be a boundary where one network 
"trusts" another for the exchange of ISUP, but not enough to protect the 
caller's privacy request. So if this boundary is in the egress GW, it must 
apply privacy based on the content of the original ISUP, not the "mapped" and 
potentially changed SIP parameters.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 10 Jun 2002 18:50:32 -0400

Mike, you shudder at the idea of "trial and error" in the routing of a call,
but this is totally consistent with the spirit of SIP.  Actually, it happens
in the PSTN too -- usually inside a switch, but sometimes, as with
crankback, between switches.  The only constraint is whether call setup
times get too long.

In this particular case, the entity that issues the 606 Not Acceptable for
appended ISUP has to be in the network, since it has to be an entity which
was trusted to receive ISUP.

I think when we enumerate the possibilities, the synchronization problem
won't be as bad as you fear.  Some ISUP information relates to the origin of
the call: that shouldn't change because of transit through another network.
Some information relates to the processing of the call en route to its
destination.  That information has to be updated as well as possible when
the call reaches a SIP-to-ISUP gateway.  Deficiencies in interworking will
be identified in SG 11 and either made good with further IETF work or
accepted.  Finally, some information relates to the destination of the call.
That information has to be updated with whatever the SIP network has
determined.  It doesn't really matter how many twists and turns the INVITE
takes through the SIP network.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 10, 2002 6:23 PM
To: Watson, Mark [MDN05:EP10:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Hogg,
Chris [MOP:MA01:EXCH]
Subject: Re: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

   Mike, 

   If all you are going to do with ISUP encapsulation is send messages
   directly from one gateway to another, then you do not need SIP at all
   - you might as well do something much simpler like send the ISUP over
   SCTP with an SDP block tacked on the side (hmm, sounds a bit like BICC to
me).

   The point of ISUP encapsulation in SIP is that it allows calls
   from the ISUP network to access services in the SIP network,
   including being routed to real SIP endpoints, with the property
   that if the call *does* return to the PSTN, then transparency
   of certain PSTN services can be maintained.

   So, the ISUP to SIP and SIP to ISUP mapping task must take place
   at the gateways independently of whether encapsulation is used.
   If there is a conflict at the SIP->ISUP point between information
   derived from a mapping and encapsulated information, then the mapped
   values take precedance.

   This does mean that the ISUP to SIP gateway must have configuration
   information as to where it can send encapsulated ISUP - it's
   actually very similar to the Trust Domain model for Network
   Asserted Identity. The key property of SIP nodes in this 'ISUP
   Trust Domain' is that they do not send ISUP information outside
   the Trust Domain. This means that they *do* have to recognise
   the Application/ISUP MIME body, but they *do not* have to actually
   understand the ISUP message inside. 

   An important question, which we will be addressing in the SG11 work,
   is what such a node should do when the message is to be routed
   outside the Trust Domain: either remove the ISUP body and send
   the message on, or reject the request with a cause which will
   make the gateway retry without ISUP.

   I actually prefer the former, since serial forking in the SIP
   network may mean that other endpoints have already been tried.
   In this case, dropping back to the gateway would cause a retry
   of those earlier destinations. 

   Please note that the 'drop the ISUP' approach does NOT mean that
   ISUP information is being sent to 'untrusted' nodes which do not
   understand what ISUP is - rather the ISUP is removed *before*
   sending the message to such nodes, but we make a distinction
   between 'understanding what ISUP is' and 'understanding the ISUP
   message itself'.

Not clear what the "trust" boundaries are here. Encapsulating ISUP requires
that all Gateways make up a "trust" domain", since the ingress GW needs to
trust the egress GW to discard parts of the ISUP (like caller identity
info). On the other hand, I would certainly hope that the egress GW "trusts"
the PSTN it is interworking to. I think of the egress GW as being a part of
that destination network. The question of when/where to drop the ISUP is
different from where the "trust" boundary is. There can be a boundary where
one network "trusts" another for the exchange of ISUP, but not enough to
protect the caller's privacy request. So if this boundary is in the egress
GW, it must apply privacy based on the content of the original ISUP, not the
"mapped" and potentially changed SIP parameters. 

   An additional consideration is that ISUP allows information
   to be marked as 'essential for the call' - i.e, the call should
   fail rather than discard that information. Since it is the Gateway
   which actually understands the ISUP message, I would suggest that
   the gateway mark the ISUP body appropriately using the 
   'handling=required' (which I think is in the Content-Disposition:
   header ?). Again, all tbd in the SG11 work. 

Regards...Mark

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 11 Jun 2002 07:31:17 +0200

Hi all
 
> -----Ursprüngliche Nachricht-----
> Von: Adam Roach [mailto:[email-masked]]
> Gesendet am: Montag, 10. Juni 2002 22:25
> An: [email-masked]'; [email-masked];
> [email-masked]; Jesske, Roland; [email-masked]
> Cc: [email-masked]; Adam Roach;
> [email-masked]; [email-masked]; Alexeitsev, Denis
> Betreff: RE: [Sipping] encapsulation of ISUP 
> draft-ietf-sipping-isup-01
> 
I think the second case is not a M3UA (normally M3UA is used to remote userparts at the SG, for a peer to peer case I would prefer M2PA) case. If I use M3UA (M2PA) to "transport" ISUP from the ingress to the egress Gateway, how can I control the Media Gateway? From my understanding there is no standardised mapping of ISUP and MEGACO/H.248 to control the Media Gateway.
One possible scenario for second case is to use it for interconnection between carriers (Service Provides) to give the trusted interconnection partner the possibility to terminate the traffic again into the PSTN or terminate within his own SIP network. The first partner don't know what the second want to do with the traffic, here we have the pure trunking case.

Best Regards 

Roland

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2002 03:31:34 -0500

A few notes on the comments below.
 
First of all, draft-ietf-sipping-isup-01 is not a complete solution for
SIP-ISUP mapping. It must be understood in the context of RFC3204 (the ISUP
MIME type) and draft-ietf-sipping-sipt-02 (the SIP-T framework document).
The SIP-T framework document actually defines the purpose of encapsulation
and translation, and motivates the need for using both.
draft-ietf-sipping-isup-01 details only message-level and header-level
mappings (essentially, the translation part).
 
The position of draft-ietf-sipping-sipt-02 is that a gateway that receives
an IAM performs both encapsulation and translation - there is no occasion
for a gateway to merely do one or another. Similarly, when a gateway
receives an INVITE, if the INVITE contains an RFC3204 body, the gateway
performs both encapsulation and translation. The characterization that there
is some fundamental gap in the overall architecture, or that this is an
unconsidered or untenable position, seems groundless to me. I don't think
there is any real problem with overwriting parameters in an encapsulated
ISUP message - the procedures for creating parameters based on SIP headers
(i.e. translation) are adequately defined in draft-ietf-sipping-isup-01, and
I think the document set is clear on how this should be applied.
 
Incidentally, there is no implied requirement in any of these documents that
the contents of an encapsulated ISUP signal will remain unmodified in the
SIP network (aside from the usual principle that intermediaries do not
modify the bodies of SIP messages). In fact, there is even a mention in
draft-ietf-sipping-sipt-02 of a case in which modifying encapsulated ISUP
would be meaningful.
 
Getting back to the subject of draft-ietf-sipping-isup-01 - the idea that
there needs to be a mapping for every ISUP parameter in every conceivable
ISUP message into SIP was considered very early in this work and rejected.
The purpose of SIP-ISUP mapping is not to create an analog in SIP for every
concept in ISUP, but rather to arrive at a mapping based on the appropriate
capabilites of the two protocols. The problem of parameter-to-header
SIP-ISUP mapping is largely confined to the IAM and the INVITE because the
headers that will be used throughout a SIP session are created (and for the
most part, set in stone) when the INVITE is created - modifying the To and
From headers after the initial INVITE could cause some SIP problems.
Obviously, cause code to response code mappings are detailed at some length
in the draft, and they are also an important part of the mapping.
 
The issue of whether or not the cause code to response code mappings are
symmetric is a separate issue - to date, we haven't seen a lot of value in
symmetry there, but I do think that's an interesting subject for discussion.
I doubt that ISUP encapsulation is the solution to that problem, anyway.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 07, 2002 11:21 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];

...Mark 

Mike comments: 

Mike Pierce 
Artel

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 12 Jun 2002 10:53:53 +0100

Jon,
 
This issue with passing ISUP outside the 'Trust Domain' is slightly
different from the identity problem. Yes, there are the same privacy
concerns, since the ISUP contains 'private' information, and these could be
addressed with cryptography, but there is also the criticality question.
 
The ISUP can contain 'critical' information which MUST be correctly
processed or the call rejected. So, the node sending encapsulated ISUP MUST
have some way of knowing that the next node will follow certain procedures
with respect to the ISUP (namely: ensure that it is processed, or reject the
call).
 
This 'knowledge that the next node will definately follow a certain
procedure' takes us into Trust Domain territory. The assumption of
'trustability' for subsequent nodes is so embedded in ISUP, that I'm not
sure we can dispence with it for SIP-T.
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 12 June 2002 09:34
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]'; Taylor, Tom-PT
[CAR:B602:EXCH]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Peterson, Jon;
[email-masked]; [email-masked]; Hogg, Chris [MOP:MA01:EXCH]
Subject: RE: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

Just one comment here, on the matter of sending SIP messages containing
encapsulated ISUP outside of the 'ISUP Trust Domain' (now there's a
terrifying concept).
 
As far as I know there has been no restriction of scope in the SIP-T work
that precludes the development of some mechanism for withholding ISUP from
inappropriate destinations, which you identify below as the purview of SG11.
In fact, draft-ietf-sipping-sipt-02 already speaks to this issue, and
specifically to the use of S/MIME encryption of ISUP bodies as the most
appropriate solution.
 
I can suddenly foresee a conversation that would closely mirror the
short-term vs. long-term identity debates. This problem is trivially solved
with cryptography, but could also be solved with an elaborate trust-based
scheme. However, I have a feeling that the reasons that cryptography seemed
inappropriate to the short-term identity work will not apply to ISUP mapping
- I'm not so sure that we need to develop a similar 'Trust Domain' concept
here.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, June 10, 2002 2:54 AM
To: [email-masked]'; Tom-PT Taylor; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Chris
Hogg
Subject: RE: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

Mike,

 

 

 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10 June 2002 01:36
To: Taylor, Tom-PT [CAR:B602:EXCH]; Watson, Mark [MDN05:EP10:EXCH];

Mike Pierce

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2002 03:34:09 -0500

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, June 10, 2002 2:54 AM
To: [email-masked]'; Tom-PT Taylor; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];

Mike,

 

 

 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10 June 2002 01:36
To: Taylor, Tom-PT [CAR:B602:EXCH]; Watson, Mark [MDN05:EP10:EXCH];

Mike Pierce

---

From: [email-masked]
Date: Wed, 12 Jun 2002 12:12:55 EDT

> draft-ietf-sipping-isup-01 details only message-level and header-level 

[MAP] I understand this, so the SIP-ISUP mapping draft should only talk about 
mapping.

> performs both encapsulation and translation. The characterization that 
> there is some fundamental gap in the overall architecture, or that this is 
> an unconsidered or untenable position, seems groundless to me. I don't 
> think there is any real problem with overwriting parameters in an 
> encapsulated ISUP message - the procedures for creating parameters based on 
> SIP headers (i.e. translation) are adequately defined in 
> draft-ietf-sipping-isup-01, and I think the document set is clear on how 
> this should be applied.
>  
> Incidentally, there is no implied requirement in any of these documents 
> that the contents of an encapsulated ISUP signal will remain unmodified in 
> the SIP network (aside from the usual principle that intermediaries do not 

[MAP] This is one of the "gaps". Either modification of the encpasulated ISUP 
is allowed or it is not. There must be a firm decision on this before going 
any further with the idea. I would like to see a concrete, unchangeable 
statement on this.

> symmetry there, but I do think that's an interesting subject for 
> discussion. I doubt that ISUP encapsulation is the solution to that 
> problem, anyway.

[MAP] It seems to me that there is still a question of why mapping is done 
and what purpose it serves. If it is to allow service interworking between 
the ISUP and the SIP part of the overall connection, then mapping will have 
to be defined for every capability that is supported in some way in both 
networks. That means that the draft starts out with a small set, and every 
time something new is defined in SIP which is in ISUP, the mapping with ISUP 
needs to be defined to allow service interworking between the two. Mapping of 
Cause codes to/from response codes is one of these issues. It needs to be 
complete so that no value is lost.

On the other hand, if the purpose is to allow "tunneling" through SIP between 
two specific, preconfidured Gateways, then it is known upfront that ISUP 
doens't have to interwork with a lot of other SIP capabilities. In this case, 
only some of the SIP specific cause codes need to be sent back to the 
originating party (mapped to some equivalent ISUP value).

I don't think the second case is what the SIP group wants, but it seems to be 
what the mapping draft does.

---

From: [email-masked]
Date: Wed, 12 Jun 2002 12:12:12 EDT

> crankback, between switches.  The only constraint is whether call setup

Yes, we do "crank-back", but its purpose to to efficiently reroute a call 
which encountered a specific transient condition such as all-trunks-busy or a 
destination subscriber service asking for a reroute. The description here for 
encapsulation sounds more like the result of a permanent condition caused by 
wrong configuration data in a gateway. I'm not concerned with what happens 
"inside a switch".

Mike Pierce

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2002 12:21:03 -0500

I am sensitive to your concerns about the goals of
draft-ietf-sipping-isup-0x. Like many other old documents (the original -00
of this document predates the IETF SIP WG, to give some idea of its age), we
had an original motivating problem set and then years of development and
comment that got us where we are. This isn't to be dismissive about scope
concerns - just because we've been doing it this way for so long that
doesn't mean we're right. But it does mean that we've encountered several
progressive waves of ISUP-oriented engineers who have become interested in
SIP, eventually found the SIP-T work and provided comments one way or
another - while there may be new arguments for adopting certain mapping
strategies, it's pretty unlikely at this point that we'll hear any new
strategies.
 
The purpose of SIP-T is to provide an ISUP protocol mapping that it easy to
implement but which nevertheless grants a reasonable amount of feature
richness. The process described in RFC3204 is a great example of the sort of
short-cuts we took - it provides a way that all parameters that are of
interest only to the ISUP world will be carried end-to-end through a SIP
network at virtually no cost to gateways. The parameter-to-header mappings
(with the exception of cause code mapping) focused only on those ISUP
parameters that seemed as if they would affect how calls would be routed in
the SIP world. These are both, I think, reasonable scopes for the respective
documents. In fact, the practices described in these documents have been
fairly widely implemented (judging from the amount of mail I get from
gateway vendors about these documents). SIP-T provides a way of bridging SIP
and ISUP that can be realistically implemented today. Your argument below
that we must choose one of two impossible extremes - either specifying
enough minutiae that we eventually turn SIP into ISUP, or saying that there
is no feature mapping whatsoever so we might as well use BICC - is unfounded
defeatism. The practices we've documented have already proven useful in the
field - not perfect, but useful.
 
Now that much said, one could argue that after draft-ietf-sipping-isup-0x
has been published as an RFC, we will continue to define features in SIP
that introduce new opportunities for mapping and parallelism with ISUP.
Totally agree - we already know of a bunch of these (consider the privacy
draft and ISUP presentation restriction, or some of the new tel URL
functionality). That however is no reason to block
draft-ietf-sipping-isup-0x, I think. This document will become a Proposal
Standard, but it will continue to evolve beyond that (in bis's, on the way
to another PS or, dare I dream, a Draft) - PS is not the conclusion of an
IETF document's life cycle. I for one believe that it is worth capturing the
work we've done so far in an RFC, even if we know that there will be more
mapping to do as SIP evolves.
 
So, I think the document set already has a reasonable scope (all of this
business about the scope of encapsulation and translation is described,
again, in draft-ietf-sipping-sipt-02). Although sipt-02 is past IETF LC,
there are still a number of comments that I need to integrate, so this would
be a good time to comment on it. However, it isn't terribly to useful to
make comments along the lines of 'either modifying encapsulated ISUP should
be allowed or not'. Clearly, it is allowed in draft-ietf-sipping-sipt-02 -
to make a pretty firm statement. Is there any reason you think it should or
should not be allowed? Any potential applications of modifying encapsulated
ISUP that make SIP-T seem better or worse to you?
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 9:13 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sipping] encapsulation of ISUP draft-ietf-sipping-isup-01

[MAP] I understand this, so the SIP-ISUP mapping draft should only talk
about mapping. 

[MAP] This is one of the "gaps". Either modification of the encpasulated
ISUP is allowed or it is not. There must be a firm decision on this before
going any further with the idea. I would like to see a concrete,
unchangeable statement on this. 

[MAP] It seems to me that there is still a question of why mapping is done
and what purpose it serves. If it is to allow service interworking between
the ISUP and the SIP part of the overall connection, then mapping will have
to be defined for every capability that is supported in some way in both
networks. That means that the draft starts out with a small set, and every
time something new is defined in SIP which is in ISUP, the mapping with ISUP
needs to be defined to allow service interworking between the two. Mapping
of Cause codes to/from response codes is one of these issues. It needs to be
complete so that no value is lost. 

On the other hand, if the purpose is to allow "tunneling" through SIP
between two specific, preconfidured Gateways, then it is known upfront that
ISUP doens't have to interwork with a lot of other SIP capabilities. In this
case, only some of the SIP specific cause codes need to be sent back to the
originating party (mapped to some equivalent ISUP value). 

I don't think the second case is what the SIP group wants, but it seems to
be what the mapping draft does. 

Jon Peterson 
NeuStar, Inc.

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 12 Jun 2002 14:38:35 +0100

Alan,

I would agree too that SIP-T solves the ISUP problem as far as it can be
solved.

One of the interesting applications of SIP-T that I see is that an operator
can deploy a SIP-based service infrastructure (perhaps some kind of
intelligent routing services) and offer those services to both SIP users and
PSTN users whilst maintaining service transparency for both SIP endpoint to
SIP endpoint and PSTN endpoint to PSTN endpoint calls. SIP to/from PSTN
calls get whatever the common set of interworked services is.

The model still works if some of the SIP-SIP services or some of the
PSTN-PSTN services are 'critical' - the call will just fail if it ends up
being routed to an endpoint of a different type, precisely because the
requested critical service could not be fulfilled.

Regards,

Mark

> From: Alan Johnston [mailto:[email-masked]]
> Sent: 12 June 2002 13:57
> To: Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; [email-masked];
> Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; [email-masked]
> Mark,
> You are trying to use SIP to fix the design flaws of ISUP, an exercise
> in futility.  ISUP, and hence SIP-T which uses ISUP, can not 
> be used in
> a global, scalable fashion in the way that SIP can.
> 
> I agree with Jon - SIP-T solves the ISUP problems as far as it can be
> solved, but it is not perfect due to the limitations of the ISUP trust
> model.
> 
> If the ISUP contains "critical" information that somehow does 
> not map to
> SIP (?) then just use SIGTRAN (or TCP) - don't bother with SIP as you
> are not using any of its features or its power.
> 
> Thanks,
> Alan Johnston
> WorldCom
> sip:[email-masked]
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Watson
> Sent: Wednesday, June 12, 2002 4:54 AM
> To: 'Peterson, Jon'; [email-masked]'; Tom-PT Taylor;
> [email-masked]; [email-masked]; Chris Hogg
> concerns, since the ISUP contains 'private' information, and 
> these could
> be addressed with cryptography, but there is also the criticality
> question.
> 
> processed or the call rejected. So, the node sending encapsulated ISUP
> MUST have some way of knowing that the next node will follow certain
> procedures with respect to the ISUP (namely: ensure that it is
> processed, or reject the call).
> 
> Peterson, Jon;
> As far as I know there has been no restriction of scope in the SIP-T
> work that precludes the development of some mechanism for withholding
> ISUP from inappropriate destinations, which you identify below as the
> purview of SG11. In fact, draft-ietf-sipping-sipt-02 already speaks to
> this issue, and specifically to the use of S/MIME encryption of ISUP
> bodies as the most appropriate solution.
> 
> short-term vs. long-term identity debates. This problem is trivially
> solved with cryptography, but could also be solved with an elaborate
> trust-based scheme. However, I have a feeling that the reasons that
> cryptography seemed inappropriate to the short-term identity work will
> not apply to ISUP mapping - I'm not so sure that we need to develop a
> similar 'Trust Domain' concept here.
> 
> Jon Peterson
> NeuStar, Inc.
> [email-masked]; [email-masked]; [email-masked];
> Chris Hogg
> directly from one gateway to another, then you do not need 
> SIP at all -
> you might as well do something much simpler like send the 
> ISUP over SCTP
> with an SDP block tacked on the side (hmm, sounds a bit like BICC to
> me).
> 
> The point of ISUP encapsulation in SIP is that it allows 
> calls from the
> ISUP network to access services in the SIP network, including being
> routed to real SIP endpoints, with the property that if the 
> call *does*
> return to the PSTN, then transparency of certain PSTN services can be
> maintained.
> 
> conflict at the SIP->ISUP point between information derived from a
> mapping and encapsulated information, then the mapped values take
> precedance.
> 
> information as to where it can send encapsulated ISUP - it's actually
> very similar to the Trust Domain model for Network Asserted Identity.
> The key property of SIP nodes in this 'ISUP Trust Domain' is that they
> do not send ISUP information outside the Trust Domain. This means that
> they *do* have to recognise the Application/ISUP MIME body, 
> but they *do
> not* have to actually understand the ISUP message inside.
> 
> reject the request with a cause which will make the gateway retry
> without ISUP.
> 
> I actually prefer the former, since serial forking in the SIP network
> may mean that other endpoints have already been tried. In this case,
> dropping back to the gateway would cause a retry of those earlier
> destinations.
> 
> information is being sent to 'untrusted' nodes which do not understand
> what ISUP is - rather the ISUP is removed *before* sending the message
> to such nodes, but we make a distinction between 'understanding what
> ISUP is' and 'understanding the ISUP message itself'.
> 
> to be marked
> as 'essential for the call' - i.e, the call should fail rather than
> discard that information. Since it is the Gateway which actually
> understands the ISUP message, I would suggest that the 
> gateway mark the
> ISUP body appropriately using the 'handling=required' (which 
> I think is
> in the Content-Disposition: header ?). Again, all tbd in the 
> SG11 work.
> 
> Regards...Mark
> All I can say is that this is not an acceptable way to do telephony!
> While an error return (e.g., 606) could occur in fault conditions such
> as incorrect configuration data (a human made a mistake), it 
> should not
> be considered as the acceptable way to resolve situations in which the
> ingress gateway does not have enough info. Setup of sessions 
> can not be
> by trial-and-error. 
> 
> The point I'm trying to make in the comment is that the Gateway
> operation at the ingress should be independent of the configuration at
> the egress if we want flexible interworking. Which says that pure
> encapsulation of ISUP messages doesn't work unless one is 
> dealing with a
> very specific case of "tunneling" through a SIP part to get 
> between two
> ISUP parts. But in that case, I would not want SIP to do 
> anything else,
> like "redirecting" the call. It is a pure point-to-point 
> session with no
> fancy stuff. 
> 
> 1. The ingress Gateway is doing "interworking" and maps all ISUP
> parameters into SIP headers (no encapsulation). Full SIP capabilities
> are possible. 
> 
> 2. The ingress Gateway set ups a session to a specific egress Gateway
> and encapsulates the ISUP messages in the SIP bodies. (No redirection,
> etc, in SIP) 
> 
> Mike Pierce 
> 
>