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
>
>
>
>
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:12345 at gateway.example.com SIP/2.0
From: <sip:Alice at example.com>;tag=2
To:
<sip:Bob at example.com>
Call-ID:
12345600 at example.com
CSeq: 1
INVITE
History-Info: <sip:Bob at example.com?
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:12345 at gateway.example.com SIP/2.0
From: <sip:Alice at example.com>;tag=2
To:
<sip:Bob at example.com>
Call-ID:
12345600 at example.com
CSeq: 1
INVITE
History-Info: <sip:Bob at example.com?
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: sipping-bounces at ietf.org on behalf of Gonzalo
Camarillo
> Sent: Thu 9/29/2005 1:43 PM
> To: Elwell, John
>
Cc: r.jesske at t-com.net; joanne at avaya.com; 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
>
sip-implementors at cs.columbia.edu for questions on current sip Use
>
sip at ietf.org 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 Mailadmin at wipro.com 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
sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org
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 sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP