-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz 
Castillo
Sent: Thursday, August 14, 2008 4:08 PM
To: [email protected]
Subject: Re: [Sip-implementors] About CANCEL proccesing in a UAS

El Thursday 14 August 2008 05:44:42 Rockson Li (zhengyli) escribió:

> > 2) - UAS receives a CANCEL for an INVITE transaction for which UAS 
> > has already sent a final response. In this case RFC3261 says:
> >
> >    "the CANCEL
> >    request has no effect on the processing of the original request, no
> >   effect on any session state, and no effect on the responses generated
> >    for the original request."
> >
> > - But should UAS reply a 4XX?

> [RL] since INVITE server transaction would be terminated on delivery 
> of 2xx, so I think CANCEL cannot match any to-be-cancelled 
> transaction, so 481 would be sent.

But what about if the final response was [3456]XX ?

[RL] again 200(CANCEL) is sent, since server transaction is matched, this is 
the only criteria in spec, nothing to do the final resp UAS sent.


> However, draft-sparks-sip-invfix intends change INVITE trasanction , 
> so I think 200(CANCEL) will be sent after this draft is accepted to 
> update RFC3261.

Thanks, I must re-read it.


> 3) UAS receives a CANCEL that matches an active NON-INVITE 
> transaction. RFC
> says:
>
>     "A CANCEL request has no impact on the processing of
>      transactions with any other method defined in this specification
>      (INVITE)".
>
> - Which response should UAS sent? a 481? a 400?
> [RL] I think 200(CANCEL) will be sent since rfc says
>
>    "Regardless of the method of the original request, as long as the
>    CANCEL matched an existing transaction, the UAS answers the CANCEL
>    request itself with a 200 (OK) response. "
>
> 200 only means CANCEL is reached at UAS, it does not mean anything 
> previous transaction would be cancelled. We can send 200 for 
> acknowledge CANCEL, but continue processing non-INVITE req without any impact.

Ok.



Thanks a lot.

--
Iñaki Baz Castillo
[EMAIL PROTECTED]

_______________________________________________
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

Reply via email to