Subject: RE: [Sipping] FW: Communication re: SIP - BICC/ISUP Interworking

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 21 Jul 2002 06:10:12 -0400

I agree that it is a policy decision at the gateway.  It really depends on
the service agreement between the gateway operator and the SIP network
operator.  If the gateway operator knows that the SIP network will withhold
the actual media address until the 200 OK, the gateway can cut through the
connection before that point.  This makes an awful lot of assumptions on the
SIP network (e.g. B2BUA), so I think we are stuck with the SG 11 assumption
as a general rule.  What distresses me is that this precludes any
announcements or other early media from the SIP network itself.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 10:40 AM
...
Subject: Re: [Sipping] FW: Communication re: SIP - BICC/ISUP
Interworking

[snip]

> 3.	Cut through in the backward direction for tones and announcements
> from the SIP network can be misused as there is a bearer path 
> potentially
> available from the user equipment without charging.  (The called UA 
> could
> send back a 180 Ringing, then send back its own media without bothering 
> to
> send a 200 OK INVITE.)  We are currently taking a conservative approach 
> and
> not cutting through until answer.  This is an issue of whether the SIP
> network can be trusted.
The PSTN allows this functionality today.  Whether the PSTN GW allows 
bidirectional early media, and how it records this request for 
accounting purposes seem like a policy decision on the gateway.

thanks,
-rohan

> [snip]
> Due to the lack of the meeting time, ITU wasn't able to make a complete
> review of the IETF interworking document. It was agreed that comments
> regarding this interworking document would be made directly by the
> individual experts and forward it to the IETF lists.
>
> The SG 11 BICC group looks forward to further communications as this 
> study
> progresses.
>
>
> Tom Taylor
> [email-masked]
> Ph. +1 613 736 0961 (ESN 396 1490)
>
>
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Jul 2002 19:45:16 -0400

A few notes inline below, some of which merely reinforce what has already
been said on this mailing list.

Jon Peterson
NeuStar, Inc.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, July 15, 2002 5:15 PM
> To: [email-masked]'
> Subject: [Sipping] FW: Communication re: SIP - BICC/ISUP Interworking
> 
[snip]
> 
> 1.	The use of ISUP Timer T10 for SIP procedures in
> draft-ietf-sipping-overlap-00.txt is questionable, because this timer is
> part of the state machine on the ISUP side of the interworking point and
> using it might have unintended consequences.  It is recommended that a
timer
> be defined specific to the interworking process instead. 
> 

I'm not sure I really understand this point. We aren't asking for a new
timer that has the same properties as T10 but is used for SIP interworking -
we're asking that the timer that is used to convert overlap to en-bloc
signaling be employed in ISUP prior to the commencement of the interworking
process with SIP. I believe that is amply substantiated in our call flows.
Is there some grave peril that this invites?

In any event, I see no reason that we couldn't clarify this in the text if
there is some material motivation.

> 2.	The mapping of FCI and BCI within the IETF draft
> draft-ietf-sipping-isup-02.txt is different from what the SG11 experts
have
> seen proper to use within Q.1912.SIP.  The setting of the FCI in the
> interworking case (INVITE - IAM) is "no end-to-end method available,
> interworking encountered, ISDN not used all the way, originating access
> non-ISDN". The Setting of the BCI in the interworking Case (180-ACM) is
"no
> end-to-end method available, interworking encountered, ISDN not used all
the
> way, originating access non-ISDN". In the SIP-T case the FCI and BCI will
be
> taken from the encapsulated ISUP.  It is not yet clear how to set the FCI
> and BCI if there is some updating of the received ISUP message using the
> contents of the SIP header mapping. 
> 

Yes, we had gotten this comment before (perhaps individually from the
aforementioned SG11 experts). We agree, essentially, and the final version
of draft-ietf-sipping-isup should reflect that.

On an academic point, we would appreciate some advice on how it is expected
that the presence of interworking indicators would affect call processing,
feature invocation and so forth. To date we have not been able to ascertain
whether or not setting the interworking bits will prevent the operation of
any features. It would be a shame if this unnecessarily impeded network
operation somehow.

> from the SIP network can be misused as there is a bearer path potentially
> available from the user equipment without charging.  (The called UA could
> send back a 180 Ringing, then send back its own media without bothering to
and
> not cutting through until answer.  This is an issue of whether the SIP

And presumably a similar risk does not exist for ISDN terminals? That
arbitray backwards media will be transmitted from an ISDN terminal after an
PROGRESS or other message has been sent to an ISDN-ISUP interworking point?
I don't see how the risks are any greater here. Is there are a similar
restriction on the interworking of ISDN and ISUP in Q.699?

I have even heard rumor that some national ISUP variants already support
cases more degenerate than this from a fraud perspective (for example, that
it is possible for even the forward media path to be cut through before ANM
at the behest of an ISDN terminal for some IVR applications).

All that said, I have no objection to detailing your recommendation as an
alternative behavior for gateways in the draft. I still believe that cutting
through backward media when a 183 is received is legitimate in many cases
(perhaps an operator could simply put a timer of some arbitrary, short
length on the gateway to combat fraud), but the point in signaling (ACM or
some CPG or ANM) at which a gateway cuts through the backward media path
could be a matter of operator policy.

There are no doubt numerous issues that might arise on the subject of
whether or not a SIP network can be "trusted". One of the things that
differentiates the SIP-T approach from, say, BICC is the fact that SIP
requests can reach terminals that are controlled by end-users. I personally
consider this to be the main strength of SIP-T, but to some it will
certainly appear to be a nuisance.

> 4.	Regarding the SIP Status Code to ISDN Cause Code Mapping, some
> changes to your proposed mappings will be integrated in the ITU
Q.1912.SIP.
> The final mapping will be decided at the next meeting in Ottawa.  We have
> simplified the mappings a bit because the ISUP/BICC network won't be able
to
> make good use of the information.  The general rule is that
> non-service-related responses will be mapped to "interworking,
non-specific"
> unless the alternative is obvious.
> 

This has been a source of endless controversy in the IETF - I don't expect
it will be easy in any forum to achieve consensus about which mappings are
appropriate. We have elected to err on the side of providing information
about why failures have occurred. To me, the "Interworking" cause code
signifies that an error has occurred in a network that is unable to express
why the error has occurred, like a legacy MF network. Surely we can do
better than that in a SIP network in many cases, and consequently make life
easier for network operators trying to debug exceptional conditions.

> individual experts and forward it to the IETF lists.

Great, we'll look forward to that.

> The SG 11 BICC group looks forward to further communications as this study
> progresses. 
> 
> 
> Tom Taylor

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 25 Jul 2002 13:45:55 +0100

Jon, all,

You asked how the FCI/BCI setting would affect services. Setting FCI in the
IAM to 'interworking encountered' and/or 'originating access non-ISDN' will
(in principle) cause the terminating exchange to assume that only the PSTN
service set is available for the call.

Now, in practice, in terms of documented effects of this assumption, things
are not 100% clear. However, based on my experience, it would be safe to
assume that at least some terminating exchanges will not allow any ISDN
services to operate if these indicators are recieved.

Something which is documented is that the 'non-ISDN' nature of the call is
communicated to the terminating ISDN terminal/PBX, and again may affect the
services that this terminal/PBX allows on the call.

An explicit example is the fallback procedures for the 7kHz telephony
service. These only work if the call is indicated as end-to-end ISDN.

The argument in the SIP/ISUP draft that the SIP network should be considered
as equivalent capability to ISDN seemed reasonable to me. When the
'interworking encountered' bit was defined it meant interworking with a
pre-SS7 system. I don't think it's reasonable to consider SIP as a pre-SS7
system.

One important point is that on an ISUP to SIP to ISUP call, these indicators
do NOT tell you anything about the complete end-to-end status of the call.
It is entirely possible that the first ISUP leg is non-ISDN and the second
is considered ISDN. It is the responsibility of the two interworking points
to map ISUP (non-ISDN) to SIP and SIP to ISUP (ISDN) respectively.

I believe the existing text in the ISUP mapping draft contains some
discussion and concludes that the indicators be set 'appropriately'. I would
not favour modification of this to specify 'non-ISDN'. This would
effectively limit the interworking to the PSTN service set. I for one would
like to see services such as videotelephony interworkable.

Secondly, on cut-through, I support your comments. Q.931 Annex K allows for
ISDN users to be given the ability to provide backwards tones/announcements
themselves. I would imagine that it is a matter of operator policy to whom
this ability is offered. I guess it is a term of interconnect agreements
that operators do not offer this capability to 'just anyone', since at the
interworking point, the originating network has no idea whether the
backwards tones it is receiving come from the network or from an ISDN end
user.

So, it nust be a policy matter at an interworking point whether the
subsequent network is 'trusted' to provide backwards media before answer or
not. I think in the SG11 'policy' model, this is something which is handled
by the SIP side of the interworking device i.e. it decides based on it's own
policy whether to accept an offer of Early Media from the SIP endpoint or
not. If it accepts, then we need interworking procedures to handle this.

Obviously, the above does not align with the SG11 position in the
communication.

...Mark

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 25 July 2002 00:45
> To: [email-masked]'
> Cc: Taylor, Tom-PT [CAR:B602:EXCH]
> Subject: RE: [Sipping] FW: Communication re: SIP - BICC/ISUP
> Interworking
> 
> 
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 26 Jul 2002 03:02:31 -0400

Thanks, Jon.  I've forwarded this response back to the SG 11 discussion
list.  I have a few quick responses inline to help things along.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 7:45 PM
To: [email-masked]'
Cc: Taylor, Tom-PT [CAR:B602:EXCH]
Subject: RE: [Sipping] FW: Communication re: SIP - BICC/ISUP
Interworking

Jon Peterson
NeuStar, Inc.

[snip]
timer

[PTT] My suggestion is to phrase things like this:  when ISUP procedures
determine that digits should be forwarded, you  go ahead and send the
INVITE.  One way ISUP procedures come to this conclusion is as a result of
expiry of ISUP timer T10.  By phrasing things this way you make it clear
that T10 is an ISUP-side thing, not something that has been coopted into the
SIP state machine.

have
"no
the
be

[PTT] People's researches so far have revealed one feature that won't work
as a result: 7 khz audio with fallback to speech.  A calling ISDN terminal
will conclude as a result of the "not ISDN all the way" indication that 7
khz speech isn't supported.  Given that the IP network can happily handle
the G.722 codec, this is a bit of a misunderstanding.  We'll have to figure
out how to sort things out.

and

[PTT] I've no further comment on this one myself.  I'll be interested to see
if the SG 11 people have comments on your answer.

Q.1912.SIP.
to
non-specific"

---

From: David Oliver <[email-masked]>
Date: Mon, 29 Jul 2002 16:07:47 -0500

Mike,

I agree that this is intimately connected to the concept of voice (phone
like) calls, and that early backward.

The original (A.G. Bell) model allowed for two way communication between the
phone user and the phone "system" - local and possibly long distance
operators - using the 10 cps. bell crank and voice. (Incidentally, hand
crank phones still work - cranking the phone "dials" 0, 10 or more pulses,
and summons the operator!) This continued until full cut-through, i.e. the
line is seized at both ends by the users' phones being off hook. End-to-end
communication and billing time thus coincided. All communications  was
performed on the voice connection eventually used to complete the call.

With the advent of pulse and tone dialing, communication from the caller to
the system became automated and voice responses from the operators were
replaced by call progress tones. As pulses and tones were also used between
switches, they were blocked or filtered in the outgoing direction (at least
after phone phreaks discovered how to make free long distance calls!), but a
return voice path was held open to allow the return of busy or ringback
tones from the callee's switch, which, of course, ceased when the phone was
answered. Again, the call was signaled down the eventual voice connection
and no useful communication happened until the call was completed - and
billed for.

The use of T-series digital trunks with Robbed Bit Signaling left the model
unchanged, as each trunk simply acts like a thick bundle of ideal analog
lines.

ISDN/SS7 (ITU-Q.764 et al) changed the architecture significantly, by
separating the voice and signaling paths. A POTS caller signals their
exchange with the callee's number, and the exchange sends an Initial Address
Message (IAM) to the next exchange which routes the packet to the callee's
station. When the IAM is sent, a backward direction transmission path
(voice/data) is established, and - for voice only - a forward path MAY be
established (and often is). Intermediate exchanges establish bi-directional
voice paths immediately. When the destination exchange has been reached, and
the callee's circuit is available, the callee is alerted (ring signal),
ringback is sent through the backward voice path, and Address Complete
Message (ACM) is returned. Call progress messages may also be sent.

When the callee answers, the called exchange generates the ANswer Message
(ANM), completes the path to the callee's phone; when the caller's exchange
receives the ANM, it opens up the forward voice path completing the call and
initiates billing on receipt of the ANM. When either party hangs up, RELease
(REL) and ReLease Complete (RLC) messages are exchanged; billing is stopped
as soon as REL is seen. By separating signaling and voice paths, SS7 allows
for more robust signaling (using higher reliability/redundant paths for
signaling) and the possibility of re-routing in the case of congestion or
voice line failures. To the POTS user, there is no change in the operation
model.

With the advent of user/PBX ISDN interfaces, the distinction between "the
system" and user equipment becomes blurred: the exchange no longer needs to
provide DTMF and pulse detection, and battery and ring voltages to the user.
If capable and authorized, the user equipment MAY provide call progress
tones on the back channel; in particular, it is common for PBXs to only
issue ANM after the callee picks their phone. It is demonstrably possible to
build an ISDN apparatus that illegally provides free (incoming) voice calls,
by simply omitting to send ANM when the call is completed!

I believe the following suggestions most closely mimic PSTN/ISDN operation
in *voice* gateways:

o In situations where there are two gateways providing SIP bridging (per
sipping-sipt-04/3.1), the gateways should act similarly to ISDN exchanges
and provide a bidirectional voice path at the time of the INVITE.

o In the case of PSTN origination (sipping-sipt-04/3.2), the gateway
should/may provide an early forward media path (which may be ignored by the
SIP client!) and, once a 18x response is received synthesize appropriate
call progress tones (ringback) unless early media is provided by the SIP
phone (or its proxy), assuming such media will be call progress of some
sort.

o In the case of SIP origination (sipping-sipt-04/3.3), the gateway may
support an early forward media path if one is provided by the SIP phone
(which may be ignored by the PSTN phone), and should provide an early
backward media path, which will provide ringback, etc. to the SIP phone.

These scenarios do allow for the possibility of voice getting through
without being billed for, but only in cases where the PSTN would let it
through. More importantly, users would never be left with unexplained "dead
air". Otherwise, there would be the strange possibility of an Internet
connection billing for more time than the PSTN leg of the call.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: mailto:[email-masked]
Tel:   210.402.9669
Fax:   210.402.6996 

Michael Hammer [mailto:[email-masked]] wrote:

> It occurs to me that the question of backward cut-through 
> is intimately tied to the concept of a voice call. 
> The assumption here is that the only communication that
> is valid is a bi-directional one.  That is billing only
> starts at full cut-through.

> If you look at this from a data perspective (i.e. suppose
> one only wants to poll devices and get short on-way media
> stream responses) then it would be obvious that the
> establishment of a unidirectional media stream end-to-end
> has commercial value and could be accounted, rated, and
> billed accordingly.

> I believe the original motivation for early backward
> cut-through was to enable well-behaved network devices
> (switches) to use the media for in-band signaling messages.
>  The extension of this to the end-user devices muddies
> the water.  Likewise, to establish an end-to-end media
> stream to an ISDN terminal, even if it is only
> uni-directional, also takes a step down that slippery slope.

> But, given that we have already headed down that path, our
> only valid rationalization for this is to consider the
> accounting and fraud issues to be orthogonal and a policy
> issue for the GW.  That is the GW may allow or deny such
> early media and, if allowed, should also account for such
> actions to allow the service provider to rate such early
> media, whether that be at a zero rate per second or more.

> So, Tom I guess I am agreeing with you, but I would ask
> everyone to keep in mind the implications this has for
> services other than voice.

> Mike