Subject: RE: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Nov 1999 09:17:54 -0600

The SAM solution works if sending ISUP in SIP works.  The basic principle is
this: if too few digits are available at a given stage to locate an egress
gateway, a 484 final response is sent back to the ingress gateway saying so.
The ingress gateway has to wait for more digits, then reissue the INVITE
(with updated encapsulated IAM).  Eventually either the call is found to
terminate on a non-ISUP network (in which case there has to be interworking
somewhere along the signalling path) or it terminates on an egress gateway.
In either case the ingress gateway will forward SAMs via INFO messages to
the point where they are consumed.  (The obvious exception is if the ingress
gateway itself is the point at which interworking must occur.)

> -----Original Message-----
> From:	Adam B. Roach [SMTP:[email-masked]]
> Sent:	Tuesday, November 16, 1999 6:06 PM
	[[TomT]]  ... >
> >Why not send an INVITE message when the ISUP IAM is received and then
> send
> >subsequent INFO messages for each ISUP SAM? I understand that "pure" SIP
> >agents will expect the INVITE to contain the complete address of the
> called
> >party. This could be handled by including support for overlap in the
> >"Require" extensions (draft-roach-mmusic-sip-pstn-require-header-00.txt).
> If
> >the terminator did not support the PSTN extensions, the originator could
> >then switch to enbloc and wait for the full address to be collected.
> 
> There are a variety of problems here. The first is determining how
> intervening proxies will react. If, for example, a proxy is making
> decisions about where to forward messages based on a called party URI, 
> your suggestion would require it to understand ISUP (for interpretation 
> of SAM message). It also requires it to have number analysis code and 
> dialing plan information (potentially for the entire globe).
> 
> The problem gets even stranger for redirect servers, which expect to
> be able to send an immediate response to an INVITE -- not sit around
> collecting digits.
> 
> Basically, your suggestion forces overlapped dialing deep into each 
> and every SIP node in the network that is expected to receive calls 
> originating from the PSTN network.
> 
> I agree that this is a problem that needs to be solved if we intend
> to use SIP between two PSTN phones; but we need to find a better
> solution than tunelling SAMs all over the place.
> 
> We shouldn't overlook human factors: it could be that customers are
> willing to, for example, be trained to press "#" at the end of a
> phone number to skip the post-dial-delay.
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> [email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
>

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 18 Nov 1999 16:30:04 -0000

I think the problem with having a # at the end of the number is that it
depends on the way the call is routed whether it is necessary.  So one day
the call might be all switched network routed, and no # is needed or
desirable (and an extra # might cause problems), and the next day the
routing might be via IP in which case the # would be required.
Alternatively, calls that go via, say, London, might be IP routed, and calls
via Amsterdam might be switched routed.  And you wouldn't expect someone in
the US to know that calls in the UK now need a # to terminate them.

I don't think you can expect users to have to cope with these sorts of
routing issues.  They would have a right not to be satisfied with such a
service.

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

-----Original Message-----
From: Thomas Marshall Eubanks <[email-masked]>
To: Larry Cox <[email-masked]>
Cc: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: 18 November 1999 12:13
Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

>Hello;
>
>Larry Cox wrote:
>>
>>
>> You have pointed out quite clearly some of the problems that I have been
>> thinking about for some time. It also appears that a compelling answer to
>> the question will not be easily found.
>>
>> Since there will be a significant interim period during which SIP systems
>> will represent a small percentage of total calls routed, it must be
>> possible to provide seamless inter-operation with the PSTN if SIP is to
be
>> an acceptable call control protocol outside of private networks. This
>> precludes requiring a # digit at the end of the digit string.
>>
>
>I would not be so sure of this. In the US, this might be a problem, as
>our phone numbers have been stable for decades. In the US, a # sign
>would probably not be
>necessary, though, except for overseas calls. In Europe, however, I am
>not sure that such a change
>would be a big problem, as changes like this tend to happen more
>frequently anyway. In Austria,
>for example, within this decade they re-numbered much of the country. I
>don't know the details,
>but EVERY number I use in Austria changed. If they can handle this, they
>can handle a # sign,
>especially as it would not be absolutely required.
>
>My point here is simply that the more "organic" the phone system, the
>more users have to
>put up with instabilities in the system, and so the more they would be
>willing to accept
>additional changes.
>
>Also, won't recently called numbers be cached ? If a number is in the
>cache, neither
>a # sign nor a wait would be necessary. For most people, this would
>remove most of the problem.
>
>> Since knowledge of the required number of routing digits in many parts of
>> the world is local information subject to change at random intervals,
>> waiting for a timeout is the only reliable way to be sure that all digits
>> are collected. This tends to introduce a significant perception of
>> unreliable call switching. It appears that it would be much better to
find
>> an alternative.
>>
>> ======================================
>>
>> Larry Cox
>> Senior Software Engineer
>>
>> Hypercom Network Systems Inc.
>> 2851 West Kathleen Road
>> Phoenix, AZ 85053
>> USA
>>
>> Phone: (602) 504-4657
>> Fax: (602) 504-4711
>> Web: www.hypercom.com
>
>                                         Regards
>                                         Marshall Eubanks
>                                         Multicast Technologies LLC
>                                         [email-masked]
>
>

---

From: [email-masked]
Date: Thu, 18 Nov 1999 11:27:35 -0500

I think this will work. In order to help you with the ISUP, I just checked Q763.
The SAM cannot contain any additional information except additional digit(s).
This means that it is not neccessary to send a SAM for each digit, but one SAM
can be sent with as many additional digits as are available, so

"The egress gateway computes the SAMs based on differentials. So, lets say it
receives the INVITE with 1555, then the INVITE with 155512. It then
sends two SAMs, the first with 1, the next with 2."

can be modified with

"It then sends one SAM, with both digits 1 and  2."

Steve Carr
Unisphere Solutions, Inc.

Jonathan Rosenberg <[email-masked]> on 11/18/99 10:57:31 AM

To:   Gonzalo Camarillo <[email-masked]>
cc:   [email-masked], [email-masked],
      [email-masked], [email-masked] (bcc:
      Steve Carr/Internet/ICN)
Subject:  Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

What if, rather than encapsulating subsequent digits into INFO, they are
added to the request URI in an INVITE? A local proxy for the gateway
will respond with 484 to all those that don't have enough digits until
it gets one that does have enough. So:

Ingress GW            P             Egress GW

INV tel:1 ------------>
CSeq: 1

INV tel:12 ----------->
CSeq: 2

<---------484 --------
          CSeq: 1

INV tel:121 --------->
CSeq: 3

<---------484 -------
          CSeq: 2

INV tel:1212 --------> ---------------------->   IAM 1212---------->
CSeq: 4

<--------------484----
               CSeq: 3

INV tel:12125---------> ----------------------> SAM 5 ------------->
CSeq: 5

INV tel:121255 -------> ----------------------> SAM 5 ------------->
CSeq: 6

INV tel:1212555 ------> -----------------------> SAM 5 ------------>
CSeq: 7

.......(same thing for digits 1, 2, 1)

INV tel:12125551212----> ---------------------> SAM 2 -------------->
CSeq: 11                                        <---------ACM-------

                         <------484-----------
                                CSeq: 5
                         <------484-----------
                                CSeq: 6
                               .......
                         <------484
                                CSeq: 10
                         <---183--------------
                                CSeq: 11

Ok, so let me explain. Proxies do routing just on longest prefix matches
for INVITE's. So, proxy P can be stateless actually, as it just forwards
INVITEs that match 1212. The ingress gateway sends a re-INVITE (possibly
without waiting for a response to the previous INVITE) every time a new
digit is received from the PSTN. Once the proxy has enough digits to
route, it won't send 484 anymore, and forwards it to the egress gateway.
The egress gateway is smart, and creates an IAM from the first INVITE.
Subsequent re-INVITEs cause SAMs to be sent, containing the difference
in the set of digits from the previous INVITE. Once the egress gateway
receives an ACM (address complete, right?), it responds with a 484 to
all the INVITEs but the last, and the final INVITE with a 183. Things
progress normally from there.

Implications:

1. proxies don't have to know anything about INFO or ISUP. They just
have to know longest prefix match routing for phone numbers. They can
even be stateless.

2. egress gateways that know ISUP effectively re-generate the SAMs

3. if the egress point is not an ISUP gateway, but a PC terminal or
something that happens to have a phone number as its name, it will have
to know enough to reject each INVITE until it gets one with a request
URI/To field that matches its own number. This, BTW, is normal behavior.
A UAS rejects an INVITE if the URI is for an address thats not its own.

4. This works *even* if there is misordering of re-INVITEs. The egress
gateway computes the SAMs based on differentials. So, lets say it
receives the INVITE with 1555, then the INVITE with 155512. It then
sends two SAMs, the first with 1, the next with 2. Lets say, then, that
the INVITE with 15551 comes. Based on CSeq, the egress gateway knows its
old and rejects it.

5. The ingress gateway doesn't depend on special messages or a
completion character, like #, to send an INVITE.

Its very possible I've completely missed something, as I'm hardly an
ISUP expert. Perhaps there is additional data in SAM such that it MUST
be sent across, rather than being regenerated. But, the above solution
seems nice, as it doesn't break anything, works with non-ISUP
terminating points, doesn't require users to dial a # at the end of the
digit string, etc.

Comments?

-Jonathan R.

Gonzalo Camarillo wrote:
>
> It is nicer to send complete URIs in the "to" header. If the i-gateway
> sends the INVITE before receiveing all the digits, the "to" header is
> not complete. It would contain just a few digits of the whole telephone
> number (this assumes that with just some digits the i-gateway figures
> out where to send the INVITE).
>
> Gonzalo
>
> [email-masked] wrote:
> >
> > >The use of a timer to force enbloc signaling is not acceptable. In the case
> > >of SIP bridging, subscribers originating calls from the PSTN will not
accept
> > >an artificial post-dial delay (even if it is just a few seconds long).
> > >Overlap signaling must be supported. It is essential that the overlap
> > >process takes place within the context of a single session - using the
> > >suggested INVITE/CANCEL/INVITE approach would result in multiple abortive
> > >calls being delivered to the terminating agent, which would not be
> > >acceptable.
> > >
> > >Why not send an INVITE message when the ISUP IAM is received and then send
> > >agents will expect the INVITE to contain the complete address of the called
If
> > Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
> > [email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
>
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Nov 1999 12:59:32 -0000

>>
>> Yes, you are right. I was thinking about using just one call leg
>> (Call-ID, To, From). As you say, if we use different call legs
>> (different to field) inside the same call (call-ID) upgrading the Cseq
>> for every new request we will avoid the problem I was pointing out.
>>
>However, while this is about the only viable mechanism, new call legs
>make the job more difficult for the SIP-to-ISUP gateway at the egress
>side, in that it now has to make a decision whether this is really a new
>call or not, since one could presumably add call legs to an existing
>call (e.g., in call transfer) in the absence of overlap dialing.
>
>

Thinking about it, my feeling is that as Jonathan originally described his
scheme it is a bit over proactive about sending new dialled digit
information.  Perhaps it should only send a new INVITE once it has received
a response to a previous INVITE.  If it receives additional dialled digits
in this time, then it just accumulates them.

This reduces the amount of information that an ingress gateway has to store
about unacknowledged INVITEs and will also reduce the potential load on
egress gateways.

This may result in slightly slowing dialling of the final digits, but
hopefully should not be as bad as waiting for a 2 or 5 second time out.  If
the delay is long, then it suggests that there is congestion some where and
sending additional INVITE messages will not help this to go away.

(In fact I have heard that when collecting digits it is worth waiting a few
hundred milliseconds after reception of a digit to see if another one
arrives before sending a notification.  This can result in fewer messages
being sent without any perceptible delay by the user.)

The only problem that seems to arise from this is if an INVITE or its
response gets lost.  In this case, if the gateway wants to send additional
digits and it thinks the previous INVITE has got lost, then it needs to send
a CANCEL to make sure that no device along the chain is still acting on the
previous request.

Pete

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Nov 1999 13:55:09 -0000

Gonzalo,

I think the problem with your analogy here is that mobile is essentially an
access technology, whereas SIP can be used for access, and trunking (toll)
and a number of other combinations.  While an access technology can limit
how it collects digits, a trunk protocol does not have this luxury.

Pete
>Matt,
>
>[email-masked] wrote:
>>
>> Gonzalo,
>>         I agree with every thing you have detailed except for
>> the statement extracted below.  I agree the problem is
>> getting smaller and smaller since it really is a hold
>> over from pre-SS7 days. My question is why do we need
>> to provide backwards compatibility? Mobile seems to have
>> done a very good job of not providing this.
>> Why not take the same approach as mobile and exclude support?
>
>A mobile always sends 'en bloc' signalling, but a call that uses overlap
>signalling will be able to reach a mobile... therefore, mobile provides
>backward compatibility in that sense.
>
>In SIP I suggest to use the same approach. We send 'en bloc' signalling,
>but we are able to receive overlap.
>
>Regards,
>
>Gonzalo
>
>
>>
>> IMHO this is one legacy PSTN function that needs left on the PSTN.
>> The amount of work required to support the feature is just
>> not justified.
>>
>> Matt
>>
>> > From: [email-masked]
>> > [mailto:[email-masked]]On Behalf Of Gonzalo
>> > Camarillo
>> > Sent: Friday, November 19, 1999 8:45 AM
>> > To: [email-masked]
>> > Cc: [email-masked]; [email-masked];
>> > [email-masked]; [email-masked]
>> snip-->
>> > The problem of a user typing # :
>> > In the States 'en-bloc' signalling is used, so this is not needed. In
>> > Europe, the use of 'en-bloc' signalling is becoming more and more
common
>> > due to the use of mobiles (in Finland there are more mobiles than fixed
>> > phones).
>>  >Therefore, the problem i getting smaller and smaller.
>> > However, we have to provide backwards compatibility.
>> > We are here for finding a solution to the problem. If we do not find a
>> > solution, we can tell all the users to press # after the phone number,
>> > but I wouldn't say that this is "finding a solution" :o)
>>
>> end snip-->
>
>--

---

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 18:20:11 -0600

Gonzalo Camarillo [mailto:[email-masked]] writes

> but we are able to receive overlap.

This sounds like the right approach to me.

Tim Schroeder

This e-mail and any files transmitted with it are the property of SBC,
are confidential, and are intended solely for the use of the individual
or entity to whom this e-mail is addressed. If you are not one of the
named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at
[email-masked] and delete this message immediately from your
computer. Any other use, retention, dissemination, forwarding, printing,
or copying of this e-mail is strictly prohibited.

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Nov 1999 11:59:06 -0000

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Pete Cordell <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]
<[email-masked]>
Date: 22 November 1999 19:58
Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

>
>
>Pete Cordell wrote:
>>
>> >Why INFO? Usage of INFO for carrying overlapped signaling is definitely
>> >an interoperability problem. Normal SIP UAS's won't know to look for
>> >digits in INFO to set up a call. The example call flow I gave in email
>> >handles perfectly well the case of PSTN-IP-PSTN with overlap on both
>> >ends.
>>
>> When I was writing this, I meant to say something like "INFO or similar
>> method," but my brain moved on before my fingers caught up, BUT
>>
>> there is the issue that in the come cases logic may not wish to cut
through
>> the caller to callee media path until there is a 200 OK accepting the
call.
>> This might favour an INFO based method.
>
>Why? These seem orthogonal. We have the whole 183 message stuff to
>decide whether to cut through. A UAS isn't going to send a 183 in
>response to an INFO, but it will to an INVITE.

183 cuts through media in the called party to calling party direction.
That's good.  But I hope it does not enforce the media to be cut through in
the calling party to called party direction.  A number of operators only
want to allow this when 200 OK is exchanged as this is when they intend to
start charging.  We couldn't possibly allow someone to have free call
time!!!  My observation was that DTMF over RTP would be media (in so far as
it is RTP) in the calling party to called party direction prior to 200 OK.

>
>>
>> >
>> >In another mail, you wrote:
>> >
>> >What I don't like about this is that it requires every proxy or UAS to
>> >know about overlap signaling. This is because they need to know to send
>> >a 484 to ask for more digits, which nearly all UAS won't.
>>
>> That's a good point, but I think the condition can be safely reduced to
>> accepting the 404 (and 604) reason also (and perhaps some others) to
>> indicate that the address is incomplete.  This would allow proxies to
remain
>> ignorant of overlapped sending.
>
>OK. I'm fine with that.
>
>> >1. send digits immediately upon receipt, as I described in my email
>> >2. wait some timeout T after a digit, and collect whatever arrives
>> >during T into a single INVITE
>> >3. wait for some longer timeout to get all the digits, effectively
>> >converting overlap to en-block at the ingress gateway
>> >4. wait for a # key
>>
>> 5. Only ever have one outstanding INVITE request and wait for a success
or
>> failure code before sending another. :)
>
>People have expressed concerns over PDD if this is done. Ideally, I'd
>prefer this also.

It's a good point, but I feel that it is no worse than waiting 5 seconds
after each digit.  Also it does provide some element of congestion control.

However, following through the various failure modes when signalled over
UDP, I don't think it makes the life of a gateway UAS any easier.  It may
make the life of a gateway UAS signalled over TCP easier though.

>
>
>> >2. A gateway that receives an INVITE with a Call-ID that matches a
>> >previous call, and whose Request-URI contains a tel or SIP URL with
>> >additional digits in the user part, should tret this INVITE as adding
>> >additional digits to the original dialed string (overlap).
>>
>> This condition will also apply to any device that wants to provide a
service
>> along the call path.
>
>For a call-stateful proxy, maybe. For a normal stateful or stateless
>proxy, no.

Yep, when I said service I meant a call state-ful service.

>
>
>>
>> Indeed, it also applys to any terminal UAS because in the general case
you
>> won't know whether a call will go to a gateway or a stand-alone UAS,
>> especially with users moving around and using location services.
>
>No. A UAS knows its a terminal and not a gateway. A terminal will never
>need to worry about things like SAMs and additional address digits. A
>terminal will have a small, finite (usually one) set of addresses that
>it is responsible for. Thus, a UAS thats a terminal will end up
>rejecting all these INVITEs but the last. If, by some chance, another
>one comes, the UAS should reject that also, since the request URI won't
>match a valid address at the terminal.

This sounds plausable, but in any text that is written up on this, I feel
there should be a noted directed at terminal UASs that indicate that this
situation may occur.  After all, the simplest implementation is not to
bother checking the To: field in a UAS and just accept any INVITE that comes
along.  This would be OK if the UAS indicated busy for second and subsequent
INVITEs, but would not give the right results if the UAS tried to conference
in the new INVITE.

>
>
>Before we get too much farther, I think we need some more discussion on
>the general direction of the solution. I see two directions:
>
>1. The one we've been discussing, which requires all egress gateways to
>know about overlap. Terminals, stateful and stateless proxies don't need
>to do anything special. Call stateful proxies may need to know about
>overlap.
>
>2. Matt's suggestion: convert the overlap to en-bloc at the ingress
>gateway with a timeout. Users don't need to dial an extra pound or
>anything, but PDD's may be longer. Do we care? If this is legacy
>technology that truly is fading away, should we bother to burden new
>gateways with it?
>
>Anyone else have an opinion on (1) vs. (2)?

I know I may not be in the category of anyone else in this debate, but I
don't feel that overlap sending will fade away anytime soon.  For a US only
solution it will probably be OK to ignore the overlap issue, but for many
other countries it would be dangerous to ignore it.