Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2005 08:52:25 +0000

Mary,

Thanks for pointing this out. I must have missed this particular message in
the past. Yes, just adopting Q.732 Redirecting Reason values would pretty
well solve the problem (only one of my proposed values isn't available
there). It would certainly solve the legacy interworking problem, since
other values will not be required for this purposed. The only drawback is
that it is not easily extendible with new values (e.g., my proposed
"hunting" value).

Legacy interworking is certainly one use case beyond VM. We already
introduced Q.850 cause values to the Reason header for that reason, so
adding Q.732 values seems to be a logical extension.

Other use cases, which I have alluded to partly in earlier postings:
i) a UAS with a human user (as opposed to VM) where a clear reason for
redirection can provide the user with information on how to react to the
call;
ii) a UAS that can take intelligent action on how to present the call to the
user, e.g., prioritisation in a queue, whether to onward forward, etc., how
to record in a missed call log;
iii) a calling human user who may be able to adapt his behaviour depending
on presented reasons.

Does anyone have any other use cases where additional values might be
required? This would help to discover whether just to add a new protocol
value for Q.732 Redirection Reasons or to add a new protocol value with an
IANA registry of reason values.

John

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 09 February 2005 21:46
> To: 'David R Oran'; Cliff McCollum
> Cc: Elwell, John; Paul Kyzivat; [email-masked]'
> Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> I don't think this problem is at all about a deficiency in 
> History-Info (albeit History-Info would likely be used in 
> many of the scenarios where John wants to use his new Reason 
> value), but it's entirely transparent to History what's in 
> the Reason header (which is included as part of the 
> History-Info entry, if available). I think the issue was that 
> the 302 response is ambiguous as to whether it was invoked as 
> part of routing by a Redirect server or due to a specific 
> response at the end user. Francois had provided an example 
> back in August that highlighted the ambiguity when a 
> voicemail server is in the PSTN:
> 
> http://www.ietf.org/mail-archive/web/sipping/current/msg06919.html 
> 
> I think, though, that we need to step back to a point made 
> earlier on this topic that suggests that what's really needed 
> here would be a "Q.732" protocol value extension to the 
> Reason header:  
> http://www1.ietf.org/mail-archive/web/sipping/current/msg06561.html
> 
> John, I can't remember why this idea was discarded (I've not 
> gone back through the archives thoroughly); was there a 
> "reason" other than it's not a generic thing?  I think the VM 
> example has gotten to be a bit of a red herring and that 
> fundamentally folks that are interworking various legacy 
> protocols need this information to properly interwork their 
> services with SIP.  As I recall, John's intent was to provide 
> something a little more general purpose.  Is there a use case 
> for this functionality beyond VM (which is already a topic 
> that we know we can't agree upon)?  
> 
> Mary 
> 
(rest of thread trimmed)

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP