SIP phones residing on LAN1 are configured in software to use mcast address 188.8.131.52, when the first SIP phone registers it sends an igmp join message which creates a group on the L2 switch, each subsequent SIP phone joins the group when they register thus creating a "room" function whereby each SIP devices "listens" sends and receives notification messages on its status to the same multicast group address, similar to a presence function.
(The multicast group is created when the first SIP device registers itself on the LAN it isn't created by a host sender always.)
A remote WAN site which uses the same SIP devices wishes to send and receive to the same multicast address 184.108.40.206 thus joining the same igmp group created on the LAN1 switch infrastructure.
The environment within the L3 core is PIM-Sparse using particular RP's which cannot be changed due to the nature of the business also requiring the use of real-time data.
I've tried to configure a GRE tunnel between the LAN1 next hop router and the router at the remote site and to then use the IGMP Join-group 220.127.116.11 command on the remote router, the tunnel works fine but the Room/Presence feature does not work.
Due to it being a production network i can only attempt the work out of hours so cannot gather logs etc...
If I understand you correctly then you have a number of SIP phones at different locations that use the multicast group 18.104.22.168 for an application similar to room/presence feature, and you want these two locations to interoperate.
I have a couple of questions:
Is the network between the main site and the remote site capable of native multicast routing, or is it necessary to tunnel the multicast traffic?
If you are tunneling the multicast traffic, have you manually modified the multicast routing table to expect the multicast senders via the tunnel interface (the RPF check)?
On which interface did you use the ip igmp join-group command?
Even though you indicated that the RP routers cannot be changed, you should be aware that you can configure separate RPs for every multicast group. You may configure different RP router for 22.214.171.124 and use the existing RP for all other groups. Is it then possible for the 126.96.36.199 group to define your own RPs if the situation requires it?
1. Yes it is possible to use native multicasting routing, we currently use PIM-SM for multicast routing for real-time data and use the core routers as rp's for certain multicast traffic (in terms of the scenario I wish to tunnel as I'd prefer not to make too many changes to the core multicast config currently in place), when testing the deployment of the scenario we've used the core for the rp which is fine... however because SIP Devices in both the local and remote location send and receive on the same 188.8.131.52 address it will be whichever SIP device sends data to the rp point that will determine the multicast route, so when we've tested using the rp as the core of the network only the presence feature for the SIP devices in one location will actually work...
3. Tunnel0 interface
4. I guess this relates to what i've written in point one.
The difficulty arises due to two different sites and hosts sending and receiving on the same multicast address.
I think I may have to look into configuring some sort of L2TP tunnel and to then extend the Local VLAN which the SIP Devices reside upon to the remote site and run IGMP over the tunnel
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...