RE: [reSIProcate] Problem designing a B2BUA with DUM
Someone can correct me if I'm wrong - but I don't think you can offer in an
unreliable 18x either. I would image the offer isn't official until it is
sent in the 200.
Scott
-----Original Message-----
From: Micky Kaufmann [mailto:micky@xxxxxxxxxxx]
Sent: Sunday, November 20, 2005 4:53 AM
To: Scott Godin; Jason Fischl; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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