-
1
- #1
Happy NYE everyone,
Just want to share on an solution that I've been trying to find for the past couple of day. I just provisioned a SIP trunk which terminates to a vMBG operating in server-only mode, located in the same subnet as the vMCD. Incoming calls are working 100%, two way audio with everything streaming to/from the vMBG. Outgoing calls on the other hand, we experiencing one way audio. Capturing packets at the WAN/LAN interfaces of the firewall, at the vMBG and vMCD confirmed that my outbound RTP packets from the IP phone were indeed being sent to the vMBG. vMBG was passing the packets to the SBC of the service provider and the called party could hear the caller. The incoming RTP packets from the SBC were passing through the firewall without being manipulated, ending up at the vMBG. Then, nothing.
The vMBG was not forwarding the packets onto the IP phone. I was able to decode and listen to both audio streams as they arrived at the vMBG. Further investigation into the SDP portion of the exchange between the vMCD and vMBG showed that the vMCD was sending a 'PRACK' containing the endpoint information in a text/plain format.
But this was after the initial INVITE from vMCD to vMBG and after the vMBG sent a 'Trying' and 'Session Progress' packet back to the vMCD. Even though the vMBG replied with an 'OK' to the vMCD 'PRACK', it doesn't look like anything became of the media endpoint information.
Fast forward to now and I have enabled this SDP Option in the SIP Peer Profile: Force sending SDP initial INVITE message
The SDP options are sent in the first INVITE packet from the vMCD and the media attributes actually show up in Wireshark in the format I would expect.
--BEFORE--
Message Body > Line-based text data: text/plain
v=0\r\n
o=- 4029 4030 IN IP4 192.168.10.56\r\n
s=-\r\n
c=IN IP4 192.168.10.56\r\n
t=0 0\r\n
m==audio 50128 RTP/AVP 0 101\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
--AFTER--
Message Body > Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creater, Session Id (o): -
Session Name (s): -
Connection Information (c): IN 192.168.10.56
Time Description, acvite time (t): 0 0
Media Description, name and address (m): audio 50436 RTP/AVP 18 102 0 8 121 101
Media attribute (a): rtpmap:102 G7221/16000
Media attribute (a): fmtp:102 bitrate=32000
Media attribute (a): rtpmap:121 L16/16000
Media attribute (a): rtpmap:18 G729/8000
Media attribute (a): fmtp:19 annexb=no
Media attribute (a): rtpmap:101 telephone-event/8000
Media attribute (a): fmtp:101 0-15
Hope this helps anyone else experiencing a one way audio problem that is not related to the default gateway of their end points but still involves SIP and vMBG.
See ya next year,
-b
Just want to share on an solution that I've been trying to find for the past couple of day. I just provisioned a SIP trunk which terminates to a vMBG operating in server-only mode, located in the same subnet as the vMCD. Incoming calls are working 100%, two way audio with everything streaming to/from the vMBG. Outgoing calls on the other hand, we experiencing one way audio. Capturing packets at the WAN/LAN interfaces of the firewall, at the vMBG and vMCD confirmed that my outbound RTP packets from the IP phone were indeed being sent to the vMBG. vMBG was passing the packets to the SBC of the service provider and the called party could hear the caller. The incoming RTP packets from the SBC were passing through the firewall without being manipulated, ending up at the vMBG. Then, nothing.
The vMBG was not forwarding the packets onto the IP phone. I was able to decode and listen to both audio streams as they arrived at the vMBG. Further investigation into the SDP portion of the exchange between the vMCD and vMBG showed that the vMCD was sending a 'PRACK' containing the endpoint information in a text/plain format.
But this was after the initial INVITE from vMCD to vMBG and after the vMBG sent a 'Trying' and 'Session Progress' packet back to the vMCD. Even though the vMBG replied with an 'OK' to the vMCD 'PRACK', it doesn't look like anything became of the media endpoint information.
Fast forward to now and I have enabled this SDP Option in the SIP Peer Profile: Force sending SDP initial INVITE message
The SDP options are sent in the first INVITE packet from the vMCD and the media attributes actually show up in Wireshark in the format I would expect.
--BEFORE--
Message Body > Line-based text data: text/plain
v=0\r\n
o=- 4029 4030 IN IP4 192.168.10.56\r\n
s=-\r\n
c=IN IP4 192.168.10.56\r\n
t=0 0\r\n
m==audio 50128 RTP/AVP 0 101\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
--AFTER--
Message Body > Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creater, Session Id (o): -
Session Name (s): -
Connection Information (c): IN 192.168.10.56
Time Description, acvite time (t): 0 0
Media Description, name and address (m): audio 50436 RTP/AVP 18 102 0 8 121 101
Media attribute (a): rtpmap:102 G7221/16000
Media attribute (a): fmtp:102 bitrate=32000
Media attribute (a): rtpmap:121 L16/16000
Media attribute (a): rtpmap:18 G729/8000
Media attribute (a): fmtp:19 annexb=no
Media attribute (a): rtpmap:101 telephone-event/8000
Media attribute (a): fmtp:101 0-15
Hope this helps anyone else experiencing a one way audio problem that is not related to the default gateway of their end points but still involves SIP and vMBG.
See ya next year,
-b
