Igor,
First, if you haven't already, take a look at the
draft-ietf-sipping-dialogusage-05 and
draft-ietf-sipping-race-examples-00, which are pertinent to your case.
I think Brett is on the right track here, but I am inclined to take a
harder line than he is. INFO is considered to be a method that is tied
to the INVITE dialog usage, so it should remain valid as long as that
usage is still valid. The CANCEL shouldn't terminate the usage - it is
the resulting 487 response to the INVITE, that *may* result from receipt
of the CANCEL, that terminates the INVITE transaction and also the
usage. So I don't think it is valid for you to be sending 481 to the INFO.
BUT, if you are going to terminate any resulting dialog asap then there
is probably no great harm in returning 481 to the INFO.
Paul
Igor Vanin wrote:
> Hello, All
>
> My softphone supports incoming requests in outgoing dialogs in early state.
> For example, the following scenario:
> Sent: INVITE
> Received: 183 (INVITE)
> Received: INFO (in the early dialog with the same tags as in 183)
> Sent: 200 (INFO)
> [...]
> Received: 200 (INVITE)
> Sent: ACK
> It's ok.
>
> My question is related to the use case when the caller hangs up (cancels the
> INVITE) before INFO is received:
> Sent: INVITE
> Received: 183 (INVITE)
> Sent: CANCEL
> Received: 200 (CANCEL)
> Received: INFO (with the same tags as in 183)
> My softphone responds to this INFO with the 481 response code because it
> considers that the early dialog and the call were destroyed when the remote
> servers answered to my CANCEL with 200.
> But my users are complaining to this behavior. They want to receive 200 OK
> response to the INFO request.
> What do you think, is this correct? MAY my softphone respond to the INFO with
> 200 response when the initial INVITE was cancelled, or it MUST respond to the
> INFO with 481 response because the early dialog was terminated after
> successfull cancellation?
>
> --
> With best regards, Igor Vanin, St. Petersburg, Russia
> mailto:[EMAIL PROTECTED] http://gpmail.spb.ru
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
