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

From: [email-masked]
Date: Wed, 12 Jun 2002 14:44:01 EDT

In a message dated 6/12/02 4:53:37 AM Eastern Daylight Time, 
[email-masked] writes:

> 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 
> 
> 
> 
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.

Mike Pierce
Artel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 13 Jun 2002 16:39:42 -0400

It would appear that the egress GW can determine that overlap signaling is 
being used by analysis of the incomplete received called number.

It would be useful is there is some way that the egress GW could signal the 
ingress GW that overlap was not supported (in the destination PSTN) so the 
ingress could do the overlap to enbloc conversion.  That would save a lot 
of SIP signaling and wasted work at the egress GW.  Point 4. below would 
not be necessary.

I had thought I had seen a way based on receiving different response 
codes.  Upon receipt of the 484 can this be assumed?

Mike

At 02:44 PM 6/12/2002 -0400, [email-masked] wrote:
>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.)
>
>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.
>
>Mike Pierce
>Artel

_______________________________________________
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