I agree with your idea that there should be a way by which it should be
ensured that the Nth INVITE reaches after the (N-1)th INVITE, but it is also
mandatory according to the overlapped dialing draft that CANCEL is sent
after the Nth INVITE is sent, in fact the CANCEL should be sent only after a
200 is received for one of the INVITEs.
Quoting from "draft-ietf-sipping-overlap-02"
3.6 Canceling pending INVITE transactions
When a gateway sends a new INVITE containing new digits, it should
not CANCEL the previous INVITE transaction.
.........
.........
However, once a 200 OK response has been received, the gateway should
CANCEL all the other INVITE transactions were generated.
In any case is it valid that an overlapping INVITE is sent before a 100 is
received for the previous 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.
Regards,
Prasanna
-----Original Message-----
From: Ravi Shiroor [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 28, 2002 12:36 PM
To: Prasanna Venkatesh; [EMAIL PROTECTED]
Subject: RE: [Sip] different messages with same call-id before 100 is
sent out
Even in overlapped dialing scenario, the UAC wouldnt(shouldnt)
be sending out a new INVITE before it receives a 484 OR before
it CENCELs the last sent Invite.
(else, it cant make sure that the (N)th INVITE reaches only after
(N-1)th has reached the UAS)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Prasanna Venkatesh
Sent: Wednesday, November 27, 2002 1:51 PM
To: [EMAIL PROTECTED]
Subject: [Sip] different messages with same call-id before 100 is sent
out
Hi,
Are there any specific scenarios where more than one request (from the same
UA) having the same call-id is received by an UAC before it has sent out an
100 for the first request. The message may be of different dialogs and
transactions.
Overlap dialling is one such scenario, are there any other known scenarios
like this?
Regards,
Prasanna
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
