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

From: [email-masked]
Date: Fri, 30 Sep 2005 23:03:10 +0530

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..

________________________________

From: MOHALI Marianne RD-CORE-ISS [mailto:[email-masked]]
Sent: Fri 9/30/2005 9:52 PM
To: Ranjith Mukundan (WT01 - Voice & Next Generation Networks); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Marcello Pantaleo (AC/EDD)
Subject: RE: [Sipping] Re: Commentsondraft-elwell-sipping-redirection-reason-02.txt

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 : [email-masked] [mailto:[email-masked]] De la part de Ranjith Mukundan
Envoyé : vendredi 30 septembre 2005 11:22
À : [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]; 'Marcello Pantaleo (AC/EDD)'
Objet : RE: [Sipping] Re: Commentsondraft-elwell-sipping-redirection-reason-02.txt

Roland,

in-line...

From: Jesske, R [mailto:[email-masked]]
Sent: Fri 9/30/2005 9:56 AM
To: Ranjith Mukundan (WT01 - Voice & Next Generation Networks); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Sipping] Re: Comments
ondraft-elwell-sipping-redirection-reason-02.txt

ranjith,
comment below

> -----Ursprüngliche Nachricht-----
> Von: Ranjith Mukundan [mailto:[email-masked]]
> Gesendet: Donnerstag, 29. September 2005 13:24
> An: [email-masked]; [email-masked]
> Cc: Jesske, Roland; [email-masked]; [email-masked]; 'Marcello
> Pantaleo (AC/EDD)'
> Betreff: RE: [Sipping] Re: Comments
> ondraft-elwell-sipping-redirection-reason-02.txt
>
>
>
> Hi,
>
> As Gonzalo has indicated, it definitely appears that the 302 case can
> be easily handled with Hist-Info.
>
> Absense of Hist-Info would indicate standard/normal SIP Redirection;
> any "Forwarding" (including those resulting from interaction at a PSTN
> Gateway/MGCF) should result in a 302 *with* a Hist-Info and the Reason
> field with standard SIP Response Code.
>

>>
>> There are several other possibilities how a Call Forwarding can
>> appear (see also the SIP service examples draft).
>>
/***
[ranjith]:

Sure. I picked on the 302 scenario as we got started on this thread with that example; but the attempt at mapping the standard SIP Response codes as illustrated in the table below, holds good in other (non-302) scenarios as well; for e.g.,:
consider the scenario of Alice calling Bob registered to a Recursing Proxy and Bob has unconditionally Retargeted (i.e., Call Foward Unconditional) the call to a PSTN gateway as shown below:

           Alice            Proxy           Bob              Gateway
             |                |              |                   |
             |    INVITE F1   |              |                   |
             |--------------->|              |                   |
             |                |              |                   |
             |(100 Trying) F2 |              |                   |
             |<---------------|              |                   |
             |                |              |    INVITE F3      |
             |                |--------------------------------->|
             |                |              | 180 Ringing F4    |
             |                |<---------------------------------|
             | 180 Ringing F5 |              |                   |
             |<---------------|              |      200 OK F6    |
             |                |              |                   |
             |                |<---------------------------------|
             |    200 OK F7   |              |                   |
             |<---------------|              |                   |
             |     ACK F8     |              |                   |
             |--------------->|              |     ACK F9        |
             |                |--------------------------------->|

As per draft-elwell-sipping-redirection-reason-02.txt (i.e., with a new Reason Namespace), the INVITE sent would be:

   F3 (INVITE): <with new Reason Name space>
     
     INVITE  sip:[email-masked] SIP/2.0
     From: <sip:[email-masked]>;tag=2
     To: <sip:[email-masked]>
     Call-ID: [email-masked]
     CSeq: 1 INVITE
     History-Info: <sip:[email-masked]? Reason=Redirection%3B
     cause%3D5%3Btext%3D%22Forward%20unconditional%22>;

Whereas, with the Standard SIP Response Code mapping as I am proposing in the table below, this could have been accomplished by sending an INVITE as
follows:

   F3 (INVITE): <with standard SIP Response Code/Reason Hdr per RFC 3326>
     
     INVITE  sip:[email-masked] SIP/2.0
     From: <sip:[email-masked]>;tag=2
     To: <sip:[email-masked]>
     Call-ID: [email-masked]
     CSeq: 1 INVITE
     History-Info: <sip:[email-masked]? Reason=SIP%3B
     cause%3D181%3Btext%3D%22Call%20is%20%being%20forwarded%22>;
             ^^^
The receipt of 181 **in the Hist-Info** can be interpreted by the application as "Call is being Fowarded" *Unconditionally*; for e.g., in the case of a PSTN centric application like the MGCF/Gateway, this can be normatively enforced (via a TISPAN spec for e.g.,) to be interpreted in this way; given that, the mapping proposed in the table below is all unique, all the Retargeting flavours can be uniquely and distinctly interpreted (and this "Flavour" interpretation can be normatively enforced by application specific standards like TISPAN for a PSTN Gateway). Please note that, I am not hinting that SIP Response codes should be interpreted in a way that contradicts with 3261 Response code intrepretation - it should indeed be interpreted in complaince to 3261; it is just the the various re-targeting flavours can be uniquely *deciphered* based on the dialogue context using the exisitng SIP response codes (without the need for additional Reason
Namespaces) - this decipehering mechanism can be made normative (for
interoperability) by the application and the concomitant standards (TISPAN or otherwise).

***/

>>
>> Some networks does not like to use a 302, because of security issues.
>> E.G in a 302 a high priced number can be included. So the caller
>> built up an new session to that new number paying the nice price. And
>> the forwarding user is out of the game.
>>
/***
[ranjith]
You are right, 302 could in result in security hazards (like spoofing) - but this can be almost completely elimilated if you ensure that - when 302 orginated in one "Trust" domain is to be intrepreted in another "Trust"
domain then, TLS is used *always* across the Trust boundary.

Also, if you want to realise PSTN-style billig, it is still possible to realize the "high priced number" scenario you are refering to by looking at the Hist-info and billing the forwarded leg of the call to the forwarding/redirecting party and not the orginal called party.

That said, there are scenarios, where 302 is the most optimal way to handle retargeting; for e.g., consider a scenario where the call from the PSTN (via a MGCF/gateway) was originally targeted for termination in a SIP network but was re-targeted back into PSTN (from the SIP network) as a result of some retargeting/call forwarding flavour active in the SIP network - if this re-targeting flavour was "call forward unconditional" the current TISPAN specs tends to indicate that the SIP network should return a 181 (Call is being forwarded) with Hist-Info - which appears to be an non-optimal approach as this could result in signaling-plane and User/bearer-plane "hair-pins" at at the PSTN Gateway/MGCF; OTOH, if a 302 is returned (with Hist-Info reason set to 181) then the "hairpin" problem can be overcome as a result of the SIP dialogues being cleared and the Redirection being handled completely in the PSTN itself - where it belongs (at least in the context of this scenario).

***/

>>
>> So forwarding by a Application Server is an other possibility and
>> TISPAN is defining that.
>> So we need some indications for interoperability reasons why the call
>> was diverted/forwarded.
>>
/***
[ranjith]
You are probably refering to ETSI TISPAN STF 281's work:TR 183 014 OR EN 383
001 => in both cases, if there is a reliance on a new Reason Header Namespace - the approach appears to be inappropriate (just the way the approach in ECMA 360 is appropriate as it relies on a new SIP Reason Header namespace). It also appears that the TISPAN work that I am alluding to above is trying to influence 3GPP TS 29.163 - which again would be inappropriate if there is a reliance on a new Namespace for the Reason Header for realizing the various Retargeting flavours.
***/

cheers,
-- ranjith..

Roland

> That said, mapping all the Diversion reasons specified in the PSTN
> world
> *may* not be *easily* "mappable" but here is one *attempt* that
> illustrates that it is certainly possible (and hence does NOT seem to
> warrant a new Reason Namespace):
>
> ==============================================================
> ==============
> ==========
> Q.732 Diversion Reasons              |      SIP Response Codes when
> associated
>
> OR just simple 3261 SIP Redirection  |      with a (typically
> "Party C") URI
> **in
>
>                                      |      History Info**
> [Except for Std
> SIP Redir]
> =====================================|========================
> ==============
> ==========
> Normal/Standard SIP Redirection      |      302  Moved
> Temporarily (**NO**
> Hist Info)
>
> (per 3261)                           |        [This should NOT be
> interpreted as a
>
>                                      |      
> Div/Deflection/Forwarding;
> this is SIP
>
>                                      |        Routing
> specific and hence 302
> without
>
>                                      |        any Hist-Info
> should NOT map
> to a
>
>                                      |      
> Div/Deflection/Forwarding
> Reason at
>
>                                      |        the PSTN G/w or a MGCF]
>                                      |
> -------------------------------------|------------------------
> --------------
> ---------
> Forward unavailable                  |      480 Temporarily
> Unavailable
> (per Q.732)                          |
> -------------------------------------|------------------------
> --------------
> ---------
> Forward busy                         |      486 Busy Here
> (per Q.732)                          |
>
> -------------------------------------|------------------------
> --------------
> ---------
> Forward no reply                     |      408 Req Timeout
> (per Q.732)                          |
>
> -------------------------------------|------------------------
> --------------
> ---------
> Forward unconditional                |      181 Call is being Fwd'd
> (per Q.732)                          |
>
> -------------------------------------|------------------------
> --------------
> ---------
> Deflection immediate                 |      302 Moved Temporarily (in
> Hist-Info Hdr)
> (per Q.732)                          |
> -------------------------------------|------------------------
> --------------
> ---------
> Deflection alerting                  |      603 Decline
> (per Q.732)                          |      
>
> -------------------------------------|------------------------
> --------------
> ---------
> Hunting                              |      100 Trying (?)
> (in Hist-Info
> Hdr) <==**
>
> (per Q.732)                          |      [** Is there
> something more
> appropriate?]
> -------------------------------------|------------------------
> --------------
> ----------
> Mobile not reachable                 |      404 Not found
> (temporarily) ?
>
> (per Q.732)                          |
>                                      |      410 Gone    
> (Permanent) ?
> <==**
>
>                                      |       [**This may not
> be appropriate]
> =====================================|========================
> ==============
> ==========
>
> On a related note, there is an ECMA work, mapping QSIG to SIP that
> seems to rely on a new Name Space (rather than reusing existing SIP
> Response code) - this, IMHO, is an inappropriate approach and should
> NOT be cited as a precedence to introduce new Reason Namespaces in
> SIP.
>
> Cheers,
> -- ranjith..
>
> From: [email-masked] on behalf of Gonzalo Camarillo
> Sent: Thu 9/29/2005 1:43 PM
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; sipping
> Subject: [Sipping] Re: Comments
> ondraft-elwell-sipping-redirection-reason-02.txt
>
>
> Hi,
>
> > Because that doesn't work when a 3xx is used - 302 does not
> capture the
> fact
> > that it was because of busy, say.
>
> You would return a 302 with a History-Info header field with a 486
> Busy... the problem with the 302 response has nothing to do with the
> new namespace. You have the same problem even if you use a new
> namespace.
>
> > Also not all reasons can be represented by SIP response codes. I am
> > currently writing a new (00) draft
> along with
> some
> > other people. This will propose a different mechanism but will still
> require
> > a new namespace to reflect different service retargeting
> reasons. Hoping
> to
> > hit the cut-off date for Vancouver.
>
> Can you provide examples of reasons that cannot be represented by SIP
> response codes? If they are general reasons, what we need to do is to
> create new response codes. We probably do not need a new namespace.
>
> Thanks,
>
> Gonzalo
>
> _______________________________________________
> 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
>
>
>
>
> Confidentiality Notice
>
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain confidential or privileged information.
> If you are not the intended recipient, please notify the sender at
> Wipro or [email-masked] immediately and destroy all copies of
> this message and any attachments.
>

_______________________________________________
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