SIP and RTP to separate IP Addresses, is this a Cisco bug?

Posts: 9 · New Forum Member Joined: Apr 15, 2005 Posts: 9

Hello,
I am an application developer with a soft-PBX type system running with Vonage service. Inbound works great, but when I call outbound the Vonage network (i.e. Cisco Gateways) sent RTP (i.e. voice) on the same address as they send SIP. Now when I get calls inbound everything is fine because the SDP I negotiate sets the RTP interface with
c= IN IP4 xxx.xxx.xxx.xxx
m= audio portnumer RTP/AVP 18 101

I set these same parameters in an outbound call's SDP but I do not get the backets to the address in c= (or even in o= which I forced to the RTP interface also).

Again, works fine for inbound calls, not for outbound. Anyone aware what could cause such issues. My guess is either Cisco configuration or a bug in their software.

Please help!

Posts: 30 · Posted: Mon Apr 25, 2005 10:19 am Post subject:

"but when I call outbound the Vonage network (i.e. Cisco Gateways) sent RTP (i.e. voice) on the same address as they send SIP."

Same address? you mean port?
Some providers break the rfc and assume that the user is behind a dumb router that doesn't NAT properly (random ports) so they send and receive on the same port used for SIP.

you use direct connection using sip_user@i-p.com ? without going through Vonage SIP gateways/proxies?

"I set these same parameters in an outbound call's SDP but I do not get the backets to the address in c= (or even in o= which I forced to the RTP interface also). "

Did you do SIP before getting to SDP?
Check your invite, are you being asked for authentication?
any Unauthorized packets coming in?
any packets at all?

Posts: 9 · New Forum Member Joined: Apr 15, 2005 Posts: 9

So it seems Vonage's gateway developer (who I can only guess is Cisco) does not support what I want to do. The fact that it works inbound seems to have puzzled them too. I just love when a vendor says 'we don't support it' not "wow, that's a very obscure bug, thank you for finding it". So I am convinced this is a bug in cisco's gateways.

I would also mention that some of this Simplex issue people have been having (only one side being heard) could be due to the same thing, because the reroute of RTP packets does not occur properly. Allow me to explain because this is part of what makes Voip so much better from the provider standpoint than TDM / Traditional systems. Voip allows my gateway (as in I am the provider) to still control signaling while routing the voice traffic directly between two end points. Now some ASCII art:

caller A Voip Prodivder Called B
---------------> (call aka INVITE)------------->
<------------- (answer OK) <-----------
now on to talking
----------------Direct UDP---------------------->
<--------------Direct UDP-----------------------

So the call control is maintained, but the voice is free to travel a shorter path should one be available. Sadly it does not seem that someone either wants us doing this (it could be construed as a carrier type operation) or as I believe it was simply a development bug.

Posts: 59 · Full Forum Member Joined: Dec 16, 2004 Posts: 59

I'm not sure I understand exactly what you are trying to do, but I doubt your supposition that it is a Cisco bug is correct. The signaling goes through Vonage's own (homegrown) proxy before it gets to a Cisco gateway, and for that matter Vonage uses Sonus gateways as well as Cisco.

But back to your problem. You say that you construct the SDP on the outbound INVITE, and you expect to receive the RTP packets at the address you specified in the SDP. So far so good. I'm a bit confused, though, about your statement that you think this is related to SIP and RTP coming from the same address on the far end (i.e., on the Vonage end). That would seem normal to me, if you are going through a Vonage session border controller.

Anyways, again back to your problem. First, setting aside the problem where you don't receive packets on the outbound call -- what about the SIP signaling ? Do you get a response to your INVITE and do you in fact get the call properly set up from a SIP standpoint (i.e., a 200 OK received from the far end)? I assume you are, because if not that would be the place to start. So if you are, and you are simply not getting RTP packets to the address you specify in the SDP, then my question would be whether you are going through a NAT device on your network. If so, and the Vonage session border controller therefore sees the RTP you send coming from a different address than that you specify in the SDP, it may be sending back to that address (i.e the source of the packets it receives) rather than the address you specify in the SDP. This would be typical for a session border controller providing an RTP relay function.

Anyways, your situation is interesting; I wish you would provide more of the pertinent details.

Posts: 9 · New Forum Member Joined: Apr 15, 2005 Posts: 9

I wish it were something simple I was doing wrong. No NAT int the mix, not even a firewall. I get the 200 OK to my invite and successfully send an ACK. I can see in ethereal that Vonage's RTP is coming, and it's headed to the correct port, of the INCORRECT IP ADDRESS. My SDP clearly says a separate IP and for inbound calls, this works. Now I suppose it may not be CISCO, but for every single SDP I have exchanged with Vonage and we're talking about VERY many for this testing, they have ALL said Cisco GWUserAgent, which kinda gives it away. I wish it was Sonus in a way because Sonus does SIP INFO DTMF, which Cisco can receive, but does not send. And no, its SENDING to the WRONG address alltogether. My RTP is done via a Brooktrout TR2020 board, with its own IP. ALL SIP is done via an ethernet interface on my windows server. So the thing about "Vonage session border controller therefore sees the RTP you send coming from a different address" is not it, because the RTP does come from the proper address, the brooktrout address. Instead the Vonage session border controller simply assumes that it should send to the SIP address.

I have solved this by altering my application and using a NAT, in theory it's solved. In practice however, this extra HOP does degrade quality, but that could be because I used a $50 NAT just to try it out. I assume that by getting a good Pix in there or something I should be good.

Believe me when I say this is an issue with something not on my end. Our brooktrout support has agreed with us on it. You are correct, it may not be a cisco bug, but it's on Vonage's network. I have noticed they keep like 4+ relays in the loop ALL the time, which is quite silly I think and it is something I have never seen Cisco equipment do. I think it's quite an interesting issue and I appreciate you're taking the time to read this post. It is quite hard to find very experienced people in Voip. Everyone thinks they know it, but very few do. I am proud to say I have actually read RFC 3261 and 2327 completely (I probably shouldn't brag about that Wink

If you're interested I can send you some Ethereal scans to look at.

Posts: 134 · Vonage Representative Joined: Apr 15, 2005 Posts: 134

you shoulld only use the rtp relay when behindf a nat'd device

Posts: 59 · Full Forum Member Joined: Dec 16, 2004 Posts: 59

Interesting. I still think a Cisco bug seems unlikely, only because I've worked with Cisco gateways in the configuration you have, where the sip and rtp are on different addresses. I still think a Vonage proxy or SBC is a likelier candidate. I would be interested in seeing those ethereal traces if you care to post them or send them to me.