[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] RE: Mapping ISUP/QSIG causes to SIP response codes
In a message dated 6/18/02 11:27:00 AM Eastern Daylight Time, adam@dynamicsoft.com writes:
We've been working on the ISUP draft for quite some time now. By far,
the area that has received the most comments is the section on cause
code mapping. We've gone through massive contortions in an attempt
to make everyone involved as happy as possible. In fact, I doubt
there's a single status code left for which someone hasn't proposed
a change (and, for the most part, every time we changed a mapping to
make one person happy, two others would stand up and tell us why
they think the change was wrong). Any changes made at this point
without good technical reasons will almost certainly cause at least
one other person to become quite unhappy.
We'd still be happy to hear of honest-to-goodness bugs in the mapping
(e.g. "cause code x mapping to SIP y will make the UAC act in this
fashion, which leads to the demonstratably bad side effect of...").
[MAP] A problem for ISUP to SIP mapping (and back to ISUP) is that several ISUP cause codes (1, 2, and 3) are mapped to 404 which then gets mapped back to 1. This would mean that information is lost in this case of ISUP-SIP-ISUP interworking. This could prevent an originating side from playing an appropriate message. The philosophy should be that ISUP/ISDN did a lot of work to define the necessary set of cause codes, and all that apply should all be carried through SIP unchanged.
> Cause 5 (misdialled trunk prefix). This would seem to be
> similar to cause 1
> (unallocated number). Yet cause 5 maps to the default response code
> (currently 500) whereas cause 1 maps to 404 (not found).
> Would it not be
> appropriate to map cause 5 to 404?
My understanding is that cause 5 would only be caused by a
misconfiguration at the gateway, while 1 can be caused by user error.
Correct me if I'm wrong.
[MAP] I have a hard time imagining a case in which this cause code would be needed in the ISUP to SIP mapping. It reflects an error made by the originator in the local dailing plan. If there is a case, then it should be transferred into SIP without loosing its meaning.
The comments seem to address a number of cases in which there would be an ambiguity of whether an error occurred in the destination PSTN or in the gateway to the PSTN. Unless there is a clear distinction between the two, then there is a serious problem. Will it be possible to say, for every response that the originating side (UAC or originating proxy) receives, whether it was the result of an error in the PSTN or in the gateway?
Mike Pierce
Artel