Subject: [Sipping] URI list for INVITE

From: "Darshan Bildikar" <[email-masked]>
Date: Fri, 29 Sep 2006 13:28:59 +0530

List,

I have recently gone through three drafts that I found interesting 

"draft-ietf-sip-uri-list-subscribe" - That allows a UA to create a
subscription to a list of resources in SIP

"draft-ietf-sip-uri-list-conferencing" - Allows conference creation using
SIP URI list services. 

"draft-ietf-sip-multiple-refer" - Refer a server to multiple resources. 

My understanding is that these drafts allow SIP requests to map to multiple
resources in order to avoid sending multiple requests. 

In this regard, I was wondering whether it can be extended to an INVITE
request too! That is, the mechanism defined in
"draft-ietf-sip-uri-list-conferencing" can be extended to normal INVITE
requests. The basic requirement is to allow an INVITE request to address
multiple AOR's. 

I know I am describing what is typically handled in by proxies through
parallel/sequential forking. But as I understand it, there is no mechanism
(correct me if I am wrong) to indicate to a server WHETHER to carry out
sequential or parallel forking. Also it is not currently possible to use a
combination of the two. Consequently, I can think of a few use cases where
in this information might be provided as user input. Some of them are
presented below

Use Case 1: Alice would like to indicate through an interface on her GUI
soft phone or a web page that she would like to talk to either Bob or Carol.
Note that Bob and Carol have different AOR's registered that MAY map to
multiple devices as indicated during REGISTRATION.

Use Case 2: A user could indicate through a web page for example, that he
wishes to talk to either of three people Alice, Bob or Carol. She wants
Alice and Bob to be tried in PARALLEL and if neither of them is available
then she would like to talk to Carol. 

Use Case 3: It would allow a server to offer this as a primitive to
requesting UA's i.e. a UA can request a server to "Route my call to a list
of SIP URI's one by one". It could then be exposed as a "service" that could
be invoked by enterprise applications through a generic interface (not
necessarily SIP)

In my opinion such a strategy would be of use when forking (using the term
loosely here) information is available only in RUNTIME (possibly as user
input) and cannot be configured statically in a proxy. 

I think this could be achieved by expanding the scope of
"draft-ietf-sip-uri-list-conferencing" to make it more generic. We need even
actually use a forking mechanism. An AS behaves as a B2BUA and generates a
separate dialog for each SIP URI in the list.

Thoughts/Comments?

Darshan

_______________________________________________
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