Re: [reSIProcate] Problem designing a B2BUA with DUM
On 11/20/05, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> 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.
>
Yes. This is correct. If the provisional response (1xx) is unreliable
it can only inform the other side of early media. Furthermore, the
subsequent offer or answer in the 2XX MUST be the same as the SDP in
the 1xx.
So to be clear, the case you are describing is not allowed unless both
the B2BUA and the called party support PRACK (100rel).
> 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' ...
> >