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

From: "Steve Langstaff" <[email-masked]>
Date: Wed, 31 Oct 2007 02:52:01 -0700

[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