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