Subject: Re: [Sipping] URI list for INVITE

From: Miguel Garcia <[email-masked]>
Date: Sun, 01 Oct 2006 13:50:37 +0300

Hi Darshan:

The mechanism described in draft-ietf-sip-uri-list-conferencing does 
what you describe, at least at the high-level: It allows a user to send 
a single INVITE request to a URI-list server (which is effectively a 
conference server), to set up a conference with a number of invitees.

However, it seems from your e-mail that you want something else than 
this function. Use case 1 does not end up in setting up a conference, so 
you don't need a conference server. So it looks like something different 
in essence.

The three cases that you are describing imply two different mechanisms: 
one to carry the list of invitees, the other to carry a strategy (or 
policy) to contact those invitees e.g., whether to use sequential, 
parallel, or a mixed strategy.

So, I think what is missing from draft-ietf-sip-uri-list-conferencing is 
a mechanism where the sender of the request can convey a policy to 
contact those URIs. Then it is up to the URI-list server to accept the 
policy or not. This policy conveyance seems to be an additional building 
block that the mentioned draft. It may have some parallelism with the 
fork-directive of the caller preferences (RFC 3841).

/Miguel

Darshan Bildikar wrote:
> 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
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
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: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 5 Oct 2006 23:38:58 +0200

(As SIP WG chair)

These documents have transferred to SIP for formal submission to IESG
(because they contain SIP elements that can only be progressed by the
SIP group).

As far as the current status of these documents is concerned, WGLC is
regarded as complete, and we are about to draft the PROTO writeup for
submission to IESG.

If you comments are of a nature that prevent this happening, i.e. that
any issue of the documents requires more discussion in the SIP WG, can
you please repost such a comment to the SIP list (and can I stress some
urgency).

Regards

Keith

> -----Original Message-----
> From: Darshan Bildikar [mailto:[email-masked]] 
> Sent: 29 September 2006 08:59
> To: [email-masked]
> Subject: [Sipping] URI list for INVITE
> 
> List,
> 
> "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. 
> 
> 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
> "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
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>