Hi Victor, Am 02.03.2009 21:28 Uhr, schrieb Victor Pascual Ávila:> Hi Nils,> thanks for your comments.>> On Mon, Mar 2, 2009 at 6:01 PM, Nils Ohlmeier<lists@xxxxxxxxxxxx> wrote:>> you and your draft are talking about allowing the terminating UA to give>> some "feedback" for an incoming call. How is this related to CANCEL at>> all? Maybe I'm missing here something but a CANCEL is only send by the>> originator if the call was not yet established, right?!>> IMHO it might make sense when dealing with B2BUAs (e.g. a 3pcc service).>> Please, correct me if I'm wrong. I assume you mean that a B2BUA could cancel the outgoing call leg. But a) where does the B2BUA gets suddenly the information from (if it has the blocking information already it would reject the incoming call leg, so there is nothing to cancel) and b) how is this different from a forking proxy (which obviously needs to cancel the remaining forked call legs if the user has rejected the call at one of the legs)? So I have to fealing that I'm still missing here something.A CANCEL goes from originator to the receiver of a request. But you want to send the blocking information in the other direction. Or do you assume that an entity which processes the blocking information could sit at the terminating side of a call leg? I fear that I would need an example or call flow to get the use case for a CANCEL. Cheers Nils_______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
