Send early RTP without 183 and ACK

[ambakoevich]

Hi,

I have pretty standard SIP call scenario between two IP Phones

Alice calls Bob

Alice -> Invite (SDP) -> Bob

Alice <- 100 (No SDP) <- Bob

Alice <- 180 (No SDP) <- Bob

Alice <- 200 (SDP) <- Bob

Alice -> ACK  (No SDP) -> Bob

Alice <-> RTP <-> Bob

Problem is that ACK from Alice to Bob takes long time to arrive.
And user experience is that when Bob picks up the phone (at this point Bob sends 200 to Alice), Alice is not able to hear first phrases of the conversation.
As far as I understand, Bob sends 200 but awaits ACK to start RTP transmission. ACK is not arriving for at least for 600-700ms and whatever Bob says in that time-frame is never transmitted to Alice.

Due to some reasons, I can not do anything about ACK arrive timing from Alice to Bob.

As a temporary solution, is there any way I can force IP Phone of Bob to start transmitting RTP right after sending 200 to Alice. Without awaiting ACK from Alice? (note that there is no 183)

Thank you in advance.

[Rajan]

Hi,

Can you tell us where these phones are registered to? whether a CUCM or CME ?
Do you see delay in phone responding to these messages or the PBX sending a delayed message ?

Also share the sip messages where you see the delay/

HTH
Rajan

[ambakoevich]

Hi, thanks for the reply.

Phones are registered at the custom "cloud PBX" solution at the SIP provider. (no CUCM, CME)

SIP Messages between IP Phones traverse several nodes that are part of the custom solution. And all this message passing/forwarding inside the "cloud" introduces delay. And as a result, from IP Phones point of view end-to-end connection between Alice and Bob is slow.

IP Phones itself do not introduce any delay, they respond to the messages instantly.

Is it possible to configure IP Phones to start sending RTP right after sending 200? (without awaiting the ACK)

[Georgios Fotiadis]

Having RTP flow before 200 OK is only possible with Early Media, but this does not apply to you as you can not have SDP in 180/183. Without early media, RTP flow starts after the ACK message, by protocol design, and you can not bypass that functionality.

[Ayodeji Okanlawon]

With early offer Media is actually sent after the final response (200 OK) is received and session is established..

 A 2xx response to an INVITE establishes a session, and it also
   creates a dialog between the UA that issued the INVITE and the UA
   that generated the 2xx response

The problem though is that you need your ACK to the 200 OK to complete the session. The ACK request method is used to acknowledge the reception of a final response to an INVITE request. So media flows at 200 OK but your session is not fully established until the ACK is received/sent, hence your session cant be established without the ACK. Also be aware that the ACK is sent directly to the contact header in your 200 OK and not the to the Via header in the INVITE. So use this to help troubleshoot why the ACK is not arriving on time..It should be network related

[ambakoevich]

Thanks all for you replies, and yes I understand your feedback.

I was just trying to come up with workaround custom temporary solution before the final patch is out. Patch that would fix the delay of the ACK.

But as you are telling me there is absolutely no way I can force IP phone to start transmitting RTP right after ACK.

[ambakoevich]

Is it possible to configure early media only on Cisco IP Phones.

I mean I would like CALLED Cisco IP Phone to generate 180 with SDP and start sending media as soon as it sends 200 OK towards the CALLER.

Is this possible without CUBE?

[Anthony Holloway]

How does that work in your head? Wouldn't that mean that Bob's phone would have to start sending media while its still ringing, and before Bob answered it?

[Saurabh]

Hi

SIP phones generally start sending RTP media without waiting for ACK . As soon as called phones sends out 200 OK, it's ports are opened and it can stream media.

You need to check with your phone vendor, if they have any provision for this. 

This might require phone firmware upgrade.

[Aeby Vinod]

Wouldn't that be a violation of the RFC, Also when you say the RTP can be streamed once the ports are opened do you mean you see that in the media layer processes denoting streaming or have you actually seen Phones sending RTP even when the ack packet is dropped?

Regards,
Aeby

[Saurabh]

Flowing of RTP stream has nothing to do with ACK.
As soon as sender initiates Invite with SDP, it opens it's port and can receive media, but that is not practical possible until receiver receives signaling and opens it's port. That is done when 200OK / 183 is sent by receiver.
The same is the case with receiver port also. ACK is just an acknowledgement for the the SIP signaling.

This is not SIP RFC violation, but you can find some RFC modifications on this.
This behavior is dependent how product is designed, i have also seen some phones sending RTP after ACK but those get into issue with interoperability sometimes, but majorly seen phones which send RTP before receiving ACK.