Subject: AW: [BLISS] Re: notification/warning: call diversion active

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 20:00:18 +0100

The conclusion was that SUB/NOT is the appropriate mechanism to inform about CDIV active, so a subscription is necessary to receive this information. We haven't discussed on the content of the NOTIFY yet.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: Steve Langstaff [mailto:[email-masked]] 
> Gesendet: Mittwoch, 31. Oktober 2007 10:52
> An: [email-masked]
> Betreff: [BLISS] Re: notification/warning: call diversion active
> 
> 
> [Sorry to follow up my own post, but I happened to have it handy!]
> 
> Did the discussion on "Call-Diversion active" SUBSCRIBE/NOTIFY come to
> any conclusion?
> 
> > -----Original Message-----
> > From: Steve Langstaff [mailto:[email-masked]] 
> > Sent: 19 September 2007 12:51
> > To: Elwell, John; Paul Kyzivat; Huelsemann, Martin
> > Cc: [email-masked]
> > Subject: RE: AW: AW: [BLISS] Re: notification/warning: call 
> > diversion active
> > 
> > I like the SUBSCRIBE/NOTIFY proposal - it seems to be the 
> > right tool for the job.
> > 
> > Might I suggest that we take a leaf out of RFC3842, and have 
> > (at least) a boolean indication that there is some sort of 
> > call diversion active?
> > 
> > E.g. where RFC3842 says:
> > "The status line allows messaging systems or messaging 
> > gateways to provide  the traditional boolean message waiting 
> > notification.
> > 
> >       Messages-Waiting: yes
> > "
> > 
> > BLISS-CALL-DIVERSION could say:
> > "The status line allows call handling systems to provide  the 
> > traditional boolean call diversion notification.
> > 
> >       Call-Diversion: yes
> > "
> > 
> > 
> > > -----Original Message-----
> > > From: Elwell, John [mailto:[email-masked]]
> > > Sent: 19 September 2007 12:00
> > > To: Paul Kyzivat; Huelsemann, Martin
> > > Cc: [email-masked]
> > > Subject: RE: AW: AW: [BLISS] Re: notification/warning: call 
> > diversion 
> > > active
> > > 
> > > Catching up after being away.
> > > 
> > > I seem to sense a consensus that there is a requirement for 
> > a UA to be 
> > > aware of the status of call forwarding unconditional (or 
> > maybe various 
> > > types of conditional call forwarding too, although that 
> seems to be 
> > > outside the scope of the present thread). It can then use this 
> > > information to advise the user in whatever way is 
> > appropriate. To me, 
> > > things like stutter dial tone or other indications at the time of 
> > > outgoing call establishment are old fashioned - for a long 
> > time I have 
> > > had phones on my desk that permanently indicate my call 
> forwarding 
> > > status. Indeed I very rarely hear dial tone, let along 
> stutter dial 
> > > tone, because I dial from an address book or hot key or 
> missed call 
> > > list, or failing that I key my digits before going "off-hook" (or 
> > > activating headset or speakerphone or whatever). My 
> cellphone never 
> > > gives me dialtone. So PLEASE let's leave the UI to the 
> UA, and just 
> > > consider how the UA becomes aware of the information.
> > > 
> > > So if this is the requirement (to keep the UA informed), let's 
> > > consider solutions.
> > > 
> > > I have a certain sympathy with Martin Huelsemann's 
> > contention that a 
> > > SUBSCRIBE/NOTIFY mechanism is too heavy in signalling.
> > > For example, dialog-stateful proxies / B2BUAs seem to be 
> > sensitive to 
> > > lots of long-term dialogs from every UA.
> > > 
> > > I like the idea of a URN, but I don't really like putting it 
> > > Alert-Info in a response to INVITE, for all the reasons stated by 
> > > various contributors to this thread.
> > > 
> > > What about a REFER request, referring to a URN that 
> indicates call 
> > > forwarding status? URN parameters could even indicate 
> > conditions, if 
> > > we need to extend this to conditional call forwarding. Something 
> > > similar has been proposed by others in the past in the context of 
> > > remote call control.
> > > 
> > > John
> > 
> > _______________________________________________
> > BLISS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/bliss
> > 
> 
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss