pbx_dancer

Hi all,

I apologize in advance for this post being so wordy. I want to make sure I provide as much information as possible, to help make it clear.

I believe I've encountered a problem with OmniPCX OXE 7.1 when it performs as a forking proxy for SIP external stations. First, I need explain the network topology for the call type. Basically, we have an the OXE connected to two SIP gateways. Service DNs from one SIP gateway are routed to the OXE, which in turn, routes the calls to a service node SIP gateway. The service node SIP gateway translates the service number into a call to a desk user on the OXE (specifically, a SIP external station desk user registered to the OXE). The service node gateway has also registered as that same desk user to the OXE. When the service node sends an INVITE to the OXE for the desk user, the OXE forks two INVITEs, one to the desk phone SIP client, and one back to the service node gateway (since both endpoints are registered).

The service node SIP gateway translates the incoming call to the desk number into another destination number (e.g., some pstn number). The service node gateway sends the call to the PSTN number back to the OXE, which in turns routes it to other SIP gateway. Below is a drawing of the call configuration. To make the drawing more readable, I've shown the one SIP gateway as two separate boxes (originating side, and terminating side):

Each line coming in and out of the OXE represents a SIP call (i.e., an INVITE). The numbers involved in the call are:

750-450-9902 (this is a pstn number, in this case the originating party)
650-550-9900 (this is a service number, one that the OXE will route to the SIP g/w service node)
250-9999 (this is a SIP external station user defined on the OXE)
450-450-9900 (this is a pstn number, in this case an additional termination number)

I'm using the following short hand in the figure, to present the TO (t: ) and FROM (f: ) parties:
6..0 means 650-550-9900
7..2 means 750-450-9902
2..9 means 250-9999
4..9 means 450-450-9999

So, the call flow is this:
1. 750-450-9902 dials service dn 650-550-9900. see (1) in figure
2. The OXE routes this call to service node SIP gateway. see (2) in figure
3. The service node SIP gateway initiates a call to 250-9999 to the OXE. see (3) in figure
4. The OXE forks this call to both endpoints registered as 250-9999 see (3.1) and (3.2) (in this case an xlite client for the actual desk, and the service node SIP gateway as additional fork). The two INVITEs that the OXE sends are identical to the initial INVITE (3), except for the branch parameter is different, which makes each forked leg unique (for SIP dialog matching purposes).
5. The xlite client sends back 180 ringing (3.1)
6. The service node SIP gateway initiates a call to 450-450-9999 to the OXE. see (4) in figure
7. The OXE routes the call to the terminating SIP gateway. see (5) in figure. The endpoint on that gateway sends back 180 ringing.

So, at this point the xlite client is ringing, and the additional 450-450-9999 endpoint is also ringing. Everything is as expected. Nothing wrong at all.

8. The device at 450-450-9999 answers the call. SIP gateway forwards 200 OK for leg (5) to the OXE.
9. The OXE returns an ACK to the SIP gateway (so call leg (5) above is established), and forwards the 200 OK to the service node SIP gateway for leg (4).
10. Service node SIP gateway forwards the 200 OK from leg (4) back to the OXE for leg (3.2)
11. At this point I was expecting the OXE to return an ACK to the service node SIP gateway. but it does not. The 200 OK is forwarded back to service node SIP gateway for leg (3)
12. As expected, the OXE also sends a CANCEL message to the xlite client (since the xlite client didn't answer the call) leg (3.1). The xlite client returns the proper 487 and 200 responses and that call leg appears to be cleaned up properly. So call leg (3.1) above has been removed.
13. The service node SIP gateway forwards the 200 OK from leg (3) back the OXE for leg (2).
14. The OXE returns an ACK to the service node SIP gateway. So call leg (2) above is established.
15. The OXE forwards 200 OK from leg (2) to the originating SIP gateway for leg (1).
16. The originating SIP gateway returns an ACK to the OXE. So call leg (1) above is established.
17. The service node SIP gateway forwards the ACK received for leg (2) back to the OXE for leg (3). So call leg (3) above is established.
18. Since the OXE didn't send the ACK for (3.1) back in step 11, I would have thought it would have forwarded the ACK just received for leg (3) to the (3.1) leg, but it does not.

So right now, call legs (1), (2), (3), and (5) have all completed call establishment (INVITE,18x,200,ACK). However, since the OXE did not send an ACK at step 11 nor at step 18, call legs (3.1) and (4) have not been fully established. At this point the OXE keeps retransmitting the 200OK on leg (4), which is forward back for (3.1), and then I see the OXE forward the 200OK back up leg (3). This seems wrong, as ACK has already been received on (3). The OXE continues to retransmit the 200OK for leg (4) until some internal timer pops around 3 seconds later, at which point the OXE sends a BYE for leg (4), which traverses all the way back to leg (1). The result is the call is torn down.

The user experience for this call is the call is answered and two way voice path is established for ~3-4 seconds, and then the call comes down. The reason voice path is established is because the ACKs are received for leg (1) and leg (5) and voice path is endpoint to endpoint. It's not until the signaling path fails, that voice is taken down.

I've attached the full traced logs from the OXE to this post, if you want to see all the messaging details. I don't see any errors or warnings in the OXE logs, so I can't see why the ACK for leg (3.1) and (4) don't occur.

One thing to note, this scenario works if I use SIP trunks instead of SIP lines. Specifically, I can use a 4068 desk phone (i.e., not a SIP phone) and use a remote extension to provide "simring" to the service node SIP gateway. In this case, there is no SIP forking being performed by the OXE, and the call works. Using the above figure as a reference, just remove (3.1) since that doesn't happen, and change the to/from headers for leg (3.2), i.e., leg (3.2) won't be a proxy-ed repeat of (3) differing only by a branch value, it has totally different to/from/tags/branches.

I can't think of anything to change, configuration wise, that would change how the OXE behaves during proxying, but maybe someone here knows of something? Is this a bug on the OXE? Has any of you experienced a problem similar to this when tandeming a SIP call through the OXE using SIP lines?


Any ideas?
//Robert