[cisco-voip] Conferencing
Ryan Ratliff
rratliff at cisco.com
Thu May 3 11:30:54 EDT 2012
I think you may need to look at ccm traces. I don't see any obvious failures in your debugs.
-Ryan
On May 3, 2012, at 10:34 AM, Collins, Matthew wrote:
This time with the debug output added inline
Hi All,
Hope one of you can help out before I open a tac case.
Trying to set up a new branch site with a 2921 H323 SRST router with SCCP transcoding and Conferencing. Everything seems to be working ok with the exception of conferencing.
CUCM running is 6.1.5
2921 is running IOS Version 15.1(4)M3 with PVDM3-64
Conference bridge is set up as a Cisco IOS Enhanced Conference Bridge and is registered within CUCM
This should be compatible from table 5 2900 Interoperability with Cisco Unified Communications Manager
<image001.jpg>
SCCP admin state is showing up
SCCP Admin State: UP
Gateway Local Interface: Loopback0
IPv4 Address: 10.xxx.xxx.231
Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: 10.xxx.xxx.1, Port Number: 2000
Priority: N/A, Version: 6.0, Identifier: 4
Trustpoint: N/A
Call Manager: 10.xx.xxx.4, Port Number: 2000
Priority: N/A, Version: 6.0, Identifier: 3
Trustpoint: N/A
Call Manager: 10.xxx.xxx.2, Port Number: 2000
Priority: N/A, Version: 6.0, Identifier: 5
Trustpoint: N/A
Conferencing Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.xxx.xxx.1, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 1
Reported Max Streams: 32, Reported Max OOS Streams: 0
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30
All 3 phones and conference bridge are in the same DP using the same MRGL that has access to the MRG with only this conference bridge in, Im sure all the CUCM config is correct as I can see some output from a debug SCCP messages (see below) but not really sure how to decipher them. Once I have both separate calls set up and hit conf soft key I get Cannot complete conference at the bottom of the screen
May 3 19:07:04 BST: SCCP:rcvd OpenReceiveChannel
May 3 19:07:04 BST: OpenReceiveChannelMsg Info:
conference_id = 100679576, pass_through_party_id = 35786399
msec_pkt_size = 20, compression_type = 4
qualifier_in.ecvalue = 0, qualifier_in.g723_bitrate = 0, call_ref = 43787041
stream_pass_through_id = 0, rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0salt_len 0
May 3 19:07:04 BST: SCCP:send OpenReceiveChannelAck
May 3 19:07:04 BST: OpenReceiveChannelAck Info:
pass_through_party_id=35786399, status=0, host_ip_addr=<Loopback IP>, port=32140
May 3 19:07:04 BST: SCCP:rcvd OpenReceiveChannel
May 3 19:07:04 BST: OpenReceiveChannelMsg Info:
conference_id = 100679576, pass_through_party_id = 35786402
msec_pkt_size = 20, compression_type = 4
qualifier_in.ecvalue = 0, qualifier_in.g723_bitrate = 0, call_ref = 43787040
stream_pass_through_id = 0, rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0salt_len 0
May 3 19:07:04 BST: SCCP:send OpenReceiveChannelAck
May 3 19:07:04 BST: OpenReceiveChannelAck Info:
pass_through_party_id=35786402, status=0, host_ip_addr=<Loopback IP>, port=18950
May 3 19:07:04 BST: SCCP:rcvd StartMediaTransmission
May 3 19:07:04 BST: StartMediaTransmissionMsg Info:
conference_id = 100679576, pass_through_party_id = 35786399
remote_ip_addr = <Phone 2 IP>, remote_port = 30250
msec_pkt_size = 20, compression_type = 4
qualifier_out.precedence_value = 184, qualifier_out.ssvalue = 0
qualifier_out.max_frames_per_pkt = 0, qualifier_out.g723_bitrate = 0, call_ref = 43787041, stream_pass_through_id = 0 rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0salt_len 0
May 3 19:07:05 BST: SCCP:rcvd StartMediaTransmission
May 3 19:07:05 BST: StartMediaTransmissionMsg Info:
conference_id = 100679576, pass_through_party_id = 35786402
remote_ip_addr = <Phone 1 IP>, remote_port = 17244
msec_pkt_size = 20, compression_type = 4
qualifier_out.precedence_value = 184, qualifier_out.ssvalue = 0
qualifier_out.max_frames_per_pkt = 0, qualifier_out.g723_bitrate = 0, call_ref = 43787040, stream_pass_through_id = 0 rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0salt_len 0
May 3 19:07:05 BST: SCCP:rcvd CloseReceiveChannel
May 3 19:07:05 BST: CloseReceiveChannelMsg Info:
conference_id = 100679576, pass_through_party_id = 35786402, call_ref = 43787040, port_handling = 0
May 3 19:07:05 BST: SCCP:rcvd StopMediaTransmission
May 3 19:07:05 BST: StopMediaTransmissionMsg Info:
conference_id = 100679576, pass_through_party_id = 35786402, call_ref = 43787040, port_handling = 0
May 3 19:07:05 BST: SCCP:rcvd CloseReceiveChannel
May 3 19:07:05 BST: CloseReceiveChannelMsg Info:
conference_id = 100679576, pass_through_party_id = 35786399, call_ref = 43787041, port_handling = 0
May 3 19:07:05 BST: SCCP:rcvd StopMediaTransmission
May 3 19:07:05 BST: StopMediaTransmissionMsg Info:
conference_id = 100679576, pass_through_party_id = 35786399, call_ref = 43787041, port_handling = 0
Any help would be greatly appreciated.
Regards,
Matthew Collins
IPT Engineer
Global Voice Services
Linklaters LLP, London
Telephone: + 44 20 7456 2353
Mobile: + 44 7827 806 179
E-Mail: Matthew.Collins at Linklaters.com
_______________________________________________
Any business communication, sent by or on behalf of Linklaters LLP or one of its affiliated firms or other entities (together "Linklaters"), is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Linklaters may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks.
Linklaters LLP is a limited liability partnership registered in England and Wales with registered number OC326345. It is a law firm authorised and regulated by the Solicitors Regulation Authority (www.sra.org.uk). The term partner in relation to Linklaters LLP is used to refer to a member of Linklaters LLP or an employee or consultant of Linklaters LLP or any of its affiliated firms or entities with equivalent standing and qualifications. Please refer to www.linklaters.com/regulation for important information on our regulatory position.
A list of Linklaters LLP members together with a list of those non-members who are designated as partners and their professional qualifications, may be inspected at our registered office, One Silk Street, London EC2Y 8HQ and such persons are either solicitors, registered foreign lawyers or European lawyers.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120503/c4a6f53d/attachment.html>
More information about the cisco-voip
mailing list