Blind transfer doesn't work on SIP trunk to ISP with early offer

[Waldo Roca Martin]

Hi

We have a problem that when an user want to perform a blind transfer (thats means press transfer 2 times in a row) after press transfer the second time the call cut  and transfer can't be completed.

CUCM is 10.5.2

User's phone is 7962 using SCCP.

We use early offer on the SIP profile.

CUCM IP 10.1.40.250

IPS SBC 10.23.0.7

The call flow is the next.

Initial caller (911839XXX call from ouside to DDI 910714XXX. The call comes from ISP SIP trunk and there is a translation rule to forward calls from 910714XXX to 10101 (external number mask 916362XXX). Cisco Phone 10101 rings and call is completed correctly. After that user press transfer to transfer the call to mobile 655865XXX using the same SIP Trunk. Mobile rings and when mobile user takes the call, the call is droped.

We have collected the SIP traces (Attached) to the process and we see ISP SBC send a 500 Internal error when CUCM send the invite to complete the transfer. (Line 33)

After 180 Ringing (when the request transfer is made to the mobile, line 16) there are 2 updates from CUCM to ISP SBC, and it answers with 491 Request Pending. (could be part of the problem Lines 18, 22, 27, 28)

ISP told us there are 4 200 Ok no answered with ACK from CUCM and that is the problem. But this belowns to the initial call flow form 911839XXX to 910714XXX (lines 23 24 25 26) .

Any ideas where is the error?

Thank you

Best regards

[Vivek Batra]

Hi,

Issue seems because of line 31. I've some doubts on exact call flow however I will share what I've observed here.

In line 29, second call has been answered as we can see 200 OK. Now seems that CUCM doesn't want to take care of media (but obvious) hence in line 31, it's sending Re-INVITE on second call with connection information in SDP set to 10.23.08 and audio port as 37076. In actual, audio port 37076 belongs to remote user of call 1 (first incoming call). So what I can conclude here is CUCM updating second call leg to connect audio/media directly to first call leg (implicitly means media connecting directly between two remote users) and seems that is what your service provider doesn't like. Service provider may not want to loopback the RTP within thier own network (would never like to see its own IP address in SDP) and hence sending 500 Internal Error.

By the way, 491 Request Pending is recieved on second call and that might be because second call is not matured yet and service provider doesn't like to accept second transaction till first is not completed. I don't think that is the cause of our issue.

Regarding four 200 OKs, you're right. This is on for first call and should not impact the second call from service provider perspective.

- Vivek

[Vivek Batra]

Hi Waldo,

Did you get a chance to re-check the same?

- Vivek

[Waldo Roca Martin]

Hi Vivek

Many thanks for the asnwer, you can be right. ISP says is CUCM fault.

So the 31 re-INVITE is to ask SBC join the 2 call legs and for any reason ISP sbc asnwer a 500 internal error, right?

Best regards  

[Vivek Batra]

Hi,

Yes, that is what I meant. I'm bit sure that ITSP would not like to take the responsiblity of attaching media between two remote users and hence would never like to see its own IP address under connection information in SDP.

At the same time, I also don't think its CUCM fault. As CUCM is not processing media and it's quite obvious that CUCM is trying to establish media directly between two remote users.

Since it's not normal and recommended to connect CUCM directly to ISP, CUBE does this job bit well.

Not sure but give a try, using MTP on SIP trunk might solve this issue.

- Vivek

[Waldo Roca Martin]

HI

ISP insist the problem is because 200 OK no aswered by ACK. They said the ACK is aswered after the error 500.

I tried. In fact, early offer ( Use MTP if requiered) is activated. I tried to force MTP but not working.

That could be a coded problem?

Best Regards

[Vivek Batra · Accepted solution]

Instead of enabling early offer under SIP profile, only enable MTP on SIP trunk. Once done, can you share the PCAP traces of transferred call?

- Vivek

[Waldo Roca Martin]

Hi

I tried using MTP only and it worked OK.

But after some time, it started to work using early offer as it was before. ISP say they diden't change anything. 

Anyway thanks a lot for the help.

Best Regards

[lorenz84gDD]

Find below my considerations about the trace:

In his first invite isp offers g711a/g711u/g729annex-b, you send a 200ok with g729 only. This is not a correct behavior from the RFC, CUCM should either offer a g729 annex b (not supported from the CUCM w/out a CUBE) or close the call. Somehow at this point the call is correctly setup because we got an ACK.

In the other messages CUCM keeps offering no annex-b while on their side they want annex-b.

In the final BYE you send them the Q.850 reason 47 that usually means codec mismatch and this is bad. Furthermore inside their 500 message you got Warning: 399 03124.04605.B.005.401.228.3.7.05254.00005254 "Bc sdp proc failed".

So basically I believe it's a codec mismatch and you need a cube in order to have cucm interwork with their sbc. Try a call transfer with g711 I guess it's gonna work.

hth

lorenz

pls. rate helpful posts

--edit: I updated the post because I was missing part of the trace.

[Vivek Batra]

Hi there,

In his first invite isp offers g711a/g711u/g729annex-b, you send a 200ok with g729 only. This is not a correct behavior from the RFC, CUCM should either offer a g729 annex b (not supported from the CUCM w/out a CUBE) or close the call. Somehow at this point the call is correctly setup because we got an ACK.

This SDP offer/answer with respect to G729 annexb negotiation complies with RFC. If annex b is ommited from either offer/answer, it should be considered as annexb=yes. Please check the example 4.2 in RFC 7261 which is exactly the same as this flow is. 

In the other messages CUCM keeps offering no annex-b while on their side they want annex-b.

There is no issue with this behavior also. If one ends tell to use annexb=yes and other say annexb=no, annexb won't be used. Both ends must agree to use annexb.

Try a call transfer with g711 I guess it's gonna work.

 Yeah, no harm to check with g711 :)

At the end, if you closely see the traces, both the call (first incoming and second outgoing) are succesfully matured and due to transfer trigger, CUCM is sending Re-INVITE on second call (line 36) with RTP port as 37076 which is actually RTP port of first IC call. CUCM eventually wants both of the remote users media to connect.

Also CUCM has sent INVITE without SDP offer on fist call for which it recieved 200 OK as well with SDP offer from service provider. What eventually CUCM will do is to send ACK with SDP answer and RTP port set to 37078 (which is of second call) but unfortunately that didnt' happen as before ACK being sent by CUCM, it recieved 500 Server Internal Error on second call. Hence on first call, ACK sent by CUCM is having IP address set to 0.0.0.0.

I'm bit sure that service provider doesn't want to see its own IP address in SDP body and that is the cause of getting 500 Server Internal Error.

Now lets analyze why CUCM is giving late ACK reply and provider needs to retransmit 200 OK on first call four times. Here is the ideal call flow for transfer on SIP trunk once both of the call has been matured.

1. CUCM sends Re-INVITE without SDP (call 1).

2. CUCM gets SDP offer in 200 OK (call 1).

3. CUCM copies the SDP from step 2 and send it in Re-INVITE as SDP offer (call 2).

4. CUCM gets SDP answer in 200 OK (call 2).

5. CUCM copies the SDP from step 4 and send it as SDP answer in ACK (call 1).

Issue is with step 3. Since after step 3, CUCM is getting 500 Server Internal Error and hence, step 4 failed and incorrect credentials are sent in step 5 under SDP/ACK.

- Vivek

Please rate useful posts.