|Summary:||ASTERISK-02885: chan_mgcp does not send correct ip in sdp until reloaded|
|Date Opened:||2004-11-24 15:40:33.000-0600||Date Closed:||2005-04-05 04:12:46|
|Description:||chan_mgcp sends incorrect "IN IP4 0.0.0.0" in CRCX command while establishing channel in "bindaddr" option in mgcp.conf is set.|
However issuing "mgcp reload" command from CLI completely resolves this bug until next asterisk coldstart.
|Comments:||By: nording (nording) 2004-11-26 10:16:58.000-0600|
note: reverse applying this patch:
resolves this bug
By: Mark Spencer (markster) 2004-12-01 00:41:43.000-0600
what is your bindaddr set to?
By: nording (nording) 2004-12-01 07:28:27.000-0600
bindaddr in mgcp.conf is set to = xxx.xxx.xxx.64, while primary system ip is xxx.xxx.xxx.14 and by defaut rtp binds to last.
And one more note: unsetting bindaddr in mgcp.conf (or setting it to 0.0.0.0) also resolves this bug.
By: Olle Johansson (oej) 2004-12-13 02:05:04.000-0600
By: Mark Spencer (markster) 2004-12-26 17:59:03.000-0600
Can you try latest CVS, too?
By: alric (alric) 2005-01-04 18:55:23.000-0600
Have you had a chance to try latest CVS, if so were there any changes?
By: nording (nording) 2005-01-05 14:26:34.000-0600
Sorry for the delay. Yes, I have tried latest CVS (CVS-HEAD-01/05/05-10:48:59) with the following results:
Asterisk issues CRCX with "c=IN IP4 xxx.xxx.xxx.14" (main system IP, not the one, which is set to be bindaddr in mgcp.conf), while listening on correct IP. This prevents sound to thavel from mgcp device to asterisk (sound from asterisk to mgcp device travels well).
And a couple of strange things is observed by the way:
1) synchronously with the correct RTP socket binding Asterisk creates one more UDP binging with IP 0.0.0.0 and port greather by one (i don't confuse it with outbound chan_sip's binding or something else - it is created almost synchronously with the correct chan_mgcp one - shortly after L/hd event)
2) "RQNT" is issued in a triple after every "NTFY D/x"
debug transcript with comments, that illustrating mentioned is placed here:
edited on: 01-05-05 17:08
By: Andrey S Pankov (casper) 2005-01-06 08:54:04.000-0600
You need to look through add_sdp function in chan_mgcp.c and add debug output there to see where we set dest.sin_addr value and why it is set this way. As I know there are still problems even in SIP channel on multihomed systems.
It would be more helpful if you include full debug output, not stripped... Thanks.
Other thing here... Are you sure everything is set up correctly? Could you show us "ifconfig", "route -n", "ip ro get x.x.x.26" (if available) output?
edited on: 01-06-05 09:01
By: nording (nording) 2005-01-08 13:33:19.000-0600
Shown debug output is full (all, that "ngrep -W byline -d eth0.16 '' port 2427" shows)
Yes, i am sure the setup is correct.
$ ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet xxx.xxx.xxx.64/32 scope global lo
valid_lft forever preferred_lft forever
17: eth0.16: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:0c:f1:e8:9b:be brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.14/27 brd xxx.xxx.xxx.31 scope global eth0.16
valid_lft forever preferred_lft forever
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
xxx.xxx.xxx.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0.16
0.0.0.0 xxx.xxx.xxx.1 0.0.0.0 UG 0 0 0 eth0.16
$ ip ro get xxx.xxx.xxx.26
xxx.xxx.xxx.26 dev eth0.16 src xxx.xxx.xxx.14
cache mtu 1500 advmss 1460
device is quite reacheable (it's cisco ata186 and 70ms delay is okay for it):
$ ping -c 1 xxx.xxx.xxx.26
PING xxx.xxx.xxx.26 (xxx.xxx.xxx.26) 56(84) bytes of data.
64 bytes from xxx.xxx.xxx.26: icmp_seq=0 ttl=250 time=70.2 ms
--- xxx.xxx.xxx.26 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.201/70.201/70.201/0.000 ms, pipe 2
Since, I don't think this is multihomed- or routing- relatad problems.
I'll try to get more debug around add_sdp in chan_mgcp.c
By: Andrey S Pankov (casper) 2005-01-18 09:09:17.000-0600
By: Mark Spencer (markster) 2005-02-04 00:22:14.000-0600
I cannot duplicate this problem. Can you please attach your mgcp.conf file? Do you see the problem when you go off hook with your MGCP device or only when you call it?
By: Mark Spencer (markster) 2005-03-08 23:58:05.000-0600
Unable to duplicate and no response from bug placer.