[reSIProcate] Multiple non-invite client transactions

[Robert Sparks]

Late response, but this has confused me and I want to make sure the 
record (and my
understanding) is correct.

I _think_ what Jason's saying is that ->DUM<- will allow only one 
outstanding non-INVITE
client transaction on a given dialog. DUM will, I believe, allow 
parallel non-INVITE client
transactions on different dialogs. If you're using the stack directly, 
it won't put this kind of
limitation on you.

I'm only begrudgingly comfortable with this limitation in DUM (if I 
understand it correctly).
The use cases that people had in mind when they made that decision were 
primarily
wrapped around INVITE related dialogs. I'm not as comfortable with 
putting this limit
on NOTIFYs, but for expediency am going with the flow.

RjS

On Sep 6, 2005, at 7:01 PM, Jason Fischl wrote:

> On 9/6/05, Keohane, Stephen <Stephen.Keohane at scansoft.com> wrote:
>>
>>
>>
>> Opps – my mistake – apparently the response to the subsequent 
>> requests has
>> not been received – (what threw me off was my server does what was 
>> requested
>> of it).
>>
>>
>>
>> As to the decision to only support one outstanding NICT seems to 
>> stray from
>> the RFC – is this correct?
>>
>
> Yeah. That was intentional. We didn't want to promote this since we
> don't think it is a good idea - but we did want to allow it on the
> UAS.
>
> Jason
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel