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

From: "Jesske, R" <[email-masked]>
Date: Thu, 10 Feb 2005 11:14:26 +0100

Dear all,
As I remember from the discussion including a new Reason value into the Histors_Info it was not accepted, because the History-Info should be seen as a generic Header and to combine it with the redirection reasons was not accepted.

The idea to define a own Reason value for Redirection Reasons and not taking Q.732 was as John said to have the chance to extend the reasons for other cases.

We need the History Info and the Redirecting Reason to fulfil interoperability to legacy networks and the TISPAN NGN simulation Communication Diversion Service. 

Both are proposed to be included into the 3GPP SIP Profile (TS24.229) and the regarding ETSI TISPAN endorsement.

I have no strong opinion how the Redirection Reason should be defined but we need it including the History info as soon as possible. (Target for the Communication Diversion Service in TISPAN is mid of 2005)

Best Regards

Roland

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im
> Auftrag von Elwell, John
> Gesendet: Donnerstag, 10. Februar 2005 09:52
> An: Mary Barnes; 'David R Oran'; Cliff McCollum
> Cc: Paul Kyzivat; [email-masked]'
> Betreff: RE: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> 
> 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
> 

_______________________________________________
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