Hi Nils A originator typically the UAC can send CANCEL if it does not want to accept the call. So the Reason header with block option can be sent while rejecting the call. While the Reason header with block option can be sent in BYE while terminating the call - i. e blocking after talking. Regards Ranjit -----Original Message----- From: Nils Ohlmeier [mailto:lists@xxxxxxxxxxxx] Sent: Tuesday, March 03, 2009 2:33 AM To: Victor Pascual Ávila Cc: Avasarala Ranjit-A20990; sipping@xxxxxxxx Subject: Re: New Internet Draft for Caller Identity Blocking 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/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
