Can CUBE be configured to send RTP when receiving 180 or 183 with SDP (early media)?

[TONY SMITH]

Hi,

The scenario here is that the CUBE makes an outbound call, receives either 180 or 183 with SDP indicating that the ITSP should be sending RTP carrying the appropriate tones or message.   At this stage some ITSPs expect that the called party (CUBE) will respond by sending RTP in order to start a two-way stream.   However it doesn't appear that the CUBE supports such behaviour, or if it does then I haven't found how to enable it.

This feature would be useful in other contexts as well, for example it would remove the requirement to have firewall rules configured for incoming unsolicited RTP.

Let me know if I've been unclear in the explanation.   I am talking about early media during provisional responses, not about early offer.

Any suggestions appreciated,

Tony S

[Shri2]

Tony,

Below link should help you.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/trunks.html

Check : 

Figure 6-4 SIP Early Offer with Early Media (PRACK)

Figure 6-5 SIP Delayed Offer with Early Media (PRACK)

[TONY SMITH]

Thanks, however that document refers to SIP trunks configured one CUCM not on CUBE.   In our configuration the CUBE does in fact send PRACK after receiving 183/SDP but does not send RTP.

[Ishan Zutshi]

Tony,

as Jonathan Schulenberg had stated, INVITE from the cube includes an SDP offer for which it receives SDP answer in 18x message. At this point the media channel is open between cube and ITSP.

Now the obvious question is: what is behind the cube? is it a phone registered to a CUCM?

if yes, then during the same transaction cube will be forwarding the 18X with SDP to cucm which will eventually ask the phone to open its media channel and connect to cube.

Hence with INVITE/SDP<-->18x with SDP the media channels have opened on both legs of the cube:

phone<-->RTP<-->cube<-->rtp<-->ITSP

even if ITSP doesnt send RTP first, the RTP from phone should start anyway.

So there is no need for cube to "generate" any RTP. Also PRACK is not required in this scenario as you have already done EO.

Make sure the other side of the cube router (CUCM?) is also doing EO.

thanks,

Ishan

[Shri2]

Tony,

Can u send the logs(debug ccsip messages) from CUBE, we can check whats happening at the other end ( assuming cucm & CUBE )

[TONY SMITH]

Maybe the following diagram helps, this is taken from the outside interface of the CUBE.  ITSP on the right, CUBE on the left, and outbound call from the CUBE.   ITSP expects to receive RTP after the PRACK, whereas CUBE doesn't start to send until the call connects.

[Mohammed al Baqari]

CUBE is initiating the call as per the ladder diagram. In this case CUBE can't send RTP before 200OK. It can receive RTP before 200OK if early media is enabled or 183 is received (which is your case).

[TONY SMITH]

Thanks.  That is exactly the issue, I have now found two different ITSPs who do not send early media unless or until they receive RTP from the customer first.  Hence my question as to whether the CUBE can be configured to do so.

Out of interest I did some tests with a Gigaset SIP phone, and that is exactly what it does.  As soon as it receive an incoming 180 or 183 with SDP it starts to send RTP even though there is no meaningful audio to send at that stage.  This achieves two things, firstly enables the inbound RTP through pretty much any sort of firewall without needing special SIP inspection or open holes in the firewall.  Secondly receiving that RTP allows the ITSP to see exactly where to send, without getting confused by NAT.

For some reason I can't embed the graphic this time, so here it is as an attachment.

[Mohammed al Baqari]

I don't think CUBE can do this.

[Jonathan Schulenberg · Accepted solution]

What's on the "inside" of CUBE? I'm going to assume a CUCM cluster for this answer.
??? --> CUBE --> SIP Carrier

Also, this problem statement doesn't quite make sense because the INVITE includes an SDP offer. The early media exchange is completed by the 183 Session Progress, after which bidirectional RTP should be flowing. A PRACK isn't even necessary in this scenario. If the carrier won't transmit an RTP packet until they receive one, then the question is whether the calling party (e.g. the CUCM-registered phone) begins sending RTP packets to CUBE after CUBE forwards the 183 Session Progress with SDP to CUCM? CUBE won't make up RTP packets on it's own.

[TONY SMITH]

Thanks.   Inside the CUBE is CUCM, and the test calls were from an SCCP phone, although of course outbound calls need to work from any source including calls handed off from ICTs or transferred from voicemail etc.

I'll have a look on the CUCM side to see what's happening there.

[TONY SMITH]

Well before I could do anything I think or ITSP must have tweaked something at their end, because I am now getting the same behaviour as our other customer sites.  One way RTP inbound only during these provisional states, two way only from connect onwards.  Example for call returning 183.

[Ishan Zutshi]

just make sure cucm does EO under sip profiles of the sip trunk. this will ensure cucm advertising ip and port numbers of the phone to cube and that RTP channels are open at both ends. CUCM or cube cannot do anything here with w.r.t generating the RTP. The phone will generate RTP towards cube and the latter will simply route it towards the ITSP.

you will have to look into cucm traces and make sure that cucm is instructing the phone to open its media channels