Subject: RE: [SIP] Expressing multiple choices in INVITE?

From: [email-masked]
Date: Tue, 26 Sep 2000 10:53:12 -0600

In reference to the notes inline below:

Yes, I am assuming that each of the URIs are literally for the same host -
again, the original URI would have to yield multiple discrete termination
points for this to be meaningful, but I think examples of this abound in IP
telephony services. A PBX could be implemented as a proxy (for other UAs) or
a gateway UA (to conventional phones for which it performs translations) -
I'm considering the latter case here. Were I considering this functionality
for a proxy, this wouldn't be quite as problematic.

Piggybacking the three INVITE messages into a single packet would work for a
parallel search - or at least, it would be more efficient than sending three
messages in separate packets. The size of the packets is a lesser concern, I
think. The problem I'm exploring, though, is eliminating the need for an
exchange between UA1 and UA2 (and specifically for the sequential search
case, in which piggybacking isn't as meaningful - the qvalues in the 300
specify priorities for the route choices, and hence they should be tried
one-by-one in order). So in other words, I would like to prevent unnecessary
backwards messaging from UA2 to UA1 as well as consolidation of signaling
from UA1 to UA2. The whole idea is to optimize the exchange of messages
between these two entities.

As for the Request-Disposition, it could be used to indicate that the search
should be sequential and so forth, but once again I think the draft is
oriented towards how a proxy should behave, rather than how a UA should
behave. But this does beg a good question - if a UA can parse
Accept-Contact, why not Request-Disposition, and why not the whole
callerprefs draft? It isn't clear now what kinds of complications might
arise from extending callerprefs to full support for UAs.

As for CPL, I'd like to think a UA could figure out how to try a few URIs
without having to execute a script... :) 

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Tuesday, September 26, 2000 2:01 AM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [SIP] Expressing multiple choices in INVITE?

Comments inline
Sean
--
Sean Olson <[email-masked]>

[email-masked] wrote:

> I've been shopping around for a mechanism in SIP that will allow me to
send
> multiple target URIs in a single INVITE message to a UA. Consider, for
> example:
>
> UA1 sends out a SIP INVITE that eventually hits a redirect server which
> sends back a 300 with four Contact URIs. The first three URIs identify
users
> (with qvalues) at UA2: harpo@ua2;q=0.1, chico@ua2;q=0.2, and
> groucho@ua2;q=0.5. Let's say that UA1 understands that it will perform a
> recursive sequential search. And also, for this to make sense, UA2 has to
be
> an entity that manages multiple discrete users (like a PBX or some kind of
> gateway), and it must have made sense for the URI in the original INVITE
to
> be mapped onto multiple possible termination URIs.

I'm assuming then that these N Contact URIs are all for literally the same
host/domain and not several aliases for the same node? (Are you
suggesting that this mechanism work for intermediate proxies as well?
Do you see the PBX as a proxy or a gateway?)

>
> Ordinarily, UA1 would first send an INVITE to groucho@ua2. If UA2 is
unable
> to accept the session for any reason, it would return an appropriate
status
> code, and then (if appropriate given the status) UA1 would send a new
INVITE
> to UA2 for chico@ua2. If Chico weren't available Harpo would be tried in
> turn.
>
> What I'm looking for is a mechanism by which UA1 could send a single
INVITE
> to UA2 containing the URIs for Groucho, Harpo and Chico, with their
qvalues,
> in order to allow UA2 to try them all without any intermediate signaling
as
> it traverses the choices. Presumably, only if none of the three were
> available would UA2 return a failure code to UA1. This could result in
> consideration optimization of signaling message exchange (hence cutting
down
> on session setup time and whatnot) for relevant applications.

Are you against piggybacking of the SIP messages in a single packet?
I realize this solution is not ideal as SIP messages seem to be growing by
leaps and bounds with Route: headers, etc.

> It has been suggested to me that the Accept-Contact header specified in
the
> callerprefs draft:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-02.txt
> is relatively close to what is desired here. Using that header, one could
> construct a message like:
>
> INVITE sip:ua2.level3.net SIP/2.0
> ...
> Accept-Contact: sip:[email-masked];q=0.5,
>                   sip:[email-masked];q=0.2,
>                   sip:[email-masked];q=0.1
>
> This differs in a couple of ways from the assumptions of the callerprefs
doc
> - the most salient difference being that in this example the target of
this
> INVITE is a UA rather than a PS. Also, the user portion of the Request-URI
> is left unspecified - all destination addresses for the session are
assumed
> to be in the Accept-Contact header.
>
> Does anyone have strong feelings for or against this method of expressing
> multiple choices in an INVITE? Any other suggestions for implementing this
> functionality?

Do you intend to allow Request-Disposition: as well? An alternative approach
would be to ship a CPL script along with the request -- not an attractive
approach, but possible :)

> Jon Peterson
> Level(3) Communications

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip