Subject: RE: [Sipping] Telling a proxy which service to execute

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 9 Nov 2005 16:59:24 -0500

Am I missing something?  In some systems, they want a call to self to go
to voicemail.  You seem to be breaking this feature.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dale R. Worley
> Sent: Wednesday, November 09, 2005 3:11 PM
> To: Sipping
> Subject: Re: [Sipping] Telling a proxy which service to execute
> 
> On Sun, 2005-11-06 at 13:28 -0500, Jonathan Rosenberg wrote:
> > INVITE sip:[email-masked]
> > Route: sip:Bs-registered-contact
> > 
> > rather than what happens today:
> > 
> > INVITE sip:Bs-registered-contact
> 
> Though this does mean the UA has to recognize that "sip:[email-masked]"
> is one of its own names.  For an ordinary desk telephone, 
> this doesn't seem to be a problem, though for more complex 
> situations, an agent might not be able to recognize all 
> addresses that "are forwarded to it".
> 
> Even the phone case might be messy...  Consider this:
> 
> In a typical sipX SIP PBX (http://www.sipfoundry.org) 
> installation, each extension forwards to first, any 
> registered contacts (phones for the extension), and second, 
> the voicemail system.
> 
> So sip:[email-masked] is proxied to sip:[email-masked] and 
> then to sip:10.1.1.20;mailbox=123;action=deposit.
> 
> Currently, SIP phones do not recognize the AOL of one of 
> their line appearances as their own name.  So if you dial 123 (meaning
> sip:[email-masked]) from phone 123:
> 
> 1. The phone forwards it to the proxy for example.com.
> 
> 2. The proxy forwards it first to sip:[email-masked].
> 
> 3. The phone rejects that call with 486 Busy.
> 
> 4. The proxy forwards it next to
> sip:10.1.1.20;mailbox=123;action=deposit, which being the 
> voicemail system, accepts the call.
> 
> If the phone were to recognize sip:[email-masked] as being 
> itself, the process would be short-circuited.  The phone 
> would not forward the call at all, and terminate it itself.  
> But it would reject the call with 486 Busy and the call would 
> never get to voicemail.
> 
> Of course, this is a pretty marginal example, but I suspect 
> that there might be more reasonable cases that would 
> demonstrate problems as well.
> 
> Dale
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.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
> 

_______________________________________________
Sipping mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Nov 2005 18:44:47 -0500

Mike,

Getting call to self to go to voicemail may or may not require some kind 
of special case in the proxy or the phone. The kind of change proposed 
may affect which particular kinds of special case are required, but 
certainly won't prevent making this particular feature work.

However, in a sip environment it might be undesirable to have a call to 
self go immediately to voicemail. If there are multiple registered UAs, 
then call to self could be valuable to reach one of the other registered 
UAs. For this to work, all that is necessary is for the UA originating 
the call to recognize its own call and refuse it rather than answer it. 
This is similar to what Dale suggested, but there are other ways to 
recognize this as a call it originated, such as checking the callid or 
contact address.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 14 Nov 2005 23:50:51 -0500

> certainly won't prevent making this particular feature work.

I've forgotten some of the context of this discussion, so I can't answer
to all the details.

The higher-level design principle is that a call from A to A should be
routed just like a call from X to A.  Any non-uniformity will at some
time come back to haunt you.

Within that principle, you have to be careful about how a UA handles a
call to "user@domain" -- if the UA isn't a declared proxy for "domain",
it must forward the call to the declared proxy, or else in some way
guarantee that it processes the call *exactly* like the declared proxy
would.

This still applies if the UA is a registered contact for "user@domain"
-- generally, the UA doesn't know the call processing logic for
"user@domain".

If I punch "123" on my phone, it generates "INVITE [email-masked]
SIP/2.0", and has to route that correctly, whether 123 is my extension
or another extension.

I think that these principles are going to wreak havoc on something

>> Route: sip:Bs-registered-contact

The trouble is that the UA will see and strip off the Route.  After
that, how is it to process "sip:[email-masked]"?  By uniformity, it
shouldn't use a special case, as someone could have constructed that
combination without knowledge that the AOR and contact URI correspond,
and really expect it to be routed through the proxy for example.com.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 15 Nov 2005 09:17:13 +0100

Dale,
> that, how is it to process "sip:[email-masked]"?

The UA should submit it to its location service, which resolves it to its 
contact (just like a proxy would do). It should then recognise that the 
contact matches a local network interface, and therefore process the request 
instead of forwarding it

> By uniformity, it

If they added a Route header with a contact address, that expectation 
wouldn't be justified (unless they knew that the contact belonged to the 
proxy). Omitting the Route would generally result in routing through the 
proxy

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 15 Nov 2005 10:28:47 -0500

> contact matches a local network interface, and therefore process the request 

In the cases I'm familiar with, the UA's "location service" (RFC 3263)
will discover that there is an SRV record for "example.com" which
specifies the proxy for example.com, not the UA's address.  And if the
UA forwards the request to the proxy, the proxy will forward it on (to
the contact), rather than returning a 302 to tell the UA to forward it
to the contact (itself).

That is, although the UA knows (by its own configuration and the success
of its registration) that it is *a* registered contact for
[email-masked], it has no way to determine whether there are other
contacts for [email-masked], or what its priority is vis-a-vis those
other contacts, or whether there may be special processing rules in the
proxy that prevent *any* calls from reaching it.

> proxy). Omitting the Route would generally result in routing through the 

Strictly speaking, with a Route header, the request must go through the
host designated in the Route header, and that host must send it to the
registered contact point for the domain of the Request-URI.  The host in
the Route header isn't allowed to shortstop the request, unless it has
positive knowledge that the registered contact for the Request-URI would
only send the request to it again.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 15 Nov 2005 16:49:32 +0100

Dale,

I'm sorry, I was reasoning along the new routing rules we discussed (i.e. 
proxy adds a Route header with the Contact, instead of rewriting the URI)

Obviously, for that to work the reception rules at the UA will need to 
change /  be clarified. Perhaps it would help if the proxy were to mark the 
Route header it adds as a 'final' destination (given that Route currently 
points to intermediates, "go-through" semantics)?

Something like:
INVITE sip:[email-masked]
Route: <sip:Bs-registered-contact>;final

A UA receiving such a Route header would not be allowed to forward the 
request further (i.e. the flag tells it that it should assume it's the final 
and only destination, it provides the positive knowledge that you were 
talking about below)

Jeroen

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Nov 2005 19:25:39 -0600

On Nov 15, 2005, at 9:28 AM, Dale R. Worley wrote:
> ...

Your "strictly speaking" case doesn't hold water, I think. That is,  
the "must send" is by no means a MUST.

Here's an example. Assume a proxy has knowledge of a Contact  
registered for an AOR. It also has policy information saying that the  
user of that AOR expects to be asleep from 0:00 to 08:00. A request  
arrives at the proxy at 0400. MUST the proxy send the request to the  
registered contact? I think not. Reasonable designs would have it  
either forwarding the request to voicemail, redirecting to voicemail,  
or issuing a retry-after 0800.

Proxies can also apply policy to determine which of several  
registered contacts should receive a request. They're by no means  
constrained to route the request to all of the registered contacts.

By this model, the new-and-improved UAS is both a UA, and a special- 
purpose proxy a with policy of routing inbound requests only to  
itself and not to any other registered contacts.

It seems to me like this works ok.

One might rephrase as:

The UA can differentiate between "inbound" and"outbound" requests.

On an inbound request, the UAS can say "Ok, there's no Route header  
left, and the Request-URI is for one of my AORs. That means it is for  
me. I should answer."

But when the user initiates a new request with the same Request-URI,  
the UAC knows that this is an outbound request, It applies different  
processing logic, which you describe above.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Nov 2005 22:07:49 -0500

I don't think this is needed at all. The UA wouldn't be getting the 
request in the first place unless it had been meant to process it. The 
UA logic that would go with this change is simple IMHO; a UA will accept 
a request if it serves requests for the identity in the R-URI. For 
single-user UA, like softphones and adaptors, this would be the AOR for 
the subscriber (which it knows). For PSTN gateways - any phone number.

I don't think there is any obligation for a UA to actually execute 
RFC3263 logic and route the request to the domain in the R-URI in case 
its NOT able to service requests for that URI. Rejecting with a 404 is fine.

The way I have proposed dealing with the backwards compatibility issue 
is to tie this to sip-outbound; if you support sip-outbound you're UA 
would also have to be prepared to receive requests in this form. I think 
its possible to couple it even more loosely, and to use a separate 
option tag for this. A UA could register and use sip-outbound but not 
include the token for this; that would imply that it would only receive 
requests the "old" way, with its registered contact in the R-URI. If it 
registers with a Supported: header field including the option tag 
"ua-route" or whatever we call this, AND it used sip-outbound, then this 
behavior would get used.

This allows us to decouple this whole discussion from sip-outbound, 
probably a good idea given the importance of sip-outbound and the 
relative work remaining in specifying this mechanism.

-Jonathan R.

Jeroen van Bemmel wrote:

> Dale,
> 
> I'm sorry, I was reasoning along the new routing rules we discussed 
> (i.e. proxy adds a Route header with the Contact, instead of rewriting 
> the URI)
> 
> change /  be clarified. Perhaps it would help if the proxy were to mark 
> the Route header it adds as a 'final' destination (given that Route 
> currently points to intermediates, "go-through" semantics)?
> 
> Something like:
> INVITE sip:[email-masked]
> request further (i.e. the flag tells it that it should assume it's the 
> final and only destination, it provides the positive knowledge that you 
> were talking about below)
> 
> Jeroen
> 
> ----- Original Message ----- From: "Dale R. Worley" <[email-masked]>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2005 09:03:32 -0500

inline

Dean Willis wrote:
> Your "strictly speaking" case doesn't hold water, I think. That is,  the 
> "must send" is by no means a MUST.
> 
> Here's an example. Assume a proxy has knowledge of a Contact  registered 
> for an AOR. It also has policy information saying that the  user of that 
> AOR expects to be asleep from 0:00 to 08:00. A request  arrives at the 
> proxy at 0400. MUST the proxy send the request to the  registered 
> contact? I think not. Reasonable designs would have it  either 
> forwarding the request to voicemail, redirecting to voicemail,  or 
> issuing a retry-after 0800.
> 
> Proxies can also apply policy to determine which of several  registered 
> contacts should receive a request. They're by no means  constrained to 
> route the request to all of the registered contacts.
> 
> purpose proxy a with policy of routing inbound requests only to  itself 
> and not to any other registered contacts.
> 

I think a proxy has discretion to retarget only when it is responsible 
for the R-URI. If it was reached as a result of a Route header, and is 
not responsible for the R-URI, then I think it must leave the R-URI 
alone. In that case, it may insert a Route header, and it then must 
route based on the top Route header, if any, or based on the domain in 
the R-URI.

So in the case under discussion the question comes down to whether a UA 
that receives a request with its AOR in the R-URI can consider itself 
responsible for the AOR. Based on existing specs I would say "no", so it 
would have to proxy, redirect, or fail the request. But we are indeed 
talking about a "change" to specifications now. Part of that change is 
to define how this should work.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 16 Nov 2005 15:19:46 +0100

> I think a proxy has discretion to retarget only when it is responsible for 
> the R-URI. If it was reached as a result of a Route header, and is not 
> responsible for the R-URI, then I think it must leave the R-URI alone. In 
> that case, it may insert a Route header, and it then must route based on 
> the top Route header, if any, or based on the domain in the R-URI.
>
> would have to proxy, redirect, or fail the request.

Existing spec (section 8.2.2.1):  it SHOULD reject the request with a 404 
(Not Found) response
This is because existing UAS will expect the request-URI to be a Contact 
address, not an AoR. It will not identify any address of the UAS, so it 
should send 404

Seems like we need to define the notion of "an UA being responsible for an 
AoR", similar to the notion of a proxy being responsible for a domain. There 
could be multiple UAs responsible for the same AoR, each individual UA may 
or may not be aware of the others. The responsibility would be set by an 
administrative action (also UAs that don't REGISTER can be responsible for 
an AoR, but perhaps when registration fails the UA should not assume 
responsibility(?))

Jeroen