Subject: Re: [Sipping] Re: Optional optimisation for SIP overlap to ISUP en-bl oc (Ove...

From: [email-masked]
Date: Thu, 13 Jun 2002 10:40:26 EDT

In a message dated 6/13/02 9:08:32 AM Eastern Daylight Time, 
[email-masked] writes:

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

Yes, this is a problem that needs to be dealt with if this is going to be 
acceptable to interwork with the PSTN. Rule is, each call originated must 
result in exactly one call going through the PSTN at a time. There can not be 
parallel call attempts being setup. I will propose a more complete solution 
than in my previous e-mail, which only gave details of what the egress 
gateways does (which can not prevent this situation).

Question is, do people agree that this situation must be avoided?

Mike Pierce
Artel

---

From: [email-masked]
Date: Thu, 13 Jun 2002 12:25:54 -0400

What is the probability of this occurring?

What is the cost in terms of the PSTN network when it does occur?

What is the cost in terms of complexity of the protocol and in terms of
interactions for a solution for
a) situations when the problem would occur if not for the solution?
b)  situations in which the problem would not occur

[email-masked]@ietf.org on 06/13/2002 10:40:26 AM

Sent by:  [email-masked]

To:   [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked]
cc:   [email-masked], [email-masked],
      [email-masked], [email-masked]
Subject:  Re: [Sipping] Re: Optional optimisation for SIP overlap to ISUP
      en-bl oc (Ove...

Yes, this is a problem that needs to be dealt with if this is going to be
acceptable to interwork with the PSTN. Rule is, each call originated must
result in exactly one call going through the PSTN at a time. There can not
be parallel call attempts being setup. I will propose a more complete
solution than in my previous e-mail, which only gave details of what the
egress gateways does (which can not prevent this situation).

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

---

From: [email-masked]
Date: Fri, 14 Jun 2002 12:39:02 EDT

In a message dated 6/13/02 12:26:27 PM Eastern Daylight Time, 
[email-masked] writes:

[MAP] The probability is unknown, since it depends on the configuration data 
in many gateways and other equipment that controls routing.

> What is the cost in terms of the PSTN network when it does occur?

[MAP] It leads to ineffective attempts which use up resources. The PSTN has 
always been designed to avoid these.

> b)  situations in which the problem would not occur

[MAP] I believe there is no cost in "complexity" to prevent the problem. In 
fact, I believe the complexity lies in trying to handle all the cases. I 
think the solution is saying that certain situations are not allowed, since 
there is no known use for them. For example, sending the first INVITE before 
the minimum number of digits has been received, only to have to later send 
another INVITE with enough digits (which may result in different routing).

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

---------------------------------
 
> [MAP] Yes, this is a problem that needs to be dealt with if this is going 
> to be