Worley, Dale R (Dale) wrote:
> Well, yes, if there is no forking, then 6xx doesn't present any
> problems. But forking is a inherent part of SIP, and (at least in the
> 6 years of experience I have building SIP-based PBXs) forking is
> ubiquitous in implementing interesting and useful features.
Forking has been part of core SIP for as long as I have
known it. Whether or not it should have been made part
of core SIP has been debated before. Personally, I think
that insofar as SIP was designed as a rendezvous protocol,
forking makes a lot of sense.
> And any situation in which forking is present, generating
> 6xx responses usually leads to undesired outcomes.
SIP has a 6xx-class response for a reason. However, to
exorcise an entire response class because it does not
work with forking seems to be throwing the baby out
with the bathwater, but that is what rfc3261 seems to
do since the 6xx responses mask repairable responses
when forking occurs. *That* is the root of the problem.
Whether or not it is worth fixing is another debate.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
