< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Problem with UAC sending ACK automatically


Adam,

I don't think there is anything wrong with your assessment here, I would
just like to control when the ACK is sent. In the 3PCC world, it's nice
to be able to generate an event that says the call has been answered.
And the most reliable msg that says that is ACK. Because even after a
200 OK is received, the call can still be rejected by the far end...
i.e. Cust hangs up before ACK is sent.

Hence the need to either: 1) fire a DUM callback when ACK is being sent
or 2) allow the app to decide when to send the ACK.


Bill Kovar
Avaya Inc.
(732) 852-2609
bkovar@xxxxxxxxx

-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx] 
Sent: Friday, June 16, 2006 2:07 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 still a little confused, since your diagram appears to have suffered
significant damage. I think it's supposed to look something like this:

3PCC             UA           Master UA       Slave UA        Customer
  |               |               |               |               |
  |               |               |               |               |
  |               |               |               |               |
  |               |INVITE offer   |               |               |
  |               |<----------------------------------------------|
  |new call       |               |               |               |
  |<--------------|               |               |               |
  |route call     |               |               |               |
  |------------------------------>|               |               |
  |               |               |INVITE offer   |               |
  |               |               |-------------->|               |
  |               |               |180            |               |
  |               |               |------------------------------>|
  |               |               |180            |               |
  |               |               |<--------------|               |
  |               |               |200 answer     |               |
  |               |               |<--------------|               |
  |               |               |200 answer     |               |
  |               |               |------------------------------>|
  |               |               |ACK                            |
  |               |               |<------------------------------|
  |               |               |ACK            |               |
  |               |               |-------------->|               |
  |               |               |               |RTP            |
  |               |               |               |...............|
  |               |               |               |               |
  |               |               |               |               |

Assuming this is what you were intending to draw, there are still some
aspects of this that give me heartburn; I'll ignore them for now. Given
that the above diagram is your intention, it's not clear to me why the
following flow doesn't work for you:

3PCC             UA           Master UA       Slave UA        Customer
  |               |               |               |               |
  |               |               |               |               |
  |               |               |               |               |
  |               |INVITE offer   |               |               |
  |               |<----------------------------------------------|
  |               |               |               |               |
**********************************************************************
***** CUSTOMER _MUST_ BE PREPARED TO RECEIVE MEDIA AT THIS POINT *****
**********************************************************************
  |               |               |               |               |
  |new call       |               |               |               |
  |<--------------|               |               |               |
  |route call     |               |               |               |
  |------------------------------>|               |               |
  |               |               |INVITE offer   |               |
  |               |               |-------------->|               |
  |               |               |180            |               |
  |               |               |------------------------------>|
  |               |               |180            |               |
  |               |               |<--------------|               |
  |               |               |200 answer     |               |
  |               |               |<--------------|               |
  |               |               |               |               |
**********************************************************************
***** SLAVE UA _MUST_ BE PREPARED TO RECEIVE MEDIA AT THIS POINT *****
**********************************************************************
  |               |               |               |               |
  |               |               |ACK WITH NO USEFUL INFORMATION |
  |               |               |-------------->|               |
  |               |               |200 answer     |               |
  |               |               |------------------------------>|
  |               |               |ACK WITH NO USEFUL INFORMATION |
  |               |               |<------------------------------|
  |               |               |               |RTP            |
  |               |               |               |...............|
  |               |               |               |               |
  |               |               |               |               |

/a

Kovar, William (Bill) wrote:
> 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
>>
>>   
>>     
>
>