[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [Sipping] Re: Comments ondraft-elwell-sipping-redirection-rea son-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). 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.
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.
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