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