Subject: RE: [SIP] query on forking.

From: [email-masked]
Date: Sun, 10 Dec 2000 12:16:04 +0530

Jonathan,
I was thinking of something simpler like adding a caller-callee preferences
token asking the forker to return all responses
(or maybe in require).
How about that ?

Regds
Arjun

Jonathan Rosenberg <[email-masked]> on 12/10/2000 03:42:59 AM

To:   archow, [email-masked]
cc:

Subject:  RE: [SIP] query on forking.

Reach all is not supported through the existing forking mechanism.

You will need to do something like fully-distributed multiparty
conferencing, TBD.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2000 12:42 AM
> To: [email-masked]
> Subject: [SIP] query on forking.
>
>
>
>
> Hi,
> assume I want to set up a chat with a group called "all-boys".
> My proxy server knows who all are in "all-boys" , I dont.
> so I send a message:
>
> MESSAGE sip:[email-masked]
> <xxxx>
>
> and the server forks this to
>
> sip:[email-masked]
> sip:[email-masked]
>
> Typically, if say boy1 returned OK and boy2 some 4xx message,
> the forking
> proxy would only send
> me the 200 OK. (best response)
>
> However  I want to receive both success and failure. That is,
> I want to
> know if boy2 returned fail .
> This may be necessary when I am sending a group request to
> people and my
> intent is not a "reach first" but
> a "reach all". If I know boy2 failed, I might use another
> means to send him
> the same message.
> Note that  I do not want to broadcast or multicast.
>
> so my question is: is there any way to use a forking service
> here and have
> it return all responses  and not
> only the "best" responses ?
>
> I noticed the recurse tag in caller and callee preferences -
> but that only
> seems to take care of either replying recursively to 300
> class messages or sending them back to the caller.
>
> Regds
> Arjun
>
> --
> Arjun Roychowdhury @ Hughes Software Systems
>
>
>
>
>
>
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>

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

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

---

From: Billy Biggs <[email-masked]>
Date: Sun, 10 Dec 2000 02:48:30 -0600

[email-masked] ([email-masked]):

> I was thinking of something simpler like adding a caller-callee
> preferences token asking the forker to return all responses (or maybe
> in require).  How about that ?

  You want to receive ALL responses to a transaction?  Uh-oh.

  This will never work for non-INVITE transactions since there is no
mechanism to reliably transmit multiple responses.  Too bad.

  You're not much better off for INVITE transactions.  First you need a
parameter to indicate you require this behavior.  Next, all proxies
along the path MUST (proxy-require'd) send some special response code
signaling to the previous hop that all branches have been checked:
otherwise there would be no way for anyone to know when to clean up
transaction state.  UAs would need to send this special code as well,
sending two responses to the INVITE (require'd).  All of these responses
would require unique To tags.

  Wow, that's alot of work.

  There is no simple way to solve this problem at the SIP layer.  Use
the user's or group's presence information instead.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]