[prev in list] [next in list] [prev in thread] [next in thread]
List: sip-implementors
Subject: Re: [Sip-implementors] Cancel message
From: Biplab Chattopadhyay <biplab () envionetworks ! com>
Date: 2007-10-31 13:52:58
Message-ID: 472885EA.3050405 () envionetworks ! com
[Download RAW message or body]
Nataraju,
I was trying to figure out the condition of the between proxies who will
have one leg as UAC and and other leg as UAS for the CANCEL request,
since CANCEL is hop-by-hop.
Biplab.
nataraju.basavaraju@wipro.com wrote:
> Biplab,
>
> This CANCEL caching would be done by UAC . UAS would just accept or reject the \
> CANCEL depending on the condition. So no additional timer for caching duration is \
> required....
> Thanks,
> Nataraju A B
>
> -----Original Message-----
> From: Biplab Chattopadhyay [mailto:biplab@envionetworks.com]
> Sent: Wednesday, October 31, 2007 1:20 PM
> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier Infrastructure)
> Cc: alex@nablecomm.com; Sreeram Kanumuri (WT01 - TES-Mobility & Carrier \
> Infrastructure); sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Cancel message
>
> Hi all,
>
> Depending on the kind of network, I think the SIP server should do the caching of \
> the CANCEL. For example, in a high speed, reliable enterprise level LAN probably \
> the 100 trying will never hang in air. But, in cases like one explained by Alex, \
> it definitely make more sense to cache the CANCEL. Blind forwarding of the CANCEL, \
> like the one explained by Sreeram, will definitely cause race condition problems.
> But if the server wants to cache the CANCEL, the question here will be - How long? \
> One simple solution is to wait until the original INVITE transaction expires. \
> Which will be (INVITEArrivalTime + INVITETxnTimeout - CANCELArrivalTime). But in \
> heavily loaded networks and core network switches this time may be made \
> configurable to reduce the overhead of storing CANCELs.
> But, can this caching lead to DOS attacks? Any thoughts?
>
> Biplab.
>
> nataraju.basavaraju@wipro.com wrote:
>
> > Comments inline...
> >
> > Thanks,
> > Nataraju A B
> >
> > -----Original Message-----
> > From: sip-implementors-bounces@lists.cs.columbia.edu \
> > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf \
> > Of ? ??
> > Sent: Wednesday, October 31, 2007 7:19 AM
> > To: Sreeram Kanumuri (WT01 - TES-Mobility & Carrier Infrastructure);
> > sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] Cancel message
> >
> > Hi Sreeram and all.
> > First thanks your advice, but about the case "100 trying is on air to caller...." \
> > it could happen well in mobile world so that's not that minor case. And as a \
> > client side developer, I wonder that what are the problems and race conditions \
> > when a server or a terminal received the CANCEL at any time. I'll appreciate if \
> > you let me know that. :)
> > [ABN] one of the scenario I can think of is something like this.
> >
> > UAC UAS
> > -------------INV ->---
> > CANCEL ------------------->
> > <-------------481----------
> > INV reaches UAS now, after CANCEL transaction is completed
> > <------------------180-----
> > <------------------200-----
> >
> > In the above scenario, the UAS is alerting the called party while the UAC \
> > terminated the call... UAC drops the 180 and 200 since the call was terminated by \
> > the UAC upon receiving the 481 for CANCEL UAS is in expectation of ACK/PRACK
> > which would never happen... Since UAC terminated call There is no timer defined @ \
> > UA core to receive the ACK before terminating the call.... This will be in \
> > hanging state...... [/ABN]
> >
> > -----Original Message-----
> > From: sreeram.kanumuri@wipro.com [mailto:sreeram.kanumuri@wipro.com]
> > Sent: Tuesday, October 30, 2007 7:47 PM
> > To: 류 영준; sip-implementors@lists.cs.columbia.edu
> > Subject: RE: [Sip-implementors] Cancel message
> >
> >
> >
> > If the caller did not receive 100, He MUST not sent CANCEL.
> > 100 is hop-to-hop, generally,we will not get a case like "100 trying is on air to \
> > caller...."
> > AKAIK, It is not advicable to keep CANCEL with out 1XX, if we keep CANCEL we have \
> > more race conditions which should be taken into account.
> >
> > -----Original Message-----
> > From: sip-implementors-bounces@lists.cs.columbia.edu \
> > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf \
> > Of ? ??
> > Sent: Tuesday, October 30, 2007 3:21 PM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] Cancel message
> >
> > Yes right in the RFC, but in practice if caller don't send CANCEL
> > while 100 trying is on air to caller, the callee who received INVITE
> > can't realize that call was canceled and would wait until time-outed.
> > That's why caller have to send CANCEL in real situations. (A lot of
> > customers wanted a caller know the callee's cancel right after)
> >
> > -----Original Message-----
> > From: sip-implementors-bounces@lists.cs.columbia.edu
> > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of
> > sreeram.kanumuri@wipro.com
> > Sent: Tuesday, October 30, 2007 6:11 PM
> > To: avinashmv@huawei.com; sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] Cancel message
> >
> >
> > Hi Avinash,
> > If Caller receives 1XX provisional response , He can send CANCEL.
> > Else, He MUST not send CANCEL.
> >
> > HTH,
> > Sreeram.
> >
> > -----Original Message-----
> > From: sip-implementors-bounces@lists.cs.columbia.edu
> > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of
> > Avinash Makam
> > Sent: Tuesday, October 30, 2007 1:24 PM
> > To: sip-implementors@lists.cs.columbia.edu
> > Subject: [Sip-implementors] Cancel message
> >
> > Hi all,
> >
> >
> >
> > Can someone let me know whether caller can send Cancel before he receive any \
> > response from the B2BUA.
> > Since My B2B UA is not processing the CANCEL message sent.
> >
> >
> >
> > Thanks and Regards,
> >
> > Avinash
> >
> > 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!
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> >
> > The information contained in this electronic message and any attachments to this \
> > message are intended for the exclusive use of the addressee(s) and may contain \
> > proprietary, confidential or privileged information. If you are not the intended \
> > recipient, you should not disseminate, distribute or copy this e-mail. Please \
> > notify the sender immediately and destroy all copies of this message and any \
> > attachments.
> > WARNING: Computer viruses can be transmitted via email. The recipient should \
> > check this email and any attachments for the presence of viruses. The company \
> > accepts no liability for any damage caused by any virus transmitted by this \
> > email.
> > www.wipro.com
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> >
> > The information contained in this electronic message and any attachments to this \
> > message are intended for the exclusive use of the addressee(s) and may contain \
> > proprietary, confidential or privileged information. If you are not the intended \
> > recipient, you should not disseminate, distribute or copy this e-mail. Please \
> > notify the sender immediately and destroy all copies of this message and any \
> > attachments.
> > WARNING: Computer viruses can be transmitted via email. The recipient should \
> > check this email and any attachments for the presence of viruses. The company \
> > accepts no liability for any damage caused by any virus transmitted by this \
> > email.
> > www.wipro.com
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> >
> > The information contained in this electronic message and any attachments to this \
> > message are intended for the exclusive use of the addressee(s) and may contain \
> > proprietary, confidential or privileged information. If you are not the intended \
> > recipient, you should not disseminate, distribute or copy this e-mail. Please \
> > notify the sender immediately and destroy all copies of this message and any \
> > attachments.
> > WARNING: Computer viruses can be transmitted via email. The recipient should \
> > check this email and any attachments for the presence of viruses. The company \
> > accepts no liability for any damage caused by any virus transmitted by this \
> > email.
> > www.wipro.com
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
>
>
> The information contained in this electronic message and any attachments to this \
> message are intended for the exclusive use of the addressee(s) and may contain \
> proprietary, confidential or privileged information. If you are not the intended \
> recipient, you should not disseminate, distribute or copy this e-mail. Please \
> notify the sender immediately and destroy all copies of this message and any \
> attachments.
> WARNING: Computer viruses can be transmitted via email. The recipient should check \
> this email and any attachments for the presence of viruses. The company accepts no \
> liability for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic