Subject: [Sipping] Overlap draft

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 5 Jun 2002 13:10:57 +0200

Hello John

I've change the subject of the tread to be more consistent with its content.

Few comments:

>[JRE] No. On receipt of a 180, say, in response to INVITE, the UAC (ingress
>gateway) can issue a CANCEL request on any previous INVITES that have
>received a 100 response but have not received a final response. I don't
>believe this changes the SIP state machine.

That is the fine trick, but I don't see much revenue out of it as at the time of the reception of 180 response all previous INVITES from the ingress GW should be already finished by the fact of the receiving subsequent INVITEs by the egress GW and responding with 484 or 490 to the previous ones. 

I would like to ask the current status of the discussion concerning the routing of the subsequent INVITES in the case if there were no e2e responses to the previous ones.

Greetings,
Denis Alexeitsev

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Jun 2002 14:28:42 +0100

Denis,

Remarks in-line

Regards,

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> -----Original Message-----
> From: Alexeitsev, D [mailto:[email-masked]]
> Sent: 05 June 2002 12:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: Overlap draft
> 
> 
> Hello John
> 
> That is the fine trick, but I don't see much revenue out of 
> it as at the time of the reception of 180 response all 
> previous INVITES from the ingress GW should be already 
> finished by the fact of the receiving subsequent INVITEs by 
> the egress GW and responding with 484 or 490 to the previous ones. 
[JRE] This will normally be the case - the purpose of the CANCEL is to clear
down any that have slipped through the net (e.g., as a result of being
routed to different egress gateways).

> 
> I would like to ask the current status of the discussion 
> concerning the routing of the subsequent INVITES in the case 
> if there were no e2e responses to the previous ones.
[JRE] I am not aware of a mechanism that can ensure identical routing.

---

From: [email-masked]
Date: Wed, 5 Jun 2002 10:28:16 EDT

In a message dated 6/5/02 7:12:09 AM Eastern Daylight Time, 
[email-masked] writes:

> I would like to ask the current status of the discussion concerning the 
> routing of the subsequent INVITES in the case if there were no e2e 
> responses to the previous ones.
> 
> 

As I noted in my comments, Section 3.1 indicates that the ingress gateway 
waits for the minimun number of digits to route a call before sending the 
first INVITE. Therefore, if there are additional digits to pass in new 
INVITES, it is necessary to require that all further INVITES are routed 
exactly the same way in order to prevent multiple IAMs at multiple egress 
gateways. Therefore, in all cases, the new INVITE can directly replace the 
previous and no CANCEL should be needed. There should have already been 484 
responses to the other INVITES.

Mike Pierce
Artel

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 6 Jun 2002 11:43:31 +0200

Hello Mike,
 
some comments inline:
 
Greeting,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Mittwoch, 5. Juni 2002 16:28
An: Alexeitsev, D; [email-masked]
Cc: [email-masked]
Betreff: Re: [Sipping] Overlap draft
In a message dated 6/5/02 7:12:09 AM Eastern Daylight Time, [email-masked] writes: 

As I noted in my comments, Section 3.1 indicates that the ingress gateway waits for the minimun number of digits to route a call before sending the first INVITE. Therefore, if there are additional digits to pass in new INVITES, it is necessary to require that all further INVITES are routed exactly the same way in order to prevent multiple IAMs at multiple egress gateways. Therefore, in all cases, the new INVITE can directly replace the previous and no CANCEL should be needed. There should have already been 484 responses to the other INVITES.  
 
[DA] The overlap draft describes a bit different behaviour, that only after the receiving of the subsequent INVITE the previous one can be answered with 4xx, otherwise if the previous will be already answered with 4xx there will be not a one session with reINVITEs, but a lot of different sessions that have nothing to do with each other. And anyway why should egress gateway answer 4xx to the first INVITE?

---

From: [email-masked]
Date: Thu, 6 Jun 2002 12:39:51 EDT

In a message dated 6/6/02 5:44:46 AM Eastern Daylight Time, 
[email-masked] writes:

> [DA] The overlap draft describes a bit different behaviour, that only after 
> the receiving of the subsequent INVITE the previous one can be answered 
> with 4xx, otherwise if the previous will be already answered with 4xx there 
> will be not a one session with reINVITEs, but a lot of different sessions 
> that have nothing to do with each other. And anyway why should egress 
> gateway answer 4xx to the first INVITE?
> 

I guess this shows some of the confusion with this whole procedure. Yes, I 
could understand why it might be better for the egress gateway to wait for 
the next INVITE before answering the first with a 4xx (for example, 484 
saying address incomplete). The problem is that the egress gateway does not 
know that the ingress gateway is trying to perfom overlap and may send 
another INVITE, so the egress gateway can't wait for another INVITE if it 
knows that the first INVITE didn't have enough digits. It might just be a 
case that the originator didn't dial enough digits and the ingress gateway 
already performed a timeout and decided that the originator was done dialing.

I'm firmly convinced that, if there is a possibility that sucessive INVITEs 
will be routed to different egress gateways, overlap operation must not be 
used.

Mike Pierce

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 7 Jun 2002 09:52:52 +0200

Hello Mike,

some comments inline.

Greeting,

Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Donnerstag, 6. Juni 2002 18:40
An: Alexeitsev, D
Cc: [email-masked]
Betreff: Re: AW: [Sipping] Overlap draft
In a message dated 6/6/02 5:44:46 AM Eastern Daylight Time, [email-masked] writes: 

I guess this shows some of the confusion with this whole procedure. Yes, I could understand why it might be better for the egress gateway to wait for the next INVITE before answering the first with a 4xx (for example, 484 saying address incomplete). The problem is that the egress gateway does not know that the ingress gateway is trying to perfom overlap and may send another INVITE, so the egress gateway can't wait for another INVITE if it knows that the first INVITE didn't have enough digits. 
 
[DA]The basic idea of the overlap draft is that the egress GW can not know whether overlap is used or not (that is absolutely valid). So in my understanding the procedure is as follows:
- If the Egress GW can route the call, it maps INVITE to IAM and sends it to the ISDN without no response. Any subsequent INVITEs (reINVITEs) for the same call will be mapped to the SAMs and will trigger the response to the previous INVITEs with 490.
- If the Egress GW can not route the call, independent from whether the absents of digits was cased by the overlap sending or by the sleeping user, it sends 484 and forgets about the call. Than it is the business of Ingress GW to keep the call info until the IDT expires and if a new address information arrives before the IDT expiration it shall issue the new INVITE (not reINVITE) with the updated number. 

I'm firmly convinced that, if there is a possibility that sucessive INVITEs will be routed to different egress gateways, overlap operation must not be used. 
 
[DA]Absolutely agree, but if the overlap draft as it is today can not guarantee that how it can be used?

---

From: [email-masked]
Date: Fri, 7 Jun 2002 11:05:40 EDT

In a message dated 6/7/02 3:54:54 AM Eastern Daylight Time, 
[email-masked] writes:

> knows that the first INVITE didn't have enough digits. 
> 
> [DA]The basic idea of the overlap draft is that the egress GW can not know 
> whether overlap is used or not (that is absolutely valid). So in my 
> understanding the procedure is as follows:
> - If the Egress GW can route the call, it maps INVITE to IAM and sends it 
> to the ISDN without no response. Any subsequent INVITEs (reINVITEs) for the 
> same call will be mapped to the SAMs and will trigger the response to the 
> previous INVITEs with 490.
> - If the Egress GW can not route the call, independent from whether the 
> absents of digits was cased by the overlap sending or by the sleeping user, 
> it sends 484 and forgets about the call. Than it is the business of Ingress 
> GW to keep the call info until the IDT expires and if a new address 
> information arrives before the IDT expiration it shall issue the new INVITE 
> (not reINVITE) with the updated number. 
> 

[MAP] This is where the basic problem is. If the egress GW can not know 
whether overlap is used or not, then it must assume overlap for every new 
session when it gets the first INVITE. However, in reality, if the egress GW 
is serving a specific part of the PSTN, it can easily know if overlap is 
being used based on the dialing plan. For example, if a GW is handling calls 
terminating in the US, it can examine the digits in the first INVITE and 
immediately know if there are enough. If not, it can simple wait for the rest 
and not send an IAM (according to T1.113, it can not send an IAM, since 
T1.113 does not suport overlap). I believe that this is fast becomg the 
preferred operation in many places as the dialing plans become more uniform.

The operation in the US would be your second bullet above, except that it 
should read "If the Egress GW can not route the call or knows that there are 
not enough digits,..."

In many other cases, the originating point determined that dialing was 
complete, either by digit analysis or by timing, and didn't send the IAM 
until it knew it had the full number. The ingress GW then knew this, but the 
egress GW doesn't.

What is still missing is an explicit indication in the INVITE put in by the 
ingress GW to indicate that overlap is not being used so that the egress GW 
can make rational decisions. As indicated in draft-ietf-sipping-isup-02, the 
called party address in the IAM is translated into a tel URL. Current plans 
to revise the tel:url do not include capabilities to include the "Nature of 
Address indicator" and the "Numbering Plan indicator" from the IAM into the 
tel:url, so this important information would be lost.

> [DA]Absolutely agree, but if the overlap draft as it is today can not 
> 

[MAP] I guess it means it can't be used.

Mike Pierce
Artel

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 10 Jun 2002 17:58:02 +0200

Hello Mike,
 
Few comments inline
 
Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Freitag, 7. Juni 2002 17:06
An: Alexeitsev, D
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: AW: [Sipping] Overlap draft
In a message dated 6/7/02 3:54:54 AM Eastern Daylight Time, [email-masked] writes: 

[MAP] This is where the basic problem is. If the egress GW can not know whether overlap is used or not, then it must assume overlap for every new session when it gets the first INVITE. However, in reality, if the egress GW is serving a specific part of the PSTN, it can easily know if overlap is being used based on the dialing plan. For example, if a GW is handling calls terminating in the US, it can examine the digits in the first INVITE and immediately know if there are enough. If not, it can simple wait for the rest and not send an IAM (according to T1.113, it can not send an IAM, since T1.113 does not suport overlap). I believe that this is fast becomg the preferred operation in many places as the dialing plans become more uniform.  

The operation in the US would be your second bullet above, except that it should read "If the Egress GW can not route the call or knows that there are not enough digits,..."  
 
[DA] Agree with the clarification. In this clarification the bullet two will work for the ANSI networks as well.
 
Also it will be cleaner to say not the new INVITE, but INVITE with the same From-tag, Call-ID and updated Request-URI, as it is not reINVITE yet, but not absolutely new INVITE as well.
 
Are there any overlap draft authors to catch this discussions in the draft document? 

In many other cases, the originating point determined that dialing was complete, either by digit analysis or by timing, and didn't send the IAM until it knew it had the full number. The ingress GW then knew this, but the egress GW doesn't. 

What is still missing is an explicit indication in the INVITE put in by the ingress GW to indicate that overlap is not being used so that the egress GW can make rational decisions. 
 
[DA]Could you clarify that, as the whole idea of the SIP overlap, as it is now, is that nothing in the network knows that there is overlap sending and only the vanilla SIP procedures are used.
 
As indicated in draft-ietf-sipping-isup-02, the called party address in the IAM is translated into a tel URL. Current plans to revise the tel:url do not include capabilities to include the "Nature of Address indicator" and the "Numbering Plan indicator" from the IAM into the tel:url, so this important information would be lost.  
 
[DA] Could you clarify what impact it should have on the overlap draft, as in my understanding the "Nature of Address indicator" and the "Numbering Plan indicator" parameters are never send overlapped.   

[DA]Absolutely agree, but if the overlap draft as it is today can not guarantee that, how it can be used?

[DA] As a proposal for the discussion:
 
It might be put as a requirement, that Egress GW shall always answer with some e2e provisional response (non 100) to the first INVITE, so the Ingress GW could route the subsequent INVITEs to it, if there is a danger of the dynamic routing in the network.

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Jun 2002 16:34:28 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

>I'm firmly convinced that, if there is a possibility that sucessive
>INVITEs will be routed to different egress gateways, overlap operation
>must not be used. 

We tried to ignore the problem, too. It made our lives much easier to
pretend that it just wasn't important.

We got shot down. On the working group list, there was an uproar (check
the archives), but, even more importantly, we had operators pushing back
telling us they flat out would not buy equipment that didn't support
overlap dialing.

So, we (well, a previous incarnation of "we" with whom I am no longer
employed) decided that, given the choice of a proprietary, non-interoperable
solution to the overlap problem was worse than a standardized, interoperable
solution. Hence, it was included in the ISUP work.

If you're really interested in pushing this point, e-mail me privately,
and I'll let you know the names of some of the operators who refused as
clearly as possible to budge on this topic. You can then get back to me
once you've convinced them that they're wrong and you're right. Until
then, the overlap dialing draft fills a very real need.

/a

---

From: [email-masked]
Date: Tue, 11 Jun 2002 10:34:54 EDT

In a message dated 6/10/02 11:59:03 AM Eastern Daylight Time, 
[email-masked] writes:

> <snip>

> hat is still missing is an explicit indication in the INVITE put in by the 
> can make rational decisions. 
> 
> [DA]Could you clarify that, as the whole idea of the SIP overlap, as it is 
> now, is that nothing in the network knows that there is overlap sending and 
> only the vanilla SIP procedures are used.
> 
> As indicated in draft-ietf-sipping-isup-02, the called party address in the 
> IAM is translated into a tel URL. Current plans to revise the tel:url do 
> not include capabilities to include the "Nature of Address indicator" and 
> the "Numbering Plan indicator" from the IAM into the tel:url, so this 
> important information would be lost.  

[MAP] In ITU-T SS#7, the originating exchange inserts an end-of-pulsing (ST) 
at the end of the digit string "whenever the originating exchange is in a 
position to know by digit analysis that the final digit has been sent." If 
carried into the INVITE, the presence of the "ST" in the first INVITE means 
en-bloc. Absence means overlap. In the US SS#7, the ST is not used. The 
requirement, if using the tel:uri, is to be able to explicitly code it to 
indicate that it contains a complete E.164 number (at least as far as the 
originating side knows).

> 
> [DA] Could you clarify what impact it should have on the overlap draft, as 
> in my understanding the "Nature of Address indicator" and the "Numbering 
> Plan indicator" parameters are never send overlapped.   

[MAP] I''m going back through Q.763 and Q.764 and I haven't found an explicit 
statement about the coding of these fields for overlap vs en-bloc. In the US 
standard we haven't cared much since it doesn't include overlap.
> It might be put as a requirement, that Egress GW shall always answer with 
> some e2e provisional response (non 100) to the first INVITE, so the Ingress 
> GW could route the subsequent INVITEs to it, if there is a danger of the 
> 

[MAP] The problem is partly timing, since the INVITES are the result of 
dialing on the originating side, there may be several additional INVITEs on 
the way (and routed differently) before the non-100 to the first INVITE gets 
back to the ingress-GW. No, the ingress GW must know to always do this, but I 
don't know how that can be done. There needs to be some statement like: "The 
ingress GW MUST NOT send the first INVITE until it has collected enough 
digits to ensure that this INVITE can be routed to the appropriate 
destination egress GW or proxy and until the number of digits equals the 
minimum number needed by that destination." Errors can then be treated as 
configuration mistakes that need to be corrected (by humans) before calls to 
that destination can be properly handled. If a later INVITE encounters 
different routing in the network based on more digits, it can be discarded 
(with an error response telling someone to fix the problem).