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

From: Prasanna Venkatesh <[email-masked]>
Date: Mon, 02 Dec 2002 09:38:01 +0530

Hi Gonzalo,
    I also agree to Mike's suggestion.  Can't a recommendation be made on
the INGRESS GW that the CSeq for an overlapped dial message should
monotonically increase, though each of the INVITEs constitute a different
dialog.  This can help the EGRESS GW to drop out-of-order INVITEs.
Regards,
Prasanna
Huawei Technologies.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, November 29, 2002 11:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] different messages with same call-id before 100 is sent
out

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Dec 2002 09:37:45 +0200

Hi,

It has been explained several times why you cannot force the subsequent
INVITEs to follow the rute that the first one followed. You can find the
discussions in the archives or in the slides I presented in Australia.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Dec 2002 09:45:56 +0200

Hi,

The recommendation about using increasing Cseqs is already in the draft.

5th paragraph of section 3.3

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip