Guys,
I'm wondering what solutions there are to this problem. We have some NATed clients making outgoing calls. The NAT traversal is done using mediaproxy and works fine. However, we have a problem with 183 responses and early media ringing sounds.
The problem is that before the NATed client starts sending out RTP data, mediaproxy doesn't know which IP and port to send the RTP traffic to. Some of the NETed clients don't start sending out RTP traffic until the call is connected, therefore none of the early media (ringing sounds) reaches the user - making it sound like dead air.
Any ideas?
Jeff
Hi Jeff,
I'm afraid it is not possible - the NAT traversal is based on symmetric IP traffic to be able to push inbound traffic. But if the client does not send anything, the nat bind will not be created and no inbound traffic will be accepted.
regards, Bogdan
Jeff Williams wrote:
Guys,
I'm wondering what solutions there are to this problem. We have some NATed clients making outgoing calls. The NAT traversal is done using mediaproxy and works fine. However, we have a problem with 183 responses and early media ringing sounds.
The problem is that before the NATed client starts sending out RTP data, mediaproxy doesn't know which IP and port to send the RTP traffic to. Some of the NETed clients don't start sending out RTP traffic until the call is connected, therefore none of the early media (ringing sounds) reaches the user - making it sound like dead air.
Any ideas?
Jeff
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi Jeff,
I'm afraid it is not possible - the NAT traversal is based on symmetric IP traffic to be able to push inbound traffic. But if the client does not send anything, the nat bind will not be created and no inbound traffic will be accepted.
Bogdan,
Is there some way to send a 180 response as well as a 183 response for NATed clients?
Jeff
Hi Jeff,
Why don't you try to fix the client? If you mess with 180/183 you will have issues with real early media scenarios. For instance, if a subscriber is making a call into an IVR that is using early media (let's say a 1-800 number for a bank), the subscriber will not be able hear the IVR and therefore the call will always fail.
Regards, Ovidiu Sas
On 2/12/07, Jeff Williams jeffw@globaldial.com wrote:
Bogdan-Andrei Iancu wrote:
Hi Jeff,
I'm afraid it is not possible - the NAT traversal is based on symmetric IP traffic to be able to push inbound traffic. But if the client does not send anything, the nat bind will not be created and no inbound traffic will be accepted.
Bogdan,
Is there some way to send a 180 response as well as a 183 response for NATed clients?
Jeff
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Ovidiu Sas wrote:
Hi Jeff,
Why don't you try to fix the client?
Ideally that would be great, but I don't control all of the clients who access our service. I was hoping that there would be a way to transparently support these clients, but there doesn't appear to be. I'm not going to sacrifice real early media for the sake of these clients.
If you mess with 180/183 you will have issues with real early media scenarios. For instance, if a subscriber is making a call into an IVR that is using early media (let's say a 1-800 number for a bank), the subscriber will not be able hear the IVR and therefore the call will always fail.
I had wondering whether a 180 with stuff up legitimate 183 early media. I guess the answer is a resounding yes.
Thanks, Jeff
Hi Jeff,
You can do an ugly hack. For those broken clients (and only for those), as soon as you receive the INVITE send back a 180 Ringing and later on drop the upstream 183. This will generate local ring to the subscriber until the 200ok is received.
Note: If the called party is busy, the caller will hear ring-back followed by busy.
Hope this helps, Ovidiu Sas
On 2/12/07, Jeff Williams jeffw@globaldial.com wrote:
Ovidiu Sas wrote:
Hi Jeff,
Why don't you try to fix the client?
Ideally that would be great, but I don't control all of the clients who access our service. I was hoping that there would be a way to transparently support these clients, but there doesn't appear to be. I'm not going to sacrifice real early media for the sake of these clients.
If you mess with 180/183 you will have issues with real early media scenarios. For instance, if a subscriber is making a call into an IVR that is using early media (let's say a 1-800 number for a bank), the subscriber will not be able hear the IVR and therefore the call will always fail.
I had wondering whether a 180 with stuff up legitimate 183 early media. I guess the answer is a resounding yes.
Thanks, Jeff
Hi Jeff,
you can drop some provisional replies, but there is no way to create or change one.
regards, bogdan
Jeff Williams wrote:
Bogdan-Andrei Iancu wrote:
Hi Jeff,
I'm afraid it is not possible - the NAT traversal is based on symmetric IP traffic to be able to push inbound traffic. But if the client does not send anything, the nat bind will not be created and no inbound traffic will be accepted.
Bogdan,
Is there some way to send a 180 response as well as a 183 response for NATed clients?
Jeff
Hi,
This problem Jeff has presented here exists for rtpproxy too, true?
I too am wondering about a solution for this problem with early media, and I suppose there are other OpenSER users like me. How do you folks deal with this?
Thanks, Sajith.
Jeff Williams wrote:
Guys,
I'm wondering what solutions there are to this problem. We have some NATed clients making outgoing calls. The NAT traversal is done using mediaproxy and works fine. However, we have a problem with 183 responses and early media ringing sounds.
The problem is that before the NATed client starts sending out RTP data, mediaproxy doesn't know which IP and port to send the RTP traffic to. Some of the NETed clients don't start sending out RTP traffic until the call is connected, therefore none of the early media (ringing sounds) reaches the user - making it sound like dead air.
Any ideas?
Jeff
-
Bogdan-Andrei Iancu -
Jeff Williams -
Ovidiu Sas -
Sajith T S