Subject: Re: [Sipping] I-D Action:draft-schwartz-sipping-nsr-code-00.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 07:44:48 +0100

David,

I did not understand the motivation for this. It seems to me that 404 is
good enough. The UAC (or some intermediate proxy/B2BUA), on receipt of a
404, may be able to deduce that the Request-URI contains a number and
that retrying with a different domain part might work. Why would the
proxy or B2BUA that generates the response code be in a better position
to deduce this? Basically it has received a URI with its own domain in
the domain part and a user part that it does not recognise. Why should
it do further work to try to puzzle out whether the unrecognised user
part is indeed a telephone number that might be available at some other
domain? Just leave it to upstream entities to do that, if they wish.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 24 June 2008 00:00
> To: [email-masked]
> Subject: I-D Action:draft-schwartz-sipping-nsr-code-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : No Service To This Number Reject Code
> 	Author(s)       : D. Schwartz
> 	Filename        : draft-schwartz-sipping-nsr-code-00.txt
> 	Pages           : 7
> 	Date            : 2008-06-23
> 
> The Session Initiation Protocol (SIP) allows for users to make calls
> using telephone numbers embedded in either "sip" [RFC3261] or "tel"
> [RFC3966] URIs.  Either way, the telephone number (TN) itself is not
> restricted and can represent an entity in the public telephone
> network, an entity in a private telephone network or an entity on the
> Internet.  This TN resolution ambiguity highlights the difference
> between the LUF and LRF functions defined in
> [I-D.draft-ietf-speermint-terminology] and underscores the need for
> more precise SIP error rejection codes.  SIP has no way to indicate
> to the calling UAC that the reason for call rejection is due to the
> fact that this number does not exist in the requested domain or realm
> but it does exist in the public telephone network for instance.  Such
> an indication is useful to allow the call to be retried at a
> different context (i.e. the public PSTN in this case) with possibly
> better results.  This specification defines a new SIP response code
> for this purpose.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-schwartz-sipping-nsr
> -code-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David Schwartz <[email-masked]>
Date: Tue, 24 Jun 2008 15:41:36 +0300

Hi John,

First of all I would like to thank you for reading this and commenting  
- I am trying to gather feedback and all comments are welcome.

Let me please explain the underlying motivation and than let me  
address you comment.

It all comes down to semantics and automata. Do I want to give the UAC  
initiating the call enough information to possibly take some  
corrective action.

3261 defines 404 as follows:

21.4.5 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.

Note the word "definitive"

In a SIP URI (non e.164 username) world, the UAS processing the  
request has "definitive" information about its own domain. There is no  
point trying the same NON-MODIFIED request at a different domain since  
that other domain will simply route this back to this first domain  
that has already responded with a 404 and gave the UAC definitive  
information that this is pointless.  As we know all to well, when the  
username is an e.164 number the domain information is usually just  
that of the service provider with whom the UAC has a relationship but  
has little or nothing to do with the ability to say anything  
definitively about the username.  Sometimes, it may be possible to  
answer definitively and in these cases 404 is indeed appropriate. In  
other cases however it is semantically wrong to issue a 404 and it  
hinders ones ability to automate failover or route advance for these  
cases.  The fact that UAC's may be smart enough to take corrective  
action on a 404 does not mitigate the inherent ambiguity in the 404  
response used for this purpose.

As far as your point about the UAS vs the UAC I would say that in the  
case of a redirect server this is the very function of the redirect  
server to give the UAC direction as to "what to do next". This could  
be a 3xx redirect or it can be a 4xx "no I cant help you with this"  
response. The point of this draft is to address the latter and provide  
for a finer resolution response in the case where the number is not  
found.

D.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 16:01:24 +0100

David, 

> From: David Schwartz [mailto:[email-masked]] 
> Sent: 24 June 2008 13:42
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: I-D Action:draft-schwartz-sipping-nsr-code-00.txt
> 
> Hi John,
> 
> other cases however it is semantically wrong to issue a 404
[JRE] I disagree. It is semantically correct to issue a 404, because the
service provider has definitive information that the user does not exist
at the service provider's domain, i.e., at the domain specified in the
Request-URI. If the Request-URI contains some domain other than the
service provider's domain, the service provider should simply route to
that other domain, so the problem does not arise in that case.

> and it  
[JRE] I agree that the UAC may have some difficulty figuring it out, but
how can the service provider's domain figure it out? It knows the user
does not exist in its own domain, but how does it know whether the user
is likely to exist in some other domain?

John

---

From: David Schwartz <[email-masked]>
Date: Tue, 24 Jun 2008 18:13:14 +0300

On Jun 24, 2008, at 6:01 PM, Elwell, John wrote:

> Request-URI.

DS: Yes - but this domain is arbitrary - this is kind of like a letter  
of the law and spirit of the law discussion. By the letter of the law  
you are right but from a spirit of the law I am pointing out that the  
domain is arbitrary and hence we can do better than a 404.

> If the Request-URI contains some domain other than the

> is likely to exist in some other domain?

DS: All I am saying is that a 404 means "I know it doesn't exist here  
AND anywhere else" and I am looking for "I know it doesn't exist here"
>
>
> John
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

---

From: David R Oran <[email-masked]>
Date: Tue, 24 Jun 2008 11:28:20 -0400

On Jun 24, 2008, at 11:13 AM, David Schwartz wrote:

> DS: Yes - but this domain is arbitrary - this is kind of like a  
> letter of the law and spirit of the law discussion. By the letter of  
> the law you are right but from a spirit of the law I am pointing out  
> that the domain is arbitrary and hence we can do better than a 404.
>
Wow, do I disagree with the notion that the domains might be  
arbitrary. Having one domain make ANY assertion about things on the  
left of the "@" sign of another domain breaks the entire architecture  
of URIs. The owner of Cisco.com can with absolute confidence say that [email-masked] 
  does not exist at ANY server. Period.

The fact that [email-masked] might exist, or perhaps  
osama-bin-laden.tora-bora.pk might exist is utterly irrelevant to SIP  
routing. Even if a UAS or proxy for the stated domain COULD make some  
inference about the left-hand part when the domain part doesn't match,  
it definitely SHOULD NOT.

> DS: All I am saying is that a 404 means "I know it doesn't exist  
> here AND anywhere else" and I am looking for "I know it doesn't  
> exist here"
What do you mean by "here"? If you mean "in this domain" then the two  
statements are isomorphic. If you mean something else I can't find it  
anywhere in the semantics of SIP addressing.

Cheers, Dave Oran.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 16:27:07 +0100

David,

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Schwartz
> Sent: 24 June 2008 16:13
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] I-D 
> Action:draft-schwartz-sipping-nsr-code-00.txt
> 
> 
> > [JRE] I disagree. It is semantically correct to issue a 
> 404, because  
> > the
> > [JRE] I agree that the UAC may have some difficulty 
> figuring it out,  
> > but
[JRE] And I would contend that 404 means "I know it doesn't exist here".

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 13:44:15 -0400

David,

Did you consider the relevance of the 604 response code to this problem?

I think it could apply as follows:

- if the R-URI is a TEL:+12125551234 uri, and is received by a
   proxy/gw, then then that proxy/gw can return 604 if it is
   authoritative for that number and knows it is unassigned,
   or if it is a gw and has received info from an authoritative
   source that the number is unassigned. Or if it just doesn't
   know how to reach the number it can return 404.

- if the R-URI is sip:[email-masked], then the proxy/gw
   for atlanta.com can return 604 if it is authoritative for that
   number and knows that it is unassigned. Otherwise if it doesn't
   know about it it should return 404.

A UAC should give up if it receives a 604. If it receives a 404 and the 
URI was a phone number (whether in sip or tel form), then it may retry
using a different domain if it knows one.

	Thanks,
	Paul

---

From: David Schwartz <[email-masked]>
Date: Tue, 24 Jun 2008 23:51:48 +0300

Hi Paul

I think you understand the basic problem and while I agree that a GW  
can issue a 604 a proxy or redirect server can't or shouldn't.

As to why I am using a redirect server instead of just going straight  
to the GW - well this may be the LUF discussed in SPEERMINT and is not  
the topic of this thread.

The point is that I need a "don't know" and I don't have one. The  
logic you propose for the 404 is correct - its the UAC processing (is  
it a phone number or not...) that I would like to avoid by simply  
having the redirect server tell me "I don't know".  In this way I can  
save the 404 for a definite no - end call, and use the new code 4xx to  
fail over to other possible routing options that the redirect server  
may not be aware of (otherwise it would have returned a 3xx). Logic  
like "if you get a 404 AND a phone-number do A else do B" is clumsy  
and can be avoided by simply having the correct error code to  
represent this case.

There is a point that I raised before and I would like to repeat for  
clarity.  No one is suggesting anything new for vanilla flavored SIP  
URIs of the form sip:[email-masked].  example.com has one of two  
options only. Either alice can be reached within this domain or not.  
with either TEL URIs or SIP URIs containing domains that in most cases  
represent the domain of the service provider (and not necessarily the  
GW owner) there are three options. Yes, No and Don't know and I  
contend that 404 is being used to address both No and Don't know and  
we are relying on smarts in the UAC to disambiguate this leading to  
interoperability issues (e.g. "what error code can you send me to  
indicate that I should fail over to my next route since I will assume  
a 404 you (not the GW) send me is definitive and I will cease my  
efforts to re-route this call".

D.

On Jun 24, 2008, at 8:44 PM, Paul Kyzivat wrote:

> A UAC should give up if it receives a 604. If it receives a 404 and  
> the URI was a phone number (whether in sip or tel form), then it may  
> retry

---

From: David Schwartz <[email-masked]>
Date: Wed, 25 Jun 2008 00:02:00 +0300

Hi David (I quote the relevant parts of the thread below)

Everyone here seems to accept the need for an automatic mechanism of  
trying to terminate a call with an e.164 username at alternate  
destinations.

The two arguments against giving a proxy a way to say “not found here,  
but maybe somewhere else” are:

a) that it breaks the definition of a URL for a domain authority to  
suggest that an address in its domain can be terminated elsewhere
b) that all the decisions of the failover mechanism properly belong in  
the UA

I will now address these two points

a)      Fails to account for the fact that e.164 users are a unique  
phenomenon which in fact does “break”, or at least bend, the  
definition of URL.  It’s the only case we have of users that may exist  
on a parallel network, e.g. the PSTN.  The uniqueness of a URL is in  
the context of a given network; once more than one network is  
involved, we need to change our semantics accordingly (see many of the  
e.164 problem statement drafts)

b)      Sounds fair, but is simply not very useful.  The proxy is  
likely to have more information about the e.164 user – perhaps because  
it has access to a directory service – than the UA, which is one  
reason for sending a message via a proxy in the first place, and we  
would be hamstringing ourselves were we to insist on closing our eyes  
to helpful information that the proxy is in a position to provide.

D.

> left of the "@" sign of another domain breaks the entire  
> architecture of URIs. The owner of Cisco.com can with absolute  
> confidence say that [email-masked] does not exist at ANY  
> server. Period.
>
> osama-bin-laden.tora-bora.pk might exist is utterly irrelevant to  
> SIP routing. Even if a UAS or proxy for the stated domain COULD make  
> some inference about the left-hand part when the domain part doesn't  
> match, it definitely SHOULD NOT.
>

> What do you mean by "here"? If you mean "in this domain" then the  
> two statements are isomorphic. If you mean something else I can't  
> find it anywhere in the semantics of SIP addressing.
>
> Cheers, Dave Oran.
>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 22:04:36 -0400

David,

Let me get this right...

You have a phone number you want to route to. And you don't know what 
domain is responsible for it. And you want to just "guess" about the 
domain, construct a sip URI containing the phone number, and route the 
request to that domain.

Then you want that domain to give you responses that distinguish between 
"I'm authoritative for this number and it isn't assigned" vs "I'm not 
responsible for that number".

Do I have that right???

You wouldn't have that problem if you would figure out what domain is 
responsible for the number and then sent it there.

If you don't know a domain is responsible for a number, why would you 
trust it to tell you that the number is unassigned?

	Paul

David Schwartz wrote:
> Hi Paul
> 
> I think you understand the basic problem and while I agree that a GW can 
> issue a 604 a proxy or redirect server can't or shouldn't.
> 
> As to why I am using a redirect server instead of just going straight to 
> the GW - well this may be the LUF discussed in SPEERMINT and is not the 
> topic of this thread.
> 
> The point is that I need a "don't know" and I don't have one. The logic 
> you propose for the 404 is correct - its the UAC processing (is it a 
> phone number or not...) that I would like to avoid by simply having the 
> redirect server tell me "I don't know".  In this way I can save the 404 
> for a definite no - end call, and use the new code 4xx to fail over to 
> other possible routing options that the redirect server may not be aware 
> of (otherwise it would have returned a 3xx). Logic like "if you get a 
> 404 AND a phone-number do A else do B" is clumsy and can be avoided by 
> simply having the correct error code to represent this case.
> 
> represent the domain of the service provider (and not necessarily the GW 
> owner) there are three options. Yes, No and Don't know and I contend 
> that 404 is being used to address both No and Don't know and we are 
> relying on smarts in the UAC to disambiguate this leading to 
> indicate that I should fail over to my next route since I will assume a 
> 404 you (not the GW) send me is definitive and I will cease my efforts 
> to re-route this call".
> 
> D.
>

---

From: [email-masked]
Date: Tue, 24 Jun 2008 22:46:10 -0400

From: Paul Kyzivat <[email-masked]>

   Let me get this right...

It makes sense if the domain in question is a SIP trunking provider
which connects to the E.164 numbers that it can, and rejects the
remainder.  Then there's a value-add if the SIP trunking provider can
provide different responses for "this E.164 number is not valid; do
not attempt to use your gateway" and "this E.164 number is valid but
we do not route to it; use your gateway".  Or at least it does if the
provider can mark a large subset of E.164 numbers as definitively
invalid.

This is related to the open questions about "fallback routing", but
instead of providing a mechanism "try A, but if you can't get to the
destination, then try B", it allows the first destination to give
positive indication as to whether to try the second destination.

As others suggest, forking the call and then using 604 vs. 404 is a
reasonable solution to this problem, although 604 still has the
problems of all 6xx responses, in that it doesn't give the desired
effect if there is a fork further upstream.  I suppose you can just
decree that the scope of the 604 is limited to that one fork.

At first, I thought a 3xx response would be ideal, in that it allows
the primary domain to reject the call but direct the upstream element
to an alternative route to the destination, but that doesn't work for
a SIP trunk provider, as each customer PBX has a different fallback
URI, so the 3xx's would have to be customized per-customer.

Dale

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 25 Jun 2008 08:56:02 +0300

[email-masked] writes:

 > we do not route to it; use your gateway".  

i don't quite understand the above.  gateways usually don't accept
random callers to try them out.

if user of domain example.com sends a request sip:[email-masked] to
its outbound proxy serving example.com, the proxy checks if the +e164
belongs to a local user and if not, it can make various enum queries to
find out, which domain might serve the +e164.

if it does not find any, it sends the request to a pstn gateway, which
is chooses according to its local policy.  in my opinion, this gateway
must be the "right" one to forward the call to pstn.  of course, it may
be broken or busy, but it must not reject the call because it does not
like the +e164.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 07:44:41 +0100

David,

I can think of a some use cases:

1. The UA submits a Request-URI of the form
sip:[email-masked];user=phone. Perhaps it got this from an address
book, call log, etc.. If example.com says that +1234 is unknown, that
should be the end of the story. Of course, the UA can try again with an
alternative, but that is entirely down to the UA, and probably won't
happen.

2. The UA submits a Request-URI of the form tel:+1234. A proxy receiving
that can either do a look-up (the SPEERMINT LUF) to determine a domain,
or can pass it on to some other proxy that can do the look-up. If it
does the look-up and finds a domain, it can forward to that domain using
a Request-URI of the form sip:[email-masked];user=phone. If +1234 is
unknown to example.com, again it can simply reject it and it is up to
the domain that translated the tel URI to the sip URI to decide whether
to try alternatives. If it knows no alternatives (or the initial look-up
fails), the proxy rejects the tel URI or forwards the tel URI to some
other domain that might be able to resolve it. This decision is the
responsibility of the entity that translated the tel URI into a sip URI,
and does not require it to receive different response codes to the sip
URI.

3. The UA just submits a dial string that it expects will be recognised
by its local domain proxy. For example, sip:[email-masked] or
sip:[email-masked];user=dialstring. The local domain proxy (for
myexample.com) looks in its dial plan and decides to map it either to a
sip URI (as in 1 above) or a tel URI (as in 2 above). From thereon the
local domain proxy acts as the UA.

None of these require a new response code. 404 is sufficient for
rejecting a SIP URI. 404 might be sufficient for rejecting a tel URI, or
perhaps 604 if the entity has sufficient knowledge that the E.164 number
exists nowhere.

If the call ends up going to a PSTN gateway and the PSTN returns "not
known", then there might be grounds for sending a 604 rather than a 404
(regardless of whether the gateway received a sip URI or a tel URI).
However, that assumes that the PSTN gateway is able to access the entire
PSTN - is that reasonable, or will there be some gateways that can
access only a limited part of the PSTN?

John

> Sent: 24 June 2008 21:52
> To: Paul Kyzivat
> Cc: Elwell, John; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jun 2008 07:56:42 -0400

John,

Nice analysis. It does a much better job of making the point I was 
trying to make.

	Thanks,
	Paul