Subject: RE: [SIP] Overlap dialing within a SIP network

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Thu, 22 Feb 2001 10:34:39 -0500

Hi, Everyone:

I agree with Keith that we should mandate en-block due to the following
benefits:

1. Simple solution considering the complexity, ambiguities and
incompatibilities in implementing the at
2. MGC that is handling the ISUP-SIP mapping can be intelligent enough to
perform en-blocking
3. First INVITE becomes the real INVITE and this solves all the potential
problems (e.g., routing, inefficiency of sending the signaling messages back
and forth, etc)
4. The additional delay incurring in collecting digits may not matter much
because we may have to deal with authentication, policies, and other related
functions to deal with the call

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Keith Robinson [mailto:[email-masked]]
Sent: Thursday, February 22, 2001 8:45 AM
To: Christer Holmberg
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [SIP] Operlap dialing within a SIP network

Hello,

Christer wrote :

>ISSUES NO MATTER WHICH METHOD IS USED:
>--------------------------------------
>
>
>1. We should be allowed to insert Route headers in initial INVITEs
>

ROUTE headers in initial INVITEs are allowed according to the latest
text from J. Rosenberg (I think). Whether or not another domain's proxies
can be guarenteed to honour them is a different matter.

Why is a ROUTE header required in the very first initial INVITE anyway ?

>AND/OR
>
>2. There should be some kind of routing mechnism in the proxis to make
>sure that additional INVITEs are routed to the same gateway.
>

The ROUTE header in 'real' subsequent INVITEs will guarentee that
these INVITEs do follow the same path. The conflict arises when the
subsequent
INVITEs look like initial INVITEs with source routing; back to the above
point.

>3. If a proxy routes additional INVITEs to another gateway, we may get
>multiple IAMs.
>

If source routing cannot be guarenteed to interop between various domains
and INFO method is not to be used then two alternatives are left; either
accept
that some extraneous IAMs are (infrequently ?) generated or mandate that the
UAC always sends the digits en-bloc (wait for stop digit or timer expiry).
The
latter approach
avoids all problems posed by overlap sending and is the most likely to
interop
in all scenarios (vanilla proxies, vanilla clients, application servers
etc..).

>
>At least the two first issues here are general issues for SIP, and not
>only related to the overlap dialing. The third issue is related to PSTN
>interworking in general, because because of forking and/or request
>re-transmission INVITEs may end up at different gateways.
>
>
>ISSUES WITH THE INFO METHOD:
>----------------------------
>
>4. We must wait for the response from the previous request before we
>send an INFO.

I assume you are concerned with the delay in set up because of this. Well,
consider the situation when additional digits are carried in initial
INVITEs; a
domain may require that AAA procedures are performed on all initial INVITEs
which will probably be a bigger drag on set up than waiting for the first
response
using the INFO approach.

>
>5. Requires new extensions (header, option-tags,...?)
>

 >
>ISSUES WITH THE INVITE:
>-----------------------
>
>6. Depending on the number of INVITEs that the gateway mangages to route
>to the next PSTN entity, we will have a number of pending INVITE
>transactions, since we only get a provisional response to those INVITEs
>until one INVITE finaly has enough digits to generate a 200, plus 484
>for all the pending requests.
>

The INVITEs generated by the ingress g/w all belong to the same call and
therefore
the same state machine within the ingress g/w (or a set of associated state
machines); the same applies
to the the egress g/w (assuming all the INVITEs get to the correct g/w).
This is
very much like
multiple INVITEs (subsequent INVITEs allowed before 200 OK) on the same call
leg.
The only thing stopping that approach is current proxies will not handle the
subsequent INVITEs
before 200 OK but perhaps it is something to think about for the future.

>7. One extra message, the ACK, for each INVITE. One ACK is nothing, but
>if you have 20000 of them...
>
>I didn't include the issue of "when a call is completely routed from a
>SIP point of view", because we can spend months arguing about that - and
>I anyway think we should make our solutions depending on what's best
>from a TECHNICAL point of view, not from a definition point of view.
>
>I've said it before, and I'll say it again, that I am not against the
>idea of using INFO. However, I PERSONALY don't think the advantages
>compared to INVITEs are so big that we should spend time on that (we
>MUST, however, clarify the provisional response thing, and which final
>responses will be sent to the pending INVITEs, in the ISUP-SIP draft).
>Instead, I think we should put our efforts on, among other things, the
>general SIP issues (1-3) we have no matter which overlap dialing method
>we have, and which we also have in other SIP scenarios.

I don't think that implementing INFO would be difficult. I also don't think
that
this
approach would be incompatible with existing servers and clients as these
would
use 484/404 if addressed with insufficient digits. However, it is clear that
the
only
problem it is solving is the potential conflict with source routing. I am
coming
to the
conclusion that mandating en-bloc working when sending  into the SIP network
is
the
best, and simplest option; let the initial INVITE be the actual INVITE.

Regards,

K. Robinson

Christer Holmberg <[email-masked]> on 21/02/2001 19:50:59

                                                              

 To:      [email-masked]                             
                                                              
 cc:      [email-masked],                         
          [email-masked], Keith            
          Robinson/MAIN/MC1@MCMAIN, [email-masked],  
          [email-masked]                           

 Subject: Re: [SIP] Operlap dialing within a SIP network      

Hi,

I here try to make some kind of conclusion of the discussion.

ISSUES NO MATTER WHICH METHOD IS USED:
--------------------------------------

1. We should be allowed to insert Route headers in initial INVITEs

AND/OR

2. There should be some kind of routing mechnism in the proxis to make
sure that additional INVITEs are routed to the same gateway.

3. If a proxy routes additional INVITEs to another gateway, we may get
multiple IAMs.

At least the two first issues here are general issues for SIP, and not
only related to the overlap dialing. The third issue is related to PSTN
interworking in general, because because of forking and/or request
re-transmission INVITEs may end up at different gateways.

ISSUES WITH THE INFO METHOD:
----------------------------

4. We must wait for the response from the previous request before we
send an INFO.

5. Requires new extensions (header, option-tags,...?)

ISSUES WITH THE INVITE:
-----------------------

6. Depending on the number of INVITEs that the gateway mangages to route
to the next PSTN entity, we will have a number of pending INVITE
transactions, since we only get a provisional response to those INVITEs
until one INVITE finaly has enough digits to generate a 200, plus 484
for all the pending requests.

7. One extra message, the ACK, for each INVITE. One ACK is nothing, but
if you have 20000 of them...

I didn't include the issue of "when a call is completely routed from a
SIP point of view", because we can spend months arguing about that - and
I anyway think we should make our solutions depending on what's best
from a TECHNICAL point of view, not from a definition point of view.

I've said it before, and I'll say it again, that I am not against the
idea of using INFO. However, I PERSONALY don't think the advantages
compared to INVITEs are so big that we should spend time on that (we
MUST, however, clarify the provisional response thing, and which final
responses will be sent to the pending INVITEs, in the ISUP-SIP draft).
Instead, I think we should put our efforts on, among other things, the
general SIP issues (1-3) we have no matter which overlap dialing method
we have, and which we also have in other SIP scenarios.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor'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" in the body.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 23 Feb 2001 00:44:01 +0200

Hello,

> I agree with Keith that we should mandate en-block due to the following

That's what I proposed in the DC IETF (long time ago), and folks
insisted that overlap dialing had to be supported...

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 23 Feb 2001 14:51:58 +0200

Hello,

I am going to put together a presentation for the next IETF. There we
will choose between a proposed solution for supporting overlap or doing
en-bloc (regular SIP) all the time.

This way we will be able to progress and move on.

See you guys in Minneapolis,

Gonzalo

"Brian F. G. Bidulock" wrote:
> 
> Gonzalo,
> 
> Perhaps those which spoke up at the DC IETF who were requesting
> that overlap dialing be supported could indicate why there is
> a need for overlap dialing.  I know of no need for overlap dialing
> and an explanation of need has not been forthcoming.
> 
> Perhaps the WG chair can ask for any objections to your original
> proposal to mandate en-bloc to see if any rational objections
> exist.
> 
> --Brian
> 
> Gonzalo Camarillo wrote:               (Fri, 23 Feb 2001 00:44:01)
> > Hello,
> >
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/