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

From: "Ranjith Mukundan" <[email-masked]>
Date: Thu, 29 Sep 2005 16:53:53 +0530

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.

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

_______________________________________________
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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Sep 2005 21:19:02 -0500

As John was saying, another draft is on the way.

No use discussing the old one.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, September 29, 2005 06:27
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: [email-masked]; sipping; [email-masked]; 
> Elwell,John; Gonzalo Camarillo
> Subject: Re: [Sipping] Re:Comments 
> The problem I have with all this is that there are a potentially 
> infinite number of reasons why a call addressed to one place 
> ends up one 
> place or another. (Note that when it is addressed to an AOR, it is in 
> general *never* answered by a server at that AOR, but instead 
> is always 
> forwarded someplace else.)
> 
> Some possible destinations are learned by registration, some (such as 
> voicemail) are learned by configuration. Various kinds of call 
> forwarding destinations may also be learned by configuration.
> 
> This attempt at reason codes seems to be trying to categorize the 
> algorithms used to decide where the call is delivered. But those 
> algorithms are not standardized in any way, at least in this venue. 
> Without a model for how to classify *real* call routing 
> algorithms into 
> these categories, the categories are meaningless. I think there is an 
> assumption that "everybody will understand how to do this", 
> but I don't 
> think that is so.
> 
> 	Paul
> 
> GARCIN Sebastien RD-CORE-ISS wrote:
> > Hi,
> > 
> > Call Forwarding unconditionnal is one example (with an AS 
> intercepting 
> > the INVITE).
> > 
> > sébastien
> > 
> > -----Message d'origine-----
> > De : [email-masked] 
> [mailto:[email-masked]] De la 
> > part de Gonzalo Camarillo Envoyé : jeudi 29 septembre 2005 
> 10:14 À : 
> > Elwell, John Cc : [email-masked]; [email-masked]; sipping
> > Objet : [Sipping] Re: Comments 
> >>Because that doesn't work when a 3xx is used - 302 does not capture
> >>the fact that it was because of busy, say.
> > 
> > 
> > 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 
> > 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
> > 
> > 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
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
>

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Fri, 30 Sep 2005 14:52:04 +0530

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

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

> 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
>
>                                      |      410 Gone     
> (Permanent) ?
> with the new
> 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.
>