The phrase states
lower CSeq sequence no. for the first INVITE which implies second
invite has a higher CSeq no?
A UAS that receives a second INVITE before it sends the final
response to a **first INVITE with a lower CSeq sequence number** on the
same dialog MUST return a 500 (Server Internal Error) response to the
second INVITE and MUST include a Retry-After header field with a
randomly chosen value of between 0 and 10 seconds.
More over if it is lower CSeq number why should it include Retry-After since
on all retries it will emit the same response.
- Sp.Raja
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ajit Kalele
Sent: Wednesday, 31 July 2002 11:12 AM
To: Sp.Raja
Cc: Medhavi Bhatia; Sip-Implementors
Subject: Re: [Sip-implementors] re-invite
comments inline ..
> In your case UAS should send 500 to the second INVITE and continue with
the
> first one as usual. Sec 14.2 says
>
> A UAS that receives a second INVITE before it sends the final
> response to a first INVITE with a lower CSeq sequence number on the
> same dialog MUST return a 500 (Server Internal Error) response to the
> second INVITE and MUST include a Retry-After header field with a
> randomly chosen value of between 0 and 10 seconds.
>
> Am I missing any thing ?
No 500 response should not be sent in this case.
The case you have explained is for a request with lower CSeq no. while what
Medhavi has asked is for a proper re-INVITE request (higher CSeq etc.) to a
UAS
which hasn't answered the previous INVITE.
> In section 14.2 of rfc 3261, the spec doesnt seem to talk about
> the following scenario:
>
> A UAS hasnt responded yet to an INVITE or a re-INVITE on the dialog
> (or early dialog), and it receives a new re-INVITE, which is different
> from what was pending (ie., higher CSeq no). The spec forbids the UAC
> (dialog peer)
> from sending a new INVITE before the UAS has responded to the old one, but
> in cases of a misbehaving UAC, what response
> should be sent to the second INVITE ?
481 Call leg / Transaction does not exist.
Here is the text from RFC3261
12.2.2 UAS Behavior
If the UAS wishes to reject the request because it does not wish to
recreate the dialog, it MUST respond to the request with a 481
(Call/Transaction Does Not Exist) status code and pass that to the
server transaction.
Regards
Ajit
*********************************************************
Disclaimer
This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.
*********************************************************
Visit us at http://www.mahindrabt.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
