Subject: [Sip] Re: [Sipping] URI list for INVITE

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Oct 2006 16:33:21 +0300

Hi,

[moving this thread to SIP]

Different servers implement different services. The draft you point to 
describes how to provide the list of participants for a particular 
service: a conferencing service.

Note that the conferencing service is defined in a different set of 
documents.

So, if you want to define a different service, you should go ahead 
define it, and then explain UAs provide the server with the data it 
needs to execute the service.

Regarding your examples, if you want to influence how routing is 
performed, you may want to look at caller preferences.

Cheers,

Gonzalo

Miguel Garcia wrote:
> 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
>>
> 

_______________________________________________
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