[reSIProcate] Problem with UAC sending ACK automatically

[Kovar, William (Bill)]

Thanks for all the comments, but my use case is a bit more specific:

I'm doing a B2B where the master side of the B2B is told to connect to
the slave side of the B2B. In this scenario, the master is a s/w only
B2b and the slave is an actual SIP device that has media capabilities.

So...

1. 3PCC tells MUA (master) to invite the SUA (slave). The SDP in the
INVITE is from a existing Customer call.
1a. The MUA sends the Cust UA 180.
2. The INVITE gets responded with 180 (no sdp) in onNewSession(..)
3. The SUA is set to auto-answer and immediately sends 200 OK w/sdp
4. The SUA needs to send the SDP to the Cust UA via the MUA's
ServerInviteSession
5. The Cust UA will (eventually) ACK to MUA
6. The MUA sends ACK to the SUA through the SUA's ClientInviteSession

In what I saw, the ACK to the SUA is done without my control.



Bill Kovar
Avaya Inc.
(732) 852-2609
bkovar at avaya.com

-----Original Message-----
From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Scott Godin
Sent: Wednesday, June 14, 2006 9:16 AM
To: Adam Roach; derek at counterpath.com
Cc: resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Problem with UAC sending ACK automatically

Ah - I didn't realize there was a MUST statement in the RFC's.  My use
case is getting less creditable.  : )

> -----Original Message-----
> From: Adam Roach [mailto:adam at nostrum.com]
> Sent: Wednesday, June 14, 2006 7:48 AM
> To: derek at counterpath.com
> Cc: Scott Godin; resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] Problem with UAC sending ACK automatically
> 
> derek at counterpath.com wrote:
> 
> >However, Bill's use case was where there was an offer in the INV and
an
> >answer in the 200. Media will flow from the UAS side once the 200 is
> sent,
> >
> >
> 
> Or possibly even earlier:
> 
> "Once the offerer has sent the offer, it MUST be prepared to receive 
> media..." (RFC 3264, section 5.1) (It goes on for a bit more than
that,
> but it really boils down to that statement).
> 
> >and will be send by the UAC(Bill's UA) once the 200 is recieved; what
is
> >the motivation for delaying the ACK?
> >
> >
> 
> For sessions with SDP in the INVITE, ACKs are a transport issue, not
an
> application issue. It makes no more sense to withhold an ACK under
these
> circumstances than it does for an application to withhold a TCP ack.
> 
> /a
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel