Subject: RE: [Sipping] elwell-sipping-redirection-reason-02

From: Elwell John <[email-masked]>
Date: Wed, 10 Aug 2005 11:06:53 +0100

Roland,

Sorry for the delay in responding. See in-line.

Discussions last week seemed to indicate that there is indeed a problem to
be solved, but that alternative mechanisms should be explored. I intend to
write something on this shortly.

John

> -----Original Message-----
> From: Jesske, R [mailto:[email-masked]] 
> Sent: 01 August 2005 12:50
> To: [email-masked]; Elwell John; [email-masked]; [email-masked]
> Subject: AW: [Sipping] elwell-sipping-redirection-reason-02
> 
> Dear all,
> I think we discussed this issue nearly one year ago.
> My assumption was to propose such redirection causes for the 
> Reason header what makes it easier to provide a bunch of 
> diversion/redirect services in combination with the History 
> header. Also the interoperability with the PSTN/ISDN (sorry 
> for mentioning here) is given.
> 
> If I'm looking on:
> http://www.ietf.org/internet-drafts/draft-jennings-sip-voicema
il-uri-04.txt
> 
> There is a try to use the SIP response codes but I have a 
> other understanding and it is not very clear for me why these 
> responses are used for such redirect interpretation.
> 
> Chapter 3  defines the following values for a new "cause" 
> parameter that is associated with the URI:
> 
>            +------------------------------+-----------------+
>            | Service                      | Cause Parameter |
>            +------------------------------+-----------------+
>            | Busy                         | 486             |
>            | No answer                    | 408             |
>            | Unconditional                | 302             |
>            | Deflect                      | 487             |
>            | No Contacts/Failure of UA    | 410             |
>            +------------------------------+-----------------+
> 
> The 486 and 408 is OK.
> 302 to use for an unconditional forwarding is from my point 
> of view misleading. 302 sends back a URI where the new 
> destination is. Compared with the PSTN/ISDN service this is 
> more Call Deflection like, because in this service the user 
> sends back a new destination number.
[JRE] The problem is that 302 can hide a number of different diversion
reasons, since the repertoire of reasons in the 3xx range is very limited.
So if you want to divert on busy and do so by redirection / recursion rather
than retargeting, what do you use? We need a solution to this. Defining a
Reason header extension to indicate the real reason would be one approach,
having an extended repertoire of 3xx response codes would be another.
I do not understand your point about "more Call Deflection like". Admittedly
one use of 302 would be where the call is presented to the user and the user
decides at that time that the call should be deflected to another
destination - this is indeed comparable with PSTN/ISDN Call Deflection. On
the other hand a UAS or proxy could act as a redirect server for this
particular request and send a 302 response based on configured or scripted
information about how to handle this particular type of request. I do not
necessarily equate this with PSTN/ISDN call deflection.

> 
> With regard to unconditional. From my point of understanding 
> no response has to be sent back because the INVITE will be 
> forwarded to the regarding destination. To inform the Caller 
> a 181 (Call Is Being Forwarded) should be send back. In such 
> a case the redirection reason is the best was to inform the 
> caller why the call was forwarded.
[JRE]The History-Info spec is silent on use of the 181 provisional response,
and in my opinion the use of History-Info removes the need for 181. The
History-Info header in a provisional or final response provides the UAC and
caller with all available diversion information (not only for unconditional
but for other forms of diversion). Of course, a History-Info header could be
sent in a 181 response, but the History-Info header would contain details of
diversion. The History-Info header URI will, of course, include a Reason
header indicating the reason. The question we have to answer is how the
Reason header in the History-Info header URI just indicates a SIP reason
code or a reason code from some other name space (as proposed in the present
redirection-reason draft), or some other solution.

> 
> I think this concept contradicts with the history header. If 
> the history header will be used instead of the cause 
> parameter. Two possible redirect reasons could be used. 1. 
> the response code as proposed in 
> 
> With regard to the mapping of response codes to the PSTN/ISDN 
> a new mechanism is needed if 
> draft-jennings-sip-voicemail-uri-04.txt and the redirecting 
> reason as proposed in John draft.
> 
> Thoughts? Can we bring such thoughts together?
> 
> Best Regards
> 
> Roland
> 
> 
> 
>  
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] 
> > [mailto:[email-masked]] Im Auftrag von James M. Polk
> > Gesendet: Sonntag, 31. Juli 2005 17:32
> > An: Elwell John; Cullen Jennings; [email-masked]
> > Betreff: RE: [Sipping] elwell-sipping-redirection-reason-02
> > 
> > 
> > At 10:20 AM 7/31/2005 +0100, Elwell John wrote:
> > >Cullen,
> > >
> > >I don't have a strong opinion whether it is additional SIP codes or
> > >extension to the Reason header, but I sensed (correctly or 
> > incorrectly) that
> > >the mood was against the latter. Any other opinions?
> > 
> > I think I remember this too, but we're running out of code 
> > number space too
> > 
> > 
> > >John
> > >
> > > > -----Original Message-----
> > > > From: Cullen Jennings [mailto:[email-masked]]
> > > > Sent: 30 July 2005 04:48
> > > > To: [email-masked]
> > > > Subject: [Sipping] elwell-sipping-redirection-reason-02
> > > >
> > > >
> > > > We had a thread on using the existing SIP codes and why 
> > they were not
> > > > adequate but I forget where it ended. Did we find some 
> > lacking things?
> > > > Should we add some more SIP codes because they are 
> > needed? The whole
> > > > discussion did not really seem to be addressed int this rev.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > 
> > 
> > cheers,
> > James
> > 
> >                                  *******************
> >                  Truth is not to be argued... it is to be presented.
> > 
> > _______________________________________________
> > 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