RE: [reSIProcate] Problem with UAC sending ACK automatically
- From: "Kovar, William (Bill)" <bkovar@xxxxxxxxx>
- Date: Fri, 16 Jun 2006 12:31:08 -0400
I see where the confusion is... Most B2B scenarios show the 'middle' of
the B2B starting the INVITE sequence, i.e. a MakeCall scenario. Not in
this particular case.
Here's my Call flow
3PCC UA Master UA Slave UA Customer
| | | | INVITE(off) |
|New Call
|<-------------------------------------------|
|<-------------| | | |
|RouteCall | | | |
|---------------------------->| | |
| | | |
|
| | |INVITE off (1) |
| | |------------->| |
| | |180 (1a) | |
| | |---------------------------->|
| | |180 (2) | |
| | |<-------------| |
| | |200 ans off(3)| |
| | |<-------------| |
| | |200 ans off(4)| |
| | |---------------------------->|
| | |ACK (5) | |
| | |<----------------------------|
| | |ACK (6) | |
| | |------------->| |
| | | | RTP |
| | | |<------------>|
The Customer calls into one UA, which doesn't know where to route the
call until the 3PCC tells it. 3PCC tell it to route to MUA which fronts
the SUA. The B2B exchange happens and the Cust and SUA start RTP. Also,
SDP negotiation is not expected due to devices all being normalized to
the same codec set (like the way an SBC does). I need to know
definitively that the RTP session between the Cust and the device the
SUA is talking to, was successful. It's possible that during negotiation
of the RTP (200, ACK) either the Cust or the SUA device went away. Hence
the need to sequence the 200 and ACK messages.
Another way to describe, using PBX semantics is:
Cust calls and lands on a route device (UA). A 3PCC looks at details of
the incoming call and decides where to route (wait treatment - MUA). The
wait treatment device (the one that actually delivers media) is behind
the SUA in this call flow. After codec negotiation, the Cust and the SUA
device exchange RTP while the MUA/SUA stays in the call control path.
Either ends dropping can be detected.
NOTE: The SUA is a UAC that contacts am actual SIP device that can do
RTP. None of the 3 UA (UA, MUA, SUA) shown above can do media. They are
only in the control path.
Bill Kovar
Avaya Inc.
(732) 852-2609
bkovar@xxxxxxxxx
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxxx]
Sent: Friday, June 16, 2006 12:03 PM
To: Kovar, William (Bill)
Cc: Scott Godin; Adam Roach; derek@xxxxxxxxxxxxxxx;
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Problem with UAC sending ACK automatically
I'm having a really hard time understanding the scenario you're
describing. Based on your list, here's the call flow you seem to be
describing:
3PCC (RFC 3725?!?) Master UA Slave UA Customer
| | | |
| | | |
| | | |
|magic (1) | | |
|------------->| | |
| |INVITE offer (1) |
| |------------->| |
| |180 (1a) | |
| |---------------------------->|
| |180 (2) | |
| |<-------------| |
| |200 answer (3)| |
| |<-------------| |
| |200 answer (4)| |
| |---------------------------->|
| |ACK (5) | |
| |<----------------------------|
| |ACK (6) | |
| |------------->| |
| | | |
| | | |
This doesn't hold together for me. Can you describe your use case more
precisely, preferably by correcting my diagram?
/a
Kovar, William (Bill) wrote:
> 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
>
>