[Sip-implementors] RFC 3398 - ISUP/SIP mapping: 404 -> Unallocated number ??

[Iñaki Baz Castillo]

Hi, when I receive an INVITE from my provider SIP_PSTN gateway I do a lookup
in my internal ENUM.
If the E164 number is mapped to a local SIP user (client of mine) I look for
it in the location server.
If the user is registered I forwad the INVITE and so... all OK.

The problem is in the case the SIP user is not registered (by any reason).
Then my proxy replies "404 Not Found" to the provider SIP_PSTN gateway.

RFC 3398 specifies that the ISUP mapped code for SIP "404" is:

-------------------------------------------------------------------------------------------------
1 Unallocated number
This number is not in the routing table or it has no path across the ISDN
cloud (network).
1. Check routing table to see it the number is available.
2. Check to make sure the correct digits were dialed and it is a
valid number.
-------------------------------------------------------------------------------------------------

So my PSTN provider replies with ISUP "Unallocated number" and the caller
provider "X" generates the typicall early media message to inform the caller:
"Provider X informs you that the number you are calling doesn't exist"

This is a big inconvenient since me, as telephony provider, am responsible of
generating that early media message. In fact, when I receive a call to a non
registered user I first reply with an own 183 Session Progress:
"My provider informs you that the number you are calling is not available
now"
After the 183 I send a 404, so the gateway mappes it to "Unallocated number"
and the caller provider adds its own early media message... the caller
listens to two early messages (mine first and him provider's one later)!!



But the callee DOES exist, the only it occurs is that the SIP user is not
registered, just it. The number DOES exist in my system, so I think it would
be better if my provider gateway would map the 404 to any of those ISUP
causes:

-------------------------------------------------------------------------------------------------
3 No route to destination.
The dialed number is in the routing plan, but there is no physical route
to the destination.
1. The PRI D-Channel may be down at one end or the other.
2. The span or WAN is not connected correctly.
-------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------
20 Subscriber Absent.
Used when a mobile station has logged off, radio contact is not
obtained with a mobile station or if a personal telecommunications
user is temporarily not addressable at any user-network interface.
-------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------
27 Destination Out-of-Order.
This is a working number, but the span to the destination is not
active or there is a problem sending messages to this destination.
-------------------------------------------------------------------------------------------------



Unfortunatelly any of the above ISUP causes (decimal 3, 20, 27) exist as a SIP
code mapping in RFC 3398.
As a very dirty solution I'm using now this RFC3398 mapping:

502 Bad gateway ---> 38 Network out of order

-------------------------------------------------------------------------------------------------
38 Network Out-of-Order.
Indicates that the network is not functioning correctly and that the
condition is likely to last a relatively long period of time.
-------------------------------------------------------------------------------------------------

So if the caller is a movile he will be first listen to my provider early
message, and later he will see "network failure" (or similar) into its
screen. It's dirty but it's the best option I've found.


Any suggestion to handle it more correctly? In short, I can't reply with "404"
since the caller will listen two early media messages and he will think that
the number doesn't exist.


Thanks for any help.

[Bi Ran]

Hi Castillo,

My two cents. As the provider I would not play early media for 404 case
since I know the PSTN provider will do it. It should be possible to identify
this special case in the coding level.

Thanks,
Ryan

--------------------------------------------------
From: "I?aki Baz Castillo" <ibc at in.ilimit.es>
Sent: Tuesday, March 04, 2008 8:12 PM
To: <sip-implementors at lists.cs.columbia.edu>
Subject: [Sip-implementors] RFC 3398 - ISUP/SIP mapping: 404 ->
Unallocatednumber ??

Post by Iñaki Baz Castillo
Hi, when I receive an INVITE from my provider SIP_PSTN gateway I do a lookup
in my internal ENUM.
If the E164 number is mapped to a local SIP user (client of mine) I look for
it in the location server.
If the user is registered I forwad the INVITE and so... all OK.
The problem is in the case the SIP user is not registered (by any reason).
Then my proxy replies "404 Not Found" to the provider SIP_PSTN gateway.
-------------------------------------------------------------------------------------------------
1 Unallocated number
This number is not in the routing table or it has no path across the ISDN
cloud (network).
1. Check routing table to see it the number is available.
2. Check to make sure the correct digits were dialed and it is a
valid number.
-------------------------------------------------------------------------------------------------
So my PSTN provider replies with ISUP "Unallocated number" and the caller
"Provider X informs you that the number you are calling doesn't exist"
This is a big inconvenient since me, as telephony provider, am responsible of
generating that early media message. In fact, when I receive a call to a non
"My provider informs you that the number you are calling is not available
now"
After the 183 I send a 404, so the gateway mappes it to "Unallocated number"
and the caller provider adds its own early media message... the caller
listens to two early messages (mine first and him provider's one later)!!
But the callee DOES exist, the only it occurs is that the SIP user is not
registered, just it. The number DOES exist in my system, so I think it would
be better if my provider gateway would map the 404 to any of those ISUP
-------------------------------------------------------------------------------------------------
3 No route to destination.
The dialed number is in the routing plan, but there is no physical route
to the destination.
1. The PRI D-Channel may be down at one end or the other.
2. The span or WAN is not connected correctly.
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
20 Subscriber Absent.
Used when a mobile station has logged off, radio contact is not
obtained with a mobile station or if a personal telecommunications
user is temporarily not addressable at any user-network interface.
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
27 Destination Out-of-Order.
This is a working number, but the span to the destination is not
active or there is a problem sending messages to this destination.
-------------------------------------------------------------------------------------------------
Unfortunatelly any of the above ISUP causes (decimal 3, 20, 27) exist as a SIP
code mapping in RFC 3398.
502 Bad gateway ---> 38 Network out of order
-------------------------------------------------------------------------------------------------
38 Network Out-of-Order.
Indicates that the network is not functioning correctly and that the
condition is likely to last a relatively long period of time.
-------------------------------------------------------------------------------------------------
So if the caller is a movile he will be first listen to my provider early
message, and later he will see "network failure" (or similar) into its
screen. It's dirty but it's the best option I've found.
Any suggestion to handle it more correctly? In short, I can't reply with "404"
since the caller will listen two early media messages and he will think that
the number doesn't exist.
Thanks for any help.
--
I?aki Baz Castillo
ibc at in.ilimit.es
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Iñaki Baz Castillo]

Isn't 480 Temporarily Unavailable a better response code from the proxy?
That could be translated by the PSTN gateway to ISUP code 20 - Subscriber
Absent.

RFC 3398 says that the mapping code for "480" is "18 No user responding":
http://tools.ietf.org/html/rfc3398#section-8.2.6.1

This produces the caller see in its mobile screen "user not responding".
I don't know if it's much better of my "502" -> "38 Network out of order"

Try it out, maybe the caller provider then plays a more correct early media
message (like "The number you have dialed is currently not available").

In fact I don't want the caller provider says early media, it should say
nothing since it will be my provider who will say the early media.

BTW, replying a "480" doesn't produce an early media in the caller provider,
that is good.

If not, maybe you can answer with 486 Busy after you have played your own
early media message. That will be converted to ISUP code 17 which will
probably play busy tone in the callers phone. That way, the caller that
calls a subscriber in your network that is not registered will first hear
your early media message informing that this callee cant be reached for the
moment, then it will get busy tone. (maybe you can answer with 403 instead
of 486, 403 may play "error tone" in the callers phone)

Yes, I don't want "486" since the caller could thing that the callee us busy,
and it's not.
About replying a 403, yes, it could be, but again I don't know if it's better
than the "480 or 502".



Thanks a lot ;)

[Iñaki Baz Castillo]

Post by Bi Ran
Hi Castillo,
My two cents. As the provider I would not play early media for 404 case
since I know the PSTN provider will do it.

Yes, I understand it. Because of that I don't want replying a 404 when the
user is not registered, but RFC 3398 doesn't give me a obvious SIP code to
reply in this escenario (user not registered but user DOES exist).

Thanks.

[Paul Kyzivat]

If you mean the callee isn't registered in the sip sense, because the
phone isn't connected, but you know the number is assigned to someone,
then IMO 404 is not the right response. A better response is 480. And
this has nothing to do with 3398.

Paul

Post by Iñaki Baz Castillo
Hi, when I receive an INVITE from my provider SIP_PSTN gateway I do a lookup
in my internal ENUM.
If the E164 number is mapped to a local SIP user (client of mine) I look for
it in the location server.
If the user is registered I forwad the INVITE and so... all OK.
The problem is in the case the SIP user is not registered (by any reason).
Then my proxy replies "404 Not Found" to the provider SIP_PSTN gateway.
-------------------------------------------------------------------------------------------------
1 Unallocated number
This number is not in the routing table or it has no path across the ISDN
cloud (network).
1. Check routing table to see it the number is available.
2. Check to make sure the correct digits were dialed and it is a
valid number.
-------------------------------------------------------------------------------------------------
So my PSTN provider replies with ISUP "Unallocated number" and the caller
"Provider X informs you that the number you are calling doesn't exist"
This is a big inconvenient since me, as telephony provider, am responsible of
generating that early media message. In fact, when I receive a call to a non
"My provider informs you that the number you are calling is not available
now"
After the 183 I send a 404, so the gateway mappes it to "Unallocated number"
and the caller provider adds its own early media message... the caller
listens to two early messages (mine first and him provider's one later)!!
But the callee DOES exist, the only it occurs is that the SIP user is not
registered, just it. The number DOES exist in my system, so I think it would
be better if my provider gateway would map the 404 to any of those ISUP
-------------------------------------------------------------------------------------------------
3 No route to destination.
The dialed number is in the routing plan, but there is no physical route
to the destination.
1. The PRI D-Channel may be down at one end or the other.
2. The span or WAN is not connected correctly.
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
20 Subscriber Absent.
Used when a mobile station has logged off, radio contact is not
obtained with a mobile station or if a personal telecommunications
user is temporarily not addressable at any user-network interface.
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
27 Destination Out-of-Order.
This is a working number, but the span to the destination is not
active or there is a problem sending messages to this destination.
-------------------------------------------------------------------------------------------------
Unfortunatelly any of the above ISUP causes (decimal 3, 20, 27) exist as a SIP
code mapping in RFC 3398.
502 Bad gateway ---> 38 Network out of order
-------------------------------------------------------------------------------------------------
38 Network Out-of-Order.
Indicates that the network is not functioning correctly and that the
condition is likely to last a relatively long period of time.
-------------------------------------------------------------------------------------------------
So if the caller is a movile he will be first listen to my provider early
message, and later he will see "network failure" (or similar) into its
screen. It's dirty but it's the best option I've found.
Any suggestion to handle it more correctly? In short, I can't reply with "404"
since the caller will listen two early media messages and he will think that
the number doesn't exist.
Thanks for any help.

[Iñaki Baz Castillo]

Post by Paul Kyzivat
If you mean the callee isn't registered in the sip sense, because the
phone isn't connected, but you know the number is assigned to someone,
then IMO 404 is not the right response.

Yes, I completely agree with that.

Post by Paul Kyzivat
A better response is 480.

Why "480"? The RFC 3398 does this mapping for 480 code:

480 Temporarily unavailable --> 18 No user responding

Is it the best choice in the PSTN world?

Post by Paul Kyzivat
And
this has nothing to do with 3398.

Why do you say "this has nothing to do with 3398"? My question is with SIP
code is the best reply to send to a PSTN gateway when the SIP user is not
registered (but it does exists). Related to it there is a RFC 3398, so...


Thanks.

[Paul Kyzivat]

A UAS should not in general know whether it has been called by a gateway
or some other sip device. And so it should not be adjusting its
responses based on the kind of thing it thinks is calling.

The response returned by the UAS should best reflect the condition at
the UAS. The purpose of specs like 3398 is to specify how the sip codes
should be mapped to/from the pstn by gateways, not to specify how other
sip devices should behave.

Paul

Post by Iñaki Baz Castillo

Post by Paul Kyzivat
If you mean the callee isn't registered in the sip sense, because the
phone isn't connected, but you know the number is assigned to someone,
then IMO 404 is not the right response.

Yes, I completely agree with that.

Post by Paul Kyzivat
A better response is 480.

480 Temporarily unavailable --> 18 No user responding
Is it the best choice in the PSTN world?

Post by Paul Kyzivat
And
this has nothing to do with 3398.

Why do you say "this has nothing to do with 3398"? My question is with SIP
code is the best reply to send to a PSTN gateway when the SIP user is not
registered (but it does exists). Related to it there is a RFC 3398, so...
Thanks.

[Iñaki Baz Castillo]

Post by Andreas Byström (Polystar T &amp; M)
Does "user not registered" really fit into the description of 404 in
RFC3261? A subscriber that isnt registered does still exists in the domain
that is handled by the server, doesnt it? I would say that the description
-----------------------------
480 Temporarily Unavailable
"The callee's end system was contacted successfully but the callee is
currently unavailable (for example, is not logged in, logged in but
in a state that precludes communication with the callee, or has
activated the "do not disturb" feature)"
...
"This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI, but does not
currently have a valid forwarding location for that user."
-------------------------------
In my mind, an unregistered user does exist but the is no information in
the callee's system on how to reach the subscriber. Compare with PSTN or
mobile networks. If you unplugg your phone or turn of your mobile, the
caller will get the prompt "User is not reachable" and not "there is no
such number"

Yes, I have it clear now, thanks.

[Iñaki Baz Castillo]

Post by Paul Kyzivat
A UAS should not in general know whether it has been called by a gateway
or some other sip device. And so it should not be adjusting its
responses based on the kind of thing it thinks is calling.
The response returned by the UAS should best reflect the condition at
the UAS. The purpose of specs like 3398 is to specify how the sip codes
should be mapped to/from the pstn by gateways, not to specify how other
sip devices should behave.

Thanks, I agree 100% with you, but the fact is that returning a 404 to a
gateway produces an unexpected behaviour in the caller (its PSTN provider
tell him in early media that the callee number doesn't exist).

The question here (and I'm know more people wondering the same) is how to
differenciate a non existing user and an existing but not registered user. A
registrar will reply "404" in both cases, but 404 produces the wrong real
behaviour explained before.

RFC 3261 says:

--------------------------------------------------------------
404 Not Found

The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.
--------------------------------------------------------------

The question is: does a non registered user "exist" or not?


Thanks a lot for you comments.
--
ilimit...


*I?aki Baz Castillo*
ibc at in.ilimit.es

?REA SISTEMES
0034 937 333 375
VOLTA 1, PIS 5
08224 TERRASSA.BCN

Aquest enviament ?s confidencial i est? destinat ?nicament a la persona a qui
s'ha enviat.
Pot contenir informaci? privada sotmesa al secret professional, la distribuci?
de la qual est? prohibida per la legislaci? vigent.

[Andreas Byström (Polystar T &amp; M)]

Does "user not registered" really fit into the description of 404 in RFC3261? A subscriber that isnt registered does still exists in the domain that is handled by the server, doesnt it? I would say that the description of 480 is better for the unregistered case. RFC3261:
-----------------------------
480 Temporarily Unavailable

"The callee's end system was contacted successfully but the callee is
currently unavailable (for example, is not logged in, logged in but
in a state that precludes communication with the callee, or has
activated the "do not disturb" feature)"
...
"This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI, but does not
currently have a valid forwarding location for that user."
-------------------------------

In my mind, an unregistered user does exist but the is no information in the callee's system on how to reach the subscriber. Compare with PSTN or mobile networks. If you unplugg your phone or turn of your mobile, the caller will get the prompt "User is not reachable" and not "there is no such number"

Regards,
// Andreas


-----Ursprungligt meddelande-----
Fr?n: I?aki Baz Castillo [mailto:ibc at in.ilimit.es]
Skickat: den 5 mars 2008 10:05
Till: sip-implementors at lists.cs.columbia.edu
?mne: Re: [Sip-implementors] RFC 3398 - ISUP/SIP mapping: 404 ->Unallocated number ??

Post by Paul Kyzivat
A UAS should not in general know whether it has been called by a
gateway or some other sip device. And so it should not be adjusting
its responses based on the kind of thing it thinks is calling.
The response returned by the UAS should best reflect the condition at
the UAS. The purpose of specs like 3398 is to specify how the sip
codes should be mapped to/from the pstn by gateways, not to specify
how other sip devices should behave.

Thanks, I agree 100% with you, but the fact is that returning a 404 to a gateway produces an unexpected behaviour in the caller (its PSTN provider tell him in early media that the callee number doesn't exist).

The question here (and I'm know more people wondering the same) is how to differenciate a non existing user and an existing but not registered user. A registrar will reply "404" in both cases, but 404 produces the wrong real behaviour explained before.

RFC 3261 says:

--------------------------------------------------------------
404 Not Found

The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.
--------------------------------------------------------------

The question is: does a non registered user "exist" or not?


Thanks a lot for you comments.



--
ilimit...


*I?aki Baz Castillo*
ibc at in.ilimit.es

?REA SISTEMES
0034 937 333 375
VOLTA 1, PIS 5
08224 TERRASSA.BCN

Aquest enviament ?s confidencial i est? destinat ?nicament a la persona a qui
s'ha enviat.
Pot contenir informaci? privada sotmesa al secret professional, la distribuci?
de la qual est? prohibida per la legislaci? vigent.

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


This message has been scanned by F-Secure Anti-Virus.

[Paul Kyzivat]

I agree with you that the definitions of the codes are not entirely
clear. IMO 404 is not an appropriate response for a known and supported
AOR for which no device is currently registered.

Paul

Post by Iñaki Baz Castillo

Post by Paul Kyzivat
A UAS should not in general know whether it has been called by a gateway
or some other sip device. And so it should not be adjusting its
responses based on the kind of thing it thinks is calling.
The response returned by the UAS should best reflect the condition at
the UAS. The purpose of specs like 3398 is to specify how the sip codes
should be mapped to/from the pstn by gateways, not to specify how other
sip devices should behave.

Thanks, I agree 100% with you, but the fact is that returning a 404 to a
gateway produces an unexpected behaviour in the caller (its PSTN provider
tell him in early media that the callee number doesn't exist).
The question here (and I'm know more people wondering the same) is how to
differenciate a non existing user and an existing but not registered user. A
registrar will reply "404" in both cases, but 404 produces the wrong real
behaviour explained before.
--------------------------------------------------------------
404 Not Found
The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.
--------------------------------------------------------------
The question is: does a non registered user "exist" or not?
Thanks a lot for you comments.

[Iñaki Baz Castillo]

Post by Iñaki Baz Castillo

Post by Paul Kyzivat
A UAS should not in general know whether it has been called by a gateway
or some other sip device. And so it should not be adjusting its
responses based on the kind of thing it thinks is calling.
The response returned by the UAS should best reflect the condition at
the UAS. The purpose of specs like 3398 is to specify how the sip codes
should be mapped to/from the pstn by gateways, not to specify how other
sip devices should behave.

Thanks, I agree 100% with you, but the fact is that returning a 404 to a
gateway produces an unexpected behaviour in the caller (its PSTN provider
tell him in early media that the callee number doesn't exist).
The question here (and I'm know more people wondering the same) is how to
differenciate a non existing user and an existing but not registered user.
A registrar will reply "404" in both cases, but 404 produces the wrong real
behaviour explained before.
--------------------------------------------------------------
404 Not Found
The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.
--------------------------------------------------------------
The question is: does a non registered user "exist" or not?

After reading again I find "480" the best reply code whe the user does exist
but it's not available:

480 Temporarily Unavailable
[...]
This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI, but does not
currently have a valid forwarding location for that user.


While 404 means the user doesn't exist.

404 Not Found
The server has definitive information that the user does not exist at
the domain specified in the Request-URI.
[...]



Anyway, does someone know a proxy/location server that replies a "480" when an
existing user is not registered?