media-gateway ip primary

[gregh]

In need of assistance understanding the "media-gateway ip primary" interface command on the 908e.

I think that it means to use the primary ip address configured on a 908e interface when communicating with a SIP server. Based on some examples that I found you could also use the secondary IP or even a loopback IP when communicating with a SIP server.

So, is it that simple or is there more to it?

Gre

[Anonymous]

Hello Gre,

Thanks for posting to our forum.  The media-gateway ip primary command needs to be on any IP interface where SIP and/or RTP passes through --- so it can be pretty straight forward.  So if you had a PRI on the CPE side and you wanted to send local calls to one SIP Server (off ethernet 0/1) and long distance calls to another SIP server (off eth 0/2), you would use media-gateway ip primary on both eth 0/1 and eth 0/2. 

Here is a link to a doc that shows IP interfaces and the media-gateway command with some examples:

https://supportforums.adtran.com/docs/DOC-2879

Let us know if you have any questions.

Regards,

Geoff

[gregh]

Thanks Geoff,

When you say "passes through" but use the example of PRI to SIP I'm a bit of confused.

I'm assuming that with a PRI on one side being translated to SIP on the other side, SIP/RTP traffic is being generated by the Adtran and is not exactly SIP/RTP traffic that is "passing through" the Adtran. In this case the SIP/RTP traffic is being generated by the Adtran and therefore needs a source IP of some interface on the Adtran.

Now, what if I had a SIP capable PBX hanging off an ethernet port of the Adtran communicating directly with a SIP server somewhere upstream of the WAN side of the Adtran. SIP/RTP traffic would be generated by the SIP PBX using the PBX IP as the source IP. The Adtran would be "passing through" the PBX SIP/RTP traffic just the same as any other customer generated traffic like HTTP, Telnet, etc.

In this case would the "media-gateway ip primary" command be required and, if so, what function is the command serving... what effect is it having on the traffic passing through?

Greg

[jayh]

There's a bit more to it than that, but putting media-gateway ip primary on every interface on which the Adtran will be handling voice traffic will work in most cases.

The command denotes the IP interface where SIP and RTP will originate and terminate on the Adtran.  If you have a complex routing scenario with a primary and backup link and you want to keep the VoIP IP address the same, you can create a loopback address on the box and have both primary and backup links route to it.  Then, on both of the outward-facing interfaces you could provision media-gateway ip loopback 1 and the VoIP traffic would source from and terminate on the loopback. This is useful in a scenario where you don't want to go through re-registration or drop a call when an IP link flaps, for example.

If you're doing SIP proxy you need media-gateway ip primary on the inside interface facing the phones as well.

If an interface has a secondary IP configured you could presumably use media-gateway ip secondary to terminate VoIP there but I haven't tried it.

[gregh]

Thanks jayh,

That's kind of the answer that I was looking for. The media-gateway ip primary command applies to SIP/RTP traffic being generated/received BY the Adtran.

So far I'm not seeing any documentation that would suggest that SIP/RTP traffic being generated/received by an outside device, sending traffic THRU the Adtran, could, would or should be manipulated by the media-gateway ip primary command.

I'm trying to win an argument regarding the actual function of the media-gateway ip primary command. So far the documentation isn't totally clear but it makes sense that you would need to specify the IP address of SIP/RTP traffic generated by the Adtran when it could potentially have multiple egress interfaces.

[jayh]

It depends on what you mean by THRU. One of the benefits of the TA900 series is its ability to manipulate the SIP messages, analyze RTP, and its general usefulness as a SIP/VoIP toolbox.

Our company is primarily a hosted VoIP provider.  We use the TA900 mostly as a SIP proxy with phones on the inside and the hosted PBX on the outside.  In this case you do need the media-gateway ip configuration even though the DSPs aren't in use, it's just passing through the RTP and proxying the SIP.

If you are strictly using it as an IP router or "dumb" NAT box with no ip sip configured, then a SIP or RTP stream passing through the box would be treated the same as any other protocol passing through and you wouldn't need the media-gateway ip configuration at all.  Of course you wouldn't get any VQM statistics, SIP NAT fixup, QoS, or any other benefit of using the TA900 platform.

So it probably depends on the wording of your wager.  You can get SIP/RTP THRU the box without the media-gateway ip configuration.  But you can also get SIP/RTP through a piece of wire without any configuration.  If you want the benefits of the TA900 platform for VoIP, you'll want the media-gateway ip command on the interfaces THRU which it passes.

In your scenario of a SIP PBX on the inside and a SIP trunk to a provider on the outside, you won't get audio if SIP is enabled on the box globally unless you put the media-gateway ip command on the interfaces.

[gregh]

jayh,

Excellent, now we're getting to the meat and potatoes so to speak. This is the kind of information that I seem to be having trouble finding.

So it would seem that the "ip sip" command along with the "media-gateway ip" command are requirements for VQM, NAT fixup, QoS, etc, but not for generic SIP traffic that just happens to be traversing the router ie; plain old ip router.  (Although I'm assuming I could still classify and apply QoS to SIP/RTP traffic regardless)

Which kind of brings me back to my original question of what effect does the "media-gateway ip" command have.

Now I'll have to expand my question a bit to include what effect the command has on the Adtran and/or the traffic flowing thru the Adtran?

I'm still thinking that the "media-gateway ip" command, by itself, does nothing more than force the 908 to use a particular IP as the source of SIP/RTP traffic generated by the router itself. And, in conjunction with the "ip sip" command, enables various advanced features.

My scenario for the wager was that the SIP trunk is directly between the SIP PBX and a SIP server with the 900 being used as an IP router only. I was told that it wouldn't work at all which didn't make a lot of sense to me.

Thank you for indulging me. I'm new to the Adtran world and the back-and-forth here in the forums is a great learning tool. Greatly appreciated.

[jayh]

I'm not an Adtran engineer, just a customer like you, but that seems to sum it up based on our testing.  If ip sip is enabled on the box, then every physical interface with SIP traffic will need to have media-gateway ip configured so the SIP engine can inspect and process the traffic.

Indeed you can leave SIP disabled with no ip sip, do QoS based on DSCP or port/protocol, and turn the TA900 into a dumb NAT box.  Kind of like having a Ferrari and never taking it out of second gear.

[Anonymous]

I just wanted to add to this dialogue and provide a little more info from the ADTRAN side.

The media-gateway command has several functions:

1. Allows an interface to listen for and transmit SIP and RTP when using the SIP proxy or SIP B2BUA
2. Allows an interface to listen for and transmit MGCP and RTP when using MGCP locally
3. Used to set the IP address in SIP, MGCP, and RTP headers when SIP proxy, SIP B2BUA, or local MGCP traffic egresses that interface, as determined by the route table

From a SIP standpoint, it is only used by the SIP proxy and SIP B2BUA. If the B2BUA and proxy aren't being used for the SIP traffic flowing through the unit, it is not necessary to configure media-gateway on the interfaces.

The media-gateway must also be configured on egress interfaces used by VQM reporter, as that information is sent via SIP PUBLISH messages. The media-gateway configuration has no effect on QoS.

Regards,

Geoff

[gregh]

Thank you Geoff,

That clears that up. Looks like I win my argument... this time.

[Anonymous]

Hello,

I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Geoff