oh, duh! Of course you are right. What was I thinking?
Sorry,
Paul
Anders Kristensen wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
