Subject: [Sipping] Re: Optional optimisation for SIP overlap to ISUP en-bl oc (Overlap WG LC)

From: Horvath Ernst <[email-masked]>
Date: Thu, 13 Jun 2002 10:21:49 +0200

Mike,

see comment inline.

Ernst Horvath
Siemens AG

> -----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: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Betreff: [Sipping] Re: Optional optimisation for SIP overlap to ISUP
> en-bloc (Overlap WG LC)
> 
> 
>[...] 
> 
> 
> 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.) 
> 
> 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. 
> 
> 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. 
> 
> 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. 
> 
> 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. 
> 

[EH] Not necessarily, if there are several gateways into the PSTN. A
subsequent INVITE may end up on a different gateway than the previous one
and will be treated as an initial INVITE. The gateway has no knowledge of
the previous call attempt and will send a new IAM into the PSTN. Eventually
only the final call attempt with the complete number will succeed, any
others should time out. But they occupy resources for some time. 

> Mike Pierce 
> Artel