Subject: [SIP] Expressing multiple choices in INVITE?

From: [email-masked]
Date: Mon, 25 Sep 2000 15:29:38 -0600

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.

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.

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?

Jon Peterson
Level(3) Communications

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

---

From: Sean Olson <[email-masked]>
Date: Tue, 26 Sep 2000 10:00:41 +0200

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

> 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?)

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

> multiple choices in an INVITE? Any other suggestions for implementing this

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 :)