Paul, Unless I'm much mistaken proxies can only forward one non-2xx final response upstream. Multiple early-dialogs don't change that.
Thanks, Anders On 2/22/2010 1:40 PM, Paul Kyzivat wrote: > At end... > > Aaron Clauson wrote: >>> -----Original Message----- >>> From: Dale Worley [mailto:dwor...@avaya.com] >>> Sent: Monday, 22 February 2010 4:42 PM >>> On Thu, 2010-02-18 at 02:50 +0000, Aaron Clauson wrote: >>> >>> You should be able to do this in a standard way. >>> >>> First, let us assume that an address of the client (which is acting as >>> UAS in this situation) is<sip:UAS>. >>> >>> The incoming request is "METHOD sip:UAS". Once the client obtains the >>> first redirect URI,<sip:DEST1>, it responds "SIP/2.0 302 Moved >>> Temp/Contact: sip:DEST1/Contact:<sip:UAS;phase=2>". >>> >>> This causes the requestor to fork to<sip:DEST1>, but the requestor >>> also >>> forks to<sip:UAS;phase=2>. The latter request goes back to the >>> client, >>> bit it is tagged so the client knows to proceed with the second phase >>> of >>> processing for the request. >>> >> >> The problem I have is that the client does not actually know all the >> redirects at the point the first one is sent. The client has a human user >> pressing buttons to initiate the redirects and there could be gaps of >> 1,2,5,10 etc. seconds between subsequent forwards. >> >> In the meantime I went ahead and used a custom info response of "184 >> Multiple Redirect" which does the job perfectly. > > Well, that is entirely proprietary. And if you are putting the "redirect > URIs" into the 184 as Contact headers, then you are also messing up > dialog state. > > I didn't fully understand what Dale was suggesting, but I can suggest > someting along the same lines: > > The trick is that you want to send a 3xx, but you want the option to > send another 3xx later. You can't do that in the same early dialog, but > you can do it in multiple early dialogs. But to do that you must > convince the caller that there is another dialog to wait on. > > So, > > When your server decides it wants to do this, it should send a 183 > response a to-tag defining an early dialog. This should be a reliable > 1xx if you are permitted to do that. > > Then when it has an address it wants to send back, it can send a 3xx, > but with a *different* to-tag. (This indicates you forked the call and > the 3xx is from a different leg.) > > If you later have another address to return, repeat the above with a > different to-tag. > > When you are done playing these games, you can send the final address in > a 3xx with the same to-tag as the 183. Or if you have no more addresses, > just return 480 with that to-tag. > > That's all fully standards compliant, and should elicit the right > behavior from any caller that is capable of doing something reasonable > with multiple 3xx responses. > > Thanks, > Paul > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
