[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] Re: Comments ondraft-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