Avasarala Ranjit-A20990 wrote: > Consider the scenario > > Alice makes call to Bob. So Bob receives the INVITE from Alice. Now if Bob does not want to answer the call from Alice and instead wishes to block Alice, Bob can send a CANCEL That is quite a large change from RFC 3261. Can't Bob simply reject the call with an appropriate response code? That would seem less disruptive than permitting backwards CANCELs! > with Reason header with protocol value as "block". Similarly say John calls Bob and Bob answers the call and after speaking realizes that John is a telemarketer or someone with whom Bob does not want to speak in future. Then Bob can send BYE and along with send Reason header with protocol value as "block". > > So this way a particular caller identity can be blocked either during the ringing or call termination phase. > > > Regards > Ranjit > > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@xxxxxxxxx] > Sent: Tuesday, March 03, 2009 1:30 PM > To: Avasarala Ranjit-A20990; Nils Ohlmeier; Victor Pascual Ávila > Cc: sipping@xxxxxxxx > Subject: RE: New Internet Draft for Caller Identity Blocking > > > > >> -----Original Message----- >> From: sipping-bounces@xxxxxxxx >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Avasarala Ranjit-A20990 >> Sent: Tuesday, March 03, 2009 12:01 PM >> To: Nils Ohlmeier; Victor Pascual Ávila >> Cc: sipping@xxxxxxxx >> Subject: Re: New Internet Draft for Caller Identity Blocking >> >> Hi Nils >> >> A originator typically the UAC can send CANCEL if it does not want to >> accept the call. >> > Originator typically initiates the call and the recipient accepts the call. How does originator accept it's own call? > > > Sanjay > > >> 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 >> >> > _______________________________________________ > 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 > > > _______________________________________________ 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
