While sending cancel itself, will specify the transaction that to be
canceled.(suppose consider Invite transaction have to be canceled.cancel
will sent with same transaction ID as of INvite). If cancel is successfully
reached UAS.then UAS will reply with 200 ok.Then will send 487 Request
Treminated for the same.
UAC UAS
> Invite Invite>
------------
>cancel cancel>
<200 ok 200 ok<
<487 Req Ter <487 Req Treminated
Note : cancel should be sent before final response.if not cancel has no
effect.
Please correct me if wrong....
Regards,
Nithya Kumar.
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prabhakaran,
Manikantan
Sent: Tuesday, June 05, 2007 12:10 PM
To: Iliff, Tina; [email protected]; [EMAIL PROTECTED];
Avasarala Ranjit-A20990
Subject: Re: [Sip-implementors] [Sipping] Proxy acting as UAS -- CANCEL
scenario
Hi,
Receiving a 200 OK for the CANCEL only ensures the CANCEL
Transaction has terminated. But what about the INVITE Transaction ? For
the INVITE transaction to be terminated the proxy should responsd with a
487 (Requested Terminated) response.
-Regards
Mani.
________________________________
From: Avasarala Ranjit-A20990 [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 05, 2007 11:59 AM
To: Iliff, Tina; [email protected]; [EMAIL PROTECTED]
Subject: RE: [Sipping] Proxy acting as UAS -- CANCEL scenario
Importance: High
Hi
In ur scenarios, SBC cannot receive 100 Trying, but it should receive
180 Ringing from TUA. Ok say SBC does not receive 180, the SBC will
retransmit INVITE for certain times with timer T1)..
Now say OUA sends CANCEL to proxy and proxy sends 200 OK to OUA - so
here the transaction ends with respect to OUA.
Now Proxy forwards CANCEL to SBC. and
SBC should send 200 OK to proxy.
Finally SBC can send CANCEL to TUA
why should proxy send 487 to OUA? I don't think it is required
amd why should SBC send 408 for the INVITE that does not exist anymore?
Regards
Ranjit
________________________________
From: Iliff, Tina [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 05, 2007 2:08 AM
To: [email protected]; [EMAIL PROTECTED]
Subject: [Sipping] Proxy acting as UAS -- CANCEL scenario
All,
RFC3261 Section 16 states the following regarding Proxy Behavior:
Being a proxy is a logical role for a SIP element. When a request
arrives, an element that can play the role of a proxy first decides
if it needs to respond to the request on its own. For instance, the
request may be malformed or the element may need credentials from the
client before acting as a proxy. The element MAY respond with any
appropriate error code. When responding directly to a request, the
element is playing the role of a UAS and MUST behave as described in
Section 8.2.
Please consider the following call flow scenario:
OUA sends INVITE to Proxy
Proxy sends 100 Trying to OUA
Proxy routes INVITE to SBC
SBC sends 100 Trying to Proxy
SBC routes INVITE to TUA
SBC does not receive 100 Trying from TUA and retransmits INVITE several
times
OUA sends CANCEL to Proxy
Proxy responds to CANCEL with 200OK
Proxy routes CANCEL to SBC
SBC does not route CANCEL to TUA
A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE request to
OUA
Several seconds elapse and Timer B pops on the SBC and it sends a 408
back to the Proxy for the INVITE request
The proxy does not ACK the 408 response; therefore, the SBC retransmits
the 408 for 64*T1 seconds
Note: The SBC is acting as a proxy and not a B2BUA
Question: Is the proxy behaving correctly by sending the 487 response
to the INVITE request on its own?
Regards,
Tina Iliff
_______________________________________________
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
