[reSIProcate] Problem with UAC sending ACK automatically
Adam Roach
adam at nostrum.com
Fri Jun 16 13:06:53 CDT 2006
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 at avaya.com
>
> -----Original Message-----
> From: Adam Roach [mailto:adam at estacado.net]
> Sent: Friday, June 16, 2006 12:03 PM
> To: Kovar, William (Bill)
> Cc: Scott Godin; Adam Roach; derek at counterpath.com;
> resiprocate-devel at list.sipfoundry.org
> 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 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
>>
>>
>>
>
>
More information about the resiprocate-devel
mailing list