hi,
Do find answers to some of the questions inline.
----- Original Message -----
From: Richard Aas <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 06, 2002 10:31 PM
Subject: [Sip-implementors] UAC behavior
> I'm implementing a SIP UAC (UDP unicast only) and have the following
> questions:
>
> PS. I'm using RFC 2543 as the standard (not the drafts).
>
> After issuing an INVITE and receiving a >=300 response , should there be
> any wait-state (before I forget all params for this call) to
> compensate for lost ACK's? I see something like that in the state
> transition diagram for clients's but it looks like this only applies to
> proxies?
Yes, you need to maintain state (wait-state) after receiving a final
response to the INVITE. This is so that
you are able to send the same ACK if you were to receive the final response
on account of the ACK getting lost or because of the ACK and the final
response passing on the wire. I am not very sure about the time, but i think
it is 32 seconds.
> After issuing a CANCEL request for a pending INVITE, and after having
> received a final response for the CANCEL request, should I enter the
> same wait-state here to ACK final responses to the INVITE being
> canceled? I have noticed that some useragents responds 487 Request
> Canceled to the canceled INVITE. How should I approach this to be
> RFC 2543 compliant?
>
> In case of a wait-state how long should it be?
The handling of the INVITE message is not affected by the response
to the CANCEL message. In other words, even if you get a 200 for the CANCEL,
it does not mean that the call got cancelled. It is the response to the
INVITE that decides this. If you get a 487 to the INVITE, the call is
cancelled and if you get a 200 for the INVITE, the call is on inspite of
receiving a 200 for the CANCEL. This behaviour is because of the CANCEL
request being hop-to-hop.
So, to answer your question, the handling of the INVITE does not
change on account of you sending a CANCEL.
Hope this helped.
regards,
Gautham A. N.
_______________________________________________
> 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
