RE: [Sipping] Re: Commentsondraft-elwell-sipping-redirection-reason-02.txt

Hi Marianne,

Yes, I understand the need for uniquely interpreting and conveying different Retargeting reasons in, for e.g., the forwarded (downstream) INVITE so that the terminating "Applications" like voicemail can uniquely handle each of the different Retargeting scenarios (keeping aside, for a moment, the larger question of whether this needs to solved in the SIP realm or not).

The point I was trying to make in the mails below is that,

(1) the exsiting SIP Response codes & Reason Hdrs (per 3326),

(2) in conjunction with the usage of Hist-Info in SIP Requests *and* Responses, AND

(3) by way of deciphering the SIP dialogue Context on receipt of (1) and/or (2) at the receiving SIP entity;

already appears to provide a way to differentiate all of the known retargeting flavours implemented by specific applications (for e.g., PSTN forwarding, that tends to use and interpret the eight Retargeting flavours per Q.732).

To reiterate, the key point here is the existing SIP capability [provided by (1), (2) & (3)] to uniquely differentiate between the known (PSTN?) flavours of retargeting (although this in itself may not be a SIP problem as there could be many other applications specific retargeting flavours beyond those described in Q.732). It appears (atleast at this point in time) that, these flavours are indeed uniquely distinguishable, per the mail train below - esp the mapping table in the my first response below.

In order that we dont go back to the (basic) discussion of "retargeting reason is required by IVR, required for AS controlled SIP routing etc", it is best that we discuss specific SIP call scenarios/flows and analyse those scenarios where (1) (2) & (3) *put together* appear to fall short - which then, might warrant introduction of a new Resp Code vis-a-vis a new Reason Hdr namespace.

Cheers,

-- ranjith..

Hi Ranjith,

For call forwarding services which are implemented with an AS intercepting the INVITE, there is the need to add in the forwarded INVITE an explicit reason. This is needed for example in case of a redirection to voicemail to play a different announcement according to the redirection reason.

Some forwarding events can correspond to the receipt by the AS of a specific SIP status code sent by the terminating UAS, examples are:

- "Call Forwarding on Busy user" (486),
- "Call Deflection" (302),

In some CF service scenarios however, the AS does not wait until a response is received but simply forwards the INVITE after having changed the Request-URI; examples are:

- "Call Forwarding unconditionnal"
- "Call Forwarding no reply"
- "Call Forwarding on not registered"

At minimum, a general solution should be searched in SIP that addresses all of these scenario in a consistent manner.

Regards
Marianne

-----Message d'origine-----
De : sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] De la part de Ranjith Mukundan
Envoyé : vendredi 30 septembre 2005 11:22
À : r.jesske at t-com.net; Gonzalo.Camarillo at ericsson.com; john.elwell at siemens.com
Cc : joanne at avaya.com; sipping at ietf.org; 'Marcello Pantaleo (AC/EDD)'
Objet : RE: [Sipping] Re: Commentsondraft-elwell-sipping-redirection-reason-02.txt

Roland,

in-line...

From: Jesske, R [mailto:R.Jesske at t-com.net]
Sent: Fri 9/30/2005 9:56 AM
To: Ranjith Mukundan (WT01 - Voice & Next Generation Networks); Gonzalo.Camarillo at ericsson.com; john.elwell at siemens.com
Cc: joanne at avaya.com; sipping at ietf.org; marcello.pantaleo at ericsson.com
Subject: AW: [Sipping] Re: Comments
ondraft-elwell-sipping-redirection-reason-02.txt

ranjith,
comment below

> -----Ursprüngliche Nachricht-----
> Von: Ranjith Mukundan [mailto:ranjith.mukundan at wipro.com]
> Gesendet: Donnerstag, 29. September 2005 13:24
> An: Gonzalo.Camarillo at ericsson.com; john.elwell at siemens.com
> Cc: Jesske, Roland; joanne at avaya.com; sipping at ietf.org; 'Marcello
> Pantaleo (AC/EDD)'
> Betreff: RE: [Sipping] Re: Comments
> ondraft-elwell-sipping-redirection-reason-02.txt
>