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

From: "Keith Robinson" <[email-masked]>
Date: Thu, 22 Feb 2001 13:44:45 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Feb 2001 00:32:17 +0200

Hi,

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

It's not required in the FIRST initial INVITE.

>and INFO method is not to be used then two alternatives are left;

This may happend even if INFO is used, since the first INVITE having
enough digits to
generate IAM may be forked and reach two different gateways. I think,
however, that this is more
an issue of how the operator confiugres his proxies, DNS, etc.

>either accept that some extraneous IAMs are (infrequently ?) generated or mandate that the
>latter approach avoids all problems posed by overlap sending and is the most likely to interop

I guess this also depends very much on the requirements, and the
functionality provided, by your gateway.

For example, if all your INVITEs go to the same domain (ie the name host
name) you MAY send the first INVITE as soon as you get the first digit.
This will, however, generate LOTS of traffic, so I would assume that
most gateways have some kind of dialing plan/digit timer for the
outgoing SIP calls. This is also needed if INVITEs can be sent to
different domains depending on the user number. For example, 12345 may
be sent to sip:[email-masked], 12777 to
sip:[email-masked], and all 1800 numbers may be sent to some
redirect server that then returns a real phone number. In this case, the
UAC gateway will have to wait for a number of digits from PSTN before
the first INVITE can be sent.

>response using the INFO approach.

This is true, but I think this is also much depending on how the network
is configured, if the UAC
gateway has some kind of dialplan etc etc etc. For example, you could
agrue, like for the routing case, that INVITEs that look similar (only
the To header and Request-URI has changed) will not require AAA
procedures...
 
>therefore the same state machine within the ingress g/w (or a set of associated state
>machines);

Yes, but they are still separate transactions, which all have to be
finished and ACKed.

>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.
>this approach would be incompatible with existing servers and clients as these would
>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.

If you can implement this for all the scenarios in the world we would
never have to use overlap dialing. And, I  don't think that overlap
dialing will be used that much, but since it CAN be used we should make
sure it works.

I also think this is one case where experience will show how it works,
since there are no rules saying how an operator has to configure his
proxies, AAA etc.

Regards,

Christer Holmberg
Ericsson Finland