RE: [reSIProcate] Problem with UAC sending ACK automatically

["Kovar, William (Bill)" <bkovar@xxxxxxxxx>]

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@xxxxxxxxx

-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Scott Godin
Sent: Wednesday, June 14, 2006 9:16 AM
To: Adam Roach; derek@xxxxxxxxxxxxxxx
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx]
> Sent: Wednesday, June 14, 2006 7:48 AM
> To: derek@xxxxxxxxxxxxxxx
> Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Problem with UAC sending ACK automatically
> 
> derek@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel