RE: [reSIProcate] Problem designing a B2BUA with DUM
I wasn't asking about the case in which a provisional response has an
answer. I was asking about the case in which a provisional response has
an offer. Sending 2 offers one after the other is supposed to be
forbidden.
If you read my original mail again It may clarify the problem.
-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Sunday, November 13, 2005 9:38 PM
To: Micky Kaufmann; 'Jason Fischl';
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Problem designing a B2BUA with DUM
When you are not using 100rel/PRACK, the SDP in the 18x is not the
official
answer - it can be used for early media, but the answer MUST be repeated
in
the 200 response. This is due to the unreliable nature of 1xx reponses.
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Micky
Kaufmann
Sent: Sunday, November 13, 2005 3:39 AM
To: Jason Fischl; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Problem designing a B2BUA with DUM
I don't think the problem exists only with a B2BUA - The only way to get
out of 'UAS_EarlyProvideOffer' state is with a 200 response that
includes an offer. However, if we send a provisional with an offer
before sending this 200 it's wrong - 2 offers one after the other...
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
Of Jason Fischl
Sent: Thursday, November 10, 2005 7:26 PM
To: Micky Kaufmann
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Problem designing a B2BUA with DUM
This seems to me like a state that you should maintain in your
application. It might also be possible to provide some b2bua support
directly in dum. If folks are interested in this I would suggest that
we have a more detailed requirements discussion on the mailing list
followed by a conference call to discuss it further.
On 11/10/05, Micky Kaufmann <micky@xxxxxxxxxxx> wrote:
> Hi all,
>
> I have the following scenario:
>
>
> 'A' B2BUA 'B'
>
> INVITE without an Offer
> ------------------------>
> INVITE without an Offer
> ------------------------>
> .
> .
> .
> 180 With Offer
> <------------------------
>
> The problem I have is in the UAS part of the B2BUA - the state of the
> UAS in the end of the scenario above is 'UAS_EarlyProvideOffer' now
when
> it sends a provisional the offer isn't sent with it.
> The B2B I want to design should let 'A' and 'B' make offer/answer
> negotiation without accepting an offer itself (only if 'A' or 'B'
> accepted an offer the negotiation should end)
> It seems like another state should be added between
> 'UAS_EarlyProvideOffer' and 'UAS_AcceptedWaitingAnswer' ...
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel