But since both OPTIONS looks the same, the proxy will forward both requests to the originator UA and the originator UA shall not be able to distinguish between them. In fact, the originator UA will manage two dialogs (established in the 18x without the To tags) but will not know about it and thus it can't hung up one of them.
Thanks, Dudy Isaac. -----Original Message----- From: Charles Eckel [mailto:[EMAIL PROTECTED] Sent: Friday, March 25, 2005 10:42 PM To: Isaac Dudy Cc: [email protected] Subject: Re: [Sip-implementors] Forking Proxy The OPTIONS are new transactions, independent of the original INVITE and of each other. If sent to the proxy, it should forward them based on the Request-URI or any existing route headers, just as it would any other request. Cheers, Charles Isaac Dudy wrote: > Hi all. > > Suppose a proxy decides to fork INVITE request & creates two different > branches. > Suppose that each branch finally ends up with different phone. > The only difference between the INVITEs is the branch since the > Call-Id & the From tag is the same for both INVITEs. > Each phone returns 18x & sends OPTIONS transaction. > The proxy can distinguish between the different 18x according to the > branch parameter. > But what about the OPTIONS transaction?? > > If each phone puts a To tag in the 18x respone, then the proxy can > match each OPTIONS to its dialog according to the From tag (since both > OPTIONS will have the same To tag). But, if the phones doesn't support > RFC 3261 and don't include To tag in the 18x how can the proxy > distinguish between the different OPTIONS and match each OPTIONS > request to its dialog?? Both OPTIONS will have the same To tag (the > original From tag), & same call id?? > > Many thanks for your answers, > Dudy Isaac. > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ______________________________________________________________________ This email message has been scanned by PineApp Mail-Secure and has been found clean. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
