Subject: RE: [Sipping] Forking is just plain wrong ...

From: Eric Burger <[email-masked]>
Date: Tue, 8 Mar 2005 15:13:08 -0500

You answer your own question: this would be SO much cleaner as a B2BUA
function, rather than a SIP Proxy function.

> -----Original Message-----
> From: Gordon Ledgard [mailto:[email-masked]]
> Sent: Monday, March 07, 2005 3:10 PM
> To: Michael Hammer (mhammer); Eric Burger; Cullen Jennings (fluffy)
> Cc: sipping
> Subject: RE: [Sipping] Forking is just plain wrong ...
> 
> 
> 
> 
> I take it that this is a joke?  Or are people seriously considering
> deprecating forking?  
> 
> Frankly I think it would be a wonderful idea but I'd be surprised if
> there weren't too many implementations that depended on it.
> 
> That said, it seems that forking was designed to solve one basic
> problem:
> Q. When someone is trying to contact another person who may 
> be at one of
> several places, how do you keep the caller from loosing patience while
> a series of devices are rung in turn? 
> A. You don't. You ring them all.
> 
> (Or are there other fundamental things this was aimed to address that
> I'm
> not aware of?)
> 
> However, it seems to me that this is fundamentally an application
> problem,
> not one that should be solved by a protocol. Is the issue that an
> application would not work fast enough for the impatient caller?
> 
> Gordon Ledgard
> Iperia, Inc.
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Hammer (mhammer)
> Sent: Monday, March 07, 2005 1:49 PM
> To: Eric Burger; Cullen Jennings (fluffy)
> Cc: sipping
> Subject: RE: [Sipping] Forking is just plain wrong ...
> 
> For what it's worth, forking reminds me of the teenage kid 
> who throws a
> party while the parents are away, only to have the invitation 
> to one kid
> result in many kids showing up unexpectedly and in un-manageable
> fashion.  Starting a feature at one point in the network and 
> completing
> it in another place seems like a recipe for complexity and confusion.
> 
> Mike
> 
> 
> >-----Original Message-----
> >From: [email-masked] 
> >[mailto:[email-masked]] On Behalf Of Eric Burger
> >Sent: Friday, March 04, 2005 6:11 PM
> >To: Cullen Jennings (fluffy)
> >Cc: sipping
> >Subject: RE: [Sipping] Forking is just plain wrong ...
> >
> >Was I the only person to hum when Dean said "Who wants to 
> >deprecate Forking?" :)
> >
> >
> >-----Original Message-----
> >From: [email-masked] 
> >[mailto:[email-masked]]On Behalf Of Cullen Jennings
> >Sent: Thursday, March 03, 2005 6:17 PM
> >To: sipping; Jonathan Rosenberg
> >Cc: Dean Willis
> >Subject: [Sipping] Forking is just plain wrong ...
> >
> >
> >
> >My favorite line in the sippging-sip-arch  
> >
> >    "Forking, which allows multiple devices to be wrong at once, ..."
> >
> >Ok this is just a typo - but it amused me greatly. 
> >
> >_______________________________________________
> >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
> >
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 11:41:35 -0500

We are not deprecating forking. This was nothing more than an incredibly 
amusing freudian slip in the sipping-arch document. I can measure the 
volume of amusement by the fact that I got several private comments 
about this within an hour of posting the document ;)

While a b2bua can be used to provide this function, that is clearly not 
how we do it(or even want to do it). To understand why, you have to look 
back at SIP's primary role. It was designed as a rendezvous service - a 
way to connect a caller to the called party based on, to a large degree, 
policy on the terminating side. It was assumed that the user would have 
multiple devices. Thus, the kind of search and forking was a fundamental 
feature of the protocol. Once the call was set up, there was no reason 
for the network to be involved. Thus, forking and its implementation are 
a consequence of the two desires to provide a rendezvous service and to 
avoid network call state.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com