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

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

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

How long are you proposing this timer be?

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

Seems reasonable, but....

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

I'm very, very against this.  It is just plain broken.

If every user magically gets a SEND button on their phone over night, then
fine, but until then this is deficiencies in the technology dictating the
UI.  In this fabulous Internet age users should not have to be confronted
with this.  Legacy or otherwise, we have a problem to solve and we should
not be looking to the user to solve our problems as they have their own
problems to contend with.

The two second plus delay is also not acceptable.  While this may only
affect international calls in the US, it will affect every call in the UK,
and presumably Germany and France, and many other countries as well.  Our
wonderful new toy should be making call services better, not worse!

Emotional shirty mode = off :)

>
>Does anybody have a problem with this solution?
>
>Gonzalo
>
>[email-masked] wrote:
>>
>> Henning Schulzrinne wrote:
>> >
>> > >
>> > > 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.
>>
>> 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.
>>
>> --
>> 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
>
>--
>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
>
>

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

---

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

> How long are you proposing this timer be?

As it is said in the draft, the maximun value for this timer is 5
seconds, but it has to be configurable depending on where the gateway is
located. In some points of the network the reception of SAMs is very
unlikely to happen. In these situations the timer will be short. If the
reception of SAMs is likely to happen, the timer has to be long enough
to avoid lots of signalling messages.

> problems to contend with.

That's what I said in a previous mail. I am just saying thatin case we
receive the end-of-digits signal, the gateway doesn't wait for the timer
to expire.

Regards,

Gonzalo

---

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

Pete, I'm sorry , I just firmly believe that the
importation of overlap signaling to SIP is a 
mistake. Your comment snipped below is right 
on the money....

"Our wonderful new toy should be making call
 services better, not worse!"

Agree completely, if you are not providing either 
new services/features or cheaper rates 
with the use of SIP, its not going to be 
heavily deployed. But on the flip side, if the
services and costs are there, people will get used
to waiting for the few seconds for the timers to
expire or learn to hit the # key real quick.

The thought of a large number of INVITES and 484
response messages flying across the network to make
overlap work just makes me shake my head.

Just my two cents...

Matt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gonzalo
> Camarillo
> Sent: Monday, November 22, 1999 7:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt
> 
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Nov 1999 09:08:57 -0500

Matt Cannon wrote:

> overlap work just makes me shake my head.

To get some feeling as to how bad (or not) this might be, I wonder if
there's any sense as to the per-country variation in number length. It
is probably reasonable for a gateway to know the minimum digit string
length for each country, so only digits beyond that would need to be
signaled digit-by-digit. (It is also very unlikely that the minimum will
suddenly drop, so updates should not be an issue.) Any observations?

(By the way, the 484 overlap signaling method is already in the SIP
spec, as this topic has been around a few times...)

I agree that we should avoid this as much as possible.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 22 Nov 1999 13:40:31 -0500

> expire or learn to hit the # key real quick.

Pete is right on with our thinking.  There is no doubt a significant group
of end users who will have no problem using a send button (assuming there
is one present) or # button etc.  However there is another group of people
that do not want to know what SIP, en bloc or over lap is they just want
their phone to dial when they are done dialing, not 2 or 5 seconds later.
Believe it or not there are many people who still do not own a mobile phone
and have not learned to use the send button.  I have been told by mobile
phone services people that "why do I have to push send" is the most
common support question from new mobile phone users.

I believe that it is necessary to support both modes for users dialing with
a
send button and without.  In the latter case a timer will cause frustration
to
the end user and should be avoided.