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

From: "Ravi Shiroor" <[email-masked]>
Date: Thu, 28 Nov 2002 15:14:25 +0530

Switching from SIP to SIPPING....

Not caring about the order of receiving INVITEs at the
UAS may possibly lead to errors.

Two things I think may be wrong.

1. Section 4.1 says that a NEW SAM should be sent out for
every subsequently received INVITE, which is wrong if the
N-1 th INVITE arrives later than Nth. (because it wont
have any extra address info in it to send)

2. Section 4.1 says that when a subsequent INVITE is received,
all the previous INVITES should be replied with a 484.
This will result in a 484 will be sent for the N th INVITE
when N-1 th INVITE arrives, even though N th INVITE had
correct and complete set of digits.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Thursday, November 28, 2002 2:57 PM
To: Prasanna Venkatesh
Cc: Ravi Shiroor; [email-masked]; [email-masked]
Subject: Re: [Sip] different messages with same call-id before 100 is
sent out

Hi,

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.

> Coming back to the original question, what are the conditions that an
INVITE
> can be received before 100 is sent for a pending INVITE, both bearing the
> same call-ids but belonging to different dialogs.

the only proposal I am aware of that uses the same Call-ID for different
dialgogs is the overlap draft. Therefore, (if we forget about overlap)
it is unlikely that you receive two INVITEs with the same Call-ID that
belong to different dialogs.

If both INVITEs come from different UACs, the Call-ID will be different,
since they typically use the something@host format.

And if both INVITEs come from the same UAC, it will make sure that the
Call-IDs are different.

Regards,

Gonzalo

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 28 Nov 2002 13:13:40 +0200

Hi,

The draft explains that the gateways have to take into account that the
INVITE with more digits is not necessarily the one that will succeed.

And the egress gateway needs to be intelligent and notice if it has
already sent a SAM when it receives the (n-1)th INVITE.

regards,

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
_______________________________________________
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: "Ravi Shiroor" <[email-masked]>
Date: Fri, 29 Nov 2002 11:19:29 +0530

my comments inline. marked as "ravi>".

regards,
ravi.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Gonzalo Camarillo
Sent: Thursday, November 28, 2002 4:44 PM
To: Ravi Shiroor
Cc: [email-masked]
Subject: Re: [Sipping] RE: [Sip] different messages with same call-id
before 100 is sent out

Hi,

ravi> explaining that "INVITE with more digits is not necessarily
ravi> the one that will succeed" doesnt seem to help in this
ravi> situation.
ravi>
ravi> I agree with you. As you say, if the egress gateway uses
ravi> its intelligence, instead of following the section 4.1
ravi> word to word, this may be avoided.
ravi> The egress gateway should use a logic that if one of the
ravi> INVITEs has already succeeded, then if any more INVITEs
ravi> arrive, they should just be neglected. Or it should neglect
ravi> any INVITEs that have a lower CSeq than the one that were
ravi> previously received.

regards,

Gonzalo