>-----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
