Subject: RE: [SIP] Overlap call setup

From: "Mark Watson" <[email-masked]>
Date: Thu, 8 Feb 2001 17:50:15 -0000

There are other reasons for overlap which are not to do with outpulsing
delay/CAS interworking, but rather to do with determining end of dialling.

1) Support of open dial-plans, where not even the terminating exchange knows
how many digits to expect, only the user equipment knows this
2) Simplification of routing data, so not all exchanges have to know the
global dial-plan in order to work out how many digits to expect

In the absence of an indication of end-of-dialling from the calling user you
have only two choices:
a) Run an inter-digit timer and assume end of dialling if it expires
b) Overlap digits through the network towards a point where the end of
dialling can be determined from dial-plan knowledge

It is generally felt that for networks puporting to offer PSTN or better
services, (a) is not acceptable as it adds post-dial delay and can
mis-identify end of dialling if the user is too slow.

Of course an end-of-dialling indication from the user is highly desirable,
which is why all systems more advanced than simple telephony are based on
this (mobile phones, ISDN, SIP), but systems exist, and will continue to
exist for many decades, which do not provide this.

I believe there are important flaws in the mechanisms in the RFC and isup
mapping draft. Not least the requirements to have multiple outstanding call
legs for each extra digit, to use a whole INVITE for a single digit and to
tie these into a single call instance on the ISUP side of a gateway could
not be described as elegant.

We seem to be near reasonable solution based on negotiating the use of INFOs
- I think we should go ahead and document this so that we can bottom out the
details.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Keith Robinson [mailto:[email-masked]]
> Sent: 07 February 2001 11:29
> To: [email-masked]
> Cc: [email-masked];
> [email-masked]; Moloney, Joshua [MDN05:CT07:EXCH];
> Taylor, Tom-PT [NORSE:B901:EXCH]; [email-masked]
> Subject: Re: [SIP] Overlap call setup
> 
> 
> 
> 
> Vendors could mandate that their SIP/PSTN gateways will 
> always block up digits
> and do everything en bloc; thats fine.
> 
> I  was raising issues I had with the mechanism for supporting 
> overlap sending if
> it was required to be performed because a particular 
> administration wants to
> use overlap signalling.
> 
> Regards,
> 
> Keith.
> 
> 
> 
> 
> 
> 
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 07/02/2001 06:49:08
> 
> Please respond to [email-masked]
>                                                               
>                   
>                                                               
>                   
>                                                               
>                   
> 
> 
>                                                               
>                                                               
>                                                               
>  To:      Keith Robinson/MAIN/MC1@MCMAIN                      
>                                                               
>  cc:      [email-masked],                  
>           [email-masked],                  
>           [email-masked],                        
>           [email-masked], [email-masked]  
>                                                               
>                                                               
>                                                               
>  Subject: Re: [SIP] Overlap call setup                        
>                                                               
> 
> 
> 
> 
> 
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Jan 1988 19:26:26 +0200

Hello,

Mark Watson wrote:
> 
> There are other reasons for overlap which are not to do with
> outpulsing delay/CAS interworking, but rather to do with determining
> end of dialling.
> 
> 1) Support of open dial-plans, where not even the terminating exchange
> knows how many digits to expect, only the user equipment knows this
> 
> 2) Simplification of routing data, so not all exchanges have to know
> the global dial-plan in order to work out how many digits to expect
> 
> In the absence of an indication of end-of-dialling from the calling
> user you have only two choices:
> It is generally felt that for networks puporting to offer PSTN or
> better services, (a) is not acceptable as it adds post-dial delay and
> can mis-identify end of dialling if the user is too slow.
> 
> Of course an end-of-dialling indication from the user is highly
> desirable, which is why all systems more advanced than simple
> telephony are based on this (mobile phones, ISDN, SIP), but systems
> exist, and will continue to exist for many decades, which do not
> provide this.
> 
> I believe there are important flaws in the mechanisms in the RFC and
> isup mapping draft. Not least the requirements to have multiple
> outstanding call legs for each extra digit, to use a whole INVITE for
> a single digit and to tie these into a single call instance on the
> ISUP side of a gateway could not be described as elegant.
> 

It is not elegant, but it is the best mechanism (or less bad than the
others, if you want).

> We seem to be near reasonable solution based on negotiating the use of

Do not think so. As I said several times, if you want the SIP network to
provide services, you have to go for multiple call legs. If you just
want to transport signalling, SIP is a very bad protocol for that
purpose. Use another.

Using INFO for sending SAMs is trying to re-create the ISDN call model
using SIP. I just do not like the whole idea.

Regards,

Gonzalo

 - I think we should go ahead and document this so that we can
> bottom out the details.

-- 
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 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.