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

From: Michael Hammer <[email-masked]>
Date: Fri, 26 Jul 2002 10:54:07 -0400

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

At 06:10 AM 7/21/2002 -0400, Tom-PT Taylor wrote:

>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

_______________________________________________
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: Al Varney <[email-masked]>
Date: Fri, 26 Jul 2002 12:31:50 -0500

At 10:54 AM 7/26/02 -0400, Michael Hammer wrote:

    In many cases, that assumption appears in regulations imposed on 
service providers.

    And that's one reason ISDN tries to distinguish voice from data calls, 
and allows per-interface (akin to per-UA) options to support cut-through in 
the backwards direction prior to answer for voice and/or data.  Interfaces 
that are not "trusted" don't get the cut-through option.  And data can, in 
many places, have rules allowing changes to begin prior to answer (assuming 
a back-ward or bi-directional path is in place prior to answer).

    Yes -- which is why it is optional and probably uncommon.  Certainly 
ISDN terminals don't use that option.  It's major use would be with PRI/PRA 
interfaces to PBXs, and in that application emulates a terminating analog 
PBX providing audible ringing tone.  (So the cut-through of audio in the 
backward direction, or even both directions, did not begin with ISDN.  It 
was an existing analog "feature".)

    Unfortunately, the SIP-BICC/ISUP Interworking model (in IETF, if not in 
SG-11) attempts to treat ISUP-to-SIP interworking to a User in the same way 
as ISUP-to-SIP interworking to another SIP-to-ISUP gateway.  The same media 
cut-through rules are unlikely to work for both situations.

    In the latter (SIP-T) case, the gateways MUST be willing to cut through 
the audio path in the reverse direction on receipt of ACM or 
183-with-media, because the SIP-to-ISUP gateway may itself connect to an 
ISUP-to-MF tandem switch.  And in that case, the ONLY source of audible 
ring tone, busy tone or other call progress tones/announcements is the 
media path.

    Crude diagram (I2S=ISUP-to-SIP, S2I=SIP-to-ISUP):

  I2S --(Invite)-> S2I --(IAM)-> ISUP-to-MF --(MF tones)-> MF CO
  I2S <-183+SDP--- S2I <-(ACM)-- ISUP-to-MF
  I2S <-[media]--- S2I <-circuit ISUP-to-MF <-(audio call progress)- MF CO

    Note the ISUP-to-MF switch returns the ACM prior to (or in parallel 
with) the MF call set-up.

    It may be possible to keep these cases separated at the ISUP-to-SIP 
gateway by recognizing an (encrypted) ACM imbedded in the 183-with-media, 
and ensuring such an ACM cannot be placed in a user-generated 183 
message.  Either that, or the gateway has to "recognize" which SIP 
destinations are trusted.

    I'm not worried (too much) about the SIP network being unable to 
deliver pre-answer tones/announcements.  I AM worried that SIP tandeming 
situations can lead to the far-end PSTN being unable to do so.

Al Varney