12 Feb
2007
12 Feb
'07
11:37 a.m.
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
12 Feb
12 Feb
12:01 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
13 Feb
13 Feb
12:10 a.m.
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
12:52 a.m.
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:47 a.m.
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
10:17 a.m.
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
4:28 p.m.
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(a)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
7 May
7 May
4:52 p.m.
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
6222
days inactive
6306
days old
7 comments
4 participants
participants (4)
-
Bogdan-Andrei Iancu -
Jeff Williams -
Ovidiu Sas -
Sajith T S