Subject: Re: [Sip] different messages with same call-id before 100 is sent out

From: [email-masked]
Date: Fri, 29 Nov 2002 13:07:51 EST

In a message dated 11/28/2002 5:08:11 AM Eastern Standard Time, 
[email-masked] writes:

> in the overlap case we do not care if the nth INVITE reaches the other
> end before the (n-1)th INVITe, so you do not have to wait for anything
> before sending the new INVITE.
> 
> 

[MAP] This may be true as long as the "other end" knows to throw away the old 
INVITE (with fewer digits). However, I believe that the very fact that 
INVITE's can arrive out of order leads to significant difficulty, since their 
correct interpretation depends on the order.

Going back to some earlier comments, I believe there must be a requirement 
that, for the PSTN-IP-PSTN case (which I think is the focus in this whole 
discussion), that a single IAM received on the ingress side (of IP) must 
result in exactly one IAM being sent on the egress side back to the PSTN. 
There may be fewer (or no) SAMs sent than received, for example, if the IP 
portion, at either the ingress or egress GW, does overlap to en-bloc 
operation, or simply has the smarts to put multiple digits (from SAMs) 
together.

I believe that a solution to meeting this requirement (single IAM) has a 
significant impact on all the other discussions about out-of-order INVITES, 
same or different Call-IDs, etc. Therefore, unless it can be agreed that this 
is a requirement, all the other discussion is meaningless.

I raise this point especially with relation to my proposals in IEPREP for a 
priority-based service for a military application which includes preemption 
in the circuit switched world using SS#7 (MLPP). Multiple IAMs (for high 
priority calls) would have the unacceptable result of preempting calls and 
then releasing the IAM when another arrived (or took another path).

Is it possible to agree that this single IAM rule should be followed?

Mike Pierce
Artel