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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 17 Nov 1999 10:26:03 +0200

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
> >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

-- 
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

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 16 Nov 1999 17:06:28 -0600 (CST)

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Nov 1999 20:46:12 -0500

"Adam B. Roach" wrote:

> phone number to skip the post-dial-delay.

It seems like the PSTN gateway is the best equipped to detect at least
some dialing plans, just like in today's network. Why can't it simply
collect the ISUP SAMs until it detects the end of 1+10 digits?

It used to be that for variable-length dialing plans (e.g., most of
Europe), you'd use timeout (or #). I imagine that SAM can now be carried
end-to-end, so this may no longer be true. Anybody know for sure? (This
would only work if every single end office is ISUP-capable, since the
digit variation often occurs within a single central office. For
example, my old university in Darmstadt had phone number 19-x, where x
could be 0 for the switchboard or a four-digit number for the
"extension").

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Nov 1999 10:57:31 -0500

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.

-- 
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: Anil Yelundur <[email-masked]>
Date: Thu, 18 Nov 1999 10:15:38 -0600

Can multiple SAMs be sent? I thought only one SAM is allowed after the IAM...I am not
very sure.
Anil Yelundur

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Nov 1999 11:37:26 -0600

> phone number to skip the post-dial-delay.

We get by here in the states quite nicely without overlap signaling.

As I understand it, MCI systems use either timeout (I believe 2 seconds) or
short-# key to trigger the IAM.

Personally, I've never used the short-# and didn't even know it was an
option until one of the switch guys told me. I just thought 3-4 seconds of
PDD was normal for long-distance calls.

On the other hand, our BT associates were quite fanatic about overlap
signaling.

--
Dean Willis

---

From: "Lyndon Ong" <[email-masked]>
Date: Thu, 18 Nov 1999 14:08:23 -0800

You definitely need multiple SAMs in ISUP, since you may need to send several additional digits in the address - if you could send them all in one SAM, you could equivalently send them in the first IAM.

2 cents: The INVITE-based solution seems most in keeping with SIP procedures, since you are not sending end-to-end information, but information that is affecting the processing of the session.  

Encapsulating the SAM might help reduce the processing needed at the far-end gateway, as opposed to generating new SAMs there, but that might not work in some cases, e.g., if you have different ISUPs at each end, or something other than ISUP at the far end.

Cheers,

L. Ong

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Nov 1999 18:15:37 -0500

> Encapsulating the SAM might help reduce the processing needed at the far-end gateway, as opposed to generating new SAMs there, but that might not work in some cases, e.g., if you have different ISU…

There is also the issue that the INVITEs may arrive out of order, and in
that case the SAMs that get sent by the egress gateway don't match whats
carried in the INVITEs.

If the ISUP messages don't contain any additional useful information
beyond whats in SIP itself, I'd much prefer not to have them carried in
SIP.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Nov 1999 17:11:06 -0600

> it gets one that does have enough. So:

Could be some fascinating interactions with TRIP and ENUM using this
approach.

One would have to do ENUM lookups and potentially TRIP path checks on each
invite (each digit) at each hop . . . it could get weird.

Maybe the resolution looks something more like

Receive IAM
lookup digits in ENUM
if found send INVITE //It's an IP phone number
else
	look for route in TRIP
	if found send INVITE  // It's a GSTN phone number
	else
		while not done and not timer-expired
			receive SAM
			lookup digits in ENUM
			if found send INVITE, set done
			else
				look for route in TRIP
				if found send INVITE, set done
			end else
		end while
	end else
	send 484 // don't know how to route, timer expired
end else

Of course, this sort of depends on length-constrained prefix-matching in
TRIP and ENUM . . . you wouldn't want to match on a partial prefix and
dispatch before receiving all of the digits.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 00:25:38 -0500

> Could be some fascinating interactions with TRIP and ENUM using this

Its going to be a general complication of overlap sending. Using INFO or
something else will be just at least as bad, probably worse. The lesson
is to use en-bloc. Fortunately, my proposed INVITE approach doesn't
require special processing; just that standard processing will be
duplicated for each INVITE.

> dispatch before receiving all of the digits.

Actually, for TRIP, thats exactly what you want to do. The whole idea is
that a given proxy doesn't have a complete digit map to fully route the
number. It knows enough to forward it somewhere else (that somewhere
else knowing even more). Its complicated in the case where a proxy has a
prefix A which is less specific than B, with A and B having different
next hops. In this case, you kind of want to wait for enough digits to
fill the longest prefix you have. Note this is not *all* the digits;
just enough to fill the longest prefix.

Anyone know how this is handled in the phone network? How does a switch
know when it has enough digits to make a routing decision?

-Jonathan R.

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 19 Nov 1999 07:26:40 -0800

Jonathan,

re: "Anyone know how this is handled in the phone network? How
does a switch know when it has enough digits to make a routing decision?"

For the overlap sending case ... it is as both Dean and Henry
described .... sometimes you don't know until you hit the last switch.

This variable-length phone number problem dates back to pre-SS7
switches where the switch legs were completed as the number
was dialed (and later DTMFed) in. As soon as the switch that
the present call leg terminated knew enough to either terminate
the call or forward the call to another call leg ... that is what it did.

Henry had an example where the number for a university he
attended in Europe where yyy-zzz-0 for the university operator,
yet something like yyy-zzz-qqq, where qqq is his phone number.

Clearly only the last switch knew if 0** was to be completed
to the operator (as soon as the zero was dialed) and that no
other phone numbers were to begin with a zero.

Thus the required number of digits is only known by the keeper
of the (local) numbering plan. It is probably unrealistic for the
originating proxy to know it a priori.

Thus you probably need a heuristic tree like Dean posted
yesterday.

Michael

>know when it has enough digits to make a routing decision?

Michael A. Ramalho, Ph.D.
Cisco Systems
Wall Township, NJ
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 09:59:35 -0500

Gonzalo Camarillo wrote:
> 
> Problem of imcomplete To field:
> If the i-gateway sends (as Jonathan suggests) an INVITE with some
> digits, and then adds the rest of them to the request URI, the To filed
> is not going to be complete. It will contain just some digits.
> Are we OK with this?
> We may have:
> 
> INVITE 123456@...
> To: 123@...
> 
> Because we received 123 in the IAM, and 456 in SAMs (a single SAM can
> contain several digits).

I don't understand why this will happen. When the request is updated,
also update the To field. This is, effectively, a new call, so keeping
the To field the same across all transactions isn't needed here. Keeping
the Call-ID the same is needed so the egress gateway can correlate all
these together.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Nov 1999 10:15:36 -0500

> the call or forward the call to another call leg ... that is what it did.

Indeed, if you look at the numbering schemes in Germany and (I believe)
France, you will find a strict geographical hierarchy, with regional
centers having shorter numbers. In the days of stepper switches, each
switch would simply connect to the next CO, which would interpret the
next digit. Extra digits are ignored, as usual.

As an aside, this makes GLP/TRIP much easier - you don't have to carry
around a list of 105 exchange codes when advertising your local calling
area (the number 105 is the length of the list for Leonia, NJ).

> Henry had an example where the number for a university he

Are you referring to me? Just curious if I have now undergone the "Ellis
Island treatment"...

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Nov 1999 16:44:35 +0200

Hi,

We are talking about several problems, all related to overlap
signalling.

First of all, this is what draft-camarillo-mmusic-sip-isup-bcp-00.txt
says in the chapter 7.1 about this. This is the chapter that has to
contain the solution that is found to be the best.

********
7.1 Address received

   Upon the reception of an IAM resources are reserved in the MG and it
   gets backward through connected.

   The B-party number can be received in just one IAM ('en bloc'
   signalling) or in one IAM followed by one or several SAMs (overlap
   signalling). In some countries there is no way for the MGC to know
   whether the B-party number is already complete or some SAMs will
   still arrive.

   If the MGC relies on the inter-digit timeout to assume that the
   number is complete the establishment of the connection is delayed.
   Alternatively, if the MGC sends the INVITE request immediately after
   receiving the IAM heavy signalling traffic may be generated.

   Therefore every individual MGC must be configured with a specific
   timer. If an MGC never receives a SAM the value of the timer should
   be zero. If the reception of a SAM is likely the value of the timer
   should be sufficient for receiving them before the INVITE is sent
   (after receiving the minimum amount of digits that can represent a
   number, around 5 seconds).

   Thus, after receiving the B-party number, the MGC issues an INVITE
   request. If after sending this request a SAM is received the MGC
   will CANCEL the INVITE and send a new INVITE to the complete
   address. If a '484 Address Incomplete' is received the MGC should
   wait for subsequent SAMs and send a new INVITE.
**************

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)

INVITE 123456@...
To: 123@...

This means that the information contained in the SIP fields is not
really correct. And we are talking about mandatory fields. That's why I
was trying to avoid this. If nobody sees a problem with this we can
proceed this way.

By the way, the trade-off I pointed out in the draft is still there. If
we issue an INVITE every time we get a SAM, we will generate lots of
messages. I still think that the timer I was proposing is an idea to
take into account.

Any comments?

Gonzalo

[email-masked] wrote:
> ........(same thing for digits 1, 2, 1)
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Nov 1999 17:47:07 +0200

> it gets one that does have enough. So:

This is in principle correct (just taking into account that one SAM can
contain both digits). But here we have a PSTN-SIP-PSTN situation, and we
are trying to achieve ISUP transparency. So, the normal behaviour of the
e-gress gateway is to generate the ISUP messages contained in the MIME
body of the SIP message. 

If we proceed as you said, the e-gateway will generate by itself some
messages (like this SAM with two digits), without taking into
consideration the MIME body of SIP.

I am not saying that this is incorrect. Actually we are sending exactly
the same information, and the result will be most likely the same. I am
just saying that we brake the ISUP transparency... 

Gonzalo

---

From: Chip Sharp <[email-masked]>
Date: Fri, 19 Nov 1999 10:49:24 -0500

>contain the solution that is found to be the best.
...snip...
>due to the use of mobiles (in Finland there are more mobiles than fixed

FWIW,
When dialing international calls from the US, the user usually must either 
enter "#" or wait for a timeout for the call to be completed.  In most 
countries I have travelled in, I have found that entering "#" to terminate 
"dialing" at least does no harm.  Sometimes it speeds up post dial delay by 
a couple of seconds.

> > > > >"Require" extensions 
> (draft-roach-mmusic-sip-pstn-require-header-00.txt). If

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Nov 1999 17:53:26 +0200

> the Call-ID the same is needed so the egress gateway can correlate all

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.

Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Nov 1999 11:01:20 -0500

> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 11:05:35 -0500

> area (the number 105 is the length of the list for Leonia, NJ).

My question about pstn operation was a bit more specific. As you say, an
exchange has some short table of prefixes, and for each, a "next hop"
switch which will know how to handle additional digits. My question is,
would this table include two prefixes that overlap, with a different
next hop? In other words, would a European switch have:

+1  -> switch A
+1 212 -> switch B

In this case, when it gets a "1", it can't yet make a decision, since if
a 212 follow it, the IAM gets sent to switch B instead of A.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 19 Nov 1999 18:01:08 +0200

> does a switch know when it has enough digits to make a routing decision?"

Every switch performs B-number analisys and knows that if the number is
inside a certain range it has to be routed to a certain next hop.

Example:

+358 9 299 3371

With +358 the signalling can be routed up to an internatinal gateway in
Finland.

+358 9

The signalling is rounted up a swtich in Helsinki.

+358 9 299

The signalling is routed to the PBX of Ericsson Finland.

Now, if the next digit is 1, you will speak to the front desk, but if
the digits dialed are 3371 you will reach my phone.

So, every switch knows about the next hop, but nothing else.

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Nov 1999 11:19:04 -0500

> e-gress gateway is to generate the ISUP messages contained in the MIME

I disagree with the goal you state. SIP is not a transfer protocol. Our
aim is for ISUP transparency in the sense that there is no loss of
information. This can be accomplished through straight transfer of ISUP,
or by allowing for reconstruction of a complete message from the SIP
information. Both approaches achieve transparency. In order to make
operation of the protocol as broadly applicable as possible, I would
strongly recommend including ISUP messages in bodies only when (1) it
provides information that cannot be otherwise reconstructed from SIP
itself, (2) the semantic of the ISUP message matches the semantic of the
SIP message. In this case, the gateway can reconstruct the SAM.
Including it only makes things confusing, since, as I pointed out, the
SAM that is generated may not be the same as the one in the INVITE
itself (this happens when messages are misordered). In fact, inclusion
of SAMs doesn't pass either condition above. The SIP INVITE is a
complete call setup request, akin to IAM, rather than a notification of
additional digits, as SAM is.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Nov 1999 11:23:06 -0500

> a 212 follow it, the IAM gets sent to switch B instead of A.

To use a real (simplified) example:

+49 2*  is the Rhineland.
+49 228 is Bonn 
+49 221 is Cologne (city of),
+49 2232 is a city near Cologne.

(Generally, +49 .. 1 seems to be the favorite way to terminate the area
code for the codes with fewer than 4 digits.)

Assume a call to +49 2232 something. The call gets to +49, which
processes the next digit (2). It then directs calls to the Rhineland
regional center. That center gets the next digit (say, 2). If it's a 1
or 8, it knows that the area code is done with and directs the call to
the CO in the city of Bonn or Cologne. Otherwise, it knows the area code
has an additional digit, and in the example, sends the call to the 223
switching center, based on the next digit. The 223 switching center uses
the next digit to find the smaller town, applying the same prefix
algorithm.

Any of these numbers have to have the Huffman prefix property, i.e.,
there can't be a city with the area code +49 2281.

If you are interested in this,
http://set.gmd.de/~halfmann/daten/avon.html
has the complete list. Area codes range in size from 2 (Berlin) to 5
(small towns near Berlin).

---

From: "Matt Cannon" <[email-masked]>
Date: Fri, 19 Nov 1999 11:47:57 -0600

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?

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

> -----Original Message-----
> 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]
> Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

snip-->

 >Therefore, the problem i getting smaller and smaller.
> However, we have to provide backwards compatibility.

end snip-->

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Nov 1999 16:59:41 -0500

> The amount of work required to support the feature is just
One subtle difference is that people have been trained to expect this on
mobile phones, but on black phones, it would sometimes work with
immediate ringback and sometimes with delayed ringback and timeout, if
carried via VoIP. Depending on how the gateway works, the behavior may
even change from call to call, e.g., if the gateway keeps the call on
the PSTN during periods of Internet congestion.

On the other hand, callers in the US expect that international calls
take a bit longer to set up, so this is probably mostly a problem for
intra-European calls...

As a historical side note, call setup delays of above ten seconds were
not uncommon not that many years ago (see Duffy and Mercer, 1978).

Henning

---

From: "Matt Cannon" <[email-masked]>
Date: Fri, 19 Nov 1999 17:38:05 -0600

Agreed,
	But even in the Intra-European wire-lined phones,
the use of overlap sending is disappearing(slowly) with
the introduction of the competitive environments and the
newer carriers. My major point was that the use of SIP 
for voice should be treated much the same way as mobile.
The expectation is that there will be enough value
add in the way of features and cost, that 'polluting' the
mechanism by which that value is added(SIP), by trying to
support some of the more esoteric legacy features is 
probably a bad thing. Just a thought.

I am the ultimate bellhead here folks, but even I recognize
that if you try and reproduce every feature of the existing
PSTN your gonna wind up with something that is no better 
than the PSTN. SIP derives much of its power from its simplicity
and ease of implementation. If overlap can be accommodated
without adding new verbs, headers or response messages and 
a minimum amount of complexity in UAC/S, great. If it cannot,
I would leave it behind on the PSTN where it belongs.

Matt

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 4:00 PM
> To: Matt Cannon
> Cc: 'Gonzalo Camarillo'; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 20 Nov 1999 01:03:12 -0500

> call (e.g., in call transfer) in the absence of overlap dialing.

True, but these appear differently. If I receive INVITEs with the same
Call-ID, but a new *From* field, these are new call legs ala multiparty
calls from the call control spec. Receiving INVITEs with the same
Call-ID and different *To* fields has no currently specified behavior,
as I recall. For a normal (not a gateway) UAS, this will probably cause
an error response to be generated, since a UAS won't normally accept
calls that are not addressed to it. A gateway will need to be a bit
smarter, as I have described.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 22 Nov 1999 14:30:15 +0200

Hi,

A review of this thread:

I think everybody agrees that overlap signalling is something not
desirable in SIP. So, we have to try to minimize its presence when
interworking with PSTN.

Therefore, the i-gateway implements a timer (it is started upon the
reception of an IAM). This way, it is likely that before it expires some
SAMs have arrive. This way the amount of signalling messages is
decreased. On the other hand, it introduces a delay.

If the timer expires, we issue the INVITE as Jonathan suggested (instead
of the CANCEL, new-INVITE solution that was suggested in the draft).

This timer is used in lots of SS7 systems, so it is not anything new.

If we educate the users and everybody types # after the number, the
timer will never be started and there will be no delay in the setup.

Does anybody have a problem with this solution?

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 22 Nov 1999 15:12:43 +0200

Matt,

> 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

---

From: "Matt Cannon" <[email-masked]>
Date: Mon, 22 Nov 1999 08:47:11 -0600

Gonzalo,
	I agree completely...
Matt

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, November 22, 1999 7:13 AM
> To: [email-masked]
> Cc: [email-masked]
> > > Subject: Re: Comments on 
> draft-camarillo-mmusic-sip-isup-bcp-00.txt
> > 
> > snip-->
> >