Hi, >Just combining both the discussions here. >----------------------------------------- > >[EMAIL PROTECTED] wrote >>If the call has been forked, and provisional responses with multiple >>to-tags have been sent back to the UAC, then it is certain that the UAC has *some* resources tied up with each early >>dialog. The 199 will allow some of that to be released. >> >>Are you suggesting that the UAC indicate if it considers those >>resources to be sufficient to justify processing an extra message? Or >>maybe you are just concerned with the likelihood that the UAC doesn't >>support 199, so that the message will just be ignored in any case? >> >> I could go either way on this one. >> >> Paul >> >[EMAIL PROTECTED] wrote >>Right - Require is inappropriate. Supported is certainly possible. I >>think it would simply mean that the UAC understands the significance of >>199 and so is prepared to take advantage of it if received. I see no >>reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - >>rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much > > sense. > > >[Ashish Saxena] I am concerned about both (justify processing of an extra message & UAC does not support 199). I brought >up this discussion with the assumption that UAC (mostly) is in better situation to understand about resources reserved at >its end. But Christer pointed out that even intermediate entities may also be interested in releasing resources asap. So >if an entity knows that it has reserved resources and would appreciate if they can be relinquished earlier, then it can >simply put "Supported" header to indicate entities downstream that it can handle 199. This is why I was suggesting it to >be call by call basis.
[CHH] Sure, if it's ok to say that an intermediate can add an option-tag to the Supported header. >But with Paul's reasoning, it will be good to have for all calls. It is easier to implement also. (otherwise UAC will >have to put extra intelligence to calculate whether it needs 199 in this call). > > IMO, Supported header will > > a) Will stop proxies sending 199 because they would already know that UAC does not understand it anyways. If an intermediate inserts the option-tag in the Supported header the UAC would of course still get the 199. > b) Reduce some 199s on network because of (a). [CHH] I don't have any strong feelings whether we define an option-tag or not. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 9:20 PM To: Christer Holmberg Cc: Avasarala Ranjit-A20990; Ashish Saxena (WT01 - Telecom Equipment); [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Right - Require is inappropriate. Supported is certainly possible. I think it would simply mean that the UAC understands the significance of 199 and so is prepared to take advantage of it if received. I see no reason why you would change it on a call by call basis. The resources aren't committed at the time of the INVITE - rather at the time the provisional response is received, so doing on a per-call basis wouldn't make much sense. Paul Christer Holmberg wrote: > Hi, > >> Can we use Require:199 to indicate to proxy to send 199? > > No. The Require header is only applicaple to a UAS. > > You can use Proxy-Require for proxies, but the problem is that you would > require this from EVERY proxy in the path. > > Regards, > > Christer > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Monday, June 23, 2008 10:24 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Probably everybody is busy. Any thoughts on this one. > > > Best Regards, > Ashish Saxena > 877-5570 > > -----Original Message----- > From: Ashish Saxena (WT01 - Telecom Equipment) > Sent: Friday, June 20, 2008 10:56 AM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > Hi Christer, > From Section 4 (Client Behaviour) part of this draft, I understood > that primary objective of this draft is to give indication to > UAC to release resources, if any. I am little worried about extra > messaging that will be seen because of 199 implementation. Can there be > a way to tell proxies and UAS downstream that UAC has some resources > reserved for this call and would be interested in receiving 199, if > possible? > > IMO, UAC (mostly) is in better understanding of the resources that it > has reserved for a particular call. So UAC can selectively add something > in INVITE to tell downstream proxies/ UAS' about its interest. > > IMO, we can have a package for 199 and UAC can use "Supported" header to > indicate entities downstream that it would be interested in getting 199 > for this *particular* call. Implicitly it would mean that UAC has > reserved some resources. I understand that we would changing the meaning > of "Supported" header on per call basis :-(. Something else may be? > > Comments please. > > Best Regards, > Ashish Saxena > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip Use > [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > [EMAIL PROTECTED] for questions on current sip Use > [EMAIL PROTECTED] for new developments on the application of sip > Please do not print this email unless it is absolutely necessary. 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 mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
