No Subject

Regards,

Christer Holmberg
Ericsson Finland




> 
> Is there some nuance missing?
> 
> Mike
> 
> At 11:30 AM 6/26/2001 +0300, Christer Holmberg wrote:
> 
> >Hi,
> >
> >Some thoughts/issues came to my mind when I read the thread (the SIP
> >implementors list) about using CANCEL for specific call-legs.
> >
> >I KNOW we have spent lots of time discussing this, but I am not pretty
> >sure that we have really thought about all the scenarios when some of
> >the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
> >PRACK- and pre-call-setup requests features, and the scenario where the
> >UAC wants to choose specific call-legs for a call).
> >
> >Instead, I think we mostly have assumed that a call setup is simply an
> >INVITE, possible provisonal responses, and one or many final responses
> >plus their ACKs, and in those cases I don't think we have any major
> >problems.
> >
> >I even think some of the extensions may LOOSE some of the good stuff
> >they are supposed to provide due to these issues.
> >
> >
> >Issue 1: Caller preferences
> >
> >The Caller preferences feature allow the UAS to indicate the feature
> >parameter in the response. The draft mentions the 200 response, but I
> >guess it is (at least it should be) allowed also in a provisional
> >response with a To-tag and Contact header. So, now the UAC may at a very
> >early stage of the call setup find out about what kind of servers it has
> >received provisional responses from, which means it may at a very early
> >stage find out that it does not want a specific call-leg (for example,
> >one could receive provisional responses from two different answering
> >machinges, or something...). However, the UAC is not able to cancel any
> >call leg (without terminating the whole call setup) before it has
> >received a final response from one UAS, which means it may have to
> >handle PRACKs, INFOs, and who knows what, with all servers - also those
> >it will never establish a call with. A solution to this could be to
> >allow CANCEL for a specific leg (assuming that the provisional responses
> >included a To-tag and Contact). If PRACKs (or other requests used before
> >the call is setup) are involved, the provisinal responses most likely
> >will include the tag and Contact, so...
> >
> >
> >Issue 2: Multi-leg call
> >
> >This could be related to the previous issue, but it can also be a "stand
> >alone" issue. Again, a UAC may receive multiple provisional responses.
> >It is going to establish a multi-leg call, ie it is going to accept a
> >specific set of final responses. Again, however, it receives provisonal
> >responses also from other servers, but again - it is not able to cancel
> >those legs before it has received the final responses for ALL parties
> >that will be in the multi-leg call. Allowing CANCEL for a specific leg
> >would help also here.
> >
> >What also may happen here, is that we receive a final response for a leg
> >that we do NOT want in the call, but we still want to wait for another
> >final response. Now we could simply ACK and BYE that leg, but then we
> >come to the issue about sending BYE requests before the whole call has
> >been setup. However, the bis DOES say that BYE is used to terminate an
> >established call-leg, and that is what we would be doing here - no
> >matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
> >says "To terminate a call instead of just pending searches, the UAC must
> >use BYE instead of or in addition to CANCEL". So, I guess some
> >clarifications in the bis may be needed here.
> >
> >
> >
> >Conclusion:
> >
> >So, I don't know if we are talking about changes, or simple
> >clarifications, in the spec, but the issues are:
> >
> >1. Should we allow CANCEL for a specific call-leg, IF we have received a
> >To-tag and Contact in the provisional response?
> >
> >2. Should we allow BYE for an established call-leg, even if the whole
> >call is yet not setup (the UAC is waiting for another final response)?
> >
> >I know that we have the issue about a UAS receiving the same request
> >from different locations (when the request has been forked), so we have
> >to find out in which scenarios this can be a problem, and how likely it
> >is that those scenarios will take place.
> >
> >
> >Comments?
> >
> >Regards,
> >
> >Christer Holmberg
> >Ericsson Finland
--------------657BAFA4789D36A1375A6768
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------657BAFA4789D36A1375A6768--


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip