Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: bogen tamb pop when user hangs up - vg224 (Jason Aarons (AM))
2. Re: bogen tamb pop when user hangs up - vg224 (Jason Faraone)
3. Comfort noise RTP (Seth McGuinness)
4. Re: Comfort noise RTP (Mark Holloway)
5. Re: CP-8831 IP Conference Phone (Ryan Ratliff (rratliff))
6. DTMF Method Stripped on reINVITE | CUCM 8.6.2 (Daniel Pagan)
7. Re: CP-8831 IP Conference Phone (Ryan Ratliff (rratliff))
8. Re: CP-8831 IP Conference Phone (Bryant Onojeta)
9. Re: CP-8831 IP Conference Phone (Ryan Ratliff (rratliff))
10. Re: DTMF Method Stripped on reINVITE | CUCM 8.6.2
(Divin John (dijohn))
11. Re: CP-8831 IP Conference Phone (Bryant Onojeta)
12. Re: CP-8831 IP Conference Phone (Ryan Ratliff (rratliff))
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Aug 2013 22:27:31 -0400
From: "Jason Aarons (AM)" <[email protected]>
To: Jason Faraone <[email protected]>, "'Erick Wellnitz'"
<[email protected]>, cisco-voip <[email protected]>
Subject: Re: [cisco-voip] bogen tamb pop when user hangs up - vg224
Message-ID:
<4e38db0a1959b04c8c83edcf069b53ed0d3aaf6...@usispclexdb01.na.didata.local>
Content-Type: text/plain; charset="windows-1252"
You really should use FXO for paging due to a lack of supervisory disconnect.
Stacking feedback eliminator usually helps as well, else you got try hanging
the phone up via End Call softkey versus setting the handset mic down hard!
From: cisco-voip [mailto:[email protected]] On Behalf Of Jason
Faraone
Sent: Wednesday, August 07, 2013 4:26 PM
To: 'Erick Wellnitz'; cisco-voip
Subject: Re: [cisco-voip] bogen tamb pop when user hangs up - vg224
I have a few locations with the same setup (VG224 => Tam B) and I don't think I
have seen this issue. My dipswitch configuration is (1,2,4,5 = OFF; 3 = ON).
From: cisco-voip [mailto:[email protected]] On Behalf Of Erick
Wellnitz
Sent: Wednesday, August 07, 2013 3:15 PM
To: cisco-voip
Subject: [cisco-voip] bogen tamb pop when user hangs up - vg224
Anyone ever had an issue where there is a 'pop' after the user hangs up to a
Bogen tamb? We have it connected via a VG224.
The strangest part is that we have another one that is perfect without tweaking
anything.
itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130807/ed96317a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 8 Aug 2013 02:33:40 +0000
From: Jason Faraone <[email protected]>
To: "Jason Aarons (AM)" <[email protected]>, "'Erick
Wellnitz'" <[email protected]>, cisco-voip
<[email protected]>
Subject: Re: [cisco-voip] bogen tamb pop when user hangs up - vg224
Message-ID: <[email protected]>
Content-Type: text/plain; charset="Windows-1252"
Yea, I've been migrating to DFT 120s when given the chance.
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: "Jason Aarons (AM)" <[email protected]>
Date: 08/07/2013 9:28 PM (GMT-06:00)
To: Jason Faraone <[email protected]>,'Erick Wellnitz'
<[email protected]>,cisco-voip <[email protected]>
Subject: RE: [cisco-voip] bogen tamb pop when user hangs up - vg224
You really should use FXO for paging due to a lack of supervisory disconnect.
Stacking feedback eliminator usually helps as well, else you got try hanging
the phone up via End Call softkey versus setting the handset mic down hard!
From: cisco-voip [mailto:[email protected]] On Behalf Of Jason
Faraone
Sent: Wednesday, August 07, 2013 4:26 PM
To: 'Erick Wellnitz'; cisco-voip
Subject: Re: [cisco-voip] bogen tamb pop when user hangs up - vg224
I have a few locations with the same setup (VG224 => Tam B) and I don?t think I
have seen this issue. My dipswitch configuration is (1,2,4,5 = OFF; 3 = ON).
From: cisco-voip [mailto:[email protected]] On Behalf Of Erick
Wellnitz
Sent: Wednesday, August 07, 2013 3:15 PM
To: cisco-voip
Subject: [cisco-voip] bogen tamb pop when user hangs up - vg224
Anyone ever had an issue where there is a 'pop' after the user hangs up to a
Bogen tamb? We have it connected via a VG224.
The strangest part is that we have another one that is perfect without tweaking
anything.
itevomcid
------------------------------
Message: 3
Date: Thu, 8 Aug 2013 11:33:32 +0100
From: "Seth McGuinness" <[email protected]>
To: <[email protected]>
Subject: [cisco-voip] Comfort noise RTP
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello All,
We have a customer complaining about Comfort Noise generating from our
Cisco AS5400, strange thing is that the packet traces suggest that the
request for comfort noise generation comes from the client SIP invite, I
can't see where this is the case in the invite.
Client invite
No. Time Source Destination Protocol Length
Info
1 2013-08-07 09:21:34.500695 10.10.1.1 192.168.1.1 SIP/SDP 1131
Request: INVITE sip:[email protected];user=phone, with
session description
Frame 1: 1131 bytes on wire (9048 bits), 1131 bytes captured (9048 bits)
Ethernet II, Src: WwPcbaTe_11:11:11 (00:0f:1f:11:11:11), Dst:
BrocadeC_22:22:22 (00:1b:ed:22:22:22)
Internet Protocol Version 4, Src: 10.10.1.1(10.10.1.1), Dst: 192.168.1.1
(192.168.1.1)
User Datagram Protocol, Src Port: sip-tls (5061), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:[email protected];user=phone
SIP/2.0
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 1375863694 1375863694 IN
IP4 10.10.1.1
Owner Username: -
Session ID: 1375863694
Session Version: 1375863694
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 10.10.1.1
Session Name (s): -
Connection Information (c): IN IP4 10.10.1.1
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 10.10.1.1
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 33870 RTP/AVP
8 0 18 101
Media Type: audio
Media Port: 33870
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-15
Media Attribute (a): sendrecv
Media Attribute (a): silenceSupp:off - - - -
Media Attribute Fieldname: silenceSupp
Media Attribute Value: off - - - -
Our response
No. Time Source Destination
Protocol Length Info
2 2013-08-07 09:21:41.862610 192.168.1.1 10.10.1.1
RTP 60 PT=Comfort noise, SSRC=0x8FED3F6, Seq=28259,
Time=1374861414
Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: BrocadeC_22:22:22 (00:1b:ed:22:22:22), Dst:
WwPcbaTe_11:11:11 (00:0f:1f:11:11:11)
Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst:
10.10.1.1(10.10.1.1)
User Datagram Protocol, Src Port: 19578 (19578), Dst Port: 33870 (33870)
Real-Time Transport Protocol
[Stream setup by SDP (frame 1)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: Comfort noise (13)
Sequence number: 28259
[Extended sequence number: 93795]
Timestamp: 1374861414
Synchronization Source identifier: 0x08fed3f6 (150918134)
Payload: 48
In our RTP Comfort noise payload type 13 in frame(2) it states that the
Stream has been setup by SDP in frame 1, I can't see this in frame 1, it
has silence suppression turned off and annexb=no, the RTP stream is
G.711 anyway, I left out the whole capture for brevity. Has anyone come
across this? Any suggestions appreciated and apologies if I post this in
the wrong place!
Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/e2dc86ae/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 8 Aug 2013 11:33:59 -0400
From: Mark Holloway <[email protected]>
To: Seth McGuinness <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Comfort noise RTP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
This is incredibly odd. I don't see a payload of 13 or an rtpmap with CN. Are
you sure you have the entire frame included? I would be curious to see a pcap
SIP ladder diagram of the call flow. That SDP is huge. I wouldn't be surprised
if something in that SDP is triggering the abnormal behavior. :)
On Aug 8, 2013, at 6:33 AM, Seth McGuinness <[email protected]>
wrote:
> Hello All,
>
> We have a customer complaining about Comfort Noise generating from our Cisco
> AS5400, strange thing is that the packet traces suggest that the request for
> comfort noise generation comes from the client SIP invite, I can?t see where
> this is the case in the invite.
>
> Client invite
>
> No. Time Source Destination Protocol Length Info
> 1 2013-08-07 09:21:34.500695 10.10.1.1 192.168.1.1 SIP/SDP 1131 Request:
> INVITE sip:[email protected];user=phone, with session description
>
> Frame 1: 1131 bytes on wire (9048 bits), 1131 bytes captured (9048 bits)
> Ethernet II, Src: WwPcbaTe_11:11:11 (00:0f:1f:11:11:11), Dst:
> BrocadeC_22:22:22 (00:1b:ed:22:22:22)
> Internet Protocol Version 4, Src: 10.10.1.1(10.10.1.1), Dst: 192.168.1.1
> (192.168.1.1)
> User Datagram Protocol, Src Port: sip-tls (5061), Dst Port: sip (5060)
> Session Initiation Protocol
> Request-Line: INVITE sip:[email protected];user=phone SIP/2.0
> Message Header
> Message Body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): - 1375863694 1375863694 IN IP4
> 10.10.1.1
> Owner Username: -
> Session ID: 1375863694
> Session Version: 1375863694
> Owner Network Type: IN
> Owner Address Type: IP4
> Owner Address: 10.10.1.1
> Session Name (s): -
> Connection Information (c): IN IP4 10.10.1.1
> Connection Network Type: IN
> Connection Address Type: IP4
> Connection Address: 10.10.1.1
> Time Description, active time (t): 0 0
> Session Start Time: 0
> Session Stop Time: 0
> Media Description, name and address (m): audio 33870 RTP/AVP 8 0
> 18 101
> Media Type: audio
> Media Port: 33870
> Media Protocol: RTP/AVP
> Media Format: ITU-T G.711 PCMA
> Media Format: ITU-T G.711 PCMU
> Media Format: ITU-T G.729
> Media Format: DynamicRTP-Type-101
> Media Attribute (a): rtpmap:8 PCMA/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 8
> MIME Type: PCMA
> Sample Rate: 8000
> Media Attribute (a): rtpmap:0 PCMU/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 0
> MIME Type: PCMU
> Sample Rate: 8000
> Media Attribute (a): rtpmap:18 G729/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 18
> MIME Type: G729
> Sample Rate: 8000
> Media Attribute (a): fmtp:18 annexb=no
> Media Attribute Fieldname: fmtp
> Media Format: 18 [G729]
> Media format specific parameters: annexb=no
> Media Attribute (a): rtpmap:101 telephone-event/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 101
> MIME Type: telephone-event
> Sample Rate: 8000
> Media Attribute (a): fmtp:101 0-15
> Media Attribute Fieldname: fmtp
> Media Format: 101 [telephone-event]
> Media format specific parameters: 0-15
> Media Attribute (a): sendrecv
> Media Attribute (a): silenceSupp:off - - - -
> Media Attribute Fieldname: silenceSupp
> Media Attribute Value: off - - - -
>
>
> Our response
>
> No. Time Source Destination
> Protocol Length Info
> 2 2013-08-07 09:21:41.862610 192.168.1.1 10.10.1.1 RTP
> 60 PT=Comfort noise, SSRC=0x8FED3F6, Seq=28259, Time=1374861414
>
> Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
> Ethernet II, Src: BrocadeC_22:22:22 (00:1b:ed:22:22:22), Dst:
> WwPcbaTe_11:11:11 (00:0f:1f:11:11:11)
> Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst:
> 10.10.1.1(10.10.1.1)
> User Datagram Protocol, Src Port: 19578 (19578), Dst Port: 33870 (33870)
> Real-Time Transport Protocol
> [Stream setup by SDP (frame 1)]
> 10.. .... = Version: RFC 1889 Version (2)
> ..0. .... = Padding: False
> ...0 .... = Extension: False
> .... 0000 = Contributing source identifiers count: 0
> 0... .... = Marker: False
> Payload type: Comfort noise (13)
> Sequence number: 28259
> [Extended sequence number: 93795]
> Timestamp: 1374861414
> Synchronization Source identifier: 0x08fed3f6 (150918134)
> Payload: 48
>
> In our RTP Comfort noise payload type 13 in frame(2) it states that the
> Stream has been setup by SDP in frame 1, I can?t see this in frame 1, it has
> silence suppression turned off and annexb=no, the RTP stream is G.711 anyway,
> I left out the whole capture for brevity. Has anyone come across this? Any
> suggestions appreciated and apologies if I post this in the wrong place!
>
> Cheers
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/a764e300/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 8 Aug 2013 17:00:55 +0000
From: "Ryan Ratliff (rratliff)" <[email protected]>
To: Bryant Onojeta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Did you charge the mics out of the box?
What is your wireless mic range set to?
-Ryan
On Aug 6, 2013, at 1:10 PM, Bryant Onojeta
<[email protected]<mailto:[email protected]>> wrote:
Hey,
Has anyone had an issue with pairing the wireless microphones with the 8831 DCU?
I cannot get the wireless mic's to pair to the DCU, I consistently get
"Microphone 1/2 pairing timeout! Retry?"
any help would be appreciated, opened a TAC case and the engineer said that he
don't have a phone to even lab this scenario up with.
I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do work
but the just the wireless mic's won't pair.
Thanks,
-Bryant
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/a3f697dc/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 8 Aug 2013 17:55:21 +0000
From: Daniel Pagan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2
Message-ID:
<a4f4beead515f947ac82d086a78c70f660319...@nyc-exch-mb01.fidelus.com>
Content-Type: text/plain; charset="iso-8859-1"
Folks:
I'm looking at an interesting issue where CUCM is stripping DTMF method from a
reINVITE and I'm wondering if you've seen this before. Topology is pretty
simple: CUCM ==SIPTrunk==VerizonSBC. CUBE is not involved in this scenario for
this particular environment (different issue, different story). Audio
cut-through is successful but no DTMF method is established.
The transaction flows is as follows (Call-ID header and IP addresses omitted):
INVITE -->SBC - Early Offer in use
..
....
t=0 0
m=audio 27030 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
200 <-- SBC - Containing SDP w/ reordered, preferred codecs
..
.....
v=0
o=BroadWorks 492305543 1 IN IP4 10.15.5.119
s=-
c=IN IP4 10.15.5.119
t=0 0
a=sqn: 0
a=cdsc: 1 image udptl t38
m=audio 41194 RTP/AVP 0 18 8 101
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
CUCM ACK's the 200 (omitted) to close the transaction and sends a reINVITE with
a single codec but no DTMF method:
v=0
o=CiscoSystemsCCM-SIP 962515 2 IN IP4 10.15.81.106
s=SIP Call
c=IN IP4 10.17.66.123
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27030 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
=========================
The SIP trunk is configured for DTMF method of No Preference. I also see no MTP
allocation attempts from MediaManager in SDI traces which makes me think we're
not dealing with a media negotiation failure. Other SBC's in this environment
perform an early cut-through of audio via 183s to CUCM resulting in no issues.
It seems to me the solution would be to force the SBC to send a 200 answer w/
only a single codec in its SDP, theoretically eliminating the need for a
reINVITE. But unfortunately this isn't possible since the provider is adhering
to the Answer/Offer Model RFC:
"For streams marked as sendrecv in the answer,
the "m=" line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer."
Any thoughts on why CUCM would be stripping the DTMF method from its reINVITE?
Again, I see no MTP allocation requests from MediaManager, so I doubt it's the
result of a negotiation failure. Setting the SIP Trunk's DTMF method from No
Preference to RFC2833 results in the same problem. Lastly, a bug scrub didn't
come back with anything that matched the symptoms spot on. CUCM is 8.6.2.
Thanks ahead of time!
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/d0f2ce6e/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 8 Aug 2013 20:18:25 +0000
From: "Ryan Ratliff (rratliff)" <[email protected]>
To: Bryant Onojeta <[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
More questions now that I've got my hands on one.
What is the led on the mic doing?
Were you able to find any document on cisco.com<http://cisco.com> that walked
you through this process?
If you didn't bother looking can you give it a shot and let me know what you
find?
-Ryan
On Aug 8, 2013, at 1:00 PM, Ryan Ratliff (rratliff)
<[email protected]<mailto:[email protected]>> wrote:
Did you charge the mics out of the box?
What is your wireless mic range set to?
-Ryan
On Aug 6, 2013, at 1:10 PM, Bryant Onojeta
<[email protected]<mailto:[email protected]>> wrote:
Hey,
Has anyone had an issue with pairing the wireless microphones with the 8831 DCU?
I cannot get the wireless mic's to pair to the DCU, I consistently get
"Microphone 1/2 pairing timeout! Retry?"
any help would be appreciated, opened a TAC case and the engineer said that he
don't have a phone to even lab this scenario up with.
I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do work
but the just the wireless mic's won't pair.
Thanks,
-Bryant
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/c53355db/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 8 Aug 2013 15:26:23 -0500
From: Bryant Onojeta <[email protected]>
To: "Ryan Ratliff (rratliff)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<CAK5i2X4e35OopZO0LhaXGm=Mg3=+eZSL=dsbsjs8xv91v12...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I did charge the mic's and the range was high.
What i found was that the pairing is:
1.admin setting>wireless mic's>pairing
2.press button til led is solid red, let go ( light will go off)
3. press button til led is solid red and pairing should be complete
....
Now i am having issue with the phone linking to another base.
On Thu, Aug 8, 2013 at 12:00 PM, Ryan Ratliff (rratliff)
<[email protected]> wrote:
> Did you charge the mics out of the box?
>
> What is your wireless mic range set to?
>
> -Ryan
>
> On Aug 6, 2013, at 1:10 PM, Bryant Onojeta <[email protected]> wrote:
>
> Hey,
>
> Has anyone had an issue with pairing the wireless microphones with the 8831
> DCU?
> I cannot get the wireless mic's to pair to the DCU, I consistently get
> "Microphone 1/2 pairing timeout! Retry?"
> any help would be appreciated, opened a TAC case and the engineer said that
> he don't have a phone to even lab this scenario up with.
> I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do
> work but the just the wireless mic's won't pair.
>
> Thanks,
>
> -Bryant
>
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
------------------------------
Message: 9
Date: Thu, 8 Aug 2013 20:54:43 +0000
From: "Ryan Ratliff (rratliff)" <[email protected]>
To: Bryant Onojeta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Your steps are correct. The fact that the charging station turns the mic on is
a bit of a pain out of the box because you have to turn the mic off and then
back on to start the pairing (as you noted).
There is supposed to be a section in the admin guide but it appears to have
gone missing at some point. I filed CSCui56402 to get that fixed hopefully (it
should be visible tomorrow).
For the daisy chain it should just work, make sure you have wall power,
network, and the DCU on the main unit. If you are using PoE I suspect the wall
power requirement may be big gotcha. I need to dig up a cable before I can
test that here.
-Ryan
On Aug 8, 2013, at 4:26 PM, Bryant Onojeta <[email protected]>
wrote:
I did charge the mic's and the range was high.
What i found was that the pairing is:
1.admin setting>wireless mic's>pairing
2.press button til led is solid red, let go ( light will go off)
3. press button til led is solid red and pairing should be complete
....
Now i am having issue with the phone linking to another base.
On Thu, Aug 8, 2013 at 12:00 PM, Ryan Ratliff (rratliff)
<[email protected]> wrote:
> Did you charge the mics out of the box?
>
> What is your wireless mic range set to?
>
> -Ryan
>
> On Aug 6, 2013, at 1:10 PM, Bryant Onojeta <[email protected]> wrote:
>
> Hey,
>
> Has anyone had an issue with pairing the wireless microphones with the 8831
> DCU?
> I cannot get the wireless mic's to pair to the DCU, I consistently get
> "Microphone 1/2 pairing timeout! Retry?"
> any help would be appreciated, opened a TAC case and the engineer said that
> he don't have a phone to even lab this scenario up with.
> I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do
> work but the just the wireless mic's won't pair.
>
> Thanks,
>
> -Bryant
>
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
------------------------------
Message: 10
Date: Thu, 8 Aug 2013 21:40:24 +0000
From: "Divin John (dijohn)" <[email protected]>
To: Daniel Pagan <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [cisco-voip] DTMF Method Stripped on reINVITE | CUCM
8.6.2
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Daniel,
Do you have CUCm traces ? Detailed SDI/SDL traces for Cisco CallManager?
Regards,
Divin
From: Daniel Pagan <[email protected]<mailto:[email protected]>>
Date: Thursday, 8 August 2013 11:25 PM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [cisco-voip] DTMF Method Stripped on reINVITE | CUCM 8.6.2
Folks:
I?m looking at an interesting issue where CUCM is stripping DTMF method from a
reINVITE and I?m wondering if you?ve seen this before. Topology is pretty
simple: CUCM ==SIPTrunk==VerizonSBC. CUBE is not involved in this scenario for
this particular environment (different issue, different story). Audio
cut-through is successful but no DTMF method is established.
The transaction flows is as follows (Call-ID header and IP addresses omitted):
INVITE -->SBC ? Early Offer in use
..
?.
t=0 0
m=audio 27030 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
200 <-- SBC ? Containing SDP w/ reordered, preferred codecs
..
?..
v=0
o=BroadWorks 492305543 1 IN IP4 10.15.5.119
s=-
c=IN IP4 10.15.5.119
t=0 0
a=sqn: 0
a=cdsc: 1 image udptl t38
m=audio 41194 RTP/AVP 0 18 8 101
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
==========================
CUCM ACK?s the 200 (omitted) to close the transaction and sends a reINVITE with
a single codec but no DTMF method:
v=0
o=CiscoSystemsCCM-SIP 962515 2 IN IP4 10.15.81.106
s=SIP Call
c=IN IP4 10.17.66.123
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27030 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
=========================
The SIP trunk is configured for DTMF method of No Preference. I also see no MTP
allocation attempts from MediaManager in SDI traces which makes me think we?re
not dealing with a media negotiation failure. Other SBC?s in this environment
perform an early cut-through of audio via 183s to CUCM resulting in no issues.
It seems to me the solution would be to force the SBC to send a 200 answer w/
only a single codec in its SDP, theoretically eliminating the need for a
reINVITE. But unfortunately this isn?t possible since the provider is adhering
to the Answer/Offer Model RFC:
?For streams marked as sendrecv in the answer,
the "m=" line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer.?
Any thoughts on why CUCM would be stripping the DTMF method from its reINVITE?
Again, I see no MTP allocation requests from MediaManager, so I doubt it?s the
result of a negotiation failure. Setting the SIP Trunk?s DTMF method from No
Preference to RFC2833 results in the same problem. Lastly, a bug scrub didn?t
come back with anything that matched the symptoms spot on. CUCM is 8.6.2.
Thanks ahead of time!
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130808/0ba3fc9a/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 8 Aug 2013 16:54:41 -0500
From: Bryant Onojeta <[email protected]>
To: "Ryan Ratliff (rratliff)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<CAK5i2X5kKCTodAJEB9cPC-613Hr+3rUnXw6=tdoy5dc0o7x...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I have the daisy chain main power...plugged in to ac...still I am
getting Link Mode: Configuring forever...May have been upgrading
firmware and it says not to unplugg...left plugged in for over and
hour and still same state... no way to check the status of the
upgrade, download...whatever... I cannot leave it up forever...it's in
place for testing....Not sure how to check.. factory default or
what... flash is full???
On Thu, Aug 8, 2013 at 3:54 PM, Ryan Ratliff (rratliff)
<[email protected]> wrote:
> Your steps are correct. The fact that the charging station turns the mic on
> is a bit of a pain out of the box because you have to turn the mic off and
> then back on to start the pairing (as you noted).
>
> There is supposed to be a section in the admin guide but it appears to have
> gone missing at some point. I filed CSCui56402 to get that fixed hopefully
> (it should be visible tomorrow).
>
> For the daisy chain it should just work, make sure you have wall power,
> network, and the DCU on the main unit. If you are using PoE I suspect the
> wall power requirement may be big gotcha. I need to dig up a cable before I
> can test that here.
>
> -Ryan
>
> On Aug 8, 2013, at 4:26 PM, Bryant Onojeta <[email protected]>
> wrote:
>
> I did charge the mic's and the range was high.
>
> What i found was that the pairing is:
> 1.admin setting>wireless mic's>pairing
> 2.press button til led is solid red, let go ( light will go off)
> 3. press button til led is solid red and pairing should be complete
>
> ....
>
> Now i am having issue with the phone linking to another base.
>
>
> On Thu, Aug 8, 2013 at 12:00 PM, Ryan Ratliff (rratliff)
> <[email protected]> wrote:
>> Did you charge the mics out of the box?
>>
>> What is your wireless mic range set to?
>>
>> -Ryan
>>
>> On Aug 6, 2013, at 1:10 PM, Bryant Onojeta <[email protected]> wrote:
>>
>> Hey,
>>
>> Has anyone had an issue with pairing the wireless microphones with the 8831
>> DCU?
>> I cannot get the wireless mic's to pair to the DCU, I consistently get
>> "Microphone 1/2 pairing timeout! Retry?"
>> any help would be appreciated, opened a TAC case and the engineer said that
>> he don't have a phone to even lab this scenario up with.
>> I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do
>> work but the just the wireless mic's won't pair.
>>
>> Thanks,
>>
>> -Bryant
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
------------------------------
Message: 12
Date: Fri, 9 Aug 2013 01:14:47 +0000
From: "Ryan Ratliff (rratliff)" <[email protected]>
To: Bryant Onojeta <[email protected]>
Cc: cisco-voip voyp list <[email protected]>
Subject: Re: [cisco-voip] CP-8831 IP Conference Phone
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I'd start with just the console logs from the web page of the master. There is
also a 'show daisy' command available via SSH (debug/cisco123 is the secondary
login) but I think that's just the status, not a debug.
The status line in the Phone Information screen for daisy should say upgrading
if it's doing an upgrade on the slave. It may also throw an error code.
-Ryan
On Aug 8, 2013, at 5:54 PM, Bryant Onojeta <[email protected]>
wrote:
I have the daisy chain main power...plugged in to ac...still I am
getting Link Mode: Configuring forever...May have been upgrading
firmware and it says not to unplugg...left plugged in for over and
hour and still same state... no way to check the status of the
upgrade, download...whatever... I cannot leave it up forever...it's in
place for testing....Not sure how to check.. factory default or
what... flash is full???
On Thu, Aug 8, 2013 at 3:54 PM, Ryan Ratliff (rratliff)
<[email protected]> wrote:
> Your steps are correct. The fact that the charging station turns the mic on
> is a bit of a pain out of the box because you have to turn the mic off and
> then back on to start the pairing (as you noted).
>
> There is supposed to be a section in the admin guide but it appears to have
> gone missing at some point. I filed CSCui56402 to get that fixed hopefully
> (it should be visible tomorrow).
>
> For the daisy chain it should just work, make sure you have wall power,
> network, and the DCU on the main unit. If you are using PoE I suspect the
> wall power requirement may be big gotcha. I need to dig up a cable before I
> can test that here.
>
> -Ryan
>
> On Aug 8, 2013, at 4:26 PM, Bryant Onojeta <[email protected]>
> wrote:
>
> I did charge the mic's and the range was high.
>
> What i found was that the pairing is:
> 1.admin setting>wireless mic's>pairing
> 2.press button til led is solid red, let go ( light will go off)
> 3. press button til led is solid red and pairing should be complete
>
> ....
>
> Now i am having issue with the phone linking to another base.
>
>
> On Thu, Aug 8, 2013 at 12:00 PM, Ryan Ratliff (rratliff)
> <[email protected]> wrote:
>> Did you charge the mics out of the box?
>>
>> What is your wireless mic range set to?
>>
>> -Ryan
>>
>> On Aug 6, 2013, at 1:10 PM, Bryant Onojeta <[email protected]> wrote:
>>
>> Hey,
>>
>> Has anyone had an issue with pairing the wireless microphones with the 8831
>> DCU?
>> I cannot get the wireless mic's to pair to the DCU, I consistently get
>> "Microphone 1/2 pairing timeout! Retry?"
>> any help would be appreciated, opened a TAC case and the engineer said that
>> he don't have a phone to even lab this scenario up with.
>> I am running the latest firmware for the 8831on CUCM 8.5.1, phone calls do
>> work but the just the wireless mic's won't pair.
>>
>> Thanks,
>>
>> -Bryant
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 118, Issue 7
******************************************
