Subject: [SIP] query on forking.

From: [email-masked]
Date: Wed, 6 Dec 2000 11:12:10 +0530

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 9 Dec 2000 17:12:59 -0500

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,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Dec 2000 18:39:47 -0500

This is simply not going to work. It would require modification of
fundamental retransmission and transaction processing in all proxies on the
path. The current state machines assume only a single non-200 response is
ever sent. 

-Jonathan R.

---

> Sent: Sunday, December 10, 2000 1:46 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] query on forking.
> 
> 
> 
> 
> 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.
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 11 Dec 2000 09:11:17 +0530

Jonathan/Billy,
Im obviously missing something.

Let me state my requirements again.

1. I want the proxy that forked to send back all final responses to me
instead of the best.

2. When I say I want to receive ALL responses, of course Im not talking
about a new fangled way to receive non-INVITE
   responses reliably. If that response gets lost and I retransmit, the
case is no different from any other non INV transaction in SIP.
  I'm talking about an inbetween proxy forwarding that response back -
thats all.

This means that the only server inbetween that really has to honour my
request would be a proxy that forks.
Proxies that dont fork, as it is will proxy the final responses back
anyway,

Now come to the case of the forking proxy.
Im suggesting that we add something like:

Request-Disposition:all-response
which is propogated to all the proxies in the path, and is processed by
proxies that fork.

It is possible that some proxies in between do not understand this
extension of ccp. Well, in that case, either he will return
an error saying he cannot handle it, or I will have to live with the
possibility that someone in between may be chopping off
final responses. Im ok with that.

The only place I see which has to add logic is a forking proxy. And that
too, its an extension. If you dont support it, return an error.
Im fine with that. I dont see why it results in UAs sending special codes ,
or why it breaks all nodes in between.

Could you sight an example as to why this would not work ?

Regds
Arjun

Jonathan Rosenberg <[email-masked]> on 12/11/2000 05:09:47 AM

To:   archow
cc:   [email-masked]

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Dec 2000 22:55:40 -0500

> Sent: Sunday, December 10, 2000 7:41 PM
> To: Jonathan Rosenberg; [email-masked]
>    responses reliably. 

Of course you are. The request is non-INVITE, and you need to get the
responses reliably.

If that response gets lost and I 
> retransmit, the

No. It effects the basic retransmission rules for non-INVITE. You simply
cannot receive more than one final response. Period. This is documented in
the FAQ:
http://www.cs.columbia.edu/~hgs/sip/faq/cache/91.html

Its not just that one proxy, of course. The multiple responses would have to
be forwarded upstream by all proxies to get back to you.

-Jonathan R.
---

---

From: [email-masked]
Date: Mon, 11 Dec 2000 09:52:45 +0530

> about a new fangled way to receive non-INVITE

jdr> Of course you are. The request is non-INVITE, and you need to get the
jdr> responses reliably.

Agreed. Although getting response reliably was not my primary goal, I
realise that
this scheme will fail in it - and that is a good enough reason for not
using the mechanism
I was suggesting.

Regds
Arjun