On Fri, Dec 12, 2008 at 4:13 PM, Scott Lawrence <[email protected]> wrote: > > On Fri, 2008-12-12 at 15:59 -0500, M. Ranganathan wrote: >> On Fri, Dec 12, 2008 at 3:19 PM, Arjun Nair <[email protected]> wrote: >> > Dale Worley wrote: >> >> Looking at 3261 and 2543, I think the point is that in 2543, both from- >> >> and to-tags are optional, but people rapidly learned that the UAS needs >> >> to provide a to-tag to allow forking to be handled correctly. >> >> >> >> So I think the "compatibility with 2543" point is that the from-tag may >> >> be missing, but that to-tag processing will be as we expect from 3261. >> >> >> >>> if we don't find a from tag in a request, can we just compare the >> >>> whole from field instead? >> >> >> >> That seems to be the correct thing to do. >> >> >> > >> > Right, I understand.. I will implement it as: >> > >> > if [ first_cseq == second_cesq ] >> > then >> > if [ first_to_tag == second_to_tag >> > || first_to_tag.isNull # <-- Support for matching dialog >> > forming >> > || second_to_tag.isNull ] # <-- requests with the correct >> > dialog >> > then >> > >> > if [ first_from_tag.isNull >> > && second_from_tag.isNull ] >> > then >> > if [ RFC 2543 : COMPARE THE ENTIRE FROM FIELD ] >> > then >> > DIALOG_MATCH = TRUE; >> > fi >> > else if [ first_from_tag == second_from_tag ] >> > then >> > DIALOG_MATCH = TRUE; >> > fi >> > >> > fi >> > fi >> > >> > >> >> I think it ought to be fine to reject requests without a From: tag. > > Be Liberal In What You Accept. > > What would it break to allow requests without a From tag? > >
I believe it would cause problems for forked subscriptions but I will admit, I have a hard time coming up with an example. -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
