Subject: RE: [Sipping] I-D: A New Forking Mechanism for Gathering andDistributing Information

From: "Michael Procter" <[email-masked]>
Date: Mon, 6 Mar 2006 16:09:20 -0000

Dale R. Worley wrote:
> I have just submitted an Internet-Draft proposing to define a way to
> mark a request to modify how it is forked:
> 
>    A New Forking Mechanism for Gathering and Distributing Information
>                     draft-worley-sipping-forking-00

I have just read this draft, and I think you have identified an
interesting problem with the interaction between forking and certain
types of service.

One area that I think is particularly interesting is the case where
the initial request-URI does not resolve directly to Contact URIs,
but instead resolves to intermediate AoRs.

An example, using your scenario in section 3.5, might be to send the
initial INVITE to the alias 'sip:[email-masked]', if you want to
have a conference with all your sales personnel.  This alias in turn
resolves to the AoRs sip:[email-masked], sip:[email-masked] and 
sip:[email-masked].  It is natural to fork the INVITE in parallel
to all these targets, as your draft encourages.

Now, if sip:[email-masked] resolves to two Contacts (desk phone
and cell phone, maybe) with differing q-values, what should happen?
Should the q-values be honoured?  Or should they both receive the
INVITE after parallel forking?

The question I am really asking is whether the change to forking
policy should affect the first fork only, or all forks involved in
the process?  I can see arguments for either, in different
circumstances.

I think it is interesting to compare this approach with the one taken
in the URI-list work (draft-ietf-sipping-uri-services et al).  They
both seem to be tackling the same basic problem (addressing multiple
destinations simultaneously) but in different ways (using a B2BUA to
'fork' the transactions as required, versus tweaking the forking
algorithm of a proxy).  There are, of course, several obvious
differences too.

Regards,

Michael Procter

_______________________________________________
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