Subject: [Sipping] AW: Optional optimisation for SIP overlap to ISUP en-bloc (Overla p WG LC)

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 13 Jun 2002 09:55:38 +0200

Hello Mike,
 
some comments inline
 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]
Gesendet am: Mittwoch, 12. Juni 2002 20:44
An: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Alexeitsev, D; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: Optional optimisation for SIP overlap to ISUP en-bloc (Overlap WG LC)
In a message dated 6/12/02 4:53:37 AM Eastern Daylight Time, [email-masked] writes: 

Section 4.1 needs to be rewriten to cover several cases as follows: 

------------------------------------------------------------------------------ 
4.1 Receiving initial and subsequent INVITEs 

Upon reception of the first INVITE, the gateway does the following: 

1. If the egress gateway determines that the number contained in the INVITE is complete by applying digit analysis (or by the presence of an explicit indication in the INVITE?), it MUST generate an IAM and respond to that INVITE with a 100 Trying following the procedures described in [3]. If it receives a subsequent INVITE with the same Call-ID and From tag as the previous one and an updated Request-URI, it MUST respond to the new INVITE with a ___ response. [some final error] and MUST NOT release the previously sent IAM. 

[DA] I think that the case with the End of Dialling sign shall be cleanly processed by the Ingress GW, so that it wont start the IDT (it will be considered as run out) and shall discard any subsequent SAMs, not sending anything to the SIP net. 
 
2. If the egress gateway determines that the number contained in the INVITE is not a complete number and the PSTN it is connected to does not support overlap, the egress gateway SHOULD respond with a 484, Address Incomplete. If it receives a subsequent INVITE, it treats it as if it were the first one.  
 
[DA] I think it will be good to recommend the Ingress GW to keep the same Call-ID and From-tag for the new INVITEs even if they are belonging to the different SIP call setups in this case. It will be useful for accounting, provisioning and so on. 

3. If the egress gateway determines that the number contained in the INVITE is not a complete number or it can not determine its completeness and the PSTN it is connected to supports overlap, the egress gateway SHOULD generate an IAM following the procedures described in [3] containing the digits received in the INVITE. It MUST NOT send any response to this INVITE. 
 
[DA] Do you mean any final, provisional or both? 
 
If it receives a subsequent INVITE with the same Call-ID and From tag as the previous one and an updated Request-URI, it SHOULD generate a SAM containing the new digits. Upon reception of a subsequent INVITE, the INVITE received previously is answered with 490 Request Updated. 

4. Alternatively in cases 2 and 3, the egress gateway MAY perform overlap to enbloc conversion. In this case, it SHOULD wait for a complete number to be received, as determined by digit analysis, timeout after the minimum number of digits, or an explicit indication in the INVITE. After it has received a complete number, the egress gateway MUST generate an IAM following the procedures in [3] and respond with 100. 
----------------------------------------------------------------------------- 

Note that this eliminate the case of multiple IAMs being sent into the PSTN for the same call.  
 
[DA] This works only for the same egress GW, but it does not preclude the dynamic routing to the different egress GWs  

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: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2002 12:22:38 -0500

I think that's probably a good idea.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 1:53 AM
To: 'Adam Roach'; 'Peterson, Jon'; [email-masked]; [email-masked]'
Cc: [email-masked]; [email-masked]; [email-masked]; Mark
Watson; Tom-PT Taylor
Subject: Optional optimisation for SIP overlap to ISUP en-bloc (Overlap WG
LC)

Hi all, 

Apologies for the lateness of this proposal in the WGLC. 

I have a comment on draft-ietf-sipping-overlap00.txt. In section 4.1
"Receiving subsequent INVITEs" I would like to propose an optional
enhancement for the case of a SIP overlap to ISUP en-bloc call where the
gateway has the ability to identify whether or not it has received enough
digits.  The enhancement is fully specified by adding one line of text
(marked [CH]) to the paragraph in section 4.1.

4.1 Receiving subsequent INVITEs 

   An egress gateway does not have any means to know whether SIP 
   overlap signalling is being used or not. So, upon reception of an 
   INVITE, the gateway generates an IAM following the procedures 
   described in [3]. 

   If a gateway receives a subsequent INVITE with the same Call-ID and 
   From tag as the previous one and an updated Request-URI, a SAM 
   should be generated as opposed to a new IAM. Upon reception of a 
   subsequent INVITE, the INVITE received previously is answered with 
   490 Request Updated. 

   If the gateway is attached to the PSTN in an area where en-bloc 
   signalling is used, a REL for the previous IAM and a new IAM should 
   be generated.  

[CH] "As an option, if the gateway can determine that there are too few
digits received in the INVITE for the call to be routed "en-bloc" to the
ISUP network then the gateway shall respond with a 484 Address Incomplete."
[CH]

Comments? 

Thanks 

Chris Hogg 
Nortel Networks

---

From: "Chris Hogg" <[email-masked]>
Date: Thu, 13 Jun 2002 15:39:25 +0100

Hi Mike,

Thanks for the comments.  More comments below.

Comments welcome.

Thanks,

Cheers
Chris.

>I think your added sentence is an important part of the fix, but the
overall description 
>needs to be corrected. (The first sentence of the section contradicts your
sentence.) 

I see what you mean.  We can get round this by deleting the first sentence
of section 4.1 so that it would read as follows.  This still leaves in the
functionality that (in the non-optimized SIP overlap to ISUP en-bloc case)
IAMs are still sent out every time an INVITE is received and upon receipt of
a new INVITE (same Call-ID and from-tag) the gateway sends back a 490 and
issues an REL for the previous IAM and a new IAM.

   Upon reception of an INVITE, the gateway generates an IAM following the
procedures 
  described in [3]. 

[CH] "As an option, (in the case of SIP overlap to ISUP en-bloc) if the
gateway can determine that there are too few digits received in the INVITE
for the call to be routed "en-bloc" to the ISUP network then the gateway
shall respond with a 484 Address Incomplete." 
[CH] 

Some comments on your proposed wording also included below:

1. If the egress gateway determines that the number contained in the INVITE
is complete by applying digit analysis (or by the presence of an explicit
indication in the INVITE?), it MUST generate an IAM and respond to that
INVITE with a 100 Trying following the procedures described in [3]. If it
receives a subsequent INVITE with the same Call-ID and From tag as the
previous one and an updated Request-URI, it MUST respond to the new INVITE
with a ___ response. [some final error] and MUST NOT release the previously
sent IAM. 

[CH] If the gateway has already determined that the number contained in the
INVITE is complete then subsequent new INVITEs (with same Call-ID and
from-tag and updated request-uri) should not be received in this case.
(Certainly, the ingress gateway in an ISUP->SIP->ISUP call should not
receive any more SAMs (which generate the new INVITEs) if the egress gateway
has determined that the number is complete).  I agree that if this scenario
were to happen then the IAM should not be released and some final error
response should be sent backwards. However, I don't understand the scenarios
under which such a situation can occur.

2. If the egress gateway determines that the number contained in the INVITE
is not a complete number and the PSTN it is connected to does not support
overlap, the egress gateway SHOULD respond with a 484, Address Incomplete.
If it receives a subsequent INVITE, it treats it as if it were the first
one. 

[CH] ok, similar to what I was describing.

3. If the egress gateway determines that the number contained in the INVITE
is not a complete number or it can not determine its completeness and the
PSTN it is connected to supports overlap, the egress gateway SHOULD generate
an IAM following the procedures described in [3] containing the digits
received in the INVITE. It MUST NOT send any response to this INVITE. If it
receives a subsequent INVITE with the same Call-ID and From tag as the
previous one and an updated Request-URI, it SHOULD generate a SAM containing
the new digits. Upon reception of a subsequent INVITE, the INVITE received
previously is answered with 490 Request Updated. 

[CH] If the gateway is connected to a PSTN overlap network then it doesn't
matter whether or not the egress gateway can determine if the number is
complete - it just sends out the IAM in response to the first INVITE and
then the SAMs in response to subsequent INVITEs.  It only needs to determine
whether or not the number is complete if the optional optimisation is being
used in the case of SIP overlap to ISUP en-bloc so that the gateway doesn't
send an IAM (and then subsequently send REL and a new IAM) every time an
INVITE is received. 

4. Alternatively in cases 2 and 3, the egress gateway MAY perform overlap to
enbloc conversion. In this case, it SHOULD wait for a complete number to be
received, as determined by digit analysis, timeout after the minimum number
of digits, or an explicit indication in the INVITE. After it has received a
complete number, the egress gateway MUST generate an IAM following the
procedures in [3] and respond with 100. 

----------------------------------------------------------------------------
- 

Comments?

Thanks,

Cheers
Chris.

---

From: [email-masked]
Date: Thu, 13 Jun 2002 17:16:31 EDT

In a message dated 6/13/02 10:39:57 AM Eastern Daylight Time, 
[email-masked] writes:

> [MAP's original proposal] 4.1 Receiving initial and subsequent INVITEs 
> 

[MAP] But the situation that may always exist is that the ingress and egress 
gateways "think" something different. The ingress doesn't know if it needs 
more digits, so it's trying overlap, and the egress knows it has enough with 
the first INVITE. The egress should send the 100 as an "end-of'-dial" 
indication, but it can still get more INVITEs due to the timing. We just need 
to make sure they are ignored properly.

> response should be sent backwards. However, I don't understand the scenarios

[MAP] Suppose that all the ingress GW knows is that the destination city uses 
a minimum of 7 and maximum of 9 digits (after the country and city codes). 
When the originator has dialed the 7 digits, the first INVITE is sent. The 
egress GW may have more information about the dial plan in the destination 
city and know immediately that this 7 digits is a complete local number 
(typically known by the first couple digits of the 7-digit local number), so 
it sends it forward to the PSTN en-bloc. Meanwhile, the originator dials an 
extra digit by mistake. Somehow, the network needs to ignore that extra 
digit. The originating side doesn't realize it and sends a new INVITE (since 
it hasn't got the 100 yet). The egress GW has to be smart enough to ignore 
the extra digit and let the ingress know which INVITE was correct. (The draft 
seems to assume that the one with the most digits was correct.)

> send an IAM (and then subsequently send REL and a new IAM) every time an

[MAP] Yes, I think that is generally correct. If using overlap into the PSTN, 
the egress GW could ignore the issue of end of dial, until it gets the 
explicit indication from the PSTN. However, since there is a known maximum 
length to the international number, it could also quit after it reaches that 
number. However, I believe that one of the uses of overlap in the past was to 
allow more digits to be transferred than the agreed maximum number (used to 
be 12 and now 15). That could be a case in which the data controlling the 
function would say that the maximum was really more than the 15 allowed. I 
don't think anyone would want it to be completely unlimited. Q.764 is a 
little ambiguous on this same point, saying that end-of-dial may be 
determined at the originating exchange by digit analysis which may consist of 
counting the maximum number of digits or maybe not.

[MAP] I guess by "optional optimisation" you mean the conversion from overlap 
within SIP to en-bloc at the egress GW.

> procedures in [3] and respond with 100. 

Mike Pierce
Artel

---

From: [email-masked]
Date: Thu, 13 Jun 2002 17:17:07 EDT

> ection 4.1 needs to be rewriten to cover several cases as follows: 
> 
> 
> 
> 
> [DA] I think that the case with the End of Dialling sign shall be cleanly 
> processed by the Ingress GW, so that it wont start the IDT (it will be 
> considered as run out) and shall discard any subsequent SAMs, not sending 
> 

[MAP] Yes, part of the solution is for the ingress GW to do specific things 
concerning the end of dial and communicate what it knows (or thinks) to the 
egress GW in the INVITE. The processing of ISUP (e.g., discarding subsequent 
SAMs after a timeout) is covered by Q.764.

> [DA] I think it will be good to recommend the Ingress GW to keep the same 
> Call-ID and From-tag for the new INVITEs even if they are belonging to the 
> different SIP call setups in this case. It will be useful for accounting, 
> 

[MAP] Absolutely, keeping the same Call-ID and From-tag (and whatever else 
associates the new INVITE with the previous) is an important part of the 
solution. I'm not sure what you mean by "even if they are belonging to the 
different SIP call setups". Could there be a case in which the ingress GW 
sends an INVITE with some of the digits, and then, when it gets more digits, 
it decides to release the first call attempt and start a new one? If so, this 
would be a "different SIP call setup". But I see this as not being needed, 
since the ingress GW should always wait for the minimum number of digits 
before sending the first INVITE, meaning that the destination has already 
been determined.

> PSTN it is connected to supports overlap, the egress gateway SHOULD 
> generate an IAM following the procedures described in [3] containing the 
> digits received in the INVITE. It MUST NOT send any response to this 
> INVITE. 
> 
> 

[MAP] Yes, I believe that is what the draft says for this case, but there is 
some confusion on this. Part of the problem is that any response sent would 
likely get to the ingress gateway after the ingress GW has already sent 
another INVITE. The point I'm making is that the ingress GW should know what 
it is doing and not need any response. 484 is used in case 2 above as a 
"final" response, since there is a mis-match between ingress and egress. Case 
3 doesn't need any provisional response since the ingress GW is doing just 
fine and the 490 response (for one INVITE) occurs when the next INVITE 
arrives. Even here, the response is there only to satisfy the protocol 
(terminate a transaction?). The call handling logic doesn't need it.

> If it receives a subsequent INVITE with the same Call-ID and From tag as the 
> previous one and an updated Request-URI, it SHOULD generate a SAM 
> containing the new digits. Upon reception of a subsequent INVITE, the 
> INVITE received previously is answered with 490 Request Updated. 
> 
> 4. Alternatively in cases 2 and 3, the egress gateway MAY perform overlap 
> to enbloc conversion. In this case, it SHOULD wait for a complete number to 
> be received, as determined by digit analysis, timeout after the minimum 
> number of digits, or an explicit indication in the INVITE. After it has 
> received a complete number, the egress gateway MUST generate an IAM 
> following the procedures in [3] and respond with 100. 
> 
> 
> [DA] This works only for the same egress GW, but it does not preclude the 
> dynamic routing to the different egress GWs  

[MAP] Yes, additional provisions need to be defined to prevent different 
dynamic routing. I think this is possible.

[MAP] I'm currious, do you know if overlap is an important capability within 
Germany? If so, do you see it as being required because of the variable 
length numbers or because of slow signaling systems at the destination?

Mike Pierce
Artel