Subject: [Sip] Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions)

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Nov 2003 15:30:29 -0800

The example you gave below is exactly what I am saying is parameterless.
Effectively there are no parameters - the URL is always
vlmner@vmhost;boxid=172.198,GR=27. I understand you CPL script could decided
to use different parameterless URLs.

If you needed to have parameters (ie something that algorithmically changed)
this would not work.

Cullen

On 11/21/03 3:02 PM, "Dean Willis" <[email-masked]> wrote:

>> As such, I think the 3087 model only works for cases where
>> the service 
>> invocation is parameterless; i.e., its a pure proxy function, without
>> the need for the proxy to know how to pull information out of
>> messages 
>> or other context, and shove it into an r-uri.
> 
> Not sur we agree here. The Proxy doesn't have to understand ANY of this.
> Whoever sets up the forwarding entries on the proxy has to understand it.
> 
> Case in point:
> 
> If you call +1 972 473 5455, this ends up as an INVITE to
> sip:[email-masked].
> 
> This SIP URL is served by a proxy -- in fact, it's a really stupid antique
> proxy that hasn't been updated in years. All it knows how to do is apply a
> primitive version of CPL to the call . . .
> 
> So this week, my CPL says "Fork to all registrations".
> 
> As a result, all my phones ring -- and if none of them answer, after ten
> seconds, the Asterisk voice mail server that also registered to
> [email-masked] asnwers, and the caller gets my voice mail.
> 
> Two weeks ago, my cpl said: "Fork to all registrations, and if not answered
> in 8 seconds, cancel all forks and forward to phone number 2142821376",
> which diverted it to my cell phone, which if not answered diverts to voice
> mail.
> 
> Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me the
> CFBNA URI for my new box is:
> 
> sip:[email-masked];boxid=172.98
> 
> Cool. My proxy doesn't have to understand this. All I have to do is paste it
> into my cpl, and we're good to go.
> 
> Now, let's say I wanted a different greeting for when my one and only SIP
> phone is busy. I go back to VoiceMailsRUs, and the tell me to use the
> optional code GR with a value of 27 to get the nifty new "Hi, this is Austin
> Powers. The swinging cat you have called is too groovy to chat right now.
> Behave, and leave a message" message.
> 
> So, I go change my CPL to forward calls, on "busy" at all forks, to
> 
> sip:[email-masked];boxid=172.98,GR=27
> 
> And once again, despite complete ignorance of anything above the level of
> SIP response codes in my proxy, I get the service I wanted.
> 
> THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY EXTERNAL
> SEMANTIC MAP.
> 
> The flip side of the rationale of 3087 is to ask "And how does VoiceMailsRUs
> feel about this?" After all they're going to buy some VM boxes from Bob, and
> some from Alice, and they want both brands to work with thir provisioning
> system, which uses a naming convention made up a demented gnome who retains
> his position by controlling incriminating photos from the 1999 company party
> . . .
> 
> So VoiceMailsRUs wants their provisioning system to be able to hook up to a
> new VM box and say to it "Make me a new box named
> vlmner@vmhost;boxid=172.198,GR=27, and provision it with the greeting
> APSWCYCISTGTCRNBALM.WAV".
> 
> VoiceMailrsRUs does NOT want to have to change their provisioning system to
> understand the behavior-specific mailbox generation semantics of Alice, or
> of Bob, or Charlie, or any other smug vendor who thinks they can replace the
> entire installed base at VoiceMailsRUs.
> 
> And that's where 3087 came from.
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Nov 2003 18:31:42 -0600

> If you needed to have parameters (ie something that algorithmically changed)

OK, just to see if you mean what I think you mean--you speak of 
situations (exploders, for example) where some input cannot be know in 
advance, right? This makes sense for ad-hoc exploder lists, since they 
by nature cannot be known in advance. VM is usually _not_ a good 
example, since the number of initial states probably can be known in 
advance.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Nov 2003 00:24:38 -0500

> example, since the number of initial states probably can be known in 

I was thinking of different cases, where the information is known at 
the time a message is received, but is, as Cullen put it, 
algorithmically derived from some aspect of the request.

As an example, consider a message transcoding service that takes SIP 
MESSAGE requests, and transcodes the content from one type to another 
type, and then forwards the request to the recipient. In such a case, 
the service can be viewed like a method invocation that takes two 
parameters - the recipient and the mime type to convert to:

doTranscode(SipURI recipient, MIMEType targetMimeType);

so, if a proxy receives a request like:

MESSAGE sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Content-Type: image/jpeg
.....

the proxy would forward it like this:

MESSAGE 
sip:[email-masked];recpt=[email-masked];target=image/tiff

In this case, the proxy would need to algorithmically derive the recpt 
parameter (its equal to the r-uri) and the target (its based on mime 
types that are listed as supported from the calle caps in the 
registration from the UA).

This service requires the proxy to understand its semantics, and to 
know how to compute the two parameters used in its invocation.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Nov 2003 15:34:42 -0600

Jonathan Rosenberg wrote:

> I was thinking of different cases, where the information is known at the 
> time a message is received, but is, as Cullen put it, algorithmically 
> derived from some aspect of the request.
> 
> This service requires the proxy to understand its semantics, and to know 
> how to compute the two parameters used in its invocation.

I think we are talking about the same thing. You cannot know in advance 
who the final recipient of a message requiring transcoding will be, just 
like you cannot know in advance what the membership of an ad-hoc list 
will be.

On the other hand, one probably _can_ know the target mime-types in 
advance, so one could pre-define a separate URI for each. Of course, 
this gets cumbersome if the number of target types is large.