[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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
_______________________________________________
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